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.
(more…)
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)
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
Features
Installation
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.
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.
SharePoint Guru