Problem
I had completed an installation of SharePoint Server 2007 Standard onto Windows Server 2003 R2 Enterprise. Domain accounts had been created and configured for the various SharePoint services, as recommended [1]. Both SP1 and 2 had been installed. No issues. No problems. The next day, I check the Windows Server event logs and found the system event log filled with the following errors that repeated with distressing frequency:
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7041
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The SPsearch service was unable to log on as .\[account name] with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.
Service: SPSearch
Domain and account: .\[account name]
This service account does not have the necessary user right "Log on as a service."
User Action
Assign "Log on as a service" to the service account on this computer. You can use Local Security Settings (Secpol.msc) to do this. If this computer is a node i a cluster, check that this user right is assigned to the cluster service account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be removed, a Group Policy object associated with this node might be removing the right. Check with your domain administrator to find out if this is happening.
For more information..
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7000
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The Windows SharePoint Services Search service failed to start due to the following error:
The service did not start due to a logon failure.
For more information...
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7041
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The SPTimer service was unable to log on as .\[account name] with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.
Service: SPTimerV3
Domain and account: .\[account name]
User Action
Assign "Log on as a service" to the service account on this computer. You can use Local Security Settings (Secpol.msc) to do this. If this computer is a node i a cluster, check that this user right is assigned to the cluster service account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be removed, a Group Policy object associated with this node might be removing the right. Check with your domain administrator to find out if this is happening.
For more information...
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7000
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The Windows SharePoint Services Timer service failed to start due to the following error:
The service did not start due to a logon failure.
For more information...
Discussion
The answer to quickly and effectively resolving both these service errors, the Timer and Search services, lies in the User Action statements for both. I wish I had grasped this at the outset.
I encountered these errors early in my SharePoint Server career and was unfamiliar with such things as GPO. Though I had good SharePoint knowledge from a user perspective, I didn't have much systems integration experience - understanding the intersection of SharePoint with its operating system. Thus, I did not initially grasp the significance of the User Action statement. Had I done so, I would have avoided several weeks of troubleshooting effort. Another difficulty involved the rather transient longevity of the network administrative staff, that I was working with at the time, staying with us for little more than a few months before moving on to other positions.
Over the course of intense troubleshooting, continuously consulting with system admin staff, I finally noticed that this flood of errors was triggered after the broadcast of a new GPO, which on our systems occurred around 3 AM daily. I didn't fully understand what a GPO was, but I could see that it was adversely impacting my carefully installed and configured SharePoint configuration, since the occurence of a new GPO event coincided with the advent of these errors. But why a GPO event in turn caused the 7000 and 7041 errors was beyond me. Finally, a savvy sys admin person, when I showed him the errors, quickly understood what was occuring: everytime the GPO was pushed out to the servers, it was overwriting the local configuration, and this caused the service accounts in question to no longer be able to logon locally. This sys admin fixed the problem in a few moments. After he explaned it, it made sense to me.
In just a few minutes, he added the "Log on as a service" right to the accounts in the GPO. The next day, I checked the system event log and: no more errors (at least this type, anyway). Voila. Problem solved. At least this one.
Lessons Learned
This experience taught me the importance of gaining cross-cutting experience, of gaining experience not just in SharePoint but also in the applications that intersect with SharePoint and most certainly in the operating system hosting the application. It also illustrated the importance of productively working with savvy system administrators and the impact they have on your operations. Happy computing!
References
I had completed an installation of SharePoint Server 2007 Standard onto Windows Server 2003 R2 Enterprise. Domain accounts had been created and configured for the various SharePoint services, as recommended [1]. Both SP1 and 2 had been installed. No issues. No problems. The next day, I check the Windows Server event logs and found the system event log filled with the following errors that repeated with distressing frequency:
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7041
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The SPsearch service was unable to log on as .\[account name] with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.
Service: SPSearch
Domain and account: .\[account name]
This service account does not have the necessary user right "Log on as a service."
User Action
Assign "Log on as a service" to the service account on this computer. You can use Local Security Settings (Secpol.msc) to do this. If this computer is a node i a cluster, check that this user right is assigned to the cluster service account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be removed, a Group Policy object associated with this node might be removing the right. Check with your domain administrator to find out if this is happening.
For more information..
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7000
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The Windows SharePoint Services Search service failed to start due to the following error:
The service did not start due to a logon failure.
For more information...
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7041
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The SPTimer service was unable to log on as .\[account name] with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.
Service: SPTimerV3
Domain and account: .\[account name]
User Action
Assign "Log on as a service" to the service account on this computer. You can use Local Security Settings (Secpol.msc) to do this. If this computer is a node i a cluster, check that this user right is assigned to the cluster service account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be removed, a Group Policy object associated with this node might be removing the right. Check with your domain administrator to find out if this is happening.
For more information...
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7000
Date: 6/17/2010
Time: 1:50:45 PM
User: N/A
Computer: [servername]
Description:
The Windows SharePoint Services Timer service failed to start due to the following error:
The service did not start due to a logon failure.
For more information...
Discussion
The answer to quickly and effectively resolving both these service errors, the Timer and Search services, lies in the User Action statements for both. I wish I had grasped this at the outset.
I encountered these errors early in my SharePoint Server career and was unfamiliar with such things as GPO. Though I had good SharePoint knowledge from a user perspective, I didn't have much systems integration experience - understanding the intersection of SharePoint with its operating system. Thus, I did not initially grasp the significance of the User Action statement. Had I done so, I would have avoided several weeks of troubleshooting effort. Another difficulty involved the rather transient longevity of the network administrative staff, that I was working with at the time, staying with us for little more than a few months before moving on to other positions.
Over the course of intense troubleshooting, continuously consulting with system admin staff, I finally noticed that this flood of errors was triggered after the broadcast of a new GPO, which on our systems occurred around 3 AM daily. I didn't fully understand what a GPO was, but I could see that it was adversely impacting my carefully installed and configured SharePoint configuration, since the occurence of a new GPO event coincided with the advent of these errors. But why a GPO event in turn caused the 7000 and 7041 errors was beyond me. Finally, a savvy sys admin person, when I showed him the errors, quickly understood what was occuring: everytime the GPO was pushed out to the servers, it was overwriting the local configuration, and this caused the service accounts in question to no longer be able to logon locally. This sys admin fixed the problem in a few moments. After he explaned it, it made sense to me.
In just a few minutes, he added the "Log on as a service" right to the accounts in the GPO. The next day, I checked the system event log and: no more errors (at least this type, anyway). Voila. Problem solved. At least this one.
Lessons Learned
This experience taught me the importance of gaining cross-cutting experience, of gaining experience not just in SharePoint but also in the applications that intersect with SharePoint and most certainly in the operating system hosting the application. It also illustrated the importance of productively working with savvy system administrators and the impact they have on your operations. Happy computing!
References
- Plan for administrative and service accounts (Office SharePoint Server) - Microsoft TechNet | SharePoint Server 2007
- Add the Log on as a service right to an account - TechNet | Windows Server 2003 | Manage an ADAM Instance
- EventID.NET
- None
No comments:
Post a Comment