Exchange 2010 and the Case of the Empty Server Container

I have seen several issues pop up with Exchange 2010 in regard to Public Folders.  They include:

  • Public Folder replication fails with Event 1020
  • Mail-enabled Public Folders do not receive email

These issues all link back to the same problem; an empty “Servers” container under an Exchange Administrative Group.  This typically occurs in an environment were you have migrated from Exchange 2003 and have decommissioned the last of the legacy Exchange servers.  To fix this issue do the following:

  1. Launch ADSI Edit and connect to the Configuration container
  2. Browse to CN=Services –> CN=Microsoft Exchange –> CN=OrganizationName –> CN=AdministrativeGroupName –> CN=Servers
  3. Verify the CN=Servers container is empty.  If it is right-click on CN=Servers and choose Delete from the context menu

More information on this error can be found in the following KB article.


Configure Conference Rooms in Exchange 2007

In Exchange 2007 you can use the following command to setup a Resource Mailbox to automatically book calendar appointments:

Set-MailboxCalendarSettings -Identity "RoomName" -AutomateProcessing AutoAccept

What about if you don’t want it to automatically book.  Instead you want the meeting request to go to a delegate (or delegates) who then can approve or deny the request.  You can use the following command:

Set-MailboxCalendarSettings -Identity "RoomName" -AutomateProcessing AutoAccept -ResourceDelegates "DelegateName" -AllBookInPolicy:$false -AllRequestInPolicy:$true

The theory is bascially the same in Exchange 2010 however all of these properties can be set in the Exchange Management Console under the mailbox properties.

The following article in the Microsoft Exchange Team Blog has more details on resource mailboxes:

How to Upgrade an Exchange 2007 CCR Cluster to SP1/SP2/SP3

I just had to upgrade an Exchange 2007 RTM CCR cluster this weekend to Exchange 2007 SP3.  This article is still the best reference.

We ran into a problem at Step 5 and Step 14 where the setup program failed reporting that there were still active cluster resources on the node.  When we investigated in the Cluster Administrator MMC we found that there was a resource named PBX-ClusterGroup-Servername.  After some investigation we found that this resource is related Symantec NetBackup.  NetBackup 6.0 contains features that are dependent on a new Common Services Framework (CSF) called, VERITAS Private Branch Exchange (PBX), thus the name.

In any event, if you just take this resource offline on each node prior to the upgrade, you will be able to run it without issue.

Remote Desktop Slow Problem Solved

I ran into this issue again today so I thought I would share.  I had a client who was experiencing very slow performance from his Remote Desktop Client to several servers he was accessing via TS Gateway.  The problem turned out to be related to a feature found in Remote Desktop Connection 6.0 and higher.  RDC 6.0 leverages the Receive Window Auto-Tuning feature found in Windows Vista and Windows 7.  The problem is that the Receive Window advertised is much larger than it was in Windows XP which allows more data to be sent in larger, faster bursts.  This is fine in a LAN environment but, when coming in via a WAN connection and then encapsulating the RDP traffic into an SSL stream, the net result was a lot of packet fragmentation.  The following command will set the Receive Window to a more conservative value and consequently improve overall Remote Desktop performance.

netsh interface tcp set global autotuninglevel=highlyrestricted

Here’s the link to the original article that explains the problem in greater detail.  Thanks guys!

Remote Desktop Slow Problem Solved