Share and Enjoy !

[Note: this post was originally published in April, 2018 and has been updated in August, 2021.]

Introduction

During a recent Jive Migration to Microsoft 365 project, I helped with the migration of personal content. For our specific project, we focused only on the Jive personal content where binary documents or pdf versions of the content were available in Jive. For example, we migrated binary files, documents, photos, and discussions (captured in PDF format) over to OneDrive for Business (ODFB). The customer wanted to migrate this type of content to ODFB since the privacy settings needed to be maintained while also ensuring that the documents would now be available within Microsoft 365. ODFB was the perfect fit for meeting these requirements.  [August 2021 – Migrating to ODFB is just one option.  We now have the option to migrate personal content to SharePoint sites as well.  This is typically done as a set of sub-sites (one per individual) under a single site collection.  We typically prefer this option when the migration is more of an archive vs. actively used content].

Please note that this article focuses on Jive personal content migration to ODFB, but the steps discussed in this article can be used in general for migrating any types of files to ODFB.

Of course, OneDrive for Business is technically just another SharePoint site under the covers, but it does have some unique features that require additional steps in order to complete content migration to each ODFB site. Below is a summary of the migration steps, and then I will discuss each step in further detail:

Migration Steps

  1. User verification and check for already provisioned ODFB sites
  2. Add any missing users in Microsoft 365
  3. Provision any missing ODFB sites
  4. Add Secondary Site Collection Admin to each ODFB site
  5. Upload Content to the ODFB sites
  6. Remove the Secondary Site Collection Admin from each ODFB site

Step 1

First, we verify that the users exist in Microsoft 365 and check if their respective ODFB sites are provisioned already. This is an important step to prepare for a time efficient and successful migration.

  • Check if the user exists in Microsoft 365 with the same email/username as found in Jive. In our case, all users in Microsoft 365 had the proper license assigned to them so they could access ODFB, but you may need to also check for licensing requirements as well. Also, ensure that the user is active in Microsoft 365.
  • Then check to see if the ODFB account has already been provisioned. If ODFB was already provisioned, typically the user self-provisioned ODFB for themselves but there is also a possibility that an administrator provisioned the ODFB site on behalf of the user using a script like the one we will discuss in Step #3. We just need to know which ODFB sites are already provisioned and which ones are not.

We used a PowerShell script to check for all the users we had identified in Jive with personal content, and then produced a report of which users were found in Microsoft 365 and whether their ODFB site had been created already.

Please note, the URL for the ODFB site generally follows the pattern below:

https://O365TenantName-my.sharepoint.com/personal/username_domain_com

The “O365TenantName” is self-explanatory, but everything to the right of the last forward slash is the username where the “@” and “.” characters are replaced with underscore characters. For example, a username of tsmith@company.com and tenant name of “company” will typically have an ODFB URL of:

https://company-my.sharepoint.com/personal/tsmith_company_com

But again, this is “typically” the pattern for the ODFB URL. To be certain you are using the correct ODFB URL for each user, it is best to check the “PersonalSpace” user profile property for each Microsoft 365 user to determine the exact ODFB URL. The code below shows how to obtain the personal site URL:

[code]

# load the user profile to get the ODFB or “PersonalSpace” URL

$properties = $peopleManager.GetPropertiesFor( "i:0#.f|membership|$Identity" )

$ClientContext.Load($properties)

Invoke-ClientContextWithRetry -ClientContext $ClientContext

if( $properties.UserProfileProperties -and $properties.UserProfileProperties.ContainsKey( "PersonalSpace" ) )

{

$userPersonalSiteUrl = $properties.UserProfileProperties["PersonalSpace"]

}

Additional Notes regarding the code above:

$peopleManager = New-Object Microsoft.SharePoint.Client.UserProfiles.PeopleManager($ClientContext)

[/code]

The $userPersonlSiteUrl obtained above will have to be added to the following root URL to obtain the complete ODFB URL: “https://{Microsoft 365 tenant name}-my.sharepoint.com”

Step 2

Any users that were identified as missing in Microsoft 365 during step #1 need to be created now and assigned a valid user license. The Microsoft 365 admin should be able to handle this via their standard user provisioning process. Please consider that you may have to map user emails from Jive to Microsoft 365 if the user has a different username in Microsoft 365, although this situation did not occur during our recent project.

Step 3

Now that all your users are set up in Microsoft 365, you need to ensure all the ODFB sites are setup/provisioned. You must use a SharePoint Online global administrator and site collection administrator in order to run the ODFB provisioning code in this step.

Since provisioning takes time, please plan accordingly to properly provision each account and complete the migration on time. Obviously, to save time, we only provisioned the users that had personal private content in Jive and that did not already have a self-provisioned ODFB site. Using the data collected in Step #1 significantly reduced the amount of time required to complete Step #3. But even then, provisioning took a significant amount of time, so please plan enough time to complete this step. In our experience, it took between 1-2 minutes to provision each ODFB site, but this value can vary significantly based on many factors. It is best to provision a small batch of ODFB sites to check how long it is taking in your specific Microsoft 365 tenant. I also recommend running the provisioning scripts during low tenant usage times for faster provisioning rates.

