So, the big question now is probably: How can all this information be used to help resolve problems or configure a server? Well, in a nutshell, it works like this. If you are troubleshooting a service or device problem, you can start with the Event Viewer and the system event log. Usually, if the service or device has any dependencies, you should find a message in the system event log informing you of the problem and the cause (the service or device that failed to start). If your WINS service fails to start, for example, it might have failed because the TCP/IP protocol driver failed to load. Which, in turn, might happen because your network adapter driver failed to load properly. Which usually means, the network adapter has a hardware failure, is misconfigured (wrong I/O address, DMA channel, memory address, or interrupt), or is not physically connected to your network. The idea behind all this is to find the root cause of an error (the network adapter, in our example) and fix it. Then, after you reboot, the problem should be solved.

Only if you have no messages in the event log will you have to start your search of the registry looking at the DependsOnGroup or DependsOnService key to find the dependencies of the service or device. You will probably have to follow a series of dependencies before you find the root dependency. This is why you should look in the event logs first. As you search through the dependencies, you might find that the service or device has been disabled, or that someone has changed the load order (Type and Start values). If the startup type or load order has been changed, you can correct the problem and reboot. Hopefully, that will resolve the issue.

You can also use the information presented in this chapter to find out more about your system and gain a fuller understanding of what will happen when you shut down a service. As an example, you might decide to shut down the Server service to back up your disk drive. But, as Table 12.3 shows, the Browser and Replicator service depends on the Server service (this is the display name for the service; the actual service name is LanmanServer), which means both of these services would be shut down as well. This could prevent users from browsing the network (if you only have one domain controller) and would prevent user logon scripts, roaming profiles, or other file replications from occurring. By understanding a service’s dependencies, you can make more prudent choices as to when to schedule a specific batch file operation

Summary

In this chapter, you learned how to manage your services and devices using the provided GUI and command-line interfaces. You also learned a bit about how to write batch files to automate your service management needs. Hopefully, this information will help as you develop your skills as a system administrator. If you have to troubleshoot a service or device, the skills you learned concerning how to find service or device dependencies should provide you with a firmer grasp of how services and devices interrelate with each other and what to do if one fails.