21. November 2016

NAV 2017 on Linux – sort of

After the more and more open way Microsoft works with Linux and Open Source in general in the last couple of years, it probably was only logical to also open the SQL Server strategy up. Still I have to admit that I was quite surprised when the announcement for SQL Server on Linux came. I’ve been working with Linux since my first developer job (creating a Tcl/Tk based GUI for an Adabas db, so you can guess how old I am) while I was still at Gymnasium (High School) and actually tried my very best to keep my environment on Linux even when I started to work with NAV by running my laptop on Ubuntu and doing everything in NAV, Office and Outlook through a VM. Not a pretty solution but really Linux has some advantages and when I had a problem with my WiFi driver in connection with Hyper-V and therefore got regular BSODs, I fondly remembered my never-crashing Linux machine. But to get back to the topic, my interest in SQL Server on Linux was there and I therefore was excited to see the corresponding announcements. As I already learned some things about Docker and Windows Containers for NAV in the last couple of days, I decided to give SQL Server on Linux in a Container a try.

Getting it to run was not as easy as the SQL Server in a Windows Container on a Windows Server because I decided to try this on my local machine (running Windows 10 anniversary update). First I had to install Docker for Windows and went with the latest beta. Then I did a

docker pull microsoft/mssql-server-linux

That went as expected but the machine didn’t come up. After a lot of digging I found two things where I went wrong:

I had to configure Docker to use 4GB of memory because at least on my machine it came with a default of 2GB but then the SQL Server container doesn’t even start. You can configure this under “Advanced” in the Docker Settings. And it is clearly stated as an important hint on the MS documentation here but reading the manual unfortunately never was my strength (and dark yellow letters on a light yellow background is not exactly inviting to read).
For whatever reason the command stated on the same web site to run the Container didn’t work for me. I had to adjust it slightly to get it to work:
```
docker run -e ACCEPT_EULA=Y -e SA_PASSWORD='&lt;YourStrong!Passw0rd&gt;' -v c:\users\tfenster:/data -p 1433:1433 -d microsoft/mssql-server-linux
```

After that I also struggled for quite some time to connect to the SQL Server. First I suspected my SQL Server Mgmt Studio 2014 and downloaded the very latest 17.0 RC1 but still had no luck. The error message stated something about named pipes, so I tried to force it to use tcp by connecting to

tcp:localhost

That also didn’t work, but at least the error message now showed a TCP connection problem. After tinkering with my firewall, changing the port exposure in the Container and updating my network drivers (didn’t make too much sense and led to the mentioned BSODs but I really wanted this to work) out of frustration I just clicked on “connect” a second time. And to my surprise, it worked!

From then on it was easy as expected: Restore the Cronus DB, configure a NAV Server instance locally on my machine to connect to the database in the Container, use SQL database authentication and generate an encryption key. After starting the instance I could just connect with Dev Environment and Windows Client as usual. I probably shouldn’t have been surprised, but I didn’t expect it to be this smooth. I really like it and have to say that starting the container (and SQL Server in the Container) is really a lot faster than starting SQL Server directly on my Windows laptop. And interacting with NAV through the Windows Client also seems faster although I just played with it a bit.

The next step now is to bring the last two blog posts together and connect my Windows Server Container NAV installation with the SQL Server on Linux Container. I probably am repeating myself but it really is amazing what is possible now that at least I wouldn’t have dreamed of two or three years ago.