Migration from Office 365 or Microsoft 365 mailboxes to G Suite using the G Suite Data Migration Service

Supported Environment

Microsoft 365, Office 365, Exchange 2016, 2013, 2010, 2007 or 2003.

Supported G Suite

G Suite Enterprise, Business, Basic, and Education accounts

G Suite Cost

Standard prices are shown. Google occasionally offers special discounts to some customers for both the Flexible and Annual Plan.

 Flexible PlanAnnual Plan
CommitmentNone1 year of service for licenses purchased at the start of the contract.
Billing cycle MonthlyMonthly
Monthly paymentG Suite Basic: USD 6 per user
G Suite Business: USD 12 per user
G Suite Enterprise: USD 25 per user
G Suite Basic: USD 6 per license
G Suite Business: USD 12 per license
G Suite Enterprise: USD 25 per license
Yearly totalG Suite Basic: USD 72 per user
G Suite Business: USD 144 per user
G Suite Enterprise: USD 300 per user
G Suite Basic: USD 72 per license
G Suite Business: USD 144 per license
G Suite Enterprise: USD 300 per license
Add usersAt any time for additional monthly costAt any time for additional monthly cost
Remove usersAt any time (reduces monthly cost)Only when you renew the annual contract. Until then, you pay for all purchased licenses.
Cancel serviceAt any time without a penaltyMust pay annual commitment (even if you cancel early).

Outlook requirements

Step1: Setup G Suite

To setup G Suite, you need three basic information and privilege to prove ownership of your domain.

  • Primary domain, e.g. mydomain.com
  • Verify Domain. When you sign up for G Suite, you can choose which type of verification record such as TXT, CNAME, MX record you want to use in the Setup Wizard.
  • personal username such as user1@mydomain.com
  • An email address which can be gmail email and can be changed later.

G Suite MX setup for your domain host

  1. Sign in to your domain’s account at your domain host.
  2. Need help? Contact your domain host’s Support team. Domain hosts are experts with MX records, and setup is a common task.
  3. Go to the section where you can update your domain’s MX records. It might be called something like “DNS Management,” “Mail Settings,” or “Advanced Settings.”
  4. Delete any existing MX records.
    If you can’t delete the existing records, change their priority number to 20 or higher.
  5. Add new MX records for the Google mail servers.

If your domain host limits the number of MX records, just add the first 2 records in this table.

Values for G Suite MX records

Name/Host/Alias Time to Live (TTL*) Record Type Priority Value/Answer/Destination
@ or leave blank 3600 MX 1 ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 5 ALT1.ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 5 ALT2.ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 10 ALT3.ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 10 ALT4.ASPMX.L.GOOGLE.COM.
  • Skip this step if you already verified your domain by another method (such as TXT record, HTML file, or meta tag).
  • Save your changes.

Step2: Test G Suite Email

  1. Sign in to admin.google.com with your G Suite username and password. 
  2. In the top right corner, click the App Launcher, Mail.

Step3 (optional): Setup Google Cloud Directory Sync (GCDS)

Setup Directory Sync to use existing authentication or on-premises Windows Domain Controller users.  With Google Cloud Directory Sync (GCDS), you can synchronize the data in your Google domain with your Microsoft® Active Directory® or LDAP server. Your Google users, groups, and shared contacts are synchronized to match the information in your LDAP server. 

Systems Requirements:

  1. Download GCDS
  2. A Google domain.
  3. Access to a Google domain super administrator account to authorize GCDS.
  4. Microsoft® Windows® (supported on Windows 7, Windows 8, Windows 10, Windows Server 2008/2012/2016).
  5. Linux®—If you’re using a 32-bit version of GCDS on a 64-bit Linux system, a 32-bit libc (such as libc6-i386) must be installed.
  6. Administrator access to your Google domain.
  7. LDAP administrator access to your directory server and familiarity with its contents as well as familiarity with the LDAP query language.
  8. Network administrator privileges and familiarity with your network and security settings for internal and outbound traffic.

Enable Authentication in Google Configuration Manager in Google Domain

Authorize access using OAuth

  1. Open Configuration Manager and click the Google Domain Configuration page.
  2. Click Authorize Now to set up your authorization settings and create a verification code.
  3. Click Sign In to open a browser window and sign into your Google domain with your super administrator username and password.
  4. Copy the token that’s displayed.
  5. In the Verification Code field, enter the token and click Validate.

Allow API Access in Google Admin Console

  1. Sign in to your Google Admin console.
  2. Sign in using your administrator account (does not end in @gmail.com).
  3. From the Admin console Home page, go to Security>API reference.
  4. To see Security on the Home page, you might have to click More controls at the bottom.
  5. Make sure the Enable API access box is checked.
  6. At the bottom, click Save.

Configure GCDS

  1. The simplest way to configure GCDS is to record credentials for Google Domain, On-premises Active Directory.
  2. Connect Google Domain and On-premises Active Directory
  3. Test connection
  4. Select an Organizational unit of Active Directory to Sync to Google Domain
  5. You’re done.

Step4: Assign Licenses

