Ever since I first learned a few months ago that Exchange 2010 will not support Single Copy Clusters (a high-availability model which has served us quite well to date), I’ve been scheming to figure out ways to transition to 2010 in a way that impacts end-users as little as possible, a task made more difficult by the lack of information about upgrade paths which has come out of Microsoft to date. I had even come up with an elaborate transition model built around Standby Continuous Replication (SCR) which would have made the transition almost transparent to end-users, provided that Exchange 2010 supports in-place upgrades from 2007, or that an Exchange 2010 mailbox server can serve as an SCR target for Exchange 2007. Alas, a new webcast from Microsoft has dashed those hopes, as both of those options are explicitly excluded from officially supported upgrade paths.

The Exchange engineers really dropped the ball on this one. Allowing an Exchange 2010 mailbox server to be an SCR target for 2007 would make transitioning quite painless.  Alas, it is not meant to be. (Of course, I understand WHY they couldn’t do this.  Exchange 2010 marks the first time that the ESE database schema for mailbox storage has been changed substantially since the introduction of Exchange. Thus, the 2007 and 2010 mailbox stores are incompatible, so it would do no good to replicate a 2007 database to a 2010 server unless some sort of database format conversion could be done on the fly.)

The supported transition path involves building new Exchange 2010 servers and performing move-mailbox operations on each mailbox, which, fortunately for us, is an easily scripted operation with PowerShell. There is one bright side to this.  Exchange 2010 introduces the concept of “Online Move Mailbox.” In previous versions of Exchange, the move-mailbox operation rendered a mailbox unavailable for the duration of the move operation.  With this enhancement, the mailbox remains continuously available except for a brief interruption when access is handed off from the source server to the destination server.  This online move mailbox feature is supported for moves from Exchange 2007 SP2 (a forthcoming service pack) to Exchange 2010.

One nice feature of Exchange 2007 is the introduction of specific mailbox types, especially room resource mailboxes, which we create manually on AEMS at the request of departments outside of the EID system (since the associated Active Directory account is disabled for resource mailboxes).  Resource mailboxes can be configured to automatically accept meeting requests, and, if configured with the “AllowConflicts” parameter set to “$true”, can automatically accept conflicting appointments.  This can be handy for group out-of-office or vacation calendars.

Unfortunately, when a recurring item is submitted to such a calendar, specific instances which conflict with other items are declined, despite “AllowConflicts” being enabled.  According to Microsoft, this bug is by design. The only workaround is to create discrete one-time items, or to create a single event which spans multiple days.

With the combination of Outlook 2007 and Exchange 2007, several new services have been introduced which are designed to simplify the end-user experience, although there are “gotchas” to be aware of. These features are called AutoDiscover, AutoConfigure, and the Availability Service.  The latter two are built around the first.

AutoDiscover is an XML-based service used by the client to locate and connect to other web-based Exchange services, including AutoConfigure, Availability Service, and Exchange Web Services (a new API for programmatically accessing Exchange).  The client (which can be Outlook 2007, Windows Mobile, the upcoming Entourage EWS, or an EWS-based program or script) passes the user’s e-mail address and credentials to the AutoDiscover service as a SOAP query (after first checking to see if the desired information is available in Active Directory). If the credentials are valid, and depending upon the type of request, AutoDiscover will pass back a SOAP response with the requested information, such as what server the client should be configured to point to, the URL for downloading the Offline Address Book, the URL for Exchange Web Services, or the URL for the Availability Service.

AutoConfiguration is an Outlook 2007 feature which uses the AutoDiscover service to configure the Outlook profile (if the user chooses not to configure their profile manually).  There are several caveats to be aware of:

1. By default, AutoConfiguration will set the Outlook profile to cached mode, which we don’t generally recommend for our clients.  Cached mode and been known to cause major problems such as inconsistent views of shared calendars and mailbox data loss due to corruption of the OST.
2. The upcoming Entourage EWS (which is currently in beta) adds autoconfiguration functionality, but returns the name of a specific domain controller for the directory server (rather than the directory.austin.utexas.edu NetScaler alias).  This is problematic for off-campus users, as the DCs are not routed off-campus.
3. When attempting to perform an autoconfiguration, the client will parse the e-mail address provided by the user and use that to construct an address to query for the AutoDiscover server (assuming that it cannot pull this info from the Service Connection Point in Active Directory).  For example, for username@mydomain.com, the client will look for the AutoDiscover service at autodiscover.mydomain.com. However, suppose that the mydomain.com Exchange server is hosting another SMTP address space, such as for an acquired company.  In this example, the user’s e-mail address is username@otherdomain.com.  The client will look for the AutoDiscover info at autodiscover.otherdomain.com.  For this scenario, either the user should  specify a “mydomain.com” address, or the network admins should add a CNAME entry to DNS pointing autodiscover.otherdomain.com to autodiscover.mydomain.com.

The Availability Service is a SOAP/XML mechanism by which Outlook 2007 retrieves free/busy information from the Exchange server.  The client uses the AutoDiscover service to locate the SOAP URL for the Availability Service, then uses SOAP queries to pull the relevant free/busy information.  This is all well and good except for one fundamental design flaw in Outlook 2007.  For authenticating against the Availability Service, Outlook uses the credentials that were used to login to the workstation, not those provided for mailbox access.  This is problematic for client systems which are not joined to the domain.  The only workaround is to join the client to the domain.  For off-site usage, this generally requires using a VPN service to join the system to the domain and to authenticate, even though the Availability Service itself simply uses web protocols.