In this edition of our series on the “Top 5 Best Practices for Exchange Online Domain Transfers,” we delve deeper into the importance of validating your plan prior to implementation. As the third phase of a Microsoft 365 Exchange Online migration project, validation follows the strategizing phase. Implementing a well-tested and practiced process will help prevent mistakes and encountering unknowns during the migration. Join us as we explore the key considerations for a successful validation phase. 

Deep Dive of the Validation Phase  

“Simulations help prepare us to succeed in real-life situations. They expose us to the unexpected and train us to improvise, making us better equipped to handle adversity.” 

Gawande, Atul. The Checklist Manifesto: How to Get Things Right. Picador, 2011. 

You’ve completed your analysis and strategy planning. Now it’s time to put your plan to the test! The strategy has been mapped out; at this point, the project team must validate the plans by performing a mock domain migration through a piloting process utilizing temporary or existing vanity domains. The overall goal of this phase is to confirm and improve the migration process laid out in the strategy phase.

Microsoft 365 Exchange Online Domain Transfers: Validation Phase Part I
Figure 1: Pilot the process 

Prepare the Trial 

To encourage a smooth migration, a crucial step is establishing a temporary vanity domain within the tenant and creating test objects that simulate third-party dependencies identified during the assessment phase. By closely replicating the production environment in the trial scenario, a comprehensive evaluation of the migration can be conducted, ensuring its success. 

Microsoft Platform Migration Planning and Consolidation

Simplify migration planning, overcome migration challenges, and finish projects faster while minimizing the costs, risks and disruptions to users.

How to add an accepted domain?  

For a single or few new domains, it is easiest to use the Microsoft  Admin Center to add a new domain(s). To add domains in bulk, PowerShell would be the recommended method. For example: 

# Import the required modules
Import-Module Microsoft.Graph

# Connect to the tenant
Connect-MgGraph -Scopes "User.ReadWrite.All","Domain.ReadWrite.All"

# Loop through the list of domains and add them to Microsoft 365
Import-Csv C:\scripts\Export.csv | ForEach-Object {New-MgDomain -BodyParameter @{Id=$_.domainname}}

You may also use PowerShell to set the DNS text records and validate domain ownership. Click here for more information on this from Microsoft.  

Keep in mind that any newly accepted domain may not be in effect immediately. It can take up to 24 hours for the changes to propagate throughout the Microsoft 365 service. 

What are the requirements for a temporary vanity domain? 

When creating a temporary vanity domain, there are several requirements to consider to ensure that it mimics your production environment as closely as possible. Here are some common things to check for before procuring any new domains: 

  • Domain name: The domain name should match the naming convention used in the production environment. This ensures that the migration process is consistent and predictable. 
  • DNS records: The DNS records associated with the vanity domain should be configured to match those of the production environment. This includes any MX, CNAME, SPF, DKIM, DMARC, and TXT records that are used for email routing or domain verification. 
  • SSL certificates: If SSL certificates are used in the production environment, they should also be used in the temporary vanity domain to ensure that secure connections are maintained. 
  • User accounts: User accounts should be created in the vanity domain to simulate the production environment. This includes any user attributes or group memberships required for the migration. 
  • Third-party dependencies: If the production environment relies on third-party services or applications, these should also be replicated in the vanity domain to ensure that the migration process is thoroughly tested. 

By ensuring that the vanity domain closely mimics the production environment, the validation process can be used to identify any potential issues or roadblocks before they become a problem during the actual migration. 

Tip 1: On a budget? There are free SSL providers out there, such as win-acme, that can help you provision certificates for your testing.  

What objects should we create? 

At a minimum, you must create user objects and group objects. Any other objects you may require will be up to your individual environment and what type of tests you are trying to accomplish.  

We recommend User and Group objects because they are the two foundational object types for granting access to resources within an Active Directory or Azure Active Directory environment.  

What attributes must they have? 

When creating user and group objects for the temporary vanity domain, it’s important to ensure that they have all the necessary attributes that are present in the production environment. This includes attributes such as user display name, username, email address, group membership, and any custom attributes that are used in the environment. Cloning the objects from the production environment will carry over all the necessary attributes and property values.

Tip 2: For Hybrid environments you can populate a Microsoft Active Directory Domain with a structure and thousands of objects. The output of the tool is a domain like a domain in the real world. Check out this free tool at GitHub
Tip 3: We recommend using a directory synchronization tool that can copy cloud and hybrid objects and properties from your production environment to your test environment for the quickest and best results.  

Should we include a pilot user group in this test? 

