SharePoint Data Migration Toolkit 1.0

SharePoint Data Migration Toolkit 1.0

The new Version of the PowerShell Content Deployment codeplex project has been released.

This solution is the only way to implement incremental content deployment, without having to transfer the whole site collection!

It also supports content deployment across two different SharePoint versions. (SharePoint2010 / SharePoint 2013)

Check out the latest Version.


I have created a tool for Content Deployment between two SharePoint Farms.
By using the switch OverrideSchemaVersion it is also possible to deploy content from SharePoint 2010 to SharePoint 2013.

Its made of PowerShell Scripts and XML.

Of course there are other tools already on the market, but with this Solution you are able to “Copy” only the list, without being forced to Copy the whole SiteCollection.

It is also possible to establish a content deployment scenario with having different Farm Versions/Patch Levels and Feature sets in the Source VS. Destination.

This tool makes it possible to implement an incremental content deployment szenario for SharePoint Lists between two distinct Farms


  • SharePoint2010->SharePoint2013 migration
  • Full migration
  • Incremental migration
  • Transfering original metadata : Created,CreatedBy,Modified,ModifiedBy
  • Lookup column support
  • Support for disconnected scenarios (2 different Farms Intern vs Extern)
  • Transfering UserInformation from external Users, even if they do not exists in the destination Farm (e.g. FBA and internal Intranet)


  • Each Farm needs a own copy of the scripts.
  • Both Farms share the same storage and export/import history file



Migrieren von Benutzern

Migrieren von Benutzern

Nachdem ein Domänen Benutzer im Active-Directory umbenannt oder dieser in eine andere Domäne migriert wurde, muss man als SharePoint Administrator das Kommando stsadm -o migrateuser oder Move-SPUser ausführen, damit das neue/migrierte Konto die SharePoint Berechtigungen erhält.

Hier ist die Snytax für das veraltete stsadm.exe Kommando

stsadm -o migrateuser -oldlogin -newlogin [-ignoresidhistory] stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob

Hier ist die entsprechende Syntax für den selben Vorgang, nur mit dem PowerShell Cmdlet und ensprechender Syntax

Move-SPUser [-Identity] -NewAlias [-AssignmentCollection ] [-Confirm []] [-IgnoreSID ] [-WhatIf []]
Move-SPUser -Identity “HSD\Bob1” -NewAlias “HS\Bob”

Wann immer die Fehlermeldung – DS_NAME_ERROR_DOMAIN_ONLY auftaucht, liegt es daran, das der SidHistory check fehlschlägt.

Das Kommando migrateuser/Move-SPUser sucht in der SIDHistory des neuen Accounts den alten Account (Neuer Account->Prüfe ob es einen Eintrag gibt->OLDName->NEWName)

In folgenden Fällen wird das Kommando Fehlschlagen, da kein Eintrag in der SID Historie des neuen Accounts gefunden werden kann.

  • Der Benutzeraccount wurde nicht umbenannt, sondern neu erstellt
  • Der Benutzeraacount wurde in eine andere Domain transferiert

Im ULS sieht die Meldung dann wie folgt aus:

stsadm: An error occurred while translating user name ‘HS\BOB1’ to a Windows account name – (DS_NAME_ERROR_DOMAIN_ONLY) Callstack: at Microsoft.Office.Server.Utilities.WindowsSecurity.TranslateUserName(String name, DS_NAME_FORMAT formatOffered, DS_NAME_FORMAT formatDesired) at Microsoft.Office.Server.UserProfiles.Helpers.GetSidHistory(String strAccountName) at Microsoft.Office.Server.UserProfiles.Helpers.IsSidInSidHistory(String strAccountName, Byte[] bOldSid) at Microsoft.Office.Server.Administration.AccountMigrationManager.MigrateAccount(Guid partitionId, UserProfileApplication userProfileApplication, String strOldAccountName, String strNewAccountName, Boolean bEnforceSidHistory)


Glücklicherweise gibt es einen Schalter, der den SidHistory check umgeht.

  • stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob -ignoresidhistory
  • Move-SPUser -Identity “HSD\Bob1” -NewAlias “HS\Bob” -ignoresidhistory
%d bloggers like this: