Overcoming challenges when migrating SharePoint Online user profile properties
Hey! I know my usual style is to write super long blog posts, but I figured I’d quickly share some things I discovered when doing a tenant-to-tenant migration for SharePoint Online user profile properties.
A bit of background: In the past, I had developed a couple of SPFx solutions for a customer that relied on custom SharePoint Online user profile properties. Those properties are excellent when you need to save user-specific settings somewhere that your SPFx solutions can easily access. Due to a company acquisition, those solutions and the user profile properties they depended upon—including their existing values—needed to be migrated to another tenant.
I had SharePoint Administrator permissions on both tenants, so I figured it’d be simple to run a PowerShell script to read the property values from one tenant and write them to another using my admin credentials. However, I ran into two issues before I could complete the task, and this blog post will detail what those issues were and how I overcame them.
User profile property values needed to be visible to “Everyone”
The user profile properties that I wanted to migrate were set to be visible only to the users themselves (“Only me”). Even though I could read these user profile property values for all users via the SharePoint admin center user interface, I could not read the values with the Get-PnPUserProfileProperty command available on the PnP.PowerShell module.
The solution was to make the properties visible for “Everyone” without the user-specific override option. After that, I could read all the existing user profile property values with PnP.PowerShell. Naturally, I manually changed the settings to their original values after the migration.
Writing user profile property values can’t be done with an account that has MFA
After setting the user profile property values to be visible to “Everyone” on both tenants, I thought I was good to go, but no. I ran into another issue: When running the Set-PnPUserProfileProperty command, I got an error saying, “This operation requires you to be managing your own data or have administrator privileges.” After which, I exclaimed: “Yeah, I have administrator privileges!!!”
After a bit of googling, I ran into a GitHub issue where the verdict was basically that this is an issue that Microsoft should fix, and in the meantime, we have multiple ways of working around the problem:
- Disable MFA and then log in with the admin credentials. Um, no. Disabling MFA is not a good idea, especially for an administrator account.
- Use SharePoint ACS (Legacy) App Only authentication. “Legacy,” you say? Next.
- Create an Entra ID application registration, grant the required permissions, and authenticate in the script using certificate authentication. OK, this is something we can work with!
Setting up the certificate authentication
Authenticating to PnP.PowerShell with a certificate is relatively straightforward once you know how to do it. And I’m here to tell you just that!
- Use the PowerShell script below to create a self-signed certificate. Note down the password. The script will generate the certificate files in the directory that is currently active on the command line when you execute the script.
- Create an Entra ID application registration using the default settings. After creation, note down its client ID for the script.
- Go to the Certificates & secrets blade and upload the certificate file to the Certificates tab.
- Go to the API permissions blade and add the following SharePoint application permissions:
- Sites.FullControl.All
- User.ReadWrite.All
- Click on the Grant admin consent button or ask your global admin buddy to do so.
- In the PowerShell script, authenticate to PnP.PowerShell with the following lines of code.
After running the script, remember to delete the application registration so those no longer needed permissions won’t stay in effect.
Afterword
Migrating SharePoint Online user profile property values was not as straightforward as I initially thought. Still, I swiftly overcame the little blockers I encountered along the way. Hopefully, this blog post will help you tackle the issues quickly and appropriately if you need to do the same task in the future.
Thanks for reading; it is always appreciated. Until next time!
Laura