Yes, it is recommended to include a pilot user group in the test, as it can help you identify any issues related to user permissions, access to resources, and other settings that may be specific to certain groups of users. Including a pilot user group will also give you a better understanding of the end-user experience during the migration and allow you to make any necessary adjustments before the final migration. 

When planning your domain migration pilot, carefully plan who the best pilot users will be, what tasks they need to accomplish pre and post-migration, when the pilot users are required to execute the tasks, and where they will execute these tasks, such as a designed laptop or device.  

To reduce complexity and cost, we recommend identifying and configuring devices commonly used in your environments and then joining each of those devices to the vanity domain with the associated pilot user accounts. The pilot users will interface with these “staged” devices (phones, laptops, etc.) during the testing cycles (before and after domain migration).  

How do we select the best pilot user group? 

When selecting a pilot user group, it’s important to consider a few factors to ensure that the test accurately reflects the experience of all users in the production environment. One approach is to identify a cross-functional group of users that represent different roles and responsibilities within the organization. This group could include users from different departments, with varying levels of technical expertise, and who use different types of devices. 

Consider selecting pilot users who are open to providing feedback and who are willing to participate in testing activities. It’s also important to ensure that the pilot user group is large enough to provide a representative sample, but not so large that it becomes difficult to manage. 

Ultimately, the best pilot user group will depend on your organization’s specific needs and the migration project’s goals. Work with your project team or IT department to identify the best pilot user group based on these considerations. 

On Demand Migration

Migrate all your workloads and Active Directory with one comprehensive Office 365 tenant-to-tenant migration solution.

Is there any cost associated to procure a vanity domain? 

Typically, yes, there is a cost associated with procuring a new vanity domain. The cost can vary depending on the registrar you choose and the specific domain name you are looking to acquire. Some registrars offer discounts for first-time users, while others may offer additional services, such as domain privacy protection, for an additional fee. It’s important to do your research and shop around to find the best registrar for your needs and budget. Additionally, organizations may have policies or procedures in place for procuring new domains, so it’s important to check with your IT department or management team to ensure you are following the proper protocol. 

Could we effectively use a subdomain within an existing domain to test the domain migration? 

Yes, you can use a subdomain within an existing domain to test the domain migration. However, it’s important to note that this approach may not fully replicate the production environment, as some settings and configurations may differ between the subdomain and the parent domain. Additionally, if the subdomain is used for other purposes, there may be potential conflicts or impacts on other systems or services. 

Are there free options? 

If you are a small or medium size business, you may not have the resources to buy new domains for testing.  

If you cannot procure a vanity domain or do not want to use a subdomain for your testing purposes, another option is to use a third-party domain that provides free domain registration, such as Freenom or Dot.tk. These domains can be used as a temporary solution for your migration testing purposes. 

Freenom offers free domain registration for a variety of domain extensions, including .tk, .ml, .ga, .cf, and .gq. While these domains are not recommended for production environments due to potential reputation and security issues, they can be useful for temporary testing purposes. 

Dot.tk is operated by the Tokelau government and is one of the largest domain name registries in the world. It allows users to register custom domain names for free with the .tk extension. However, the free service does have some limitations and restrictions, and users may need to upgrade to paid options for more control over their domain name. 

Note that when using a third-party domain, you may need to update your DNS settings and configure them to work with your migration testing environment. Additionally, you may need to update your migration scripts and other settings to reflect the use of a different domain. 

Overall, while using a third-party domain is not the ideal solution, it can be a cost-effective and convenient way to conduct your domain migration testing on a budget. 

What’s up Next 

Since we have so much to share with our loyal readers, we felt that in order to provide the most value, we would break up our deep dive into the validation phase into three (3) parts for you to digest and absorb more easily. So, stay tuned for part 2 of the series, where we will continue by putting the communication plan to the test! 

About the Author

Richard Dean

Richard is a seasoned product leader and solutions architect with over 25 years in the IT industry, specializing in Microsoft Cloud & Hybrid technologies. As Quest's Senior Manager of Technical Product Management, he excels in managing complex Microsoft 365 challenges. Richard is a certified Microsoft Professional, speaker, blogger, and podcaster. He co-hosts the Practical 365 podcast, sharing insights on Microsoft 365. Recently, he co-hosted The Experts Conference (TEC) 2023 in Atlanta, GA, presenting on multi-tenant management solutions. Passionate about sharing knowledge, Richard helps organizations succeed in their digital transformation journey.

Comments

  1. Michel de Rooij

    Did somebody.proofread this? There’s no New-AcceptedDomain in the online world.

    1. Rich Dean

      Sorry for the confusion. It was a placeholder for what needed to be there. It is all fixed now. Thank you so much for helping us maintain quality.

Leave a Reply