Service Pack 2 Preview: Get-NamedProperty

In today's installment of "Microsoft Exchange Server 2007 Service Pack 2 Preview", I bring you a brief overview of how we are making monitoring named property id usage easier (in the aforementioned service pack 2 - yes, for Exchange Server 2007).

As previously covered here, Exchange Server has the ability to convert x-headers into MAPI NamedProperties. These named properties contain the values of the Xheader for consumption by native MAPI clients who do NOT want to parse the transport headers themselves.

As also covered before, there's a limit on how many of these there can ever be on a single database - 32k. There is also (as mentioned before) no way to recover a named property id once it is distributed.

Rounding out our named property recount, the Information Store (STORE) applies a named property quota which limits how many properties can be handed out. When the quota is exceeded delivering a message with x-headers which can't be created results in those x-headers not being promoted to individual properties. Delivering a message that has a named property which is NOT an x-header and cannot be mapped results in an NDR.

Questions and Answers

There are three basic questions that most admins ask after encountering a named property quota error:

1. How close am I to doom?

2. How fast are my named property ids being consumed (and by who?)

3. If I'm already hosed, what consumed the ids?

The answer is in Service Pack 2 - a new cmdlet, Get-NamedProperty. One cmdlet with three distinct uses, to answer the primary questions for named property promotion.

Get-NamedProperty by default requires a mailbox identity parameter. That's an SMTP address, a guid, a XDSDN (legacyDN) or a LDAP DN for the mailbox object. It runs in one of three mapping modes:

Last: Find the highest named property identifier in use. This is the one I use for monitoring named property growth (we see people use this in scripts to monitor MDBs and adjust the named property quotas appropriately). In this mode you get back the last named property mapped.

New: Find named properties registered since a given id. This one isn't terribly useful unless you already ran get-namedproperty in last mode (the default mode) once. You use it to monitor how fast named property ids are being consumed and where they are coming from. In conjuction with the -StartingPropId parameter, this retrieves only properties mapped since the -StartingPropId.

All: Retrieve all named property mappings. If you are stuck doing analysis of a database which has consumed all named property ids, the number one question is "Why did this happen?" All mode gives you the data you need to answer this. All also requires -Force if you don't want the cmdlet to ask if you really want to retrieve everything.

How to use this

First off, this only exists in Service Pack 2. If you are not running service pack 2 (and you probably aren't, given that it hasn't released yet), wait patiently until it does arrive. Get-NamedProperty is a support namespace cmdlet, meaning that by default you don't see it in the command list. In order to use it, you open an exchange powershell prompt and type:

> Add-PSSnapin Microsoft.Exchange.Management.Powershell.Support

(I modify my Exchange.ps1 in $exbin to do this automatically).

Now Get-NamedProperty will be available and ready to assist in your diagnosis and monitoring.

Let's look at some of the ways we can use it:

PS] C:\SP2Auditing\Perfdata>Get-NamedProperty Administrator | fl

Kind       : String

Guid       : 33eba41f-7aa8-422e-be7b-79e1a98e54b3

Propset    : 33eba41f-7aa8-422e-be7b-79e1a98e54b3

Name       : ConversationIndexTrackingEx

PropertyId : A02E

The last id in use is A02E. Since named property IDs begin at 0x8000, there are 202E properties in use - 8238. Now, we know (from this kb:, found by using "Named Property Quota" in a search engine) that by default the named property quota for internet headers is 8192 (0x2000). This MDB will certainly be logging named property quota errors. Now we also know (from the same kb) that the limit for Non MAPI named properties by default is 16384 (0x4000). So while MAPI clients can still map property ids, x-headers are not being promoted to separate named properties.

Get-NamedProperty - coming soon to a support namespace near you. Not changing the world, just making Exchange administration a little easier.

- Jason Nelson

