Exchange 2007 provides a rich set of PowerShell tasks for administering Exchange objects and Public Folders are no exception. The tasks let you perform basic public folder operations – i.e. Create a Public Folder, Modify a Public Folder, Delete a Public Folder – however, the real power comes from piping support and enabling bulk operations on these objects. Let's take a look at the tasks that exist to work with public folders.
Public Folder Management Tasks for individual public folders
These tasks are used to manage public folders in the MAPI public folder tree (also sometimes called the MAPI hierarchy). These are public folders that are defined in the public folder database, which may or may not be mail-enabled. There are a number of other public folder related tasks that are used to manage mail-enabled public folders and public folder permissions which will be covered in a later blog post.
The new-publicfolder task allows you to create a new public folder in the MAPI public folder tree (or hierarchy). For example, you could run the following command:
New-PublicFolder –Name Foo
That would create a folder named "Foo" at the top of the hierarchy (for those familiar with the term, it actually creates the folder "Foo" under IPM_SUBTREE). If no parent folder is specified, as in the case above, then the top of the hierarchy (represented as "\") is assumed. To subsequently create a child folder of the new "Foo" folder you would specify the parent folder with the "-path" parameter and a command like:
New-PublicFolder –Name FooChild –Path \Foo
The remove-publicfolder task is the opposite of new-publicfolder. It removes a Public Folder from the MAPI hierarchy. For example, you could run the following:
Remove-PublicFolder –Identity \Foo\FooChild
This will remove the folder named "FooChild" under the \Foo path. You will notice that the identity above is the full path to the public folder you want to remove. You can pass the identity in three different ways – as an object reference (ie through piping), as a full path (see above example), or as a LongTermEntryId (a globally unique identifier for a public folder). This is how Identity is used in all Public Folder tasks. Obviously, using the full path is easiest when working with the command shell manually, however, when scripting you are much better off using an object reference or LongTermEntryId if you have access to them because they are significantly faster than using the full path. This is because to calculate the folder path, the system must first look up each parent folder in the path in order to navigate to the correct folder. By providing the LongTermEntryId, the system can access the public folder directly, rather than having to look up each parent first. However, LongTermEntryId is only used primarily in scripting because it is a VERY long identifier and unwieldy to type and virtually impossible to remember.
If you ran the above command and the "FooChild" folder had any children, then the command would error out since you cannot delete a folder which has children. If you had wanted to remove "FooChild" and its children, then you would need to run the following:
That command will set the MaxItemSize property to 10MB for the folder, meaning that it won't accept items larger than 10MB. It also sets the replica list for the folder so it will be replicated to the public folder databases on Server1 and Server2.
The Get-PublicFolder command retrieves a public folder or set of public folders. The output of this task can then be piped to any of the other public folder related tasks (set/remove/update-publicfolder, get-publicfolderstatistics, add/remove/get-PublicFolderClientPermissions, add/remove/get-PublicFolderAdministrativePermission, or enable/disable/get/set-MailPublicFolder), making it a very useful way to define the scope of folders affected by some action you wish to take.
It can also be used to see the specific settings on a particular public folder. For example, you could run the following command:
Get-PublicFolder –Identity \Foo
That would return the folder named "Foo" at the top of the hierarchy. By default, it would show only the folder name and the path of the folder in the display output. If you wanted to see all of the properties associated with that public folder, such as Replicas, Quotas, and Age limits, you could run:
Get-PublicFolder –Identity \Foo | Format-List
That works for getting a specific folder where you already know the exact path. However, what if you wanted to see the children of a specific folder because you weren't quite sure of the exact name of the folder you wanted. You could run the following:
This will return the list of children under the top of the hierarchy. You will notice that no Identity was passed in that example. If no Identity is passed, it defaults to "\" which is the top of the hierarchy.
You can also perform a get recursively on a portion of the public folder tree by running the following command:
Get-PublicFolder –Identity \Foo –recurse
That will return "Foo" and all of its children (and all their children, etc) recursively. Note that this operation could take a long time and as it is written above is a pretty useless command (it only outputs these objects to the screen). However, this technique becomes very powerful when combined with piping to another command. For example if you wanted to set the MaxItemSize property on all public folders under \Foo, then you would run:
WARNING: Piping as shown above is the correct way to perform bulk operations on Public Folders. You never want to recursively get a set of public folders and store them in a variable. For example you should never run:
This would trigger content replication of the folder named "Foo" at the top of the hierarchy using Server1 as the source.
Global Public Folder Management Tasks
These tasks are used to control the entire public folder hierarchy rather than a single public folder.
The Update-PublicFolderHierarchy task triggers replication of the public folder hierarchy from a particular server. For example you could run the following:
Update-PublicFolderHierarchy –Server Server1
This is just like the Update-PublicFolder example above, except instead of replicating the content of a specific folder, it replicates the public folder hierarchy information (ie – the list of folders and their configuration details rather than their content).
These tasks suspend or resume public folder content replication for the entire organization. This is useful if you are having a replication storm. This is the equivalent of a big, red "STOP" button for public folder content replication. Note that suspending content replication DOES NOT suspend hierarchy replication. Change to the public folder hierarchy will still be replicated. Neither of these commands take any parameters.
This is the first part of public folder management blog posts. A later public folder tasks post will discuss mail enabled public folders and public folder permissions.