On the Licenses page of Configuration Manager, set up the GCDS license synchronisation for users in your Google domain.

If you have purchased different product SKUs for your domain, you may want to disable auto license assignment and use the GCDS license synchronisation feature to manage licenses for your Google user accounts. You should manage user license assignment using a single method. Either assign and manage product licenses through the Admin console or use the GCDS license synchronisation feature described here.

Additional Guide:

Step5 (optional): Setup Mailflow Co-existence between Office 365 and G Suite

Follow this guide to setup mailflow co-existence between Office 365 and G Suite.

Step6: Migrate email from Microsoft Exchange or Office 365

  1. Sign in to your Google Admin console.
  2. . Sign in using your administrator account (does not end in @gmail.com).
  1. From the Admin console Home page, go to Data migration. To see Data migration, you might have to click More controls at the bottom.
  2. Select the Email option and click Continue.
  3. On the Email Migration screen:
    1. From the Migration source list, select the Microsoft Exchange or Office 365 mail server that matches your legacy environment (where you’re migrating from). 
    2. Select the connection protocol of the legacy mail server by choosing an option:
      • To automatically determine the protocol, select Autoselect (Recommended).
      • To specify the Exchange Web Services URL for your legacy service, select Exchange Web Services and type the URL. The URL is the is the address that Exchange uses to communicate with Exchange Web Services, for example, https://outlook.office365.com/EWS/Exchange.asmx.
    3. Enter the email address and password for your role account.  
  4. Click Connect
  5. (Optional) If the connection fails, verify that the role account and connection protocol information is correct. Then, click Connect again. 
  6. In the Migration start date and Migration options sections, accept the default options or choose to exclude data that doesn’t need to be migrated. 
  7. Click Select Users.

Step7: Migrate a test email for a single user

  1. Complete the steps to set up the data migration service.
  2. Hover over Add and click Select user .
  3. In the Migrate From field, enter the user’s Exchange email address.
  4. In the Migrate To field, start typing the user’s new G Suite email address and choose from the list of suggested users. 
  5. Click Start.
  6. (Optional) To migrate another user’s email, repeat these steps. 
  7. To exit a completed migration, click Settings > Exit migration

Step8: Migrate email for multiple production users

  1. Complete the steps to set up the data migration service.
  2. Hover over Add and click Select multiple users.
  3. Click Attach File to upload a CSV file containing the legacy email addresses and the new G Suite email addresses. For details on how to format the file, see Use CSV files with the data migration service.
  4. Click Upload and start the migration.
  5. If there are errors in your file, choose an option:
    • To update the file, click Cancel, fix the file, and reload the updated file.
    • To ignore the incorrect mappings, check the Ignore errors box.

Notes: Formatting the CSV files

You can use a spreadsheet application, such as Google Sheets or Microsoft Excel®, or a text file to create the CSV file. Data in your CSV file is case-sensitive: make sure to use the correct case for emails, passwords, usernames, and resources.

Don’t include headers or use commas to separate the fields. Use line breaks to separate each entry.

Example CSV File


In this example, you’re migrating john.doe@microsoftdomain.onmicrosoft.com (office 365) to john.doe@googledomain.com (G Suite) with a calender1 of Office 365.

Decide on Office 365 Migration Path

Deciding on the best migration path of your users’ email to Office 365 can be difficult. Your migration performance will vary based on your network, existing messaging systems design, mailbox size, migration speed, and so on.


For migrations from an existing on-premises Exchange Server environment, you can migrate all email, calendar items, tasks and contacts from user mailboxes to Office 365. The available methods are cutover, staged, and Exchange Hybrid migrations.

For migrating third-party email to Office 365, you can configure mail flow coexistence if the third-party email provider permits then migrate the mailboxes using IMAP or cutover migration options.

Migrating from Exchange 2003 or Exchange 2007

Number of mailboxes How quickly do you want to migrate? Use
Fewer than 150 Over a weekend or a few days. Cutover
Fewer than 150 Slowly, by migrating a few users at a time. Staged
Over 150 Over a weekend or a few days. Staged
Over 150 Slowly, by migrating a few users at a time. Staged

Migrating from Exchange 2010 or Exchange 2013 or Exchange 2016 or Exchange 2019

Number of mailboxes How quickly do you want to migrate? Use
Fewer than 150 Over a weekend or a few days. Cutover
Fewer than 150 Slowly, by migrating a few users at a time. Exchange Hybrid
Over 150 Over a weekend or a few days. Exchange Hybrid
Over 150 Slowly, by migrating a few users at a time. Exchange Hybrid

Migrating from third-party email system to Office 365

Number of mailboxes How quickly do you want to migrate? Use
Fewer than 150 Over a weekend or a few days. Cutover
more than 150 Slowly, by migrating a few users at a time. IMAP with mail flow coexistence

If the mailboxes you’re migrating contain a large amount of data, you can also use Office 365 Import Service to import PST files to Office 365.

