##Update 30 Aug 2013##

The MS13-061 security update has been re-released for Exchange Server 2013, the download links below have been updated.

##Update 15 Aug 2013##

The MS13-061 security update for Exchange Server 2013 has been pulled as it seems to cause an issue with the Content Index for mailbox databases. If you have already installed this update see KB2879739 for information on how to resolve this. This issue does not occur in Exchange 2010 or Exchange 2007.

A few hours ago Microsoft released a critical security update for all supported editions of Microsoft Exchange Server 2007, 2010, and 2013. This security update addresses vulnerabilities that exist in the WebReady Document Viewing and Data Loss Prevention features of Exchange that could allow remote code execution in the security context of the transcoding service on the Exchange server if a user previews a specially crafted file using Outlook Web App. For detailed information, see Microsoft Security Bulletin MS13-061

Microsoft recommends that customers apply the update immediately. The update can be downloaded at the following links:

• Update Rollup 11 for Exchange Server 2007 SP3
• Update Rollup 7 for Exchange Server 2010 SP2
• Update Rollup 2 For Exchange 2010 SP3
• Security Update For Exchange Server 2013 CU1
• Security Update For Exchange Server 2013 CU2

Perhaps you are planning your on-premises upgrade to Exchange 2013 or you’ve just introduced the first Exchange 2013 server into your existing Exchange 2010 environment. Welcome to coexistence! Hopefully by now you already know that the Exchange Admin Center (EAC) is the web-based management console in Microsoft Exchange Server 2013 and it replaces the Exchange Management Console (EMC) and the Exchange Control Panel (ECP), which were the two interfaces used to manage Exchange Server 2010.

So how do you access the EAC? Well.. if you had just installed a fresh new Exchange 2013 org you would simply navigate to https:///ecp in your browser. In a coexistence scenario however, doing that would redirect you to Exchange 2010 ECP and you would probably see something like this (once logged in):

The reason for this is that your mailbox is probably still located on an Exchange 2010 server. You now have two options:

1. Move your mailbox to Exchange 2013 and try again, or
2. Use the following URL: https:///ecp?ExchClientVer=15 

You should now see the Exchange 2013 Admin Center which will look something like this:

You are now able to continue configuring Exchange 2013 via the EAC.

Read more about the EAC here

Mario Tevanian (Microsoft) and I will be presenting a “Exchange 2013 Hybrid Deployments” session at TechEd Australia 2013 (3-6 September, Gold Coast) The session will provide an overview of the complete range of migration options that are available when migrating to Exchange Online and discuss the new Exchange 2013 hybrid configuration wizard. Did you know that public folders are now supported in Exchange Online? Come and learn more about modern public folders and how to migrate them. In this session we also share some notes from the field and highlight the recommended approach and best practices you should consider as you plan to migrate your existing Exchange environment to Exchange Online.

Room and time slot details are not available yet, but I’ll share them as soon as I know what they are. The session code is: EXL314. See you there!

Microsoft Application Request Routing (ARR) is a proxy-based routing module for IIS that forwards HTTP requests to content servers based on HTTP headers, server variables, and load balance algorithms. After my recent posts on reverse proxy servers and Exchange Server I received a few emails about using ARR as a reverse proxy for Exchange Server. The Exchange Team recently released some guidance on how to achieve this on their blog for those of you who are interested in this setup, here is a link to the post.

In March this year I wrote a post entitled “Exchange Server and the Reverse Proxy”. I had many similar conversations with peers and customers about the topic, and at the time my intention was twofold:

1. Question the ‘old school’ notion that Exchange services published to the internet are only secure if a reverse proxy is used;
2. Provide a high-level list of potentially suitable solutions for customers planning new deployments who felt they still needed a reverse proxy.

I’ve received many comments and emails about that post and have been planning to put together this follow-up for some time now so it was a happy coincidence when the ever entertaining (and deceptively brilliant!) Greg Taylor recently posted about the same topic on the Exchange Team blog. I’m sure he won’t mind me ‘borrowing’ some of this content, it is not my intention to take anything out of context so feel free to read this entire post here. A couple of things that really stand out in his post are:

“Here are some interesting Exchange-related facts to help further cement the idea I’m eventually going to get to.

1. We do not require traffic to be authenticated prior to hitting services in front of Exchange Online.
2. We do not do any form of pre-authentication of services in front of our corporate, on-premises messaging deployments either.
3. 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.
4. We have come to learn that adding layers of security often adds little additional security, but certainly lots of complexity.
5. We have invested in getting our policies right and monitoring our systems.”

“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;”

