We recently ran across an issue a customer was having with the migration of “My Site” content to SharePoint 2010. In their case, the target configuration was Claims Mode using an external STS for authentication. They upgraded their web application to claims-mode, converted the users to SAML claims principals, and then configured the User Profile Service to synchronize with Trusted Identity Providers.
Profile synchronization ran fine. However, whenever a user clicked the “My Content” link, a brand new “My Site” would get created which, of course, did not contain the user’s old data. The issue turns out to be quite straightforward when one examines the user profile after synchronization runs:
You can see that when running profile synchronization in Trusted Claims Provider mode, the default personal site location gets set to: /my/trustedprovider_{trusted_provider_name}_{identity_claim_value}. As far as I can tell, there is no way to override this default.
The good news is that all one has to do is set this value back its original pre-migration settings that existed back in MOSS. And I found a set of handy, dandy PowerShell scripts by Paul Childs you can use to make this happen in-bulk. Just be sure to replace $adAccount = “PBDEVtnielsen” with something like $identityClaim = “i:0e.t|ADFS20|tnielsen@pbdev.local”. After correcting the path to the Personal Site, all should be well.
Profile synchronization ran fine. However, whenever a user clicked the “My Content” link, a brand new “My Site” would get created which, of course, did not contain the user’s old data. The issue turns out to be quite straightforward when one examines the user profile after synchronization runs:
You can see that when running profile synchronization in Trusted Claims Provider mode, the default personal site location gets set to: /my/trustedprovider_{trusted_provider_name}_{identity_claim_value}. As far as I can tell, there is no way to override this default.
The good news is that all one has to do is set this value back its original pre-migration settings that existed back in MOSS. And I found a set of handy, dandy PowerShell scripts by Paul Childs you can use to make this happen in-bulk. Just be sure to replace $adAccount = “PBDEVtnielsen” with something like $identityClaim = “i:0e.t|ADFS20|tnielsen@pbdev.local”. After correcting the path to the Personal Site, all should be well.
