Ready to finish our look at SC (sc.exe), the command-line tool that offers wide-reaching control over services? In previous columns, I've demonstrated how SC lets you start and stop services, create new ones, delete existing ones, and control dependencies between services. But that's not all you can do with services. For example, I often find myself changing a service's startup status—whether it starts automatically or manually, whether it's disabled, and so on. You can control startup status, and much more, by using the SC Config command.
How It Works
The SC Config command largely mirrors the SC Create command, which I've covered before. Its overall syntax looks like
sc config <servicekeyname> <option= value>
Here's an example that will illustrate this command's usefulness: Ever since Windows Server 2003 Service Pack 1 (SP1) and Windows XP SP2 disabled the Messenger service, I've gotten pretty regular email from people who say they need it. (Some folks really like the Net Send command.) To configure the Messenger service to automatically start every time you boot your computer, you could type
sc config messenger option= auto
(Recall that SC has the syntactic quirk of requiring a space between the equals sign and the option's value.) The other possible values are boot, system, demand (i.e., manual), and disabled.
By the way, Windows Vista systems have yet another possible value—delayed-auto—that reflects Vista's new delayed start option. The notion of delayed-start services reflects Microsoft's observation that many auto-start services need to start automatically but don't necessarily have to start immediately. Microsoft wanted Vista to get started up and ready to go as quickly as possible, and part of the reason why the XP and Windows 2000 desktop OSs boot slowly is because they're waiting for those auto-start services that always start immediately.
Other useful options for the SC Config command are password, error, depend, and perhaps obj. You're already familiar with the obj and password options. A couple months ago, I showed you how to use them for creating a new service: obj= lets you configure which account to run a service under with SC Config just as the obj= parameter lets you specify the service account in SC Create. You probably won't change service accounts very often, but you might end up changing those accounts' passwords, and for that task, you can use the password= option. If a service with a key name of myservice has a service account whose password has changed to swordfish, you can inform Windows as follows:
sc config myservice password= swordfish
You can use the error= option to control Windows' behavior when a service fails. Remember, while creating a new Windows service, you can tell Windows to respond to a service failure in one of four ways: ignore, which merely notes the failure in the event log; normal, which acknowledges the failure with a message but lets operations continue; severe, which reboots the system with Last Known Good and tries again; or critical, which reboots the system, retries the service, and—if it still fails to run—bluescreens the system. I can tell Windows that if myservice doesn't run, Windows doesn't run (clearly a measure to use sparingly), as follows:
sc config myservice error= critical
We're not quite done with SC Config—there's one more oddity to look at. Over the course of the past three columns, I've shown you that whenever SC lets you specify more than one option/value pair for a command, you separate those option/value pairs with forward slashes. I demonstrated the technique last month with the depend= option, and you can also observe it if you look up the syntax of Vista's SC command. By contrast, with SC Config, you specify more than one option by merely separating them with spaces. (Granted, this behavior might be considered standard in the scripting world; it just seems odd in the context of SC's other syntax.) For example, to combine those last two commands into one, I could type
sc config myservice password= swordfish error= critical
Consider the Possibilities
Need to control a service from the command line because you want to use a batch file? Want to use a low-bandwidth textual interface for remotely configuring a system? Perhaps you're just getting up to speed with the command line so that you can control the upcoming command-line-only Server Core product. Whatever your scenario, you'll find SC a useful tool.