The recent release of Windows Server 2012 R2 Preview brings with it the new Web Application Proxy role. Web Application Proxy is a new Remote Access role service in Windows Server 2012 R2 Preview that provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy pre-authenticates access to web applications using Active Directory Federation Services (AD FS), and also functions as an AD FS proxy. My esteemed colleague Marc Terblanche has put together a couple of great posts on the Kloud Solutions blog about the Web Application Proxy role, check them out here:

• Windows 2012 R2 Preview Web Application Proxy – Exchange 2013 Publishing Tests
• Publish Lync 2013 with 2012 R2 Preview Web Application Proxy

I also wanted to post an update on the Apache/mod_proxy solution I mentioned in my previous post. Free time (aka lab time) has become somewhat limited lately so I haven’t been able iron out all the issues with the solution yet, but I recently came across an open source project that looks very promising. The guys at Vulture seem to have created exactly what I was trying to do in a much more elegant way. They’ve put together a web application firewall using open source components like Apache and mod_security and have even added a configuration web gui to it. Vulture does pre-authentication using a number of authentication providers and also provides other features like load balancing. I have not tested it myself (yet!) but if this interests you, check it out here: http://www.vultureproject.org/ – The documentation is in French but seems to translate reasonably well..

Ross Smith IV announced the release of Exchange Server 2013 RTM Cumulative Update 2 (CU2) on the Exchange Team blog earlier today.

In addition to bug fixes, Exchange 2013 RTM CU2 introduces enhancements in the following areas:

• Per-server database support - increased from 50 to 100 databases
• OWA Redirection - adds single sign-on when FBA is used on source and target
• High Availability - introduces the new "DAG Management Service"
• Improvements to Managed Availability
• Cmdlet Help - introduces Update-ExchangeHelp cmdlet to update local Shell help
• OWA Search Improvements
• Malware Filter Rules - introduces the –MalwareFilterRule cmdlets

He also announced that the Exchange Product Group is in the final validation stages to support Windows Azure for Witness Server placement. There has been much talk about leveraging Windows Azure for things like Witness Servers lately, so this is quite an exciting announcement for many organizations.

Exchange 2013 CU2 does include schema changes so I highly recommend reading the upgrading/deploying section before attempting to implement it. The download is available here.

