Unleashing SC on Service Configuration

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

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.