Introducing: Log Parser Studio
To download the Log Parser Studio, please see the attachment on this blog post. Anyone who regularly uses Log Parser 2.2 knows just how useful and powerful it can be for obtaining valuable information from IIS (Internet Information Server) and other logs. In addition, adding the power of SQL allows explicit searching of gigabytes of logs returning only the data that is needed while filtering out the noise. The only thing missing is a great graphical user interface (GUI) to function as a front-end to Log Parser and a ‘Query Library’ in order to manage all those great queries and scripts that one builds up over time. Log Parser Studio was created to fulfill this need; by allowing those who use Log Parser 2.2 (and even those who don’t due to lack of an interface) to work faster and more efficiently to get to the data they need with less “fiddling” with scripts and folders full of queries. With Log Parser Studio (LPS for short) we can house all of our queries in a central location. We can edit and create new queries in the ‘Query Editor’ and save them for later. We can search for queries using free text search as well as export and import both libraries and queries in different formats allowing for easy collaboration as well as storing multiple types of separate libraries for different protocols. Processing Logs for Exchange Protocols We all know this very well: processing logs for different Exchange protocols is a time consuming task. In the absence of special purpose tools, it becomes a tedious task for an Exchange Administrator to sift thru those logs and process them using Log Parser (or some other tool), if output format is important. You also need expertise in writing those SQL queries. You can also use special purpose scripts that one can find on the web and then analyze the output to make some sense of out of those lengthy logs. Log Parser Studio is mainly designed for quick and easy processing of different logs for Exchange protocols. Once you launch it, you’ll notice tabs for different Exchange protocols, i.e. Microsoft Exchange ActiveSync (MAS), Exchange Web Services (EWS), Outlook Web App (OWA/HTTP) and others. Under those tabs there are tens of SQL queries written for specific purposes (description and other particulars of a query are also available in the main UI), which can be run by just one click! Let’s get into the specifics of some of the cool features of Log Parser Studio … Query Library and Management Upon launching LPS, the first thing you will see is the Query Library preloaded with queries. This is where we manage all of our queries. The library is always available by clicking on the Library tab. You can load a query for review or execution using several methods. The easiest method is to simply select the query in the list and double-click it. Upon doing so the query will auto-open in its own Query tab. The Query Library is home base for queries. All queries maintained by LPS are stored in this library. There are easy controls to quickly locate desired queries & mark them as favorites for quick access later. Library Recovery The initial library that ships with LPS is embedded in the application and created upon install. If you ever delete, corrupt or lose the library you can easily reset back to the original by using the recover library feature (Options | Recover Library). When recovering the library all existing queries will be deleted. If you have custom/modified queries that you do not want to lose, you should export those first, then after recovering the default set of queries, you can merge them back into LPS. Import/Export Depending on your need, the entire library or subsets of the library can be imported and exported either as the default LPS XML format or as SQL queries. For example, if you have a folder full of Log Parser SQL queries, you can import some or all of them into LPS’s library. Usually, the only thing you will need to do after the import is make a few adjustments. All LPS needs is the base SQL query and to swap out the filename references with ‘[LOGFILEPATH]’ and/or ‘[OUTFILEPATH]’ as discussed in detail in the PDF manual included with the tool (you can access it via LPS | Help | Documentation). Queries Remember that a well-written structured query makes all the difference between a successful query that returns the concise information you need vs. a subpar query which taxes your system, returns much more information than you actually need and in some cases crashes the application. The art of creating great SQL/Log Parser queries is outside the scope of this post, however all of the queries included with LPS have been written to achieve the most concise results while returning the fewest records. Knowing what you want and how to get it with the least number of rows returned is the key! Batch Jobs and Multithreading You’ll find that LPS in combination with Log Parser 2.2 is a very powerful tool. However, if all you could do was run a single query at a time and wait for the results, you probably wouldn’t be making near as much progress as you could be. In lieu of this LPS contains both batch jobs and multithreaded queries. A batch job is simply a collection of predefined queries that can all be executed with the press of a single button. From within the Batch Manager you can remove any single or all queries as well as execute them. You can also execute them by clicking the Run Multiple Queries button or the Execute button in the Batch Manager. Upon execution, LPS will prepare and execute each query in the batch. By default LPS will send ALL queries to Log Parser 2.2 as soon as each is prepared. This is where multithreading works in our favor. For example, if we have 50 queries setup as a batch job and execute the job, we’ll have 50 threads in the background all working with Log Parser simultaneously leaving the user free to work with other queries. As each job finishes the results are passed back to the grid or the CSV output based on the query type. Even in this scenario you can continue to work with other queries, search, modify and execute. As each query completes its thread is retired and its resources freed. These threads are managed very efficiently in the background so there should be no issue running multiple queries at once. Now what if we did want the queries in the batch to run concurrently for performance or other reasons? This functionality is already built-into LPS’s options. Just make the change in LPS | Options | Preferences by checking the ‘Process Batch Queries in Sequence’ checkbox. When checked, the first query in the batch is executed and the next query will not begin until the first one is complete. This process will continue until the last query in the batch has been executed. Automation In conjunction with batch jobs, automation allows unattended scheduled automation of batch jobs. For example we can create a scheduled task that will automatically run a chosen batch job which also operates on a separate set of custom folders. This process requires two components, a folder list file (.FLD) and a batch list file (.XML). We create these ahead of time from within LPS. For more details on how to do that, please refer to the manual. Charts Many queries that return data to the Result Grid can be charted using the built-in charting feature. The basic requirements for charts are the same as Log Parser 2.2, i.e. The first column in the grid may be any data type (string, number etc.) The second column must be some type of number (Integer, Double, Decimal), Strings are not allowed Keep the above requirements in mind when creating your own queries so that you will consciously write the query to include a number for column two. To generate a chart click the chart button after a query has completed. For #2 above, even if you forgot to do so, you can drag any numbered column and drop it in the second column after the fact. This way if you have multiple numbered columns, you can simply drag the one that you’re interested in, into second column and generate different charts from the same data. Again, for more details on charting feature, please refer to the manual. Keyboard Shortcuts/Commands There are multiple keyboard shortcuts built-in to LPS. You can view the list anytime while using LPS by clicking LPS | Help | Keyboard Shortcuts. The currently included shortcuts are as follows: Shortcut What it does CTRL+N Start a new query. CTRL+S Save active query in library or query tab depending on which has focus. CTRL+Q Open library window. CTRL+B Add selected query in library to batch. ALT+B Open Batch Manager. CTRL+B Add the selected queries to batch. CTRL+D Duplicates the current active query to a new tab. CTRL+ALT+E Open the error log if one exists. CTRL+E Export current selected query results to CSV. ALT+F Add selected query in library to the favorites list. CTRL+ALT+L Open the raw Library in the first available text editor. CTRL+F5 Reload the Library from disk. F5 Execute active query. F2 Edit name/description of currently selected query in the Library. F3 Display the list of IIS fields. Supported Input and Output types Log Parser 2.2 has the ability to query multiple types of logs. Since LPS is a work in progress, only the most used types are currently available. Additional input and output types will be added when possible in upcoming versions or updates. Supported Input Types Full support for W3SVC/IIS, CSV, HTTP Error and basic support for all built-in Log Parser 2.2 input formats. In addition, some custom written LPS formats such as Microsoft Exchange specific formats that are not available with the default Log Parser 2.2 install. Supported Output Types CSV and TXT are the currently supported output file types. Log Parser Studio - Quick Start Guide Want to skip all the details & just run some queries right now? Start here … The very first thing Log Parser Studio needs to know is where the log files are, and the default location that you would like any queries that export their results as CSV files to be saved. 1. Setup your default CSV output path: a. Go to LPS | Options | Preferences | Default Output Path. b. Browse to and select the folder you would like to use for exported results. c. Click Apply. d. Any queries that export CSV files will now be saved in this folder. NOTE: If you forget to set this path before you start the CSV files will be saved in %AppData%\Microsoft\Log Parser Studio by default but it is recommended that y ou move this to another location. 2. Tell LPS where the log files are by opening the Log File Manager. If you try to run a query before completing this step LPS will prompt and ask you to set the log path. Upon clicking OK on that prompt, you are presented with the Log File Manager. Click Add Folder to add a folder or Add File to add a single or multiple files. When adding a folder you still must select at least one file so LPS will know which type of log we are working with. When doing so, LPS will automatically turn this into a wildcard (*.xxx) Indicating that all matching logs in the folder will be searched. You can easily tell which folder or files are currently being searched by examining the status bar at the bottom-right of Log Parser Studio. To see the full path, roll your mouse over the status bar. NOTE: LPS and Log Parser handle multiple types of logs and objects that can be queried. It is important to remember that the type of log you are querying must match the query you are performing. In other words, when running a query that expects IIS logs, only IIS logs should be selected in the File Manager. Failure to do this (it’s easy to forget) will result errors or unexpected behavior will be returned when running the query. 3. Choose a query from the library and run it: a. Click the Library tab if it isn’t already selected. b. Choose a query in the list and double-click it. This will open the query in its own tab. c. Click the Run Single Query button to execute the query The query execution will begin in the background. Once the query has completed there are two possible outputs targets; the result grid in the top half of the query tab or a CSV file. Some queries return to the grid while other more memory intensive queries are saved to CSV. As a general rule queries that may return very large result sets are probably best served going to a CSV file for further processing in Excel. Once you have the results there are many features for working with those results. For more details, please refer to the manual. Have fun with Log Parser Studio! & always remember – There’s a query for that! Kary Wall Escalation Engineer Microsoft Exchange SupportSupport of DANE and DNSSEC in Office 365 Exchange Online
Microsoftis committedto providing world-classemailsecurity solutionsand the support forthe latestInternetstandards in order to provide advanced email protection for our customers.Today we areannouncing that Exchange Online will be adding support for two new Internet standards specific to SMTP traffic.Life 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 TeamConfiguring 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 ExperienceClient Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2013
Our goal with this article is to articulate the various connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2013 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016. Note: While not explicitly called out in this blog post and graphics, Exchange 2019 behavior is the same as Exchange 2016 behavior. Existing Environment 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 has Exchange 2013 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2013 infrastructure. Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2013 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2013 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 2013 infrastructure. Note: The term, Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURL property populated. To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the three users. Autodiscover The Autodiscover 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 retrieve configuration settings based on their mailbox’s location. Note: The recommended practice is to configure the 2013 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 internal load balanced VIP for the 2013 Client Access servers in your environment. For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service. Outlook Anywhere & MAPI/HTTP Clients When you have an Exchange 2013 or later mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 and later mailboxes. In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013 (and Exchange 2016), 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 Outlook Updates 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 use different names for Outlook Anywhere inside and out. Outlook will also prefer 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. By utilizing two namespaces for Outlook Anywhere, you can ensure that your internal clients can connect utilizing Kerberos authentication. The default Exchange 2013 (and Exchange 2016) 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. For Outlook Anywhere clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will de-encapsulate the RPC from the HTTP packet and obtain the data. For MAPI/HTTP clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will act on the MAPI ROPs embedded in the HTTP protocol and obtain the data. Red User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3. Orange User will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Note: In ad dition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, url’s for which are provided via the Autodiscover response. Outlook Web App For Outlook Web App clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site. Red User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site 3. 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. 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 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. 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 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. Exchange ActiveSync For Exchange ActiveSync clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. CAS2013 in Site1 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data. In addition, Exchange 2013 and later no longer supports the 451 redirect response – Exchange 2013 and later will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed). Red User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3. For the Orange User, there are two possible scenarios: Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. 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. CAS2013 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Exchange Web Services For Exchange Web Services clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Client Connectivity with Exchange 2016 in Site1 Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. Both Exchange 2013 Client Access servers and Exchange 2016 Mailbox servers participate in the load balanced namespace mail.contoso.com and autodiscover.contoso.com. To understand the client connectivity now that Exchange 2016 exists in the environment, let’s look at the four users. A utodiscover Either CAS2013 or MBX2016 in Site1 will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located. CAS2013 or MBX2016 will proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response. Outlook Anywhere & MAPI/HTTP Connectivity For Outlook Anywhere connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s RPC proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server). For MAPI/HTTP connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s MAPI virtual directory proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server). Red User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Purple User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3. Orange User will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Outlook on the web For Outlook on the web clients, either an Exchange 2013 Client Access server or an Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site. Red User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Purple User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013/MBX2016 in Site1 will proxy the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site 3. 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013/MBX2016 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 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. Exchange ActiveSync The Exchange 2013 Client Access server or Exchange 2016 Mailbox server receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server) Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Purple User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3. For the Orange User, there are two possible scenarios: Orange User’s ActiveSync client will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. Orange User’s ActiveSync client will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013/MBX2016 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Exchange Web Services Like with other protocols, Exchange Web Services follows the same methodology. Either an Exchange 2013 Client Access server or Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version or where the mailbox is located. The server will then proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. For the Purple User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Offline Address Book Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL. For the Red User, Purple User and Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active copy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL. Conclusion Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2016 when coexisting with Exchange 2013. Please let us know if you have any questions.Client Connectivity in an Exchange 2016 Coexistence Environment with Mixed Exchange Versions
Our goal with this article is to articulate the various connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2013 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016. Existing Environment 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 has Exchange 2013 and Exchange 2010 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2013 infrastructure. Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2013 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2013 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 Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURLproperty populated. To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the four users. Autodiscover The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records for all Client Access servers resolve to the CAS2013 infrastructure located in Site1. Outlook clients, ActiveSync clients (on initial configuration), and EWS clients 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, 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 2013 (Purple User and Orange User), 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. Note: The recommended practice is to configure the 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 AutoDiscoverServiceInternalUrito a value that resolves to the internal load balanced VIP for the 2013 Client Access servers in your environment. For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service. Outlook Anywhere & MAPI/HTTP Clients 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. When you have an Exchange 2013 or later mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 and later mailboxes. In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013 (and Exchange 2016), 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 OutlookUpdates 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 use different names for Outlook Anywhere inside and out. Outlook will also prefer 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. By utilizing two namespaces, you can ensure that your internal clients can connect utilizing Kerberos authentication. The default Exchange 2013 (and Exchange 2016) 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. For Outlook Anywhere clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows. For MAPI/HTTP clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will act on the MAPI ROPs e mbedded in the HTTP protocol and obtain the data. 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 perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to a CAS2010 server in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server. Orange User will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, url’s for which are provided via the Autodiscover response. Outlook Web App For Outlook Web App clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version, where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site. 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 endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the HTTP session to a CAS2010 server 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. 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 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. 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 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. Exchange ActiveSync For Exchange ActiveSync clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows. Note: Exchange 2013 and later no longer supports the 451 redirect response – Exchange 2013 and later will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed). 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 his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Blue User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to a CAS2010 server 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. 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. CAS2013 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Exchange Web Services For Exchange Web Services clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS 2013 will then proxy the request to an Exchange 2010 Client Access server within the local site. For the Purple User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to a CAS2010 server in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Client Connectivity with Exchange 2016 in Site1 Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. Both Exchange 2013 Client Access servers and Exchange 2016 Mailbox servers participate in the load balanced namespace mail.contoso.com and autodiscover.contoso.com. To understand the client connectivity now that Exchange 2016 exists in the environment, let’s look at the five users. Autodiscover Either CAS2013 or MBX2016 in Site1 will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located. CAS2013 or MBX2016 will proxy the request as follows. For mailboxes that exist on Exchange 2010, CAS2013/MBX2016 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, 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 2013 (Purple User and Orange User), CAS2013/MBX2016 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. For mailboxes that exist on Exchange 2016 (Yellow User), CAS2013/MBX2016 will proxy the request to the Exchange 2016 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response. Outlook Anywhere & MAPI/HTTP Connectivity For Outlook Anywhere’s connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s RPC proxy component will receive the incoming connections, authenticate and choose which server to route the request to (regardless of version), and proxy the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server or Exchange 2016 Mailbox server). For MAPI/HTTP connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s MAPI virtual directory proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server). Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 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/MBX2016 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 or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Yellow User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. CAS2013/MBX2016 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 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Outlook on the web For Outlook on the web clients, either an Exchange 2013 Client Access server or an Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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. MBX2016 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 endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Yellow User will connect to mail.contoso .com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. Blue User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013/MBX2016 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013/MBX2016 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 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. Exchange ActiveSync The Exchange 2013 Client Access server or Exchange 2016 Mailbox server will receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server, or Exchange 2016 Mailbox server). Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 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/MBX2016 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 his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. Yellow User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. CAS2013/MBX2016 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013/MBX2016 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. Exchange Web Services Like with other protocols, Exchange Web Services follows the same methodology. Either an Exchange 2013 Client Access server or Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version or where the mailbox is located. The server will then proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 will then proxy the request to an Exchange 2010 Client Access server within the local site. For the Purple User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1. For the Yellow User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2. 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/MBX2016 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 Yellow User and Purple User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active c opy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 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. Conclusion Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2016 when coexisting with both Exchange 2010 and Exchange 2013. Please let us know if you have any questions. Ross Smith IV Principal Program Manager Office 365 Customer Experience
