-->

• Microsoft Exchange Login
• Microsoft Exchange 365 Sign In
• Microsoft Hosted Exchange
• Microsoft Exchange 365 Login

This test will check the external domain name settings for your verified domain in Office 365. The test will look for issues with mail delivery such as not receiving incoming email from the Internet and Outlook client connectivity issues that involve connecting to Outlook and Exchange Online.

This topic describes how to configure server-based authentication between Dynamics 365 (on-premises) and Exchange Online. The diagram below illustrates the communication between Dynamics 365 (on-premises), Azure Active Directory, and Exchange Online.

• This article describes how to configure the Microsoft Dynamics CRM E-mail Router with Microsoft Office 365 Exchange Online for incoming and outgoing email messages. More Information. When you configure the Microsoft Dynamics CRM E-mail Router with Office 365 Exchange Online, you must follow specific requirements for incoming and outgoing messages.
• Email, phone, or Skype. Can’t access your account?

Permissions required

Microsoft Dynamics 365

• System Administrator security role.
• If you are using a self-signed certificate for evaluation purposes, you must have local Administrators group membership on the computer where Microsoft Dynamics 365 Server is running.
• The account that you use to sign in to the CRM deployment servers must have full local administrator rights.

Exchange Online

• Office 365 Global Administrators membership. This is required for administrative-level access to the Office 365 subscription and to run the Microsoft AzurePowerShell cmdlets.

Important

In this deployment, the Dynamics 365 administrator can approve mailboxes.

Set up server-based authentication with Microsoft Dynamics 365 and Exchange Online

Follow the steps in the order provided to set up Dynamics 365 (on-premises) with Exchange Online.

Important

The steps described here must be completed in the order provided. If a task is not completed, such as a Windows PowerShell command that returns an error message, the issue must be resolved before you continue to the next command, task, or step.

Verify prerequisites

Before you configure Dynamics 365 (on-premises) and Exchange Online for server-based authentication, the following prerequisites must be met:

• The Dynamics 365 (on-premises) deployment must already be configured and available through the Internet. More information: Configure IFD for Dynamics 365 Customer Engagement (on-premises)
• Microsoft Dynamics 365 Hybrid Connector. The Microsoft Dynamics 365 Hybrid Connector is a free connector that lets you use server-based authentication with Microsoft Dynamics 365 (on-premises) and Exchange Online. More information: Microsoft Dynamics 365 Hybrid Connector
• An x509 digital certificate issued by a trusted certificate authority that will be used to authenticate between Dynamics 365 (on-premises) and Exchange Online. If you are evaluating server-based authentication, you can use a self-signed certificate.
• Verify that all servers that run the Asynchronous Processing Service have the certificate that is used for Server-to-Server authentication.
• Verify that the account that runs the Asynchronous Processing Service has read access for the certificate.

The following software features are required to run the Windows PowerShell cmdlets described in this topic:

Configure server-based authentication

1. On the Microsoft Dynamics 365 Server where the deployment tools server role is running, start the Azure Active Directory Module for Windows PowerShell.

2. Prepare the certificate.

   Change the directory to the location of the CertificateReconfiguration.ps1 file (by default it is C:Program FilesMicrosoft Dynamics CRMTool).

3. Prepare the Windows PowerShell session.

   The following cmdlets enable the computer to receive remote commands and add Office 365 modules to the Windows PowerShell session. For more information about these cmdlets see Windows PowerShell Core Cmdlets.

4. Connect to Office 365.

   When you run the Connect-MsolService command, you must provide a valid Microsoft account that has Office 365 Global Administrator membership for the Exchange Online license that is required.For detailed information about each of the Azure Active Directory PowerShell commands listed here, see MSDN: Manage Azure AD using Windows PowerShell.

5. Set the certificate.

6. Set the Azure Active Directory Service Principal Name (SPN) in Exchange Online.

   Replace *.contoso.com with the domain name where Microsoft Dynamics 365 Server is located.

7. Configure the Microsoft Dynamics 365 Server for server-based authentication with Exchange.

Set the Exchange Online tenant ID

1. In the Azure Active Directory module for Windows PowerShell shell, run the following commands.

2. Copy the GUID that is displayed to the clipboard.

3. Update S2STenantId for the organization by running these commands, where OrganizationName is the unique name of the organization.

Error received during enable server-based authentication wizard

Error: Failed Authentication. This error can be returned when the certificate used for server-to-server authentication is missing or invalid. To resolve, update or install the certificate and try again.

Create an email server profile

1. Go to Settings > Email Configuration > Email Server Profiles.
2. Select New > Exchange Online (Hybrid).
3. For an Exchange email server profile, specify the following details.

4. Select Save.
5. Select Test Connection and review the results. To diagnose issues, see the following section.

Troubleshoot the Exchange Online (Hybrid) profile connection

If you’ve run Test Connection and have issues with the Exchange Online (Hybrid) profile connection, use the information in the Test Connection dialog box to diagnose and fix the connection.

You can find information on recurring issues and other troubleshooting information in Blog: Test and Enable Mailboxes in Microsoft Dynamics CRM 2015 and Troubleshooting and monitoring server-side synchronization.

Configure default email processing and synchronization

Set server-side synchronization to be the default configuration method.

1. Go to Settings > Email Configuration > Email Configuration Settings.
2. Set the processing and synchronization fields as follows:

• Server Profile: The profile you created in the above section.
• Incoming Email: Server-Side Synchronization or Email Router
• Outgoing Email: Server-Side Synchronization or Email Router
• Appointments, Contacts, and Tasks: Server-Side Synchronization or Email Router

Note

If your users primarily use Dynamics 365 for Outlook on their desktop computers, Microsoft Dynamics 365 for Outlook might be a better choice.

If you leave the Email processing form unapproved user and queues at the default values (selected), you will need to approve emails and queues for user mailboxes as directed below in Approve Email.

3. Select OK.

Configure mailboxes

To set mailboxes to use the default profile, you must first set the Server Profile and the delivery method for email, appointments, contacts, and tasks.

In addition to administrator permissions, you must have Read and Write privileges on the Mailbox entity to set the delivery method for the mailbox.

Select one of the following methods:

Edit mailboxes to set the profile and delivery methods

1. Go to Settings > Email Configuration > Mailboxes.
2. Select Active Mailboxes.
3. Select the mailboxes that you want to configure, and then select Edit.
4. In the Change Multiple Records form, under Synchronization Method, set Server Profile to the Exchange Server profile you created earlier.
5. Set Incoming and OutgoingEmail to Server-Side Synchronization or Email Router.
6. Set Appointments, Contacts, and Tasks to Server-Side Synchronization.

Note

If your users primarily use Dynamics 365 for Outlook on their desktop computers, Microsoft Dynamics 365 for Outlook might be a better choice.

7. Select Change.

Approve email

You need to approve each user mailbox or queue before that mailbox can process email.

1. Go to Settings > Email Configuration > Mailboxes.
2. Select Active Mailboxes.
3. Select the mailboxes that you want to approve, and then select More Commands (…) > Approve Email.
4. Select OK.

Test configuration of mailboxes

1. Go to Settings > Email Configuration > Mailboxes.
2. Select Active Mailboxes.
3. Select the mailboxes you want to test, and then select Test & Enable Mailboxes.

This tests the incoming and outgoing email configuration of the selected mailboxes and enables them for email processing. If an error occurs in a mailbox, an alert is shown on the Alerts wall of the mailbox and the profile owner. Depending on the nature of the error, Microsoft Dynamics 365 tries to process the email again after some time or disables the mailbox for email processing.

The result of the email configuration test is displayed in the Incoming Email Status, Outgoing Email Status, and Appointments, Contacts, and Tasks Status fields of a mailbox record. An alert is also generated when the configuration is successfully completed for a mailbox. This alert is shown to the mailbox owner.

Tip

If you’re unable to synchronize contacts, appointments, and tasks for a mailbox, you may want to select the Sync items with Exchange from this Dynamics 365 org only, even if Exchange was set to sync with a different org check box. Read more about this check box.

Test email configuration for all mailboxes associated with an email server profile

1. Go to Settings > Email Configuration > Email Server Profiles.
2. Select the profile you created, and then select Test & Enable Mailboxes.

When you test the email configuration, an asynchronous job runs in the background. It may take a few minutes for the test to be completed. Microsoft Dynamics 365 tests the email configuration of all the mailboxes associated with the Exchange Server profile. For the mailboxes configured with server-side synchronization for synchronizing appointments, tasks, and contacts, it also checks to make sure they’re configured properly.

Tip

If you’re unable to synchronize contacts, appointments, and tasks for a mailbox, you may want to select the Sync items with Exchange from this Dynamics 365 org only, even if Exchange was set to sync with a different org check box. Read more about this check box.

See also

Server-side synchronization
Troubleshooting and monitoring server-side synchronization

Note

Can you tell us about your documentation language preferences? Take a short survey.

The survey will take about seven minutes. No personal data is collected (privacy statement).

This full step-by-step guide is available as a PDF. Please click here to download!

If you are planning an Exchange to Office 365 migration, then it can be quite confusing to understand the steps you need to take and in which order.

In this article, we’ll walk through the steps and decisions you need to take when migrating to Exchange Online. In part one we’ll consider the two most important first steps – deciding upon a migration approach and performing the core steps for identity. In part two, we’ll perform the Exchange Hybrid configuration and perform the migration of Mailboxes.

And, although we’re going to cover a lot of information in a short amount of time, you’ll find detailed guidance linked throughout.

Preparing your Exchange to Office 365 Migration

Before you begin a migration, it’s important to make sure that the source environment you are migrating from is in a good state.

If the Exchange environment you are running today isn’t healthy, then often that can serve as the motivator to move. After all, what can be an easier solution to bad day-to-day Exchange performance than moving to Office 365?

Unfortunately if you are experiencing day-to-day issues with Exchange, such as user issues accessing Exchange remotely, error messages and slow access times to mailboxes – or worse, database corruption – then moving to Office 365 will most likely be another source of trouble; not just for people accessing the environment you are trying to migrate from, but also when migrating as it’s likely you’ll experience failures along the way.

Your first step before beginning a migration should be to ensure that the environment is reasonably error free and correct any underlying issues prior to migration.

Read More: Patching your Exchange Environment

Hybrid migration or tool-based migration?

If you are thinking about moving your Exchange environment to Office 365 then you’re probably aware there are many options available.

From Microsoft, you have options for a Staged Migration and a Cutover Migration as well as a Hybrid Migration, and from third-party vendors a large number of different tools on the market for email archive migrations.

In general, if you have a version of Exchange Server that’s supported by Microsoft (Exchange Server 2010 and above) and it is part of your Active Directory then your default option should be an Exchange Hybrid Migration.

An Exchange Hybrid is based on either minimal or full Exchange Hybrid and creates a relationship between your on-premises Exchange servers and Exchange Online. This allows native mailbox moves, similar to between on-premises Exchange servers, with Outlook clients natively switching over without even needing to re-download offline copies of email. With full Hybrid, this also extends to secure mail flow between the two environments and co-existence functionality like free/busy and calendar sharing.

Azure AD

Azure AD Connect complements Exchange Hybrid, and you should expect to use Hybrid if you plan to synchronize your identity to the cloud. Azure AD Connect synchronizes your local Active Directory domain to Office 365, creating a copy of local AD accounts in Azure Active Directory that link back to the master copies. Azure AD Connect is also the part of the puzzle that maintains a consistent Global Address List between on-premises and the cloud.

Because AD and Azure AD Connect understand when there’s an existing Exchange organization in place, existing mailboxes on-premises won’t have mailboxes created in Office 365. You’ll be expected to use Exchange Hybrid to move mailboxes.