Migrate On-premises Exchange Server to Office 365 using MigrationWiz


  • An operational on-premises Microsoft messaging environment or an IMAP Source
  • An operational Microsoft Office 365 tenant for Exchange Online
  • Active Directory synchronised with Microsoft Azure Active Directory using DirSync
  • Licenses are assigned to Active Users.
  • There are place holder mailboxes e.g. user@tenant.onmicrosoft.com or real mailboxes e.g. user@domain.com as destination mailboxes.

Credit: BitTitan knowledge Base Articles. KBs mentioned here are BitTitan KBs not Microsoft KB.

Prepare Source: Exchange Environment

  1. Set up an administrator account “Domain\MigrationWiz” for migration on the Source Exchange mailbox server. Grant Domain Admins and Organisation Management Role for this Admin Account. KB004944
  2. Test OWA using https://mail.domain.com/owa. KB004392
  3. Test mailbox access. KB004616
  4. Disable the Exchange throttling policy during migration. KB004945
  5. Allow impersonation by MigrationWiz account

New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:MigrationWiz

  1. Grant Full Access to MigrationWiz Admin Account for all mailboxes

Get-Mailbox -Resultsize Unlimited | Add-MailboxPermission -User MigrationWiz -AccessRights FullAccess -InheritanceType All

  1. Enable Circular Logging on the Mailbox Database properties. De-mount Mailbox Database and remount mailbox database after running the below command.

Get-MailboxDatabase | Set-MailboxDatabase -CircularLoggingEnabled $true

  1. Grant higher CPU and Memory to the source Server.
  2. Allocate minimum 50MB/s to 100MB/s bandwidth to outgoing network from on-premises Exchange Environment to internet
  3. Allow outbound Office 365 Ports and URLs on the firewall devices

Prepare the Destination: Exchange Online Environment

  1. Create an administrator account “MigrationWiz@tenant.onmicrosoft.com” in Office 365 to be used for migration, or use the global admin account for the tenant. KB004948
  2. If Microsoft DirSync was used to create and synchronize the local AD accounts up to Office 365, remember to disable it prior to using MigrationWiz. KB004336

Note: BitTitan recommend stopping DirSync during migration however I have migrated mailboxes without stopping DirSync. You must not change mail attribute and UPNs of any Active Directory Account during migration phase. You can do it later using PowerShell Cmdlets in bulk.

  1. Set up accounts on Office 365 and assign licenses. These can be created in several ways:
    • By bulk import using PowerShell via CSV file input.
    • By Microsoft DirSync. Read this very important Knowledge Base article before running Microsoft DirSync, to see if it should be run prior to migration. KB004336
    • By BitTitan Sync tool. KB004336
  2. Prepare tenant to send and receive large mail items. KB005139
  3. Contact Microsoft to ask to have the tenant EWS throttling limits raised for 60 days. Note: This step is only required if your Source environment will support migration speeds that are faster than the Destination. KB005493
  4. Allow impersonation by MigrationWiz Account

New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:MigrationWiz@tenant.onmicrosoft.com

  1. Grant Full Access Permission to MigrationWiz Account

Create a CSV file with these CSV Headers

name, user

mailbox1@domain.com, MigrationWiz@tenant.onmicrosoft.com

mailbox2@domain.com, MigrationWiz@tenant.onmicrosoft.com

$Mailboxes = import-csv C:\CSV\FullAccess.csv

Foreach ($Mailbox in $Mailboxes)

{Add-MailboxPermission -Identity $Mailbox.Name -user $Mailbox.User -AccessRights ‘FullAccess’ -InheritanceType All}

 Migrating On-premises Mailbox to Office 365 using MigrationWiz

Buy Licenses

Note: This step can be completed by a re-seller. You must provide company email address (migrationadmin@company.com ) to associate your company with MigrationWiz Portal. This Email Address is the log on details of Migration Admin who will perform the migration task.

  1. Create the customer. KB005421
  2. Create the Source and Destination endpoints. KB005427
  3. Purchase licenses. From your MSPComplete dashboard, click on Purchase > Mailbox Migration > select MigrationWiz-Mailbox and enter the number of licenses you wish to purchase. Check to see if there are any available bundles for discounts (e.g., MigrationWiz-Mailbox and DeploymentPro Bundle). KB004647
  4. Deploy DMA to users. Once DMA has been deployed to users, check the Users tab in MSPComplete. This will be populated with the user accounts that have DMA installed. DMA can be deployed by either of these options:
  5. Via Group Policy Object (GPO). Note: This is the recommended methodology, because no end user interaction is required. KB005412, KB005411


Pre-stage Mailboxes

  1. Create the Mailbox Migration project. KB005070. Create the Mailbox Migration project > Select the customer > Select the Source endpoint > Select the Destination endpoint. Add the accounts (also referred to as “items”) that will be migrated to the project. KB004842
  1. Set the Project Advanced Options. KB004834
  • Set to use impersonation at the Destination. Checkmark the Use impersonation at Destination box. KB004727
  • Set Maximum concurrent migrations e.g. 500. If the Source server has enough server resources, set this parameter based on the bandwidth guideline of three (3) mailboxes per 1Mbps of bandwidth. Therefore, for example, if there is a 10Mbps connection, we recommend setting the maximum concurrent migrations parameter to be 30.
  • Set maximum error to 100.
  • Set successful and failed migration report to migrationadmin@company.com . Do not send a report to end user. This may cause confusion among users when you run credential checks and run pre-stage.
  1. Select the Project> Bulk Add using CSV file. CSV Headers

