In my previous article, I described how to troubleshoot Windows service failures. I will now dig a little deeper and explain how to resolve a Windows dependency problem. Remember, services may have dependant services -- a list of services that must start before another given service will begin.
I recently worked on an issue where the Exchange System Attendant (SA) service would not start automatically during boot, but it would when started manually. While the example here involves the Exchange SA service, the troubleshooting principle is the same for any service with dependencies.
Figure 1 shows the dependant services for Exchange SA. This problem is a classic case of a dependant service not starting as expected, so the Exchange SA service couldn't start. This is typically just a timing issue and means that the dependant services are not starting in time to start the Exchange SA service. But, by the time the user logs on, all dependencies are started, so Exchange SA can begin.
Figure 1
The resolution to this problem is really simple, though it might seem a little like cheating. Since the dependant services need more time, I suppose we could try to figure out why they aren't starting as expected -- but that may not be successful. The easy, dependable way to fix this is to simply find a service that is one of the last to start during boot, then add that service to the Exchange System Attendant service dependency list. This will force the Exchange SA service to wait longer, giving the real dependant services time to start.
Note: Find more details on this procedure in the Microsoft TechNet article on automatically starting Windows services.
Step 1
To find a late starting service, go to the Exchange 2003 server, and use Regedit to open the registry. Browse to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ServiceGroupOrder. In the right pane you will see a value called LIST, as shown in Figure 2.
Figure 2 (Click to enlarge)
Open that value to see a list of service groups in the order that they start on startup of the server. Note the last service listed. In the example in Figure 3, the MS Transactions service group is the last to start.
Figure 3 (Click to enlarge)
Step 2
Use the registry editor's FIND command (Edit menu /Find) and search on the service group shown in Step 1. In this case, we are searching for MS Transactions. We want to find which service listed MS Transactions is in the "group" key. As seen in Figure 4, this was the MSDTC service. You would do the same thing -- i.e., search for the last service group name found in Step 1 and locate the service that corresponds to that group.
Figure 4 (Click to enlarge)
Step 3
Now we want to make the Microsoft Exchange SA service dependant on this service. In this example we want to add the MSDTC service to the dependency list for the MSExchangeSA service. There are two ways to do this:
- Edit Registry value "DependOnService" under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA and include "MSDTC" as a service dependency, as shown in Figure 4.
OR
- Edit registry value "DependOnGroup" under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA to include "MS Transactions" as a group dependency, as shown in Figure 5.
Figure 5 (Click to enlarge)
Either one of these actions ensures that the MSExchangeSA service waits for MSDTC to be active before it starts the System Attendant.
Note: Use of MSDTC is not specifically required, it is just the particular service group that was last in the "List" value under ServiceGroupOrder on my Exchange server. Note that I checked three Exchange servers and MSDTC was the last service in the service group on all of them. The important thing is to use the last service listed in the ServiceGroup value in the registry, as described in Step 1.
With the SA service configured to start only after the last service in the registry's ServiceGroup value, it should only start after all other services have started. This procedure indeed solved the problem of the ExchangeSA service not starting on boot. Note that if you do this and the service still doesn't start, then at least you know it isn't a dependency issue. In most cases, though, it should resolve the problem. In addition, it will not hurt the action or performance of the Exchange SA service.
