Caveat when connecting your BC container to a default SQL instance or why does importing the encryption key fail

Considering the big news today, this is only a small nugget of information but as I wasted a couple of hours trying to find out what goes wrong, I still wanted to share it: Connecting a BC or NAV container against a SQL Server running outside of that container is pretty easy, you just need to set a couple of env parameters. Assuming that you have a database called newsystem_180110600 on a server called s00-nsys-ver using the default SQL instance your would do something like the following

docker run -e databaseServer=s00-nsys-ver -e databaseName=newsystem_180110600 -e "databaseUserName=testuser" -e "databasePassword=DontThinkSo" -e accept_eula=y mcr.microsoft.com/dynamicsnav:2017-cu31-de-ltsc2016

Unfortunately this will fail, seemingly when trying to import the encryption key.

Initializing... Starting Container Hostname is 6f21d1c43e61 PublicDnsName is 6f21d1c43e61 Using NavUserPassword Authentication Starting Internet Information Server Import Encryption Key Cannot establish a connection to the SQL Server/Database. This could be due to one of the following reasons: * SQL Server is not started. * The database does not exist. * Proper permissions have not been given to the NAV Server Account. Try again later or contact your system administrator.

My first inclination was that this actually is a problem with the encryption key, but this is only a coincidence¹. The problem happens because during the build process the container is configured to look for database server localhost and database server instance SQLEXPRESS. Unfortunately that configuration is never cleared, so if you don’t actively override it, it is still in place when running the container which effectively means that with the configuration above the container looks for the right database on the right server, but on instance SQLEXPRESS, which of course fails. The workaround is to just let the container explicitly know to use the unnamed instance with

-e databaseInstance=

With that in place, the container starts fine.

docker run -e databaseServer=s00-nsys-ver -e databaseInstance= -e databaseName=newsystem_180110600 -e "databaseUserName=testuser" -e "databasePassword=DontThinkSo" -e accept_eula=y mcr.microsoft.com/dynamicsnav:2017-cu31-de-ltsc2016 Initializing... Starting Container Hostname is 5128441a07d2 PublicDnsName is 5128441a07d2 Using NavUserPassword Authentication Starting Internet Information Server Import Encryption Key Creating Self Signed Certificate Self Signed Certificate Thumbprint 118282BC3C5BCCE93D176A11E3CAD246FBA35A65 Modifying Service Tier Config File with Instance Specific Settings Starting Service Tier Creating Web Site Creating Web Server Instance Creating ManagementServicesPort and setting it to 7045 Creating http download site Container IP Address: 172.20.192.123 Container Hostname : 5128441a07d2 Container Dns Name : 5128441a07d2 Web Client : https://5128441a07d2/NAV/WebClient/ Files: http://5128441a07d2:8080/certificate.cer Initialization took 40 seconds Ready for connections!

There would be a somewhat easy solution for this (s. PR #373 in the nav-docker repo) but Freddy Kristiansen understandably argues that we have an easy workaround and there probably already are solutions out there who expect the behavior as it is today.

The error message is actually very clear…

The Author

Tobias Fenster