Something that always seems to strike me as somewhat interesting is when I find colleagues, co-workers and fellow engineers not really thinking through the entire process of migrating from one SharePoint services based platform to another. I tend to cringe when I hear Microsoft salesman talk about the extensibility and the modularity of SharePoint 2007 and how easy it is as an administrator to do things, so much that you donât even need a systems administrator for regular maintenance, nor an architect or engineer to design things prior to deployment.
Low and behold thatâs where the Ghost swoops in and starts pointing out the deficiencies of a system prior to migration and why it will topple and post migration on a system not well suited for it. Thatâs also where the Ghost starts to build up fixes and implementation guides to be sure that the system does not fail so that thereâs no egg upon the face of those that will be assisting in deploying it to customers and clients.
Currently though I am working through a few migration struggles that all focus on SharePointâs security identifier (better known as a SID) and how itâs referenced by content that resides within your friendly neighborhood content database. The stsadm migrateuser operation is fairly handy in being able to move a user from Domain A to Domain B and reassign their identity within SharePointâs access control lists, however on a grand scale where youâre dealing with 10âs of 1000âs of site collections and web applications and users in an enterprise implementation, to say the least it can be quite daunting.
What Iâve found to be the best option is to mellow out and go Gray for a while and think things through, working out a migration strategy and methodology, while clearly communicating to customers, clients and stakeholders the risks and impacts that need to be defined so as to demonstrate the impact to the business operations. Typically a large whiteboard comes in handy as well as some unsweetened ice tea along with Jack Johnson playing in the background.
The largest problem that I have come to find is that when migrating a user from one domain to another using out of the box Active Directory tools such as LDIFDE if Iâm feeling lazy or the Active Directory Migration Tool that obviously I want to keep SID history – but wait, thatâs only for the Windows 2003 user object and not the SharePoint SID. SharePoint stores both the SID information and the login name (sAMAccountName) as a property identifying the user within SharePoint.
So what happens when the sAMAccountName changes or the userlogin? As Brian Regan would say, âHell on earth.â Okay, so itâs not that bad, rather the user just no longer has ownership of a particular file. So if a user resides in Domain A and has several hundred files spread across several web applications, whatâs the best methodology to migrate their content and the user to Domain B? I ask myself that constantly.
What I have come to find is that to be successful, all SharePoint data must be migrated to the new SharePoint instance within the new domain (domain B, which has a two way trust with domain A), and then the migration of users can begin. Otherwise, as a userâs content moves to the new domain and then the user moves in, a single operational modification needs to be performed to reassign privileges to the user. Else, there is a constant struggle of moving content, reassigning permissions on both instances until all of the userâs content has been moved.
Is there an easier way to do this in a short period of time in a highly distributed system? Not that I know ofâŚÂ It seems that you can either go the route of six in one hand or half dozen in the other.
The Tech Blog of Dan Usher 