Port Sharing with NAV2013

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:

• Use service accounts
  
• Set up delegation / registering SPN’s
  
• Handle the Query Notification
  
• ….
  

What I always liked about how we are able to set it up, is the fact that we are able to use instance names!

Some history

For months, we had been installing databases and NST’s for our development environments internally, and we had been installing all NST’s with separate port names. What was that all about? You can imagine we were keeping and managinglists, like:

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:

• Always use the same, default ports
  
• Always give a significant meaning to the Instance name
  

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.

Port Sharing

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:

1. First search for the Service name in the properties of the service where you want to configure Port Sharing
   
2. Open a cmd shell and type the following command:
   

   
   sc config MicrosoftDynamicsNavServer$Waldo_Demo_2013 depend= NetTcpPortSharing/HTTP
   

3. Do this for all services that are actually trying to use those ports.
   

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