MigrateUserAccount and MigrateAccount, the new methods that came with SPS SP2.
The Service Pack 2 (SP2) release of Microsoft Office SharePoint Portal Server 2003 contains two new methods that allows to make necessary changes in WSS and SPS databases in case you want migrate the access rights from one account to another or transfer the user’s account into an another domain.
In WSS the MigrateUserAccount method is a member of existing SPGlobalAdmin class.
In SPS the MigrateAccount method is a member of the new PortalAccountMigrationManager that created specially for this method .
Here are the references:
There are couple of things you have to take into account if you want to use the methods:
- For WSS you just use MigrateUserAccount method, for SPS you use MigrateAccount method but Microsoft says that “Windows SharePoint Services settings should be updated first by way of its MigrateUserAccount method. It is recommended that the Windows SharePoint Services migration API be run before running this Microsoft Office SharePoint Portal Server 2003 API.”. So you have to execute both of them
- Both methods are static (MigrateUserAccount and MigrateAccount) and don’t care about your SPS or WWS site, what you need to execute them is just two user names (source and target) in format domainUserLogin. It means that the method makes changes in all WSS/SPS databases on the server.
- In terms of database changes there are no deletes or inserts, in fact looks like the method just find the entries SourceUser and updates them to TargetUser. So after migration you SourceUser just disappear from SPS and WSS and replaced with the TargetUser.
- The method replaces just LoginName but SPS/WSS databases also contain Name and e-mail that will be the same after migration. As the result if you use the SPS or WSS UI to check the result of the migration you won’t see the difference because what you see there is Name that is not changed. For example you want to migrate User: loginName: Source, Name: Source, e-mail source@source.com to User: loginName:Target, Name:Target, e-mail target@target.com . After you execute both methods the user Source won’t be able to use any of WSS/SPS sites any more instead of it the user Target will have access to all sites the user Source used to have. But the name stays the same it means that Name of the target is still Source and he has the source’s e-mail. If you “manage users” of WSS to check the sites or areasthat the Source had access to you will still see the Source (instead of target) because SharePoint UI show you the user’s name.
- The Migrate methods don’t expose their functionality as Web Services so if your application is talking to Sharepoint through web services you will have to create your own. I will talk about it in the next blog.
So it works pretty well if you just moved an account of the same user into another AD domain in this case the users name and e-mail stays the same. But if you want to use the methods to replace the access rights of one user with the rights of another one there is a lot additional work you have to do. You have to go through all WSS sites and SPS areas and update the Names and e-mails of the source user with Target. You can try to use the SharePoint utility suit http://www.microsoft.com/sharepoint/downloads/components/search.asp that is console application with the source code.
I found it much more convenient to use Sharepoint web services and AD API to update migrated user accounts with the names and e-mails from AD. I used some of the code from the SharePoint utility suit to create a web services that allows getting list of users for SPS areas (unfortunately I couldn’t find a method in SPS web services that would return a list of users for an area) I also used methods from UserGroup AreaService web services.
