Previously Windows 8.1 and Windows Server 2012 R2 were released to the TechNet subscriber download centre.   Prior to Windows Server 2012 R2 being tested and validated by the Exchange Product Group, we had asked to pause deployments of 2012 R2 DCs into environments where Exchange was installed. 

Exchange 2013 Service Pack 1, Exchange 2010 SP3 RU5 and Exchange 2007 SP3 RU13 were all released today, the 25th of February 2014.   As announced back in November the Exchange team were working to test and validate Exchange against Windows Server 2012 DCs.   That work has been completed, and the support stance has been updated on TechNet. 

To prevent confusion for folks that may have read this post prior to today’s updated support stance it has been heavily edited to reflect the new information.  Probably not much point showing out-dated stuff, eh?

Walking The Supported Path

TechNet documents the Exchange Product Group’s supported OS for each version of Exchange.  Here are the links for your convenience:

There have been a couple of posts in the TechNet forums where people have run into some issues when they have either:

• Upgraded the OS in place to Windows Server 2012 R2
• Tried to install Exchange 2010  onto Windows Server 2012 R2

Unfortunately there is not much that can be done to help apart from digging out backups as they are not supported options.

I didn’t list Exchange 2003 as hopefully no one out there is going to be trying that with Server 2012 R2. **

Supported Operating System Platforms

The following tableidentifies the operating system platforms on which each version of Exchange can run. Supported platforms are identified by an X character.

You will note that Windows Server 2012 R2 is currently only listed as a supported OS platform for Exchange 2013 SP1.  In addition to this please also note that Windows Server 2012 R2 is listed as a supported Domain Controller for Exchange 2013 SP1, Exchange 2010 SP3 RU5 and Exchange 2007 SP3 RU13 or later builds of each. 

Supported Active Directory Environments

The following tableidentifies the Active Directory environments with which each version of Exchange can communicate. Supported environments are identified by an X character. An Active Directory server refers to both writable global catalog servers and to writable domain controllers. Read-only global catalog servers and read-only domain controllers aren't supported.

Previous update history to this post for full disclosure:

Update  3-10-2013: Added additional note about Domain Controller support

Update 12-11-2013: Added note to indicate TechNet has updated support stance to say Exchange 2013 support  for Windows Server 2012 R2 will be provided by future version of Exchange 2013.

Update 20-11-2013:  Additional details here.

Update 25-2-2014:  Re-wrote this post to reflect the current support stance

Cheers,

Rhoderick

** Well you never know I suppose….

>>>>

Via this blog we have discussed the fundamentals of Exchange Autodiscover, and also issues around the Set-AutodiscoverVirtualDirectory cmdlet. 

At this point the message should be out there with regards to how Outlook functions internally and externally to locate Autodiscover and the difference that having the workstation domain joined makes.   Lync on the other hand is a different beastie! 

Both the Outlook Client and the Lync client want to get to the Exchange Autodiscover endpoint, but they differ in how to get to Sesame Street. **

Same But Different

At one of my recent engagements the customer experienced a situation around Lync 2010 and Exchange 2010 integration.  Exchange was successfully upgraded to Exchange 2010, and OCS was still in use.  When piloting Lync 2010 and the Lync 2010 client they noted errors in the Lync client.  There were a couple of reasons for this.  The required configuration on the load balancer was not in place, and the device’s firmware was not at the required build level. 

When we investigated what Lync and Exchange Autodiscover were doing, we noted that Lync was not locating the Exchange Autodiscover endpoint.  Hmm.  That’s a  bit strange, innit? Outlook was running perfectly, and all the domain joined clients were always able to located Autodiscover by querying for the SCP.  The Lync client on the other hand does not leverage SCP when locating Exchange Autodiscover.

Dave Howe’s whitepaper Understanding and Troubleshooting Microsoft Exchange Server Integration discusses this in more detail and is a great read!  The one line that distils the important message is:

Unlike Outlook, which uses an SCP object to locate the Autodiscover URL, UC clients and devices will only use the DNS-based discovery method.

There is also a flow diagram in the whitepaper showing the DNS records used. 

Note that nowhere in Dave’s article does he change or view the properties of the Autodiscover virtual directory.  The same is also true in Prerequisites for Integrating Microsoft Lync Server 2013 and Microsoft Exchange Server 2013. 

There are some differences between Exchange 2007 and 2010 with regards to how the requests get serviced.  Exchange 2007 only does POX  (Plain Old Xml) whereas newer Exchange does SOAP (Simple Object Access Protocol) in addition.  Lync can leverage SOAP, Outlook kicks it old School with POX. 

Letting Lync Play Nicely With Exchange Autodiscover

The customer above had deployed Exchange, but had not created any internal DNS records for Autodiscover.domain.com.  Technically this was not needed for their Exchange + Outlook design, as they have an environment with HA load balancers and multiple CAS servers behind each load balancer.  Their Autodiscover namespace had been set as the load balancer FQDN.  As such the FQDN Autodoscover.domain.com was not on any of the Exchange CAS Certificates.  And as mentioned in the busting Autodiscover myth post on Set-AutodiscoverVirtualDirectory their Autodiscover URI was previously configured by running:

Set-ClientAccessServer  –AutoDiscoverServiceInternalUri “https://lb.contoso.com/Autodiscover/Autodiscover.xml”

In order to change this they:

1. Request and install new certificates that included the Autodiscover.domain.com namespace
2. Update the service bindings on Exchange to use the new certificate
3. Update the configuration on the load balancers
4. Create internal DNS entries for the Autodiscover.domain.com namespace
5. Test
6. Update build documentation
7. Update DR documentation

Cheers,

Rhoderick

** - That 8 foot tall yellow bird still freaks me out!!

>>>

RPC Client Access is the main conduit for Outlook clients communicating to Exchange 2010.  So when something happens to it, the impact can be classified as “not good”…..

While Exchange 2010 SP3 RU2 addresses issues with RPC Client Access that may be caused by RPC Client Access threads hanging on a mailbox server that is experiencing issues, there is an additional update that was recently released to resolve an issue with the RPC Client Access Service crashing when running on Windows 2008 R2 SP1. 

This update is released as hotfix 2836445 and updates one file:

File this one away just in case you run into it in the future!

Cheers,

Rhoderick