We have an Exchange 2007 server with SP1 and Update Rollup 10. A while back, we started getting eventID 9667 errors saying we'd hit the 8192 quota limit for Non-MAPI named properties. Articles on TechNet say that Update Rollup 8 was supposed to remove the function of x-headers from anonymous sources being promoted (we're at 10 so should have that in there). I added an item in the registry for GenerateNamedProperties=0x0 (but later realized that was meant for 2003 so probably is having no effect here). At the same time I bumped up the quota limit to 8392 which caused the 9667 errors to go away for a little while, but now that quota has been reached and the 9667 errors have returned. User impact has actually been minimal. The first incident of someone having a bounced message was brought to our attention today. I'm a little mystified by a few things: 1.) When will Exchange actually bounce a message due to this issue? If I manually telnet to the SMTP port of the server and enter a message to myself with an X-header like X-BogusHeader: 345, I'll see a 9667 error logged in the Event Log, but I'll still receive the message itself. However, a user today tried to send a message, using Outlook, to another user on the server. He has AVG on his machine and it scanned the outgoing message, adding a header called "AVGProcessed". A 9667 (quota of 8392 reached) error was generated for that message and the server bounced it back to him. Why did his message bounce and none of my test messages do? 2.) The afore mentioned user is using Outlook. That's a MAPI client. Why is the Non-Mapi named properties quota being applied to his messages? The only odd ball bit is that he's on a laptop and probably has it configured to use Outlook Anywhere and/or RPC over HTTPS. 3.) Everything I've read says that, short of migrating to Exchange 2010 which we're not prepared to do yet, the "fix" for this issue is to install Service Pack 2 where you can finally just turn off named property promotion entirely. Is that the case? If so, how do you set that? I haven't been able to track down that information. If you *do* turn that off, what happens to an incoming message that has an unknown X-Header? Is it simply delivered without the header (fine by me) or is it rejected?

Hi MinisterOfPropaganda, Possible reasons will cause this issue: · 3rd party software such as spam filtering software which adds X-Headers and those will also get added to the named props table. · These applications may be installed on the Exchange server or even sitting in front of Exchange servers, and hand held device software. It all depends on what we have deployed in the environment and what 3rd party applications are involved in your environment. · Any 3rd party applications which create additional MAPI properties, those properties are also added to the table. · External recipients which send email contains new x-header · Internet span containing unique X-headers So, the only setting we can control or change on exchange server itself is increase the number limit of named properties. There is no other way to clear out this table unless we create a new mailbox store. Related Links Understanding the Impact of Named Property and Replica Identifier Limits on Exchange Databases <http://technet.microsoft.com/en-us/library/bb851492.aspx> How to Configure Named Properties and Replica Identifier Quotas for Exchange 2007 Databases <http://technet.microsoft.com/en-us/library/bb851493.aspx> Events 9666, 9667, 9668, and 9669 Received When Named Properties or Replica Identifiers Are Depleted for An Exchange Database <http://technet.microsoft.com/en-us/library/bb851495.aspx> Regards! Gavin

That's great information, and I've read all the links you provide, but none of it really answers my questions. I *still* have not been able to get Exchange 2007, SP1, with RU 10, to bounce a message due to the quota of Named Properties having been reached. However, I have seen a user get exactly that error. I even recreated the circumstances. I set the quota on a test system database to 200. Sending a message with a previously unmapped X-header resulted in a 9667 error in the log, but the message was delivered just fine. I then installed AVG Anti-Virus on a test system (which is what the user had on his system). When *HE* attempted to send a message, a 9667 error was generated saying the database could not create a named property called "AVGProcessed" and the message was bounced (on our production server). On my test server I sent a message to a user on a database that was at the quota limit (using Outlook, the same as the user who had a problem), and my message went through. In addition, NO 9667 ERROR WAS GENERATED. IN fact, there was an informational message saying that the named property AVGProcessed had been successfully created. Ummmm....what? What could cause this discrepancy? Does the fact that the user with the issue was using RPC over HTTPS have anything to do with it?

The quota is 32,000 per mailbox store. What you are setting is the treshhold when errors will fire in the event logs. You cant actually change the quota itself. http://msexchangeteam.com/archive/2010/07/29/455687.aspx

The quota is 32,000 per mailbox store. What you are setting is the treshhold when errors will fire in the event logs. You cant actually change the quota itself. http://msexchangeteam.com/archive/2010/07/29/455687.aspx Right. I understand that. However, I'm finding that the exchange server will, in certain particular cases which I am trying to determine, bounce messages if that quota has been reached. What I'm trying to figure out is what circumstances will cause it to bounce? And why are messages sent by a MAPI client, being subjected to the *Non-MAPI* named propery quota?

On Mon, 25 Oct 2010 15:56:17 +0000, MinisterOfPropaganda wrote: >That's great information, and I've read all the links you provide, but none of it really answers my questions. I *still* have not been able to get Exchange 2007, SP1, with RU 10, to bounce a message due to the quota of Named Properties having been reached. However, I have seen a user get exactly that error. I even recreated the circumstances. I set the quota on a test system database to 200. Sending a message with a previously unmapped X-header resulted in a 9667 error in the log, but the message was delivered just fine. I then installed AVG Anti-Virus on a test system (which is what the user had on his system). When *HE* attempted to send a message, a 9667 error was generated saying the database could not create a named property called "AVGProcessed" and the message was bounced (on our production server). On my test server I sent a message to a user on a database that was at the quota limit (using Outlook, the same as the user who had a problem), and my message went through. >In addition, NO 9667 ERROR WAS GENERATED. IN fact, there was an informational message saying that the named property AVGProcessed had been successfully created. Ummmm....what? What could cause this discrepancy? Does the fact that the user with the issue was using RPC over HTTPS have anything to do with it? If you're using an authenticated connection then there's a different quota limit. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Mon, 25 Oct 2010 17:00:11 +0000, MinisterOfPropaganda wrote: > > >The quota is 32,000 per mailbox store. What you are setting is the treshhold when errors will fire in the event logs. You cant actually change the quota itself. > > > >http://msexchangeteam.com/archive/2010/07/29/455687.aspx Right. I understand that. However, I'm finding that the exchange server will, in certain particular cases which I am trying to determine, bounce messages if that quota has been reached. What I'm trying to figure out is what circumstances will cause it to bounce? And why are messages sent by a MAPI client, being subjected to the *Non-MAPI* named propery quota? You said you cahnge "the quota limit" to 8392. Did you set separate limits for the "Named Props Quota" (16K default) and "NonMAPI Named Props Quota" (8K default)? Any limits set for "Replids Quota" (8K default)? You say that when you use telnet to sent an e-mail with a X-header the message isn't rejected. Do you have more than one Receive Connector? If so which one was used? Is that connector set with the "Externally Secured" permission? Have you tried that same test using an IP address outside the range set in the InternalSMTPServers value of the get-transportconfig cmdlet? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Mon, 25 Oct 2010 17:00:11 +0000, MinisterOfPropaganda wrote: > > >The quota is 32,000 per mailbox store. What you are setting is the treshhold when errors will fire in the event logs. You cant actually change the quota itself. > > > >http://msexchangeteam.com/archive/2010/07/29/455687.aspx Right. I understand that. However, I'm finding that the exchange server will, in certain particular cases which I am trying to determine, bounce messages if that quota has been reached. What I'm trying to figure out is what circumstances will cause it to bounce? And why are messages sent by a MAPI client, being subjected to the *Non-MAPI* named propery quota? You said you cahnge "the quota limit" to 8392. Did you set separate limits for the "Named Props Quota" (16K default) and "NonMAPI Named Props Quota" (8K default)? Any limits set for "Replids Quota" (8K default)? You say that when you use telnet to sent an e-mail with a X-header the message isn't rejected. Do you have more than one Receive Connector? If so which one was used? Is that connector set with the "Externally Secured" permission? Have you tried that same test using an IP address outside the range set in the InternalSMTPServers value of the get-transportconfig cmdlet? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP The only quota I changed was the "NonMAPI Named Props Quota" in the registry. We have three receive connectors. There is the client one that was installed by default, haven't touched that one and no one is using it to my knowledge (though there isn't necessarily anything preventing them from doing so). There is the default connector which has been modified on the network tab to receive mail from only our internal IP addresses. This one is set for "External Secured". The third one is one that was created called "Authenticated Relay", which has all IP's in it's network tab for receive (i.e. 0.0.0.0-255.255.255.255), but Externally secured turned off and Basic Authentication and integrated windows authentication turned on. Basically, we allow local clients to relay and send mail, but external IP addresses must authenticate in order to relay. In addition, all incoming mail first comes though a barracuda spam firewall before being delivered to the exchange server. Here's a thought. If the Default receive connector is set to "Externally Secured", does that mean that anything coming in on that connector is considered "Authenticated"? Because, since the spam firewall comes from a local IP, that would be...everything.

