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…

At least once a week, a Remedy ticket pops into my queue from a user frantically requesting a restore of missing messages from their mailbox.  Sometimes this is warrented, as both Entourage and Outlook operating in cached mode are somewhat notorious for eating messages. However, a restore is usually overkill, as the messages are usually not as “missing” as the end-user might believe at first blush.  This is an important point, as restoring the contents of an individual mailbox from backup is a non-trivial, time-consuming task.

So how is one to know if a restore is actually warranted?  There are several steps that an Exchange end-user can take to on their end (or that their desktop support personnel could walk them through) to try to recover their missing e-mail before ever having to get their friendly, neighborhood Exchange administrator involved. Here is a handy-dandy checklist which might help.

Deleted Item Recovery

When a message is deleted in Exchange, it does not go away immediately.  First, the message goes to the “Deleted Items” folder, where it remains until such time as that folder is emptied. (Client software can be configured to automatically empty Deleted Items upon logging out.)  If the missing items are still there, great. Just drag them back where they belong. But if the Deleted Items folder has been emptied, all is not lost. When the Deleted Items folder is emptied, the messages within it actually get shuffled into another, hidden folder referred to as a dumpster. Items are retained in the dumpster for a period specified by the Exchange administrators on a database by database basis. (In the case of AEMS, deleted item retention is set for 14 days.)

During this retention window, items can be retrieved from the dumpster using the “Recover Deleted Items” feature found in Outlook and OWA Premium. (Alas, this leaves Mac and Linux users out in the cold until Exchange 2010 is deployed with its lovely cross-browser support for OWA Premium.  Until then, seek a coworker’s PC, or use a Windows Terminal Server or a VM. I know, it isn’t fair, but relief is at least in sight.) In Outlook, highlight the Deleted Items folder, then go to the Tools menu and select “Recover Deleted Items….”  In OWA Premium, click Options, then click “Deleted Items.”

It is important to note that EACH FOLDER in an Exchange mailbox has its own hidden dumpster folder.  The procedure above only works for recovering items that were deleted by way of the Deleted Items folder.  In cases where the user has shift-deleted a message, that message will have bypassed the Deleted Items folder and would be sent directly to the dumpster associated with whatever folder the message was in.  (This also holds true for messages deleted via IMAP or POP, as those protocols generally bypass the Deleted Items folder.)  In that case, it is necessary to use Outlook to access the dumpster for the appropriate folder by selecting the folder in question, then choosing “Recover Deleted Items….” from the Tools menu.  (OWA Premium only exposes the dumpster associated with the Deleted Items folder.)

Make Sure the Messages Are Actually Missing

If the preceding step doesn’t do the trick, it doesn’t hurt to actually verify that messages are really missing.  They may merely be misplaced by a long-forgotten rule or a sloppy click-drag.  The following steps are designed to check for these issues.

Try Different Clients

Try viewing the mailbox multiple ways to rule out a problem with the client.  Especially try using Outlook Web Access (OWA), as this will present the most authoritative look into the mailbox, free from problems introduced by client software.

• If the messages show up in OWA, but do not show up with, for example, Outlook or Entourage, then the messages are actually in the mailbox, but the client software is not displaying them properly, perhaps due to a corrupted local cache. Rebuild your client profile (preferably not in cached mode in the case of Outlook), and all should be right in the world.  Another reason that Outlook might not show the mailbox as it really is might be that you’ve been tinkering with custom views (View -> Current View), which might restrict what messages get shown.
• If messages do not show up in OWA, but do show up on the client, the messages are not actually in the mailbox.  The most common cause for this is that the Outlook profile has been accidentally configured to deliver the mail to a local PST file rather than to a mailbox.  In this case, you are in luck. Simply fix this profile setting, then drag your mail from the PST back up to the server.

Search, Search, Search….

You would be suprised how often it turns out that a user has accidentally dragged their messages off into a different folder without realizing it.  If you know the subject of one of your missing messages, nose around for it using the search feature of your client.  Search the entire mailbox, not just where you think the messages should be.  If you having any PST files (personal folders), don’t forget to check there.

Check Rules and Auto-Archiving

Sometimes a mailbox rule will intercept and shuffle around messages in ways that were not intended. Double check your rules for one which might be doing something unanticipated.  Auto-archiving can also sneak up on you.  If all of your messages from prior to a certain date have suddenly gone AWOL, check to see if Auto-Archive might have tucked them away into an archive file.

Check PST Files

Several ways in which messages might get shoved into PST files have already been mentioned.  Leave no stone unturned.  See if your wayward messages might be lurking locally.  Remember that PST files are local to your specific computer. If you use Outlook on multiple computers, you’ll need to check for PST files on all of them. (And, for the record, Microsoft does not officially support accessing PSTs via a network share. That is bad, bad, bad.)

Okay, Maybe DO You Need a Restore

If you’ve worked your way through all of these scenarios and are still unable to find your missing e-mail, then perhaps a restore is in order.  When you submit your restore request, be sure to provide your best estimate of a date and approximate time when the missing items were actually known to be in your mailbox.  Your Exchange admins will need that info in order to determine from which backup the restore needs to be taken. The dates that you received the messages don’t help here (“All of my mail older than six months is gone!”).  We need to know when the messages were there.  Also keep in mind that backups are generally only kept for a finite amount of time.  They take up storage space.  For AEMS, backups are only retained for two weeks.  If you come to us with a restore request a month after the messages went missing, we can’t help you.