SHAREPOINT USER MIGRATION
Rishabh Y Mathur
SCRIPT
Assumption: AD user migration is migrating users based on OU and is not migrating all user objects at once.
• We will have to migrate users in batches by getting the user mapping from your AD team for every iteration.
• We could then use the below/attached reference script to migrate users
Sample script
============
Function MigrateUsers($inputUserFile)
{
foreach($SPSite in (Get-SPSite -Limit all))
{
foreach($SPWeb in (Get-SPWeb -Site $SPSite))
{
foreach($SPUser in $inputUserFile)
{
if($UserObject = (Get-SPUser -Identity $SPUser.UserAlias -Web ($SPWeb.url) -ea 0))
{
Move-SPUser -Identity $UserObject -NewAlias $SPUser.NewUserAlias -IgnoreSID -confirm:$False
if($UserObject)
{
Remove-Variable -Name UserObject
}
}
}
}
}
}
You can run by the below option with your AD team if this would make sense for you or not.
UserAlias FirstNameLastName Email
NewUserAlias
RC2012\UserOne
User
One
[email protected]
RC2012\UserEleven
RC2012\UserTwo
User
Two
[email protected]
RC2012\UserTwelve
RC2012\UserThree
User
Three
[email protected]
RC2012\UserThirteen
RC2012\UserFour
User
Four
[email protected]
RC2012\UserFourteen
RC2012\userFive
User
Five
[email protected]
RC2012\UserFifteen
I have attached a full script that you could potentially leverage in full or parts. Please note that I highly recommend braking the script in parts and testing it first before applying any
changes in production.
THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
RISK MITIGATION
- The blog lists some side effects of move-spuser cmdlet, but the sample script I have attached takes care of it.
http://blogs.msdn.com/b/rcormier/archive/2012/02/24/interesting-side-effects-of-the-move-spuser-powershell-cmdlet.aspx
- In flight workflow will be affected with the move-spuser cmdlet as well. You will have to write some custom code to possibly associate those
workflows to the migrated user identity.
Note: above issue was identified with earlier build of SP2010 (pre SP1, need to check exact build), SP 2013 you should not see this issue.
- Ensure you are disabling the mysite cleanup job during the migration process.
- Disable the “<UPA Name> - User Profile to SharePoint Full Synchronization” (ProfSync) timer job while user are being migrated.
Some other potential issues
#1
SharePoint Designer 2007 workflows that have not been upgraded to SharePoint Designer 2010 workflows will fail to start if 'Move-SPUser'
command is used to change the users or if IMigrateUserCallback is used to write object model that performs a similar task.
The following error will be displayed in ULS:
RunWorkflow: Microsoft.SharePoint.SPException: User cannot be found.
CONTD
RunWorkflow: Microsoft.SharePoint.SPException: User cannot be found.
at Microsoft.SharePoint.SPUserCollection.get_Item(String loginName)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.LoadWorkflowBytesElevated(SPFile file, Int32 fileVer, Int32& userid, DateTime& lastModified)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.LoadWorkflowBytesElevated(SPWeb web, Guid docLibID, Int32 fileID, Int32 fileVer, Int32& userid,
DateTime& lastModified)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.<>c__DisplayClass1.b__0(SPSite elevatedSite, SPWeb elevatedWeb)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.LoadWorkflowBytes(SPWeb web, Guid docLibID, Int32 fileID, Int32 fileVer, Int32& userid)
at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)
at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)
at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection`1 events, SPWorkflowRunOptionsInternal runOptions)
CONTD
#2
Newsfeed posts that were created before the migration still reference the old account.
This is a known product behavior
Move-SPUser command doesn't affect the Microfeed list, but is limited to UserInfo table.
The following list of columns from the Microfeed list may contain references to the old account name:
PostAuthor - Refering the author of the current post
RefRoot – Whena user replies on a conversation that was initiated by another user.
RefReply – when the users replies don a conversation that was initiated by another user. The account may be URL encoded
PeopleList – the list of users that have replied to a conversation
eMailSubscribers – the list of users that have subscribed to the conversation by replying or clicking the LIKE button
LikedBy – the users that have clicked on the LIKE button
ContentData – if a user is mentioned (by typing @DisplayName in a post or a comment). The account may be URL encoded
Ref:
http://blogs.msdn.com/b/sowmyancs/archive/2012/01/07/migrate-users-groups-powershell-script.aspx?PageIndex=2
SharePoint, MySites and AD domain migrations. How to make it happen smoothly
http://blogs.technet.com/b/sheyia/archive/2014/05/22/sharepoint-mysites-and-ad-domain-migrations-how-to-make-it-happen-smoothly.aspx
LAB TESTING - SETUP
Performed below tasks in my lab environment
- Setup 2 forests : fabrikam and contoso
- Setup SP2013 in contoso domain
- Created a two way transitive trusts between the two forests
- setup people picker property as below
fabrikam domain users were searchable in people picker post execution of below query
stsadm.exe -o setapppassword -password ABCDEFG
Operation completed successfully.
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv
"forest:fabrikam.com,fabrikam\administrator,access" -url http://sp
Operation completed successfully.
Note: if password for fabrikam admin changes, peoplepicker will stop working. Need to run above cmdlet
with updated password
Ref: https://technet.microsoft.com/en-us/library/gg602075.aspx
LAB TESTING - STATE
- Before Migration State
 UserInfo table in content db
 Logging in with fabrikam account
LAB TESTING – MIGRATION CMDLETS
- User claim
Get-SPUser -Identity "i:0#.w|contoso\test1" -Web http://sp
UserLogin
---------
DisplayName
-----------
i:0#.w|contoso\test1 test1
- Tested migration for one account successfully
$olduser = Get-SPUser -Identity "i:0#.w|contoso\test1" -Web http://sp
$newuser = "i:0#.w|fabrikam\test1"
Move-SPUser -Identity $olduser -NewAlias $newuser -IgnoreSID -Confirm:$false
LAB TESTING - STATE
- Post migration state
 Userinfo table in content database
LAB TESTING – WRAP UP
- Experience logging on to the site
MIGRATING USERS BETWEEN DOMAINS GOTCHAS
- move-spuser gets applied across all web apps in the farm for specified user.
- SPD 2007 workflows that have not been upgraded to SPD 2010 will fail to start if
'Move-SPUser' command is used to change the user identity
- The migrate user cmdlet does the following in order:
#Marks the “new login id” for deletion (if the “new login id” already has some
permissions set)
#Replaces the “old login id” to the “new login id” (when the “old login id” already
has some permissions set)
More details: https://blogs.msdn.microsoft.com/srigutha/2013/02/27/migrateusers-in-sharepoint-users-having-access-issues-after-migration/
PEOPLE PICKER ISSUE WITH OLD DOMAIN BEING
ACTIVE
Symptoms
Consider the following scenario:
The SharePoint farm exists in DomainB.
You have users in DomainA.
You migrate users to DomainB, including SID history, and disable them in DomainB.
You use People Picker in your SharePoint farm to find a user in DomainA.
In this case, People Picker shows the active users in DomainA, but also shows the disabled users in DomainB.
If you choose the active user in DomainA, it may resolve to the disabled user in DomainB.
Another scenario here is that when you use people picker, it only shows the active user in DomainA, but when you select the
user, it resolves to the account in DomainB.
For example, you find Contoso\User1. However, when you select that user, it then resolves to Fabrikam\User1.
Notes:
I’ve seen some customers leave both users active. This same problem occurs, and the same resolution applies.
This is common in situations where the customer is using Exchange linked mailboxes to provide email to users in DomainA.
CONT’D
Cause
People Picker calls a Windows API (LsarLookupSids3) to resolve the user name by SID. This goes to the local DC first (in DomainB) which returns accounts matching that SID even though they
are disabled.
This is a known issue, see the description here:
http://support.microsoft.com/kb/2687339
“Consider the following scenario:
You add a user account in a domain (domain A) to a SharePoint site in another domain (domain B).
You migrate the user account from domain A to domain B.
You disable the user account in domain B.
You use the People Picker control to search for the user account on the SharePoint site.
In this scenario, both the active user account and the disabled user account are displayed”
Resolution
This is fixed in the August 2012 Cumulative Update (build 14.0000.6126.5000) for SharePoint 2010. It is also fixed in the RTM version of SharePoint 2013. You would also need to
enable it for SharePoint 2013 RTM and above.
To enable the fix, run this stsadm command:
stsadm -o setproperty -propertyname "HideInactiveProfiles" -propertyvalue "true"
Notes:
Both the strings "HideInactiveProfiles" and "true" are case sensitive and must be entered exactly as shown.
After making this change, you may also need to temporarily disable / clear the LSA cache on the WFEs to clear out any “bad” SID to name mappings in the cache. Failure to do so may
result in the appearance that setting HideInactiveProfiles did not work.
Example: In one case, the customer was hitting scenario #2 above. After setting HideInactiveProfiles to True, Contoso\User1 was still resolving to Fabrikam\User1, even though other users
we tested were resolving correctly. This is because we had been testing with Contoso\User1 the whole time, and the SID was cached on the local WFE as resolving to Fabrikam\User1.
Just follow the steps here to disable LSA cache on the WFEs:
http://support.microsoft.com/kb/946358
Important: Once you've disabled LSA cache and done at least one PP search, you should re-enable the cache by deleting the LsaLookupCacheMaxSize key. Failure to re-enable the LSA
cache can result in SIDs being resolved to the wrong accounts. For example, entering "Contoso\User1" and hitting "check names" may resolve the account to Fabrikam\User1.