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.

Looks like Apple finally released an update to fit the exchange calendar bug

 

Update: iOS 6.1.2 resolves this problem

I have see a lot of reports lately about the Apple iOS 6.1 bug effecting organisations using Exchange 2010. The problem appears to occur when a user using a Apple device (iPad, iPhone, etc) with iOS 6.1 responds to or edits a single instance of a recurring calendar event, this causes excessive log growth and a significant increase in memory and CPU resource consumption in turn causing server performance to be affected. Both Microsoft and Apple have released support articles for this bug, but at the time of writing it has not been fixed.

If you do currently have a large iOS device fleet, I would suggest advising your users against upgrading their devices until this is resolved. If you are already experiencing resource problems on your Exchange servers, I strongly suggest using either a custom throttling policy for iOS 6.1 users or blocking iOS 6.1 users completely. For more information on these workarounds, see the following Microsoft support article.

A few moments ago the Microsoft Exchange Team announced the availability of Exchange 2010 SP3. I can’t remember any other service pack that has been as eagerly anticipated as this one, mostly because SP3 will allow coexistence with Exchange 2013 which was released late last year. Unfortunately, it appears that customers wanting to introduce Exchange Server 2013 into their existing Exchange 2010 environment will have to wait just a little longer for the release of Exchange 2013 CU1, or at least that is how I interpret the following release note on the Exchange Team Blog:

NOTE: Exchange 2010 SP3 allows Exchange 2010 servers to coexist with Exchange 2013 CU1, which is also scheduled to be released in Q1 2013. Customers can test and validate this update in a representative lab environment prior to rolling out in their production environments as an important coexistence preparatory step before introducing Exchange Server 2013 CU1.

This service pack also resolves numerous issues, a list of these can be found here.

To download Exchange 2010 SP3, click here.

In case you missed it, the evolution of hardware has caused an architectural change in Exchange 2013.. gone are the 5 Exchange server roles that we have all come to know and love since Exchange 2007. In Exchange 2013 things are a lot more simple with only two server roles, namely, the Client Access server role and the Mailbox server role. Don’t let the familiar names fool you though, there is nothing familiar about these roles. In Exchange Server 2013 there are two basic building blocks – the Client Access array and the Database Availability Group (DAG). Each provides a unit of high availability and fault tolerance that are decoupled from one another. Client Access servers make up the CAS array, while Mailbox servers comprise the DAG.

Ross Smith did a great job (obviously!) of introducing the new Exchange 2013 role architecture during the technical keynote at MEC 2012 last year.. if you have not already seen it, I highly recommend you watch it here. He also recently publish the following post of the Exchange team blog that covers the same topic.

As we are all aware, the next wave of Office 365 is currently in preview and will be available soon. One of the expected (and long awaited) new features is the ability to administer Lync Online via PowerShell, this is something that is lacking in the current release. I was recently working with a customer who are preparing for to transition several thousand users to Lync Online and this got me curious about remote PowerShell and Lync Online 2013. Since there is no documentation available yet for the upcoming release, I thought I would share my initial findings.

Before I go any further I should mention that at the time of writing this I am testing with a Office 365 Preview tenant and as with all things still in development, it is possible (likely even) the the final release will behave differently. I also want the mention that remote PowerShell does not work with Lync Online on an Office 365 Preview tenant (see details below) so I am sharing this information purely for those who might be interested in how it may or could work in future – I will of course update this post once the next wave of Office 365 has been released.

My discovery came after I installed the Lync 2013 administrative tools on my laptop, I was browsing around the modules folder when I noticed it had installed a module called “LyncOnlineConnector” which is not imported by default.

 

 

So as any curious geek would, I thought I would play around a little.. I imported the module and took a look at the cmdlets available.

 

 

Once imported, the “LyncOnlineConnector” module contains a “New-CsOnlineSession” cmdlet which according to the help file is used to set up a remote session to Lync Online.

 

 

If you attempt to run the cmdlet, you receive the following error: "Remote Windows PowerShell session creation is restricted by tenant Windows PowerShell policy". This leads me to believe that remote PowerShell is currently restricted on Office 365 Preview tenants.

Ever wondered what version of Exchange your tenant is provisioned on? Michael Van Horenbeeck has written quick post on how to determine this. I think this will be really handy in the near future so I wanted to share it.

You can check the version by issuing the following cmd via powershell:

Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization

Michael has some great information in his post that can be found here so be sure to check it out.