Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 2 down vote favorite

Our team has recently configured a new server with a SharePoint 2010 installation and restored a backup of a site from hosted pool onto the new dedicated server. The timer service in central administration has been configured to use credentials for an account with database access, but periodically, some process is editing the configuration for the SharePoint 2010 Timer service in Windows Services and changing the password used to authenticate. The actual password has not in fact changed, so the service fails on startup (normally overnight). We have to reconfigure the stored credentials and restart the service every few days.

SharePoint is not configured to change the password for this account periodically, and we've gone into central administration's account management and updated the stored password for this account a few times now. What else could be responsible for these erroneous automated changes in the service configuration?

EDIT:

Some additional information that may or may not be of consequence. When attempting to manually change the service account password in Central Administration > Security > Configure Managed Accounts, I am receiving a permissions error. It is logged as follows:

System.ComponentModel.Win32Exception: Access is denied at Microsoft.SharePoint.Win32.SPNetApi32.NetUserChangePassword...

It does lead me to wonder if this why the service account is reconfigured with a new password, but since it does not have permissions to modify the actual account password, everything falls apart. I still need to find WHAT is responsible for that behavior however.

I did find this TechNet forum post regarding the issue but did not glean any information from the selected answer that would help me troubleshoot that issue.

In addition, a few other log entries on that correlation token may be of interest are below.

Under the Topology category:

The configuration database was queried for a non-existent object with the id 23363474-ec38-43bc-b069-cbfc9e5b0364. Most commonly, this is caused by removing an SPFeatureDefinition without writing upgrade code to remove references to the feature from each site.

Under the User Profiles category:

OnCredentialsChange: Profile Synchronization Service instance is not online yet: once online, please manually stop and restart the service if your password has changed.

share|improve this question
Just to check: account is member of local Admin group and you already read technet.microsoft.com/en-us/library/ff182790.aspx ? Is this 'auto-pass-reset' visible under CA > Manage Account > Account Information > Password update information? Did you try to really change account password and then set managed account to new password (some sort of password refresh)? – Vedran Rasol Apr 25 '12 at 20:39
@VedranRasol I've already checked the information at the technet article, but re-checked it again just now to be thorough. Regarding whether or not auto-pass-reset is visible, I can't follow your navigation tree to anywhere in Central Admin. I can tell you that automatic password reset is not actively configured for that account, as I mentioned. Regarding changing the password, I'm actually receiving an Access Denied alert when attempting to do so. – lthibodeaux Apr 27 '12 at 13:48

4 Answers

up vote 0 down vote
+100

If this account is also a Managed Account (check in SP-CA under Security - Managed Accounts) it is possible that someone has configured the automatic password change - NEW IN SP2010.

There is no way (that I know - but i'm not an expert) to find who changed a password in AD, but you can reduce to whom can change it and any way you need to turn on Auditing Account Management prior!

Hope it helps, C:\Marius

share|improve this answer
1  
In the OP, I state "SharePoint is not configured to change the password for this account periodically." I'm afraid this is not the resolution. – lthibodeaux Apr 23 '12 at 14:28
Is this account used by any other services in your network (or do you have by any chance multiple farms which use it) - it was my case as developers used the same Domain Accounts on their local Farms. You could start investigating by using the following to see when is changed (replace OU) Set objUser = GetObject("LDAP://CN=myServiceAccount,OU=Users,DC=Fabrikam,DC=com") Wscript.Echo "Password last changed: " & objUser.PasswordLastChanged – C. Marius Apr 25 '12 at 20:33
The account was specifically created when we set up the server (and named sp_db_user to indicate its purpose), and in general, there's very little work done on the client's domain. The farm environment is less a farm and more a dedicated web server for the client. It is not in use elsewhere. – lthibodeaux Apr 27 '12 at 13:57
You would need to register your account as Managed Account. Get someone with Domain Admin rights with you so it helps you change the password - FROM SharePoint - on the page where you configure the Managed Account. This will achieve 2 things: change password in AD and update TimerJOb. Plus - now being Managed Account - SP stores a hash of it -which could also explain why someone is attempting to change it for your Timer Job - that is SharePoint.! – C. Marius Apr 27 '12 at 23:36
The account is already a managed account. Please see the update above. It is not currently possible to initiate a password change from SharePoint given the current system configuration due to permissions restrictions. – lthibodeaux Apr 28 '12 at 0:11
show 6 more comments
up vote 0 down vote

The Timer Service runs under Farm Account which is also referred to as the database access account and is used as the application pool identity for Central Administration.

If AD DS and SharePoint Server 2010 account passwords are not synchronized, services in the SharePoint farm will not start.

It seems that the password for Farm account is updated in active directory and so your Timer Service fails to start. The option is to update the password for the managed account in Central Administration whenever the password is reset or Configure "Automatic Password Change" if you don't want to do it manually.

share|improve this answer
The converse is true. What is happening is that the password in Active Directory remains unchanged, but the configuration for the SharePoint Timer Service is updated by some automated process to reflect a new password that was never set. As a result, the service does not start automatically, and we are forced to go into the service configuration and change the password back to its original state to start the service. Once resetting the service configuration, the timer service starts normally. – lthibodeaux Apr 27 '12 at 14:00
up vote 0 down vote

It sounds like the password that is file with SharePoint 2010 is not synchronized with AD. I know that if you attempt to change the password manually for the Timer Servier in Service Configuration, the SharePoint 2010 will reset it back to its value. Therefore, I had to use Manage Services on a Server in CA to reset the password and match it to the AD. Have you attempted that already?

share|improve this answer
If you could elaborate on the process, I could test this. However, I do not see any options to update account passwords in this panel, including in any of the configurable services that utilize the account. – lthibodeaux Apr 27 '12 at 17:31
up vote 0 down vote

Does your account have log on as service rights to the machine? In some instances I have seen this being a reason for the account to fail. In most circumstances it is due to a global server policy being pushed out that overrides the log on as service accounts.

share|improve this answer
No, it does not. – lthibodeaux Apr 27 '12 at 17:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.