Discussing the ins and outs of developing for SharePoint and the Microsoft platform

This is one of those posts that I make from time to time that doesn’t actually have the answer to it, but I thought I would put it out there just in case someone else is feeling my pain and can sympathise with me at least!

Essentially what we are trying to do is to migrate users from one AD forest to a new domain in a new forest, and we need SharePoint to play ball with this. Now I mentioned in a previous post how you should migrate a user, using ‘stsadm -o migrateuser’. But the problem that I am having here is that it isn’t working and I am getting a variety of errors:

1. Object reference not set to an instance of an object
2. Access is denied. (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED))
3. New user account does not have a valid SID history
4. Error migrating profile

So here are my explanations for the first two – number 1 comes when the user you are running the command as does not have permission to the configuration databases (this is the same error you will see when a user with no access to the configuration database tries to add a solution with the stsadm -o addsolution command). The we resolved that and then found the second error – the way around this one was to add the user to the “Farm Administrators” group in the central administration site in MOSS. Put that in and you will then be at the same roadblock I am at.

So error number 3 says that the user doesn’t have a valid SID history. We checked the logs from the AD migration tool and it clearly states the migration history was successfully moved, so we don’t think that is the issue. The migrateuser command has an option “-ignoresidhistory” which is supposed to tell the migration to not verify the SID history after the move is done. However when we add that to the command we get to error number 4.

So given that error 4 is useless as well, a peep into the 12 hive logs reveals what the underlying exception is. Its a System.UnauthorizedAccessException with ”Attempted to perform an unauthorized operation” as a message. The stack trace takes us through the PortalAccountMigrationManager’s MigrateUserAccount method (which is the method you would use to migrate a user if you were doing it through code), with the actual exception happening in a method called SharedServiceAccessControlList.AccessCheckThrowIfUnauthorized. Now this leads me to believe there is an issue with the accounts access to the Shared Service Provider, but a quick browse through the UI with the account in question reveals that it has no dramas at all in getting to the content in the SSP and playing around with settings.

 So that is my current dilema – seriously if anyone out there has ideas, leave me a comment or talk to me on twitter because this is driving me up the wall!