Migrating Exchange 2007 to Exchange 2019

by sircles on Jan 28, 2025
We have the following: a 2008 R2 domain controller in a 2008 domain that is dying. An exchange 2007

 

We have the following: a 2008 R2 domain controller in a 2008 domain that is dying. An exchange 2007 server and we need to get migrated over to two new servers, one 2016 new dc and subsequently a 2019 exchange server. What is the pathway with the least middle steps and installs?

Migrating from such an old infrastructure to newer systems is a significant task, and there are a few constraints to keep in mind due to compatibility issues. Here’s a step-by-step pathway with the least intermediate steps:

1. Prepare the Environment

  1. Raise the Functional Level of the Domain/Forest:

    • Ensure the domain and forest functional levels are compatible with Windows Server 2016 (minimum 2008). If not, upgrade them before proceeding.

  2. Check Existing Infrastructure:

    • Verify the health of the current domain controller (DC) and Exchange 2007 server (dcdiag, repadmin, Exchange Best Practices Analyzer).
    • Take a full backup of the domain controller, Exchange server, and Active Directory.

  3. Install New Windows Server 2016 Domain Controller:

    • Add a new Windows Server 2016 server to the domain.
    • Promote it to a domain controller using the dcpromo process.
    • Transfer FSMO roles to the new 2016 DC.

  4. Demote the Old 2008 DC:

    • Demote the 2008 R2 DC once the new DC is running and replication is confirmed.
    • Decommission and remove the old DC from the environment.

2. Migrate Exchange to a Supported Intermediate Version

Exchange 2007 cannot be directly migrated to Exchange 2019, so you'll need to use Exchange 2013 or Exchange 2016 as an intermediate step. The simplest pathway is:

  1. Install Exchange 2016:

    • Set up a new Exchange 2016 server in your environment.
    • Prepare Active Directory using Exchange 2016 schema updates (Setup.exe /PrepareSchema and Setup.exe /PrepareAD).
    • Configure the new Exchange 2016 server (mailbox databases, connectors, certificates, etc.).
    • Migrate mailboxes from Exchange 2007 to Exchange 2016 using the Exchange Admin Center (EAC) or New-MoveRequest.

  2. Decommission Exchange 2007:

    • Once all mailboxes and services are migrated, uninstall Exchange 2007 from the old server.

3. Upgrade to Exchange 2019

  1. Install Exchange 2019:

    • Set up a new Exchange 2019 server on Windows Server 2019.
    • Prepare Active Directory again for Exchange 2019 schema updates.
    • Migrate mailboxes from Exchange 2016 to Exchange 2019 using the EAC or PowerShell.

  2. Decommission Exchange 2016:

    • After confirming all mailboxes and services are running on Exchange 2019, decommission and remove the Exchange 2016 server.

4. Final Cleanup

  • Ensure the domain and forest functional levels are upgraded to at least Windows Server 2016.
  • Remove any leftover objects from Active Directory (e.g., Exchange 2007 and 2016).
  • Validate the health of the new domain controller and Exchange 2019 environment.

Summary of Steps

  1. Install the new Windows Server 2016 DC and migrate FSMO roles.
  2. Install Exchange 2016 and migrate mailboxes from Exchange 2007.
  3. Install Exchange 2019 and migrate mailboxes from Exchange 2016.
  4. Decommission old servers step-by-step.

This method minimizes intermediate installations (only one for Exchange 2016), ensures a supported migration path, and avoids compatibility issues. 

Will exchange 2007 still work if I upgrade the domain DCs to a 2016 functional level?

Yes, Exchange 2007 can still work with a Windows Server 2016 domain controller and a 2016 domain functional level, but there are important considerations and potential issues:

Compatibility Between Exchange 2007 and Windows Server 2016

  1. Exchange 2007 Compatibility:

    • Exchange 2007 is not officially supported on domain controllers running Windows Server 2016.
    • However, in practice, Exchange 2007 may function if:
      • The schema and functional level updates for Windows Server 2016 are done carefully.
      • The domain controllers remain separate from the Exchange server.

  2. Domain Functional Level:

    • Exchange 2007 is compatible with up to Windows Server 2008 R2 functional level.
    • While it may technically work at the 2016 functional level, Microsoft does not support this configuration, and unexpected issues could arise.

  3. Schema Updates:

    • Introducing a Windows Server 2016 DC into the environment requires updating the Active Directory schema.
    • Exchange 2007 was not designed to work with the schema changes introduced by Exchange 2013/2016/2019 or Windows Server 2016. Test thoroughly to ensure no adverse effects.

Potential Issues to Watch For

  1. Global Catalog/Domain Controller Communication:

    • Exchange 2007 relies heavily on Global Catalog servers for user lookups and directory access.
    • Ensure the new Windows Server 2016 domain controllers are properly configured as Global Catalog servers.
    • Test authentication and directory lookups to ensure compatibility.

  2. Management Tools:

    • Exchange 2007 management tools may behave inconsistently when interacting with a 2016 domain/forest.

  3. Unforeseen Breakage:

    • Since Exchange 2007 is out of support and not tested with newer domain configurations, you risk unexpected errors that Microsoft will not assist in resolving.

Recommended Actions

To ensure a smoother transition:

  1. Install the New Domain Controller:

    • Add the Windows Server 2016 domain controller to the existing domain.
    • Verify replication and functionality.
    • Gradually transition FSMO roles to the new DC.

  2. Keep the Domain Functional Level Temporarily at 2008:

    • If possible, do not raise the domain or forest functional level to 2016 until after migrating away from Exchange 2007. This approach ensures continued compatibility.

  3. Plan for Exchange 2007 Migration:

    • Migrate from Exchange 2007 to Exchange 2016 as soon as possible.
    • Decommission Exchange 2007 and fully upgrade the domain and forest functional levels once all mailboxes are migrated.

Key Consideration: Avoid Delaying Migration

Even if Exchange 2007 continues to function after upgrading the DCs, it’s risky to maintain such an unsupported setup. If Exchange 2007 fails unexpectedly in this configuration, there will be limited options to troubleshoot or recover.

By migrating to Exchange 2016 or 2019 promptly, you’ll eliminate these risks and future-proof your environment. 

Let's add the 2016 DC at 2008 functional level, promote it to 2008 R2 and leave until the migration is done

You're absolutely right—keeping the domain functional level at 2008 R2 during the Exchange migration is the safest and most practical approach. Here’s why your plan makes sense and how to execute it effectively:

Why Your Plan Works

  1. Maintains Compatibility:

    • Exchange 2007 is fully supported in a 2008 R2 functional level domain.
    • Raising the domain functional level to 2016 before migrating Exchange could introduce unexpected issues, especially with schema changes and feature incompatibilities.

  2. Minimizes Risk:

    • Adding a Windows Server 2016 domain controller to a 2008 R2 functional level environment is supported.
    • This allows you to modernize your domain controller infrastructure while ensuring that Exchange 2007 remains functional during the migration.

  3. Controlled Upgrade Path:

    • Once the Exchange migration is complete (to Exchange 2016 or 2019), you’ll be free to raise the domain and forest functional levels to 2016.

Steps to Execute Your Plan

1. Add the New Windows Server 2016 Domain Controller

  1. Prepare Active Directory:

    • Run the required schema updates for Windows Server 2016: 
      adprep /forestprep
adprep /domainprep
    • These updates are backward-compatible with 2008 R2 functional levels and won’t disrupt Exchange 2007.

  2. Promote the 2016 Server to a Domain Controller:

    • Use the Active Directory Domain Services Configuration Wizard to promote the server to a domain controller.
    • Ensure the new DC is also a Global Catalog.

  3. Transfer FSMO Roles:

    • Once the new DC is stable, transfer the FSMO roles to the Windows Server 2016 DC: 
      ntdsutil
    • Validate the health of the domain after the role transfer.

  4. Demote the Old 2008 R2 DC (Optional):

    • If you plan to decommission the old DC, ensure all roles and services have been transferred.

