Handling Services on Remote Systems, Part 1 – Determine Startup Type

Lately I have had the task of devising a way to stop a particular service (or services) on a number of systems. Once stopped, property files would be updated and then the services restarted. You can imagine that doing this on 6+ servers each with at least 6 to 10 individual service properties to be corrected… Yeah, it takes a while. To add to the fun, just stopping the service through the service manager is not enough. The services have to be killed or they get stuck in a “Stopping” state.

I have become a fan of AutoIT after years of scripting with batch files and some time with PowerShell. Don’t get me wrong, they are still viable solutions. I use them for quick tasks. If the tasks are large and I want some visible feedback, I reach for alternative scripting languages, such as AutoIT. That being said, I’ll dive into this project.

Goals of this script:

  1. Locate the service in question within the registry on the remote system.
  2. Reading the correct key, find the name of the service to work with.
  3. Locate the process name that will need to be “killed” to prevent it from being stuck in a “stopping” state.
  4. Confirm that the service is indeed stopped.
  5. Update the properties file of the service.
  6. Restart the service and confirm it is operating.

To complete these goals, I plan to walk through different parts of the script in no particular order.  I will be completing these tasks with AutoIT which can be found here if you wish to follow along.

I am going to start by saying that this script involves working with your system Registry and could cause harm if not careful. I am not responsible for problems caused by these scripts. They are here as examples.

We will be reading registry keys related to services from the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Lets start by determining the type of startup a service is configured for. We will test using the local system “Alerter”, “Removable Storage” and “Computer Browser” services. Your results may vary depending on how your system is configured. You are welcome to choose different services to test against.

AutoIT makes available a nice built in function called “RegRead”. Providing it with the keyname and the valuename with return the value in that registry entry. Its syntax is RegRead ( “keyname”, “valuename” )

Take this line as an example: $regValue = RegRead (“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Alerter”,”Start”)

It will return a string value of what the Key is set for. The Key, “start” in this case, contains a value indicating what type of startup a service is configured to use. There are 3 values that we will be interested although there are 5 different possible values. I’ll not go into details about all of the values. More information can be had here from Microsoft. Here are the values we are looking to see:

Start Type Meaning Friendly Name
0x2 To be loaded or started automatically. Automatic
0x3 To be loaded manually by the user. Manual
0x4 Not to loaded in any condition. Disabled

When you use the RegRead function, it only returns the numeric values shown in the first column above. This is fine if you are not looking to display information when your script is executed. Lets say you wish to return values like you see in the 3rd column instead, making the results more human friendly. What I did was to create a Case statement to interpret the values for me.

This will now translate the “0x4” retrieved by RegRead into “Disabled”. From there you can take that value and return it to the user or use it elsewhere in your script. Here is a quick example that displays the service name and the startup type for the service in a message box.

Pretty simple, huh. Its not the most flexible of scripts but it gives some idea on how to handle registry data. A more elaborate method and perhaps one that makes more sense, woould be to turn the Case statement portion into a function. This would allow it to be transported to other scripts were needed in the future. For example…

Ok, maybe a little confusing. To sum up, I placed my values in more variables. Created a new registry key to be read based on what is passed to the function. The “$sysName” and “$svcName” are the two main players here. When this function is called, the name of the system is passed to the function and the Service name is passed as well. The line to pass the data to this function is…

In the function, if you pass a blank value as the system name, it will assume you mean the localhost. So what does it all look like together?

You can take this a step further by turning the function into an include file and calling that using an include statement when needed in other scripts. Pretty slick. I won’t go into details here. Let me know what you think. Next post we’ll check the current status of the service to see if it is Running, Stopped, etc.

Leave a Comment