Using Windows PowerShell with Staged Migrations: Part 5
Summary: Use Windows PowerShell to license users and correct the login ID for Office 365.
Note This is a five-part series that includes the following posts:
- Using Windows PowerShell with Staged Migrations: Part 1
Use Windows PowerShell to add and verify email domains in Office 365. - Using Windows PowerShell with Staged Migrations: Part 2
Use Windows PowerShell to upload and start staged migrations. - Using Windows PowerShell with Staged Migrations: Part 3
Use Windows PowerShell to obtain the status and statistics from staged migrations. - Using Windows PowerShell with Staged Migrations: Part 4
Use Windows PowerShell to convert mailboxes to mail-enabled users in Office 365. - Using Windows PowerShell with Staged Migrations: Part 5
Use Windows PowerShell to license users and correct the login ID for Office 365.
Honorary Scripting Guy, Sean Kearney, is here, and we're finishing up our week with Windows PowerShell and staged migrations in Office 365. By this point you’ve done all the dirty work. The user email accounts are up in Office 365 and the on-premise staff is still able to communicate via email while the migration is ongoing.
Ah, yes…excellent. A job well done. Well, almost.
The Office 365 mailboxes still need to be licensed unless you’d like for them to be automatically deleted in 30 days. Which I don’t think you would.
The licensing process is very easy on a per-user basis. Simply log in to the portal and access your list of active users.
Select a user's name, and click the Edit option to open the user's attributes.
Then click the Licenses tab, choose a country for the user's location, and assign an available license.
All-in-all, this is a simple and pain-free process.
But then you think about the other 50 or 500 hundred accounts you need to license, and sometimes multiple types of licenses, and your head drops to the “shiny spot” on the desk.
Which, of course, is why you use Windows PowerShell to bypass all of these silly things. So let’s show you the easy way.
Our first task (presuming you have the MSOnline cmdlets installed and running) is to get the name of AccountSKU. These are the names assigned to all of your licenses in Office 365. We do this with the Get-MSOLAccountSKU cmdlet.
This image shows that two license packs are available in this system. We’re going to use components from the ENTERPRISEPACK, so we’ll access the AccountSkuID object and grab the last entry:
$License=(GET-MSolAccountSKU)[-1].AccountSkuID
To assign the Office 365 license with the MSOnline cmdlets requires two changes. We need to assign the user country and then assign the license (as we did in the console).
We set the country with the Set-MsolUser cmdlet and target the login ID or the user principal name in Office365, for example:
Get-MsolUser –userprincipalname ‘adent@contoso.com’ | Set-MSoluser -UsageLocation ‘US’
Then we add a license with the Set-MsolUserLicense cmdlet while providing the account SKU that we obtained earlier:
Get-MsolUser –userprincipalname ‘adent@contoso.com’ | Set-MSoluserlicense –addlicenses $License
By using this process, we would have licensed the single user, adent@contoso.com, for Office 365.
Remember that I mentioned using that cloud.csv file that we discussed yesterday? This file contains a list of all users that were successfully migrated, and it also contains the login ID. So we can repurpose this file and its contents!
So rather than typing all of this, we could use this simple script, with the presumption that the cloud.csv file is in the same folder:
$UserList=import-csv cloud.csv
foreach ($User in $Userlist)
{
get-msoluser -userprincipalname $User.CloudEmailAddress | set-msoluser -UsageLocation 'US'
get-msoluser -userprincipalname $User.CloudEmailAddress | Set-MsolUserLicense -AddLicenses contoso:ENTERPRISEPACK’
}
There we go! All done!
However, there is another issue that you might encounter. The login ID. This is inherited from the DirSync (from the user principal name) in Active Directory.
There are some situations in which you’d like to customize the login ID. We can use the same script and add in one additional line in the loop to have it grab the current email address and make it the login ID:
set-msoluserprincipalname -userprincipalname $User.CloudemailAddress -newuserprincipalname $_.onPremiseEmailAddress }
There you go. Now you have all the bits and pieces I could think of to help you if you’re doing staged migrations with Windows PowerShell and Exchange 2007. Hope this makes things a bit easier in your migration tasks!
I invite you to follow The Scripting Guys on Twitter and Facebook. If you have any questions, send an email to The Scripting Guys at scripter@microsoft.com or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then remember eat your cmdlets every day with a taste of creativity.
Sean Kearney, Windows PowerShell MVP and Honorary Scripting Guy
Light
Dark
0 comments