Tagged: Exchange On-line

Staged migration from Exchange 2003 to Exchange online


The following prerequisites must be in place to carry out a staged migration.

  1. A directory sync server must be configured to synchronise on-premises users to Office 365. See here for instructions.
  2. Your Office 365 tenant organisation must have the domain of your on-premises organisation as an accepted domain i.e add the domain to Office 365 within the portal.
  3. Confirm Outlook anywhere is working on your on-premises Exchange deployment
    1. In my scenario I was migrating from Exchange 2003 and Outlook Anywhere was not configured. I used the guide here. The only comments I would make are the
    2. registry entry HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\RPC\RPCPROXY requires the NetBIOS name, internal FQDN and external FQDN (if they’re different) and NTLM authentication is required on the RPC virtual directory and within Outlooks proxy settings; these seems to be true when using Outlook 2010, I haven’t tested other clients.
    3. To confirm Outlook anywhere is working use the Microsoft Remote Connectivity analyser: https://testconnectivity.microsoft.com/OutlookAnywhere1
    4. OutlookAnywhere2
  4. Create an on-premisesuser who will be the migration administrator; this user can be either a domain admin or assign the user full access to the mailboxes and modify the writeProperty permission on the TargetAddress. The TargetAddress security can be modified using ADSIedit.
  5. Lower the TTL of the MX record for the domain you’re migrating.
  6. Tell the users that their mailbox is being migrated. Depending on your user base Outlook Web App may be suffice if not an autodiscover record should be created but could cause issues.
  7. Export the user account email addresses from Active Directory using csvde e.g. csvde -f c:\output.csv -r “(&(objectCategory=person)(objectClass=user)(mail=*email.domain.name))” -l “mail”. The default header is mail but for the migration it must be emailAddress.



Create a migration end point

Login to the Exchange Administration Center and select recipients, then migration, then the plus sign and migration to Exchange On-line.


Select staged migration.


Enter the credentials of the on-premises account which has access to all mailboxes being migrated; this is either the domain admin or the user created in prerequisite step no. 4.


Specify the internal FQDN of the Exchange server and RPC proxy i.e. the public FQDN used when connecting via Outlook Anywhere.


Name the migration e.g. maybe you’re migrating users with surnames A-G then maybe Exchange2003MailboxesAtoG.


The status of the migration can be viewed from within the Exchange Admin Center.


At this point the TargetAddress attribute of the users you’re migrating is modified to username@tenantname.onmicrosoft.com.


Depending on the size and number of items it may be best to plan migrations over a weekend or may be an evening would suffice e.g. in my experience a 3.8GB mailbox took around 3 hours over a 5Mb connection.

If your user would like to be able view new incoming emails straight away then point them to Outlook Web App, configure their mobile device to use Exchange On-line or configure a new Outlook profile to utilise the Exchange On-line. If you opt for a new Outlook profile a few points to remember:

  • Outlook 2010 or 2007 client needs to be at least SP1 and SP3 respectively
  • Outlook 2010 and earlier client require the desktop setup to be run; pretty sure this installation requires a reboot too.


  • An autodiscover record should exist too; existing users should not see any problems unless you  have to reconfigure their Outlook profile.

Once the migration is complete you’ll receive an email like the one below.


The migrated users’ on-premises mailbox-enabled accounts should be configured as mail-enabled accounts; Microsoft have a number of scripts to streamline this process which can be found here.

The script: ExportO365UserInfo.ps1 requires PowerShell to be installed, the synopsis of the script is as follows:

  • Create and connect to a remote session of Exchange On-line
  • Import the migrated users
  • Using the migrated users email address get the Exchange Distinguished name, cloud email address and on-premises email address
  • export the above to a csv.

The script: Exchange2003MBtoMEU.vbs requires the output of the PowerShell script above, Microsoft Exchange management tools and a FQDN of a domain controller. The synopsis of the script is as follows:

  • Import information from csv file created by the script above
  • Collect information from Active Directory
  • Adds x.500 addresses and distinguished names to a proxy list
  • Deletes the users mailbox
  • Mail enables user using information collected earlier

Once your batch is complete, delete it from the migration section of the Exchange Admin Center.

Final tasks

Switch MX to Exchange On-line; this can be viewed within the Office 365 portal. Login go to domains, select the domain, then select view DNS settings, then select View DNS records.


