Using Service Recovery
Options to Diagnose and Resolve Service-Related Issues
Most of the services
that are installed by Windows Server 2003 run under the Local System
context; that is, the special Local System account controls when the
service should be started and stopped. However, additionally loaded
services (usually by Microsoft or third-party applications) run under
potentially different contexts. Often, when the service is being loaded,
the administrator is asked for specific credentials under which the
service is run. This way, instead of providing the service unobstructed
access to the system by means of the special System account, the service
is restricted to the context of the user the administrator provides.
Sometimes this account is a local user to the computer (say, a local
administrator account); other times, the account has even fewer
privileges. The level of access required depends on the requirements of
the application and the services it installs.
The best approach,
however, is to provide to the account only the least amount of access
that is required. For instance, if the service account could start with a
local user account, you should not necessarily make the account a local
administrator account simply because it is going to be used to control a
service. Consult your installation documentation for specific rights
required for each application you are planning to load.
Occasionally, after installing a new
application that installs new services, the new application’s services
might not start. You can see whether the service is started by
inspecting Computer Manager; however, diving into the System event log
yields much more productive information, as shown in Figure 3 and Figure 4.
Warning
In real life, you
would not actually change the logon account properties of the Telnet
service. This figure showing the Telnet service is provided only as an
example of what it looks like to change the account properties as if the
service were a third-party installed service. |
However, even the
information in the event log needs to be reconciled. Just knowing that
you have a logon failure is not enough. Indeed, there can be many
possible reasons why the failure has occurred:
The user name for
the account has been renamed, deleted, disabled, or is otherwise
invalid.
The
password for the account has expired and needs to be reset.
The account specified to run the
service has not been granted the Log On As A Service right.
To address any of
these problems, first, in the service itself, inspect the Log On tab, as
shown in Figure 5, to ensure that the account
information provided is correct based on the application’s
specifications.
After verifying the name
of the account and the password, you should additionally ensure that the
account has been granted the Log On As A Service right. If you are
using a domain account to run the service, you should inspect the
Default Domain Controller policy. To perform this task, from the Start
menu, point to Administrative Tools, and then click Domain Controller
Security Policy. In the left pane under the Local Policies node,
double-click User Rights Assignment, and in the right pane, select Log
On As A Service, as shown in Figure 6.
Ensure
that the domain account you want to use is specified in the Policy
Setting and attempt to restart the service.
If the account you want to
use is on a stand-alone machine running Windows Server 2003, run
Gpedit.msc. Then expand Local Computer Policy, Computer Configuration,
Windows Settings, Security Settings, Local Policies, and finally, select
User Rights Assignment. Locate the Log On As A Service right and ensure
that the account you want to use is listed.
Windows Server 2003 has
many options about what it can do if a service fails to start because of
any of the reasons described previously. If a service fails, events are
logged to the server where the service is loaded. However, you can
choose to take a more proactive approach to service management.
If you select the
Recovery tab of the service, a myriad of options allow you to specify
behavior if a service fails, as shown in Figure 7.
If
a service fails, you have four choices:
Take No Action
Restart The Service
Run A
Program
Restart The Computer
A single service failure
might be an anomaly. That is, the service could have failed to load
initially because another service it depended on had not yet been
started. This situation could occur for a number of reasons, including
temporary slow disk access, or another service needing to finish writing
to a log file before being fully started. Hence, because that other
service was not fully started, this service could have requested to
start, recognized that a service it depended on was not started, and
simply missed the opportunity to start. Therefore, on the first failure,
you are advised to restart the service.
However, if the service
fails multiple times, you could try to restart it again, run a program
to let you know that the service has not started, or restart the
computer to see whether the timing dependency has disappeared.
