Monthly Archives: September 2009

Setting Delegates on Mailboxes That Are Not Your Own

Posted on by
1

(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 →

Exchange 2010 Educational Resources

Posted on by
Reply

In addition to the webcasts I’ve mentioned previously, I’ve learned of some further education resources for getting a leg up on Exchange 2010 (courtesy of the September “MCP Flash” newsletter):

I’ve just about finished going through the last of the webcasts (finally). Now I have more to dig into.

When will we be moving our environment to Exchange 2010? We still don’t know, but I would like to shoot for Summer of 2010.  There are a lot of dependencies, such as storage and server purchases (our CX500 is only supportable for another year, and Exchange 2007 Database Availability Groups will require more storage capacity than our current Single Copy Cluster model), and completion of our new data center (~Summer 2010 maybe, possibly, fingers crossed?). Also, since Exchange 2010 makes Client Access Servers (the front-ends) the endpoints for RPC/MAPI connectivity, we’ll need to figure out a way of implementing high availability and load balancing for this traffic, something which our current load balancing appliances aren’t able to do.

Moving to Exchange 2010 will actually help us shift our Exchange services to the new data center with minimal service interruption, since DAG’s can span different subnets and sites. This is a good thing, as a forklift move of our existing cluster and its accompanying storage infrastructure would involve an outage of several days at the least.

I know that we have users chomping at the bit for Exchange 2010, and so am I. Cross-browser OWA Premium is a nice enticement (especially for our Mac clients), and that is only the tip of the iceberg. But I’ll save enumerating the pros and cons of moving to Ex2010 for another day….

iPhone OS 3.1, Device Encryption, and Exchange

Posted on by
Reply

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…