Comments (12)
  1. Brian says:

    I thought named properties were going to be controlled with a recent rollup?  Is this not the case yet?  Once it is the case, would emails that couldn’t create named properties still result in NDR’s?

  2. xC0000005 says:

    Messages aren’t the only thing that can create them.  And yes, rollups offer a greatly reduced area of creation now.  Service Pack 2 takes this further by giving the choice to the administrator – Force Named Property Creation for X-headers, Allow Named Property creation for x-headers, Disallow Named Property Creation for x-headers.  This allows Administrators to tune the settings to match their needs.  Customers who choose to enforce x-header to named property creation will need to watch carefully their consumption.

  3. johnny says:

    I thought Rollup8 for SP1 was supposed to be fixing this in part, so there would be no need to report on the problem?

    The named properties debacle is a very sore subject.  As admins have no control over x-headers coming into their organisation, their exchange databases have been ticking time bombs.

    This needs fixed properly and thoroughly documented ASAP.  Seriously.  There has still been no advice about what to do if folk have been experiencing the problem post rollup 8.  There is a reluctance to keep updating the named properties quota knowing that there is a catastrophic failure on the horizon.  (having to constantly create new databases and migrate thousands of users is a catastrophe).

  4. mwallis says:

    I have to agree. This really needs fixing and soon.

    The 2007 release of Exchange makes me sad, so many bugs, so little time to work through them all with PSS.

    If 2010 doesnt improve these things I’m outta here…

  5. keosaki says:

    I always use these two tools to fix the above issue:

    Header filter agent and Jetapputil

  6. pesospesos says:

    Can someone address whether or not Exchange 2010 will have some kind of backup option at release?  The DPM team is saying that 2010 will not be supported until DPM v3 which is not expected until next Spring.

  7. Kevin Benson says:

    Interesting to stumble on this from 5 days ago.  This morning running into NDR’s from my Exchange 2007 SP1 Rollup 9 database when I try to e-mail my CIO.  New twist…sending from Outlook 2010 Tech Preview.  Sent fine from Outlook 2003.  Could be a show stopper for me beta testing the new Office stuff.

  8. JD says:

    Yes, we too have been receiving NDRs when sending from the 2010 tech preview.  With all of these problems, I’m bemused as to why Outlook 2010 adding more named properties?  Messages send fine from 2007 and 2003.

    Seems like quite a few folk experiencing the problem with Outlook 2010.

  9. xC00000005 says:

    Brian – Yes, there is control for this in a recent rollup.  That doesn’t mean you do not want to know who is consuming what, what your growth rade is, and where the property ids are in use.

    Johnny – I’m well aware this has been a sore subject (I’ve spend more time on named properties and their impact than I can relay in a blog post).  It’s clear that the reason why you are still concerned is that we haven’t communicated Exchange 2007 SP2’s controls for header promotion – SP2 comes with settings that allow an administrator to decide which promotion mode he desires.  Some people will need property promotion, and let consumption be damned.  Some don’t want to lose named properties and don’t want promotion, and some people will be ok with promotion so long as they can monitor consumption.  With SP2, it is your choice.

    Keosaki – If by jetaputil you are indicating that you have removed property mappings, this is a combination of extremely dangerous and funny (in a black humor sort of way).  I cannot ever recommend doing so, and I would recommend to PSS that they not support a database upon which this had been done.

    Kevin  & JD – Consumption due to mail from 2010 is a known issue.  There are new named properties.  IF your mdb was already crowded with properties, you could encounter NDRs until the base set is registered.  In SP2 we pre-register many of the necessary properties.  We can’t "turn back the wheel" and make space for new properties if a database is already very sick but it will prevent many new NDRs.

  10. absolon says:

    My organization have several Exchange 2003 mail stores which have reached the 4 Kb limit assigned to named properties from Outlook. Hence we can’t add new named properties to our custom Outlook forms.

    I have noticed that some of the most recently added named properties are only present in one of the mail stores. Can anyone tell me if this will create problems if the forms is being used by those users whose mailboxes are located in mail stores where the named properties aren’t present?

    And if this isn’t a problem can I work around the limit by adding another mail store and publish the forms as a user whose mailbox is located in the new store, which haven’t reached the limit?

  11. Petri says:

    Can we get any help from E2007 SP2 for more easier way to convert "Linked mailbox" to "User mailbox"? Your recommendation to disable mailbox is not realistic, because in that way we lose all secondary addresses.

Comments are closed.

Skip to main content