Permanently Clear Previous Mailbox Info
We are introducing a new parameter that can be called by using the Set-User cmdlet in Exchange Online PowerShell. The feature is focused for customers doing migration of on-premises mailboxes to the cloud and you will be able to use it within three weeks or so (Edit 1/19: we updated this due to slower than expected rollout): Customers who have Hybrid or on-premises environments with AAD Connect / Dir Sync may have faced the following scenario: User Jon@contoso.com has a mailbox on-premises. Jon is represented as a Mail User in the cloud. You are synchronizing the on-premises directory to the cloud in preparation to migrate to Exchange Online. Due to issues with the on-premises sync or due to a configuration problem, the user Jon@contoso.com does not get the ExchangeGUID synchronized from on-premises to the cloud. If the Exchange GUID is missing from the object in the cloud, assigning an Exchange license to Jon@contoso.com will cause Exchange Online to give the user a mailbox, converting the object from a Mail User to a User Mailbox. (Adding the license is a step required for the migration of the mailbox from on-premises to the cloud.) The end result is the user that has 2 mailboxes: one on-premises and one in the cloud. This is not good. Mail flow issues will follow. Those doing these types of migrations will know that the ExchangeGUID value is very important as it helps Exchange Online identify that the user has a mailbox on-premises, and if an Exchange license is assigned in the cloud, a new mailbox should not be created. The immediate fix for this situation is to remove the Exchange License from Jon@contoso.com. This will convert the cloud object for Jon back to a Mail User. Mail flow should be restored at this point. The problem now is that you have an “unclean” cloud object for Jon. This is because Exchange online keeps pointers that indicate that there used to be a mailbox in the cloud for this user: PS C:\WINDOWS\system32> Get-User Jon@contoso.com | Select name,*Recipient* Name PreviousRecipientTypeDetails RecipientType RecipientTypeDetails ---- ---------------------------- ------------- -------------------- Jon UserMailbox MailUser MailUser Re-assigning the license after that will always err on the side of caution and Exchange Online will try to re-connect the (duplicate, temporary) mailbox in the cloud (and mailboxes can be reconnected for 30 days). Therefore Jon’s account in the cloud can’t be licensed in preparation for migration. Up to now, one of the few options to fix this problem was to delete *only in the cloud* Jon’s object and re-sync it from on-premises. This would delete jon@contoso.com from the cloud – but from all workloads, not only Exchange. This is problematic because Jon could have his OneDrive or SharePoint data in the cloud only and deleting his account means that this will be deleted too. If the account is then re-created, Jon and the tenant admin would have to work to recover to his new account all the data he used to have in OneDrive or SharePoint just because Exchange data needed to be “cleaned up”. The new parameter in the user cmdlet will allow tenant admin to clean up Exchange Online Jon’s object without having to delete it. To clean the object, you can run the following command: PS C:\> Set-User Jon@contoso.com -PermanentlyClearPreviousMailboxInfo Confirm Are you sure you want to perform this action? Delete all existing information about user “Jon@contoso.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY. Do you want to continue? Yes Yes to All No No to All [?] Help (default is "Y"): Y Executing this leaves you with a clean object that can be re-licensed without causing the 2-mailbox problem. Now you can on-board Jon’s on-premises mailbox following the usual steps. An alternative – a call to support to do the clean-up for you - is also not needed. Remember, cleaning up the user means that the older associated disconnected (duplicate) cloud mailbox is not recoverable. If you want to keep it or be able to check it’s content, we recommend using Soft Deletion or Inactive Mailboxes to keep the mailbox. Note: This command is expected to be executed when you have an on-premises mailbox and a mailbox in the cloud for the same object due to bad AAD Connect configuration, to clean the object that can be re-licensed. The procedure allows you get out of the dual mailbox state and enable you to re-try on-boarding the mailbox immediately. If you execute this for a user whose mailbox is cloud only after delicensing the user (and intend to later re-license the same user and expect to have a new clean mailbox for the user) - then this will not happen immediately. To avoid potential loss of mailbox data due to unintended/mistaken execution of the command, we retain the mailbox data for 30 days so that you may recover it. If your intention is to clean-up cloud only mailbox then you may hard delete the user account to re-create a clean mailbox. Mario Trigueros SolorioCalendaring is Really Hard to Code and That’s Why You Were An Hour Late to that Meeting
Writing code for calendaring features is hard. You finally figure out a good time for your team to meet and then one of the attendees happens to live in a country that decided to implement Daylight Saving Time (DST) and change the local time by an hour. Just in that country. Here's some advice on what to do and how to handle it.Demystifying Hybrid Free/Busy: what are the moving parts?
Hybrid Free/Busy is one of those things that many people do not fully understand. If everything works well, the complexity is hidden from view and people working in various parts of organization can seamlessly work together. But if things go wrong… you will appreciate deeper understanding of what makes it work. This is why we wanted to create the blog post series on the subject. In this article, we will discuss how Free/Busy works in an Exchange Hybrid configuration. In next blog post, you will learn what we (Microsoft Support) see as the most common problems along with how we go about diagnosing those (often) complex issues. Hope you like reading, because there is a lot to cover! So, what is Free/Busy? Free/Busy is a feature that allows you to see when others are free (their calendar shows availability), busy (their calendar shows them as busy), or even Out of Office, or Something Else (tentative or working away) so that you can find an appropriate time for your meetings. Calling it all “Free/Busy/OOF/Something-Else” didn’t sound so cool to marketing hence “Free/Busy”. In a Hybrid deployment, we usually have some mailboxes in Exchange On-Premises and some mailboxes in Exchange Online (users are in different premises) and this has to work there too. One of the most important parts in Hybrid Configurations is the Federation Trust and many features, including Free/Busy can rely upon this. A quick overview of a hybrid deployment with a focus on Federation Trust components In Contoso – On-Premises side we have on-premises Exchange Servers and mailboxes. We also have a federation trust with the Microsoft Federated Gateway (MFG) - now called Azure Authentication System. A Federation trust is not set by default for Exchange On-Premises organizations and we can either create it manually or run the Hybrid Configuration Wizard (HCW) which will do this for us. If you don’t have already a federation trust established on-premises (usually for purposes to share F/B with another on-premises organization) and you plan for a Hybrid deployment, then we strongly recommend you run HCW to automatically create the Federation Trust. In Contoso – Cloud Side there are Office 365 Exchange Online servers, your Office 365 tenant and mailboxes migrated from on-premises. A Federation trust with the MFG is automatically created for cloud-only-based Exchange organizations whom do not have a Hybrid relationship to an on-premises organization. If you run Get-FederationTrust cmdlet in Exchange Online PowerShell (see here how to connect to Exchange Online PowerShell) you would see two trusts: “WindowsLiveId” (Consumer Instance of Microsoft Federation Gateway) and “MicrosoftOnline” (Business Instance of Microsoft Federation Gateway) . Note: As a troubleshooting tip, you might want to make sure the Application Identifier is “260563” and the Application Uri is “outlook.com” for both; in case you have a different App ID (292841) and a different App URI (outlook.live.com) for a Cloud trust, this means your tenant has an old reference pointing to MFG and most probably Free/Busy from on-premises to cloud would fail with a quite generic 401 Unauthorized error. If you were to find yourself in a such situation, please open a support case with Microsoft to get it resolved. About Free/Busy lookup directionality To guide you to the correct troubleshooting steps we first need to determine what direction Free/Busy queries are failing in. Understanding how Free/Busy works in general and the direction that lookups are failing can greatly simplify the troubleshooting steps. Simply said, there are 2 possible Free/Busy directions (referring to our example above): When Joe looks up Jane’s Free/Busy, the Free/Busy direction is On-premises to Cloud. When Jane looks up Joe’s Free/Busy, the Free/Busy direction is Cloud to On-Premises Now that you are familiar with the Free/Busy directions, we should take a moment to discuss how it all works. Let me set the stage for the below diagram: joe@contoso.com has his mailbox in Exchange on-premises and jane@contoso.com has been moved to Exchange Online. In Exchange on-premises, joe@contoso.com is a Mailbox User. Because Directory Synchronization is a requirement for Hybrid Deployments, joe@contoso.com (mailbox) is synced to the cloud and represented as a Mail Enabled User (MEU) object in Cloud with Target Address (TA) of joe@contoso.com. jane@contoso.com was once a Mailbox User in Exchange on-premises. Her mailbox was then migrated to Exchange Online. Jane now has a Mailbox User in Exchange Online and is represented as a Remote Mailbox (RM) object in Exchange On-Premises. Jane has a Primary SMTP address (SMTP: jane@contoso.com) and a secondary smtp address (smtp: jane@contoso.mail.onmicrosoft.com). Notice how we refer to a primary email address (SMTP) and to a secondary email address (smtp). According to TechNet, the difference between primary and secondary addresses is that the primary address serves as the return e-mail address. When mail is received from a recipient, the primary address determines which address the mail appears to have come from. Recipients can receive mail sent to any of the addresses associated with them (primary or secondary). The Target Address (TA) of the on-premises Remote Mailbox object is represented as jane@tenant.mail.onmicrosoft.com (secondary smtp) and this is crucial for Autodiscover and email routing from on-premises to cloud. A successful Autodiscover query is important in the Free/Busy process as it provides us with the Availability Service URL of the user which is the External EWS URL of an Exchange Organization. This TechNet article gives us more information on this <domain>.mail.onmicrosoft.com secondary email address: The wizard (HCW) adds an accepted domain to the on-premises organization for hybrid mail flow and Autodiscover requests for the cloud organization. This domain, referred to as the coexistence domain, is added as a secondary proxy domain (contoso.mail.onmicrosoft.com) to any email address policies which have PrimarySmtpAddress templates for domains selected in the Hybrid Configuration wizard(contoso.com). By default, this domain is <domain>.mail.onmicrosoft.com. Table below illustrates the hybrid user objects discussed above as well as how to look them up. On-premises commands = Exchange Management Shell Cloud commands = Exchange Online PowerShell Typical Hybrid user objects configuration On-premises commands On-premises objects Corresponding cloud objects Cloud commands ON-PREM MAILBOX USER MAIL ENABLED USER IN CLOUD Get-mailbox Joe@contoso.com | FT PrimarySMTPaddress On-premises mailbox user with SMTP: Joe@contoso.com Cloud mail enabled user with SMTP: Joe@contoso.com Get-MailUser Joe@contoso.com | FT PrimarySMTPAddress (Get-mailbox Joe@contoso.com). EmailAddresses On-premises mailbox user has a secondary smtp address of @contoso.mail. onmicrosoft.com configured by HCW (Email Address Policies) Cloud mail enabled user has this secondary smtp Joe@contoso.mail. onmicrosoft.com (Get-mailuser Joe@contoso.com). EmailAddresses (Get-mailbox Joe@contoso.com). EmailAddresses On-premises mailbox user has a secondary smtp Joe@contoso.mail. onmicrosoft.com Cloud mail enabled user has an ExternalEmailAddress Joe@contoso.com Get-MailUser Joe@contoso.com |FT ExternalEmailAddress REMOTE MAILBOX ON-PREM MAILBOX USER IN CLOUD Get-RemoteMailbox Jane@contoso.com |FT primarySMTPaddress Remote mailbox SMTP: Jane@contoso.com Mailbox User SMTP: Jane@contoso.com Get-Mailbox Jane@contoso.com |FT PrimarySMTPAddress Get-RemoteMailbox Jane@contoso.com | FT RemoteRoutingAddress Remote mailbox TargetAddress: Jane@contoso.mail. onmicrosoft.com Mailbox User smtp: Jane@contoso.mail. onmicrosoft.com (Get-Mailbox Jane@contoso.com). EmailAddresses Now that we understand user objects and their relevant properties, we should come back to Free/Busy directions. Between the on-premises organization and cloud organization there are bidirectional Organization Relationships and/or bidirectional Intra Organization Connectors (for Exchange 2013 or later) that are created during Hybrid Configuration. The source of these Relationships / Connectors plays an important role in the F/B directionality. The Free/Busy directions are: Direction On-premises to Cloud You are logged in to Outlook on the Web or Outlook on Windows as an on-premises user (joe@contoso.com), you’re your mailbox hosted on your on-premises Exchange server. As an on-premises user you wish to have a meeting with the cloud user (jane@contoso.com) but will first have to check their availability for the meeting. Let’s walk through the process: 1. Joe creates a meeting request and adds Jane as an attendee. 2. The on-premises Exchange server in Contoso determines (usually based on Target Address of the mail-enabled user) that Jane is not a local mailbox and has a different domain name of contoso.mail.onmicrosoft.com set as the Target Address. 3. The Availability Service on the on-premises Exchange server (Client Access Server if Ex2010 or Mailbox Server if 2013/2016) in Contoso then checks to see if there is a path to query Jane’s Free/Busy information for Contoso’s cloud side. First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.mail.onmicrosoft.com (assuming the Exchange server is version 2013 or later). If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.mail.onmicrosoft.com in the list of any existing Organization Relationships. If neither an IOC nor an Organization Relationship for the domain contoso.mail.onmicrosoft.com exists, then we look for the domain name contoso.mail.onmicrosoft.com as an Availability Address Space (3). 4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso on-premises Organization Relationship is set to outlook.com, which is an identifier for the Contoso Cloud organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token that will be accepted by Contoso Cloud Organization. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange server in Contoso on-premises sends an Autodiscover request to Exchange Online, and upon a successful Autodiscover response will send an EWS request to Exchange Online for Jane’s availability information. 6. The Exchange Online server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Jane’s mailbox. Here is a flowchart which illustrates the Free/Busy lookup process: Direction Cloud to on-premises You are logged in to Outlook on the Web or Outlook on Windows as a cloud user (jane@contoso.com), whose mailbox is in Exchange Online. Jane wants to have a meeting with an on-premises user (joe@contoso.com), but must first check their availability for the meeting. 1. Jane creates a meeting request and adds Joe as an attendee 2. The Exchange Online servers in Contoso-cloud side organization determine (usually based on target address of a mail-enabled user) that Joe is not a local mailbox and has a domain name of contoso.com set as the target address. 3. The Availability Service on Exchange Online servers checks to see if there is a path for it to find the Free/Busy information for Contoso on-premises side organization. First, we check if we have an Intra-Organization Connector (1) with the domain name of contoso.com (assuming the Exchange server is 2013 or later on-premises). If an IOC does not exist, then we look to see if an Organization Relationship (2) is configured by looking for the domain name of contoso.com in the list of any existing Organization Relationships. If neither an IOC nor an Organization Relationship for the domain contoso.com exists, then we then look for the domain name contoso.com as an Availability Address Space (3). 4. Assuming we would have an Exchange 2010-only environment in the on-premises and we’ve ran HCW successfully, we should expect to see both an Organization Relationship as well as a Federation Trust which combined is the second option from step #3. The Target ApplicationURI in the Contoso Cloud Organization Relationship is set to FYDIBOHF25SPDLT.contoso.com, which is an identifier for the Contoso on-premises organization trust in the Azure Authentication System. A request is then made to the Azure Authentication System for a delegation token which will be accepted by Contoso on-premises organization. 5. Once the delegation token is received back from the Azure Authentication System, the Exchange Online server in Contoso cloud sends an Autodiscover request to the on-premises Exchange Servers and upon receipt of a successful Autodiscover response it will then send an EWS request for Joe’s availability. 6. The Contoso on-premises Exchange server validates the token provided by the Azure Authentication System and once confirmed, returns the requested Free/Busy data for Joe’s mailbox. Hybrid Free/Busy lookup order To summarize, the following order would be used when processing for Free/Busy lookups from cloud to on-premises: Look for IntraOrganizationConnector (OAUTH) If there is no IntraOrganizationConnector or if it is disabled, then look for Organization Relationship (DAUTH) If neither of these are found or they’re disabled, then look for Availability Address Space. Availability Address Space is normally only used for Lotus Notes organizations. If Free/Busy lookup is getting all the way down to using the final Availability Address Space option for cloud to on-premises lookups in a hybrid deployment, then this would suggest there are configuration issues which must be repaired. The order for Free/Busy lookups from on-premises to cloud is almost the same with some exceptions: If we have Exchange 2007 servers in coexistence with Exchange 2010/2013, we use Availability Address Space from Exchange 2007 to Exchange 2010/2013 and then Exchange 2010/2013 will use Org Relationship (Ex2010) or IntraOrganization Connector (Ex2013) to Cloud. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is enabled, Exchange 2010 will use Availability Address Space to Exchange 2013/2016 and then 2013/2016 will use the IntraOrganization Connector to Cloud. If we have Exchange 2010 with Exchange 2013/2016 and OAuth is not enabled, Exchange 2010 will not send the request to the Exchange 2013/2016. Instead Exchange 2010 will use Organization Relationship to Cloud for Free/Busy. Exchange 2013 Cu5+ and Exchange 2016 organizations without coexisting with legacy Exchange servers will use by default IntraOrganization Connectors from On-Premises to Cloud (normal process) This table summarizes which components (Get-IntraorganizationConnector / Get-OrganizationRelationship / Get-AvailabilityAddressSpace) are present (YES) or not (NO) in the Exchange Organization depending on the Exchange Server versions on-premises in a Hybrid deployment. Free/Busy component matrix Exchange Hybrid Environment Intra Organization Connector (IOC) Organization Relationship Availability Address Space Pure Exchange 2016 Hybrid YES (created automatically by HCW) YES YES Pure Exchange 2013 (CU5+) Hybrid YES (created automatically by HCW) YES YES Pure Exchange 2010 Hybrid NO YES YES Mixed Exchange 2007 + Exchange 2010 Hybrid NO - Ex2010 NO - Ex2007 YES - Ex2010 NO - Ex2007 YES - Ex2010 YES - Ex2007 Mixed Exchange 2007 + Exchange 2013 Hybrid YES - Ex2013 (if created manually) NO - Ex2007 YES - Ex2013 NO - Ex2007 YES - Ex2013 YES - Ex2007 Mixed Exchange 2010 + Exchange 2013 Hybrid YES - Ex2013 (if created manually) NO - Ex2010 YES - Ex2013 YES - Ex2010 YES - Ex2013 YES - Ex2010 Mixed Exchange 2010 + Exchange 2016 Hybrid YES - Ex2016 (if created manually) NO - Ex2010 YES - Ex2016 YES - Ex2010 YES - Ex2016 YES - Ex2010 Mixed Exchange 2013 + Exchange 2016 Hybrid YES - Ex2016 (created automatically by HCW) YES - Ex2013 YES - Ex2016 YES - Ex2013 YES - Ex2016 YES - Ex2013 Note: OAuth is by default configured by HCW in Exchange 2013 CU5 and above (including Exchange 2016) organizations. If Exchange 2013 / Exchange 2016 servers coexist with Exchange 2010 or older then OAUTH is not configured by default by the HCW but can be manually configured. Note: Exchange 2013 CU5 is considered old and unlike wine, the finest CU is always the most recent one. You probably have heard about our n and n-1 supported version statement in Hybrid Deployments and can read more about it here and here. Which Free/Busy lookup method are you using? I won't go into all the details about the two types of authentication (OAUTH vs DAUTH) in this post, but I recommend reading this blog post at bedtime: Deep Dive: How Hybrid Authentication Really Works. As explained there, OAuth is an open-standards based model which is more preferred to a customized model. You can quickly determine if you are using OAuth or not by running: Get-IntraOrganizationConnector cmdlet in Exchange Management Shell (for F/B direction On-Premises to Cloud) and in Exchange Online PowerShell (for F/B direction Cloud to On-Premises). If you see Enabled = True, then you are using OAuth or the system should at least be trying to. Note: We also need to make sure that the Target Domain is present on the Intra Organization Connector or Organization Relationship when deciding if using OAUTH or DAUTH. I have created two flowcharts to show you the logic of using OAUTH vs DAUTH in a F/B lookup process for each F/B direction. The user’s setup remains still the same as shown in previous examples and I am reposting the diagram here so that you don’t need to scroll up. 1. Joe’s Exchange server deciding whether to use Oauth or Dauth : 2. Jane’s Exchange Online server deciding whether to use Oauth or Dauth Now that you know which method is being used (or at least which should be attempted) and we know the direction Free/Busy is failing, we can see if you have everything configured correctly. In most cases these configurations are handled by the HCW and should be accurate and you can re-run the HCW to get things back to a good configuration. If Exchange On-Premises > Exchange Online Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from on-premises. If Exchange Online > Exchange On-Premises Free/Busy is failing for all users, you would first check Intra Organization Connector or the Organization Relationship from Exchange Online. Below, you will see a sample of the expected configuration for Intra Organization Connectors and Org Relationships from both sides (on-premises and cloud). This Baseline configuration was documented by my co-worker Ray Fong (Support Escalation Engineer) and I am very happy to have it when I troubleshoot Free/Busy issues. Exchange Online side Use this article to connect to Exchange Online PowerShell. INTRA ORGANIZATION CONNECTOR IN CLOUD Get-IntraOrganizationConnector | fl TargetAddressDomains,DiscoveryEndpoint,Enabled TargetAddressDomains : {contoso.com} DiscoveryEndpoint : https://autodiscover.contoso.com/autodiscover/autodiscover.svc * Enabled : True Note: In practice, the On-Premises Discovery Endpoint (Autodiscover) is more likely to be found in the format https://mail.contoso.com/autodiscover/autodiscover.svc because of the EWS External URL, so pay attention to this Autodiscover URL and replace it if needed with the autodiscover.yourdomain.tld on the IOC present in the Cloud Side (Reference Set-IntraOrganizationConnector) Get-IntraOrganizationConfiguration | fl OnPremiseTargetAddresses OnPremiseTargetAddresses : {contoso.com} TargetAddressDomains - This should be your federated domains. Example: contoso.com You can find the domains name by cross-checking Exchange Online's (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses TargetDiscoveryEndpoint - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/.If you paste the URL in IE, you should receive a regular windows authentication security prompt Enabled - This must be True. Exchange On-Premises side (use Exchange Management Shell) INTRA ORGANIZATION CONNECTOR IN ON-PREM Get-IntraOrganizationConnector | fl Name,TargetAddressDomains,DiscoveryEndpoint,Enabled Name : ExchangeHybridOnPremisesToOnline TargetAddressDomains : {contoso.mail.onmicrosoft.com} DiscoveryEndpoint : https://outlook.office365.com/autodiscover/autodiscover.svc Enabled : True TargetAddressDomains - This should be your tenant.mail.onmicroosft.com name. Example: 'contoso.mail.onmicrosoft.com' TargetDiscoveryEndpoint - This should be the address of EXO Autodiscover endpoint. Example: https://outlook.office365.com/autodiscover/autodiscover.svc Enabled - This must be True. Exchange Online side Use this article to connect to Exchange Online PowerShell. ORGANIZATION RELATIONSHIP IN CLOUD Get-OrganizationRelationship "Exchange Online to on premises Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled DomainNames : {contoso.com} FreeBusyAccessEnabled : True FreeBusyAccessLevel : LimitedDetails FreeBusyAccessScope : TargetApplicationUri : FYDIBOHF25SPDLT.contoso.com TargetSharingEpr : TargetOwaURL : TargetAutodiscoverEpr : https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity Enabled : True DomainNames - This should be your federated domains. Example: contoso.com You can find the domains name by cross-checking On-Premises' (Get-FederatedOrganizationIdentifier).Domains TargetAutodiscoverEPR - This should be the address of the On-Premises Autodiscover Endpoint. Example: https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity. If you paste the URL in IE, you should receive a regular windows authentication security prompt TargetSharingEPR - Ideally this is blank. If it is set, it should be the On-Premises Exchange servers EWS ExternalUrl endpoint. Example: https://server.contoso.com/EWS/Exchange.asmx You can find the URL by cross-checking On-Prem's Get-WebServicesVirtualDirectory ExternaUrl. If you paste the URL in IE with /WSSecurity at the end (https://server.contoso.com/EWS/Exchange.asmx/WSSecurity), you should receive a regular windows authentication security prompt TargetApplicationURI - This must match the ApplicationUrI from On-Prem. Example: FYDIBOHF25SPDLT.contoso.com You can find the value by cross-checking On-Prem's (Get-FederationTrust).ApplicationUri FreeBusyAccessEnabled - This must be True. FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails. AvailabilityOnly: Free/Busy access with time only LimitedDetails: Free/Busy access with time, subject, and location FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization. Enabled - This must be True. Exchange On-Premises side (use Exchange Management Shell) ORGANIZATION RELATIONSHIP IN ON-PREM Get-OrganizationRelationship "On Premises to Exchange Online Organization Relationship" | fl DomainNames,FreeBusy*,Target*,Enabled DomainNames : {contoso.mail.onmicrosoft.com} FreeBusyAccessEnabled : True FreeBusyAccessLevel : LimitedDetails FreeBusyAccessScope : TargetApplicationUri : Outlook.com TargetSharingEpr : TargetOwaURL : https://outlook.com/owa/contoso.onmicrosoft.com TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity Enabled : True DomainNames - This should be your tenant.mail.onmicrosoft.com name. Example: contoso.mail.onmicrosoft.com TargetAutodiscoverEpr - This should be a valid Exchange Online Autodiscover endpoint. Example: https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity or https://pod51038.outlook.com/autodiscover/autodiscover.svc/WSSecurity [<-- A pod address] You can find the value from TargetAutodiscoverEpr of Get-FederationInformaiton -DomainName tenantname.mail.onmicrosoft.com -BypassAdditionalDomainValidation | fl TargetSharingEPR - Ideally this is blank. If it is set, it should be Office 365 EWS endpoint. Example: https://outlook.office365.com/EWS/Exchange.asmx TargetApplicationURI - This must be outlook.com if this is for organization relationship of the cloud tenant. For non-cloud organization relationship, this must match (Get-FederationTrust).ApplicationUri of the On-Prem trust of the other organization. FreeBusyAccessEnabled - This must be True. FreeBusyAccessLevel - This should be either AvailabilityOnly or LimitedDetails. AvailabilityOnly: Free/Busy access with time only LimitedDetails: Free/Busy access with time, subject, and location FreeBusyAccessScope - This is typically blank. The FreeBusyAccessScope parameter specifies a security distribution group in the internal organization that contains users that can have their Free/Busy information accessed by an external organization. Enabled - This must be True. Both Autodiscover and EWS virtual directories must be enabled for WSSecurity authentication and/or OAuth. For example, if using OAuth, you should have OAuth listed as Authentication Methods, whereas if using only DAuth (Exchange 2010 for example), you would see only WSSecurity. Example of virtual directories authentication methods for an Exchange 2013 Hybrid Organization: Get-AutodiscoverVirtualDirectory -Server SERVER01 | fl Name,AdminDisplayVersion,*authentication* Name : Autodiscover (Default Web Site) AdminDisplayVersion : Version 15.0 (Build 1044.25) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} Get-WebServicesVirtualDirectory -Server server01| fl Name,AdminDisplayVersion,*Authentication* Name : EWS (Default Web Site) AdminDisplayVersion : Version 15.0 (Build 1044.25) InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth} As explained earlier, there are some situations where Free/Busy from on-premises to cloud is going via Availability Address Space. This would be the expected configuration for Availability Address Space in Exchange on-premises (Exchange Management Shell): Get-AvailabilityAddressSpace contoso.mail.onmicrosoft.com | fl ForestName, UserName, UseServiceAccount, AccessMethod, ProxyUrl, Name ForestName : contoso.mail.onmicrosoft.com UserName : UseServiceAccount : True AccessMethod : InternalProxy ProxyUrl : https://server01.contoso.com/EWS/Exchange.asmx Name : contoso.mail.onmicrosoft.com ForestName - The should be the tenant.mail.onmicrosoft.com domain name. This should also match the domain name of RemoteRoutingAddress of remote mailboxes. Example: contoso.mail.onmicrosoft.com UserName - This should be blank. UserServiceAccount - This must be True. AccessMethod - This should be InternalProxy. ProxyUrl - This should be the Exchange 2013/2016 Exchange Web Services Virtual Directory URL. The address could be the internal FQDN or load balancing EWS URL. Example: https://server01.contoso.com/EWS/Exchange.asmx We recommend you check the following requirements for inbound/outbound connectivity to and from Exchange servers in a Hybrid Deployment: Understanding Federated Delegation Office 365 URLs and IP address ranges If you have read this far – thank you! This concludes the Part 1 of this blog series. Onto troubleshooting next! Huge thanks to all that contributed to this blog post: Ray Fong, Nino Bilic, Tim Heeney, Greg Taylor and Brian Day. Mirela Buruiana
