In my time working with SharePoint 2010 I have been often amazed at the thought that went into making the product as seamless and clean as possible.  It was as though Microsoft listened to all of our gripes and grimaces and attacked them all with a  passion to make SharePoint 2010 the best product they ever released.  And then there is the User Profiles.

Some of my favorite enhanced features of SharePoint 2010:

1.) Scheduled Automated Password Resets – We spent months getting this right in SharePoint 2007 because our environment was so complex, and then we still had problems from time to time where things just didn’t get set cleanly

2.) No multi-try service starts – In all other versions of Microsoft products that I have worked with we always had multiple fail times before allowing you back to a stopped state, and some services would just hang in a starting state forever until you rebooted.

3.) Implementation of the principle of least privilege for service accounts running services – You can specify a specific managed accounts to run services in order to manage permissions required to execute with the least privilege required to do the job

4.) Windows Service naming convention – Most of the SharePoint specific services have SharePoint in the name (simple right?)

5.) No elevated Active Directory Permissions required to run SharePoint

How did the FIM (Forefront Identity Management) team who implemented the User Profiles section of SharePoint 2010 break each of these enhancements?  Let’s take a look:

1.) Scheduled Automated Password Resets –

The User Profile Synchronization Service MUST run as the farm admin account.  There is no way to successfully change this.  I have tried and it has been a miserable failure.

Unfortunately, the way that they implemented the UPS Service is that it requires that the password be entered upon startup.  It does not respect Managed Accounts.  This means that you cannot use the automatic password reset capability built into Managed Accounts for your farm admin account.  You must set the password to something known so that you can enter it in for the UPS to start up.  I haven’t figured out a programmatic way around this yet, but I am on the look out and will post something if I find it.

The best part is that outside of Spencer Harbar’s Bible for UPS, Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization, (which is an absolute must read for anyone who is setting up a SharePoint 2010 farm and wants a chance in hades of getting UPS working) there is NO PLACE that comes right out and tells you this information.  I am probably going to post a separate article on this just so that we start to get it out there for people to easily find.  The #1 account you would expect to use the automated password changing functionality for, and the FIM team breaks your ability to use it right out of the gate.  Hopefully this is going to be addressed in a service pack or an R2 version of the product because it is a thorn in an administrator’s side.

2.) No multi-try service starts –

Once you start the UPS Service it is time to go get a cup of coffee, read the paper, finish the cup of coffee and then go for a 5 mile run.  That is unless you are like me and feed the ULS Logs and the Event Viewer hoping not to see one of those awful ERR errors that don’t flag as errors in ULS and don’t show up in the Event Viewer.  If you are lucky enough to get the UPS Service to provision cleanly the first time out of the gate (you can thank your lucky stars, or Spencer, dealer’s choice), but if you are like most of us, it is going to take a couple of tries to get it right because you are either cutting corners, trying to be smarter than SharePoint, or just don’t follow directions well.

The bottom line is that the UPS Service tries (in my experience) no less than 10 times before it finally fails out and goes back to stopped, if it gets back to stopped.  The more fun version of this story is when you end up in a starting state for a week or so.  Then you want to rip what little hair you have left our of your head…  but maybe that is just me.  I have a good post on how to deal with that situation coming next week.

3.) Implementation of the principle of least privilege for service accounts running services –

This goes back to the farm account running the UPS Service.  So much for least privilege…

4.) Windows Service naming convention –

The 2 services that run the UPS Service inside of SharePoint are listed in the Windows Services as “Forefront Identity Manager Service” and “Forefront Identity Manager Synchronization Service”.

5.) No elevated Active Directory Permissions required to run SharePoint –

In order to perform a User Profile Sync you must give the account performing the action the “Replicating Directory Changes” permissions in Active Directory.

I have yet to find a detailed exact explanation of what this permission has rights to do, but based on my testing it appears to be just an elevated permission to allow a deeper level of read.  I have not tested to see if it can read from hidden confidential flags yet (an AD schema extension is required that I don’t have in any of my accessible ADs yet), but that will come in the next week or so.  The Microsoft TechNet article was just updated to include the details on this in September and can be found at http://technet.microsoft.com/en-us/library/ee721049.aspx (nice credit at the bottom to Spencer here…  nice to see that we are all listenting to the same guy that Microsoft is listening to)

Hopefully this helps to shed some light for you, gentle readers, on some areas of SharePoint that have certainly been tripping points for me and many of my colleagues.  I still love the product and advocate for it passionately, I just tend to leave out the part about what a pain in the @$$ UPS is.