If you often use the Remote Connectivity Analyzer tool (https://www.testexchangeconnectivity.com/) you may have noticed the “Message Analyzer” tab that was added recently. I noticed it a while back but never gave it much thought until I have troubleshooting  a mail flow problem for a customer today so I thought I would write up this quick post about it.

SMTP message headers contain a lot of valuable information about origins of a message and how it eventually made it to the intended destination. The Message Analyzer displays SMTP message header information in a easy to read format.

To use the Message Analyzer, simply copy the SMTP message header from a message and paste it into the tool:

Once you click “Analyze headers” the header information will be displayed in a table

The Exchange Team recently released some great guidance on how to size Exchange 2013 deployments. I think this is a really comprehensive post and as expected, the guidance is in favour of multi-role deployments. There is no “calculator” spread sheet out yet, however we should see one released soon. Read the full post here

Following the release of Exchange 2010 SP3 in February, the Exchange Team have announced the release of Exchange Server 2013 Cumulative Update 1 (CU1). CU1 does include some new features, including *some* access Public Folder content through Outlook Web App but I think it is fair to say that legacy coexistence is the reason everyone has been waiting for CU1. CU1 is the minimum version of Exchange 2013 required for on-premises coexistence with supported legacy Exchange Server versions, but, before you steam ahead and install it I think it is important to understand all the caveats of coexistence so be sure to check out the Planning and Deployment documentation. Scott Schnoll put together a great post about the high availability changes in Exchange 2013 CU1 which is also worth reading.

The Exchange 2013 CU1 release notes are available here and you can download it here

Ever since Microsoft announced that Forefront Threat Management Gateway (TMG) 2010 will be discontinued, I have had many customers ask me “What should we use as a reverse proxy for Exchange?”. This question has sparked many heated debates among colleagues and customers alike. To be fair, this announcement may have come as a huge shock to many people, but I think deep down many of us expected it to happen sooner or later.. TMG was a great product and really became the de facto standard for reverse proxying Exchange (and Lync, etc) and thinking back to all the Exchange deployments I have been involved with over the years, it is fair to say that most of them made use of ISA/TMG as a reverse proxy in some way. It worked well, but sadly all good things come to an end.

So, lets get back to the question.. “What should we use as a reverse proxy for Exchange?” I’ve been thinking about this for a while and I don’t believe there is a magical silver bullet solution that will work for everyone and I urge my customers to think it through and make an informed decision. Do you even need a reverse proxy for Exchange? This is where things get heated.. but hear me out.. there are those who have been talking about the death of the DMZ for some time now. I remember attending a Tech-Ed session back in 2008 where Steve Riley talked about this and Deb Shinder has also blogged about this topic in the past. I’m not saying get rid of your firewall, but what I am saying is that perhaps you no longer need to use a reverse proxy to secure connections to your Exchange servers and this is something that should be thought about. My first response to the “What should we use as a reverse proxy for Exchange?” question is “Do you still need a reverse proxy?” and 99% of the time the answer I get back is “Yes, because it is insecure not to”. Perhaps it used to be, but is that statement still true? Every environment is different and every organisation has different needs and requirements. My intention with this post is to help you ask the right questions and make an informed decision.

One of the great things about being a consultant is that I get to work with many different types of customers and see many different types of environments and typically the decision to implement a reverse proxy is driven by one or both of the following factors:

1. Application Hardening - The concept of application hardening has been around for some time now and there is a lot of information floating around about it. The question we need to ask is: does Exchange (the CAS role in particular) need to be hardened? The reality is that times have changed and both Windows Server and Exchange have matured and are hardened by default. Exchange CAS was designed to be internet facing so there really is no need for a reverse proxy in order to secure it anymore. Sure, using a reverse proxy is useful if you wish to implement third party two factor authentication or have other very specific requirements, but will your Exchange implementation be less secure without one? probably not.
2. Security Policy - Security policy is much more complex and as you would expect, these policies come in many flavours! One thing most of them have in common is that they restrict traffic from passing through an entire zone or prevent services on the internal network from being accessed directly from the internet, i.e traffic cannot pass directly through the DMZ to the internal network, and must first terminate in the DMZ. In the past, the solution was to implement ISA/TMG as a reverse proxy in the DMZ. We already know that Exchange does not need any further hardening, so technically there is no need for this, but while technology matures relatively quickly security policies rarely keep up so it is fairly common to have this type of out-dated policy that dictates the use of a reverse proxy. Sometimes the remnants of this type of security policy are still visible long after the policy has evolved – I did some work with a customer recently who had a policy like this in the past and over time as their network grew they made decisions based on this policy that have resulted in a few technical constraints that are now causing some headaches. Typically, these security policies are similar to the diagram below:

There is something else to consider and that is performance. Often due to the mission critical nature of DMZ infrastructure and its various dependencies, this infrastructure is not upgraded or refreshed as regularly as other infrastructure so you end up building on infrastructure that was never intended to deal with the load that is now being placed on it. A classic example of this is an environment I saw a while back – this particular organisation was in the process of refreshing their messaging platform and had just made a significant investment in a highly available Exchange environment only to go and use the ageing 32-bit only ISA 2006 infrastructure in their DMZ as a reverse proxy because connections to Exchange needed to be “secured”.

So what’s answer then? Well.. I think it is important to first understand what your requirements are. Are you currently using TMG? why change? Mainstream support for TMG will continue into 2015 with extended support through 2020. Are you looking to implement a reverse proxy because you think it will make Exchange more secure? If so, perhaps you need to rethink your approach. Are you looking for a TMG replacement because your security policy dictates the use of a proxy server and you really have no choice in the matter? Here are three options:

1. F5 BIG-IP Access Policy Manager (APM)  - Many organisations have already invested in BIG-IP LTM devices to load balance Exchange. It makes sense to leverage this infrastructure, you’ll have the added benefit of infrastructure consolidation if you move the reverse proxy functionality to your BIG-IP devices. More info here
2. KEMP LoadMaster Edge Security Pack (ESP) - I have always been a big fan of the KEMP LoadMaster devices and KEMP is currently working on their Edge Security Pack which will help provide some TMG functionality and compliment their already excellent offering. These devices already provide excellent value for money and my understanding is that the ESP will be a free upgrade for most customers. ESP is not publically available yet but I think it is worth looking at. More info here
3. Apache HTTP Server with mod_proxy - No, your eyes are not deceiving you, it is possible to use apache as a reverse proxy. I am not making any claims about the supportability of the solution or saying that it is an enterprise ready option, and just because it is possible to do it does not mean you should. I have seen many attempts at this solution in the past so I am currently working on a post that will provide a guide on how to go about setting it all up as well as explain the limitations and pitfalls of the solution. I hope to post more about it soon.

I’m sure there are many other equally suitable solutions, but my intention was to mention some of the ones I have worked with or tested. Each of these also have different pricing and scalability options so they will appeal to a wide range of different organisations.