Powering Microsoft Dynamics NAV 2013 on AWS - 1
Dynamics NAV is one of the widely used solutions for warehouse and inventory management by firms across various sectors. Given the featureset 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 cloudbased 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, Sambabased 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 straightforward 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 Webclient 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/chefcookbooks/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.
