Learn what's next for Exchange and Office 365 at Ignite - Full session list now available
This morning we released the complete list of sessions offered at Microsoft Ignite, including the full list of Exchange sessions. Ignite is the premier event for the Exchange community, bringing together the people who build Exchange and those who work with it every day. If you are one of the many Microsoft Exchange Conference (MEC) alumni, Ignite is the evolution of MEC. Be there as we talk about what’s coming next in Exchange, announce new Office 365 innovations and share our overall technology vision and strategy. Deep technical content At Ignite, we’ll have over 65 breakout sessions dedicated to Exchange on-premises and online, 9 hands-on-labs (HOLs) and 2 pre-day offerings for Exchange IT Pros – many of these offerings presented for the first time at Ignite. You will hear from Exchange engineering, deployment and support teams, as well as independent MVP experts. Ignite offers more than just Exchange content, providing easy access to a broad set of content across Microsoft technologies. You will find over 550 sessions ready for selection at Ignite. So go broad and deep with leading experts from Microsoft and the community on topics ranging from product overview, best practices, how-to, deep-dives, vision and roadmap – tailored by role, level, and specific interests. Here as few sessions you will find on the agenda for Ignite. Title Speaker Level Exchange Server Preferred Architecture Ross Smith IV 300 Under the Hood with DAGs Tim McMichael 400 Exchange Hybrid: Make Office 365 Work for You Michael Van Horenbeeck and Timothy Heeney 300 Experts Unplugged: Exchange Top Issues Exchange and Office 365 Support Teams 300 MVPs Unplugged: The Journey to Microsoft Exchange Online Exchange MVPs 300 View all sessions featuring Exchange product technology here. Unrivaled community & networking opportunities If you’ve been to MEC in the past, you know the real magic happens with the connections you make on site – impromptu geek-out whiteboard sessions, ad-hoc syncs and afterhours at the big and small parties. We are building a complete Ignite experience to deliver opportunities to network at Ignite as Exchange MVP Jason Sherry shared with us early in the Ignite planning process. "The key thing for me is the networking and open dialog that can easily be had with anyone there. Easy access to my peers and product group. We powwow and can then walk to sessions together. Interacting with your peers and socializing is the biggest benefit." – Jason Sherry, Exchange MVP & MEC Alumni, @JasonSherry We’re hosting six large theaters in the spacious expo hall at the event to serve as community zones – these provide a platform for community leaders to share their knowledge and experience with attendees as well as comfortable meeting places for the spontaneous conversations that crop up. The content in these theaters is 100% community-driven; you can expect community-run panel discussions, short fire-starter sessions in which you share an idea with the community and get immediate feedback and birds of a feather session in which people with similar interests gather for discussion, and maybe some of that ‘controlled chaos with clarity’ this community is known for. Mealtimes and after hours provide a whole new slew of opportunities to network and make connections, from scheduled events including the Welcome Reception Monday night and Attendee Party Thursday night to more informal gatherings including meal-time mashups with seating by topic or geography so every meal at the conference becomes a chance to meet someone with similar interests. Join in Register today and join us at Ignite!Important notice for Office 365 email customers who have configured connectors
If you are an Exchange Online or Exchange Online Protection (EOP) customer and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action before the deadline (July 5th, 2017). If your organization has a hybrid deployment (on-premises plus Office 365), you often need to relay emails to the Internet via Office 365—i.e. emails from your on-premises environment (mailboxes, applications, scanners, fax machines, etc.) that are sent to Internet recipients will be routed to Office 365 first, then sent out. Figure: Email relayed from your on-premises email servers to the Internet via Office 365 For this relay to work, your organization needs to follow these steps: Create one or more connectors in Office 365 to authenticate emails coming from your on-premises mail servers, using either the sending IP address or a certificate. Configure your on-premises servers to relay via Office 365. Configure your setup so that: a) The sender domain belongs to your organization (i.e. you have registered your domain with Office 365). For more information, see Add Domains in Office 365. OR b) Your on-premises email server is configured to use a certificate to send email to Office 365, and the CN (Common-Name) or SAN (Subject Alternate Name) in the certificate contains a domain name you have registered with Office 365 and you have created a certificate based connector in Office 365 with that domain. If neither step 3a nor 3b is true, Office 365 will NOT be able to know deterministically whether the email sent from your on-premises environment belongs to your organization. Therefore, it is important that organizations with hybrid deployments ensure that they fulfill either step 3a or 3b. This protects your organization, your domain, and your IP reputation. Beginning July 5, 2017 (changed from Feb. 1, 2017), Office 365 will no longer support relaying emails if a hybrid customer has not configured either step 3a or 3b (see detail above). Such emails will get rejected with the following error message: “550 5.7.64 Relay Access Denied ATTR36. For more details please refer to https://support.microsoft.com/kb/3169958.″ Additionally, if your organization needs the following scenarios to continue to work (and most hybrid organizations do), you need to ensure that you follow step 3b. Your organization needs to send NDR (Non-Delivery Report) or bounce messages to a recipient on the Internet and needs to relay them through Office 365. You need to send emails on behalf of domains that do not belong to your organization. Your on-premises users have forwarding rules configured, and messages need to be relayed through Office 365. For example: Contoso.com is your organization’s domain. A user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding of all her messages to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization. Figure: When step 3b is followed, a forwarded email from contoso.com will be allowed to be relayed via Office 365 For more details, see the step-by-step instructions below. Create or Edit a certificate-based connector in Office 365 For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps. 1. Sign in to Office 365 admin center, and go to Admin > Exchange. 2. Go to mail flow > connectors, and do one of the following: If there are no connectors, choose ’+’ (Add) to create a connector. If a connector already exists, select the connector, and choose Edit to modify it. 3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your On-premises server is the sending source for your messages. 4. Enter connector name and other information, and then choose Next. 5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match the CN name or SAN in the certificate you are using to send email and this domain must be a domain you have registered with Office 365 (see Add Domains in Office 365). For example: The certificate you plan to use has CN or SAN as contoso.com. In that case, you can enter contoso.com in the dialog below and register contoso.com in Office 365 (see Add Domains in Office 365) The certificate you plan to use has CN or SAN as <hostname>.contoso.com or mail.contoso.com. In that case, you could enter *.contoso.com in the dialog below, and register contoso.com in Office 365 (see Add Domains in Office 365) Note: Existing hybrid customers that used the Hybrid Configuration Wizard to configure their connectors SHOULD check their existing connector and ensure that it is using *.contoso.com instead of mail.contoso.com or <hostname>.contoso.com, since mail.contoso.com or <hostname>.contoso.com may not be a registered domains with Office 365. Register your domain with Office 365 You can follow the steps to register your domain here - Add Domains in Office 365. Go to Setup > Domains in the O365 Admin Center to see the list of domains registered: Prepare your on-premises email servers to relay messages through Office 365 If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access. For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365. Carolyn LiuMicrosoft Ignite 2018 - The Recap
Microsoft Ignite 2018 ended a few weeks ago, and what a great event it was. It was great to see so many of our customers, partners and friends there – thank you for coming to our sessions, thank you for coming to the booth, thank you for hanging out with us whenever the opportunity arose and thank you for giving us great feedback on what we’re doing. We’re still recovering but we heard you and are focused on doing a better job because of it. All of the sessions were recorded this year, and so here’s a handy reference to all the sessions in the Exchange and Outlook track, and some others we think you’ll find interesting, so you can refer back here whenever you want to find one. You will need an account in Tech Community to access them, but that’s something you should have anyway. So here’s a long list of sessions, in no particular order but grouped by technology as much as possible. Exchange Welcome to Exchange 2019! Panel discussion: Microsoft Exchange/Calendar/OWA Hybrid Exchange – Making it easier and faster to move to the cloud Scott Schnoll's Exchange and Office 365 Tips & Tricks Securing Exchange Online from Modern Threats So long and thanks for all the (email) phish Email Search in a Flash! Accelerating Exchange 2019 with SSDs Turbo charge your Exchange on-premises and Hybrid environment – Notes from the field How to add MFA to your Exchange On-Prem/Online mailboxes in 20 minutes or less Preparing to Move (or remove) Those Public Folders to the Cloud Why do we need to keep an Exchange Server on-premises when we move to the cloud? Making the best of the cloud: How Exchange Online is different from Exchange on-premises Azure Information Protection and Exchange Online - better together Securing your Office 365 environment from advanced phishing campaigns with Office 365 Advanced Threat Protection Outlook Deep dive into what’s new and coming soon to Outlook for Windows and Mac Outlook mobile in the Enterprise Deploying Outlook mobile securely in the enterprise What's Amazing and New in Calendaring in Outlook! Outlook on the web - What's new and why you should care! The Best (Outlook driven) Day of Your Life Success through people with LinkedIn and Microsoft 365 What's New in groups in Outlook Panel discussion: Microsoft Outlook (Windows, Mac, and Mobile) Let the intelligence built into Outlook help you to make time for what really matters Simple room booking in Outlook using new built-in Intelligence The Power of People in Outlook Security made real with Outlook mobile in-app experiences Outlook on the web: Don’t block your users, restrict them with conditional access/limited access! Adaptive Cards in Teams, Windows, Outlook and your own applications Create engaging, powerful new business processes in Microsoft Outlook with Adaptive Cards Office 365 Notes from the field: how we moved a large global bank to Office 365 Office 365 – Marriages, Divorces and Adoptions Getting stuff done: Solving Office 365 problems with PowerShell How to be an author and write about Office 365 Real-world best practices for managing Office 365 groups Embrace Office 365 Groups: What's new and how to get started Office 365 Groups automation inside-out Delivering Office 365 as an evergreen service: What to do, and more importantly, what not to do Understanding how Microsoft Information Protection capabilities work together to protect sensitive information across devices, apps, and services Secure enterprise productivity with Office 365 threat protection services including EOP, ATP, and Threat Intelligence Strategies for building effective, optimal and future proof connectivity to Office 365 that will delight your users Implementing a modern network architecture to get the most out of Office 365 Addressing global data residency needs with Multi-Geo in Office 365 Podcasts/Broadcasts Ross Smith IV & Greg Taylor on theCUBE Scott Schnoll & Jeff Mealiffe on theCUBE Ross Smith IV on Channel 9 talking about Outlook mobile Greg Taylor on Channel 9 talking about Exchange Server 2019 Greg Taylor, Tony Redmond and Paul Robichaux – Office 365 Exposed talking about random stuff It’s possible we missed a session you think we should have included (there were 750 or more after all), if so, add it to the comments section so people can find it. Thanks! Happy watching! And see you next year for more of the same. Microsoft Ignite 2019 here we come! Greg Taylor Director of Product Marketing Exchange Server and OnlineTooManyBadItemsPermanentException error when migrating to Exchange Online?
Some of you may have noticed that more migrations might be failing due to encountering 'too many bad items'. Upon closer review, you may notice that the migration report contains entries referencing corrupted items and being unable to translate principals. I wanted to take a few minutes and provide more information to help understand what this means, why these are now occurring, and what can be done about them. Ready to geek out? During a mailbox migration, there are several stages we go through. We start off with copying the folder hierarchy (including any views associated with those folders), then perform an initial copy of the data (what we call the Initial Sync). Once the initial data copy process is complete, we then copy rules and security descriptors. Reviewing a move report shows entries similar to these. Stage: CreatingFolderHierarchy. Percent complete: 10 Initializing folder hierarchy from mailbox <guid>: X folders total Folder hierarchy initialized for mailbox <guid>: X folders created Stage: LoadingMessages Copying messages is complete. Copying rules and security descriptors. For our discussion today, we are interested in the stage of “Copying rules and security descriptors”. Security descriptors are Access Control Lists (ACLs), which are then comprised of Access Control Entries (ACEs, or the individual permissions entries) and stored in SDDL format. In the context of a mailbox, we include both the Mailbox security descriptor (Mailbox permissions) as well as Folder security descriptors (permissions on individual folders). When we look at the Mailbox Security descriptor, it should be noted that only Explicit mailbox permissions are copied. These would include permissions granted by using the Add-MailboxPermission cmdlet, by using the Exchange Management Console (2010) or Exchange Admin Center (2013 and 2016) to add Full Access rights. Any Inherited permissions are not evaluated during the copy process. For example, granting the Receive-As permission on a database object in Active Directory results in an Inherited Allow for Full Access for all mailboxes on that database. When mailboxes on that database are migrated to Exchange Online, those Inherited permissions will not get copied. Now that we have briefly covered security descriptors, let’s look at the issue. About midway through 2016, a change was introduced to Exchange Online whereby if a security principal could not be successfully validated/mapped to an Exchange Online object, it would be marked as a bad item. Previously, the behavior was that invalid permissions would simply be ignored, and administrators were then left to wonder why some permissions no longer worked after the migration. With this new behavior, corrupt/invalid permissions are now logged so that administrators will know that there are problems with permissions. From my perspective as a Support Engineer, this is a change for the better because as Administrators, you are now able to see when there are issues with permissions. It is possible that this behavior will continue to evolve over time, but I would advise to become familiar with this new behavior so that you understand what is happening. Now how does this affect you? Since we are now incrementing the bad item count for each corrupt/invalid permission, this means that if we encounter more corrupt/invalid permissions than your current bad item limit is set to (default is 10 for a migration batch), the migration will fail. Depending on the state of permissions, you could potentially see a LOT of bad entries being logged. If you are looking at the migration report text file (downloadable from the Exchange Online Portal), you may see entries similar to the following: 11/12/2016 8:44:43 AM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals for folder "Folder Name"/"FolderNTSD": Failed to find a principal from the source forest. 5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: Alias: <alias>; DisplayName: <Display Name>; MailboxGuid: <mailbox guid>; SID: <SID of User>; ObjectGuid: <Object GUID>; LegDN: <legacyExchangeDN>; Proxies: [X500:<legacyExchagneDN format>; SMTP:user@contoso.com;];. 5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: <SID of User>; ObjectGuid: <Object GUID>;. So, what is the logic used to validate permissions? I’m glad you asked! Here is the process spelled out. There are four basic steps to this process, broken out as follows. Exchange Online - I need to resolve this SID which is present in the security descriptor (Folder or Mailbox) Exchange Online - Make a request to the On-Premises MRS Proxy, passing the SID to resolve On-Premises MRS Proxy - Look up the SID against Active Directory and return a set of attributes (including primary SID and legacyExchangeDN) Exchange Online – Take the legExchangeDN value provided, and attempt to match it up with a user account in the cloud which has that stamped as an X500 proxy address. Normally, Directory Synchronization will take care of stamping the legacyExchangeDN from each side as an X500 proxy address, but this does mean that the On-Premises legacyExchangeDN must match a Mail-enabled recipient (i.e. Mailbox, MailUser, Mail-enabled Security Group) in the cloud by an X500 Proxy. If it does not, then resolving that permission entry will fail. I do want to differentiate between the different types of permissions errors you may see. SourcePrincipalMappingException – these mean that when MRS Proxy tried to look up the SID against On-Premises Active Directory, it couldn’t be resolved. This is a common scenario when users leave the company and their accounts are deleted. You could also encounter these issues if the SID in question is part of the SIDHistory of an On-Premises account. When MRS Proxy attempts to look up the SID, we only search by ObjectSID or msExchMasterAccountSID. MRS Proxy does not evaluate against SIDHistory, so the SID failing to be resolved would be expected behavior. SIDHistory being populated won’t be a common scenario, but it is nonetheless something to be aware of. Note: Exchange Online has a special built-in bad item limit of 1000 for these Source Principal Mapping errors, so these moves will not fail unless you encounter more than 1000 of these types of bad items. TargetPrincipalMappingException – these mean that we can’t map the permission to a user account in the Target forest (Exchange Online). A common scenario here would be if a user or group was given permissions on a mailbox, but that user or group is not in your dirsync scope. After trying to move that mailbox via MRS, that user or group is not going to be present in Exchange Online, so this error would be expected. Another scenario is if a security group (not mail-enabled!) was used to assign permissions. Non mail-enabled security groups are not synchronized to Exchange Online, so they won’t exist in the Target forest. To resolve this issue, there are really two options. Increase the bad item limit to account for permissions errors. In complex legacy environments where multiple Exchange versions have been in place, and there has been a lot of user turnover, I’ve seen where permissions errors can number into the thousands. Be prepared that you may need to increase the bad item limit to a number higher than you expect. The good news here is that with improvement to Exchange over the years, the odds of encountering actual bad messages is relatively slim, so odds are good that the vast majority of bad items are bad permissions. The second bit of good news here is that we log the type of bad item that is encountered and make this information available in the move report. I’ll show you how to dig into a move report and look at the bad items later on in this blog post. Cancel the move, fix the bad permissions from the folder or mailbox by either removing them or fixing the issue causing the user/group to not be resolved in Exchange Online, and then submit the move again. But – you may ask – what if I want to fix the permissions on the current move and then resume it? Well, I’m not going to stop you from fixing bad permissions. But I will tell you that it won’t make any difference for the current move. We only evaluate permissions once, at the end of the initial data copy. If the move fails due to bad items (permissions), even if you fix the bad permissions we won’t re-evaluate the now fixed-up permissions and allow the move to complete successfully. You either have to up the bad item limit, or remove the move and fix the permissions and submit a new move. Now, I promised earlier that I would go through how to review the permissions errors. You can do this by using PowerShell and saving the move report into a variable where it is stored in memory. I typically have the move report exported out to an XML file because I don’t have direct access to customer tenant information. If you are reviewing failed moves within your own tenant, there is no need to do that if you don’t want. I’ll provide the context to do both just in case you want to know both methods. To save the move report to a variable, you would run the following from PowerShell connected to Exchange Online. $movereport = Get-MoveRequestStatistics <move request identity> -IncludeReport To save the move report to an XML file, then import the XML file into PowerShell, you would run the following from PowerShell connected to Exchange Online. Get-MoveRequestStatistics <move request identity> -IncludeReport | Export-CliXml c:\temp\movereport.xml Once the file is saved, then you import it into PowerShell. Note that this PowerShell instance does not have to be connected to Exchange Online. It can be just a regular PowerShell instance. $movereport = Import-CliXml c:\temp\movereport.xml If you never dug into a move report, let me just say that there are all sorts of golden nuggets of information buried inside (which won’t show in the text file from the Portal, by the way!) Now that you have the move report imported as a variable, you can access all the rich information within the report. We specified our variable earlier as $movereport, so we just need to call that variable, and access the information stored inside it. $movereport.report.baditems – this gives you a list of all the bad items encountered. A cool tip is that you can use the Out-GridView PowerShell function to open another window with the list. $movereport.report.baditems | Out-GridView What is nice about the Grid View is that you can then filter the output. For example, to validate that all of your bad items are permissions errors, you can simply choose “Add criteria”, check the “Kind” box, and click “Add”. Change “Contains” to “Does not contain”, and type Security. This will quickly show you if there are any other types of bad items. Now that we have identified the behavior change, and gone over how to address it, let’s end by talking about what approach should be taken for migrating mailboxes. The recommended approach to this new change in behavior would be to continue to migrate using low bad item counts, and then manually remediate those that fail. We recommend this approach because migrations that fail would indicate either a LOT of bad source permissions (more than 1000), or it indicates there are valid, working permissions On-Premises that are failing to be correctly mapped to objects in Exchange Online. Both of these conditions should not be common, so investigation would be warranted to ensure that you are in fact dealing with bad permissions. Special thanks to Brad Hughes and the rest of the MRS team for their assistance and review of this content. Ben WinzenzImportant notice for Office 365 email customers who have configured connectors
Note: This post, originally published in March, got accidentally re-published on 8/23/16 when updating step 5 below. We are leaving it published as a reminder to our customers as the time for this change is now closer. If you are an Exchange Online or Exchange Online Protection (EOP) customer and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action before the deadline (July 5th, 2017). If your organization has a hybrid deployment (on-premises plus Office 365), you often need to relay emails to the Internet via Office 365—i.e. emails from your on-premises environment (mailboxes, applications, scanners, fax machines, etc.) that are sent to Internet recipients will be routed to Office 365 first, then sent out. Figure: Email relayed from your on-premises email servers to the Internet via Office 365 For this relay to work, your organization needs to follow these steps: Create one or more connectors in Office 365 to authenticate emails coming from your on-premises mail servers, using either the sending IP address or a certificate. Configure your on-premises servers to relay via Office 365. Configure your setup so that: a) The sender domain belongs to your organization (i.e. you have registered your domain with Office 365). For more information, see Add Domains in Office 365. OR b) Your on-premises email server is configured to use a certificate to send email to Office 365, and the CN (Common-Name) or SAN (Subject Alternate Name) in the certificate contains a domain name you have registered with Office 365 and you have created a certificate based connector in Office 365 with that domain. If neither step 3a nor 3b is true, Office 365 will NOT be able to know deterministically whether the email sent from your on-premises environment belongs to your organization. Therefore, it is important that organizations with hybrid deployments ensure that they fulfill either step 3a or 3b. This protects your organization, your domain, and your IP reputation. Beginning July 5, 2017 (changed from Feb. 1, 2017), Office 365 will no longer support relaying emails if a hybrid customer has not configured either step 3a or 3b (see detail above). Such emails will get rejected with the following error message: “550 5.7.64 Relay Access Denied ATTR36. For more details please refer to https://support.microsoft.com/kb/3169958.″ Additionally, if your organization needs the following scenarios to continue to work (and most hybrid organizations do), you need to ensure that you follow step 3b. Your organization needs to send NDR (Non-Delivery Report) or bounce messages to a recipient on the Internet and needs to relay them through Office 365. You need to send emails on behalf of domains that do not belong to your organization. Your on-premises users have forwarding rules configured, and messages need to be relayed through Office 365. For example: Contoso.com is your organization’s domain. A user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding of all her messages to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization. Figure: When step 3b is followed, a forwarded email from contoso.com will be allowed to be relayed via Office 365 For more details, see the step-by-step instructions below. Create or Edit a certificate-based connector in Office 365 For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps. 1. Sign in to Office 365 admin center, and go to Admin > Exchange. 2. Go to mail flow > connectors, and do one of the following: If there are no connectors, choose ’+’ (Add) to create a connector. If a connector already exists, select the connector, and choose Edit to modify it. 3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your On-premises server is the sending source for your messages. 4. Enter connector name and other information, and then choose Next. 5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match the CN name or SAN in the certificate you are using to send email and this domain must be a domain you have registered with Office 365 (see Add Domains in Office 365). For example: The certificate you plan to use has CN or SAN as contoso.com. In that case, you can enter contoso.com in the dialog below and register contoso.com in Office 365 (see Add Domains in Office 365) The certificate you plan to use has CN or SAN as <hostname>.contoso.com or mail.contoso.com. In that case, you could enter *.contoso.com in the dialog below, and register contoso.com in Office 365 (see Add Domains in Office 365) Note: Existing hybrid customers that used the Hybrid Configuration Wizard to configure their connectors SHOULD check their existing connector and ensure that it is using *.contoso.com instead of mail.contoso.com or <hostname>.contoso.com, since mail.contoso.com or <hostname>.contoso.com may not be a registered domains with Office 365. Register your domain with Office 365 You can follow the steps to register your domain here - Add Domains in Office 365. Go to Setup > Domains in the O365 Admin Center to see the list of domains registered: Prepare your on-premises email servers to relay messages through Office 365 If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access. For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365. Carolyn Liu
