Using Windows PowerShell with Staged Migrations: Part 4

Doctor Scripto

Summary: Use Windows PowerShell to convert mailboxes to mail-enabled users in 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. When last we left, you had been shown how to access the reports and statistics from your staged migration from Windows PowerShell. By that point, you would have some mailboxes completed with their data in the cloud.

What next? Today we’re stepping into the bits and bytes in Windows PowerShell.

For a moment, let’s think about what we really have: two separate and foreign Exchange servers with content on both sides. Staging is supposed to offer some type of mail flow between the systems. How would this occur?

The process is actually pretty easy. Here’s an example of our user, Mr. Ford Prefect:

Exchange 2007 email address: fprefect@contoso.com

Office 365 email addresses: fprefect@contoso.com and fprefect@contoso.onmicrosoft.com

For staff to be able to email the new address, we need to delete the old mailbox and create a mail-enabled user that has two addresses on Exchange 2007: an internal box with the old email address and an external address with .onmicrosoft.com.

But somehow they are able to email back to the original server even though both Exchange systems are in charge of Contoso.com.

Here is all that happens. On the Office 365 side, there is simply a connector created. It simply states that if an email for this domain is not found, go to THIS guy (which would be the original Exchange server environment).

So obviously, all we need to do for email connectivity is delete the mailboxes and re-create them as mail-enabled users, and all goes well…

Right! But what about additional email addresses the user had? The user GUID in Exchange? If we don’t capture that data, the end result will be bad during the migration.

Remember all of this “nicknames” in Outlook (or as many users refer to them, “My Address Book”)? Those will all break.

Fortunately for us, Microsoft has a ready-made solution to get you up and running with two scripts: Convert Exchange 2007 Mailboxes to mail-enabled users after Exchange migration.

Although these are prewritten scripts, I’m going to review them for a few reasons.

• I had trouble figuring them out the first time (silly reasons).
• There is a bug in one, which can be disastrous if you don’t watch for it.
• You can leverage the output from one of them for tomorrow's installment!

Now your first script is the ExportO365Userinfo.ps1, which takes that list of users you uploaded to Office 365 and obtains all of the relevant information you will need for Exchange 2007 as a mail-enabled user.

To run the script, you need a computer that is running at least Windows PowerShell 2.0. This does not mean that you have to upgrade Windows PowerShell on the server running Exchange Server 2007 because it only gathers data.

You need only supply your Office 365 credentials and the path of the CSV file you uploaded to Office 365 as the following example shows:

.\ ExportO365UserInfo.PS1 –migrationCSVFilename C:\Folder\UserstoStage.csv

When you execute this, you will get the following message asking you if you’d like to use an existing session:

Here’s the catch. You can do this if you imported the remote session with a prefix of Cloud.

So your normal method of managing Exchange in Office 365 might be something like this:

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session

If you have authenticated in this manner, this session will not work unless you want to go into editing the script. (You can do this by simply searching for ‘-Cloud’ and replacing it with ‘-‘.)

Or you can make this change to the script to manage Office 365 Exchange. I prefer this approach because if I need to manage Exchange 2007 and Office 365 mailboxes on the same system, it places a differentiation in the cmdlet names. It forces me to think, “I am modifying this,” instead of trying to remember, “Was this new mailbox for Exchange 2007 or Office 365?”

To use a prefix of Cloud (which allows no change to the change and may ease headaches for you), add the following change:

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session –Prefix Cloud

With this change in place you can allow the script to leverage an existing management session for Office 365.

When the script has completed, you’ll have a single file called cloud.csv. You can copy this file to one of your servers running Exchange Server 2007 (or to a workstation with the Exchange Management Console and the Windows PowerShell cmdlets) and run against it.

But wait…

I have to warn you. That first script (ExportO365UserInfo.ps1) has a bug in it. It tries to convert the CSV file and get rid of the quotation marks for some reason.

If you look at the bottom portion, the line (“Get-Content “.\cloud.csv”) should not be there. It removes quotation marks that contain nothing, and this will break your next script in some cases. (I found this when a user had some blank spaces in their distinguished name.)

So the answer is very easy. Delete or Just “Comment out the line like this”

            }

            $Users | Export-CSV -Path ".\cloud.csv" -notype

# Don’t             (Get-Content ".\cloud.csv") | %{$_ -replace '"', ''} | Set-Content ".\cloud.csv" -Encoding Unicode

            Write-Host "CSV File Successfully Exported to cloud.csv" -ForeGroundColor Green

}

With this done, you can safely use the next script on your server running Exchange Server 2007 or the Exchange Management Console. You’ll only need the necessary rights to manage Exchange normally as an admin and the name or IP address of a domain controller to authenticate to.

So presuming I have copied the following cloud.csv file to said server in a folder called C:\Temp, along with the Exchange2007MBtoMEU.ps1, I would execute the script as follows in the Exchange Management Console (presuming the domain controller name is DC01):

.\Exchange2007MBtoMEU –domainController DC01

This will now run through, capture the users provided in the cloud.csv file, and flip those objects to mail-enabled users.

The script is not perfect because it’s based on the premise of “assume nothing goes wrong.” But it works for most situations.

Come by tomorrow because we still need to license these users in Office 365 and maybe tweak their log-in attributes!

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

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow