Powering Microsoft Dynamics NAV  2013 on AWS ­ - 1

. July 20, 2016 .

Dynamics NAV​ is one of the widely used solutions for warehouse and inventory management by  firms across various sectors. Given the feature­set and ease of adoption, this is one of the  favorites of SMEs. We decided to move from Uniware to Dynamics NAV in mid 2015. Traditionally, NAV is hosted independently on a physical server. However, given that our entire infrastructure, including test stacks existed on AWS, we went ahead with a complete AWS  based solution. Issues with Uniware, our earlier WMS   Uniware was a cloud­based WMS which we had been using since 2013. We had started  outgrowing the system ­ its rigidity, lack of powerful APIs and customizability quickly forced us to  move to NAV

While Dynamics AX is a big brother of Dynamics NAV in terms of feature set and size, we firmly believed that Dynamics NAV is the right choice for us given the scope of Dynamics AX, the fact it is fundamentally targeted towards large enterprises and importantly our need to hit production at the earliest. 

Structure of Dynamics NAV   

Core components of a basic NAV implementation include:

  • Dynamics NAV Service and Web Client  
  • SQL Server Enterprise/Standard  
  • Active Directory for user management 

Why Active Directory ?   

Since you are doing a production setup, chances are high that a lot of users are going to use  the webclient. Hence Active Directory is far preferable for user management when compared to  in database or form based solutions. Also for a two tiered architecture Active Directory is pretty much a must as you scale up, unless you have one running in your infrastructure already.   

Some benefits:  

a) Your Dynamics NAV and SQL server authentication can be controlled by a dedicated AD  user. You can also use AD service accounts for even more flexibility and control.  b) All users can be centrally managed via Active Directory, giving much better user tracking compared to having all your users solely residing in NAV database.  
 AWS solutions for Active Directory   

When we started with AD implementation on AWS, Samba­based Simple directory service was the only option available against hosting our own individual Active Directory server which would not be feasible due to the maintenance involved. Later, Amazon introduced a native, Microsoft  based Directory service in addition to SimpleAD service.   

While SimpleAD is pretty decent for most workloads, there are a bunch of important restrictions  here.    

There is no way straight­forward way to migrate from a SimpleAD based Active Directory to a Microsoft based AD from within AWS or vice versa. If you have more than 3000 users, it is  better to go for Microsoft AD, even though it is expensive.

Simple AD, while cheaper has few disadvantages due to bugs present in the Samba4  implementation of Active Directory. ​Most notable one​ is an empty SPN field leading to  Windows Server Cluster setup failing at validation stage. Failover cluster creation and  validation are the initial steps before a High Availability cluster is created in SQL Server  2012. Fortunately we found a ​workaround for this bug​ where the fix is to not keep the SPN  field empty.  

We had to start a seperate Windows 2008 based instance due to an ​existing issue​ with  SimpleAD service which threw a fit when adding users to Active Directory on a Windows  2012 instance. We lived with this issue until very recently, when Amazon upgraded their  SimpleAD service to remedy this. Now we have installed AD DS tools within our primary  NAV Server to avoid the overhead of an additional instance. 

Dynamics NAV server on AWS   

Our first thought was to go for a three tier architecture with separate web client and server machines. However since Dynamics NAV serves internal stakeholders in the firm, we didn’t expect the volume of web requests to be sizeable enough to warrant a dedicated web client node. Hence we settled for a two tiered architecture with the Dynamics NAV server and IIS Web­client running off a single  server with a separate SQL cluster.

Automated installation using Chef    Although this was basically a cakewalk, there are some factors to be taken care of here    

a) IIS is a principal dependency for Dynamics NAV along with .NET 3.5  For IIS you can use the IIS cookbook for installation ​https://github.com/chef­cookbooks/iis  .NET 3.5 is a simple to solve scenario, where you can simply toggle windows features using the ​windows_feature​ chef resource 

b) Dynamics NAV installation is done off the recipe from a configuration file stored in S3


Security Group: Inbound ports to be opened

7047 ­ this will be your SOAP Services port by default and needs to be open to all your services that are talking to it.

7046 ­ In case you would want to connect a desktop client to your Dynamics NAV server.

7048 ­ default ODATA port, needs to be open to pull reports right off of Dynamics NAV from third party solutions.

1433 ­ SQL default port. Change this port to obfuscate it for more security. Make sure that NAV machine has access to this port.

3389 ­ For remote desktop access


In the next part of this blog, we will be exploring SQL Server High Availability setup for Dynamics NAV

This article has been authored by Ganesh Hegde, a DevOps engineer at Urban Ladder.  While not fiddling with code and systems Ganesh loves to pretend he is on a diet. Ganesh has a penchant for dark humour.


Tagged Under