2. Keep the Functional Level at 2008 R2

  • Do not raise the domain or forest functional levels to 2016 until the Exchange migration is complete.

3. Migrate Exchange

  1. Install Exchange 2016:

    •  

      Add a new Exchange 2016 server to your environment.
    • Migrate mailboxes and services from Exchange 2007 to Exchange 2016.

  2. Decommission Exchange 2007:

    • Once the migration is complete and all mailboxes are moved, uninstall Exchange 2007 and remove it from the environment.

4. Upgrade Domain Functional Levels

  • After Exchange is fully migrated and decommissioned:
    • Raise the domain and forest functional levels to 2016.
    • Ensure all applications and services are compatible with the new functional level before upgrading.

Final Thoughts

This approach ensures maximum compatibility with minimal risk. By keeping the functional level at 2008 R2 during the transition, you’re reducing the likelihood of unexpected issues with Exchange 2007 while still modernizing your domain infrastructure. Once the Exchange migration is done, you’ll have a clean slate to complete the upgrade process.

Will MS Exchange 2016 Install to a Windows 2008 R2 Functional Level Domain?

Yes, Exchange 2016 can install in a Windows Server 2008 R2 functional level domain, but there are a few considerations and prerequisites to keep in mind:

Compatibility

  1. Domain Functional Level:

    • Exchange 2016 supports Windows Server 2008 R2 domain functional level and higher.
    • You do not need to raise the domain functional level to 2012 or 2016 to install Exchange 2016. Keeping the functional level at 2008 R2 during migration is perfectly fine.

  2. Active Directory Schema:

    • Exchange 2016 requires specific Active Directory schema updates to be applied.
    • These schema updates are backward-compatible with a 2008 R2 functional level domain.

  3. Domain Controllers:

    • Ensure that at least one writable Global Catalog server is available in the same Active Directory site where you plan to install Exchange 2016.
    • Domain controllers running Windows Server 2008 or later are supported.

Prerequisites for Installing Exchange 2016

  1. Prepare Active Directory:

    • Run the following commands from the Exchange 2016 setup media to prepare the schema and domain: 
      Setup.exe /PrepareSchema
Setup.exe /PrepareAD /OrganizationName:"YourOrganization"
Setup.exe /PrepareDomain
    • Make sure the account running these commands has Enterprise Admins and Schema Admins privileges.

  2. Server Requirements:

    • Exchange 2016 must be installed on Windows Server 2012 R2 or Windows Server 2016.
    • Ensure the server meets the Exchange 2016 system requirements, including sufficient CPU, RAM, and storage.

  3. DNS Configuration:

    • Verify that DNS is functioning correctly, with proper forward and reverse lookup zones.
    • Configure a split DNS setup if your environment requires internal and external DNS resolution for mail flow.

  4. Coexistence with Exchange 2007:

    • Exchange 2016 can coexist with Exchange 2007 during migration. Use Exchange 2016 CU3 or later for proper coexistence.
    • Set up the proper connectors for mail flow between the two servers during migration.

Important Notes

  • Mixed Functional Levels: Even if the domain functional level is 2008 R2, you can still add newer domain controllers (e.g., Windows Server 2016) to the environment. Ensure that the domain controllers are properly replicated before installing Exchange 2016.
  • Legacy Outlook Clients: Exchange 2016 does not support Outlook 2007 or earlier versions. Ensure users have upgraded to Outlook 2010 SP2 or later before migration.

