Windows Services and Patch Management
Every month, during patch week, Windows administrators face challenges trying to execute a successful patch cycle. These can range from something as small as time constraints in their patch windows, to major obstacles like server owner resistance in allowing their servers to be patched. It also doesn’t help that patch cycles often include at least one reboot of the target computer.
Concerns expressed by application owners about the adverse effects of forced reboots on databases or mission critical applications are real. Because of this, it is sometimes necessary to gracefully shutdown certain services before a reboot to avoid corruption or loss of data.
Since production services cannot be shutdown for hours before patching begins and patching usually begins after hours, server owners traditionally have had two options to choose from:
-
- Give the patch administrators access to logon to servers and let them shutdown services.
- Work during the patch cycle to stop the services yourself right before patching occurs.
Neither one of these is a particularly appetizing choice for very different reasons. This was the world before BigFix. Using BigFix to patch opens up a new avenue which addresses both of these concerns rather elegantly.
Patch Management Access:
Server owners are not particularly thrilled to give just anyone access to their servers, but with BigFix, they don’t have to. Because the BigFix Client acts with Local System authority and it will be the one performing the operation, patch administrators do not need admin rights on the servers they will be patching.
Patch Orchestration:
BigFix has the ability to manage many aspects of a host computer. As a result, gracefully stopping services is as simple as issuing a command in a Fixlet or a Task. This can be done days, hours or even minutes before patching occurs. There’s no longer the need for anyone to be up at odd hours of the night logging on to servers just to issue a simple command.
By creating a task that shuts down certain services, and placing it first in a Baseline, a patch administrator can ensure that production services will be available right up to the last minute before patching begins. The services can then be gracefully stopped, minimizing the possibility of data loss or corruption.
Once this is done, patching can proceed and when the reboot occurs, services set to auto will be restarted. Any service set to manual will require an additional step after patching to ensure the service is started. BigFix can address this as well.
I uploaded such a task to bigfix.me that will help patch administrators work with services pre and post patch. It can be downloaded here:
https://bigfix.me/fixlet/details/26928
The task is ready to go with one exception. Once downloaded, you must change the URL in the action command so that it reflects your own Root Server location. This must be done in both Action 1 and Action 2.
The task has four actions. Their functions are briefly described below:
Action 1:
This option allows you as the operator to create a list of ‘service names’ you consider ok to leave running during patching and any subsequent reboots. This list will be used as a basis for comparison with the running services on the target computer. Any service running on the target computer that is not on this list will be stopped prior to any patches being installed.
Action 2:
This is essentially the mirror of the first action. This action allows operators to create a list of services they specifically wish to stop before a patch cycle. The computer will then stop only the services on this list.
Action 3:
Sometimes you just need to stop a single service. This option provides that functionality by allowing the operator to enter the ‘service name’ of any one service. The BigFix Client then instructs the computer to stop only this service.
Action 4:
If a service start-type was set to manual, it will not restart after a reboot. This option allows the operator to enter the ‘service name’ of any one service and start it remotely.
That’s it! It’s a simple as creating your whitelist or stoplist and the task will do the rest. Once you download the task, remember that you can modify anything about it, from the Relevance clause to the parameters in the actionscript, the file names, locations or any of the commands within.
Those familiar with ActionScript will have no trouble modifying this task to their liking. If you are new to BigFix however and want to learn more about the power of the Relevance language, take a Content and Relevance class. You’ll be writing your own Fixlets and Tasks in no time.