Source Email,Source Login Name,Source Password,Destination Email,Destination Login Name,Destination Password,Flags

Note: Since MigrationWiz has full access rights to source email and destination email. There is no need to populate password on the password column.







  1. Run Verify Credentials for all mailboxes. KB004511
  2. Notify users that a migration is occurring. Send email to all users telling them the time and date of the migration.
  3. Pre-Stage pass: Select the users > Click on the Start button from the top, and select Pre-Stage Migration > Under the Migration Scheduling section, from the drop-down list, select 30 days ago > Click on Start Migration. KB004938
  4. If you notice any failed migration, just filter those failed migration> Pause Failed Migration. Select all Paused migration>Pre-stage all paused migration to complete migration simultaneously instead of waiting for migration to complete and retry error.

m2   m5










Final Migration or MX Cutover

  1. MX Record Cutover. Change over MX records on the DNS provider’s portal. Also include the AutoDiscover (CName) setting.
  2. Full (Delta) pass: Select the users > Click on the Start button from the top, select Full Migration > Click on Start Migration. KB004938
  3. Run Retry Errors. KB004658
  • Look through the user list and click on any red “failed migration” errors. Review information and act accordingly.
  • If problems persist, contact Support. KB004529
  • If not using DeploymentPro, users must create new Outlook profiles, and set up their signatures again, and reattach any PST files that were attached to their previous profile.
  1. Click on the pie chart icon in the MigrationWiz dashboard to receive an email containing all the project migration statistics. KB004626

Outlook Client Migration to new Office 365

DeploymentPro Steps

  1. Go to All Products > DeploymentPro and follow the prompts to launch.
  2. Select a customer from the list by clicking on the customer name. Note: The status column will show enabled when a customer account has had DMA deployed. Configure customer DeploymentPro module:
  • Enter Domain.
  • Select the Source endpoint.
  • Checkmark the Auto-populate box.





Note: In the Client Interface Configurations section, upload your company logo and add supporting text. Note: We strongly recommend doing this, because this is the logo and text that end users will see in a desktop pop-up when they are prompted to reconfigure their Outlook profiles. If you do not upload your own logo, the default BitTitan logo will be included instead.

  1. Save and continue.
  2. Activate DeploymentPro module for users.
  3. Either select all users (by checkmarking the box to the left of the Primary Email column heading), or select the individual users (by checkmarking the boxes to the left of the user email addresses). Note: You will need to purchase DeploymentPro licenses for each user that will be using DeploymentPro. KB004647
  4. Click on the Run Module button.
  5. Schedule the profile cutover date.
  6. Set the date and time for the Outlook profile configuration to occur, and click on the Run Module button.


  • The DeploymentPro module will install on user devices immediately, and then run silently until this date.
  • The profile cutover date should be set to a date and time that is shortly after MX record cutover.
  • On the profile cutover date, users will be guided through the reconfiguration of their Outlook profile.


On-prem to Office 365 Migration: PowerShell Script Collection

On-Premises Exchange (versions 2007 and later) to Office 365 Migration Guide

Mailflow Co-existence between Hosted Mail and Office 365 during IMAP Migration

Mailflow Co-existence between G Suite and Office 365 during IMAP Migration

This article will explain how to create mail flow coexistence between disparate IMAP source and Exchange Online destination.

Use case:

  1. Customer wants a mailflow co-existence between hosted email e.g. Gmail and Exchange Online during mailbox migration phase.
  2. Customer has on-premises Exchange Server but does not want to create hybrid environment or have a situation where hybrid configuration is not feasible.
  3. Customer plans to migrate mailboxes, calendar, contacts, resources and distribution groups to Exchange Online in phases.
  4. Customer does not want a cutover migration to Exchange Online.

Source Environment:

  1. Email Domain: Domain.com
  2. Migration Method: IMAP
  3. Source Infrastructure: On-premises Microsoft Exchange or Hosted Gmail

Destination Environment:

  1. Office 365 Tenant: domain.onmicrosoft.com
  2. Default Domain: domain.onmicrosoft.com
  3. Email Domain: Domain.com
  4. CatchAll Domain or Subdomain: subdomain.domain.com

Migration Method:

  • Pre-stage: In pre-stage migration, data will be pre-filled to a place holder mailbox then migrate delta changes.
  • Backfill: In backfill method, data will be back filled to a real mailbox after cutover.

Prepare Source Email Domain:

  1. Add Proxy address or alias to all mailboxes.

To add proxy address, create a CSV file with the below header and run the scripts

Name, EmailAddress

User1@domain.com, user1@domain.onmicrosoft.com

