ATTN: Rich Matheisen [MVP] and/or Andy David {MVP}
in [Microsoft Exchange]
|
From: Andy David {MVP} on 28 Jun 2008 10:27 On Sat, 28 Jun 2008 10:20:31 -0400, "jim" <jim(a)nospam.com> wrote: >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. > Let us know what they tell you :) >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 >
From: Rich Matheisen [MVP] on 28 Jun 2008 12:16 On Sat, 28 Jun 2008 08:51:54 -0400, Andy David {MVP} <adavid(a)pleasekeepinngcheesebucket.com> wrote: >>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. That might delay the onset of the problem, but if it's just one mailbox in the database that's receiving all those headers you won't be able to get any smaller than that! --- Rich Matheisen MCSE+I, Exchange MVP
From: Rich Matheisen [MVP] on 28 Jun 2008 12:20 On Sat, 28 Jun 2008 10:20:31 -0400, "jim" <jim(a)nospam.com> wrote: >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. It makes a lot of sense! The messages that are successful don't contain some odd-ball header that adds to the number of named properties in the database. The ones that fail have some unique header that requires adding another named property to the database. Can you capture some of these messages before they hit your store and see what's in the headers? --- Rich Matheisen MCSE+I, Exchange MVP
From: Andy David {MVP} on 28 Jun 2008 12:26 On Sat, 28 Jun 2008 12:16:47 -0400, "Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote: >On Sat, 28 Jun 2008 08:51:54 -0400, Andy David {MVP} ><adavid(a)pleasekeepinngcheesebucket.com> wrote: > >>>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. > >That might delay the onset of the problem, but if it's just one >mailbox in the database that's receiving all those headers you won't >be able to get any smaller than that! Oh yea, I know :P >--- >Rich Matheisen >MCSE+I, Exchange MVP
From: Hunter Coleman on 30 Jun 2008 12:53
> Let us know what they tell you :) I'm waiting for "close port 25 on your firewall." It would be right up there with "move all of the mailboxes to a new store." -- Hunter "Andy David {MVP}" <adavid(a)pleasekeepinngcheesebucket.com> wrote in message news:ghic64h4qa60clap0e2n8ccvease332cfj(a)4ax.com... > On Sat, 28 Jun 2008 10:20:31 -0400, "jim" <jim(a)nospam.com> wrote: > >>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. >> > > Let us know what they tell you :) > > >>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 >> |