Should you turn on any services that don't run by default? The answer depends on your situation. For example, you might want to enable the Indexing service, but this service slows server performance every time it indexes the server's content. If you need fax capability or RRAS functionality, you should turn on those services. Table 4, page 42, lists useful system services that you might want to enable.
When tuning your system's services, perform a full backup before you significantly alter your server's configuration and to log configuration changes. Backups and logs are your primary vehicles for troubleshooting problems if a configuration change results in a broken application or performance degradation.
Security Tune-Up
Disabling security-related services on any server—but especially on a DC—sacrifices the system's protection and endangers your network environment. However, you can tune service settings to ease systems management.
In Part 1, I discussed how to create service accounts for applications and services. These accounts control the security context under which the applications and services run, help you control the access rights and interactivity of multiple related services, and secure the system's core management and application functions.
Using Win2K's native security object model, you can control access to individual server properties and actions. So, for example, you can control which services your Help desk technicians can access, what actions they can take, and even what management information they can view. By setting ACLs on individual services, you can delegate control and access rights to those services. Alternatively, you can use Microsoft BackOffice Server 2000 to determine, through logon credentials and locked-down Microsoft Management Console (MMC) files, what a technician has permission to do. For example, you can customize a context menu to display only Start Service (and not Stop). The Microsoft Windows 2000 Resource Kit Service ACL Editor tool also lets you administer services at a granular level. (For a complete list of related resource kit tools, see Part 1.)
You can set logon credentials for services, enter passwords, and set interaction with the desktop through the Log On tab of a service's Properties window. Through the logon account, you can determine which rights a service or application will have on your server. Thus, for services that are potential security risks, you can limit access to server resources. You can create a unique user account and manually assign the account to the groups that contain the permissions necessary to work with that service. When you do so, create the user account in the Local User and Groups container. (If your system is a DC, create a unique domain account rather than a local or system account.) Make sure that you limit the account's functional scope as much as possible (e.g., provide limited logon rights and no general server access unless the service requires it). Setting up service-management accounts that have different names and strong passwords will make cracking your network more difficult.
However, creating a multitude of service accounts can result in a hassle when you must change accounts' passwords (according to your company's password policies). One option is to set these accounts' passwords to never expire. This setting protects you from finding yourself with a dead server if a password times out and prevents the associated service from logging on and running. But this setting is also a security risk. Rather than create many accounts with passwords that don't expire, you can create a few, nonprivileged service accounts and develop a process for changing their passwords as needed.
Desktop interaction for a service means that the service can bring itself up in the Windows desktop environment for input by anyone logged on to the system. Selecting the Allow service to interact with desktop check box in the service's Properties window exposes the service's UI so that users can change the service's settings. Leaving this check box clear prevents logged-on users from interfering with the service. This configuration option is available only when a service is running under the Local System account. Usually, you wouldn't change the interaction settings of common Windows components and services because doing so could have detrimental effects on your server's operation. However, in a development environment or if you're running an application as a service, permitting desktop interaction might be necessary to control a service or to provide user-input settings.
What if you mess up? You mistakenly set the Server service to log on under a user account with an expired password. Now, you find that you can't log on to your system. Don't panic. Reboot the server into Safe Mode, which is a minimal service and driver configuration. Through one of the various Safe Mode startup options, you can get back into Windows and fix your error.
Tune Up or Tune Out
You've learned your way around services' administration tools and interfaces, and now you know how to apply that knowledge through enabling and disabling services and tweaking services' security-related settings. You can use these articles as a Win2K services primer to ease service management, and you can consult Windows Help and the resource kit documentation for more information about tuning your system's services.