NAV server instance, set to autostart, sometimes not automatically starting

q_hartgers

Dear all,

We have observed the following behaviour from a well-running, functioning environment:
1) Windows Updates are applied. This triggers a required reboot.
2) AD-servers will go first, in terms of updating & rebooting.
3) Navision application servers follow after (2).
4) Navision application servers have the Microsoft Dynamics NAV Server [x]-service set to automatically start.
5) The recovery settings on first, second, and subsequent failures are set to restart.
6) Sometimes, the server instance, does NOT automatically come back up.

Now, we have examined the Event Viewer carefully to find the nature of this, but found anything we can relate to Dynamics NAV. Also, we have not been able to reproduce this. Sometimes, the server-service starts (as intended). Sometimes, it just does not, for no appearant reason.

I understand that you might require more information/details before you can give a solid view/opinion, please let me know what you need. I will check this topic frequently. Thanks so much!

RemkoD

Hi q_hartgers,

Do you have Port Sharing enabled for the NAV Service Tiers? If you've I would recommend to set the NAV services to startup type 'Automatic (Delayed Start)' to prevent the service from starting before the depending Net. Tcp Port Sharing Service is up.

I'm not sure if the Recovery settings on the NAV Service kicks in if the service didn't start proper the first time.

I would expect an error in the Windows Event Viewer Application log. Odd nothing is there.

Slawek_Guzek

Set your nst service dependencies to include the SQL Server, so it won't try to start before the SQL server is up.

You can use command line tool sc for that.

q_hartgers

@RemkoD, thanks for your suggestion. I will change the startup type to see if it makes a difference (over time, might take some time before we are able to conclude anything given the erratic nature).

@Slawek_Guzek thanks for your input, I will check on how to configurate this and see if it makes a difference (over time).

q_hartgers

@Slawek_Guzek What technique do you suggest when the specific service/services are not on the same server? Thanks a lot!

Slawek_Guzek

I'm afraid I don't know how or if it is possible at all to synchronize startup of services across different computers. I don't think that any built-in mechanism exists in Windows allowing such thing.

The only workaround I can think of is to try to start the NST services remotely, from the SQL server, using some script which runs automatically when the SQL Server starts.

For example; you could set up a SQL Server Agent job, having a task of PowerShell or Command Line type, this task would attempt to start the NST(s) on the remote box(es) (remote to the SQL Server box). You could set the startup option in job schedule for that job to run at startup.

There is one other thing to check when it comes to setting up dependency (between local processes)

Perhaps your NST service(s) already depends on some other service(s) (HTTP, and/or NetTcpPortSharing). It that's the case then Windows will not attempt to start it, before all services it depends on are up and running - therefore the NST process recovery settings won't apply.

Also if such a process gets stopped your NST(s) depending on it will be forced to stop too.

If you do already have some dependencies for the NST process, make sure to set the recovery option on all processes your NST depends on, to ensure that the OS will try to resurrect them too should they fail.

About Delayed Start option - personally I don't think that it may not help, it may even get things worse. The Delayed Start option is described nicely here. There is one interesting sentence in the article:

The Service Control Manager starts services that are configured for the delayed automatic start after all of the automatic-start threads have finished starting.

The implication of the above would be that if any process configured in Automatic start mode will fail to start (for any reason) the OS will not attempt to start processes configured for Delayed Autostart.

The article, however, is quite old, and things might have changed since Windows Server 2008, also I may be misinterpreting the "have finished starting (I assumed finished starting = started successfully) - so it may still be worth to give it a go, having remembered that new Delayed Autostart is the first suspect if things get worse.

Balwan

No

Balwan

.

RemkoD

Balwan wrote: »

No

I think your 'no' was meant for this topic?

q_hartgers

Slawek_Guzek wrote: »

I'm afraid .... get worse.

Slawek, thanks so much for your input. I will have to figure out a way to go with your suggestions and you have been most helpful! Much appreciated.