Fixing Public Folder Directory Objects That Aren’t Linked To The Hierarchy
In my recent post on the Exchange Team Blog, I briefly mentioned the dangers of forcibly removing an administrative group from ADSI Edit. The most common unintended consequence of this is a deletion of the directory object that represents the Public Folder Hierarchy.
Deleting this object creates quite a mess, because all of your mail-enabled public folders and all of your public folder stores point to it. Even if you create a new hierarchy object and manually link the stores to it by setting the msExchOwningPFTree value, you still have a ton of public folder directory objects in Microsoft Exchange System Objects with no homeMDB.
I had a customer today in this situation, and I wrote a quick Powershell script to fix all the directory objects for the mail-enabled public folders. Here it is.
If you find yourself in this situation, you’ll still need to create a new hierarchy object and link your public folder stores to it. This script does not fix that part of the problem, although it wouldn’t be hard to adapt it to link the stores as well.
To keep things simple, this only runs against one domain at a time. You’ll need to change the container to point to the Microsoft Exchange System Objects container in each different domain.
# Link-PFProxies.ps1
#
# Change these two values to match your environment.
# $container should point to the MESO container you want to run against.
# $pfTreeDN should contain the distinguishedName of the public folder hierarchy object.
$container = [ADSI]("LDAP://CN=Microsoft Exchange System Objects,DC=contoso,DC=com")
$pfTreeDN = "CN=Public Folders,CN=Folder Hierarchies,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com"
#################################################
$filter = "(!(homemdB=*))"
$propertyList = @("distinguishedName")
$scope = [System.DirectoryServices.SearchScope]::OneLevel
$finder = new-object System.DirectoryServices.DirectorySearcher($container, $filter, $propertyList, $scope)
$finder.PageSize = 100
$results = $finder.FindAll()
("Found " + $results.Count + " folder proxies with no homeMDB...")
foreach ($result in $results)
{
("Fixing object: " + $result.Path)
$entry = $result.GetDirectoryEntry()
$entry.Put("homeMDB", $pfTreeDN)
$entry.SetInfo()
}
Comments
Anonymous
January 01, 2003
Hi Frank, Is your OAB even generating at this point? It sounds like the OAB public folder might not have a replica, which would prevent it from generating and prevent clients from downloading it. If it does have a replica, I recommend you get a case open with support so we can troubleshoot the issue.Anonymous
January 01, 2003
Avi, it depends on what you mean by 'archive'. You can certainly drag and drop emails into the folder. Since it's not mail-enabled, you just have to have some way of getting the messages into the folder that doesn't involve emailing them.Anonymous
January 01, 2003
Wow the formatting of my comment is awful. I had put those in a nice clear list, but it ran all the names together.Anonymous
January 01, 2003
Hey Nick, I'm not sure what you mean when you say most mail-enabled PFs point to the 2003 admin group. Do you mean the legacyExchangeDN? It doesn't really matter which admin group that points to. It will always point to the admin group that contained the server on which the folder was originally created, and it never changes, even if that admin group is deleted. This is normal. As far as the location of the hierarchy, that doesn't matter either. The public folder directory object is linked to the hierarchy object via the homeMDB value, which is a DN-linked attribute. This means that when you move the hierarchy, the homeMDB value on the public folder directory object automatically updates to reflect the new location. This is a function of the Active Directory, and doesn't rely on anything within Exchange. For the SystemMailboxes, I'm not sure why they are hanging around without homeMDB values. They're definitely not working if they're in that state. Those SystemMailboxes might correspond to stores that no longer exist. Updating the homeMDB should be fine, or you can probably just delete them. You can confirm if the store still exists by matching the GUID in the SystemMailbox name with the objectGUID of each mailbox store. If there's no mailbox store with that objectGUID value, you can delete the SystemMailbox object.Anonymous
January 01, 2003
Bill, We have eliminated our public folders, and I would like to clean out the MESO folder. There are still hundreds of objects that probably serve no purpose, but I don't see a way of determining which are still necessary. Some examples:EventConfig_Servername (where the server is long gone)globalevents (also globalevents-1 thru 29)internal (also internal-1 thru 29)OAB Version 2-1 (and 2-2 and 2-3)Offline Address Book - Storage group nameOWAScratchPad{GUID} (30 of them)Schedule+ Free Busy Information - Storage group nameStoreEvents{GUID} (31 of them)SystemMailbox{GUID} (over 700 of them)Most of the SysemtMailboxes are Type: msExchSystemMailbox, but 3 are Type: User. I found one that was created last month. Apart from the SystemMailboxes, most everything else has a whenChanged date of 2010. What to do?Thanks, MikeAnonymous
January 01, 2003
Hi Anonymous,If your public folders are gone you can definitely delete the following:EventConfig_globaleventsinternalOAB VersionOffline Address BookOWAScratchPadSchedule+ Free BusyStoreEventsAll those objects correspond to system folders that were once part of your public folder structure. The SystemMailboxes do not correspond to folders, so I would leave those alone. Presumably, many of those are no longer being used, but since I'm not sure how to identify which ones you can safely delete, I would err on the side of safety in regards to the SystemMailbox objects.Anonymous
January 01, 2003
Great! I am glad you found it useful.Anonymous
January 01, 2003
Hey Mike, I answered your question in more detail in a post on my new blog: http://bill-long.com/2014/01/11/cleaning-up-microsoft-exchange-system-objects/Anonymous
July 21, 2010
I really must say thank you for this litlle piece of code that prevented me of major headaches...Anonymous
September 27, 2010
Good morning! I had a quick question on this script. We had a situation where the PF object was moved from the 2003 Administrative Group to the 2010 Admin Group. Exch 2003 and 2010 are coexisting right now but most mail enabled PFs point to the 2003 Admin Group. Also, when I mod the script to list mail enabled PFs a few SystemMailboxes are returned as well. Is it safe to update these SystemMailboxes with the mew home MDB value?Anonymous
April 11, 2011
We had this happen to our Exchange server about six months ago by an administrator who migrated our Exchange 2003 server to Exchange 2010. When the Public Folders were gone, all email for our Outlook 2003 clients stopped. A consultant fixed the issues with email, scheduling, etc.. However, when the Outlook 2003 Clients try to download changes from the GAL to a local OAB, it fails. These clients are unable to see neGAL objects when using Cached mode. This is the closest thing I have seen to the issue. Bill, do you have any specific suggestions or info about Outlook 2003 clients not downloading GAL changes to the OAB?Anonymous
October 11, 2011
Great, thanks - fixed it for me. It didn't straight away, I had to remove the 'servers' object under the old first administrative group (which I've done before) but after this it all worked.Anonymous
December 20, 2012
Hi Bill, just got 1 question, can we archive emails in a non mail enabled public folder on Exchange 2010?Anonymous
December 21, 2012
Thanks a lot :-)Anonymous
December 21, 2012
Thanks a lot for that Bill..Actually the issue is something like this, we have a public folder and its non mail enable and now we found out that this public folder database is grown massively in size. So we want to archive some older emails to a pst file and save it on a network location. Just like how we do for a mailbox. Not sure how it works for public folder. I would really appreciate if you have any ideas or suggestions on this?Anonymous
February 21, 2014
These are the top Microsoft Support solutions to the most common issues experienced using Microsoft Exchange