Steps to Install Exchange 2016 in a 2008 R2 Functional Domain

  1. Verify the health of your current domain using dcdiag and repadmin.
  2. Install a new server with Windows Server 2016 or 2012 R2 for Exchange 2016.
  3. Prepare Active Directory (schema, AD, and domain).
  4. Install Exchange 2016 on the new server.
  5. Set up coexistence between Exchange 2007 and Exchange 2016:
    • Configure mail flow connectors between the two.
    • Test internal and external mail flow.
  6. Migrate mailboxes and public folders to Exchange 2016.
  7. Decommission Exchange 2007 after ensuring all data and services are migrated.

Conclusion

Yes, Exchange 2016 can be installed and operate in a domain with a 2008 R2 functional level. This allows you to migrate mailboxes from Exchange 2007 to Exchange 2016 without needing to raise the functional level or make drastic changes to your domain infrastructure.

We Need to Migrate Existing File Shares on the DC to the new 2016 DC, keeping the old UNC File Share Name

Migrating a file share from your existing domain controller (DC) to a new Windows Server 2016 machine while maintaining the same UNC path (e.g., \\OldDC\Share) involves careful planning. Here's a step-by-step guide to achieve this:

Steps to Migrate the File Share

1. Prepare the New File Server

  1. Install the File Server Role:

    • On the new Windows Server 2016, install the "File Server" role via Server Manager.

  2. Create the File Share:

    • Create a folder on the new server (e.g., D:\Shares\ShareName) where you will migrate the files.

2. Migrate Files to the New Server

  1. Use Robocopy for File Migration:

    • Robocopy ensures file permissions (ACLs) are preserved during migration.
    • Use the following command: 
      robocopy \\OldDC\Share D:\Shares\ShareName /E /COPYALL /R:2 /W:1 /LOG:C:\FileMigration.log
      • /E: Copies all subdirectories, including empty ones.
      • /COPYALL: Copies all file data and attributes (permissions, timestamps, etc.).
      • /R:2: Retries twice on failed copies.
      • /W:1: Waits 1 second between retries.
      • /LOG: Logs the output for troubleshooting.

  2. Verify File Integrity:

    • Check the log file for errors.
    • Manually verify that all files and permissions have been successfully copied to the new server.

3. Update DNS to Retain the UNC Path

  1. Set the Old DC Name to Point to the New Server:

    • After demoting or decommissioning the old DC:

      • Create a DNS alias (CNAME) for the old DC’s hostname to point to the new file server.
      • For example, if the old DC is OldDC, create a DNS entry so OldDC resolves to the IP of the new server.

      Steps:

      • Open the DNS Manager on your domain.
      • Right-click on the zone and select "New Alias (CNAME)."
      • Enter the alias name (OldDC) and the FQDN of the new server (e.g., NewServer.domain.local).

  2. Set the Old File Share UNC Path:

    • Ensure the share name (Share) is created on the new server, matching the old path (\\OldDC\Share).
    • Verify that users can access the share via \\OldDC\Share.

4. Optional: Configure a Virtual Server Name

If you prefer not to modify DNS, you can configure a server alias using a new virtual server name and UNC path.

  1. Create a Server Alias:

    • On the new server, use the SetSPN command to create an alias for the old server name. 
      setspn -A HOST/OldDC.domain.local NewServer
setspn -A HOST/OldDC NewServer

  2. Enable SMB Server Alias Support:

    • Add the old server name as an alias in the registry:
      1. Open regedit.
      2. Navigate to: 
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
      3. Add a new Multi-String Value called OptionalNames and enter OldDC.
      4. Set DisableStrictNameChecking to 1:
        • Navigate to: 
          HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
        • Create a new DWORD value DisableStrictNameChecking and set it to 1.

  3. Restart the Server:

    • Reboot the new server to apply the changes.

5. Decommission the Old DC

  1. Demote the Old Domain Controller:

    • After confirming the file share is fully functional on the new server, demote the old DC. 
      dcpromo

  2. Remove the Old DC from the Domain:

    • Ensure the old server is cleanly removed from Active Directory.

