ATTN: Rich Matheisen [MVP] and/or Andy David {MVP}
in [Microsoft Exchange]
|
From: Andy David {MVP} on 30 Jun 2008 14:07 On Mon, 30 Jun 2008 10:53:36 -0600, "Hunter Coleman" <glacialtill(a)yahoo.com> wrote: >> 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." Reboot! Hows it going Hunter? Long time.
From: Hunter Coleman on 30 Jun 2008 18:34 LOL. It was going great until two of our stores filled up the mapiNamedProperty table. Hey, DEC added Exchange stuff to become TEC. Almost like MEC. Y'all should go...http://www.directoryexpertsconference.com/ "Andy David {MVP}" <adavid(a)pleasekeepinngcheesebucket.com> wrote in message news:968i64prfmokdf8koi3isqugvltmhk4o02(a)4ax.com... > On Mon, 30 Jun 2008 10:53:36 -0600, "Hunter Coleman" > <glacialtill(a)yahoo.com> wrote: > >>> 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." > > > Reboot! > > Hows it going Hunter? Long time. >
From: Andy David {MVP} on 30 Jun 2008 21:28 On Mon, 30 Jun 2008 16:34:20 -0600, "Hunter Coleman" <glacialtill(a)yahoo.com> wrote: >LOL. It was going great until two of our stores filled up the >mapiNamedProperty table. > >Hey, DEC added Exchange stuff to become TEC. Almost like MEC. Y'all should >go...http://www.directoryexpertsconference.com/ > Interact 2008 in San Diego was pretty good and MEC like as well! > >"Andy David {MVP}" <adavid(a)pleasekeepinngcheesebucket.com> wrote in message >news:968i64prfmokdf8koi3isqugvltmhk4o02(a)4ax.com... >> On Mon, 30 Jun 2008 10:53:36 -0600, "Hunter Coleman" >> <glacialtill(a)yahoo.com> wrote: >> >>>> 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." >> >> >> Reboot! >> >> Hows it going Hunter? Long time. >>
From: dwatson80 on 2 Jul 2008 18:24 I am dealing with this same problem of Named Properties. Here is what I don't understand - If the only solution is to move mailboxes to a new store, which effectively clears the database/named props table, why not just build that functionality into Exchange, a rolling database. Instead of "I'm going to store every single named property until I blow up somewhere around 32,000". Why not "I'll store the first 10,000 I receive and then every named property after that insert at the top of the list and the bottom one gets deleted" - Problem solved "Hunter Coleman" wrote: > > 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 > >> >
From: Rich Matheisen [MVP] on 2 Jul 2008 21:12
On Wed, 2 Jul 2008 15:24:01 -0700, dwatson80 <dwatson80(a)discussions.microsoft.com> wrote: >I am dealing with this same problem of Named Properties. Here is what I >don't understand - If the only solution is to move mailboxes to a new store, >which effectively clears the database/named props table, why not just build >that functionality into Exchange, a rolling database. > >Instead of "I'm going to store every single named property until I blow up >somewhere around 32,000". >Why not "I'll store the first 10,000 I receive and then every named property >after that insert at the top of the list and the bottom one gets deleted" - >Problem solved What if the named properties are still in messages in the database? Moving all the mailboxes doesn't "fix" anything if the messages with the named properties are still in the mailboxes. --- Rich Matheisen MCSE+I, Exchange MVP |