1

On our SharePoint 2010 farm we have implemented managed accounts and these are configured to automatically change password each month. The issue we face is sometimes after the password is changed it is not properly propagated to all the services, for example application pools sometimes are using old passwords, and we only come to know about this issue when one of the application pools on Application server or web servers is stopped and is not able to start again, it could happen on the same day of password change or after weeks of password change, and when this happens we get all kinds of nasty errors like "Can't connect to database". And we can only make it work by resetting the identity of the application pool and providing it new password manually. Please note we have configured automatic recycling of application pools each night. I have few questions:

  1. Why password change is not propagated to all the services which use the managed account

  2. Why does not the recycling of application pool force application pool to use new password or how come it can go on with stale password for days even though we have recycling setting for each night

  3. How can we make sure that passwords are propagated to all the services How can we automate this process that we don't have to manually input new password

0

This is normal behavior with SharePoint 2010 farm, When we implement this in our Farm 4 years ago and had exactly same issue due to automatic change every 3 months. we found couple of reason.

  • we have couple of accounts, when it change password and proceed to 2nd account but timer job somehow stuck and did not completed their task.so password change not pushed to other servers.
  • if you see the monitoring > review job definition > on this page you will a lot of one time job for password change which never completed.
  • another strange thing, we noted it change password on the central admin server but did not push to others.
  • while SharePoint pushing the things, network disturbance can terminate this

After Bad experience, we change the that and now we changing the password manually and update SharePoint with it. But still it is not fool proof.here what we are doing.

  • change the password on AD, then update sharepoint with new password.
  • Now we perform IIS reset on all servers to make sure changes propagate on all servers.
  • from central admin > monitoring > review job definition> make sure no one time Timer job related to password exist here.
  • In some case we check the app pools on wfe to make sure they get the correct password( using appcmd tool).

Finally, i am hoping with new version of SharePoint 16, they will improve it.

  • Thanks for you detailed answer I have a question about the approach you are using for password change. While changing password manually why don't you use change password functionality from "Managed Accounts" in central administration. This way you could reduce a step of changing password in AD. I am asking to make sure there is no catch in that as well. – KayEye Feb 16 '16 at 20:28
  • Bad experience, we cant trust SharePoint on this, Timedout while changing the password....after that we decide to manual thing – Waqas Sarwar MVP Feb 16 '16 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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