Well it’s a year from today until a raft of products reach the end of their extended support window.   As they say in the boy scouts, better be prepared!

Please make sure that the 8th of April 2014 is in your calendar.

Outlook 2003 will transition out of extended support on 8th of April 2014

Exchange Server 2003 will transition out of extended support on 8th of April 2014

Windows XP will transition out of extended support on 8th of April 2014

Exchange 2010 SP2 will transition out of support on 8th April 2014

And as non Exchange specific item, please also note Windows 2003:

Windows Server 2003 will transition out of extended support on 14th of July 2015

The Lifecycle site’s FAQ has more information and details on support options if you are not able to complete your migration prior to the end of support dates.

Make sure that you are able to migrate to a supported product prior to the support expiration date.  Security updates will not be provided for products that are not supported.

Cheers,

Rhoderick

After a small delay the Exchange team have announced the eagerly awaited release of Exchange 2013 Cumulative Update 1!   Knowledge base article 2816900 contains a description of CU1.  This update will allow on premise installations to co-exist with Exchange 2007 and Exchange 2010.

CU1 marks a change in how updates are going to be released and supported by the Exchange team, and this is detailed in a previous post.

As always check the Exchange 2013 system requirements to ensure that all support aspects have been met.  Exchange 2013 CU1 will support coexistence with Exchange 2007 SP3 RU10 and Exchange 2010 SP3 servers in the same Exchange organisation.  Just as before you cannot re-introduce a down level Exchange role once the last one has been removed.  For example if you want to maintain the capability to install additional Exchange 2007 servers ensure that you preserve at least one machine that has all the roles.  This will allow you to add more Exchange 2007 servers in at a later date.  The same also applies for Exchange 2010, once that role has been removed you cannot add additional servers back into the Exchange org.

Exchange 2013 RTM’ed at build  15.00.0516.032  and CU1 takes this build number to 15.0.620.29 

CU Is the New SP (well almost)

You can to start thinking of a CU like a service pack in previous versions of Exchange, though it is not 100% the same.  There are several good reasons for this:

• A CU can update a previous install
• A CU is a complete build of Exchange and CU1 can be used to install  a server – no need to install RTM bits and then have to upgrade them
• You cannot uninstall a CU.  Removing the CU will uninstall Exchange 2013 from that server
• CU may have Active Directory schema changes
• CU may make additional Active Directory changes

Some Items For Consideration

• Exchange 2013 sizing guidance is not yet finalised
• CU1 requires AD and Schema changes, plan accordingly
• Read the release notes to understand the impact on OAB downloads.  Unexpected full OAB downloads in a large environment are not a good thing….
• Cannot uninstall a single role from a server, uninstalling a single role will remove both CAS and Mailbox.  This is a change from previous versions.
• Mailbox sizes will be tracked more accurately and thus appear to be larger.  Make sure you understand what growth ratio is applicable in your environment based off moving pilot users. 
• Exchange 2013 Public Folders can be accessed through Exchange 2013 OWA
• Do not install this update (or any other for that matter) until you thoroughly test it in a lab
• Do not install this update until you ensure that all 3rd party vendors have certified their product against it.  Hearing the words “Not Supported, sorry but you are on your own” is guaranteed to ruin your day…….

And for many customers who had issues with managers of Distribution Groups after moving to Exchange 2010 it is great to see that Group on Group action is back!!!  Groups in Exchange 2013 can now manage groups!

Note that Exchange 2013 does NOT support

• Outlook 2003
• Exchange 2003 co-existence in the same forest
• Exchange 2007 SP3 RU9 or lower versions of Exchange
• Exchange 2010 SP2.  Exchange 2010 SP3 is required for coexistence with Exchange 2010
• Outdated Outlook 2007 clients (Outlook 2007 SP3 with November 2012 Cumulative Update is required)
• Outdated Outlook 2010 clients (Outlook 2010 SP1 with November 2012 Cumulative Update is required)

Additional Resources

What's Discontinued in Exchange 2013

Exchange 2013 CU1 Release Notes

Exchange 2013 Release Announcement – especially the comments!

Exchange 2013 High Availability Changes in CU1

Keep a weather eye on the Exchange 2013 forums to see what feedback the community has!

Cheers,

Rhoderick

This is one of those long overdue posts (and yes there are certainly many more where it came from in my drafts folder) regarding some of the incorrect instructions about setting up Autodiscover which can be found on the Internet.

