On Demand Migration Current - Active Directory User Guide

DMARC

What is DMARC?  

DMARC is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. Wikipedia

Is DMARC supported with Email Rewrite Services (ERS)?  

Yes, DMARC is fully supported in all ERS mail flow scenarios. Either natively or through product supported methods.

Table 1: Supported DMARC Mail Flow Scenarios

What does product supported mean?  

Product supported means that Domain Rewrite maintains domain authenticity, through internal methods to ensure the message received by the originating Microsoft 365 tenant was DMARC compliant before it is rewritten and redirected to the destination Microsoft 365 tenant.

In other words, Domain Rewrite ERS will verify and sign the rewritten email with a secret key so that when it is received by the destination Microsoft 365 tenant, transport rules may verify its authenticity then deliver to the intended user.

What does natively supported mean?  

Natively supported means that DKIM domain alignment is achieved when an ERS rewritten email is sent or received. Therefore, DMARC will pass when received without interruption by the intended recipient domain.

What is required for DMARC to function with ERS?  

DMARC is supported natively for all ERS users when sending mail outbound to an external domain recipient or across to a neighboring Microsoft 365 tenant. Simply choose the accepted domains in use during your project setup of the DKIM signatures. This will ensure the required domains are signed to achieve domain alignment and pass DMARC. The project wizard will guide you through the process.

Why are reply emails sent to the Junk folder?  

When an ERS user receives a reply email from an external user, it is rewritten back to the original email address. This disrupts domain alignment and Exchange Online Protection by default will mark such emails as SPAM, delivering it to the end-user’s junk email folder.

How do I prevent ERS reply emails from being marked as SPAM?  

It’s very easy to do. Simply setup a new action in one of the ERS transport rules. When ERS is deployed in each tenant environment, transport rules are created to manage to flow of mail for ERS users only.

This new action will allow ERS validated emails only to by-pass SPAM and deliver the message directly to the end-user’s inbox.

How do I setup an action in my transport rule to prevent ERS reply mail going to Junk?  

During this deployment, a rule named “BT-IntegrationPro-In-DKIM” is created and configured in each Microsoft 365 tenant in scope for Email Rewrite Services.

Follow these steps to setup a new action in the ERS Transport Rule using the Exchange Admin Center.

1. Login into Exchange Admin Center with your Exchange Online Administrator or higher role account.
2. Navigate to Mail Flow, Rules.
3. Locate the rule named, BT-IntegrationPro-In-DKIM.
4. Click Edit.
5. Click Add Action.
6. From the Do the following… field select, Modify the Message Properties.
7. Select set the spam confidence level (SCL).
8. Select the specify SCL to be Bypass spam filtering.
9. Select OK.
10. Select Save.

PowerShell may also be used to modify the rule. Here is an example.

Set-TransportRule "BT-IntegrationPro-In-Dkim" -SetSCL –1

See the Set-TransportRule for more information.

May I set additional actions to the rule such as add a disclaimer or append the subject?  

Yes, additional actions are supported on this rule. For example, it may be desired that a disclaimer be added to these ERS emails informing the recipient they are safe and were rewritten by our authorized service provider. Another common example is to prepend to the subject line that this is an ERS email. This provides additional awareness to the end-user users receiving and sending these types of email.

If additional actions are added to this rule, please validate the changes do not impact any functionality. And do not modify the rule order or add rules that reorder the ERS rules.

If this rule is deleted will it be recreated automatically?  

Yes, Domain Rewrite health monitoring will recreate any rules that it created for ERS. If ERS is disabled in your project, all rules will automatically be removed from all tenant environments.

Will the rule be recreated with my additional actions?  

No, any additional actions you may have added to the rule must be added again to the newly created rule.

How do I make a back-up of my rules with my custom actions?  

You may easily use Exchange Online PowerShell to export your rules to a CSV file as a back-up. For example, here is a script that will export all rules created by Domain Rewrite during the ERS deployment.

Get-TransportRule BT-Integration* | export-csv C:\Users\%USERNAME%\Downloads\BT-Integration_TransportRules.csv

Domain Move

