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.
0 replies on “Developing Migration Methodologies”
i hope you would be aware of the fact that with the new stsadm -o migrate user tool, you can migrate your users to the new domain in sharepoint.
I’m aware of the stsadm -o migrateuser command and the ability to move a user’s permissions from domain A to domain B as mentioned above, however this becomes daunting when you’re doing a piecemeal migration of site collections from an Enterprise SharePoint system in domain A to an Enterprise SharePoint system in domain B, continuously having to repermission the user’s data on both sides so that they have to maintain ownership. This unfortunately isn’t really solved by the migrateuser command as that’s a one time migration – new data requires that it be re-run.
What you could do I suppose is to write a script that enumerates all users that are on a site and then map that to the new domain when the site is moved, but it still is something that has to be considered so that a user maintains owernship throughout the process.
Here’s one for ya: What about moving 10000+ AD accounts used for a WSS 2.0 site into an ASPNET SQL Server user store for use with a Membership Provider for MOSS?
So if it were me, I would do an LDIFDE of the AD – specifically the OUs with user information. I would then take that and import it into SQL Server using a little data parsing to clean things up. From there I would hope and pray that stsadm -o migrateuser would be able to migrate the permissions from the AD authentication provider to the SQL server authentication provider. If so I would batch script the entire thing and go listen to some Jack Johnson.