Knowing your limits
Published Apr 17 2006 02:09 PM 1,598 Views

Recently MSIT wanted to make some global changes to the retention time of public folders. In the past we had a global limit of 3 years retention on items in public folders. The plan was to change the default limit to 1 year, and then exempt folders as needed.

 

But there were a couple of complications...

 

After examining the public folder tree and gathering feedback from the user base, we found that about 30% of the public folder tree would need an exemption for one reason or another. About 100,000 folders give or take a sub tree. Worse, the folders to be exempted where "sprinkled" throughout the tree in no real pattern.

 

Secondly, in Exchange 2003, public folder age limits are enforced thru 3 mechanisms, per replica properties, database limits, and per folder properties. Database properties and folder properties could be accessed thru a variety of mechanisms (DAV, LDAP, and Exchange System Manager) but replica properties are accessible only thru ESM.

 

Age Limit Enforcement

Precedent

Per Replica

1st

Per Database

2nd

Per Folder

3rd

 

Due to the number of public folders that needed to be exempted, and problems around manually keeping each folder replica in sync, using Exchange System Manager to set per replica limits wasn't going to work. Since database policies had higher precedence then per folder limits, we decided that we would have to set all folders at the folder level and then turn off database and replica limits (fortunately, only a few folders had replica limits.)

 

In order to get the data we needed, we first used PFDAVAdmin to extract information about the tree. We needed the display name, folder path, folder size, item count, the PR_OVERALL_AGE property (this is the per folder age limit property), and the PERMANENTURL (mapi prop:0x670e001f)

 

Exchange 2003 SP2 introduced a number of cool new features, one of which is a wizard for doing large scale modifications of public folders. Since the folders where scattered all around, we couldn't use this tool to set the age limits on the folders. PFDavAdmin doesn't support importing modifications of these types of properties so it was out too. Time to write some code! Fortunately, there are lots of examples of how to do this; MSDN has a good one here.

 

Basically we need to do a DAV propatch something like this on each folder:

 

            queryBuilder = new StringBuilder();

            queryBuilder.Append(@"<?xml version=""1.0""?>");

            queryBuilder.Append(@"<b:propertyupdate xmlns:a=""http://schemas.microsoft.com/mapi/proptag/"" xmlns:b=""DAV:"" xmlns:z=""urn:schemas-microsoft-com:datatypes"">");

            queryBuilder.Append(@"<b:set>");

            queryBuilder.Append(@"<b:prop>");

            queryBuilder.Append(@"<a:0x66990003 z:dt='int'>" + Int32.Parse(ageLimit) + @"</a:0x66990003>");

            queryBuilder.Append(@"</b:prop>");

            queryBuilder.Append(@"</b:set>");

            queryBuilder.Append(@"</b:propertyupdate>");

 

We still needed to have a way to identify each folder. Since users can modify display names, move folders, and include symbols which maybe hard to code into a URL, we need a better URL naming mechanism. Fortunately, this already exsisted, the permenateurl property we had gathered ealier. Basically, each public folder in Exchange can be identified by a URL that looks something like the following:

 

http://myPublicFolderServer/ExAdmin/Admin/<FQDN>/public%20folders/-FlatUrlSpace-/f85c74f57f7280469fa...

 

We now have all the information we need to set the folder age limits, the desired age limit, the url of the folder, and a tool to stamp each one. Any public folder server will work, since the age limit is a property on a folder, and all public folder servers have a copy of the folder hiearchy. We're ready to go.

 

The final step was to batch the folders into smaller groups. Making large scale changes to public folder properties can result in mail replication storms as each PF server sends out and recieves change notifications. We needed to ensure that our changes where small enough that we didn't cause any problems. After a little testing in our lab, and carefully monitoring the impact on our infrastrucutre, we found the magic number (which will vary from deployment to deployment, you'll have to do this on your own) and a week or two later had removed all the stale unwanted data from our environment.

 

- Ted Kolvoord

8 Comments
Version history
Last update:
‎Jul 01 2019 03:13 PM
Updated by: