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 FilesMicrosoftExchange ServerV14Scripts
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 FilesMicrosoftExchange ServerV14 and C:Program FilesMicrosoftExchange ServerV14bin 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.
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 on his blog.
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