The case of the missing Free/Busy public folder pt.2

In an earlier blog, I described the situation where a customer had improperly decommissioned Exchange 2003 Administrative Groups and ended up with invalid, orphaned legacyExchangeDN values causing all sorts of issues, most Public Folder / Free Busy related. Read more on this story here.

In the blog, I had two options on how to proceed:

  1. Edit the legacyExchangeDN attribute of the users affected;
  2. Recreate the Free/Busy public folder.

In the first blog, I described how to fix the situation using the 2nd option. Here’s how to solve this if you have no Exchange 2003 server left and want to go with the other option.

To fix this situation by changing the legacyExchangeDN values, you need to perform the following steps:

  1. Identify all mailboxes containing improper legacyExchangeDN values;
  2. For all those mailboxes, add the current legacyExchangeDN value as an x500 address;
  3. Fix the current legacyExchangeDN.

Note that by adding the invalid legacyExchangeDN value as an X500 address, we make sure (responding to) old e-mail messages or nickname entries can resolve properly.

You could use tools like ADModify to bulk edit those values. However, you also achieve the same result using a little PowerShell (surprise!), as shown in the following script:

Note: Use the script at your own risk. I cannot accept any responsibility for consequences when using this in your production environment. Before using it, prepare it in a lab environment first: test, test, test! Also, this script fixes invalid legacyExchangeDN values; it does not fix any related invalid settings, like delegates; that might be something for a next version when there’s demand for it.

$oldDN="/o=ADATUM/ou=First Administrative Group"
$newDN="/o=CONTOSO/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients"
$mbx= get-mailbox -Filter "LegacyExchangeDN -like '$($oldDN)/*'"
$mbx | ForEach {
    $x5= "x500:"+ $_.legacyExchangeDN
    Set-Mailbox $_.Identity -EmailAddresses @{Add=$x5}
    $User = [ADSI]("LDAP://"+$_.distinguishedName)
    $newDN= $newDN+ “/cn=”+ $_.Name
    $User.Put("legacyExchangeDN", $newDN)
    $User.SetInfo()
}

To use the script, replace the $oldDN value with your old, invalid legacyExchangeDN value (as reported in the Event Log entries with Event ID 14031). Set $newDN to your new legacyExchangeDN value; the default value of would be in the format “/o=<Organisation Name>/ou=<Administrative Group, i.e. Exchange Administrative Group (FYDIBOHF23SPDLT)>/cn=Recipients/cn=<Name>”.

If you have any questions, drop them in the comments below.

For all the PowerShell purists: Sometimes I prefer readability over trying to fit everything one 1 line. After all, this isn’t an Obfuscated Code Contest 🙂

The case of the missing Free/Busy public folder

A customer who recently migrated to Exchange 2010 and was still in the co-existence setup with Exchange 2003, reported lots of users experiencing issues with regards to Free/Busy information. Symptoms were inaccurate or missing Free/Busy information, which especially gets annoying when scheduling appointments.

It turned out these users were using Outlook 2003; users on Outlook 2007 or later experienced no issues. As you probably know, Outlook 2003 still utilizes public folders to publish users’ Free/Busy information. This information is consulted by Outlook 2003 when scheduling appointments; Outlook 2007 or later uses Exchange Web Services for this purpose.

A quick look in the Eventlog revealed lots of 14031 errors were generated by the FreeBusy Assistant:

Err14031

This told us Exchange was unable to store Free/Busy information in a public folder, in this case /o=EUROPE/ou=First Administrative Group. A quick look at the Public Folder Management Console in Exchange 2010 showed that the folder didn’t exist. Since the Free/Busy public folder to be used by an Outlook 2003 user is determined by the legacyExchangeDN attribute, this was the cause of the issue.

The reason for the folder’s absence was unknown so one can only speculate. My best guess is improper decommissioning of the organization and administrative group originally hosting those users, identified by that “orphaned” legacyExchangeDN.

With the Free/Busy public folder missing and the original Exchange infrastructure gone, there are two alternatives to resolving this issue, apart from upgrading clients to a recent version of Outlook of course:

  1. Edit the legacyExchangeDN attribute of the users affected;
  2. Recreate the Free/Busy public folder.

The 1st option has consequences for the users, like being able to reply to earlier e-mail by co-workers. This can be resolved by adding the current legacyExchangeDN as an X500 address to the current set of e-mail addresses, but that also makes things a bit messy.

The 2nd option is to recreate the Free/Busy public folder; Here’s how to proceed:

  1. First, using the Exchange System Manager (luckily, Exchange 2003 was still present), create an Administrative Group, e.g. First Administrative Group
  2. Then, using ADSIedit.msc, navigate to CN=<Administrative Group>,CN=Administrative Groups,CN=<Organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>
  3. Right-click the Administrative Group, e.g. First Administrative Group, and click Properties. There, edit the legacyExhangeDN attribute. Set it to match the missing Free/Busy public folder, e.g. /o=EUROPE/ou=First Administrative Group
  4. Next, edit the siteFolderServer attribute. Set it to match the distinguishedName of a a public folder database. Note that you can pick the Exchange 2003 as well as Exchange 2010 Public Folder database here. In this example, I picked the Exhange 2003 public folder database, hence the storage group (SG1):

siteFolderServer

Now we need to wait for the store to recreate the Free/Busy public folder during its maintenance cycle, which may take up to 24h. If you’re in a hurry, and the situation allows you because of the service interruption, you can also restart the Information Store. When the Information Store has created the Free/Busy public folder, event 3047 is logged by the MSExchangeIS Public Store:

Recreate_FB_PF

To verify this, startup the Public Folder Management Console or any other Public Folder management tool, and you’ll see the newly created folder:

PFMC_Appear

After a while you’ll notice Outlook 2003 users are now storing their Free/Busy information in this public folder and Free/Busy will work again for these users. You can verify clients are storing Free/Busy information using EMS, ExFolders or MFCMAPI, e.g.:


Finally, don’t forget to create replicas of this new Free/Busy public folder when appropriate.

Exchange 2010 & Outlook 2003 Notifications

Update (13 apr 2011): Rollup 3 for Exchange 2010 SP1 contains UDP support. To enable it, apply RU3 and set HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem\EnablePushNotifications to 1 (REG_DWORD). More information in support article kb2009942.

New e-mail notifications from Exchange to Outlook, we receive them all the time. Most of us never look at the technique, because in most cases this works so there’s no need. But what if it doesn’t or you are experiencing delays? With Exchange 2010 this situation is more likely to occur than with earlier versions of Exchange, because many people are still using Outlook 2003 or earlier clients.  To understand why this happens, you need to understand how these notifications work (or should I say worked).

Note: To improve readability, you should read “Outlook 2003 or earlier versions in online mode” when it reads “Outlook 2003” from here on, unless states otherwise.

When Outlook 2003 connects to Exchange, it tries to register itself to receive notifications. If registration is successful, Outlook 2003 tells Exchange on what port it expects (UDP) packages to arrive, and it by default this is in the port range 1024-65535. When sending notifications, the Exchange server will also open a dynamic port in this range and connect to the registered client port. After receiving the notification, Outlook 2003 will retrieve the message, will display it in the appropriate folder, make a sound, show a systray icon, change your cursor, etc. When the registration for new mail notifications fails, Outlook 2003 will use a polling mechanism the check for changes.

Now, with Exchange 2010 this behavior has changed because Exchange 2010 does not send these kind of notifications to Outlook 2003 (i.e. UDP notifications were removed). Therefor, Outlook 2003 will revert to polling, which by default is set to 1 minute. This means in worst case users will be notified of new e-mail after approximately 1 minute, where (sort of) real-time feedback is expected. To make things worse in terms of user experience, this also means delays in visible feedback on any folder updates, e.g. e-mail seems to stay in outbox, deleted items not being deleted, moved items not being moved, etc.

The related knowledge base article (kb2009942) mentions two solutions. One solution is a mere pretext and explains increasing the polling frequency. To do so, it requires applying Exchange 2010 Rollup 1 on the CAS server and configuring the following registry key on that CAS server:

HKLM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem\Maximum Polling Freqeuency (DWORD, range 5000-120000)

The reason for performing this step on the CAS server is that Exchange 2010 will determine the polling frequency, not the client. The setting will work immediately, but clients need to reconnect in order for the new value to become effective. Note that setting this value lower than 5000 has no effect because Outlook 2003’s minimum poll rate is 5000.

Another solution is to enable cached mode for Outlook 2003 clients. This will not solve the delay in receiving new e-mail notifications, but it will solve the most annoying issue, being the delay in visual feedback. In cached mode users won’t notice the delay because they’re working with a local copy of their mailbox. Any changes (sends, deletes, moves) will happen in the local cached file (OST), and Outlook will update their Exchange mailbox in the background.

The article fails to mention the third solution: upgrade! The reason Outlook 2007 doesn’t have this issue is that Outlook 2007 (and later) support a third method: asynchronous (push notification). And as you’ve probably guessed, Exchange 2010 (and Exchange 2007) supports this method as well.