Cloud Migration Woes: Validating Office 365 Users and Licenses (Part-1)

Cloud Migration Woes: Validating Office 365 Users and Licenses (Part-1)

Last we began like every great week begins, with coffee. The good times as it is said, didn’t last. No sooner had the warmth of the coffee left me, I started running into issues when I started migrating.

Diving Down the Rabbit Hole

The Scenario: Moving a simple and small SharePoint 2010 team site to SharePoint Online using a third party tool
The How: Most migration tools provide the capability to map users from old accounts to new accounts whether it is migrating between domains in a customer’s environment, or mapping to a provider’s hosted SharePoint domain.
The Issue: User migrations were not successful, not all mapped users were being migrated

One small complexity when migrating users to SharePoint Online, users must be mapped to what is their user principle name in Office 365. The problem is that this can take several formats depending on the active directory structure of your organization.

For Example the user Luc Hollande has email, and the domain logon user (Alias) of lhollande, though he came in from an acquisition, so really his primary email is

What does this mean in terms of the mapping? This user could have one of several mappings to an Office 365 User Object…

Which one do I use? That’s a very good question. I’ll answer that in a moment…

Licensing Implications

Now think about a user that you know that the user mapping is correct, meaning you have verified that their “Domain Logon” matches their “Cloud Logon”, and yet every time you perform the migration the user mapping fails to migrate that user. Well that’s because the user can’t be created if it doesn’t have a license assigned… Think about that for a second. That means inactive users, or users that aren’t necessarily part of a SharePoint migration can have their content migrated, however references to them as users in the site will cease to exists. This doesn’t necessarily mean that these users have left the company or that don’t use SharePoint, this just means that they may not be part of this initial migration to the cloud. This brings a whole slew of additional considerations into Migration planning and unfortunately makes the job more complex in the long run.

I can understand why this check is in place for the cloud service, maintaining active users and assuring licenses. However it may force business to allocate licenses/users much sooner than they are otherwise prepared to commit. What if a business doesn’t have enough licenses purchased to assign all of those users? This rapidly becomes an escalating issue which can be a blocker in a migration project, waiting on a purchase order, or the stakeholders to decide if they want to bring over user history, or perhaps waiting for the Active Directory Synchronization configuration to propagate correctly.

So now if the users have been assigned license and are ready to migrate, you are still faced with the problem of matching on premise users to their counterpart identities in the cloud. Luckily, Microsoft has provide the Microsoft Online PowerShell commandlets which you can use to attempt to match users identities using the “Get-MSOLUser – SearchString” Command. One small downside is that you need to download an installation file here to have access to the commandlets. Even more of a wrinkle, to get the nice login fidelity for Office 365 you really need the Sign In Assistant (Beta)


These are the steps necessary to get this script working in your environment

  1. Install the Microsoft Online Services Sign-In Assistance found here
  2. Install the Windows Azure Active Directory Module for Windows Powershell found here
  3. Launch the Windows Azure Active Directory Module, Found in the Start Menu, as pictured in Windows 8
  4. Create a reference to your Office 365 Credentials using “$cred = Get-Credential”
  5. Connect to Office 365 by running the command “Connect-MosolService -Credential $cred”
  6. Search for an online User using the command “Get-Msol-User – SearchString “search query””
  7. …Profit?!
    Using command $user | fl to get a list of properties and values of the member object of which the property IsLiscensed is very important

Matching Users

Well now that I know how to find users, how do I match up all of these users with their different logon information to their cloud identities? Well in this case I had to run the search three different times

The first search uses an assumed email format ( to try and match users to logons



Last and not least.. well maybe a little desperate, I search based on full name to see if I can find a unique user. In a small environment this works well, however in a larger environment, it might not as well.

The hope is that by this time we will have resolved the local user information to a user in our tenant so we can perform the migration. So what happens after we have found the user? The next most important thing is to determine if the user is licensed Office 365 so we can migrate that user successfully, luckily all we have to do is look at the IsLicensed property to figure that out and while we’re at it we grap the actual User Principal Name of the object in the cloud to refer to.


So now given a local user, we can now determine which users are online, which are licensed, and use that information in our migration strategy.

Now I know what you’re saying, wouldn’t it be nice to put this all together and scan a SharePoint site to see if all the users existed in the cloud? Furthermore wouldn’t it be nice to know if those users had licenses assigned? Heck couldn’t you even generate a UserMapping xml document for me to use for this migration?

The answer is yes it would, come back for Part 2 and you’ll see how it’s done.


Leave a Reply

Your email address will not be published. Required fields are marked *