Exchange 2010 RTM bits have been made available for download. Weee!

Also, the Exchange 2010 Mailbox Server Role Requirements Calculator is out and I’m reading through the documentation on it now. (Now for a comparable tool for scaling CAS and HUB deployments and we’ll be all set.)

But wait, there is more. The Exchange Server 2010 Deployment Assistant has also been released. This is basically a wizard which asks questions about your environment, and creates deployment checklists. Very helpful, far more so than trying to wade through the mountains of TechNet docs to create such checklists (which I remember vividly doing for our transition to Exchange 2007). On the downside, the current release is only for transitions from Exchange 2003 to 2010. A version which includes transitioning from 2007 is slated for release in early 2010.

Of more immediate interest to the UT community, after I (along with our storage guru, Alex Barth) had spent most of last week cobbling together a preliminary plan for transitioning AEMS to Exchange 2010, we met with a Dell consultant for a whiteboard session to go over options for such a transition. Although there was not much depth to the session, the consultant did bring to our attention some ideas we had not really considered, so now we have more food for thought and testing to perform. My plan may very well undergo significant rewrites, but that’s okay. Actual deployment is a long way off, which gives us ample time to refine our plan so that, hopefully, it will go off with a minimum of problems.

With the introduction of Exchange 2007, Microsoft introduced a new model for making free/busy information available to clients. While older, down-level clients (Outlook 2003 and older) still access free/busy by pulling it from a system Public Folder, newer clients such as Outlook 2007 retrieve free/busy information by making use of the SOAP-based Availability Service. This works quite well for most situations, thus paving the way for the eventual deprecation on Public Folders, but their are certain situations where this model is somewhat…lacking. The most common scenario where the limitations of this approach are made manifest is the case where the Outlook 2007 client is running on a workstation which is not bound to the Active Directory domain where Exchange is hosted. Unfortunately, this is a common situation for many departments in our environment.

Continue reading →

(This posting is based upon a message I recently sent to a customer, and is essentially an expanded version of this posting.)

From time to time, it is necessary to grant certain users “Full Access” permissions to log into mailboxes that are not their own in order to allow those individuals the ability to set up delegates and/or sharing permissions, especially in the case of Exchange 2007 resource mailboxes, since the underlying AD accounts for such mailboxes are disabled by default.  However, over the years, there have been difficulties with this. Continue reading →

There has been a great deal of discussion (and confusion) over the last few days regarding a bug exposed by the recently-released iPhone 3.1 software regarding encryption and Exchange connectivity from iPhone and iPhone 3G (but does not impact the iPhone 3GS).

First, the good news: this does not impact AEMS users, since we do not have the relevant ActiveSync policy setting enabled.

So what is the fuss about?  Well, there is a setting in Exchange ActiveSync mailbox policies that allows the Exchange administrators to require that any device connecting to their Exchange environment via ActiveSync have device encryption turned on. (This does not refer to encryption of the connection between the device and the server, but rather encryption of the data sitting on the device. Transport encryption is handled by HTTPS.)  Neither the original generation iPhone nor the iPhone 3G have the necessary hardware support for device-level encryption. This feature was not introduced to the iPhone platform until the 3GS was brought to market.

Now stay with me. This is were it gets complicated.  Although the first two generations of iPhones do not support device encryption, prior to the iPhone OS 3.1 release, if the Exchange server was saying “Hey, we require device encryption,” these older iPhones would report back (with fingers crossed behind their backs like truent children) “No problem. I’m encrypted.”  In other words, the iPhone would spoof the relevant flag in its ActiveSync conversation to convince the server that device encryption was turned on.

With the release of iPhone 3.1, this behavior changed. Now when the server tells these older devices that device encryption is required, they no longer fib, and the iPhone user receives an error which says:

Policy Requirement
The account “_______________” requires encryption which is not supported on this iPhone.

In other words, this isn’t really a bug, but rather the software on the iPhone finally coming clean in its negotiations with the server about its capabilities.

So, what’s the solution for those encountering this error?

1. Get an iPhone 3GS, which DOES support device-level encryption, or
2. Cajole the Exchange administrators into turning off the device encryption requirement.

The first solution is annoying and costs money. The second may not be viable depending upon the security requirements of the environment in question.

To reiterate, this is not an issue for the Austin Exchange Messaging Service, since our ActiveSync policy does not currently require device encryption, so rest easy…