Solutions
Markets
References
Services
Company
Caveat when connecting your BC container to a default SQL instance or why does importing the encryption key fail

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

31. July 2019

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 coincidence1. 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.

  1. The error message is actually very clear…