I was pinged on a question today about Sharepoint, an app I have never had to deal with. Well the question was how to easily resync Sharepoint after a user object changes… for instance, email, displayname, domain, or userid… I was like what? Why would it need to do that if it is all in the same forest? That is why GUIDs don’t change, so you can constantly be linked to specific objects.
Well it seems that if you have any of those changes and you are using Sharepoint, you get to build an XML file and then run a command line tool to update the Sharepoint data. If anyone who does dev for Sharepoint is reading this… WTF people? Your company builds a directory that allows for easy changing of most aspects of a user including moving between domains and changing userids and you hard code this? I expect that silliness out of uninformed vendors, not MSFT.
I visualize customers have three options off the top of my head…
First you can insert yourself into the provisioning process and when there is one of those changes, you generate the proper Sharepoint updates and process them. That way you have all of the info so you can set up the update file. This only works if ALL changes ALWAYS go through provisioning. I think the number of environments that can adhere to this are far outweighed by the ones that can’t.
Second you add some attributes to AD to track old and new versions and what Sharepoint currently has registered for domain\userid and occasionally run something to make sure you are all synced up.
Third you build a whole other store to keep all of the information and when you detect changes you update Sharepoint and the extra store.
How are people handling this out there?
ping me and i’ll try and explain. sharepoint has several mechanisms and issues here and they’re fun to sort out in big deployments.