How to preserve certain values or features when migration sharepoint content using Sharegate

When document are migrated from one site to another through Sharegate, the timestamp and user (Modified, Modified By, Created, Created By) are not preserved for draft versions. To preserve these, Sharegate provide a Server extension to be installed. The Server Extension allows Sharegate to provide you with additional functionality that might be needed in order to preserve certain values or features as indicated in Sharegate support site.

Here is one simple testing result before and after install the Sharegate Server Extension when migrating the same document. Please note the “Modified By” value will be preserved ONLY after Sharegate server extension installed.

Here is the version history for the original document on source site document library.

Here is the version history for the document on destination site document library when Sharegate server extension not installed. Please note the “Modified By” is not preserved and becomes migration account.

During the migration, Sharegate will prompt the following message.

Here is the version history for the document on destination site document library when Sharegate server extension already installed.

The installation of the Sharegate server extension is simple and no server bounce required.

1. Download the Extension installer from here.
2. Copy the Extension installer on your SharePoint web front-end server. If you have more than one Web Front-End server, copy the installer on all of them. 
3. Launch the Extension installer. It will not cause any downtime on your SharePoint server. It doesn't require a server reboot.

You can verify the installation from GAC as the following screenshot.

Here is the table of the feature that required Sharegate server extension.

Value to preserve	Source SharePoint	Destination SharePoint	Must be installed on
Authors and timestamps	Any	2007	Destination
Modified by on Draft Versions	Any	2010, 2013, and 2016, or Office 365 (when using normal mode)	Destination
Approval status (with authors and timestamps)	Any	2007, 2010, 2013, 2016	Destination
Business data (BDC)	Any	2007	Destination
Content type OOB (Out-Of-the-Box) workflow configuration	2007	Any	Source
Items declared as Records	2010, 2013, 2016, Office 365	2010, 2013, 2016	Destination
Items with a high version number on the first version	Any	2007, 2010, 2013, 2016	Destination
List OOB (Out-Of-the-Box) workflow	2007 Foundation (WSS 3.0)	Any	Source
Nintex workflow constants	2007, 2010, 2013	2010, 2013	Both
Nintex workflow history	2007, 2010, 2013	2007, 2010, 2013	Both
User alerts	2007, 2010, 2013, 2016	2007, 2010, 2013, 2016	Both
Records Enabled	All versions of Office 365 or Sharepoint	Office 365 (when using normal mode)	Both
Features
Insane Mode	2007, 2010, 2013, 2016, Office 365	2007, 2010, 2013, 2016	Both

You can check all the features that server extension Sharegate required for migration here. You might need to install the server extension on both source and destination SharePoint servers or O365 site.

You can remove the Sharegate server extension from add/remove features.

Now you can enjoy using Sharegate to migrate contents.

What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro, developer, or end user?

We plan to migrate SharePoint 2010 from classic-mode to claims-based authentication to prepare the 2013 upgrade as described in previous article. Although Microsoft describes this is a simple process, it seems the tips and tricks are not provided for different SharePoint users including IT Pro, developer, or end user. This article describes the details what you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro, developer, or end user. Several tips and scripts are provided to help you on the smooth migration.

1. What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro?

A. Migration steps are simple and in four steps

• Migrate webapp

     $WebAppName = "http://yourWebAppUrl"
     $wa = get-SPWebApplication $WebAppName
     $wa.UseClaimsAuthentication = $true
     $wa.Update()

• Configure the policy to enable the farm admin account to have full access

     $account = "yourDomain\farmAdmin"
     $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
     $wa = get-SPWebApplication $WebAppName
     $zp = $wa.ZonePolicies("Default")
     $p = $zp.Add($account,"PSPolicy")
     $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
     $p.PolicyRoleBindings.Add($fc)
     $wa.Update()

• Migrate users

     $wa.MigrateUsers($true)

• Perform provisioning

     $wa.ProvisionGlobally()

B. Tips and scripts to help IT Pro for the migration

• Apply June CU 2012 in SP 2010 environment before migration and advantages of this CU are given below.
• An update enables the MigrateUser method to accept content database names as parameters so that you can perform migrations on the specified list of database. Additionally, this update enables you perform the migration in parallel if you have a large volume of data that contains millions of users.
• An update provides APIs or cmdlets to make sure that the same claim type uses the same encoding character on multiple SharePoint farms.

• Remove manually added IIS host header bindings for the web applications configured to use claim based authentication. Otherwise an authentication failure will happen with 401 errors. You could change the host header URL as described here.

• Keep Kerberos over claims to streamline integration to external system and the reason is list in previous blog