This user guide covers the steps required to configure and perform a Domain Move. The Domain Move Quick Start Guide summarizes these steps and addresses some frequently asked questions.

Platform Requirements

Supported Environment Deployments  

Domain move between two Microsoft 365 tenants cloud-only or hybrid tenants is supported.

Exchange Hybrid Deployments  

Domain Move currently provides limited support for Exchange hybrid deployments. Environments with an Exchange Server 2013 (or later) hybrid deployment are supported, but with the following limits on functionality:

• Support for the Email Relay Service is limited to mail flow configurations that use Microsoft 365 for message ingress and egress. Centralized mail flow configurations that use the on-premises Exchange environment for inbound and outbound message delivery may require custom configuration with Support.

Application Service Account Requirements  

To set up a Domain Move project the following must be provided by the owner of each of the associated Microsoft 365 tenants.

1. Application Account: One (1) dedicated and licensed application service account to grant permissions and automatically orchestrate various activities within the project. This account must have the Exchange Online plan assigned to facilitate automatic email communications to end-users and project administrators during cutover activities, otherwise all communications will appear to be sent from the PowerShell account.
2. Roles: The Global Administrator role is required for connecting environments for projects and workflows to grant permissions and to create a PowerShell account within each configured tenant.
3. Licenses: At least one (1) E1 or above license must be available to be assigned to the PowerShell account for Migration/Integration Projects.

What are the minimum administrator roles required to manage a project?  

At a minimum, after project set up the following Microsoft 365 Role is required to automatically manage various aspects of your project.

1. Global Administrator Role

Important Tip: For the best application experience, it is always recommended to use the Global Administrator role. However, it is only required during the initial Project setup, reconnections to the tenant or during a Domain Cutover event, where more authority is required. All account and role management are strictly the responsibility of the tenant administrators.

Modern Authentication Requirements  

Domain Move projects take advantage of Modern Authentication to help manage your projects. Modern Authentication is the default behavior for all Microsoft 365 tenants. Unless it was disabled, no action is required. However, we recommend the following configuration parameter is validated prior to deployment.

Get-OrganizationConfig | Format-Table Name,OAuth* -Auto

If Modern Authentication is disabled it must be enabled prior to any migration activities can proceed. To enable Modern Authentication for Exchange Online, run this command under the correct authority.

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

Here is some additional information about how to Enable modern authentication in Exchange Online.

PowerShell  

The following accounts are required:

• Account: One Cloud-only account will automatically be created during project setup.
• Microsoft 365 Administrator Roles: Automatically assigned the Exchange and SharePoint Administrator roles.
• Microsoft 365 License Requirements: Automatically assigned one available license (E1 minimum) for destination tenants.
• The accounts must be excluded from MFA requirements.

Important Note: This account will automatically be assigned the Global Administrator role at the start of a Domain Cutover event, where more authority is required to complete the process.

Domain Move Requirements

Source and Target Domain Pairing  

During configuration, you will be asked to choose your source and target domains for each tenant. This process is called domain pairing.

Source & Target User Matching Attributes 

• You will need to select a pair of attributes that will match exact values from the source user object to the target user object to discover and match the appropriate user accounts.

  • The available matching attributes are as follows, choose at least 1 with a maximum of 3:

    • userPrincipalName

    • mail

    • extensionAttribute1-15

Note: The userPrincipalName and mail attributes are matched based on the local part of the address and the paired Domains (e.g. Tom.Dean@contoso.onmicrosoft.com would use Tom.Dean@binarytree.onmicrosoft.com as a match against the target account.)

Multiple AD Forest Support  

If your organization has multiple Active Directory Forests are connected to your Microsoft 365 tenants, this is supported scenario for migration and integration. There are no additional requirements to support this deployment type.

Directory Synchronization  

Domain Move projects provide automatic orchestration of directory objects to provide capabilities to create and update directory objects during critical points within the migration or coexistence life cycle. To facilitate these activities the following is required for set up.

Local Agents for hybrid AD deployments  

For complete details about local Agents, visit Directory Sync Requirements.

Source & Target Organization Units for hybrid AD deployments  