On Mon, 25 Oct 2010 20:10:50 +0000, MinisterOfPropaganda wrote: >On Mon, 25 Oct 2010 17:00:11 +0000, MinisterOfPropaganda wrote: > > >The quota is 32,000 per mailbox store. What you are setting is the treshhold when errors will fire in the event logs. You cant actually change the quota itself. > > > >http://msexchangeteam.com/archive/2010/07/29/455687.aspx Right. I understand that. However, I'm finding that the exchange server will, in certain particular cases which I am trying to determine, bounce messages if that quota has been reached. What I'm trying to figure out is what circumstances will cause it to bounce? And why are messages sent by a MAPI client, being subjected to the *Non-MAPI* named propery quota? You said you cahnge "the quota limit" to 8392. Did you set separate limits for the "Named Props Quota" (16K default) and "NonMAPI Named Props Quota" (8K default)? Any limits set for "Replids Quota" (8K default)? You say that when you use telnet to sent an e-mail with a X-header the message isn't rejected. Do you have more than one >Receive Connector? If so which one was used? Is that connector set with the "Externally Secured" permission? Have you tried that same test using an IP address outside the range set in the InternalSMTPServers value of the get-transportconfig cmdlet? --- Rich Matheisen MCSE+I, Exchange MVP >--- Rich Matheisen MCSE+I, Exchange MVP > >The only quota I changed was the "NonMAPI Named Props Quota" in the registry. > >We have three receive connectors. There is the client one that was installed by default, haven't touched that one and no one is using it to my knowledge (though there isn't necessarily anything preventing them from doing so). There is the default connector which has been modified on the network tab to receive mail from only our internal IP addresses. This one is set for "External Secured". So anything you send to that connector is considered to be an authenticaed connection and bypasses all the anti-spam checks and is treated as an authenticated connection. >The third one is one that was created called "Authenticated Relay", which has all IP's in it's network tab for receive (i.e. 0.0.0.0-255.255.255.255), but Externally secured turned off and Basic Authentication and integrated windows authentication turned on. Basically, we allow local clients to relay and send mail, but external IP addresses must authenticate in order to relay. In addition, all incoming mail first comes though a barracuda spam firewall before being delivered to the exchange server. When you look at the SMTP receive protocol log, which connector is that anti-spam appliance using? Why would there ever be any "external IP addresses" delivering e-mail to your Hub Transport server? >Here's a thought. If the Default receive connector is set to "Externally Secured", does that mean that anything coming in on that connector is considered "Authenticated"? Because, since the spam firewall comes from a local IP, that would be...everything. That's why I asked about it. :-) Set up another Receive Connector just for the IP address of that anti-spam appliance and just allow anonymous connections on the connector. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Mon, 25 Oct 2010 20:10:50 +0000, MinisterOfPropaganda wrote: When you look at the SMTP receive protocol log, which connector is that anti-spam appliance using? Why would there ever be any "external IP addresses" delivering e-mail to your Hub Transport server? >Here's a thought. If the Default receive connector is set to "Externally Secured", does that mean that anything coming in on that connector is considered "Authenticated"? Because, since the spam firewall comes from a local IP, that would be...everything. That's why I asked about it. :-) Set up another Receive Connector just for the IP address of that anti-spam appliance and just allow anonymous connections on the connector. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP I checked and, of course, logging isn't turned on for those connectors. I'll turn it on and verify that the spam appliance is using that connector but I'm pretty positive it is. I like the idea of creating a new connector just for the spam firewall. The purpose of the "Authenticated Relay" connector is for users who are off site to be able to connect and use TLS/SMTP Authentication to send out mail.

I turned the logging on for the Default connector (briefly, yikes that log fills up scary fast) and, indeed, the spam appliance is using that connector. So I sat down to test the idea of creating a separate, anonymous connector just for the spam firewall on my test system. I created a connector that was set to anonymous, with no authentication and set the receive network portion to be JUST a single IP of another test system. I then connected from that test system and sent an email message with a bogus, previously unseen X header. The SMTP logs showed my connection has having used this new anonymous header, but the exchange server *STILL* tried to promote the X-header to a named property... And of course, the message was delivered despite the 9667 error. That's the other thing I'm having the most difficulty trying to figure out: why does the server NDR some messages when it can't promote a Named Property, but not others??

