We are running Big Fix version 9.5.7 on Windows Server 2008R2. Lately, we have been experiencing an weird issue involving some automatic services on our Windows Server clients not starting up on reboot after patches are deployed. We will create a baseline with Windows patches for our servers, schedule the baseline to deploy to the servers off-hours, and configure a post action to restart the client after completion. When we come in the next day, we will see that the action completed successfully, but many automatic services on the servers will not be started. Most of these are critical services related to the application installed on the server, but some of them are Windows services like Volume Shadow copy. If we do a straight reboot from the servers themselves, the services always seem to start up fine. It’s only after we have deployed baselines through BigFix that we seem to have this problem. I do not have any direct evidence that says it is BigFix definitively, but nothing else makes sense. Our servers are a mix of 2008R2 and 2012. So far, the issue only seems to affect the 2008R2 clients. And it is not every automatic service. Only some of them. The event viewer does not provide much help. Just get a generic event saying the service did not respond to the start command in a timely manner. I was just wondering if anyone has ever dealt with this before.
Have you verified that the server(s) actually rebooted after the baseline completed?
Yes, the servers are rebooting. All of the proper Windows events are logged. I have also watched it live during tests
Hi @rsturtevant did you ever find a solution to this problem? Although this is an old thread, I am seeing the same on Win2016 and Win2019 servers today. Would this be related to patching in a Baseline? Is anyone else experiencing this problem?
There are lots of threads about this issue on other forums - On https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/services-not-automatically-restart-nic-teaming they suggested to configure:
Set the Startup type of the service to Automatic (Delayed Start)
(Or)
Service’s Recovery properties to Take action on First failure and Restart the Service on Second failure.
I saw this on some of my initial win2016 builds a few years ago
My issue was with patching running the systems out of real memory and required paging.
At the time the paging was set to system managed and it started lests than a gig and grown on demand. Since this was the final boot and updates were being applied service failed to start due to lack of memory. Because systems slowly grew their page space the issues randomly stopped for some while on others it started.
MS in their great paging algorithms - when a process needs memory and the paging space needs to grow to compensate for not enough free real memory, it does not pause the request and grow the space - instead it fails the process and grows the space. The solution was to not have paging set to system managed and set most of my systems with hard Min 7g max 8g page spaces.
We don’t ever want to page but some times you cant see it coming, and need to provide for that one off scenario, otherwise I would rather fail the system then live day to day with paging