This is part of an on-going article for migrating mailboxes from an on-premise Exchange 2010+ environment to Microsoft's O365. See post here.
When performing a migration from on-premise Exchange to O365, the migration batch/move-request process will look for specific properties (Exchange GUID, Primary SMTP Address) and fail the moves if they do not match. In addition, you'll want to modify the UserPrincipalName on the AD objects so that clients logon to OWA using their email address.
Exchange properties and ADObject name:
The script:
Point the following script at the CSV and the Organizational Unit for where to create new user objects. Note: New users will typically be resource type mailboxes in the Exchange environment. They can be moved after creation to the correct folders in your AD structure. Just make sure that this other OU is also synced up to the O365 tenant.
.\Import-O365IdentityPackageCSV.ps1 -CSVPath .\Finance.CSV -NewUserOU "Contoso.local\Resource Accounts"
Creating the Identity Package - Mailboxes
As an Exchange admin, one of your first steps will be to sync the mailbox properties from the resource forest into the authentication domain. These mailbox properties are applied to the mailbox linked master account and synchronized to O365.When performing a migration from on-premise Exchange to O365, the migration batch/move-request process will look for specific properties (Exchange GUID, Primary SMTP Address) and fail the moves if they do not match. In addition, you'll want to modify the UserPrincipalName on the AD objects so that clients logon to OWA using their email address.
Exchange properties and ADObject name:
- #Name (name)
- #DisplayName (displayname)
- #SamAccountName (SamAccountName)
- #WindowsEmailAddress (mail)
- #PrimarySMTPAddress (from ProxyAddresses)
- #LegacyExchangeDN (legacyExchangeDN)
- #EmailAddresses (proxyaddresses)
- #ExchangeGUID (msExchMailboxGUID)
- #GrantSendOnBehalfTo (publicDelegates)
- #ExternalEmailAddress (TargetAddress)
Part 1: Exporting Exchange properties from Exchange:
This script (testing out pastebin), is the latest revision of my script to do this. When it is run in your RF, you'll need to provide it a list of mailbox objects, the current accepted email domain (@example.com) and the tenant email domain (i.e. @ExampleTenant.onmicrosoft.com). The script will export a CSV file in the current directory containing all of the required properties.- $ExportNames = get-mailbox -organizationalunit "Finance" -resultsize unlimited
- .\Export-RFToAD.ps1 -identity $ExportNames -acceptedDomain "Example.COM" -O365Domain "Contoso.OnMicrosoft.com" -department "Finance"
The script:
Part 2: Importing the Exchange Properties
Once the CSV has been created, copy it over to the Exchange box in the authentication domain. This admin account will need to have sufficient permissions to modify all objects in this domain.Point the following script at the CSV and the Organizational Unit for where to create new user objects. Note: New users will typically be resource type mailboxes in the Exchange environment. They can be moved after creation to the correct folders in your AD structure. Just make sure that this other OU is also synced up to the O365 tenant.
.\Import-O365IdentityPackageCSV.ps1 -CSVPath .\Finance.CSV -NewUserOU "Contoso.local\Resource Accounts"
If the script is unable to finish the steps, it will generate a new CSV called ".\FailedToImport.csv". Review each of these users in the authentication AD to see why they may have failed.
Possible Failure scenarios:
- Legacy Exchange properties - Unable to apply new Exchange properties as they still have properties from a former Exchange install. "Can't enable mail user as it's already a mailbox", or "Can't contact (some server long gone) to mail enable user". I attempt to resolve this issue by checking for the setting (~ line 92). If this does not resolve the issue, check the ADUC Attribute Editor for references to the legacy environment and (you may have to) remove them.
- Non-Inherited permissions - If the script was unable to modify an account "ACCESS DENIED", the issue is typically because the account is not inheriting permissions.
- Active Directory Users and Computers
- enable Advanced Features (view menu)
- Open properties of the AD account for failed user.
- Security tab -> Advanced button
- Check the "Include Inheritable permissions from this object's parent' checkbox.
For a quick check, I recommend doing two things:
- Make sure all of the objects that you mail-enabled match the CSV. We had an odd issue were the wrong GUID got applied to the wrong mailbox. Not a BIG deal as after migration, the missed GUID is still on premise and the wrong account now has the wrong displayname/email address. For example:
import-CSV .\csvpath | ?{(get-mailuser $_.exchangeguid).displayname -ne $_.displayname} - Make sure mail-enabled accounts are in OUs that are sync'd via AAD Connect.
import-CSV .\csvpath | %{get-mailuser $_.exchangeguid} | group organizationalUnit
No comments:
Post a Comment