| A few days ago on Twitter there was a discussion about yet another thing that breaks SharePoint 2010’s User Profile Service, backing up SharePoint. This is particularly frustrating because backups are so important. In this blog post I’ll explain why this happens, and some ways to work around it.
SharePoint first introduced built in Farm backups in the 2007 version of the product. You could fire one off in Central Admin under Operations, or with STSADM. It worked okay, though it wasn’t a great solution for large environments. One weird little side effect we discovered after a while was that if you ran a farm backup, it paused any search crawls that were going on. Turns out that the SharePoint Farm backup likes to keep things in a consistent state, so it would pause as much as it could when it started so that everything was in a consistent state. Since Search has so many moving parts (like the Index files and the Property database) it paused everything to make sure it backed them up just right. Its heart was in the right place, and it worked pretty well. It was just a bit unnerving when we saw our Crawls stopped unexpectedly. Then along came SharePoint 2010 and the much maligned User Profile Service Application…
The farm backup in SharePoint 2010 behaves very similarly to the one in SharePoint 2007. It still pauses the things it can to get you the very best backup it can muster. It has a new service to deal with in SharePoint 2010, the User Profile Service Application (UPA) (dun dun duuuuuuuuuun). Much like Search, the UPA has a lot of moving parts, including three databases (Profile, Social and Sync) and two service instances (User Profile Service (UP) and User Profile Sync Service (UPS)). In its quest to get you a good farm backup, SharePoint tries to pause it too during the backup. Unfortunately the UPS doesn’t pause, so the backup process actually un-provisions the UPS during the backup, undoing all your hard effort getting the damned thing to work in the first place. When the backup is finished it tries to put everything back together and it reprovisions the UPS. Now, what do we know about provisioning the UPS, besides the fact that it burns one of your three wishes from a genie, and it takes one of your cat’s nine lives each time you do it? We know that the Farm account must be a local admin when it’s provisioned. We also know that if the UPS and Central Admin are running on the same box (and they often are) that you need to do an IISRESET after it’s provisioned. Unfortunately most of us don’t leave our Farm account in the local admin group as a general rule, so the reprovisioning fails. The symptom of this is that profile syncs no longer run, and the two FIM services on the box running the UPS are set to “disabled.” Let’s say though you’re the planning ahead type of person and you leave the Farm account as a local admin. Your UPS will probably reprovision, but you won’t have the necessary IISRESET afterwards.
What’s the moral of this story? Well, if the UPS just seems to unravel itself from time to time it might be because you’re doing a SharePoint aware backup. The Farm backups in Central Admin will do this, as will some 3rd party products. If you’re going to try to schedule Farm backups in order for them to be successful you will probably need to leave your Farm account as a local admin on the box running the UPS and you’ll need to schedule an IISRESET afterwards. You could probably just put that in the same script as your backup.  You could also fall back to just doing database backups in SQL of your SharePoint databases. That’ll address 90% of your recovery needs.
Hope that helps. Next week I’ll solve the mystery of how they stick Teflon to a pan, when nothing sticks to Teflon.
tk |