OWA
75 TopicsClient Connectivity in an Exchange 2013 Coexistence Environment
This article is part 3 in a series that discusses namespace planning, load balancing principles, client connectivity, and certificate planning. Over the last several months, we have routinely fielded questions on how various clients connect to the infrastructure once Exchange 2013 is deployed. Our goal with this article is to articulate the various connectivity scenarios you may encounter in your designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2007 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2013. Existing Environment Figure 1: Exchange 2007 & Exchange 2010 Multi-Site Architecture As you can see from the above diagram, this environment contains three Active Directory sites: Internet Facing AD Site (Site1) - This is the main AD site in the environment and has exposure to the Internet. This site also has a mix of Exchange 2007 and Exchange 2010 servers. There are three namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2010 infrastructure and legacy.contoso.com resolves to the CAS2007 infrastructure. Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2010 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2010 infrastructure located within this AD site. Non-Internet Facing AD Site (Site3) - This is an AD site that does not have exposure to the Internet. This site contains Exchange 2010 infrastructure. Note: The term, Internet Facing AD Site, simply means any Active Directory site containing Client Access servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Client Access servers whose virtual directories do not have ExternalURL property populated. To understand the client connectivity before we instantiate Exchange 2013 into the environment, let’s look at the four users. Autodiscover The Autodiscover namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2010 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2010 infrastructure and retrieve configuration settings based on their mailbox’s location. The Autodiscover service on Exchange 2010 can process Autodiscover requests for both Exchange 2007 and Exchange 2010 mailboxes. Note: The recommended practice is to configure the 2007 and 2010 Client Access server’s AutoDiscoverServiceInternalUri value (which is the property value you use to set the SCP record) to point to autodiscover.contoso.com, assuming split-brain DNS is in place. If split-brain DNS is not configured, then set AutoDiscoverServiceInternalUri to a value that resolves to the load balanced VIP for the 2010 Client Access servers in your environment. For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service. Internal Outlook Connectivity For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will connect to the Exchange 2010 RPC Client Access array endpoint (assuming one exists). Keep in mind the importance of configuring the RPC Client Access array endpoint correctly, as documented in Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations. For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox. Outlook Anywhere Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server. Purple User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server is located on an Exchange 2007 server, and proxy the Outlook RPC data to the target Exchange 2007 Mailbox server. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server hosting the mailbox is located in another AD site (in this case Site3) and proxy the Outlook RPC data to the target Exchange 2010 Client Access server. Orange User will connect to mail-region.contoso.com as his RPC proxy endpoint. CAS2010 in Site2 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server. Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, which are provided via the Autodiscover response. Outlook Web App For more information, see the article Upgrading Outlook Web App to Exchange 2010. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server. Purple User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to legacy.contoso.com. CAS2007 will then process the request and retrieve the necessary data from the Exchange 2007 Mailbox server. Blue User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2010 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured: Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is configured to do a cross-site silent redirection, therefore, CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server. Exchange ActiveSync For more information, see the article Upgrading Exchange ActiveSync to Exchange 2010. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server. Purple User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2010 proxies the request to CAS2007. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any EAS ExternalURLs. CAS2010 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server. For the Orange User, there are two possible scenarios: Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an EAS ExternalURL. Assuming the device supports Autodiscover and is on a defined list of devices that supports the 451 redirect response, CAS2010 will issue a 451 response to the device, notifying the device it needs to use a new namespace, mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server. If the device is not on the supported list, then CAS2010 in Site1 will proxy the request to CAS2010 in Site2 Exchange Web Services For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site1 will service the request. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 will then proxy the request to an Exchange 2010 Client Access server located in Site3. For the Purple User, Autodiscover will provide back the legacy.contoso.com namespace for the Exchange Web Service URL. CAS2007 in Site1 will service the request. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site2 will service the request. Client Connectivity with Exchange 2013 in Site1 Exchange 2013 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. As a result, Outlook Anywhere has been enabled on all Client Access servers within the infrastructure and the mail.contoso.com and autodiscover.contoso.com namespaces have been moved to resolve to Exchange 2013 Client Access server infrastructure. Figure 2: Exchange 2013 Coexistence with Exchange 2007 & Exchange 2010 in a Multi-Site Architecture To understand the client connectivity now that Exchange 2013 exists in the environment, let’s look at the four users. Autodiscover The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2013 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2013 infrastructure and depending on the mailbox version, different behaviors occur: For mailboxes that exist on Exchange 2010, CAS2013 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User and Orange User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response. For mailboxes that exist on Exchange 2007, CAS2013 will proxy the request to an Exchange 2013 Mailbox server in the local site, which will generate the Autodiscover response. This means for Purple User, the MBX2013 server in Site1 will generate the response. For mailboxes that exist on Exchange 2013, CAS2013 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response. Internal Outlook Connectivity For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will still connect to the Exchange 2010 RPC Client Access array endpoint. For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will still connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox. When you have an Exchange 2013 mailbox you are using Outlook Anywhere, both within the corporate network and outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 mailboxes. In Exchange 2007/2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013, you have both an internal host name and an external host name. Think of it as having two sets of Outlook Anywhere settings, one for when you are connected to the corporate domain, and another for when you are not. You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP. However, ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings. To correctly use these settings, the Outlook client must be patched to the appropriate levels (see the Exchange 2013 System Requirements for more information). Outlook will process the ExHTTP in order – internal first and external second. Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must utilize the same authentication value for both your internal and external Outlook Anywhere settings, or switch to use different names for Outlook Anywhere inside and out. Outlook gives priority to the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings. The default Exchange 2013 internal Outlook Anywhere settings don’t require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads. External Outlook Connectivity In order to support access for Outlook Anywhere clients whose mailboxes are on legacy versions of Exchange, you will need to make some changes to your environment which are documented in the steps within the Exchange Deployment Assistant. Specifically, you will need to enable Outlook Anywhere on your legacy Client Access servers and enable NTLM in addition to basic authentication for the IIS Authentication Method. The Exchange 2013 Client Access server’s RPC proxy component sees the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (legacy CAS or Exchange 2013 Mailbox server). Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server. Purple User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2007 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013 will proxy the request to CAS2007 in Site1. CAS2007 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2007 Mailbox server. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. CAS2013 will proxy the request to CAS2010 in Site3. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server. Orange User will continue to access his mailbox using the Exchange 2010 regional namespace, mail-region.contoso.com. Outlook Web App For Outlook Web App, the user experience will depend on the mailbox version and where the mailbox is located. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server. Purple User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to legacy.contoso.com. CAS2007 will then facilitate the request and retrieve the necessary data from the Exchange 2007 Mailbox server. Blue User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server. For the Orange User, there are two possible scenarios: Orange User will connect to mail-region.contoso.com as his namespace endpoint. In this case, CAS2013 is not involved in any fashion. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013 in Site1 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server. Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007 and the mailbox is located in Site3. CAS2013 will issue a single sign-on silent redirect to legacy.contoso.com. CAS2007 in Site1 will authenticate the user and proxy the request to the Exchange 2007 Client Access server infrastructure in Site3. Exchange ActiveSync For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2013 no longer supports the 451 redirect response – Exchange 2013 will always proxy ActiveSync requests. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server. Purple User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007. CAS2013 will proxy the request to a local Exchange 2013 Mailbox server. The Exchange 2013 Mailbox server will send the request to an Exchange 2007 Client Access server that exists within the mailbox’s site (specifically, the InternalURL value of the Microsoft-Server-ActiveSync virtual directory on CAS2007), which will retrieve the data from the Exchange 2007 Mailbox server. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. CAS2013 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server. For the Orange User, there are two possible scenarios depending on how the device is configured: Orange User’s ActiveSync client is configured to connect to mail-region.contoso.com as the namespace endpoint. In this case, CAS2013 is not involved in any fashion. Note that any new device that is configured will automatically be configured to use mail-region.contoso.com. Orange User’s ActiveSync client is configured to connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within another AD site. CAS2013 will issue a cross-site proxy request to an Exchange 2010 Client Access server that resides in the same site as the mailbox. Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007 and the mailbox is located in Site3. CAS2013 will proxy the request to a local Exchange 2013 Mailbox server. The Exchange 2013 Mailbox server will send the request to an Exchange 2007 Client Access server that exists within the mailbox’s site, which will retrieve the data from the Exchange 2007 Mailbox server. Exchange Web Services Coexistence with Exchange Web Services is rather simple. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 will then proxy the request to an Exchange 2010 Client Access server within the local site. For the Purple User, Autodiscover will return the legacy.contoso.com namespace for the Exchange Web Service URL. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 will then proxy the request to an Exchange 2010 Client Access server located in Site3. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, the Autodiscover response will provide back the legacy.contoso.com namespace for the Exchange Service URL. CAS2007 in Site1 will proxy the request to an Exchange 2007 Client Access server that exists within the mailbox’s site, which will retrieve the data from the Exchange 2007 Mailbox server. This is why you cannot remove Exchange 2007 from the Internet-facing Active Directory site as long as Exchange 2007 exists in non-Internet facing Active Directory sites. Offline Address Book Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question. For the Purple User, Autodiscover will return the legacy.contoso.com namespace for the Offline Address Book URL. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL. Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, the Autodiscover response will provide back the legacy.contoso.com namespace for the Offline Address Book URL. This is why you cannot remove Exchange 2007 from the Internet-facing Active Directory site as long as Exchange 2007 exists in non-Internet facing Active Directory sites. How CAS2013 Picks a Target Legacy Exchange Server It’s important to understand that when CAS2013 proxies to a legacy Exchange Client Access server, it constructs a URL based on the server FQDN, not a load balanced namespace or the InternalURL value.But how does CAS2013 choose which legacy Client Access server to proxy the connection? When a CAS2013 starts up, it connects to Active Directory and enumerates a topology map to understand all the Client Access servers that exist within the environment. Every 50 seconds, CAS2013 will send a lightweight request to each protocol end point to all the Client Access servers in the topology map; these requests have a user agent string of HttpProxy.ClientAccessServer2010Ping (yes, even Exchange 2007 servers are targeted with that user string). CAS2013 expects a response - a 200/300/400 response series indicates the target server is up for the protocol in question; a 502, 503, or 504 response indicates a failure. If a failure response occurs, CAS2013 immediately retries to determine if the error was a transient error. If this second attempt fails, CAS2013 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), CAS2013 will attempt to determine the health state of the down CAS to determine if it is available. The IIS log on a legacy Client Access server will contain the ping events. For example: 2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 302 0 0 277 170 0 2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 309 177 15 2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 245 170 0 2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 301 0 0 213 169 171 2014-03-11 14:00:01 W3SVC1 DF-C14-02 157.54.7.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 2 5 293 194 31 2014-03-11 14:00:04 W3SVC1 DF-C14-02 157.54.7.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 2 5 261 170 171 If for some reason, you would like to ensure a particular CAS2010 is never considered a proxy endpoint (or want to remove it for maintenance activities), you can do so by executing the following cmdlet on Exchange 2010 (note that this feature does not exist on Exchange 2007): Set-ClientAccessServer <server> -IsOutofService $True IMAP & POP Coexistence All this discussion about HTTP-based clients is great, but what about POP and IMAP clients? Like the HTTP-based client counterparts, IMAP and POP clients are also proxied from the Exchange 2013 Client Access server to a target server (whether that be an Exchange 2013 Mailbox server or a legacy Client Access server). However, there is one key difference, there is no health-checking on the target IMAP/POP services. When the Exchange 2013 Client Access server receives a POP or IMAP request, it will authenticate the user and perform a service discovery. If the target mailbox is E2010, CAS2013 will enumerate the POP or IMAP InternalConnectionSettings property value for each Exchange 2010 Client Access server within the mailbox’s site. Therefore, it is important to ensure that the InternalConnectionSettings maps to the server's FQDN, and not a load-balanced namespace. If the target mailbox is E2007, CAS2013 will enumerate each Exchange 2007 Client Access server’s server FQDN within the mailbox’s site. CAS2013 will choose a server to proxy the request based on the incoming connection’s configuration. If the incoming connection is over an encrypted channel, CAS2013 will try to locate an SSL proxy target first, TLS next, plaintext lastly. If the incoming connection is over a plaintext channel, CAS2013 will try to locate a plaintext proxy target first, SSL next, TLS lastly. Important: Exchange 2013 Client Access servers do not validate that the POP or IMAP services are actually running on the target Client Access servers. It's important, therefore, to ensure that the services are running on every legacy Client Access server if you have POP or IMAP clients in your environment. Conclusion Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2013 when coexisting with either Exchange 2007 or Exchange 2010. Please let us know if you have any questions. Ross Smith IV Principal Program Manager Office 365 Customer Experience Updates 3/14/2014: Added section on IMAP/POP coexistence 3/25/2014: Added detail that MBX2013 proxies to the CAS2007 MSAS InternalURL for 2007 EAS mailbox access260KViews0likes27CommentsManaging Focused Inbox in Office 365 and Outlook
Focused Inbox—focus on the emails that matter most For many, the inbox is the command center for their day. It’s the way to keep track of what is going on and what needs to get done. Outlook’s Focused Inbox makes this process easier by helping you focus on the emails that matter most to you. It separates your inbox into two tabs — Focused and Other. Emails that you need to act on right away are on the Focused tab, while the rest wait for you in Other. You’ll be informed about email flowing to “Other”, and you can switch between tabs at any time to take a quick look. For more about what makes Focused Inbox great, see Outlook helps you focus on what matters to you. Admin controls available for Focused Inbox: Ensure certain business critical mails land in the Focused tab. Tenant admins have controls to ensure certain business critical communications, like HR, Payroll, etc., always land in the user’s Focused tab of the Inbox. These whitelists can be set up using mail flow rules from the Admin center or via PowerShell cmdlets. After these are set up successfully, all future messages that satisfy these mail flow rules would be delivered in the Focused tab of the Inbox on Outlook clients that support Focused Inbox. Tenant and mailbox level control to enable/disable Focused Inbox. Tenant admins will controls to enable/disable Focused Inbox on Outlook clients (Windows, Mac, and web) for all current and future mailboxes or select mailboxes in their tenant. These controls are available via PowerShell cmdlets. If tenant admins enable/disable Focused Inbox, the Focused Inbox experience will be turned ON/OFF for these users the next time they boot the client. These controls do not block the availability of the feature for these users. If the users so desire, they can still re-enable the feature individually again on each of their clients. Transition from Clutter Focused Inbox is a refinement and improvement of a previous feature called Clutter. Clutter’s purpose was also to help you focus on the most important items in your inbox, but it did so by moving “Other” email to a separate folder. Focused Inbox makes it easier for you to stay on top of incoming email without having to visit another folder. The same machine learned algorithm that moved items to the Clutter folder now powers Focused Inbox, meaning that any emails that were set to move to Clutter will now be moved to Other. The learning and training that users invested into Clutter are transitioned to Focused Inbox without any effort on the user’s part. Users can keep using the existing Clutter experience through the transition. However, after the transition period, Clutter will be completely replaced by Focused Inbox. In the meantime, if a Clutter user chooses to opt-in to using Focused Inbox they will no longer receive less actionable email in the “Clutter” folder. Instead, email will be split between the Focused and Other tabs in their inbox. Tenant admins will be proactively notified before Clutter is fully replaced. Note: If a user activates Focused Inbox from Outlook on the web, their messages will no longer be moved to the Clutter folder in Outlook desktop. For this reason, we don’t prompt active Clutter users to try Focused Inbox in Outlook on the web. If you have previously disabled Clutter for users in your organization, we will not automatically re-enable Clutter for those users, nor will we automatically enable Focused Inbox for those users. The following table outlines how the user experience will look like as Focused Inbox rolls out: Admin Action User Experience - Today If admin does nothing during Focused Inbox rollout OFF by default for users who are actively using Clutter today OFF by default for users who have disabled Clutter themselves OFF by default for user who had Clutter disabled by an administrator ON by default for everyone else Individual user can still enable or disable the feature in supported Outlook clients If admin disables Focused Inbox organizationally OFF by default for every user Individual user can still enable or disable the feature in supported Outlook clients If admin enables Focused Inbox organizationally ON by default for every user in your organization (including those using Clutter before) Individual user can still enable or disable the feature in supported Outlook clients Roll out of Focused Inbox Focused Inbox is now available (as of December 2017) to all Office 365 customers on the Monthly Channel of Office 365 ProPlus. Customers on the Semi-Annual Channel will see it arrive in the March 2018 Semi-Annual Targeted release and the July 2018 Semi-Annual release, according to that channel’s standard scheduleFrequently asked questions: What happens to the Clutter folder after a user enables Focused Inbox? After Focused Inbox is enabled for a mailbox, Clutter folder would be demoted to a regular user folder. All regular user created folder operations would be supported, including delete. Could admins clean up the Clutter folder for their users without enabling Focused Inbox? We will enable admins to clean up the Clutter folder for their users, if they so desire. This will be supported via the current PowerShell cmdlets. Is Focused Inbox available to on-premises users? Focused Inbox only applies to Office 365 Exchange Online tenants and users. Which Outlook clients support Focused Inbox? Here is an updated list of supported Outlook clients. Platform Required build iOS Any supported build Android Any supported build Mac 1 15.26+ Web N/A. Available to all users. Windows 10 Mobile 16.0.8600+ Outlook 2016 for Windows (1), (2),(3) 16.0.7967.2xxx+ | Version 1703 of Current Channel. Expected as part of July 2018 Semi-Annual release. (1) requires the Office 365 subscription versions of the clients. Focused Inbox will not be delivered to Outlook for Mac 2011, or the perpetual versions of Outlook 2013 for Windows and Outlook 2016 for Windows. (2) Prior to build 16.0.8730 Version 1711, requires Modern Authentication to be enabled for Exchange Online. The Exchange Team Updates 6/5/2017: Updated list of supported clients. 11/8/2017: Changed "Modern Authentication to be enabled for Exchange Online" to "Prior to build 16.0.8730 Version 1711, requires Modern Authentication to be enabled for Exchange Online." Removed "(3) We are also working on an additional update, which will remove the requirement of Modern Authentication for Focused Inbox to work. That will come in a future fork." Changed "Emails that matter most to you are in the Focused tab, while the rest remain easily accessible—but out of the way in the Other tab." to "Emails that you need to act on right away are on the Focused tab, while the rest wait for you in Other." 12/12/2017: Several updates related to rollout. Details here.148KViews1like95CommentsConfiguring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role
6/17/2019 - We have some updated info relevant to this blog post - https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Monitoring-Exchange-using-Multiple-OWA-ECP-Virtual-Directories/ba-p/697122 We have previously published guidance for setting up multiple OWA and ECP virtual directories for Exchange Server 2007 and 2010, and now it is the turn of Exchange Server 2013. The eagle eyed amongst you may spot some copy and paste from previous blogs on the subject, and well frankly, you’d be correct. The reasons for doing this haven’t changed, only the method by which you do it, so I’m re-using some of the text to avoid wasting electrons. In short: Microsoft supports using multiple Outlook Web App (OWA) and Exchange Control Panel/Admin Center (ECP) front end virtual directories on a server with the Exchange 2013 Client Access Server role, when each is in its own website and is named ‘OWA’ and ‘ECP’. Each virtual directory must be listening on the standard TCP 443 port for the site. Note: You must ensure that the Default Web Site is set to All Unassigned for IP, or problems will occur with PowerShell. There are usually three reasons for choosing this type of configuration. Each of these has slightly different considerations. Here’s what we said for Exchange 2010: Scenario 1: You have one Active Directory site facing the Internet, and are using a reverse proxy (such as Microsoft Forefront Threat Management Gateway or Unified Access Gateway) in front of Exchange. You are delegating credentials from that firewall to Exchange, meaning you have to use Basic or Integrated Windows Authentication (IWA) on Client Access Server (CAS) and not Forms-based Authentication (FBA). Your requirement is to provide FBA for all users, internal and external. Scenario 2: You have a non-Internet facing Active Directory site and your requirement is to provide FBA for all users, internal and external. In this configuration, in order to provide external users access to OWA or ECP, a CAS in the Internet facing site must proxy requests to the CAS in the non-Internet facing site – this requires the CAS in the non-internet facing site have IWA enabled, thereby disabling FBA. Scenario 3: You have different users within one organization who require a different OWA experience, such as a different Public/Private File Access or other policy or segmentation features. (This might be a good place to remind you that customizing and branding OWA isn’t something we support in Exchange 2013, so this is NOT a reason you want to consider this type of configuration in case you were wondering) Now things are actually a bit different with Exchange 2013. I’m calling this out in case you didn’t actually know. You can achieve scenario’s 1 and 2 out of the box with no additional configuration, specifically, no need for an additional web site. Yes, really. Exchange 2013 ships with Integrated Windows auth enabled on the OWA and ECP virtual directories as well as Forms based auth. So, if you choose NTLM delegation, or KCD, from TMG/UAG to Exchange, it just works. And because OWA is smart enough to determine the machine connecting to it is a browser and not another Exchange Server, the second scenario just works out of the box too. Clients get FBA, but proxy still works. Genius. With Exchange 2013 there’s one new reason to add to the list, separation of the client facing ECP settings pages, and the Exchange Administration Console (EAC) settings pages. Both of these are served by the ECP virtual directory, which is somewhat confusing I’ll admit. Basically the code behind the ECP virtual directory serves up either the personal ECP pages or the administrators EAC pages based upon on the credentials of the user logging in. Of course this means if you allow access to /ECP from the Internet (which you need to for OWA or Outlook users to go to ECP) you also allow someone with administrative credentials to log into EAC. Some customers don’t like this. So to summarize, the only reasons for which you might feel the need to create multiple OWA and ECP virtual directories: Separating admin/user ECP access. Or scenario number 3 as described earlier, because you have different policies or settings, or authentication requirements. Now that’s clear, here’s some more statements, warnings and caveats. Microsoft supports creating additional OWA/ECP virtual directories in a new IIS Web Site with a new IP address, and using those only for client access purposes. By default that new virtual directories will be FBA enabled, and have no internal or external URL values. You will also need to ensure that whatever name the users will be using to connect to the new FBA enabled OWA/ECP site is present on the installed certificate and that DNS for that name resolves to the correct IP address. Additional considerations: To avoid issues with DNS registration, the following Hotfix is recommended, if Exchange is installed on Windows 2008 R2 http://support.microsoft.com/default.aspx?scid=kb;en-US;2386184 If one site uses too many resources and it is throttled, the operations in all web sites in this application pool will be throttled. If you ever decide to recycle the Application Pool, all web sites hosted in this Application Pool will cease to work temporarily. So now you understand the scenarios properly, and understand the constraints and potential issues, there’s just the actual steps you need to use to go through. Ok, just remembered, there’s one more warning. Only the following set of steps are supported. If you decide to miss a few steps out, change a few to suit yourself, or anyway otherwise generally ignore these and go your own way, you will not be supported. And, just as likely and more importantly, you will break something and your users will be angry, and so will your boss. So just follow the steps, and don’t cross the streams. Here are the steps, at last. This process assumes you are setting the default web site to use Integrated Windows auth only, and the new Virtual Directory will be configured for FBA, because that’s supported. You can leave default web site configured for FBA too, by not doing anything to it, but I’m documenting the steps for turning that off, just in case that’s your choice. Add a secondary IP address to the server– this could be with another NIC, or done just by adding an IP to an existing NIC. If you added a NIC, in the network properties, uncheck 'register this connection in DNS' in IPv4 for the NIC (this also prevents IPv6 from registering too as it happens). Create the additional website in IIS in a new root folder (C:\inetpub\OWA_SECONDARY) and bind it to the new IP. Enable for SSL, choose whatever certificate you want to use for this site. Give the local IIS_IUSRS group Read and Execute permission to the C:\inetpub\OWA_SECONDARY folder. Copy the Default Web Site root folder contents in its entirety including any subfolders to the new site root folder (i.e. copy %SystemDrive%\inetpub\wwwroot\ contents to C:\inetpub\OWA_SECONDARY). Create new OWA and ECP subfolders in your new web site’s root folder (C:\inetpub\OWA_SECONDARY\OWA, C:\inetpub\OWA_SECONDARY\ECP). Copy the entire contents of the Default Web Site OWA and ECP folders including any subfolders to the new subfolders for new web site. (Copied from /…/FrontEnd/HttpProxy). Run the following (substituting <Server> for the server hosting the CAS role); New-OwaVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\OWA" New-EcpVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\ECP" Run the following to set the default site to IWA only (this is optional, but provided in case you want to do this); Set-OwaVirtualDirectory -Identity "<server>\owa (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true Set-EcpVirtualDirectory -Identity "<server>\ecp (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true Perform an IISReset. Test! Really, make sure you do. The final thing to understand is what you need to do when you apply a Cumulative Update (CU) to any server you have made these changes to. The CU install will NOT properly update the files in the secondary OWA or ECP web site for you, nor will the secondary site work correctly. It’s not just a resource folder/file version issue and just updating the files in directory is not going to do it, there’s more to it. The only supported solution here is to delete the secondary Vdirs and Web Site and re-do all the steps. So, make sure you have noted any non-default settings you had on the site, then delete the Vdirs, delete the web site (don’t forget to do this), delete any content in the folders, and start again at step 3 in the list above. Re-create the web site, re-create the Vdirs, copy the latest files and re-apply any custom configuration or settings you previously applied. Don’t skip any steps or take any shortcuts. Script it (you can even script the deletion/creation of a web site), run that script after you install the CU, and ensure you do this after each and every CU. Once you have done that you should be good to go. We hope this helps you understand the configuration a bit better now should you choose to go down this route and please post back if you have any questions or comments. Greg Taylor Principal PM Manager Office 365 Customer Experience113KViews0likes14CommentsOWA Cross-Site Silent Redirection in Exchange 2010 SP2
By now, many of you have seen the articles that discussed Address Book Policies, hosting changes, and the Hybrid Configuration Wizard, but deep down I know you all have been hoping that we would discuss the most sought after feature that we decided to include in Exchange 2010 SP2. What’s that you say? Yes, I know, Tony said that the “new features in SP2 are unlikely to cause much of a fuss” and that there are not that many new features in SP2 (I believe his exact words were “relative paucity”) in his SP2 announcement article over at Windows IT Pro. Well, I'm here to set the record straight. There's one killer feature in Exchange 2010 SP2, that's often not mentioned. That's right – it's time to discuss Cross-Site Silent Redirection for Outlook Web App! Definitions First, let’s go over some definitions to make sure we are all on the same page. Internet-facing Active Directory Site An Active Directory site that contains CAS that have an ExternalURL populated for the associated service (like OWA ). Typically this is the primary datacenter/site where Exchange 2010 is deployed. Regional Internet-facing Active Directory Site An Active Directory site that contains CAS that have an ExternalURL populated for the associated service (like OWA). Non-Internet-facing Active Directory Site An Active Directory site that contains CAS that do not have an ExternalURL populated for the associated service. Direct Connect The process where CAS establishes an RPC session with the Mailbox server hosting the mailbox data. Proxy The process where a CAS in an Internet-facing Active Directory site proxies incoming requests to a CAS in a Non-Internet-facing Active Directory site (that's located in the same site as the Mailbox server being accessed). Redirection The process where an Internet-facing CAS in one Active Directory site redirects the end user to another Internet-facing CAS that resides in the same site as the Mailbox server being accessed. Silent Redirection The process by which CAS issues a silent redirect back to the user’s browser, telling the browser to establish a connection to a specified URL. Single Sign-On (SSO) Redirection The process by which CAS issues a silent redirect back to the user's browser, telling the browser to submit the request and authentication credentials to a target CAS so that the login experience is seamless. OWA Connection Process In order to understand the various proxy and redirection scenarios, it's important to understand the mechanics behind what happens when a user authenticates against a CAS to access OWA as it happens today with Exchange 2010 pre-SP2: User accesses OWA URL using web browser. User enters credentials. CAS authenticates user and retrieves the following information via service discovery request: User's mailbox version User's mailbox location (Active Directory site), if known CAS gathers additional information based on mailbox information so that it can perform the correct operation: If mailbox is Exchange 2010 and local, CAS performs direct connect. If mailbox is Exchange 2007 and local, CAS retrieves the ExternalURL of an Exchange 2007 CAS (if one isn't defined it'll use the InternalURL) and silently redirects. If mailbox is Exchange 2003, CAS retrieves Exchange2003URL and silently redirects. If mailbox is not local, CAS retrieves target ExternalURL (if defined) and redirects or proxies if no OWA ExternalURLs are defined in the target Active Directory site. SP1 OWA Redirection Types In Exchange 2010 SP1, we changed things slightly which resulted in three types of redirection experience for OWA in the on-premises product: Manual Redirection Temporary Manual Redirection Legacy Silent Redirection Manual Redirection Manual redirection enables customers to not have to funnel and proxy all traffic from a central location when there are CAS closer to the user’s mailbox. Manual redirections are performed when CAS must redirect an OWA request to Exchange 2007 or Exchange 2010 CAS infrastructure that's located in a different Active Directory site. As mentioned previously, in order for a manual redirection to be performed, the target OWA virtual directory must have an ExternalURL. Your users see the following manual redirection message and the ExternalURL of the CAS in the other Active Directory site: Figure1: Manual redirection when mailbox is located in another Active Directory site Temporary Manual Redirection In SP1, we added another redirection type for OWA, known as Temporary Manual Redirection. There are two scenarios where Temporary Manual Redirection comes into play: During a datacenter activation switchback event, there exists the possibility that the user’s web browser still has the incorrect DNS entry cached and thus is pointing to the CAS infrastructure in the Ative Directory site that no longer hosts the mailbox. As a result, the CAS will issue a manual redirect to the correct Active Directory site, but the redirection is to the same URL that the user is currently using. To prevent a ping-pong effect where the user cannot access his mail, CAS will detect if the same session cookie is being returned and if so, will check to see if the target CAS has a FailbackURL value for the OWA virtual directory. If a FailbackURLis specified, then CAS issues a temporary manual redirection page providing the FailbackURL link. If a FailbackURL is not specified, CAS issues an error page asking the user to close all browser sessions and to try again. Figure 2: Temporary manual redirection upon datacenter activation switchback The second scenario is where CAS will issue the temporary manual redirection page when it detects that the local CAS's site matches that of the Mailbox databases's RpcClientAccessServer value, but the database is actually mounted in a different Active Directory site, so CAS issues a temporary redirect with the ExternalURLof the CAS in the site hosting the mounted database. Figure 3: Temporary manual redirection when mailbox is mounted in another Active Directory site Legacy Silent Redirection For Outlook Web Access, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange. Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location: If the Exchange 2007 mailbox is in the same Active Directory Site as CAS2010, CAS2010 will silently redirect the session to the Exchange 2007 CAS. If the Exchange 2007 mailbox is in another Internet-facing Active Directory Site, CAS2010 will manually redirect the user to the Exchange 2007 CAS. If the Exchange 2007 mailbox is in a non-Internet-facing Active Directory site, CAS2010 will proxy the connection to the Exchange 2007 CAS. If the mailbox is on an Exchange 2003 server, CAS2010 will silently redirect the session to a pre-defined URL. As indicated above, legacy silent redirection is only used for same-site redirection events between an Exchange 2010 CAS and the legacy infrastructure. When performing the legacy silent redirection, CAS2010 issues a silent redirect back to the user’s browser, telling the browser to establish a connection to legacy CAS2007/FE2003 infrastructure. In order to successfully redirect to the legacy infrastructure, the following must be configured: To redirect Exchange 2003 mailboxes, the Exchange 2010 OWA virtual directory must have the Exchange2003URL populated. To redirect to an Exchange 2007 CAS, the target Exchange 2007 OWA virtual directory must have the ExternalURL. Legacy Silent Redirection can also provide a single sign-on experience when Forms-Based Authentication (FBA) is used on the source and destination OWA virtual directories by issuing back to the web browser a hidden FBA form with the fields populated. This hidden form contains the same information as what the user had originally submitted to CAS2010 FBA page (username, password, public/private selector) as well as, a redirect to the target Exchange specific path and query string. As soon as this form is loaded it is immediately submitted to the target URL. The result is the user is automatically authenticated and can access the mailbox data. What’s wrong with Manual Redirection? At first glance, you might think, “hey, manual redirection is great, Microsoft” and to some extent you are correct. It is a great feature for the IT organization to control where users access their data (and thus forcing users to utilize the correct network links). But in reality, the experience is not optimal for the end user. In the scenario where the user uses the wrong OWA URL, the user performs the following actions: User enters into the web browser the wrong URL. User enters credentials and authenticates against CAS (wrong site). CAS (wrong site) performs service discovery and determines that it can redirect user to the correct CAS. CAS (wrong site) provides the user with a page that contains a link to CAS (correct site). User clicks link to access OWA from the correct site. User enters credentials and authenticates against CAS (correct site). It’s this experience where the user is told they used the wrong URL and that he has to enter his credentials twice that are the sub-optimal experiences with manual redirection. Cross-Site Silent Redirection in Exchange 2010 SP2 To remove this sub-optimal experience (Greg refers to this as a crappy experience, by the way), we've provided a fourth redirection experience for OWA in Exchange 2010 SP2, known as Cross-Site Silent Redirection. As its name implies, Cross-Site Silent Redirection only performs silent redirection for requests that are destined to CAS located in another Active Directory site (within the same Exchange organization) that have an OWA ExternalURL. A new parameter has been created to support Cross-Site Silent Redirection, CrossSiteRedirectType. This parameter is available on the Set-OWAVirtualDirectory cmdlet and supports two values, Manual and Silent. Cross-Site Silent Redirection is disabled by default (the default value is Manual), meaning that if you currently perform manual redirection between CAS in different Active Directory sites, it will continue after you deploy SP2. If you want to enable Cross-Site Silent Redirection, set the CrossSiteRedirectType to Silent on the Internet-facing CAS OWA virtual directories: Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent We've updated the OWA connection process to support Cross-Site Silent Redirection. The CAS performs the following steps during service discovery: Evaluate the mailbox version (either Exchange 2007 or Exchange 2010). Check the mailbox's location. Obtain the ExternalURL of target CAS . Obtain the redirection type on the source CAS. If CrossSiteRedirectType=Manual, we issue a manual redirect. If CrossSiteRedirectType=Silent, we issue a silent redirect. If source and target CAS have FBA enabled, then the source CAS issues a hidden form back to the browser that contains the user’s credentials and FBA settings, along with the redirect URL. If FBA is not enabled on source and target, source CAS simply issues a 302 redirect. That’s right; Cross-Site Silent Redirection can be a SSO experience when the source and target OWA virtual directories leverage Forms-Based Authentication. Customers that only deploy OWA internally can also achieve a SSO experience when the OWA virtual directory authentication mechanism is Windows Integrated Authentication and the OWA namespaces are added to the “Local Intranet” security zone. Msn.Video.createWidget('PlayerAd1Container', 'Player', 605, 340, {"configcsid": "MS_Office", "configname": "EHLO%20Player", "v": "71697ac7-6995-4fbd-802f-d599384ccfb2"}, 'PlayerAd1'); When can I not obtain a SSO Experience? These are the few scenarios where you can't obtain a SSO experience when redirecting between Active Directory sites: You use Basic Authentication on the source and target OWA virtual directories. You leverage different authentication settings on the source and target OWA virtual directories. You leverage a two-factor authentication solution on the source and target OWA virtual directories. You leverage a pre-authentication solution (like Microsoft Threat Management Gateway 2010) that uses different web listeners for the source and target OWA namespaces. When the local CAS issues a temporary redirection to another CAS in another Active Directory site. Keep in mind, that while the SSO experience will be unavailable for these scenarios, a 302 redirection (what we refer to as a silent redirection) will still occur. Cross-Site Silent Redirection reduces the end user dissatisfaction around having to click a link to get to the correct OWA infrastructure, and may in fact remove the need to enter credentials a second time. For those of you that have been using OWA Manual Redirection up to now, I hope you will enable Cross-Site Silent Redirection when you deploy Exchange 2010 SP2! Ross Smith IV Principal Program Manager Exchange Customer Experience111KViews0likes17CommentsLife in a Post TMG World – Is It As Scary As You Think?
Let’s start this post about Exchange with a common question: Now that Microsoft has stopped selling TMG, should I rip it out and find something else to publish Exchange with? I have occasionally tried to answer this question with an analogy. Let’s try it. My car (let’s call it Threat Management Gateway, or TMG for short), isn’t actively developed or sold any more (like TMG). However, it (TMG) works fine right now, it does what I need (publishes Exchange securely) and I can get parts for it and have it serviced as needed (extended support for TMG ends 2020) and so I ‘m keeping it. When it eventually either doesn’t meet my requirements (I want to publish something it can’t do) or runs out of life (2020, but it could be later if I am ok to accept the risk of no support) then I’ll replace it. Now, it might seem odd to offer up a car analogy to explain why Microsoft no longer selling TMG is not a reason for Exchange customers to panic, but I hope you’ll agree, it works, and leads you to conclude that when something stops being sold, like your car, it doesn’t immediately mean you replace it, but instead think about the situation and decide what to do next. You might well decide to go ahead and replace TMG simply based on our decision to stop selling or updating it, that’s fine, but just make sure you are thinking the decision through. Of course, you might also decide not to buy another car. Your needs have changed. Think about that. Here are some interesting Exchange-related facts to help further cement the idea I’m eventually going to get to. We do not require traffic to be authenticated prior to hitting services in front of Exchange Online. We do not do any form of pre-authentication of services in front of our corporate, on-premises messaging deployments either. We have spent an awfully large amount of time as a company working on securing our code, writing secure code, testing our code for security, and understanding the threats that exist to our code. This is why we feel confident enough to do #1 and #2. We have come to learn that adding layers of security often adds little additional security, but certainly lots of complexity. We have invested in getting our policies right and monitoring our systems. This basically says we didn’t buy another car when ours didn’t meet our needs any more. We don’t use TMG to protect ourselves any more. Why did we decide that? To explain that, you have to cast your mind back to the days of Exchange and Windows 2000. The first thing to admit is that our code was less ‘optimal’ (that’s a polite way of putting it), and there were security issues caused by anonymous access. So, how did we (Exchange) tell you to guard against them? By using something called ISA (Internet Security and Acceleration – which is an odd name for what it was, a firewall). ISA, amongst other things, did pre-authentication of connections. It forced users to authenticate to it, so it could then allow only authenticated users access to Exchange. It essentially stopped anonymous users getting to Windows and Exchange. Which was good for Windows and Exchange, because there were all kinds of things that they could do if they got there anonymously. However once authenticated users got access, they too could still do those bad things if they chose to. And so of course could anyone not coming through ISA, such as internal users. So why would you use ISA? It was so that you would know who these external users were wouldn’t you? But do you really think that’s true? Do you think most customers a) noticed something bad was going on and b) trawled logs to find out who it was who did it? No, they didn’t. So it was a bit like an insurance policy. You bought it, you knew you had it, you didn’t really check to see if it covers what you were doing until you needed it, and by then, it was too late, you found out your policy didn’t cover that scenario and you were in the deep doo doo. Insurance alone is not enough. If you put any security device in front of anything, it doesn’t mean you can or should just walk away and call it secure. So at around the same time as we were telling customers to use ISA, back in the 2000 days, the whole millennium bug thing was over, and the proliferation of the PC, and the Internet was continuing to expand. This is a very nice write up on the Microsoft view of the world. Those industry changes ultimately resulted in something we called Trustworthy Computing. Which was all about changing the way we develop software – “The data our software and services store on behalf of our customers should be protected from harm and used or modified only in appropriate ways. Security models should be easy for developers to understand and build into their applications.” There was also the Secure Windows Initiative. And the Security Development Lifecycle. And many other three letter acronyms I’m sure, because whatever it was you did, it needed a good TLA. We made a lot of progress over those ten years since then. We delivered on the goal that the security of the application can be better managed inside the OS and the application rather than at the network layer. But of course most people still seem to think of security as being mainly at the network layer, so think for a moment about what your hardware/software/appliance based firewall does today. It allows connections from a destination, on some configurable protocol/port, to a configured destination protocol/port. If you have a load balancer, and you configure it to allow inbound connections to an IP on its external interface, to TCP 443 specifically, telling it to ignore everything else, and it takes those packets and forward them to your Exchange servers, is that not the same thing as a firewall? Your load balancer is a packet filtering firewall. Don’t tell your load balancing vendor that, they might want to charge you extra for it, but it is. And when you couple that packet level filtering firewall/load balancer with software behind it that has been hardened for 10 years against attacks, you have a pretty darn secure setup. And that is the point. If you hang one leg of your load balancer on the Internet, and one leg on your LAN, and you operate a secure and well managed Windows/Exchange Server – you have a more secure environment than you think. Adding pre-authentication and layers of networking complexity in front of that buys you very little extra, if anything. So let’s apply this directly to Exchange, and try and offer you some advice from all of this. What should YOU do? The first thing to realize is that you now have a CHOICE. And the real goal of this post is to help you make an INFORMED choice. If you understand the risks, and know what you can and cannot do to mitigate them, you can make better decisions. Do I think everyone should throw out that TMG box they have today and go firewall commando? No. not at all. I think they should evaluate what it does for them, and, if they need it going forward. If they do that, and decide they still want pre-auth, then find something that can do it, when the time to replace TMG comes. You could consider it a sliding scale, of choice. Something like this perhaps; So this illustrated that there are some options and choices; Just use a load balancer – as discussed previously, a load balancer only allowing in specified traffic, is a packet filtering firewall. You can’t just put it there and leave it though, you need to make sure you keep it up to date, your servers up to date and possibly employ some form of IDS solution to tell you if there’s a problem. This is what Office 365 does. TMG/UAG – at the other end of the scale are the old school ‘application level’ firewall products. Microsoft has stopped selling TMG, but as I said earlier, that doesn’t mean you can’t use it if you already have it, and it doesn’t stop you using it if you buy an appliance with it embedded. In the middle of these two extremes (though ARR is further to the left of the spectrum as shown in the diagram) are some other options. Some load balancing vendors offer pre-authentication modules, if you absolutely must have pre-auth (but again, really… you should question the reason), some use LDAP, some require domain joining the appliance and using Kerberos Constrained Delegation, and Microsoft has two options here too. The first, (and favored by pirates the world over) is Application Request Routing, or ARR! for short. ARR! (the ! is my own addition, marketing didn’t add that to the acronym but if marketing were run by pirates, they would have) “is a proxy based routing module that forwards HTTP requests to application servers based on HTTP headers and server variables, and load balance algorithms” – read about it here, and in the series of blog posts we’ll be posting here in the not too distant future. It is a reverse proxy. It does not do pre-authentication, but it does let you put a non-domain joined machine in front of Exchange to terminate the SSL, if your 1990’s style security policy absolutely requires it, ARR is an option. The second is WAP. Another TLA. Recently announced at TechEd 2013 in New Orleans is the upcoming Windows Server 2012 R2 feature – Web Application Proxy. A Windows 2012 feature that is focused on browser and device based access and with strong ADFS support and WAP is the direction the Windows team are investing in these days. It can currently offer pre-authentication for OWA access, but not for Outlook Anywhere or ActiveSync. See a video of the TechEd session here (the US session) and here (the Europe session). Of course all this does raise some tough questions. So let’s try and answer a few of those; Q: I hear what you are saying, but Windows is totally insecure, my security guy told me so. A: Yes, he’s right. Well he was right, in the yesteryear world in which he formed that opinion. But times have changed, and when was the last time he verified that belief? Is it still true? Do things change in this industry? Q: My security guy says Microsoft keeps releasing security patches and surely that’s a sign that their software is full of holes? A: Or is the opposite true? All software has the potential for bugs and exploits, and not telling customers about risks, or releasing patches for issues discovered is negligent. Microsoft takes the view that informed customers are safer customers, and making vulnerabilities and mitigations known is the best way of protecting against them. Q: My security guy says he can’t keep up with the patches and so he wants to make the server ‘secure’ and then leave it alone. Is that a good idea? A: No. It’s not (I hope) what he does with his routers and hardware based firewalls is it? Software is a point in time piece of code. Security software guards against exploits and attacks it knows of today. What about tomorrow? None of us are saying Windows, or any other vendor’s solution is secure forever, which is why a well-managed and secure network keeps machines monitored and patched. If he does not patch other devices in the chain, overall security is compromised. Patches are the reality of life today, and they are the way we keep up with the bad guys. Q: My security guy says his hardware based firewall appliance is much more secure than any Windows box. A: Sure. Right up to the point at which that device has a vulnerability exposed. Any security device is only as secure as the code that was written to counter the threats known at that time. After that, then it’s all the same, they can all be exploited. Q: My security guy says I can’t have traffic going all the way through his 2 layers of DMZ and multitude of devices, because it is policy. It is more secure if it gets terminated and inspected at every level. A: Policy. I love it when I hear that. Who made the policy? And when? Was it a few years back? Have the business requirements changed since then? Have the risks they saw back then changed any? Sure, they have, but rarely does the policy get updated. It’s very hard to change the entire architecture for Exchange, but I think it’s fair to question the policy. If they must have multiple layers, for whatever perceived benefit that gives (ask them what it really does, and how they know when a layer has been breached), there are ways to do that, but one could argue that more layers doesn’t necessarily make it better, it just makes it harder. Harder to monitor, and to manage. Q: My security guy says if I don’t allow access from outside except through a VPN, we are more secure. A: But every client who connects via a VPN adds one more gateway/endpoint to the network don’t they? And they have access to everything on the network rather than just to a single port/protocol. How is that necessarily more secure? Plus, how many users like VPN’s? Does making it harder to connect and get email, so people can do their job, make them more productive? No, it usually means they might do less work as they cannot bothered to input a little code, just so they can check email. Q: My security guy says if we allow users to authenticate from the Internet to Exchange then we will be exposed to an account lockout Denial of Service (DoS). A: Yes, he’s right. Well, he’s right only because account lockout policies are being used, something we’ve been advising against for years, as they invite account lockout DoS’s. These days, users typically have their SMTP address set to equal their User Principal Name (UPN) so they can log on with (what they think is) their email address. If you know someone’s email address, you know their account logon name. Is that a problem? Well, only if you use account lockout policies rather than using strong password/phrases and monitoring. That’s what we have been telling people for years. But many security people feel that account lockouts are their first line of defense against dictionary attacks trying to steal passwords. In fact, you could also argue that a bad guy trying out passwords and getting locked out now knows the account he’s trying is valid… Note the common theme in these questions is obviously – “the security g uy said…..”. And it’s not that I have it in for security guys generally speaking, but given they are the people who ask these questions, and in my experience some of them think their job is to secure access by preventing access. If you can’t get to it, it must be safe right? Wrong. Their job is to secure the business requirements. Or put another way, to allow their business to do their work, securely. After all, most businesses are not in the business of security. They make pencils. Or cupcakes. Or do something else. And is the job of the security folks working at those companies to help them make pencils, or cupcakes, securely, and not to stop them from doing those things? So there you go, you have choices. What should you choose? I’m fine with you choosing any of them, but only if you choose the one that meets your needs, based on your comfort with risk, based on your operational level of skill, and based on your budget. Greg Taylor Principal Program Manager Lead Exchange Customer Adoption Team83KViews1like41CommentsExchange 2007 Autodiscover and certificates
Update 10/4/2007: Since this post has been published, we've updated the Exchange 2007 Autodiscover Service whitepaper to include this information. Please consult the whitepaper for most up-to-date information. In Exchange 2007, we introduce the idea of the Autodiscover service. This service allows your Outlook 2007 clients to retrieve the URLs that it needs to gain access to the new web services offered by Exchange 2007. These web services ( OAB , Unified Messaging, OOF , and Availability) provide a good portion of the new functionality available to Outlook 2007. For more details about the Outlook 2007 features that light up based on the Exchange server version, please see Outlook 2007 feature matrix based on Exchange Server version. For domain-joined clients, Outlook is able to find the Autodiscover service using a service connection point (SCP). The SCP is an Active Directory entry specific to each client access server. When Outlook 2007 is able to securely connect to the domain and read this entry from Active Directory, it can connect directly to this URL. Once connected to the Autodiscover end-point, the Autodiscover service provides the client with the URLs of the other exchange web services. For non-domain-joined clients or clients that are not able to directly access the domain, Outlook is hard-coded to find the Autodiscover end-point by looking up either https://company.com/Autodiscover/Autodiscover.xml or https://Autodiscover.company.com/Autodiscover/Autodiscover.xml (where company.com is the portion of the user's SMTP e-mail address following the @ sign). This means that to service clients in this scenario we must provide connectivity to one of these URLs. On the surface this should not be hard; but this connection is made over SSL and requires a valid certificate. SSL and Certificates The communication to the Autodiscover end-point and subsequent communications to the services all occur over SSL. This requires that we have valid certificates (signed by a trusted CA , with a Subject Name matching the URL the user is connecting to, and not expired) for the Autodiscover connection point and the services URLs. By default the services URLs are all variations of https://serversname. When you install a Client Access server, Exchange Setup creates a self-signed certificate that meets validity tests for domain joined clients. When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. The client must explicitly trust the issuing authority. Long-term use of this self-signed certificate is not recommended by Microsoft. Instead, it should be replaced with a commercially available Internet trusted, or a trusted internal PKI Infrastructure issued certificate as soon as possible. The problem is that we must be able to resolve Autodiscover.company.com or company.com with a trusted certificate in addition to other externally published exchange services like OWA. Most of our smaller customers currently only have an Exchange related certificate for use with OWA . This certificate usually has a Subject Name like mail.contoso.com. This continues to work for OWA in Exchange 2007, but now we also have to handle an SSL connection to Autodiscover.contoso.com. (Microsoft recommends using Autodiscover.company.com for the Autodiscover service.) This requires us to either resolve mail.contoso.com and Autodiscover.constoso.com to separate IP addresses, or to provide both names in the same certificate. Multiple names in one certificate Microsoft recommends that you provide both names in the same certificate. This is done thru something called a Unified Communications certificate, also know as a Subject Alternative Name certificate. There are a number of vendors that can provide you with this type of certificate (we covered experience with one of them here). The advantage of a Unified Communications certificate is that it makes configuration of Autodiscover much easier; the down side for our customers is that currently, this type of certificate can cost up to 10 times more than any existing single name certificates that they may already own. Configuration with this type of certificate is very easy. Here is a general outline of the process: Get a Unified Communications certificate for your environment with Autodiscover.company.com and any other names you need. (e.g. mail.company.com, www.company.com , etc) Apply the Certificate to the CAS server. Configure your internal SCP to point to Autodiscover.company.com Configure your Internal and External Service URLs to point to mail.company.com Make sure that your configured URLs resolves via DNS to the expected IP address of the CAS server Alternative methods If you're not able to get a Unified Communications certificate, there are two other methods you can use to get the same level of functionality. Both of these methods are supported by Microsoft but are harder to implement and manage over the longer term and thus could have a higher total cost of ownership depending on your environment. Both also require that you have two external IP addresses available. Method 1: Multiple Certificates To work around the need for a Unified Communications certificate, you can get two certificates for your environment – your existing mail.company.com certificate and a new autodiscover.company.com certificate. As long as we can serve up the correct certificate at the correct time we're able to connect with no issues. Doing this simply requires that we setup two virtual servers on the CAS server. One services Autodiscover.company.com on one IP address and the other services the remaining web services on mail.company.com using a different IP address. Here's an outline of this setup process: Get a certificate for mail.company.com and one for autodiscover.company.com Create a new virtual server in IIS on the Clien Access server Create a new Autodiscover virtual directory in the new virtual server and remove the old one Assign separate IP address and certificates to each Virtual server Configure your internal SCP to point to Autodiscover.company.com Configure your Internal and External Service URLs to point to mail.company.com Make sure that your configured URLs will resolve internally and externally via DNS to the expected IP address for each of the services In this configuration, internal domain member clients find the SCP to make the connection to Autodiscover. External clients find Autodiscover.company.com using DNS to make the connection to Autodiscover. In both cases, the clients are referred to mail.company.com for the actual Exchange Services. Method 2: Http Referral This option allows us to redirect the client to another URL for Autodiscover. The major downside of this configuration is that users are prompted in Outlook to confirm this redirection. There is a check box on the prompt to not get prompted again for this URL to limit the impact for users. To implement this configuration we still have to use two IP addresses and two virtual servers; but we only need one certificate. Here's an outline of this setup process: Create a virtual server on the Client Access server with a new IP address Create a stub Autodiscover virtual directory and Autodiscover.xml file thru IIS Redirect the Autodiscover.xml file to mail.company.com Configure your internal SCP to point to mail.company.com Configure your Internal and External Service URLs to point to mail.company.com Make sure that your configured URLs will resolve via DNS to the expected IP address of the Client Access server In this configuration, domain member clients get the SCP and connect to the Autodiscover service using that URL. External clients connect to Autodiscover.company.com over http and get a referral to mail.company.com. External Outlook clients are prompted the first time they make this connection to verify they are being redirected to a trusted URL; once that is accepted Outlook connects to the mail.company.com for Autodiscover. Conclusion There are multiple ways to setup Exchange 2007 to support Outlook 2007 clients and the new services URLs. You have to decide what method is best for your environment, technical skill level, and cost. Implementation Pros Cons Unified Communications certificate Easy to implement Supports all client connections Future proof Microsoft Recommended best practice Higher cost of the Unified Communications certificate Multiple certificates and websites Lower cost Both sites are secured with SSL Requires an additional public IP address Somewhat complex to setup and maintain Single certificate with redirect Can be done with only your existing certificate No additional Cost Requires an additional public IP address Non Domain joined users receive a prompt when they first connect Somewhat complex to setup Additional resources / related reading: White Paper: Exchange 2007 Autodiscover Service Unified Communications Certificate Partners for Exchange Server and for Communications Server Set-ClientAccessServer cmdlet help How to Configure SSL Certificates to Use Multiple Client Access Server Host Names Deployment Considerations for the Autodiscover Service: Using Multiple Sites for Internet Access to the Autodiscover Service Deployment Considerations for the Autodiscover Service: Hosted Environments and the Autodiscover Service How to Configure Exchange Services for the Autodiscover Service There's an excellent script at http://www.exchangeninjas.com/set-allvdirs that can assist you in setting up all of the URLs and the SCP without having to type out all of the commands. This script is provided as is and use of the script is solely at your own risk. Matthew Byrd76KViews0likes26CommentsExchange Server 2007 Out of Office (OOF)
The Out of Office (OOF) feature is commonly used by end-users to let other people know when they are not available to respond to e-mail. Exchange 2007 Out of Office capabilities such as scheduled OOF, different external and internal OOF messages and the ability to control what kind of OOF to send on a per-domain basis improves the experience for both end-users and for administrators. For End-Users In Exchange Server 2007, some of the new Out of Office Assistant features are: The ability to schedule OOF messages in advance. If users are planning time away from the office, they can set their OOF to begin at a future date and time and do not have to worry about forgetting to turn on OOF right before leaving. Separate internal and external OOF messages. This way, private information can be shared with co-workers without sending that information out to external senders. External OOF messages can be sent only to a user's external contacts. Some users want to send their Out of Office messages only to a limited set of external contacts, but not anyone who might email them - for privacy reasons. OOF messages can now be set as HTML instead of plain-text. OWA and Outlook 2007 users who are hosted on Exchange 2007 mailboxes will see these new capabilities. Outlook 2007 users who are on Exchange 2003 (or earlier) servers will have the same features as they have with Outlook 2003. This screen shots show the OOF configuration options available to end-users in Outlook Web Access (please click on the thumbnail to see the full size screenshot): For Administrators and Exchange organizations In Exchange 2007, Administrators can choose to control external OOF capabilities at a per-domain and per-user level. Some organizations do not enable external OOF messages today, because they do not believe they are "safe". Some users put personal information in their OOF message that should not be leaked externally, and some companies have expressed concern about OOF messages as a mechanism for spammers to validate users' email addresses. In Exchange 2007, we believe we've addressed these organizational concerns. For other customers, they would like to enable some of their users for external OOF messages (such as the ones working directly with customers), but not all of them. Per User Settings Exchange 2007 lets administrators control per-user external OOF messages using the Monad command "Set-Mailbox" with the "ExternalOOFOptions" parameter: MSH>Set-Mailbox -id <mailbox identity> -ExternalOOFOptions [InternalOnly,External] By default, per-user external OOF option is set to allow external OOF. By setting this to "InternalOnly" for a given mailbox, instead of "External", that mailbox will not be able to send OOF messages outside the company, using any client, regardless of what the user selects. Per-Domain Settings Administrators can also control which (if any) OOF messages go to which external domains. These per-domain settings are set via the Monad command "Set-remoteDomain" using the parameter "AllowedOOFType": MSH>Set-remoteDomain -Identity <domain identity> -AllowedOOFType [None,InternalLegacy,Internal,External(Default)] The AllowedOOFType values are as follows: None: This blocks all OOF messages to the target domain. InternalLegacy: This allows either Exchange 2007 internal OOF or OOF set by Outlook 2003 or earlier clients to be sent to the target domain but blocks Exchange 2007 external messages from being sent to the target domain. You would use this setting with a close partner company who you wanted to receive your internal OOF messages. You would also use this setting in a cross-forest environment where one company had multiple Exchange deployments. ExternalLegacy: This setting allows either Exchange 2007 external OOF or OOF set by Outlook 2003 or earlier clients to be sent to the target domain. If you already allow OOF messages to flow outside your company, you probably want to use this setting, so that existing Outlook 2003 users do not see any change in behavior. External (the default): This setting allows only Exchange 2007 external OOF messages to be sent to the target domain but blocks internal OOF messages or OOF messages set using Exchange 2003. If you currently block OOF messages to other domains, you probably want to use this setting in order to keep the same behavior for Outlook 2003 users but allow Exchange 2007 external OOF messages out for those who specifically choose them. You can choose the wildcard '*' for the target domain if you wish your per-domain OOF settings to apply to all external domains that don't otherwise have a specific setting for them. The following screen shot shows the per-domain OOF configuration settings in Exchange Management Console (please click the thumbnail to see a big version): In addition, in Exchange 2007 OOF responses are more secure because of the following two checks: OOF messages will not be sent out in response to server-detected Junk E-mail. If Exchange 2007 detects a message as Junk or if the message sender is in the user's block list, no OOF response is sent. OOF messages are not sent as responses to Internet mailing lists. Exchange 2007 does not send OOF responses for incoming messages with the Precedence:bulk header set. However, if this header is missing, it is possible that OOF responses may be sent out because there is no reliable way of determining that the message was sent to a mailing list. OOF messages are also not sent as responses for incoming messages with the X-Auto-Response-Suppress:OOF header. PS. If you ever wondered what "OOF" stands for - go read this post. - Ashish Consul71KViews0likes20CommentsOWA for iPhone and OWA for iPad are now available!
Today, we are excited to announce the availability of OWA for iPhone and OWA for iPad, which provides even more value to organizations on any Office 365 subscription that includes Exchange Online. OWA for iPhone and OWA for iPad are mobile apps that offer the same email, calendar, and contact functionality you get in Outlook Web App on the browser, but with additional capabilities that are only possible through native integration of the app with mobile devices. Our goal is to help our customers remain productive anytime, anywhere. This includes providing a great email experience on smartphones and tablets. We already offer Exchange ActiveSync (EAS), which is the de facto industry standard for accessing Exchange email on mobile devices. Windows Phone 8 comes with Outlook Mobile, and the Outlook Web App experience in the Windows Phone 8 browser is top-notch. In order to better support many of our customers who use their iPhones and iPads for work, we are introducing OWA for iPhone and OWA for iPad, which bring a native Outlook Web App experience to iOS devices! OWA for iPhone and OWA for iPad can be installed directly from the Apple App Store. A subscription to Office 365 that includes Exchange Online is required to use the app.1 If you aren’t already an Office 365 subscriber, you can visit www.office.com to learn more and sign up. Note: OWA for iPhone/iPad is for Office 365 customers who have the newest update of Exchange Online. Support for Exchange Server 2013 is planned for the future. For more details, head over to OWA for iPhone and OWA for iPad on the Office 365 technology blog. Note: for additional information about OWA for iPad as well as some related troubleshooting information, you can go to the OWA for iPhone and OWA for iPad Office 365 Wiki page. The Exchange Team67KViews0likes46CommentsPublish S/MIME certificates for external contacts to Active Directory for use with Exchange Server 2007
In the past, if you wished to use S/MIME for e-mail encryption with an external recipient, you would add the recipient to your Contacts folder. This was typically done by having the recipient send you a digitally signed item and then right click on the recipient in the From field and click "Save to Contacts". This solution was difficult for Helpdesk and Administration personnel to manage, as only the mailbox user (or someone logged on as the user) could modify the Contacts. Rather than a warning that the certificate in the contact had expired, the user would see somewhat cryptic error messages when attempting to send a signed/encrypted message. Having seen a growing interest from customers regarding how to decrease administrative overhead associated with handling these issues (Helpdesk tickets, etc.), customers have requested information regarding how to save a remote recipient's public key to an AD Contact, so that it can be updated once, and addressed in Outlook via the Global Address List (GAL). A quick look at an AD contact vs. an AD user in Active Directory Users and Computers (ADUC) shows a vastly different experience with respect to certificates - there is essentially nothing exposed in the UI for the contact (on the left), while the user object has a rich certificate interface (on the right): Fortunately, using a tool like LDP, we find that both types of objects contain the needed attributes to allow us to store certificates for use with Outlook and/or OWA. The attribute that needs to contain the certificate is the userCertificate attribute, which exists for the object, but has no facility in the UI to load the certificate. Sounds like a job for Certutil.exe... This utility is part of Certificate Services in Windows Server 2003. It can also be downloaded here. http://www.microsoft.com/downloads/details.aspx?FamilyID=C16AE515-C8F4-47EF-A1E4-A8DCBACFF8E3&displaylang=en Certutil.exe is a command line tool that provides a way to manage certificates, particularly to add certificates to AD objects - like our contact. The syntax required is: This assumes some prerequisites: The certificate needs to have an "E" value in its subject. The "E" value must match the SMTP address assigned to the contact. The certificate needs to be valid - (validity period, trusted, etc.), or issues will crop up later. The user sending the signed/encrypted email has their own valid certificate. Executing the certutil syntax properly results in <ldp: Binary Blob> showing up in the userCertificate attribute if viewed from LDP. So far so good... Now all that remains is to open Outlook, create a new message, pick the newly "certified" contact from the GAL, set the message security options to encrypt, and the send the message. Again, provided that the user sending the message has their own certificate, this works like a champ, otherwise, they will see an error message indicating the sender doesn't have a valid certificate, and the message will have to be sent un-encrypted - more on this a little later. Things are essentially the same if using an internal (ie. not trusted in popular browsers) CA. For our testing purposes, we used Windows 2003 Certificate Services, and issued certificates using the default "User" template. (Discussion of templates, their care and feeding, etc. are beyond the scope of this article, please refer to http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx as a good starting point) The most common issue we encounter when using an "Internal" CA is that the CA is not trusted by either the client machine, the Exchange servers, or both. Opening a certificate on a machine that doesn't trust the CA will look as follows: This condition is manifested in OWA and Outlook as well, but with a different message (please click to see a bigger version): Once you have the certificate trust issue resolved, you'll see the following instead: Steps to publish the S/MIME certificate to Active Directory: 1. Obtain the public certificate from the user and save it where certutil.exe is loaded. 2. Open the certificate and verify the subject name that it is issued to. 3. Create a new mail enabled contact in the Exchange Management Console. 4. Give it a matching E mail address as the subject name on the certificate. 5. Open a command prompt. 6. Run certutil -dspublish c:\path-to-user.cer The utility will match the E= value to an item in Active Directory. If this is not found it will then try to match the distinguished name in the subject field to the distinguished name in Active Directory. If it does not find a match the operation will fail. You can verify the command was successful with ADSIEdit (as well as LDP.exe). The certificate will be placed in the userCertificate attribute on the matching contact object. It will be populated as an Octet string, so it will not be in a readable format. This attribute is <not set> by default. To remove the certificate simply remove the value from this field. In OWA, if you bring up the properties of the contact from the global address list, you will see the recipient has a valid digital ID for S/MIME - "Secure Messaging The Recipient has a valid Digital ID for encrypting e-mail messages." Troubleshooting So, you went through all the steps, and it still didn't work - got an error like the following: Most often, this indicates that the recipients certificate was issued by a Root CA, and/or an Intermediate CA, that isn't trusted - obtain the Root certificate, and any intermediates, from the remote Organization, and install them on the appropriate computers: From a workstation, you can just install the certificate using the Wizard. If you need to install it on a server, the best way to proceed is to Use the Certificates MMC to install the certificate, because you need to install it to the "Local Computer" account to trust CA. Go to Start > Run, type in MMC, and press Enter. Once the MMC opens, File > Add/Remove Snapin, Add the "Certificates" snapin... NOTE: choose the "Computer Account" radio button. Finish the wizard and you should see "Certificates (Local Computer)": Drill down to Trusted Root Authorities > Certificates folder, right click and choose Import: Work through the wizard, specifying the file to import: Once the wizard is complete, you should see the CA in the list. To be sure you are covered, it is best to repeat this for all Exchange servers in the Org for each CA Root certificate and/or Intermediate. Now when you look at the cert, it should look like: "But I can't get the certificate published using the tool!" - Make certain that the SMTP address configured in the certificate matches the AD contact. You should be able to publish even if the certificate is not trusted, although this isn't a good idea, as you will almost certainly run into the preceding error. Also note that if you try to publish a certificate into an AD contact that already has one, you will receive an error message indicating you can't overwrite the existing cert. Use ADSIEdit, or your favorite LDAP tool to remove the certificate and re-publish. Note: Be very careful when using tools like ADSIEdit, as they can cause significant damage if used incorrectly. A word about Certificate handling in OWA versus Outlook - In order for this to work the user sending email has to have a valid certificate installed on the machine from which they are sending. This is because the Exchange security model requires a certificate for both parties when sending signed/encrypted email (http://technet.microsoft.com/en-us/library/aa997737.aspx). OWA will detect the presence of the user's certificate, and perform the appropriate operation assuming: The certificates are issued for the intended purpose There aren't multiple certificates for the user in the certificate database The first one in the list is expired or otherwise invalid. OWA uses the first cert in the list, even if it is no good. Hopefully, the user has only one private key for decrypting messages, so this doesn't become a problem. If the user has several private keys, each one will need to be installed on the workstation where they are accessing their mailbox for the body of messages they need to decrypt. OWA will also handle the scenario where one certificate is issued for Encryption, and another is issued for Digital Signing. It determines which to use based on the values in the "Key Usage" attribute on the certificate: Outlook, on the other hand implements handling of multiple S/MIME certificates Settings, where the user can choose a certificate to be the default for signing/encrypting. The user can create a message to be sent to a user, and choose the certificate they wish for Outlook to refer to for Exchange Security purposes. This can be changed at any time by the user, and should work provided that they don't select an invalid cert. (http://office.microsoft.com/en-us/outlook/HP012305371033.aspx - Get a Digital ID: provides info on configuring certificates in the Trust Center) Note: The examples in this article were conducted using Exchange/OWA/Outlook 2007, using Windows 2003 AD and CA. You should see similar behavior from Exchange/OWA/Outlook 2003, but your experience may vary, particularly with diagnostic messages. We strongly recommend that you test this process extensively in your labs to make sure that it gives you the functionality that you expect. Additional reading http://msexchangeteam.com/archive/2007/08/20/446760.aspx - Secure Messaging with S/MIME and OWA on Exchange Server 2007 SP1 http://msexchangeteam.com/archive/2005/01/14/353167.aspx - Common Trust, Encryption and Digital ID Troubleshooting - for Microsoft Outlook and Microsoft Exchange users http://office.microsoft.com/en-us/outlook/CH100622191033.aspx - Security and privacy for Outlook 2007 How to - DJ Ball, Roman Maddox66KViews0likes4Comments