6. Test and Validate

  1. Verify UNC Path Access:

    • Ensure that users can access the file share using the old path (\\OldDC\Share).
    • Test permissions to confirm they match the old setup.

  2. Monitor Access:

    • Use the file share management tools on the new server to monitor access and ensure users are connecting without issues.

Key Notes

  • Backup Before Migration:
    • Take a full backup of the files on the old DC before starting the migration.
  • Demotion Timing:
    • Do not demote the old DC until you’ve confirmed the new server is fully functional and all users can access the file share without issues.
  • DNS Propagation:
    • If you’re relying on DNS changes for the UNC path, ensure adequate time for DNS changes to propagate across the network.

This approach keeps the UNC path valid (\\OldDC\Share) while modernizing your environment. 

Changing the DC Name with setspn Would Drive AD Nuts

Yes, using DFS (Distributed File System) is an excellent and supported way to maintain the original UNC path (e.g., \\OldDC\Share) while migrating the file share to a new server. This approach avoids disrupting Active Directory and ensures seamless access for users. Here's how you can set it up:

Steps to Migrate the File Share with DFS

1. Set Up DFS Namespaces

  1. Install DFS on the New Server:

    • On the new Windows Server 2016, install the DFS Namespaces role:
      • Open Server Manager → Add Roles and Features.
      • Select DFS Namespaces under File and Storage Services → File and iSCSI Services.

  2. Create a DFS Namespace:

    • Open the DFS Management Console:
      • Start → Type DFS Management and open it.
    • Right-click Namespaces → New Namespace.
    • Choose the new server (e.g., NewServer) as the host for the namespace.
    • Name the namespace to match the old DC’s hostname (\\OldDC).

    Example:

    • Namespace path: \\OldDC\Share
    • This ensures users can continue to use the same UNC path.

2. Add the File Share Target

  1. Add the New Server as a Target:

    • Right-click the namespace (\\OldDC) → New Folder.
    • Name the folder the same as the share (e.g., Share).
    • Add the target folder on the new server (e.g., D:\Shares\Share).

  2. (Optional) Add the Old Server as a Target:

    • During the migration, you can add the old server as another target for redundancy or coexistence.
    • DFS will handle referrals to the appropriate server.

3. Migrate Files

  1. Transfer Files to the New Server:

    • Use robocopy to migrate files from the old DC to the new server while preserving permissions: 
      robocopy \\OldDC\Share D:\Shares\Share /E /COPYALL /R:2 /W:1 /LOG:C:\FileMigration.log

  2. Synchronize During Cutover:

    • Run robocopy again with the same command to copy any incremental changes before finalizing the migration.

4. Update the DFS Namespace for Cutover

  1. Remove the Old Target:

    • Once the migration is complete and you’ve verified that everything works on the new server:
      • Open the DFS Management Console.
      • Remove the old file share target (\\OldDC\Share) from the namespace.

  2. Update Referral Settings:

    • In the DFS Management Console, adjust the referral settings for the namespace:
      • Set the new server (\\NewServer) as the primary target.

5. Test and Validate

  1. Verify Access:

    • Test accessing the share using the original UNC path (\\OldDC\Share) from multiple client machines.
    • Ensure that users are redirected to the new server.

  2. Monitor DFS Replication (Optional):

    • If you configured DFS replication between the old and new servers during migration, monitor the replication status to confirm that it has completed.

Why DFS Works Well

  • Seamless User Access:
    • Users continue to use the old UNC path (\\OldDC\Share), even though the data is now hosted on the new server.
  • Scalability:
    • You can add additional targets in the future if needed.
  • Redundancy:
    • DFS provides fault tolerance by automatically redirecting users to available targets if one server goes down.

Final Steps

  • Once everything is running smoothly and the old server is no longer needed:
    • Decommission the old file share on the DC.
    • Demote the DC if it’s being retired.

This method keeps the UNC path intact, avoids any hacks that could break Active Directory, and provides a robust migration path.

Add comment