Exchange 2007 onwards contain a treasure trove of built in scripts to help administer the system. These scripts are listed in TechNet and are found under the Exchange installation path in the scripts folder. Yes – somewhat unsurprisingly.
In this post let’s take a look at the scripts that can help with administering public folders, specifically adding new replicas to public folders. This post will cover Exchange 2007 and Exchange 2010. Exchange 2013 leverages Modern Public Folders. The below steps are from an Exchange 2010 SP3 based lab.
Running Get-Item *Replica*.ps1 will show the replica scripts, though there are additional ones to manage other aspects of public folders which have the phrase “PF” in their name. Looking at the scripts whose name contains replica using Get-Item *Replica*.ps1 we see:
And then using Get-Item *PF”.ps1 the other public folder management scripts:
You will note that the default Exchange 2010 path is:
C:\Program Files\Microsoft\Exchange Server\V14\Scripts
One of my favourite shortcuts is to use the $EXScripts variable in the Exchange Management Shell. This abstracts the Exchange install location. As an extra bonus, there are also variables automatically created for $ExInstall and $ExBin. They point to C:\Program Files\Microsoft\Exchange Server\V14 and C:\Program Files\Microsoft\Exchange Server\V14\bin respectively.
Let’s look at the process to add more replicas using the in-box scripts. There are other scripts to help with maintaining and managing Public Folder permissions, though we will not look at them in this post.
Tidy Up
In an ideal work the Exchange admins will know the business justifications for each Public Folder, and can know which are valid and which are not. Thus we could delete stale and unwanted content before adding replicas to another server.
But that’s not typically how it works, and there is a long history of just moving over all content to a new server. If it is possible to do some clean up, that would be fantastic but I will not be holding my breath……
Environment Check
Before we start adding replicas to Exchange 2010, it is worth verifying that we will not experience a known issue. Public Folder replication to Exchange 2010 may not work if there is an empty servers container in AD DS. This is something that we need to manually verify and manually remediate. This can be caused by previous Exchange 2000/2003 Administrative Groups which remain in the AD DS, though all servers have been removed from those Administrative Groups. There is a chance that an Administrative Group (First Administrative Group or another custom Administrative Group) remains with a Servers container, but no servers inside it. During replication, when the Exchange 2010 Store Driver sees the empty Servers container in Active Directory, it's expecting a System Attendant object inside the container and when it is not found the error occurs.
Use the ADSI Edit tool to remove ONLY THE SERVERS CONTAINER using the following steps. Do NOT delete the entire Administrative Group.
- Start the ADSI Edit tool. To do this, click Start , click Run , type adsiedit.msc , and then click OK
- Expand Configuration Container [servername.domainname.com] , and then expand CN=Configuration,DC=DomainName,DC=com
- Expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=OrganizationName where OrganizationName is the name of your Exchange organization.
- You will see the empty Administrative Group. Expand the CN=AdministrativeGroupName
- Expand CN=Servers
- Verify there are no server objects listed under the Servers container
- Right click on the emtpy CN=Servers Container and choose Delete.
Please see KB 2487271 for additional details.
Adding Replicas To Public Folders
The act of adding a replica to an new Public Folder database is straightforward. We can use the AddReplicaToPFRecursive.ps1 script which will maintain all of the current replicas and simply add the new one to the list. This script adds a new server to the replication list for a public folder and all the folders beneath it in the hierarchy. If the server is already listed in the replication list for a folder, nothing is changed for that folder. The script accepts the follow parameters where “Server” is the Exchange Public Folder database server to work against. The TopPublicFolder is the folder which identifies the uppermost portion of the Public Folder tree to be manipulated. This may be the root of the Public Folder hierarchy, or a sub-tree,
-
Server (Optional) This parameter specifies the server to operate against. This server must be an Exchange Mailbox server that has a public folder database. If you don't use the Server parameter to specify a server, the script defaults to the local server.
- TopPublicFolder (Required) This parameter specifies the identity of the folder at the top of the public folder tree.
- ServerToAdd (Required) This parameter specifies the server identity to add to the replica list. This server must contain a public folder database.
One thing to note is that we need to ensure that both user and system public folders are replicated to ensure consistency. This is one of the issues that I often see in the field, the system folders are often overlooked. The top of the user portion of the hierarch is referenced as “” whereas the system public folders are located under “NON_IPM_SUBTREE”. Since these folders are in different locations, we need to run the script twice so that both are added as replicas to the new Public Folder database.
From the Exchange Management Shell we could run:
.AddReplicaToPFRecursive.ps1 -TopPublicFolder "" -ServerToAdd "E2K10B"
.AddReplicaToPFRecursive.ps1 -TopPublicFolder "NON_IPM_SUBTREE" -ServerToAdd "E2k10B"
Moving Replica To New Public Folder Database
You will notice that there are a couple of different scripts which can be used to move Public Folder replicas. We could execute either MoveAllReplicas.ps1 or alternatively both of these two scripts AddReplicaToPFRecursive.ps1 & RemoveReplicaFromPFRecursive.ps1.
MoveAllReplicas.ps1 replaces a server with a new server in the replication list for all public folders, including system folders. This is great if you already have multiple replicas and simply need to swap one out for a new Public Folder server.
My personal favourite is to perform the second option noted above. Namely to run both AddReplicaToPFRecursive.ps1 & RemoveReplicaFromPFRecursive.ps1 scripts. The primary reason for this is control. I want to ensure that any planned change is executing in the way that I expect, and individual steps should be validated. By running the AddReplicaToPFRecursive.ps1 we can allow time for replication to occur and verify that replication is healthy prior to removing the replica which is being replaced.
See the section below on verifying replication status.
Public Folder Replication Delay
You may or may not run into issues with Public Folder replication. For those who have worked through enterprise replication issues, they are thankful with the simplification which Modern Public Folders bring!
The ultimate guide to Public Folder Replication Troubleshooting is from Bill Long (in three parts). In the second part he discusses the “backfill array” which is very important in large content replication situations:
“When you experience a situation where you've added replicas of a lot of folders to a new store, and replication seems fine at first but then grinds to a halt over the next day or two, you have probably hit the outstanding backfill limit. The outstanding backfill limit is a mechanism intended to throttle replication. By default, the store will only allow 50 outstanding backfill requests at a time. Once it has 50 outstanding, it will re-request those 50 over and over until they are satisfied. Once any one outstanding entry has been satisfied, that opens up a slot in the OBL for a new set of data to be requested. This means that if 50 requests are having problems being satisfied for whatever reason, replication can not proceed.”
This worth noting so that when large amounts of data are added, sufficient time is required to allow for replication to the new store.
Verifying Public Folder Replica And Replication Status
Exchange provides all of the necessary plumbing and infrastructure to report on the status of Public Folders. That said, the Exchange community is very active with extending and enhancing the built-in tools, and reporting on Public Folder status is no exception.
Mike Walker posted a script which reports upon Public Folder replication status in a graphical format. Please download and test the tool which is available on the TechNet scripting gallery.
In addition to this Thomas Stensitzki has updated Mike’s original script to deal with UTF, most likely due to the European customers that he works with. This is also available for download on the TechNet script gallery.
Update 9-5-2016: The domain renewal for Mike’s site appears to have lapsed.
Update 8-6-2016: Updated links for reporting scripts.
Reviewing Exchange Public Folders
To review the Public Folders we can use either the Public Folder Management Console, which can be found in the Exchange toolbox, or Exchange Management Shell.
The Public Folder Management Console has a couple of quirks. Note that to see the properties of a Public Folder it must be expanded in the left pane to make the individual folder visible in the right hand pane. Right click the folder in the right hand pane to see the properties:
In the Exchange Management Shell we can use the Get-PublicFolder cmdlet to review folders and their properties. For example to list all folders with their name and replicas
Get-PublicFolder -Identity NON_IPM_SUBTREE -Recurse | Select-Object Name, Replicas
Get-PublicFolder –Identity “” -Recurse | Select-Object Name, Replicas
Cheers,
Rhoderick