I turned the logging on for the Default connector (briefly, yikes that log fills up scary fast) and, indeed, the spam appliance is using that connector. So I sat down to test the idea of creating a separate, anonymous connector just for the spam firewall on my test system. I created a connector that was set to anonymous, with no authentication and set the receive network portion to be JUST a single IP of another test system. I then connected from that test system and sent an email message with a bogus, previously unseen X header. The SMTP logs showed my connection has having used this new anonymous header, but the exchange server *STILL* tried to promote the X-header to a named property... And of course, the message was delivered despite the 9667 error. That's the other thing I'm having the most difficulty trying to figure out: why does the server NDR some messages when it can't promote a Named Property, but not others?? I dont know if I have answer for all scenarios, but when I have seen messages actually bounced, it turned out that Exchange 2007 was on the backend and Outlook 2010 was the client. ( The same message would go through successfully when the client was Outlook 2007).

On Tue, 26 Oct 2010 14:17:58 +0000, MinisterOfPropaganda wrote: >I turned the logging on for the Default connector (briefly, yikes that log fills up scary fast) You can tell the transport server how long to keep the log files, how big you want the set ot log files to become, etc. It's a good idea to keep the logging enabled. >and, indeed, the spam appliance is using that connector. So I sat down to test the idea of creating a separate, anonymous connector just for the spam firewall on my test system. I created a connector that was set to anonymous, with no authentication and set the receive network portion to be JUST a single IP of another test system. I then connected from that test system and sent an email message with a bogus, previously unseen X header. The SMTP logs showed my connection has having used this new anonymous header, but the exchange server *STILL* tried to promote the X-header to a named property... And of course, the message was delivered despite the 9667 error. That's the other thing I'm having the most difficulty trying to figure out: why does the server NDR some messages when it can't promote a Named Property, but not others?? I'm afraid the the only peole that can answer that question definitively are those with access to the source code. The rest of us, like you, are left to puzzle it all out and just speculate on "the way things work". FYI, the header filter agent (http://headerfilteragent.codeplex.com) should still work. If you have a list of the X-headers you want to allow, it isn't hard to add the agent and the data to the registry. After that the unwanted headers will simply be removed from the message before it reaches the store. It's a bit more work but a heckuva lot more control. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

In other words, "Pay for some support buddy!" :) I hear ya though. Service Pack 2 supposedly gives you the ability to flat out turn off the named property promotion so I'll look at that on my test system as well as the headerfilteragent. I knew about that agent, but hadn't really looked too deeply at it because their main page says that their product became unnecessary with Update Rollup 8 so I was concerned that no one was maintaining it anymore. I don't like running unmaintained packages on a production system so I see that as a last resort.

On Wed, 27 Oct 2010 12:16:04 +0000, MinisterOfPropaganda wrote: >In other words, "Pay for some support buddy!" :) I hear ya though. More like "talk to the people that wrote it". :-) >Service Pack 2 supposedly gives you the ability to flat out turn off the named property promotion so I'll look at that on my test system as well as the headerfilteragent. I knew about that agent, but hadn't really looked too deeply at it because their main page says that their product became unnecessary with Update Rollup 8 so I was concerned that no one was maintaining it anymore. I don't like running unmaintained packages on a production system so I see that as a last resort. It's just a small C# project. IIRC the code's less than a single page. Go have a look. You may not want (or be able to) drop all X-headers. Some of them are needed to interpret the messages content. Some of them actually contain useful information. Others are just useless noise. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Ah. In that case I'll take a look. I have put SP2 on my test system, which apparently sets the HeaderPromotionSetting to "NoCreate" by default. That certainly worked as expected. Changing that to "MayCreate" brought me back to my current situation which is all headers, regardless of being anonymous or not, were getting promoted. So it seems my choices are either don't promote headers at all or use the filter. Quite frankly, though, this issue has been going on for quite a while, with no headers being promoted at all due to the quota limit and no one has encountered any problems. The only reason I'm investigating this is because we ran in to a message that was bounced. If SP2 and turning off header promotion will prevent mail bouncing, then I'm fine with that. I can always tweak that setting later if we absolutely need to get something promoted.

On Wed, 27 Oct 2010 12:16:04 +0000, MinisterOfPropaganda wrote: >In other words, "Pay for some support buddy!" :) I hear ya though. More like "talk to the people that wrote it". :-) >Service Pack 2 supposedly gives you the ability to flat out turn off the named property promotion so I'll look at that on my test system as well as the headerfilteragent. I knew about that agent, but hadn't really looked too deeply at it because their main page says that their product became unnecessary with Update Rollup 8 so I was concerned that no one was maintaining it anymore. I don't like running unmaintained packages on a production system so I see that as a last resort. It's just a small C# project. IIRC the code's less than a single page. Go have a look. You may not want (or be able to) drop all X-headers. Some of them are needed to interpret the messages content. Some of them actually contain useful information. Others are just useless noise. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP And dont forget Sharepoint alerts! You'll need to whitelist the custom x-headers it uses! BTDT :P