When will AEMS be upgraded to Exchange 2010?

That is a very good question, and somewhat in flux given current efforts to migrate ITS servers to the new data center. Tentatively, we are looking at sometime in 2011, depending upon when we can purchase the needed hardware.

How will this transition be done?

We’ve already taken the first steps by upgrading our environment to Exchange 2007 SP2, which applies the relevant AD Schema modifications which are required for Exchange 2010. An additional benefit of this update, is that it will enable the use of “online mailbox moves” when we migrate users from 2007 mailbox servers to 2010 mailbox servers.

Exchange cannot be upgraded “in-place” to 2010. What will be necessary for us to do will be to install new Exchange 2010 servers in parallel with our existing Exchange 2007 servers. We will then move user mailboxes over from the 2007 servers to the 2010 servers.  Due to the new “online mailbox move” feature, connectivity to the mailbox from Outlook will be maintained throughout the move until the very end of the move process, at which time connectivity will be interrupted for about 30 seconds while the connection is switched over to the new server location. (Outlook 2003 users will likely have to restart Outlook.)

That sounds all very well and good for Outlook users. What about other clients?

Unfortunately, online mailbox moves only work for Outlook users since it is a feature tied to the MAPI protocol. Anyone using an IMAP client, Entourage, Outlook:mac, or Snow Leopard’s Exchange-enabled applications will find their mailbox access interrupted for the duration of the move of their mailbox (just as it was for all users during the transition to Exchange 2007). Such clients will likely have to be restarted after the mailbox move is complete. The duration for any given mailbox move will, of course, depend upon the size of the mailbox and how busy the servers are at the time of the move.

Important note for Entourage users!

If you are using a version of Entourage prior to the Web Services Edition, you will need to upgrade to Entourage 2008 Web Services Edition (or to Outlook:mac 2011) prior to having your mailbox moved to Exchange 2010. The new version of Exchange drops support for WebDAV, the protocol used by older Entourage versions for Exchange connectivity, in favor of Exchange Web Services (EWS). Upgrading to the Web Services Edition is accomplished by applying a downloadable patch to an existing Entourage 2008 installation. The latest version of this patch , released just this week, also adds synchronization of Tasks, Notes, and Categories. Alternatively, upgrade to Outlook:mac 2011, which is available now from ITS’ Site Licensed disk share as part of the Office 2011 suite. Outlook:mac 2011, which also makes use of EWS for its Exchange connectivity (as opposed to the MAPI protocol used by the Windows version of Outlook), is essentially a from-the-ground-up rewrite of Entourage using the Cocoa API’s and incorporates substantial improvements over Entourage, most notably a change in the architecture of the local cache database to make it more Spotlight-friendly.

Important note for Snow Leopard users!

With the release of the Snow Leopard edition of Mac OS X, Apple added native Exchange connectivity (via EWS) to Mail, iCal, and Address Book. For the most part, this works fairly well. However, based upon reports from other institutions which have already made the jump to Exchange 2010, these applications exhibit some problematic behavior during the transition period.

Earlier, I mentioned that transitioning to Exchange 2010 involves setting up Exchange 2010 servers in parallel with the existing 2007 environment. What is supposed to happen with EWS connections (and all protocol connections, for that matter) is the following:

1. The client connects to the 2010 Client Access Server (CAS) and authenticates.
2. If the user’s mailbox is on a 2010 Mailbox (MBX) server, the 2010 CAS mediates the connection normally.
3. If the user’s mailbox is still on a 2007 MBX server, the 2010 CAS redirects the client (complete with authentication tokens) to the appropriate 2007 CAS, which then mediates communication between the client and mailbox.

Unfortunately, it seems that the Snow Leopard apps do not handle the redirection mentioned in step 3 properly. Other institutions have had to instruct the users of those applications to temporarily configure their software to use an alternative client configuration (pointing specifically to the legacy CAS infrastructure) until such time as the mailboxes are moved.  We will of course be testing to find ways to mitigate the impact of this flaw. Hopefully, by the time we are ready to roll out 2010, Apple will have issued an update to correct this issue.

This all sounds grand. But what are the benefits of upgrading to Exchange 2010?

• An improved high-availability model for reducing downtimes.
• An improved fine-grained security model based upon Role-Based Access Control (RBAC) , which will allow us to delegate some support functions to Help Desk staff and/or departmental Technical Support Contacts.
• An overhauled database schema, allowing for improved performance and better scalability as we grow.
• A vastly improved OWA experience. OWA, now called Outlook Web App, has many new features, including allowing users to perform their own searches of the message tracking log, support for sharing Calendars and viewing shared Calendars, external Calendar sharing, Conversation View, and cross-platform OWA Premium support in Firefox and Safari! (Mac and Linux users rejoice! Although not officially tested by Microsoft, Chrome works as well.)
• Support for MailTips when used with Outlook 2010.

Entourage users: please DO NOT create folders with leading or trailing spaces in their names!

When creating a folder with a leading or trailing space in the name, Entourage will quietly generate an error as follows:

Error

Could not synchronize record: <foldername> to Exchange server: <identity name>

Explanation

The folder save operation failed due to invalid property values.

Error: -19918

However, Entourage will then proceed to behave as if the folder creation actually worked, display the misnamed folder in the folder tree, and allowing messages to be dropped into it.  Looking at the same mailbox via Outlook, the misnamed folder never appears, and the “moved” messages remain where they originally are. (Verified with testing using Entourage 2008 Web Services Edition, version 13.0.4 (100208).)

I note that Outlook will strip leading or trailing whitespace from folder names when creating them, as does Apple’s Mail.app.

I’m not the first to notice this issue: http://blogs.technet.com/b/pawan/archive/2010/03/02/issue-with-synchronizing-folders-in-entourage-ews-which-are-created-with-trailing-or-ending-spaces.aspx

On a potentially related note, it seems that one of our users actually managed to create a folder with a trailing space on our Exchange 2007 SP1 system (I assume that this was done using an older, pre-EWS version of Entourage), which created a world of woes when trying to merge his restored mailbox contents from a Recovery Storage Group. I need to perform some more testing to verify that the trailing whitespace was the source of the problem with restore-mailbox, which might be tricky if I can’t figure out how to create a test folder with trailing whitespace in the name to begin with.  I’ll follow up on that later once I have had a chance to do some testing.

I’ve long been aware that Entourage does not know how to properly handle the granularity of control over free/busy information introduced by Exchange 2007, but I’ve now become aware of an even more serious bug on this front in Entourage 2008 Web Services Edition. It seems that anytime that version of Entourage is used to modify Calendar sharing permissions on an Exchange 2007 server (and presumably an Exchange 2010 server), the user or group to whom the permissions are being granted looses the ability to see the free/busy information for that Calendar, regardless of the permissions level granted.

Here are the steps that I have taken to replicate this issue in our environment.  We have Exchange  2007 SP1 Rollup 8. In the testing which I describe below, I am using Outlook 2007 and Entourage 2008 Web Services Edition, Version 13.0.03  (091002). Steps to reproduce the issue are as follows:

• – In Outlook, grant sharing permission to another user on your Calendar. For this example, we’ll grant the user “Free/Busy time, subject, location” permissions. Verify that on the permissions tab, with that user selected, in the Read section, the radio button  for “Free/Busy time, subject, location is checked. After clicking “Apply”, verify that the user can in fact see your free/busy. We have now set a baseline for expected functionality.
• – Now, in Entourage, check the sharing permissions on your Calendar. For the user to whom you have granted permissions, the permissions level will show as “None.”  Now let us use Entourage to modify the sharing permissions. Set it to “Reviewer” for example, and click “OK.”
• – At this point, the user to whom permissions have been granted will be unable to see your free/busy information. (This is true regardless of what permission  level is set in Entourage.)  Looking at the Calendar sharing permissions in Outlook, none of the Read permission items are checked.

This is a serious bug in Entourage, and the only way that I know of to repair the damage is to properly set the permission with an Outlook client.

UPDATE (Sept. 15): We received a note from Cornell indicating that they found that applying Service Pack 3 fixed this issue. Thanks for the heads-up. We are at SP2 RU4, and the problem still manifests at that patch level.