Port sharing no longer works ?

Slawek_Guzek · 2016-11-09

Dear All

I used to have 10 different instances configured on the server with port sharing, there was a mixture of 2009/2015 and 2016 NST servers. Most of the time 3 or 4 NST servers were running in parallel with no problems.

I have recently added 2017 instance, removed 2015 NST and upgraded all 2016 instances to CU12-GB version and from that point onward I cannot get port sharing working.

All the services are configured to depend on Net.Tcp.Port.Sharing service. The AD account which is used as a service account for all NST services has been added to <allowAccounts> in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SMSvcHost.exe.config file.

It used to work fine but now is not.

I have installed 2017 and at this point everything seemed to be still working, I've had 2 NST one 2016 and one 2017 NSTs working fine for a short period of time.

It looks like installing CU12-GB broke the thing. I have installed CU12 by uninstalling previous version and installed CU12 from using setup, rather than overwriting existing binaries in Service folder.

Does anyone experiences anything similar?

Regards,
Slawek

davmac1 · 2016-11-10

what is the advantage of doing port sharing? i always use separate ports for all my instances.

DenSter · 2016-11-10

using port sharing makes it so you can use the same port numbers for multiple service tiers

davmac1 · 2016-11-11

my question is why? there is no shortage of port numbers. is this used to cut down on firewall rules?

Slawek_Guzek · 2016-11-11

It is easier to manage only meaningful service names and stick to standard 7045 - 7048 range rather than for each instance have a new set of ports. IMHO.

Some Big Names in NAV world also think it is only way which makes sense

ara3n · 2016-11-11

MS stopped supporting port sharing in 2013 and yes there was a workaround but I guess it finally stopped working. I never use it myself.

Slawek_Guzek · 2016-11-14

That would be a shame...

I am downgrading back to CU6 to double check it.

Slawek_Guzek · 2016-11-22

Downgrading to CU6 didn't help.

But.

Have been to NavTechDays 2016 and managed to speak to two Microsoft guys (Thomas Hejlsberg who is Chief Architect / CTO and and Vincent Nicolas who is Principal Engineering Manager) and they both said it SHOULD work..

The have pointed to possible .NET differences - 2017 brings NET4.5.2 while 2016 is using NET4.0 - therefore there might be some conflicts somewhere.

Slawek

DenSter · 2016-11-22

I was also at NAV Techdays and in one of the pre conference workshops we had portsharing turned on with NAV 2017, so that still works

Slawek_Guzek · 2016-11-23

@DenSter Do you know/remember SQL version they have been running on?

DenSter · 2016-11-28

Not sure if that matters, but I have SQL Server 2014 on Windows Server 2012 R2, running in a VMWare Fusion virtual machine on a MacBook Pro, with NAV 2017 build 10.0.13682

kriki · 2016-11-29

SQL server shouldn't matter. I have used port sharing with all kinds of SQL Server versions (2008R2,2012,2014,2016). No problem at all.
Important is that your NAV Service is enabled for portsharing. If you forget to do that and start the service, the other (port sharing) services will not start anymore.

Slawek_Guzek · 2016-11-30

It was not about SQL Server as such, more about complementary software it comes with it, or prerequisites - like .NET. And that actually might matter if SQL and NST are on the same box.

For example SQL 2012 needs .NET 3.5 SP1, SQL 2014 installs .NET 4. and SQL 2016 installs .NET 4.6.1 NAV has its own requirements - both NAV 2016 and 2017 use NET 4.5.2.

Having said that I've had SQL2012 plus 2009, and 2015 and 2016 NSTs all working with port sharing for more than a year - so certainly I have not forgotten any configuration bits. They all have been working fine until recently, when they all refused to work with port sharing. It happened when I have added another 2017 NST and it didn't matter in what order I have tried to start services - on one worked at a time.

I have managed to get all working back. I did make some changes like adding the service account to local Administrator group on the server and it seemed to help - although I am pretty sure it used to work without it. I have an entry in SMSvcHost.exe.config to allow this specific account to use port sharing and that seemed to be enough for long time.

The problem is that I am an "occasional admin" on this box, we have IT people dedicated to take care of servers. It is possible that they have made some changes without telling me that could have broken the port sharing - and the fact that port sharing stopped working when I've installed 2017 NST was just a coincidence - problem was before there but it surfaced later after server reboot.

vaprog · 2016-12-01

Hi Slawek,

I noticed you mentioned an absolute path to the SMSvcHost.exe.config file in your first post. That config file needs to be in the same path as the SMSvcHost.exe that is actually run as your NetTcpPortSharing service. You can find this path in the properties of the service in the management console or from the command line using

sc qc NetTcpPortSharing

Slawek_Guzek · 2017-08-18

Its been quite a long but I though that I will post an update for others who may face similar problems.

I've finally managed to get to the root cause of the problem. The problem was the NST service dependencies configuration in the registry.

The service dependencies are held in registry, in HKLM\SYSTEM\CurrentControlSet\services\<nstservicename>\DependOnService key. The dependencies are listed as a list of service names , separated by an carriage return character. Like this:

In my case the HTTP dependency was listed twice, like this:

The above is apparently incorrect as with this setup the port sharing didn't work.

The other problem in my case was that this incorrect setup with HTTP service listed twice somehow ended up in in the default instance registry key, and each time I created a new instance it has been copied to the new instance registry keys.

Regards,
Slawek

TimSimmonds · 2017-11-06

Hi,

This post was useful in finding a solution to our similar issue.
In checking the registry keys, in our case it appears that the keynames are case sensitive and we had typed NetTCPPortSharing instead of NetTcpPortSharing into the SC command.

eg.
sc config <ServiceName> depend =NetTcpPortSharing/HTTP

Cheers.

Slawek_Guzek · 2017-11-06

I'm glad it helped. It costed me a lot of time and frustration to get to the bottom of this.

Also I've forgotten to mention that dependencies should be defined using SC utility - editing directly the DependOnService key in registry generally does not work.

Slawek

Port sharing no longer works ?

Comments

Categories