Ranko

Note: Please note that I plan on verifying this on a clean system as soon as time allows. So grain of salt please.

The task at hand is changing a user name and login name of a Dynamics CRM 4.0 user. Most probably you know how to do it, it is well documented in the How to change the user name and the logon name for a user record in Microsoft Dynamics CRM article on Microsoft support site. But say you get an unknown error. Say you get no love from your event viewer, or the huge log files generated by the CRM Diagnostic Tool 4. Do you dare to go to SQL directly?

The Pledge

For this particular fun migration this was what had happened: I’d go and do the migration on a system that had plenty of user migrations done up to date. And then in the latest user group to get migrated most of the accounts would go like this:

1. Change the login to an Active Directory account not used by MS Dynamics CRM 4.0. Save.
2. Change the Domain Login field to the new AD account. Save and get the unknown error.
3. Try to save again, hoping it was something dumb. Get an error that this Domain Name is already being used by MS Dynamics CRM 4.0.

The Turn

For extra fun I had a friendly user try to login; do note that all I can see in the GUI is the account used for the migration. And the user I am trying to migrate successfully logs in and all the records and permissions are fine.

Stumped.

I could not even think of how it was done. Without a clue.

The Prestige

Having had some experience with problematic migrations, I took a quick look at the SQL. This is what you need to do, and remember this is unsupported.

USE OrganizationName_MSCRM
SELECT ActiveDirectoryGuid, DomainName, SystemUserId
FROM SystemUserBase
WHERE DomainName = 'ActiveDirectoryDomain\MigrationAccount'

Now open the migration account and the new account in AD. Compare the objectGUID of both of these to ActiveDirectoryGuid. For this version of the trick, the migrating account’s objectGUID will be stored in the ActiveDirectoryGuid field.

Now, run the following query:

USE MSCRM_MSCRM
SELECT AuthInfo
FROM SystemUserAuthentication
WHERE AuthInfo = 'W:objectSID of the new AD account'

You should get a match. One database holds your migration account, the other the new account info.

Horribly unsupported solution, backup your databases before proceeding. Test on a different server if at all possible. Do an update of the SystemUserBase in OrganizationName_MSCRM database, simply update the DomainName with the new AD login and the ActiveDirectoryGuid with the new account’s objectGuid you retrieved from AD. Open the user in CRM, update the rest of the fields manually and delete all info from the address fields – then save and it should be fine.

The Reveal
The underlying issue is the address field. When we added the original users their AD accounts had Street 1 field over 50 characters. After pulling that info the CRM threw a pop-up warning, and would only save after it was shortened.

On a login change it doesn't complain so nicely. It breaks as described. The only resolution is wither SQL updates (buuu! no!) or after you enter the new login switch to the address fields and shorten the offenders before saving. That makes it play nice.