ATTN: Rich Matheisen [MVP] and/or Andy David {MVP}
in [Microsoft Exchange]
|
From: jim on 27 Jun 2008 13:42 Sorry to call you guys out like that, but you had been helping with this issue previously... We started getting the "MapiExceptionNamedPropsQuotaExceeded" again (see original message below.) The way we resolved it last time was by moving mailboxes back and fourth between different storage groups. At that time the emails were coming from a single source, a custom app that emailed calender events to employees that added vacation schedules to their Outlook calendar. Now it's happening with a single mailbox when an external person tries replying to a meesting request sent from this mailbox. I've tested with several external accounts, and they all get the "MapiExceptionNamedPropsQuotaExceeded" error after sending the acceptance to the originating mailbox. This originating mailbox never receives the response. I've tried moving the mailbox between storage groups as before, as well as moving other mailboxes to and from the original store. None of it has helped. Considering that it's happening on all the external accounts we've tested it against (all different domains), i don't think it's a problem with the senders message (i.e. there 'meeting accepted' response.) I'm running out of ideas short of calling MS support. Any thoughts? Thanks, and again, sorry for calling you guys out specifically. jim ORGINAL MESSAGE: One of our developers is setting up a system whereby when an employee makes a vacation request on our intranet, the approval is emailed to the user along with a calendar item they can add to their Outlook calendar (an .ics file). She's using ColdFusion with a java script that does the actual emailing. Shortly after she started testing it, the messages stopped being delivered. I tracked the failed messages and they're all coming up with this error: 550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: "MapiExceptionNamedPropsQuotaExceeded" I found a technet article that describes how to increase 'Named Properties' quota, but it doesn't seem to be recommended by Microsoft as a good solution. It's far better to fix the application that's using Exchange than to manipulate Exchange to accommodate the app. That said, how can i determine the number of named properties she's sending so that she can adjust them on her end? Is there some logging i need to turn up on the MB server? We're entirely Ex2k7 SP1, rollup 2. Here's the full error if that helps: 550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: "MapiExceptionNamedPropsQuotaExceeded:16.18969:BE000000, 17.27161:00000000D4000000000000000000000000000000, 255.23226:31000000, 255.27962:7A000000, 255.27962:56000000, 255.17082:00090480, 0.16993:80030400, 4.21921:00090480, 255.27962:FA000000, 255.1494:00000000, 255.26426:56000000, 4.6363:0F010480, 2.31229:00000000, 4.6363:0F010480, 2.17597:00000000, 2.22787:00000000, 2.22787:00000000, 2.22957:00000000, 2.19693:00000000, 2.17917:00000000, 2.27341:00000000, 2.22787:00000000, 4.5415:00090480, 4.7867:00090480, 4.4475:00090480, 4.4603:00090480, 4.5323:00090480, 255.1750:00000000, 0.26849:2F000000, 255.21817:00090480, 0.24529:00000000, 4.18385:00090480".
From: Rich Matheisen [MVP] on 27 Jun 2008 21:41 On Fri, 27 Jun 2008 13:42:18 -0400, "jim" <jim(a)nospam.com> wrote: >Sorry to call you guys out like that, but you had been helping with this >issue previously... > >We started getting the "MapiExceptionNamedPropsQuotaExceeded" again (see >original message below.) The way we resolved it last time was by moving >mailboxes back and fourth between different storage groups. At that time >the emails were coming from a single source, a custom app that emailed >calender events to employees that added vacation schedules to their Outlook >calendar. Now it's happening with a single mailbox when an external person >tries replying to a meesting request sent from this mailbox. I've tested >with several external accounts, and they all get the >"MapiExceptionNamedPropsQuotaExceeded" error after sending the acceptance to >the originating mailbox. This originating mailbox never receives the >response. > >I've tried moving the mailbox between storage groups as before, as well as >moving other mailboxes to and from the original store. None of it has >helped. Considering that it's happening on all the external accounts we've >tested it against (all different domains), i don't think it's a problem with >the senders message (i.e. there 'meeting accepted' response.) > >I'm running out of ideas short of calling MS support. Any thoughts? > >Thanks, and again, sorry for calling you guys out specifically. The number of named properties is not associated with a single mailbox, but with the entire database. If there's only one mailbox in the database, and all the original messages are still in the mailbox, then moving the mailbox to another dataase will just create those named properties in the target datagbase and you're right back in the same mess. The way to get out of the situation is to remove the messages from the database and then move the mailbox(es). The way to prevent the problem is to remove those headers from the message before they get to the mailbox (or public folder) database. The only way, with Exchange 2007, that I know of would be to write a transport rule that removed all the offending headers (I'm assuming that they're X- headers) as they pass through the hub transport servers. Raising the maximum number of named properties on a database will just lenghten the time between fixing the problem and the next occurence of the problem. It's not a fix. I can't advise you on calling PSS, though. I know I'd call them if it were me. But they aren't going to be able to fix the problem, although they'll help you get through the situation you're in now. Only a change in the (I think) ill-advised assigning of a named property to every header will fix this problem. --- Rich Matheisen MCSE+I, Exchange MVP
From: andy webb on 28 Jun 2008 02:27 But do, please, call and open a case to give more weight to it getting fixed. "Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message news:vt4b64hpg3abmma614pgbtnnho4chukfbn(a)4ax.com... > On Fri, 27 Jun 2008 13:42:18 -0400, "jim" <jim(a)nospam.com> wrote: > >>Sorry to call you guys out like that, but you had been helping with this >>issue previously... >> >>We started getting the "MapiExceptionNamedPropsQuotaExceeded" again (see >>original message below.) The way we resolved it last time was by moving >>mailboxes back and fourth between different storage groups. At that time >>the emails were coming from a single source, a custom app that emailed >>calender events to employees that added vacation schedules to their >>Outlook >>calendar. Now it's happening with a single mailbox when an external >>person >>tries replying to a meesting request sent from this mailbox. I've tested >>with several external accounts, and they all get the >>"MapiExceptionNamedPropsQuotaExceeded" error after sending the acceptance >>to >>the originating mailbox. This originating mailbox never receives the >>response. >> >>I've tried moving the mailbox between storage groups as before, as well as >>moving other mailboxes to and from the original store. None of it has >>helped. Considering that it's happening on all the external accounts >>we've >>tested it against (all different domains), i don't think it's a problem >>with >>the senders message (i.e. there 'meeting accepted' response.) >> >>I'm running out of ideas short of calling MS support. Any thoughts? >> >>Thanks, and again, sorry for calling you guys out specifically. > > The number of named properties is not associated with a single > mailbox, but with the entire database. If there's only one mailbox in > the database, and all the original messages are still in the mailbox, > then moving the mailbox to another dataase will just create those > named properties in the target datagbase and you're right back in the > same mess. > > The way to get out of the situation is to remove the messages from the > database and then move the mailbox(es). > > The way to prevent the problem is to remove those headers from the > message before they get to the mailbox (or public folder) database. > The only way, with Exchange 2007, that I know of would be to write a > transport rule that removed all the offending headers (I'm assuming > that they're X- headers) as they pass through the hub transport > servers. > > Raising the maximum number of named properties on a database will just > lenghten the time between fixing the problem and the next occurence of > the problem. It's not a fix. > > I can't advise you on calling PSS, though. I know I'd call them if it > were me. But they aren't going to be able to fix the problem, although > they'll help you get through the situation you're in now. Only a > change in the (I think) ill-advised assigning of a named property to > every header will fix this problem. > --- > Rich Matheisen > MCSE+I, Exchange MVP
From: Andy David {MVP} on 28 Jun 2008 08:51 On Fri, 27 Jun 2008 21:41:06 -0400, "Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote: >On Fri, 27 Jun 2008 13:42:18 -0400, "jim" <jim(a)nospam.com> wrote: > >>Sorry to call you guys out like that, but you had been helping with this >>issue previously... >> >>We started getting the "MapiExceptionNamedPropsQuotaExceeded" again (see >>original message below.) The way we resolved it last time was by moving >>mailboxes back and fourth between different storage groups. At that time >>the emails were coming from a single source, a custom app that emailed >>calender events to employees that added vacation schedules to their Outlook >>calendar. Now it's happening with a single mailbox when an external person >>tries replying to a meesting request sent from this mailbox. I've tested >>with several external accounts, and they all get the >>"MapiExceptionNamedPropsQuotaExceeded" error after sending the acceptance to >>the originating mailbox. This originating mailbox never receives the >>response. >> >>I've tried moving the mailbox between storage groups as before, as well as >>moving other mailboxes to and from the original store. None of it has >>helped. Considering that it's happening on all the external accounts we've >>tested it against (all different domains), i don't think it's a problem with >>the senders message (i.e. there 'meeting accepted' response.) >> >>I'm running out of ideas short of calling MS support. Any thoughts? >> >>Thanks, and again, sorry for calling you guys out specifically. > >The number of named properties is not associated with a single >mailbox, but with the entire database. If there's only one mailbox in >the database, and all the original messages are still in the mailbox, >then moving the mailbox to another dataase will just create those >named properties in the target datagbase and you're right back in the >same mess. > >The way to get out of the situation is to remove the messages from the >database and then move the mailbox(es). > >The way to prevent the problem is to remove those headers from the >message before they get to the mailbox (or public folder) database. Man, having this problem with a pf database would really bite. >The only way, with Exchange 2007, that I know of would be to write a >transport rule that removed all the offending headers (I'm assuming >that they're X- headers) as they pass through the hub transport >servers. And IIRC, your own option with a rule is to delete the entire header based on the existance of the text string "x-" or something equivalent. > >Raising the maximum number of named properties on a database will just >lenghten the time between fixing the problem and the next occurence of >the problem. It's not a fix. Another "not a fix", but may help going forward in planning is to create "smaller databases" and spread them out more across more SGs. > >I can't advise you on calling PSS, though. I know I'd call them if it >were me. But they aren't going to be able to fix the problem, although >they'll help you get through the situation you're in now. Only a >change in the (I think) ill-advised assigning of a named property to >every header will fix this problem. Yea, call them. >--- >Rich Matheisen >MCSE+I, Exchange MVP
From: jim on 28 Jun 2008 10:20
Ugh. The offending messages are only coming from external addresses, and only for 'meeting request accepted' replies. Like i said, it doesn't seem to matter which external account, external domain, or external client is sending the meeting acceptance reply. They all get the named props error from our system. Straight emails between the two addresses are fine. They can reply to each other over and over again without issue. As well, meeting acceptance replies sent from internal accounts are fine. This makes no sense. I think i may have to call MS Support on this one. It seems silly to make us re-architect our SG's to fix the problem. Oh well. Thanks for the input guys. I greatly appreciate it. jim "Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message news:vt4b64hpg3abmma614pgbtnnho4chukfbn(a)4ax.com... > On Fri, 27 Jun 2008 13:42:18 -0400, "jim" <jim(a)nospam.com> wrote: > >>Sorry to call you guys out like that, but you had been helping with this >>issue previously... >> >>We started getting the "MapiExceptionNamedPropsQuotaExceeded" again (see >>original message below.) The way we resolved it last time was by moving >>mailboxes back and fourth between different storage groups. At that time >>the emails were coming from a single source, a custom app that emailed >>calender events to employees that added vacation schedules to their >>Outlook >>calendar. Now it's happening with a single mailbox when an external >>person >>tries replying to a meesting request sent from this mailbox. I've tested >>with several external accounts, and they all get the >>"MapiExceptionNamedPropsQuotaExceeded" error after sending the acceptance >>to >>the originating mailbox. This originating mailbox never receives the >>response. >> >>I've tried moving the mailbox between storage groups as before, as well as >>moving other mailboxes to and from the original store. None of it has >>helped. Considering that it's happening on all the external accounts >>we've >>tested it against (all different domains), i don't think it's a problem >>with >>the senders message (i.e. there 'meeting accepted' response.) >> >>I'm running out of ideas short of calling MS support. Any thoughts? >> >>Thanks, and again, sorry for calling you guys out specifically. > > The number of named properties is not associated with a single > mailbox, but with the entire database. If there's only one mailbox in > the database, and all the original messages are still in the mailbox, > then moving the mailbox to another dataase will just create those > named properties in the target datagbase and you're right back in the > same mess. > > The way to get out of the situation is to remove the messages from the > database and then move the mailbox(es). > > The way to prevent the problem is to remove those headers from the > message before they get to the mailbox (or public folder) database. > The only way, with Exchange 2007, that I know of would be to write a > transport rule that removed all the offending headers (I'm assuming > that they're X- headers) as they pass through the hub transport > servers. > > Raising the maximum number of named properties on a database will just > lenghten the time between fixing the problem and the next occurence of > the problem. It's not a fix. > > I can't advise you on calling PSS, though. I know I'd call them if it > were me. But they aren't going to be able to fix the problem, although > they'll help you get through the situation you're in now. Only a > change in the (I think) ill-advised assigning of a named property to > every header will fix this problem. > --- > Rich Matheisen > MCSE+I, Exchange MVP |