•  Configure C2WTS ‘AllowedCallers’ as described in c2wtshost.exe.confi file is saved in the following location \Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config 

•  Stop the following services and applications before migration

•  User Profile Sync
•  Search crawling
•  Web analytical 
•  Search service application window service
•  World Wide Web Publishing Service window service
•  Third party tool like DocAve process and NextLabs services

• Identify scheduled timer jobs and disable them before migration. Enable them after migration using the following steps I got from out consultant.

• Capture the list of currently enabled jobs                         

             Get-spTimerJob | where { !$_.IsDisabled } | SELECT ID | out-file c:\enabledjobs.txt

• Open c:\enabledjobs.txt and delete the first three lines and save. Then, you will need to delete the last three blank lines in the file (If you do not do this it will disable all jobs)

• Run the following command and make sure the last column says false (this ensures you have edited the enabledjobs.txt file correctly                      

               Get-Content c:\EnabledJobs.txt | Foreach-Object { Get-SPTimerJob -id $_  | SELECT ID, DisplayName, IsDisabled}

• Disable all those jobs run the following                            

               Get-Content c:\EnabledJobs.txt | Foreach-Object {Disable-SPTimerJob $_ }

• Re-enable all those jobs run the following                                 

               Get-Content c:\EnabledJobs.txt | Foreach-Object {Enable-SPTimerJob $_ }

•  Configure the publishing cache accounts to reflect the claim format identities, otherwise publishing sites will fail with “Access Denied” Error

•  Run “Claims to windows token service” if there are external sources used and passing NTLM credentials for authentication. Verify excel services.

2. What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as developer?

      A. Getting the Current User in Claims Mode code change 

HttpContext.Current.Identity;                      //Old way

SPContext.Current.Web.CurrentUser;       //Still works

IClaimsIdentity identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity; // New way

    B.  After claim migration – Impersonating the user using c2wts

// Check the current claims identity and use the UPN claim

if (SPSecurityContext.IsWindowsIdentityAvailable)

{

    // Use the c2WTS and get the windows identity

    WindowsIdentity wid = SPSecurityContext.Current.WindowsIdentity;

    //Create the Impersonation context

    using ( WindowsImpersonationContext ctxt = wid.Impersonate() )

    {

        // Do work here

    }

}

   C.  Retrieve user name from its claims representation code change

                   SPClaimProviderManager mgr = SPClaimProviderManager.Local;

                   string userName userName =  

                         mgr.DecodeClaim(SPContext.Current.Web.CurrentUser.LoginName).Value;

   D. Get claim from login user name

         SPClaimProviderManager mgr = SPClaimProviderManager.Local;

         SPClaim claim = new SPClaim(SPClaimTypes.UserLogonName, "myuserName", 

            "http://www.w3.org/2001/XMLSchema#string", 

            SPOriginalIssuers.Format(SPOriginalIssuerType.Forms, "myprovider"));

         string userName = mgr.EncodeClaim(claim)

      We have this in out perl WCF code.

                claim = new SPClaim(SPClaimTypes.UserLogonName, userName, 

                              "http://www.w3.org/2001/XMLSchema#string",    

                               SPOriginalIssuers.Format(SPOriginalIssuerType.Forms,  

                               ConfigurationManager.AppSettings["Membership"].ToString()));

   E. Client object model potential code change - add header to request
         WebRequestExecutor.RequestHeaders.Add( "X-FORMS_BASED_AUTH_ACCEPTED", "f");

3. What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as an end user?

  A. FAST Search Server 2010 for SharePoint document preview does not work with SharePoint Server 2010 claims-based Web applications.

   B. Existing alert may not fire. We might need to delete and recreate them.

  C. People picker (in SP 2010) will display the user information in a different way like "i:0#.w|na\harrycx" . This is worth if you want to display the groups. Please see this article for the claim format.

  D. The following SharePoint Server 2010 features do not work when you switch to a claims-based Web application that uses forms-based authentication or Security Assertion Markup Language (SAML) security tokens. These features do not work because claims-based authentication does not generate a Windows security token, which is necessary for these features. Our extranet webapps are using Claims with FBA and will have these issues. However, some of them are still working that need to be verified again.

• Search Alerts
• SharePoint Server 2010 Explorer View
• Claims to Windows Token Service (C2WTS)
• InfoPath Forms Services  
• Search crawling

  E. Any function related to authentication like UNC, exchange connection, workspace, security store, BCS external connections as I have described in previous blog need to be verified.

    F. Some third party tools like NextLabs may not support claims at this time.

There are more functions need to be tested and please refer my previous blog and Microsoft article for more details.