Please keep in mind that there is a limit of 200 users per batch when doing bulk provisioning. This limit is documented (here).  You will want to ensure that the batch is complete before starting the next full batch of 200 since there is a queue for the tenant that will only process up to 200 users at a time.

Here are the primary PowerShell script lines for provisioning the ODFB site:

[code]

#Run OneDrive/PersonalSite Provisioning in batches of 200 since that is the batch size limit, so the list of usernames passed into $usersToProvision should not exceed 200 total users

Request-SPOPersonalSite -UserEmails $usersToProvision -NoWait;

[/code]

Note: Microsoft.Online.SharePoint.PowerShell module must be installed to run the code above.

After all batches are run, I recommend rerunning the script from Step #1 to verify that each ODFB site was properly provisioned before moving on to Step #4.

Step 4

Before the content can be uploaded to the ODFB sites, the migration user account must be added to each ODFB site as a secondary site collection administrator. By default, the ODFB user is the only site collection administrator for their respective ODFB site, and therefore the only user with access to the ODFB site content. The migration user account being added to each ODFB site must be an administrator with upload rights and must also be licensed for SharePoint Online.

This migration user account will only be temporarily added to the ODFB sites for the purposes of migration.

Here is a code example of a PowerShell script that adds the migration user account to the ODFB site as a secondary site collection administrator:

[code]

#Add secondary admin here:

Connect-SPOService -Url $tenantAdminUrl -Credential $credential

$sODFBSite=$mysitewebUrl + $userPersonalSiteUrl

Set-SPOUser -Site $sODFBSite -LoginName $secondaryODFBAdmin -IsSiteCollectionAdmin $true

Additional Information about the code variables above:

$secondaryODFBAdmin = "{email address for admin user being added as secondary site collection admin}"

$mysitewebUrl = "https://{Microsoft 365 tenant name}-my.sharepoint.com";

$userPersonalSiteUrl = same personal ODFB site URL obtained in the Step #1 code example from the User Profile Property named “PersonalSpace”.

$tenantAdminUrl = "https://{Microsoft 365 tenant name}-admin.sharepoint.com"

$credential = a credential object for a specified user name and password

[/code]

Step 5

Now that the users and ODFB sites are all prepared in Microsoft 365, we are finally ready for the actual migration of the files/content.

To upload the Jive personal content to ODFB, we agreed with our customer that all Jive content would be placed in a newly created subfolder named “Migration”. You can place the content wherever you would like in ODFB, but we recommend identifying a standard location, especially if you have a large number of users. This becomes especially important for communicating with users when the IT support person does not have direct access to the ODFB site files or folder structure, yet has to direct the user where to find their recently migrated content. Of course, a subfolder name should be selected that is unique for all the existing ODFB sites, so the Jive content is organized in a new, distinct location with no chance of overwriting an existing file.

During our recent migration project, we also created additional subfolders under the new “Migration” subfolder, labeled by Jive Content Type, to help further sort the files and allow the user to find items more easily.

Here is a code example of creating a new subfolder in ODFB, so all migrated files can be found in a standard location for each user:

[code]

using (var clientContext = new ClientContext(URL))

{

List list = clientContext.Web.Lists.GetByTitle("Documents");

clientContext.Credentials = new SharePointOnlineCredentials(userName, secure);

clientContext.Load(list.RootFolder);

clientContext.ExecuteQuery();

Folder NewFolder = list.RootFolder.Folders.Add("Migration");

clientContext.Load(NewFolder);

clientContext.ExecuteQuery();

}

[/code]

The URL in the first line of code is the personal ODFB site. The “Documents” list is the default location for ODFB files. In the example above, we added a new subfolder named “Migration” to place all the migrated Jive personal content files, but this subfolder name could obviously be changed for a new migration.

Once the new “Migration” subfolder was created (as well as our other custom subfolders), we used our standard file upload functions to move the personal content files into each appropriate ODFB site, iterating through each user that was identified as having personal content.

Step 6

As a final step, remove the secondary site collection admin after the migration has been tested/verified. There may be reasons to keep the secondary site collection admin, such as oversight and support; but in our case, we removed this secondary site collection administrator once the migration was verified so the user would not see this additional admin user in their personal ODFB site.

Summary

Although this article focuses on Jive personal content migration to OneDrive for Business, please keep in mind that the steps described above can be used to migrate files from other sources over to ODFB sites in Microsoft 365.  [August 2021 – As mentioned earlier, migrating personal content to ODFB is one option.  As we continue to refine our migration capabilities, we love to provide customers with the best option to suit their needs].

If you follow the 6 Steps above, you should be able to move more of your users’ content into Microsoft 365 from Jive or elsewhere and enable your users to better take advantage of the benefits of OneDrive for Business. Consolidating your users’ information into one common location really improves the user experience and efficiency, and will be well worth the effort.

 

Share and Enjoy !

Related Content: