Exchange 2010 SP1 Rollup 3 Released: Fixes Bug since SP1 in EMC & Brings Back UDP Support

UPDATE March 9th 2011: I have installed Exchange 2010 SP1 Rollup 3 at one site and this did indeed fix this issue finally.

The Microsoft Exchange Team Blog just announced the release here Released: Update Rollup 3 for Exchange 2010 SP1 and Exchange 2007 SP3. This is good news for all the folks out there that got bitten by the Exchange 2010 SP1 bug that causes the Exchange Management Shell (EMC) not to show all database copies after upgrading to exchange 2010 SP1. I’ve blogged about this in EMC Does Not Show All Database Copies After Upgrade To Exchange 2010 SP1 and chimed in to the discussion at Database copies are not all showing up in EMC after SP1 upgrade on the Exchange forums. So apart from cheers for the UDP notifications returning in support of Outlook 2003 let’s hear it for a the EMC case sensitivity bug getting fixed Smile

After while Microsoft also blogged about this Database copies fail to display after upgrading to Exchange 2010 Service Pack 1

We got notified around October 13th that they would included the fix in Exchange 2010 SP1 Roll Up 3 but that they where working on an interim update. They dropped the ball there because communication died about the latter and we were left to conclude we would have to wait for Rollup 3. Well that took it’s time. It’s now march 2011. One of the reasons I think it took so long for Rollup 3 to arrive is the decision for to re-add UDP support for Exchange 2010 for use with Outlook 2003 as blogged about in Microsoft Listens To Customers & Adds UDP Notification Support Back to Exchange 2010

In the ends we will have silly and long unaddressed bug fixed and a welcome aid in migrating customers to Exchange 2010 that are running Outlook 2003. I do wonder however if the bug had been with  PowerShell in the EMS and not in the EMC if Microsoft would have fixed this sooner.  Sure it wasn’t an issue as you could manage everything perfectly using PowerShell and it was only a GUI bug but for some users/customers this is not as obvious  and it made ‘m feel a bit like 2nd class citizens so we had to do some extra “damage” control on that front as well.

Microsoft Listens To Customers & Adds UDP Notification Support Back to Exchange 2010

Well, after almost 14 months of deploying Exchange 2010 and tweaking the Outlook 2003 settings via GPO’s to give users an acceptable experience Microsoft adds support for User Datagram Protocol (UDP) notification functionality back into Microsoft Exchange Server 2010. By doing so they recognize that a lot of businesses & organizations will be using Outlook 2003 for a while and that not all of them where happy to deal with the way Outlook 2003 functions with Exchange 2010. More information on the UDP issue can be found here http://support.microsoft.com/kb/2009942 (In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox). Now most my customers use cached mode where possible and a GPO Setting to reduce the Maximum Polling Frequency registry entry to 5 seconds helped. But there are places where cached mode is not an option (Terminal Services) or people don’t accept this change in behavior and go with Outlook 2007 instead of 2010  or even choose to deploy Exchange 2007 over 2010. All because of this dropping of the UDP notification support.

Now this functionality will be back with in Exchange Server 2010 Service Pack 1 Roll-Up 3 (SP1 RU3).  Good news for people dealing with Outlook 2003 and Exchange 2010. Less good news for the people dealing with the GUI bug that Exchange 2010 SP1 introduced where the Exchange Management Console does not show all database copies after upgrading to Exchange 2010 SP1. This is set to be fixed in Roll-Up 3 but to get the UDP support back they adjusted the release schedule for the E2K10 Sp1 Roll-Up 3, which is now expect to be released in March 2011. So we’ll have to wait a bit longer for that fix. As you noted you need to be running Exchange 2010 SP1 to get this backward compatibility support for outlook 2003.

Read this announcement on the Exchange Team Blog: UDP Notification Support Re-added to Exchange 2010

Exchange 2010 SP1 Public Folder High Availability Returns with Roll Up 2

Al lot of people were cheering in the inter active session on Exchange 2010 SP1 High Availability with Scott Schnoll and Ross Smith of the Exchange Team. They announced (between goofing around) that the alternate server that provides failover to the clients (so they can select another public folder database to connect to) for public folders and that is sadly missing from Exchange 2010 would return with Exchange 2010 SP 1 Roll Up 2. This feature is needed by Outlook to automatically connect to an alternate public folder and it’s return means that high availability will finally be achievable for public folders in Exchange 2010 SP1. That’s great news and frankly an “oversight” that shouldn’t have happened even in Exchange 2010 RTM. The issue is described in knowledge base article “You cannot open a public folder item when the default public folder database for the mailbox database is unavailable in an Exchange Server 2010 environment” which you can find here  http://support.microsoft.com/kb/2409597.

In previous versions of exchange you made public folders highly available to Outlook clients by having replica’s. The Outlook clients could access an replica on another server if the default public folders as defined in the client settings of the database was not available. Clustering in Exchange 2010 does nothing for public folders. In Exchange 2010 the Outlook clients connect directly to the mailbox server in order to get to a public folder so they do not leverage the CAS or CAS array. Also the DAG does not support public folders and as clustering happens at the database level on DAG members and no longer at the server level we no longer get any high availability for the clients with clustering in Exchange 2010. Sure, if you have multiple replica’s the data is highly available but the access to another replica/database/server for public folder doesn’t happen automatically in Outlook when you’re running Exchange 2010. To make that happen you need an alternate server to be offered to the client for selection But as this feature is missing in Exchange 2010 up until SP1 Roll Up 1 in reality until now you need to keep using Exchange 2003/2007 to have public folder high availability.  Exchange 2010 SP1 Roll Up 2 will change that. I call that good news.

Exchange 2010 Public Folder Worries At Customer: No existing ‘PublicFolderProxyInformation’ matches the following Identity

A customers was recently using the EMC GUI in their Exchange 2010 environment, having a look a the public folder properties when they got this error:

—————————
Microsoft Exchange
—————————
Can’t log on to the Exchange Mailbox server ‘DAGMBX.demolab.com’. No existing ‘PublicFolderProxyInformation’ matches the following Identity: ‘demolabHeadQuartersFincanceDepartmentFiscalUnit’. Make sure that you specified the correct ‘PublicFolderProxyInformation’ Identity and that you have the necessary permissions to view ‘PublicFolderProxyInformation’.. It was running the command ‘Get-MailPublicFolder -Identity ”demolabHeadQuartersFincanceDepartmentFiscalUnit” -Server ‘DAGMBX.demolab.com”.
—————————
OK  
—————————

image

Hey … when did this start?  They never complained about this before, but did they ever use it.This probably was actually the first time they tried to look/edit the public folder permissions after doing the following over the past month and in this particular order:

  1. Moving to Exchange 2010 SP1
  2. Removing the last Exchange 2007 servers from the organization.

Now I know about a bug that exist and that was recently blogged about by Dan Rowley in Exchange 2010 get-mailpublicfolder name returns No existing ‘PublicFolderProxyInformation’. The point is that there should be a mailbox database mounted on the server that has the System Attendant mailbox associated with it.  However, this is not the case here.  The mailbox servers are member of a DAG and all of them host a copy of the PF. The replication runs fine, users can work with them, the remaining Outlook 2003 users report no issues. But there is more in that blog: “Basically the work around is to mount a mailbox store on the server that is generating the error, or if there is a database already mounted – verify the system attendant is properly configured to point to a valid homemdb.” Now that last point is interesting and indeed that was the issue here. On two members of the DAG the homeMDB attribute was not set. Now what could be the root cause of this? I don’t know, certainly not in this case. All things have been done by the book … Ah well, luckily the fix is not very difficult. We need to put a valid entry in the homemdb. In this case we’ll take the value of the DAG member that had it filled in. This seems to be the most recently created database in the DAG. In Exchange 2010 this is done as described below. Note we have a DAG here, so we can work with any database that has a valid copy on the server(s) in question.

How to check the homeMDB attribute value:

  • Start ADSI Edit and navigate to CN=Configuration,DC=,DC=,DC=/Services/Microsoft Exchange//Administrative Groups/Exchange Administrative Group (FYDIBOHF23SPDLT)//Servers/MBXServerWithIssue
  • Right-click Microsoft System Attendant, and then click Properties to display the  Attributes list and find the homeMDB attribute.
  • If the homeMDB attribute has a value make sure  it points to a valid mailbox database. If the value of the homeMDB attribute is empty (not set) or incorrect you need to fix this.

image

How Fix the homeMDB attribute value:

  • In ADSI Edit navigate to Start ADSI Edit and navigate to CN=Configuration,DC=,DC=,DC=/Services/Microsoft Exchange//Administrative Groups/Exchange Administrative Group (FYDIBOHF23SPDLT)/Databases."
  • Right-click a mailbox database that is local (NON DAG) or has a valid copy on the server (DAG) , select Properties and in  the Attributes list, select the distinguishedName, and then click View.
  • Copy the value of the distinguishedName attribute and close the dialogs

image

NOTE in this particular case we can copy the value that was filled in the homeMDB attribute on one of the DAG members. You might not have one set in any.

  • Right-click Microsoft System Attendant, and then click Properties to get to the Attributes list, click homeMDB, and then choose Edit
  • In the Value box, paste the value that you copied form the distinguishedName attribute
  • Close the dialog boxes and exit ADSI Edit

When you’ve don this you’ll find following entry in the application event viewer:

Log Name:      Application

Source:        MSExchangeSA

Date:          11/2/2010 3:25:59 PM

Event ID:      9159

Task Category: General

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      DAGMBX.demolab.com

Description:

Microsoft Exchange System Attendant has detected that the system attendant object in the DS has been modified. System Attendant needs to restart the Microsoft Exchange Free Busy Publishing Service.

image

After that, I wait 10 minutes to get AD replicated and make sure to close the EMC and start it again and voila, it’s fixed.