Thursday, July 25, 2013

Manually Updating Passwords in SharePoint

I had the pleasure recently of being tasked with updating application pool and other service accounts in a mixed version, multiple SharePoint farm SharePoint environment.  Since this is routinely performed annually, I was disappointed to learn that there was very little documentation and truly no telling exactly where each of these accounts may have been used throughout the farms.  Since these environments were in production, it was very important that we took our time and tested functionality each step of the way.  Previously we had an issue where we issued a command to force a single password change through SharePoint, but it automatically changed every single farm password causing a mismatch between what SharePoint had as a password verses what it was actually set as in Active Directory.  This was a disaster!  We had to manually update the passwords in SharePoint using powershell.  Needless to say, we disabled all managed accounts from automatically changing the password.

So we started with the obvious, managed accounts.  Each account had to be simultaneously changed in Active Directory and then updated in SharePoint.  Once we completed the the managed accounts, we restarted the services to make sure they were working properly, and checked each server to make sure they replicated properly.  Below I've listed a few lessons learned and perhaps even some ideas for proactive approaches that you can take now to make the next password update process much more pleasant with a proven and predictable outcome. 

These are in no particular order:

  1. Make sure the timer service is started on all servers in the farm.  This will insure that the passwords are replicated from the managed accounts section in Central Administration to the services/applications across the farm.
  2. If possible, do your password changes off hours.  Although hearing user complaints about something not working right would be an excellent indication that a change was not applied properly, it's best practice to reduce the impact as much as possible on your user population.
  3. Take one step at a time.  Change the password in Active Directory, then change it in SharePoint, then test completly.  Only once you are positive the change was successful should you move to the next.
  4. If you do not already have a SharePoint list of all the service accounts you have in your farm and where they are used, this is the perfect time to start one. It will save a ton of research time before your next password change and allow for the process to be shared by multiple teams.  I use a custom list with columns such as: service account name; account type; app pool or application service, details, last password change, etc.  I also recommend using a program like KeyPass or PasswordSafe to keep track of current account passwords and pass phrases.
  5. Sometimes you have to manually change the password on the application pool itself in IIS Manager. Also be sure to update secure store service IDs.  This is where your list will pay off big time because once you go through this process once, you will know exactly where those accounts are being used so you can update all instances.
Having written proceedure and clearly documented details not only saves you time and effort the next time you need to manually change passwords, but it's also artifacts that can be passed down to newer team members as staff or responsibility changes.

No comments:

Post a Comment