What am I wibbling about?  Well repeatedly over the last 5 years or so since Exchange 2007 shipped, multiple sources have claimed that one *MUST* configure the InternalURL and ExternalURL on all of your Autodiscover Virtual Directories.  It does not help that TechNet also says the same thing for Exchange 2007 & 2010.

Setting the InternalURL and ExternalURL on the Autodiscover Virtual Directory is not required, and has no effect on your configuration.  You can knock yourself out and change it if it makes you feel good, but it's pretty pointless!

Let’s look to see what Autodiscover is doing and why we do not have to set InternalURL or ExternalURL values on the Autodiscover Virtual Directory.

Autodiscover – Bring The Action!

The below screenshot shows a default Exchange 2010 installation.  Note that the InternalURL and ExternalURL parameters are not filled in by default for any of the Autodiscover virtual directories. 

So let us check that Autodiscover is actually working, and we will use the Test-OutlookWebServices cmdlet.  This example retrieves the information for the Administrator account (yes kids, don’t do this at home ) and as you can see the relevant information is found and rendered onto the screen.

So that is good, and the InternalURLs are not entered onto the Autodiscover Virtual Directories.  These values are obtained by directly querying Active Directory.  What about machines that cannot query AD directly to locate the Autodiscover endpoint?

Machines that are not domain joined or are outside of the corporate network cannot get to AD to issue any queries.  For such scenarios DNS name resolution to well known names is the only way to locate the Autodiscover endpoint.  As covered on more detail here the flow looks like this:

With this update installed the SRV query is added:

• https://<smtpdomain>/Autodiscover/Autodiscover.xml

• https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

• http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

• SRV record query for _autodiscover._tcp.<smtpdomain>

Sooooooooooooooooooooooooo

If Autodiscover is working, clients are getting the right data and we do not have the URLs filled in on the Autodiscover Virtual Directories then what gives?  How is this possible?

As mentioned in this post on Autodiscover, domain joined machines that are on the internal network locate the Autodiscover endpoint by directly querying AD.  They look for Service Connection Point (SCP) objects that have a well known GUID and AD returns a list to the Outlook client.  Outlook will get either an in-site list or out of site list of SCP endpoints.  It will not get both.  The SCP contains the URL that the internal domain joined Outlook client will connect to using HTTPS.  This and the AD Site coverage can be seen below.

EDIT 3-4-2013:  Please note that I am *NOT* advocating that the AutoDiscoverServiceInternalUri is left at the default.  It is here for explanation purposes, and to get into why it should be pointed to a load balancer and what issues that causes with certificates means I have to finish another one of those draft posts……

Please see the comments at the bottom of the post for full details.  Thanks for the feedback!!

We can tell how Outlook located the Autodiscover endpoint by running a Test E-Mail AutoConfiguration, and looking at the Log tab.  Note that the URL HTTP://Exch-1.tailspintoys.com/Autodiscover/Autodiscover.xml was located by SCP.

The SCP object can be found in AD at the following path:

CN=exchangeserver,CN=Autodiscover,CN=Protocols,CN=exchangeserver,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=org name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com

On the SCP object there are a couple of values that interest us.  Firstly the attribute called serviceBindingInformation is where the  AutoDiscoverServiceInternalUri data is stored.  Secondly the attribute called keywords holds the AutodiscoverSitescope value.

For external domain joined machines, or those in a workgroup they both have no method to directly query AD for the SCP so they will only use DNS to locate the Autodiscover endpoint. Again this is mentioned in the previous Autodiscover post.

The Big Reveal

(well almost)

So as you can see everything is working fine without setting the InternalURL or ExternalURL on the Autodiscover Virtual Directory.  Now that we have established, and proved by testing, that it is not needed let’s answer the burning question about why it’s actually there.

The reason for this is pretty simple.  In the schema that defines Exchange virtual directory objects the InternalURL and ExternalURL are mandatory.  So every object of class Exchange Virtual directory must have these attributes.  Thus they are present on the Autodiscover virtual directory as they are inherited.  Exchange does not use them on the Autodiscover Virtual Directory, but they are heavily used to configure proxy and redirection for the other Virtual Directories – OWA for example.

If you look at the Exchange 2013 Set-AutodiscoverVirtualDirectory cmdlet documentation on TechNet, you will note that the InternalURL and ExternalURL attributes are not present.

Cheers,

Rhoderick