As you might know, installing NAV2009 isn't painless. Or at least .. that's my idea of it. The NAV-typical "beauty of simplicity" is hard to find… you have to do quite a lot to have it successfully installed:
What I always liked about how we are able to set it up, is the fact that we are able to use instance names!
Same situation at our first customers, where we always install 3 environments, which we call: QA, LIVE, TRAINING. For every customer, we had to point them to url's, like:
There is obviously something very wrong in this way of installing NST's. First of all, we're able to provide instancenames in the CustomsSettings.config:
So we decided to turn things around, and:
This made our internal NST connection strings look like:
And at the customer:
I'm sure you agree that this (and only this) makes sense .. and the first situation didn't. The only problem is .. It needed some setup.
It's all about sharing ports, and distinguish your services with a unique instance name. Sharing ports is not configured by default, and is actually enabled by starting (and setting up as "Automatic") the "NetTcpPortSharing" service:
If this isn't running, none of it all will work.
Furthermore, NAV 2009 and NAV 2013 aren't configured as being shared at all. This involves some manual configuring..
Let's now focus on the NAV2013-part (you most probably figured out how to do all this in NAV2009 anyway ;°)).
What happens when you're using the Microsoft Dynamics NAV Administration tool?
This tool rocks. This tool is what we missed with NAV2009, right? :-). Well, like I explained above, I would like to be able to set up extra service tiers on my machine, sharing the same 4 ports (7045..7048), but having other instance names. Having an advanced Administration tool like this, will do all tricks, I guess … .
First thing I do is "Add Instance" in the Admin tool, and complete the necessary fields like I would like to use it:
I'm not caring about the account right now, because that's beside the point of the blogpost.. . Normally, I would always use a service account, just because of "best practices" of installing and running services on multiple tiers... .
Note that I'm already running a default installation-instance, called "DynamicsNAV70".
After the install, you'll see the added instance, and you think all is fine:
(note, the other services are NAV2009 services on my machine)
Until you're trying to start the service. You'll see this error message popping up:
And when you're checking the log, it actually says that the Port isn't shared.
Well, it's actually no hocus pocus .. . Starting the NetTCPPortSharing service isn't enough .. I also have to change the service-configuration for using NetTCPPortSharing, the default instance that came with the setup DVD, is not sharing its port, thus claiming it, which makes it impossible for my second server to also use the default ports.
Make sure all services use NetTCPPortSharing
Well, this will involve some small steps:
sc config MicrosoftDynamicsNavServer$Waldo_Demo_2013 depend= NetTcpPortSharing/HTTP
Afterwards, restart the services. You can do that using the Dynamics NAV Admin Tool again. Off you go!
Is that all?
Not exactly. When you're using a dedicated service account, things might become a slight more difficult.
But I'll keep that for coming blogs… (as this hasn't anything to do with portsharing..).
Is there a maximum number of NST's that we can put up on 1 port?
Are there any consequences if we install a large number of NST's on 1 port?
Thanks for the tip :-).
Mgt-tools are always nice .. but knowing what's behind is necessary, I guess ;-)
I always install Tegos ServiceTier from www.mibuso.com/dlinfo.asp
Then its easy to manage NAV-services.
Who knows ;-)
Now we just need Microsoft to add this to their next release of the admin tool...
Indeed. That's why I said "Do this for all services that are actually trying to use those ports" :-)
Now I finally got the time to test it. Works fine, as long as you remember also to do the port sharing for the standard instanse.
Thanks for sharing. Managing all these different port numbers has been a nightmare since NAV 2009. Looking forward to test your solution.
right .. just saw you were talking about NAV2009 ;-) .. while I was still in NAV2013 with my mind ;-).
thanks for the tip! :-)
one thing .. doesn't it need to be something like:
Very important when creating a new service (NST) is also to give it an instance in the binpath.
sc create MicrosoftDynamicsNAVServer_Test binpath= "C:\Program Files (x86)\Microsoft Dynamics NAV\60\Service\Microsoft.Dynamics.Nav.Server.exe" DisplayName= "Microsoft Dynamics NAV Server_Test" start= auto type= own depend= NetTcpPortSharing
sc create MicrosoftDynamicsNAVServer_Test binpath= "C:\Program Files (x86)\Microsoft Dynamics NAV\60\Service\Microsoft.Dynamics.Nav.Server.exe $TEST" DisplayName= "Microsoft Dynamics NAV Server_Test" start= auto type= own depend= NetTcpPortSharing
This is because NAV uses the ProgramData directory. When you don't give it an instance, every assembly, temp, ... is created in the same folder.
You must give it an instance so NAV can use a different directory in the ProgramData.
Today I had the issue that NAV said sth. like "Meta data for object XMLport 50000 is in an inconsistent state, which [...]" and with the ProgramData directory. After creating the service new, the issue was solved.