With a tool-based migration, the same rules do not apply. A fully Microsoft-supported Exchange Hybrid migration provides an excellent experience. However, especially in multi-forest environments it can be complex to set up correctly, hosted environments often do not allow for Azure AD Connect or Exchange Hybrid to be configured; and if you have legacy versions of Exchange it can involve installing additional servers running Exchange 2010 or higher which include the Hybrid components. Therefore, there are valid uses for a bespoke tool to migrate email to Office 365 – but in this article, we’ll assume you’ve made the decision to use Exchange Hybrid.

Read More: Methods for migrating to Office 365

Understanding pre-requisites and dependencies

Once you’ve decided that migrating to Office 365 using Exchange Hybrid is suitable for your organization, and you have a healthy environment to migrate, then you need to ensure you’ve completed necessary planning activities.

Many organizations who begin this journey will at this point ensure they have a design in place to support the changes that will take place. However, as you aren’t designing Office 365 or Exchange Online and instead designing the bridge to Office 365 then the design is often not as detailed as a full Exchange migration.

Instead, you are focusing on the changes necessary to your existing environment to make sure it is ready for the changes. In this article, we won’t cover this, but it’s worth remembering that most organizations, large and small, don’t just head into the unknown without making plans first.

The key pre-requisite for migrating to Exchange is ensuring the correct identity model is in place, first. There is a variety of options available when choosing an identity, but the most common scenario will be to utilize Azure AD Connect with synchronized identities and password hash sync.

Prior to this, we’ll perform a number of key tasks.

First, we’ll ensure that we’ve added all of our custom domains to our Office 365 tenant. These will need to match the email domains we use on-premises:

<Portal Domain

To add a new domain, choose <Path> and Add Domain. You’ll need to follow the steps, and verify each domain using a TXT record, similar to the one shown below:

Use your DNS provider’s control panel to add the corresponding TXT record to each domain, then continue the verification process.

Once you reach the point to add additional DNS records, it’s important you choose to Skip adding records such as Autodiscover or MX record changes.

This is crucial because at this point in the process your email is still looked after by on-premises systems, and you do not want to redirect clients to Office 365. The Hybrid relationship we create will manage this for us, later on.

Microsoft Exchange Login

We’ll sign-in to Office 365 using a login ID in the same format as an email address. In an Exchange Hybrid relationship, we expect this to match the Active Directory UserPrincipalName for each user. However, in many organizations, the login IDs are not in a format that will be suitable

In the above example, the issue is with the UserPrincipalName (UPN) suffix – the contoso.local part that typically matches the full AD Forest Name. To resolve this, we’ll add a UPN suffix to match our email domains registered with Office 365 in Active Directory Domains and Trusts:

We’ll then update the UserPrincipalName value for each user using Active Directory users and computers (or, ideally, PowerShell) to match the email address:

In most cases, this will not cause any user issues with sign-in, as nearly all organizations still expect users to login with the Pre-Windows 2000 / CONTOSOusername format. However, you should always validate this before making changes. After making these changes, the formats for login IDs will be similar to below:

We’ll also run the Microsoft IDFix tool against the domain. This step will highlight other issues within your Active Directory relevant to the domain sync. IDFix identifies errors, such as invalid email addresses (known as Proxy Addresses), invalid characters in usernames and other data and common issues, like using an invalid UPN suffix.

Use the list of issues identified by ID to make the corrections recommended, then install Azure AD Connect. In the example below, we’ve chosen Use Express Settings:

We’ll then follow the wizard steps to connect both as a global administrator to our Azure AD/Office 365 tenant, and to our local Active Directory. You’ll remember above though we added an additional UPN suffix to our local AD due to it not being a valid domain to use with Office 365. This will be highlighted during the installation wizard, however, because we’ve dealt with this it will be safe to continue:

Because we chose the Express Settings the wizard has pre-selected that we’ll use Password hash synchronisation. Our final choice is to ensure that an Exchange Hybrid Deployment is selected before beginning the install. This will ensure Azure AD Connect writes-back Exchange-related attributes to our local AD:

Once initial synchronization completes, you should be able to access the Microsoft 365 Admin Center and navigate to Users>Active Users and see synchronized accounts. You’ll see your AD users with a Sync Type of Synced with Active Directory:

Further Reading:

Other areas you’ll need to consider

In addition, before you migrate mailboxes to Office 365, you need to consider other pre-requisites. Key areas you need to consider include:

Legacy Archiving

If you currently use a solution like Veritas Enterprise Vault for archiving or journaling email then this configuration will not work as-is with Office 365. Instead, the most common approach is to move archives to Exchange Online after migrating mailboxes.

In this scenario, stubs (or shortcuts, to use the EV term) will be re-hydrated with the original archive messages; or moved to archive mailboxes in Exchange Online. Quadrotech’s Archive Shuttle can handle this task and works well with an Exchange Hybrid migration.

Outlook clients

You’ll need to run a supported version of Outlook when connecting to Office 365. The following versions of Outlook are supported:

• Office 365 ProPlus
• Outlook 2019
• Outlook 2016
• Outlook 2013

Ideally, use the newest version (Office 365 ProPlus) that you have available. Outlook 2013, 2016 and 2019 will work with Office 365. If you are running Outlook 2010 today, then this can work with Exchange Online but for security reasons you will most likely want to block the protocols it uses.

Mobile devices

If you use Microsoft ActiveSync today to connect to Exchange on-premises, then you can allow mobile devices to continue to use this protocol when connecting to Exchange Online. Expect though in all but the most unusual circumstances to need to reconfigure ActiveSync devices to work with Exchange Online.

Instead, consider deploying the new Outlook mobile client to devices. If you choose to move to Microsoft Intune, then you can also use Intune to deploy and configure the new Outlook client. This supports additionally functionality to ActiveSync including the ability to schedule Teams meetings directly from the client, and new functionality like Focused Inbox. From a security perspective it can ensure that you have control over data, such as attachment downloads.

Internet Publishing

The way you publish Exchange Server to the internet is important for a Hybrid deployment. This used to be crucial for all implementations, however, the new Hybrid Agent means that we can avoid many of the more complex areas for Exchange firewall and SSL certificate configuration for simple deployments.

There are a number of areas you must consider though:

• Autodiscover – In a Hybrid environment the Autodiscover service on-premises will be used by both on-premises mailboxes and Exchange Online mailboxes in Office 365. If you are moving to a model where users can access their mailboxes anywhere, then you will need to publish Autodiscover externally.
• Mail Flow – The Hybrid Agent removes the need to publish Exchange over HTTPS for mailbox moves and free/busy access. However, we’ll still need to allow mail flow between on-premises and Exchange Online. This requires TCP/25 connectivity both to and from Exchange Online Protection.
• Outbound access from Exchange servers to Exchange Online. Although the Hybrid Agent will allow access from Exchange Online to on-premises servers, your servers will still need to connect outbound for both the Hybrid Agent itself, and for requests such as free/busy.
• Client Access to Office 365. You’ll also need to ensure that all Office 365 clients like Outlook can access the service. Ideally this will be direct connection (instead of via a proxy server) accessing Office 365 by the fewest number of hops to the closest Microsoft Point of Presence. Use the Office 365 Network Onboarding Tool as a standing point.

In our example Exchange Organization, we’ve got a valid, third-party SSL certificate configured for Exchange Server for both our SMTP namespace (smtp.exchangelabs.co.uk) and HTTPS (autodiscover.exchangelabs.co.uk and outlook.exchangelabs.co.uk). We’ve allowed direct connectivity outbound on HTTPS to the required Office 365 and Exchange Online IP address ranges and SMTP connectivity to and from Exchange Online Protection.

Microsoft Exchange 365 Sign In

Summary

In part one, we’ve selected the migration method to use for migration to Exchange Online, focusing on a Hybrid migration. We’ve then performed the core pre-requisite step for Exchange Hybrid – synchronizing Active Directory using Azure AD Connect. Finally, we’ve examined other areas, such as archiving, clients and connectivity.

Microsoft Hosted Exchange

In part two, we’ll implement Exchange Hybrid and perform mailbox moves.

Microsoft Exchange 365 Login

Alternatively, you can download the full step-by-step guide here.