Export Exchange Properties From Resource Forest.

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.

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:

1. #Name (name)
2. #DisplayName (displayname)
3. #SamAccountName (SamAccountName)
4. #WindowsEmailAddress (mail)
5. #PrimarySMTPAddress (from ProxyAddresses)
6. #LegacyExchangeDN (legacyExchangeDN)
7. #EmailAddresses (proxyaddresses)
8. #ExchangeGUID (msExchMailboxGUID)
9. #GrantSendOnBehalfTo (publicDelegates)
10. #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.

1.  $ExportNames = get-mailbox -organizationalunit "Finance" -resultsize unlimited
2.  .\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:

1. 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. 
2. 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. 
1. Active Directory Users and Computers
2. enable Advanced Features (view menu)
3. Open properties of the AD account for failed user.
4. Security tab -> Advanced button
5. Check the "Include Inheritable permissions from this object's parent' checkbox.

For a quick check, I recommend doing two things:

1. 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}
2. Make sure mail-enabled accounts are in OUs that are sync'd via AAD Connect.
   
   import-CSV .\csvpath | %{get-mailuser $_.exchangeguid} | group organizationalUnit

Migration from on-premise Exchange 2010 resource forest to EXO.

We've just finished a year long project migrating 80,000 mailboxes from our single on-premise Exchange 2010 solution, to multiple O365 tenants. The on-premise environment is/was an Exchange resource forest. This means that user's logged into their local authentication domain, then via AD trust, they gained access to their mailbox hosted with us.

The only difference to this diagram, instead of the Internet cloud, replace with a WAN cloud. Clients could only access mail via Outlook over the VPN to our data center. I plan to use this space to post each of the scripts that I generated for this project.

image source: MS Blog - you had me at ehlo

To migrate from shared-multi-tenant, on-premise resource forest Exchange environment to individual O365 tenants.

1. Create O365 tenant
2. Configure Authentication domain
1. Update AD to 2012 R2 or better. 
2. Install Exchange 2013/2016 
1. Clean-up legacy Exchange properties
2. Extend schema for Exchange
3. Install Exchange software
4. Remove SCP record reference for auto-discover
3. Cleanup 
1. Consolidate (if possible) OUs so that they are easy to manage.
2. Remove dead accounts.
3. Cleanup mailboxes in Exchange.
4. Update workstations so using latest Outlook (2013/2016) as available in Windows Update. Don't forget other Office applications.
5. Public Folders
3. Configure ADFS and AAD Connect to O365 tenant.
4. Do Mailbox Identity Sync
1. Export identity information from resource forest (RF). 
2. Import identity info into similar objects in account forest.
5. Sync mail enabled accounts and groups from account forest to O365.
1. Review mailboxes for permissions assigned to Auth domain security groups. Include these groups in the sync.
2. 
   
6. Migrate mailboxes from RF to O365.
1. Create migration end-point from O365 to Exchange on-premise
2. Create migration batches/move requests 
3. Monitor / complete move requests.
7. License mailboxes once migrated. 
1. Convert any resource mailboxes that came over as USERMAILBOX to shared/equipment so as to avoid using a mailbox license.
8. Create groups and external contacts in O365 tenant. 
9. Review/ fix shared mailbox permissions (security groups)

Updates:

• 3.14 - extended outline, added page for Identity Sync scripts.