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!An update to Important notice for Office 365 email customers who have configured connectors
Since we posted this blog post, we have received positive responses from many of our customers, who have proceeded with changing their connectors (as per instructions in the post), thereby protecting their email/domain reputation. However, we are also aware of customers who are either in the midst of making this change or need some additional time to complete their changes. We understand a change like this can take some time, so we have decided to move our deadline from Feb 1 st , 2017 to July 5 th , 2017. We have also added more details in the original post. If you are an Office 365 email customer and your organization is hybrid (you have an on-premise environment), please take some time to read it! Carolyn LiuImportant 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 Hybrid Agent Preview Update
As you are aware, we released the Microsoft Hybrid Agent for Exchange Server as a preview on Feb. 5 th , 2019. The blog post for that release is located here. We have been busy working on a few improvements for the Hybrid Agent over that past two months and wanted to let you know of some new features now available in the latest build of the Hybrid Configuration Wizard. The three enhancements for the Hybrid Agent are: Multi Agent installation and configuration Agent status views Registration/Usage of a load balancer for the internal URL instead of a specific Exchange Client Access Server Multi Agent Deployment Option 1 – Use the Hybrid Configuration Wizard to install additional agents For existing Hybrid Agent preview customers who would like to install additional Hybrid Agents for redundancy, simply download the latest version of the Hybrid Configuration Wizard (HCW) and open the application on the machine where you would like to install an additional Hybrid Agent. Like previous HCW runs, start the application, select Next. Select a desired server to execute against, select Next. Provide credentials to sign into your Office 365 tenant, select Next. The HCW will gather configuration information, select Next when complete. Select the default option provided for either Full or Minimal, select Next. Select Exchange Modern Hybrid Topology, Next. Agree to the Terms, Next. A new page will be shown that will provide you with the status of your existing / previously installed agent. Make sure the status of the existing agent is accurate before proceeding to the next step. Select Install and additional agent option, Next. Example: The HCW will install the additional Hybrid Agent. When the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running (look for Microsoft Hybrid Service - mshybridsvc). At that point, you can either re-run HCW if you wish to make further changes to your hybrid config, or simply cancel the wizard. You can repeat this step on each machine where you would like an additional Hybrid Agent installed. Option 2 – Manually download & install additional agents A second option for installing additional agents is outside the HCW itself and is done by downloading and manually installing the agent on the desired machine. Go to https://aka.ms/hybridagentinstaller. Save the MSHybridService.msi to a location on your machine. From that machine, open a Windows Command console as Administrator and run: Msiexec /i MSHybridService.msi to install the hybrid agent. You will be prompted for your tenant Global Admin credentials. After the installation is complete, you can open the Microsoft Windows Services console from the machine and verify the service / agent is installed and running. You can repeat this step on each machine where you would like an additional Hybrid Agent installed. Checking the Status of Your Hybrid Agents Option 1 – Get status via the Hybrid Configuration Wizard (HCW) Start the HCW application, select Next. Select a server in your Exchange org, select Next. Provide credentials to sign into your Office 365 tenant, select Next. The HCW will gather configuration information, select Next when complete. Select default option provided for either Full or Minimal, select Next. Select Exchange Modern Hybrid Topology, Next. Agree to the Terms, Next. A new page will be shown that will provide you with the status of your existing installed agents. Cancel the HCW app when you are done. Option 2 – Get status via the Hybrid Management PowerShell Module With each installation of the Hybrid Agent, we install the Hybrid Management PowerShell module in the directory …\Program Files\Microsoft Hybrid Service\ on the machine where the agent is installed. By default, this module is not imported and so you will need to import it before you can use it. This module also requires the Azure module for PowerShell if not already installed. Please install the PackageManagement modules first and then see this article for how to install the Azure module. To import the Hybrid Management module, run the following from a Windows PowerShell prompt as Administrator: Import-module .\HybridManagement.psm1 After that you can run: Get-HybridAgent -credential (get-credential) to view agent status: Note: the ‘id’ value provided in the above snip is the agent identity and not your unique tenant guid assigned to the route. Directing your Hybrid Agent(s) to the load balancer instead of a specific server If you would like your Hybrid Agent(s) to direct requests to your load balancer instead of a specific Exchange Client Access Server, this can be done with the Hybrid Management PowerShell module. In preview, the Hybrid Agent supports routing requests to the load balancer for Exchange Server 2013 – 2019 Client Access Servers. You cannot use this if you only have Exchange Server 2010 CAS deployed. Follow the steps above to import the Hybrid Management module for PowerShell. From PowerShell, then simply use the Update-HybridApplication cmdlet to change the value of the internalURL (targetURI parameter) from a specific server to your load balancer endpoint. Before running this cmdlet you will need to get the unique guid value (e.g. 12345678-1234-1234-1234-1111111111111) of your tenant’s endpoint from either your MRS configuration or the Organization Relationship object (TargetSharingEPR). Example: PS C:\PowerShell> Get-OrganizationRelationship ((Get-OnPremisesOrganization).OrganizationRelationship) | Select-Object TargetSharingEpr TargetSharingEpr ---------------- https://e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx Or PS C:\PowerShell> Get-MigrationEndpoint "Hybrid Migration Endpoint - EWS (Default Web Site)" | Select-Object RemoteServer RemoteServer ------------ e399b770-3b66-407b-a71a-96ef80a67714.resource.mailboxmigration.his.msappproxy.net To be clear, the ID parameter required in this cmdlet is not the agent ID, but the guid listed in your custom registered endpoint retrieved using the method above. Example: We really hope you are enjoying and benefitting from using the Hybrid Agent. We see a lot of usage and we’re working hard to improve it all the time. Thank you! Exchange Hybrid TeamMicrosoft 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 OnlineImportant 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 LiuChange in behavior for delicensed Exchange Online users
Several weeks ago, we enabled a new Office 365 feature to some tenants where the removal of the Exchange License didn’t immediately mail disable the user and disconnected the mailbox. The new behavior then required to manually (via RPS - remote PowerShell) go and run through EXO RPS the Disable-Mailbox -PermanentlyDisable cmdlet to achieve the same result we previously had – a permanent deletion of the disconnected mailbox. Due to extensive feedback from customers we are rolling back this feature to the original behavior in order to improve the feature before we release it again in an easier format (and with better documentation). As of today (10/31/2016) – going forward until feature is re-introduced in the future: The removal of Exchange license from a user will trigger a mail disable operation in Exchange Online as it did before. The user’s mailbox will then be disconnected and will enter a tombstone state. This is not a soft deletion operation; if you want to preserve the mailbox for later recovery please use the Soft Deletion feature or Inactive mailboxes with in-place or litigation hold. Adding the license back to this user within 30 days will result in a ‘best effort’ reconnect with the old content of the mailbox. This is the behavior we had before the change, we are just reverting to it. Note: we have already started the rollback of this feature but it might take about 24 hours until all of our customers see changed behavior. To be safe, please assume that behavior has changed already starting right now. What happens to the users whose license was removed within the time frame of the feature being enabled? We are grand-fathering in these users. The mailbox and user will remain connected and mail enabled for an indefinite amount of time. You have some options for these users: How to find them? Users in this state can be found through EXO remote PowerShell using Get-Mailbox and looking for the SKUAssigned flag in EXO being set to “False”. Sample user with removed license during feature being on: What do I do with them? You have 4 options (since a mailbox without a license has access blocked within 30 days of creation): Soft Deletion: Retention for a short period in case mailbox needs to be recovered. Mailboxes in this state are removed from Exchange after 30 days, at which time they can no longer be recovered. By default, a mailbox is soft-deleted if the user’s Office 365 account is removed. The entire object (including the UPN and identity) are in a soft deletion state across the service. This allows for full data recovery and full re-use of any and all properties of the user in soft deletion state in a new user. Permanent removal (hard-deletion). In this case, the mailbox can no longer be recovered. You can permanently purge a mailbox from Exchange Online by running the Disable-Mailbox cmdlet (UI to come) [PS] C:\> Disable-Mailbox -Identity <User> -PermanentlyDisable The user object also loses Exchange properties in this case; that frees all email/proxy addresses and allows the object to be stamped with External Email address a new. The process requires for you to remove the license, then run the above command and then update the necessary attributes. Retained indefinitely (inactive mailbox). A mailbox becomes inactive if it is under a litigation or in-place hold for compliance or regulatory purposes and is then deleted. Exchange recognizes that the hold exists and retains the mailbox for as long as the hold applies. During this time, the mailbox can be recovered or restored. When the hold is removed, the mailbox is permanently deleted. Add a license back to the user – this will restore access and the mailbox will become fully active. We apologize for the back and forth on this, and realize that we have to do better when releasing features to the service, which the team is committed to doing when we release this feature again. Mario Trigueros SolorioIntroducing the Microsoft Office 365 Hybrid Configuration Wizard
For up-to-date information on Hybrid Configuration Wizard steps, please see Microsoft Docs. The Exchange hybrid team has been working hard over the past year getting the 3 rd version of the Hybrid Configuration Wizard (HCW) ready. This new version is called the Microsoft Office 365 Hybrid Configuration Wizard. This article tells you what’s new and shows you how to run the wizard. We also explain the various issues that have been addressed with the new Wizard, and touch on some of the telemetry we pull with every run of the wizard. We think this new wizard has enough of the old to reduce the learning curve while adding plenty of enhancements to make your hybrid deployment as friction free as possible. Microsoft Office 365 Hybrid Configuration Wizard Stand-Alone Application This version of the HCW is a standalone application that is downloaded from the service. This is an important change because one of the bigger limitations of the previous versions of the HCW was that it was included with the on-premises product. This led to the following issues: Up-To-Date hybrid experience: When you ran the HCW you got the experience consistent with your on-premises version of Exchange Server. This meant that if you are running Exchange 2013 CU7 you got the CU7 experience. If you ran Exchange 2013 CU9 you got the CU9 experience in HCW. Each customer would have a different HCW experience. Solution: The new HCW will download the latest version every time it is run, therefore providing the latest and improved experience. As soon as we make changes to, or fix any issues in the HCW, customers will see the benefits immediately. HCW not tied to Cumulative Updates: Since the previous versions of the HCW were part of the on-premises product they were updated per the regular Exchange Serviceability model. This means that the hybrid team had to wait for a new Cumulative Update (Rollup for Exchange 2010) every three months to deliver any enhancements or changes. For a component like hybrid that is a problem, we have to be agile enough to handle changes not just to on-premises, but also in the service. Solution: Again, every time you attempt to run the HCW we will ensure you have the latest version. This version will of course go through its rounds of validation, but it is in no way tied to the releases of a CU. No more waiting months for fixes! Piloting Changes: As we move forward with this new HCW we will be making some aggressive changes. In the months ahead we want to add more capabilities to HCW. One of the most important changes in HCW will be the ability to roll out feature changes slowly and in a controlled manner. Solution: We have built in the capability to allow customers who are on “first Release” and any other customers we specify (for example TAP customers) to see the latest version of the HCW. Often the latest release and the production release will be the same version, but we do have the ability to pilot versions of the HCW as needed. Improvements to error handling The HCW has a lot of dependencies and relies on various prerequisites for a successful completion. For example, you have to add an external TXT record for the HCW to create the Federation Trust, you have to have your certificates properly installed on your Exchange servers, and you have to have Internet access from your Exchange servers to name a few. I am not trying to scare you away from hybrid, in fact the wizard does walk you through most of the prerequisites. I am instead trying to point out that there are many failure points for the HCW to contend with. Up till now the solution was to provide you an error message that included a stack trace. These error messages are extremely difficult to decipher and often the first reaction after a couple of failed Internet searches was to call into support. Figure 1 shows the old error Experience for those that may not be familiar with it. Figure 1: Old error messages Our goal is to allow you to successfully configure without an error, but we also want to make sure that we give you the information needed to get past any hurdles you may face. Figure 2 shows a sample of the new (much more informative) error experience. In the sample you can see the following major improvements to the error experience: Improved Title: We have added the ability to see what Phase and Task were being completed at the time of the failure. For instance, you can know if we failed at the prerequisite check or configuration phase. You will also immediately know if you failed to create the Organization Relationship or Outbound Connectors. Error code: We have added a new error code for all the possible error messages in the new wizard. You will now see all errors prepended with a code HCW8***. This change allows for our errors to be easily searched and it allows them to remain searchable even if we change the context of the errors. Humans can read the errors: One of the previous challenges was that we provided a stack trace as the error message instead of just a friendly actionable string. We now keep the stack trace in the logs for anyone who may want that information. New “More info” feature: We added the “More info…” option under the error message. We have recently associated a KB or TechNet article as the most likely solution to EVERY error message the HCW throws. Simply click the “More Info…” link and you will be taken to that solution Access to log Files: You can easily access the HCW log file by clicking on the link that says “Open Log File”. In addition, you will find the log file on the system were you ran the new wizard from by going to “%appdata%\Microsoft\Exchange Hybrid Configuration”. Keep in mind the old location for the logs in the Exchange install directory is not used. Coolest addition: When you run the HCW you will more than likely have the Exchange Admin Center already open, but there is a chance that if you run into an issue you will need to use either your on-premises or Exchange Online PowerShell. The new HCW error experience includes a link that will open the on-premises and/or Exchange Online PowerShell. We already have the credentials you entered into the wizard, so you can seamlessly open PowerShell by using those credentials. In addition, we open the Exchange Online PowerShell with a blue background and the Exchange on-premises PowerShell with a black background so you can easily differentiate the two. Figure 2: Awesome error experience Top issues solved by the new HCW About a year ago we came out with a toolto assist you to troubleshoot your hybrid experience. This tool collects and parses the HCW log and provided a link to an article that gave a solution to your issue. The tool has been run thousands of times and has given us great insights into what the top failure points are for the HCW. This telemetry tells us what we need to focus on and allows us to see any failure trends, but in the end we were limited to the information gathered from folks that ran the HCW troubleshooter. Because we want to be as helpful as possible, we now by default upload the HCW logs to the service when you run the new wizard. Gathering this data will allow us to serve you better by limiting the amount of time it takes for someone in support to find out more about your environment and it allows us to see any trending issues and failure points that we need to address. Even with the limited amount of logs we have collected from the troubleshooter, we have been able to identify the following issues and are addressing them in the new HCW. I think you will see why the log collection is so important to the hybrid team. Note: If you want to opt out of uploading the Hybrid logs you can do that by using the registry key below on the machine were you are running the HCW from: 1. Navigate to the following location in the registry, create the path if needed: Exchange 2016: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v16\Update-HybridConfiguration Exchange 2013: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Update-HybridConfiguration 2. Create REG_DWORD “DisableUploadLogs” with value 1 TXT proof string issues Any time you are required to add an DNS entry you are dealing with a potential for failure. HCW includes a step were you need to add a record to an external DNS to prove to the Azure Authorization Service (known as Microsoft Federation Gateway) that you own the domain. This step may seem trivial but it accounts for ~15% of our HCW failures. Usually the TXT proof string get messed up in one of two ways: Incorrect string entered: when creating the DNS record to provide domain ownership we often see that the incorrect value was provided. This is in large part due to the way the HCW copied the value. In the previous version of the HCW, when you copied the TXT string, we prepended the words “Domain Proof” so it looked similar to “Domain Proof = t4jnhkjdesy78hrn…”. Solution: While simple, moving forward we are only going to copy the part of the string that is needed from the “copy link” option in HCW, which should lead to less issues with incorrect TXT strings. Domain name lockouts: The point of providing this TXT string to the external DNS is so the service can validate that you own the domain and federation certificate. After a few failed attempts to validate a domain we lock you out from federating that domain for a few hours. The purpose of this lockout is to prevent a denial of service attack. Often this issue occurs because someone put the wrong value in DNS (see the first bullet), someone created the record and did not wait for replication of the record, or someone created the record in internal (not external) DNS. Solution: To resolve this we created a new external endpoint in the service that will perform the DNS lookup for the TXT record and only try to federate the domain if the record is correct or if that new service endpoint cannot be found. The logic for this is as follows: First we try to hit the new external service endpoint and see if the TXT record is resolvable externally and is correct in DNS. If so, we move forward with federating the domain. If the record is either wrong or not resolvable, we inform you that you need to verify the record and wait for replication. If the new external TXT validation service is not reachable, we will warn you that we could not verify the TXT record but allow you to continue anyway. Figure 3 show the new TXT experience you will be getting with the Microsoft Office 365 Hybrid Configuration Wizard. Figure 3: TXT records Missing Certificate in Wizard The HCW has a screen that asks you for the “Transport Certificate”. The HCW looks to ensure this certificate is installed on every server that you designated to be part of the Send and Receive Connector Configuration, as shown on the pages in Figure 4. Figure 4: Send and Receive Connector In order for the certificate to properly display you need to ensure that the following has been completed on all of the servers designated in the wizard pages shown in figure 4: The Certificate must be a third party trusted certificate. The proper names must be on the certificate such as mail.consoto.com or *.contoso.com. The SMTP service must be assigned to the certificate on each of the sending and receiving servers. The certificates must have a private key. These requirements are nothing new, but if you have a large environment, getting all of this correct on a large number of servers can be a tough task. If even one server was missing any of the requirements, we would fail to show you the certificate. In previous versions of the HCW you were left with a blank screen (see figure 5) which offered no direction or solution. Figure 5: Blank certificate The Microsoft Office 365 Exchange Hybrid Configuration Wizard experience will not remove the certificate requirements, but it will help you solve the issue. The HCW will now show you a list of certificates that meet the requirements, and it will show you the servers that do not have a proper certificate installed (see figure 6). This will allow you to either remove those servers from the HCW receive and send connector pages, or you can properly install the certificate on those servers. Figure 6: Better certificate error A more efficient Hybrid experience One of the things we tried to do with the HCW is ensure that we are performing the various configurations in the most efficient way possible (this is our on-going green effort). A good example of an inefficient task that the HCW previously performed was the Mailbox Replication Service (MRS) enablement process. In the HCW logs collected from the troubleshooter, we could see that this cmdlet was often taking an extremely long time to complete. What we do now, is enable the Migration endpoint on the servers in your environment so that you can start moving mailboxes when the HCW is complete without having to enable the endpoint. One of the cmdlets that we used in the previous version of HCW was get-WebServicesVirtualDirectory. In a larger often geographically dispersed environment this cmdlet could take over eight hours to run. In many cases you would end up getting the following error: ERROR: Updating hybrid configuration failed with error 'Subtask Configure execution failed: Configuring organization relationship settings. Execution of the Set-WebServicesVirtualDirectory cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings. Unable to access the configuration system on the remote server. Make sure that the remote server allows remote configuration Solution: We have resolved this issue in the new HCW using the -ADPropertiesOnly option with Get-WebServicesVirtualDirectory. This changes things so the HCW reads the MRS settings using a local directory call instead of waiting for a response from every server in the environment. This change along with a few others in this area, makes the process take around 15 minutes instead of 8 hours (your deployment times will vary) in these large environments. This is just one example of the type of cleanups we did in the HCW to improve the reliability and speed of the configuration tasks. Autodiscover issues in HCW The single most common failure point for the HCW is the inability to retrieve the Federation Information via the Autodiscover call initiated by the Get-FederationInformation cmdlet. The output of this cmdlet is needed in order to create the Organization Relationships so you can do things like free busy sharing. This accounts for nearly 30% of all HCW failures based on the logs collected from the troubleshooter (are you starting to see the importance of these log files?). When looking at the issue there are certain things the wizard cannot directly address. For instance, at times the issues are related to an improperly configured firewall, or someone doesn’t have a third-party certificate for IIS on the Exchange servers. However, a good portion of you have had things configured correctly and still we failed to complete the Get-FederationInformationcmdlet. One of the things this cmdlet does is use DNS settings from the server you are connected to in order to resolve the Autodiscover endpoint and retrieve the federation information. Many customers do not have a DNS record created for Autodiscover internally since there is often no need for this. The internal Outlook client will use the Service Connection Point to find the Autodiscover endpoint so there is no need for this from an outlook standpoint, however the Get-FederationInformation cmdlet does not use the Service Connection Point. Therefore, if there is no forwarding configured for this zone in DNS the Get-FederationInformationcmdlet will be unable to resolve the autodiscover endpoint and the HCW will fail. Solution: To resolve this issue, we have added a new method for checking for the federation information. We still try to use local DNS first and if it fails we then will try to hit an external service to see if we can get the federation information externally. This will ensure that if you have Autodiscover published properly externally the HCW will complete as expected. See figure 7 for details: Figure 7: Get-FedInfo OAuth Integration Another common failure point is the OAuth portion of the HCW. The HCW today shows you an option to configure OAuth if you are Exchange 2013 native, but not if you coexist with previous versions of the Exchange. OAuth is required for some featurestoday, such as cross premises discovery and automatic archive retention. Because of that, we want to ensure that OAuth is by default configured so all of the Hybrid features work when you complete the HCW. One downside to this is that the current OAuth configuration experience previously had a high rate of failure. We have gone through and fixed a good portion of the experience and we have also added logic to the new HCW so that if the OAuth portion fails we will disable the OAUTH configuration by disabling the IntraOrganizationConnector and let you know we disabled it and give you remediation steps. This will ensure that a failed OAuth configuration does not prevent other hybrid features such as cross premises Free Busy from working. Many more… The above are just a few of the issues that have been addressed with the latest version of the HCW. There are many example that we could have used such as a couple of issues we addressed with mail flow, Multi-Forest deployments, and many more. In this latest version we strived for feature parity, while improvement the failure rate, and allowing for future innovation. We think we have hit the mark. Running the HCW Now that we have covered some of the new features and benefits of running the Microsoft Office 365 Exchange Hybrid Configuration Wizard, let’s take a guided tour. We are not going to go through each option in depth as most of them have not changed from Exchange 2013. How to find the new HCW We have not moved the location of the HCW in the Exchange Admin Center, the entry point look and feel is consistent with previous version of the Exchange 2013 HCW. The only difference is that instead of calling local code when you click “configure” or “modify” in the hybrid node of EAC, we now initiate the click once application. Figure 8 shows the entry point. Figure 8: Entry Point HCW Landing Page The next screen you will see is the HCW landing page, which is a page that serves two purposes. The first and most important purpose is that we can redirect a small subset of customers (based on pre-defined criteria) to an alternate HCW experience. As discussed previously in this blog, this allows us to pilot new features without affecting the production HCW experience. The second benefit of this landing page is that it allows us to provide a proper error message if the browser version, popup blockers, etc. are not configured in a way that would support the HCW. When you are on the landing page you will select the “click here” option to download the HCW. See figure 9 for a view of the landing page. Figure 9: Landing page Welcome Screen The Welcome screen (see figure 10) will provide you with a link that will inform you about what a Hybrid configuration is along with an additional link at the bottom that explains what the HCW application is going to do. The Second link is at the bottom-left of the screen and says What does this application do?On this screen you will simply click next to continue. Figure 10: Welcome screen Server Detection Page The next screen allows you to choose which server you will use to perform your hybrid configuration. This is the machine that the HCW will remote PowerShell into in order to perform all of the hybrid configuration tasks. The selected server must be running a version of Exchange that is within two releases of our currently released Cumulative update. This means at launch the new HCW will work if you are connecting to an Exchange 2013 CU8 or newer version of Exchange. However, when Exchange 2013 CU11 releases you will see that we will no longer allow you to run the new HCW from Exchange 2013 CU8 and will require a minimum of CU9. Keep in mind that even though the HCW will allow you to proceed if you are two versions older than the current release (n-2), we actually only support going one version back for Hybrid (n-1). If for you were to select a server that is running an unsupported version, the HCW will provide you with an error stating that you are not running a supported version. In addition, the HCW will provide you with a list of servers that are running a supported version (if any exist). Figure 11: Unsupported version The HCW will try to select the best server to perform the configuration tasks from using the following logic: First we look to see if the server we are on is running the latest supported version of Exchange in the organization. Next we look to see if there is an existing Exchange server in the site running the latest supported version of Exchange. Finally, we attempt to connect to an out of site Exchange server (typically in a different geographical location) running the latest supported version. If you do not like the server selection the HCW made via the above mentioned detection logic you can manually specify the server name that you want to connect to. You can use the short name (ServerName) or the long name (ServerName.Contoso.com) in the provided box to select the appropriate server running the supported version of Exchange. The last option on this page allows you to select the tenant location. For most the tenant location is simply “Microsoft Office 365” but if your Office 365 is operated by 21 Vianet, you can also use the “21 Vianet” option. Figure 12: Server detection Credentials page The main improvement on this page is the fact that we do not force you to type in your on-premises credentials. However, if you are not signed in as the user with the Organization Management Role you can manually override this behavior and provide separate credentials. Figure 13: Credentials page Connection Status page We will then show you the connection status window, which will let you know if improper credentials were provided on the previous step. Usually this is a pretty uneventful window and you just click next. Figure 14: Connection status Mail flow options page The rest of the questions in the HCW from this page on are related to the mail flow options. The experience and windows you see from this point forward may vary depending on the options selected. For more information on the mail flow options you have please review this article. Figure 15: Mail flow options Receive and Send Connector Configuration This page of the wizard allows you to select the Exchange 2013 and/or Exchange 2016 servers that you intend on configuring for sending and receiving mail for your on-premises environment. You can have a mix of 2013 and 2016 servers selected. We do not allow you to choose Exchange 2010 servers from these menus. Figure 16: Receive Connector Figure 17: Send Connector Certificate selection page We described the enhancements to this certificate selection page previously in the blog, we covered the experience you will get if a valid certificate cannot be found on any one of the Sending and Receiving servers selected on the previous page (figure 16 and figure 17). This certificate page is what you should expect to see when the certificates are installed properly on all servers. In this case you will get a list of certificates that are meeting all of the requirements and installed on all of the selected servers. In most cases the list includes only one certificate that meets the list of requirements. Figure 18: Certificate FQDN for Mail Flow The final question in the wizard will allow the HCW to properly configure the smart host settings on the outbound connector in Exchange Online. You will usually provide the FQDN that matches your MX record in this window. Figure 19: FQDN Update page Up to this point in the HCW there has been no modification made to your on-premises or Exchange Online environment. When you select the update option on this page we will start making the modification based on the answers to the questions you provided on the previous screen. Similar to the old version of the HCW we will store those answer in the local Active Directory in a configuration object known as your desired state. We will then read from that configuration object to make the modification. Figure 20: Update Wrapping this up The Exchange hybrid configuration process is something that has evolved rapidly over the past few years. We have done a lot over that time to simplify these complex configurations. With this latest version we have continued that trend by adding flexibility for innovation, more HCW stability, better HCW performance, a cleaner configuration experience, and (if needed) a proper error experience. However, our tools and services are built for you so let us know what you think, when you try out the wizard send us feedback through the feedback widget in the HCW. Just look for the “give feedback” link on the bottom of the page in the wizard and please rate the experience. The Exchange Hybrid Team