Import-Csv c:\data.csv | Foreach{

$maileg = Get-Mailbox -Identity $_.Name

$maileg.EmailAddresses += $_.emailaddress

$maileg | Set-Mailbox -EmailAddresses $_.emailaddress


  1. Create target address or forwarding address to all mailboxes. To add target address, create a CSV file with the below header and run the script

CSV Headers are Mailbox, ForwardTo

User1@domain.com, user1@domain.onmicrosoft.com

user1@domain.com, user1@subdomain.domain.com

Import-CSV “C:\CSV\Users.csv” | ForEach {Set-Mailbox -Identity $_.mailbox -ForwardingAddress $_.forwardto}

  1. Send & Receive Connector

If you have strict mailflow condition on the on-premises environment or hosted environment, you may have to create a send connector and receive connector to allow Office 365 email in both directions.

  1. MX record still pointed to source environment.

Prepare Exchange Online

  1. Create Office 365 tenant: domain.onmicrosoft.com
  2. Add customer domain e.g. domain.com on the Office 365 portal and validate the domain
  3. Go to Office 365 ECP, Select Mailflow, Click Accepted Domain, Select Domain.com, Click Edit and set the domain to Internal Relay
  4. Go to Office 365 ECP, Select Recipient, Go to Groups, Create a distribution group and add all users to the distribution group. To find a script to do the job, refer to step3 of post migration section of this article. replace remove-distributiongroupmember to add-distributiongroupmember on the script.
  5. Go to Office 365 ECP, Select Mailflow, Connectors, create an Outbound Send Connector to send email from Office 365 to Your organisation email server. When creating this Connector select the smart host option and on the smart host window, type the Public IP Address or FQDN of MX record of domain.com
  6. Go to Office 365 ECP, Select Mailflow, Rules, create a rule to forward any inbound emails coming to @domain.com and member of special distribution group created in step 4 to be forwarded to the send connector you have created in previous steps 5.
  7. Enable Mailflow for subdomain or catchall domain i.e. @subdomain.domain.com Set-AcceptedDomain -Identity domain.com -MatchSubdomains $true

Mailflow during migration phase

When an Exchange Online mailbox user1@domain send mail to user2@domain.com (On-premises/hosted Gmail), as user2 does not exist at Exchange Online side, and the domain: domain.com set as “Internal Relay” under “Accept domain” configuration, so the message will delivery to on-premises/Gmail through special outbound connector.

Post Migration:

Once you have migrated a batch of mailboxes, you have to remove proxy address and forwarding address from that batch of source mailboxes on the source email domain.

  1. Remove Proxy Address from Source Environment

CSV Headers are Name and EmailAddress

User1@domain.com, user1@domain.onmicrosoft.com

Import-Csv C:\CSV\ProxyAddress.csv | Foreach{

$maileg = Get-RemoteMailbox -Identity $_.Name

$maileg.EmailAddresses += $_.emailaddress

$maileg | Set-Mailbox -EmailAddresses @{Remove=$_.EmailAddress} }


  1. Remove Forwarding address from Source Environment

CSV headers are Mailbox, ForwardTo

User1@domain.com, user1@domain.onmicrosoft.com

Import-CSV “C:\CSV\Users.csv” | ForEach {Set-Mailbox -Identity $_.mailbox -ForwardingAddress @{Remove=$_.forwardto}}

  1. Remove the batch of mailboxes from the distribution groups once migrated to Office 365.

CSV Headers are

Identity, Members

Accounts, user1@domain.com

Import-Csv “C:\CSV\RemoveMembers.csv” | foreach{Remove-DistributionGroupMember -Identity $_.identity -Member $_.members}

  1. Delete special Distribution Group, Maiflow rule and Outbound Connector created on the step 4, step 5 and step 6 after MX record cutover to Office 365.


Rename Domain with Exchange 2007/2010 not feasible! an alternative solutions

Recently my company registered a new domain name and wanted to me to investigate best possible way to rename domain internally, change websites (hosted on IIS) publicly accessible CNAME to new domain name and change email address for entire organization. Fun hahh!! Google search appears that domain rename possible in win2k3 AD and exchange 2003 SP1.  However, according to Microsoft TechNet I can not rename Windows 2008 native domain with Exchange 2007 . what happen to those who are in the following situation:

  • Rename Business registration
  • Merger and/or Acquisition between companies
  • Change of ownership

If your management decide to have new user account@newdomain, email addresses@newdomain and websites with new domain name. Now you will not have a choice but  find out a solution regardless of who says what. In this article (Ref: Plan A), I will investigate and share with you what happen if you rename domain on a test environment similar to my organisation i.e. Microsoft Active Directory 2008 and Exchange 2007/2010. Those who are in my situation, I will explain (Ref: Plan B) how I can accomplish same objectives with alternative deployment that means without messing around AD domain and Exchange 2007/2010.  I know plan A is going to fail but worthwhile to produce documents to management and go for plan B. So that business runs smoothly. when time perfect and fund is available then rebuild Microsoft messaging systems for entire organization.

Light bulbDo NOT perform these steps in a production environment. Domain rename is NOT supported when Exchange 2007/2010 installed in a member server.

Rename Domain on a Testbed


  • Rename Domain
  • Migrate IIS to new domain
  • Fix GPO and Exchange (only applicable for Exchange 2003)



Steps involve:

  • Set up your control station for the domain rename operation.
  • Freeze the Forest Configuration
  • Back up all the domain controllers in your forest.
  • Generate the current forest description.
  • Specify the new forest description.
  • Generate domain rename instructions
  • Push domain rename instructions to all domain controllers, and verify DNS readiness.
  • Verify the readiness of the domain controllers.
  • Execute the domain rename instructions
  • Update the Exchange configuration, and restart the Exchange servers (Only applicable for Exchange 2003 SP1)
  • Unfreeze the forest configuration
  • Re-establish external trusts
  • Fix Group Policy objects (GPOs) and links.

Precaution: Use the following link for Active Directory Backup and Restore in Windows Server 2008  or keep your resume handyWink

To verify the forest functionality to Windows Server 2008

  1. Open Active Directory Domains and Trusts.
  2. In the scope pane, right-click Active Directory Domains and Trusts and then click Raise Forest Functional Level.
  3. In the Select an available forest functional level box, click Windows Server 2008, and then click Raise.
  4. Click OK to raise the forest functionality, and then click OK again.


To analyze and prepare DNS zones for domain rename

  1. Compile a list of DNS zones that need to be created.
  2. Use the DNS MMC snap-in to create the required DNS zones compiled in step 1.
  3. Configure DNS zones according to “Add a forward lookup zone” in Windows Server 2008.
  4. Configure dynamic DNS update according to “Allow dynamic updates” in Windows Server 2008.

To generate the current forest description file

In windows server 2008, rendom and GPFix utility are available in %Windir%system32 folder. If you change your directory into c:Windowssystem32 and run rendom /list then domainlist.xml will be placed in same directory.

  1. On the control station, open a command prompt and change to the X:DomainRename directory.
  2. At the command prompt, type rendom /list the following command and press ENTER:
  3. Save a copy of the current forest description file (domainlist.xml) generated in step 2 as domainlist-save.xml for future reference by using the following copy command: copy domainlist.xml domainlist-save.xml


To edit the domainlist.xml file

  1. Using a simple text editor such as Notepad.exe, open the current forest description file domainlist.xml generated in “STEP 3: Generate the Current Forest Description” earlier in this document.
  2. Edit the forest description file, replacing the current DNS and/or NetBIOS names of the domains and application directory partitions to be renamed with the planned new DNS and/or NetBIOS names.



To review the new forest description in domainlist.xml

At the command prompt, type the following and then press ENTER: rendom /showforest

To generate the domain rename instructions and upload them to the domain naming master

  1. On the control station, open a command prompt.
  2. From within the X:DomainRename directory, execute the following command: rendom /upload
  3. Verify that the domain rename tool created the state file dclist.xml in the directory X:DomainRename and that the state file contains an entry for every domain controller in your forest


To discover the DNS host name of the domain naming master

  1. On the control station, open a command prompt.
  2. At the command prompt, type the following and then press ENTER: Dsquery server –hasfsmo name

To force synchronization of changes made to the domain naming master

The following procedure forces the Active Directory changes initiated at the Domain Naming master DC in STEP 4 to replicate to all DCs in the forest.

  1. On the control station, open a command prompt.
  2. At the command prompt, type the following and then press ENTER: repadmin /syncall /d /e /P /q DomainNamingMaster

where DomainNamingMaster is the DNS host name of the domain controller that is the current domain naming master for the forest.

To verify the readiness of domain controllers in the forest

1. On the control station, open a command prompt and change to the X:DomainRename directory

2. At the command prompt, type the following command and then press ENTER: rendom /prepare

3. Once the command has finished execution, examine the state file domainlist.xml to determine whether all domain controllers have achieved the

To execute the domain rename instructions on all domain controllers

  1. On the control station, open a command prompt.
  2. At the command prompt, type the following and then press ENTER: rendom /execute
  3. When the command has finished execution, examine the state file domainlist.xml to determine whether all domain controllers have reached either the Done state or the Error state.
  4. If the domainlist.xml file shows any DCs as remaining in the Prepared state, repeat step 2 in this procedure as many times as needed until the stopping criterion is met.


To force Rendom /execute to re-issue the RPC to a DC in the Error state

  1. In the domainlist.xml file, locate the <Retry></Retry> field in the domain controller entry for the DC that you believe should be retried.
  2. Edit the domainlist.xml file such that the field reads <Retry>yes</Retry> for that entry.
  3. The next execution of the rendom /execute command will re-issue the execute-specific RPC to that DC.

To fix up DFS topology in every renamed domain

On the control station, open a command prompt. For each Dfs root, if any of the topology components as described above needs to be fixed, type the following command (the entire command must be typed on a single line, although it is shown on multiple lines for clarity) and press ENTER:

dfsutil /RenameFtRoot /Root:DfsRootPath /OldDomain:OldName /NewDomain:NewName /Verbose


DfsRootPath is the DFS root to operate on, e.g., \microsoftguru.com.aupublic.

OldName is the exact old name to be replaced in the topology for the Dfs root.

NewName is the exact new name to replace the old name in the topology.

To fix up Group Policy in every renamed domain

  1. On the control station, open a command prompt and change to the X:DomainRename directory.
  2. At the command prompt, type the following command (the entire command must be typed on a single line, although it is shown on multiple lines for clarity) and press ENTER:

gpfixup /olddns:OldDomainDnsName /newdns:NewDomainDNSName /oldnb:OldDomainNetBIOSName

/newnb:NewDomainNetBIOSName /dc:DcDnsName 2>&1 >gpfixup.log


OldDomainDnsName is the old DNS name of the renamed domain.

NewDomainDnsName is the new DNS name of the renamed domain.

OldDomainNetBIOSName is the old NetBIOS name of the renamed domain.

NewDomainNetBIOSName is the new NetBIOS name of the renamed domain.

DcDnsName is the DNS host name of a domain controller in the renamed domain, preferably the PDC emulator, that successfully completed the rename operation with a final Done state in the dclist.xml state file in “STEP 8: Execute Domain Rename Instructions” earlier in this document.

For example,

gpfixup /olddns:wolverine.com.au /newdns:microsoftguru.com.au /oldnb:wolverine /newnb:microsoftguru /dc:dc.wolverine.com.au 2>&1 >gpfixup1.log


To force replication of the Group Policy fix-up changes made at the DC named in DcDNSName in above step of this procedure to the rest of the DCs in the renamed domain, type the following and then press ENTER: repadmin /syncall /d /e /P /q DcDnsName NewDomainDN


DcDnsName is the DNS host name of the DC that was targeted by the gpfixup command.

NewDomainDN is the distinguished name (DN) corresponding to the new DNS name of the renamed domain.

Repeat steps  in this procedure for every renamed domain. You can enter the commands in sequence for each renamed domain.

For Example, repadmin /syncall /d /e /P /q dc.microsoftguru.com.au dc=microsoftguru,dc=com, dc=au 

To update the DNS name of the CA machine

  1. On the CA machine, open registry editor and locate the entry CAServerName under HKLMSystemCurrentControlSetCertSvcConfigurationYourCAName.
  2. Change the value in CAServerName to correspond to the new DNS host name.

To update the Web enrolment file

To enable proper Web enrollment for the user, you must also update the file that is used by the ASP pages used for Web enrollment. The following change must be made on all CA machines in your domain.

1. On the CA machine, search for the certdat.inc file (if you have used default installation settings, it should be located in the %windir%system32certsrv directory).


2. Open the file, which appears as follows:



<%’ CODEPAGE=65001 ‘UTF-8%>

<%’ certdat.inc – (CERT)srv web – global (DAT)a

‘ Copyright (C) Microsoft Corporation, 1998 – 1999 %>

<% ‘ default values for the certificate request






‘ global state

sServerType=”Enterprise” ‘vs StandAlone




‘ control versions




3. Change the SServerConfig entry to have the NewDNSName of the CA machine.

To perform attribute clean up after domain rename

  1. On the control station, open a command prompt.
  2. At the command prompt, from within the X:DomainRename directory, execute the following command: rendom /clean
Command-line usage to run XDR-fixup.exe

XDR-fixup.exe /s:start_domainlist.xml /e:end_domainlist.xml [/user:username /pwd:password | *] [/trace:tracefile] /changes:changescript.ldf /restore:restorescript.ldf [/?]

Note This command is one line. It has been wrapped for readability.

Command-line usage to verify XDR-fixup.exe

Use the following command line to verify the changes that are made by XDR-fixup.exe:

XDR-fixup /verify:restorescript.ldf /changes:verifycorrections.ldf

To unfreeze the forest configuration

From within the X:DomainRename directory, execute the following command: rendom /end

To force remove domain member if fails to join new domain using following command. Then re-join domain manually.

netdom remove <machine-name> /Domain:<old-domain> /Force”

To use Control Panel to check for primary DNS suffix update configuration for a computer

The following procedures explain two ways to view the setting for a member computer that determines whether the primary DNS suffix changes when the name of the membership domain changes.

1. On a member computer, in Control Panel, double-click System.

2. Click the Computer Name tab and then click Change.

3. Click More and then verify whether Change primary domain suffix when domain membership changes is selected.

4. Click OK until all dialog boxes are closed.

To use the registry to check for primary DNS suffix update configuration for a computer

1. On the Start menu, click Run.

2. In the Open box, type regedit and then click OK.

3. Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters.

4. Verify whether the value of REG_RWORD SyncDomainWithMembership is 0x1. This value indicates that the primary DNS suffix changes when the domain membership changes.

To determine whether Group Policy specifies the primary DNS suffix for a computer

  1. On a member computer, perform one of the following steps:
  2. At a command prompt, type gpresult. In the output, under Applied Group Policy objects, check to see whether Primary DNS Suffix is listed.

Open the Resultant Set of Policy Wizard, as follows:

In Active Directory Users and Computers, right-click the computer object, click All Tasks, and then click Resultant Set of Policy (Logging).

Open a command prompt and then type: ipconfig /all

Check the Primary DNS Suffix in the output. If it does not match the primary DNS suffix that is specified in the System Control Panel for the computer (see “To use Control Panel to check for primary DNS suffix update configuration for a computer” earlier in this document), then the Primary DNS Suffix Group Policy is applied.

u In the registry, check for the presence of the entry Primary DNS Suffix under HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemDNSclient. If a value is present, then the Primary DNS Suffix Group Policy is applied to the computer.

To install Support Tools

1. On the Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition operating system CD, double-click the Support folder.

2. In the Support folder, double-click the Tool folder and then run suptools.msi.

To use ADSI Edit to add DNS suffixes to msDS‑AllowedDNSSuffixes

The attribute msDS‑AllowedDNSSuffixes is an attribute of the domain object. Therefore, you must set DNS suffixes for each domain whose name is going to change.

1. On the Start menu, point to Programs, Windows Server 2003 Support Tools, Tools, and then click ADSI Edit.

2. Double-click the domain directory partition for the domain you want to modify.

3. Right-click the domain container object, and then click Properties.

4. On the Attribute Editor tab, in the Attributes box, double-click the attribute msDS‑AllowedDNSSuffixes.

5. In the Multi-valued String Editor dialog box, in the Value to add box, type a DNS suffix and then click Add.

6. When you have added all the DNS suffixes for the domain, click OK.

7. Click OK to closed the Properties dialog box for that domain.

8. In the scope pane, right-click ADSI Edit and click Connect to.

9. Under Computer, click Select or type a domain or server.

10. Type the name of the next domain for which you want to set the primary DNS suffix, and then click OK.

11. Repeat steps 2 through 7 for that domain.

12. Repeat steps 8 through 10 to select each subsequent domain and repeat steps 2 through 7 to set the primary DNS suffix for each subsequent domain that is being renamed.


To apply the Group Policy setting Primary DNS Suffix to groups of member computers

1. In Active Directory Users and Computers, right-click the domain or organizational unit that contains the group of computers to which you are applying Group Policy.


In Active Directory Sites and Services, right-click the site object that contains the computers to which you are applying Group Policy.

2. Click the Group Policy tab.

3. In the Group Policy object Links box, click the Group Policy object that you want to contain the Primary DNS Suffix setting.


To create a new Group Policy object, click New and then type a name for the object.

4. With the Group Policy object selected, click Edit.

5. Under Computer Configuration, click to expand Administrative Templates, Network, and then click DNS Client.

6. In the results pane, double-click Primary DNS Suffix.

7. Click Enabled, and then in the Enter a primary DNS suffix box, type the DNS suffix for the domain whose member computers are in the group you selected in Step 1.

8. Click OK.

9. Close the Group Policy dialog box, and then close the properties page for the selected object.

To configure the redirecting alias DNS entry

1. In the DNS MMC snap-in, expand the DNS server node to expose the old DNS zone.

2. Right-click the old DNS zone.

3. Click New Alias (CNAME ).

4. In the Alias name box, type the original fully qualified domain name (FQDN) of the HTTP Server..

5. In the Fully qualified domain name for target host box, type the new FQDN of the HTTP Server, and then click OK.

At this point you can test the redirection by pinging the FQDN of the old HTTP server. The ping should be remapped to the new FQDN of the HTTP server.

Issues involving domain rename:

  • XDR-Fixup tool does not work on Exchange 2010 
  • Exchange SMTP stops functioning
  • Exchange organization initialization fails


Simple alternative solutions without renaming domain

Microsoft does not support domain rename if Exchange 2007 installed in member server. So what could be work around if you have to have new user account, corresponding emails account and web sites with new domain name without renaming domain.

  • Prepare a control workstation station and log on as a domain admin, schema admin and enterprise admin
  • Create a new range of IP in your infrastructure
  • Prepare an windows server 2008 and promote as your new primary domain with new domain name
  • Create External trust between two domains
  • Ask your ISP Add new Host (A) and MX record with new domain


  • Point this new MX record to existing SMTP server
  • Add new domain into trusted domain list


  • Add new email policy for new domain





  • Change default email address to new email addresses through email property of mailbox using Exchange management console


  • Migrate IIS web sites to new web server
  • Redirect CNAME record to new websites for customers and stakeholder
  • Add 301 redirect using Google webmaster if necessary 

Relevant Articles:

Microsoft Exchange System Attendant service does not start

completely remove Exchange 2000 or Exchange 2003 from Active Directory

How to remove Exchange Server 2003 from your computer

How to remove the first Exchange Server 2003 computer from the administrative group

Removing and Modifying Exchange 2007

Step-by-Step Guide to Implementing Domain Rename

Windows Server 2003 Active Directory Domain Rename Tools

Exchange Server Domain Rename Fixup

Microsoft KB842116

Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup)

Windows 2003 domain rename tools