SideBar    Simple Troubleshooting Tools

Problem: Windows Services Don't Start
You notice that when you restart a Windows 2000 Server machine, services that aren't set to start with the Local System Account fail to start. You must manually open the service, reenter the password, and start the service. Each time you reenter the password, you receive the message <username> granted the logon as service right.

To troubleshoot this problem, start by asking the following questions:

  • What has changed? Did anyone make any changes on this server?
  • Did the services start in the past?
  • Are the username and password valid?

You investigate and discover that the server, a DC, was until recently a member of the Domain Controllers organizational unit (OU). The services started properly until the server was moved out of that OU. The username and password you used to start the services are valid. Upon further research, you discover that members of the Domain Controllers OU have specific rights, among them the right to log on as a service. The server lost this right when it moved out of the OU; you need to restore the right to the server.

To grant the right to the server, take the following steps:

  1. Start the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, then open the Domain Controllers OU's Properties dialog box.
  2. On the Group Policy tab, click Default Domain Controllers Policy, then click Edit. This step starts Group Policy Manager.
  3. Expand the Computer Configuration object, expand Windows Settings, then expand Security Settings. Expand Local Policies, then click User Rights Assignment.
  4. In the right-hand pane, right-click Log on as a service, then click Security.
  5. Add the user account used to start up the service to the policy, then click OK.

For more information about this procedure, see the Microsoft article "How to Troubleshoot Service Startup Problems" (http://support.microsoft.com/?kbid=259733).

Prev. page     1 [2] 3     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Alan Sugano's "Network Troubleshooting Basics" (June 2003, http://www.winnetmag.com, InstantDoc ID 38938) was very informative. I wholeheartedly agree with him about the "right" way to tackle networking problems. One of the examples confused me, though. In "Problem: Windows Services Don't Start," the author mentions that someone removed a server—a domain controller (DC)—from the Domain Controllers organizational unit (OU), and afterward a certain service failed to start. First question: What are valid reasons to remove a DC from the Domain Controllers OU? The service was configured to start under a certain user account that was different from the Local System account. Second question: Why didn't the author propose setting the Local System account for this service? By moving the server out of the OU, the server—which is the Local System account, if I'm right—lost the right to log on as a service. But the service didn't run under the Local System account, so why does this loss of rights influence the ability of the service to run? Other services ran under this Local System account, but the author doesn't mention that they failed. The author then explains that the solution to the problem is to edit a GPO, which is exclusively (I think) applied to members of the Domain Controllers OU. Because the server was recently moved out of that OU, I can't see how editing the GPO can solve the problem.<P> The client I wrote about in this article had a very large network and many OUs. They wanted to place this particular server in a different OU to make it "easier" to find. This approach was just a matter of style. The service that failed to start was VERITAS Software's VERITAS Backup Exec. Backup Exec must start with a valid user account, so that's the reason they couldn't use the Local System account. With the Exchange add-in for Backup Exec, you must have a unique mailbox account start the Backup Exec services in order to perform a mailbox backup. And yes, you should edit the GPO for the particular OU to which the server was moved, not the Domain Controllers OU. In this specific scenario, services that start under the Local System account are not affected by a change in the OU. For more information about service startup, see the Microsoft article "How to Troubleshoot Service Startup Permissions" (http://support.microsoft.com/? kbid=259733). <BR> --Alan Sugano

Jacques Willemen

 
 

ADS BY GOOGLE