Upgrade to Exchange 2010 and then remove the Exchange 2003 installation. Guides on Microsoft TechNet:

Understanding upgrade from 2003 to 2010:


Removing Exchange 2003:


Office 365 – Manage Roles

Office 365 administrator roles

Billing Administrator – manages subscriptions, purchases, support tickets and service health.

Global Administrator – There can only be one, by default it is the person who signs up for Office 365. This administrator can assign other administrative roles.

Password Administrator – manages password resets, service requests and monitors service health. NOTE: This role cannot reset passwords for other administrative roles.

Service Administrator – manages service requests and monitor service health.

User Management Administrator – manage password resets, monitor service health, manage user accounts and groups and manage service requests. NOTE: This role cannot create administrative users nor can it reset the passwords of users with administrative role assignments.

Delegated Administration

Delegated administrators can create users, reset passwords and manage domains.

To enable delegated administration you need to send your customer a link in an email which will enable delegated administration; this is done via the partner page within the Office 365 portal.


Once the customer accepts you as a delegated administrator you’ll be listed within their delegated administrators. The global administrator of the partner Office 365 account can then decide how much administrative access you have over the partners.



To access a customers resources using your delegated credentials go to service settings from within your customers portal.


Within SharePoint you can grant your organisation as a support partner access to your customers SharePoint site collections.


Exchange role-based access control (RBAC) roles

Exchange role-based access control (RBAC) is used to grant administrative users specific privileges within Exchange and allow users to make changes to their personal settings e.g. mobile number.

RBAC can be assigned in 3 ways.

  1. Management role groups; these are used to assign a group of users administrative privileges within the organisation or for objects with a specific attribute.
  2. Management role assignment policies; these are used to assign users more or less privileges over their own mailbox. Only one management role assignment policy can be assign to any one mailbox at a time.
  3. Direct user role assignment; this is where a user account or universal security group would be granted access to a particular role without using a role group or role assignment policy.

The diagrams below show how RBAC components link together.

e.g the Discovery Management role group has management role assignments of Mailbox Search-Discovery Management and Legal Hold-Discovery Management. The assignments link the role group to the management roles Mailbox Search and Legal Hold, if you query those management role using PowerShell you’ll see which cmdlets are available e.g. Get-ManagementRoleEntry  “Mailbox Search\*”

The scope of the management role assignment can be the organisation or a specific attribute e.g. the office attribute equal to “some location” e.g. New-ManagementScope -Name “Ossy Branch” -RecipientRestrictionFilter {Office -eq “Ossy”} If you wanted to protect who could manage mail recipients in the Office location of Ossy, you could make the scope exclusive.

Once the scope is created you would also create New-DistributionGroup as a universal security group (USG) and a New-RoleGroup which defines the Branch e.g.

New-DistributionGroup -Name “Ossy Admins” -Alias OssyAdmins -Type Security

New-RoleGroup “Oswaldtwistle Recipient Admins”

Finally to link together your role group and management role you would create a role assignment defining the scope created earlier e.g.

New-ManagementRoleAssignment -Name “Oswaldtwistle Recipient Admins-Mail Recipients” -Role “Mail Recipients” -SecurityGroup “Oswaldtwistle Recipient Admins” -CustomRecipientWriteScope “Ossy Branch”

Users are now made a member of the USG OssyAdmins would be able to manage recipients who have the Office attribute equal to Ossy.

A custom management role must have a builtin parent role, and cannot have more rights than its parent role i.e. access to more cmdlets. Every role with a Remove- or Set- cmdlet must have a respective Get- cmdlet.

Management Role Assignment

The management role assignment policies are assigned to end users and allow them to manage their own mailboxes and distribution groups; you can introduce new functionality or remove functionality by creating new management role assignment policies, modifying the role assignments and assigning that new policy to a mailbox.

A mailbox can only have one role assignment policy and can only contain roles which are scoped to the end user i.e. start with My…

To view the role assignment assigned use PowerShell to query the management role assignment that are part of the default role assignment policy e.g.

Get-ManagementRoleAssignment | ? {$_.RoleAssigneeName -eq “Default Role Assignment Policy”} | Select-Object Name, RoleAssigneeName

Management Role Assignment Policy