Knowing your limits


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-/f85c74f57f7280469fa523b239cea3e3-1e834051

 

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

Comments (8)
  1. Jon says:

    We’re going through a very similar initiative here as well, and am curious how you were able to determine "only a few folders had replica limits."  What property stores the replica limit?

  2. Exchange says:

    Jon,

    There is no programmatic mechanism available to determine this. The per replica folder size limit is a property that can only be accessed thru an administrative RPC call (non-MAPI) in ESM.

    MSIT had a list already available where we had this information previously captured. If you needed to determine this, you would have to use the Exchange System Manager and walk thru all public folder replicas and check the limit folder by folder.

    Ted.

  3. Troy says:

    We’ve had several Exchange administration headaches like this.  We wanted to 1) export Exchange configuration to a SQL databases, 2) do queries against the database to update/find out configuratino informatin and then 3) run an exchange utility program to apply the changes back to Exchange.  This would help us in 1) greatly reduce the complexity of applying mass changes to Exchange, 2) allow us to use SQL to do Exchange updates instead of DAV.

  4. Anonymous says:

    WARNING: Next week I won’t post the traditional &quot;Weekend reading&quot;. Actually I won’t post anything, I’ll…

  5. Anonymous says:

    Security

    &amp;nbsp;

    News

    &amp;nbsp;

    Are Smart Cards the New Way of Life? – Solving the…

  6. Anonymous says:

    Security

    &amp;nbsp;

    News

    &amp;nbsp;

    Are Smart Cards the New Way of Life? – Solving the…

  7. aaron says:

    …and this is yet another example of why I recommended my clients not to use PF’s. :-)  With the proliferation of storage technologies and mechanisms around, bogging down mail servers with filing-cabinet style storage seems to be a bit antiquated.  Depending on the type of content, we push our users to standard file shares that have either device/3rd-party archiving and vaulting or SharePoint sites (that also have 3rd-party archiving and vaulting tools managing them).  The only PF’s I have to deal with are the forms repositories and scheduling. ;_)

Comments are closed.

Skip to main content