wntSvcStatus

[chrislegarth]

I recently migrated a scheduled task that I had on running a Windows 2012 server over to a Windows 2022 server. When the task ran on the 2012 server it took about 10 minutes to complete. The same program on the 2022 server takes 40 minutes. I simply copied the task to the new server. Same program, same network account. I iterate through a list of servers, checking if two services exist and what their current status is. The debug log shows that every time the wntSvcStatus function runs on the 2022 server, it takes 21 seconds to get a response. On the 2012 server, the first time wntSvcStatus ran it took 21 seconds but the subsequent 3 times the responses were immediate.

Any thoughts on what may be causing this?

Thanks in advance!

[td]

You prefaced your post by saying that you have a scheduled task and then you referred to a Windows service. Which are you referring to?

From first-hand experience, I know that a properly written script running as a scheduled task on 2012 will work on 2022 without change assuming all needed resources are available to the script.

[chrislegarth]

Sorry for the confusion.  The scheduled task (WinBatch script) runs on the 2022 server.  The script iterates through a list of Windows PCs checking for the existence and status of two services.

[chrislegarth]

More info...
Resource wise the only difference I see between the two servers is that the 2012 server was provisioned with 4 sockets and 4 vCPUs.  The 2022 server is provisioned with 2 sockets and 4 vCPUs.  The processor type is the same on both virtual servers.  Other than that the 2022 server has additional resources for memory and storage.

[chrislegarth]

Looks like I found my solution.  I came across this article (https://learn.microsoft.com/en-us/windows/win32/services/services-and-rpc-tcp) and performed the To disable RPC/TCP on the client side step and my scheduled task now completes in 10 seconds.  If this registry key breaks something else is TBD. :)

[td]

Interesting and also impressive that you found the somewhat obscure solution. Since Windows Server 2012 is a post Vista OS, one would think you would have encountered the same problem/solution on 2012. Perhaps the registry change had already been made on the 2012 system?

If you feel inclined, posting about any adverse side effects of your registry change would be informative.

[chrislegarth]

The registry setting wasn't on the 2012 server which is why I think it timed out on the first attempt.  I'm baffled as to why the next three were immediate on 2012 but not on 2022.  So far so good on any side effects.

Thanks!

[td]

The change to SCM behavior related to communication protocol could be the result of MSFT fiddling with some code without considering all the side effects.