Domain Move does not create Organizational Units. When deploying a Domain Move project that involves at least one (1) hybrid environment you must choose or create designated Organizational Units within your local AD Forest to allow new User or Contact objects be created.

Hybrid Tenant Support

The Active Directory forest attached to the Microsoft 365 Tenant must have the Microsoft Exchange 2010 SP3 (or later) schema extensions applied.

What is required to set up Directory Synchronization for Integration projects?  

For hybrid or mixed environments, where your local Active Directory (AD) is being synchronized to Microsoft Entra ID the following is required.

1. At least one (1) Windows server to host the local Agent.
2. During set up, install at least one (1) local Agent in each AD Forest. Up to 5 agents are supported. One (1) agent per server.
3. Account credentials for one (1) AD account with permissions to create and update objects within the designated Organizational Units (OU).
4. Account credentials for one (1) Global Administrator within your Microsoft 365 tenant.
5. Designated OUs in each environment to create new objects.

For additional details about local Agents, visit Directory Sync Requirements.

For cloud only environments, where there is no local Active Directory the following is required.

1. Account credentials for one (1) Global Administrator within your Microsoft 365 tenant.

For more information about account permissions, click here.

Local Agents for hybrid AD deployments  

For complete details about local Agents, visit Directory Sync Requirements.

Source & Target Organization Units for hybrid AD deployments  

When deploying a Premium Integration project that involves at least one (1) hybrid environment you must choose or create designated Organizational Units within your local AD Forest to allow new User or Contact objects be created.

Hybrid Tenant Support

The Active Directory forest attached to the Microsoft 365 Tenant must have the Microsoft Exchange 2010 SP3 (or later) schema extensions applied.

Domain Sharing (Email Relay Services)  

To deploy Email Relay Services (ERS) between tenants the following will need to be ready prior to the configuration of the service.

During initial project set up you may choose to configure ERS now, if you are ready or later after the initial discovery is complete.

ERS Deployment Checklist:

The following checklist provides a quick reference to the items or decisions required to begin configuration of ERS.

1. Procure one (1) SSL single domain certificate for each tenant environment using one (1) of the accepted domains.
2. The password associated with the SSL certificate will be required when uploading each certificate.
3. Choose which domains will particulate in ERS.

Important Tip:When using advanced Email Relay Service, please ensure the MTA-STS policy includes the Email Relay Server’s MX record to avoid email disruption.

SSL Certificates  

To successfully configure the Email Relay Service, a valid SSL certificate must be procured for all source and target tenants. The certificate must contain a single accepted domain, one (1) for each tenant. The selected certificate cannot contain subject alternative names (SAN). The common name (Subject Name) must match one (1) of the Exchange Online accepted domains configured within the tenant.

This certificate is utilized to secure the Exchange Online connectors over TLS that will be used to transfer message between the Email Relay service and each tenant. The new certificates will be uploaded to the project using a PFX formatted certificate. PFX files contain the public key file (SSL Certificate file) and the associated private key file (password).

The requirements for the certificate are as follows: (Names are for example purposes only.)

• Common Name: contoso.com
• Cryptographic service provider: Microsoft RSA SChannel Cryptographic Provider
• Bit length: 2048 or higher
• Must be valid for Server Authentication and Client Authentication.
• Must be signed by a trusted public root CA.
• Must contain a private key (password).
• Must not expire before the end of the project.
• Must have a Friendly Name defined.

Important Tip: The domain listed on the certificate cannot be moved as part of a Domain Cutover process. If you plan to move all accepted domains, you should plan to acquire a certificate for a newly created accepted domain to use as a placeholder. This domain will not be moved or used; it will be used only as the subject for the TLS certificate.

Domain Cutover  

There are no additional requirements to set up Domain Cutover services, however it is recommended that the following related topics be reviewed prior to execution.

Important Tip: The domain listed on the SSL certificate cannot be moved as part of a Domain Cutover process. If you plan to move all accepted domains, you should plan to acquire a certificate for a newly created accepted domain to use as a placeholder. This domain will not be moved or used; it will be used only as the subject for the TLS certificate.