From: dwatson80 on
Aaaa HA!!!!
So if people are hanging onto the thousands of emails that get sent to their
Junk E-mail folder, that could be why my test of moving mailboxes between two
databases didn't do anything. I will do some more testing, making sure Junk
E-Mail folders are cleared out and then move mailboxes.

Since Named Properties are for the entire database...there isn't a way to
find which mailboxes have the messages associated with the named props, is
there?

"Rich Matheisen [MVP]" wrote:

> 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
>
From: dwatson80 on
So in the Microsoft document:
http://technet.microsoft.com/en-us/library/bb851495(EXCHG.80).aspx
They don't say anything about having to delete or remove the messages that
contain the named properties. So if the mailboxes still contain the same
messages as when you are at 20,000 named properties, and you perform the
following steps, you will still end up at 20,000 named properties?

Create a new mailbox database on the same server or a different Exchange
server with the Mailbox server role installed.
Move all mailboxes from the database you need to recover to the new mailbox
database.
On the Exchange server that has the mailbox database you need to recover, do
the following:
Dismount the mailbox database you need to recover.
Delete the database file that corresponds to the mailbox database you need
to recover.
Mount the mailbox database. This creates a blank database file for the
mailbox database.
Move all the mailboxes back to the recovered blank mailbox database.



"dwatson80" wrote:

> Aaaa HA!!!!
> So if people are hanging onto the thousands of emails that get sent to their
> Junk E-mail folder, that could be why my test of moving mailboxes between two
> databases didn't do anything. I will do some more testing, making sure Junk
> E-Mail folders are cleared out and then move mailboxes.
>
> Since Named Properties are for the entire database...there isn't a way to
> find which mailboxes have the messages associated with the named props, is
> there?
>
> "Rich Matheisen [MVP]" wrote:
>
> > 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
> >
From: Rich Matheisen [MVP] on
On Wed, 2 Jul 2008 22:58:00 -0700, dwatson80
<dwatson80(a)discussions.microsoft.com> wrote:

>So in the Microsoft document:
>http://technet.microsoft.com/en-us/library/bb851495(EXCHG.80).aspx
>They don't say anything about having to delete or remove the messages that
>contain the named properties.

They're assuming that messages are being deleted from the database.
It's not a bad assumption, but it's not a given.

>So if the mailboxes still contain the same
>messages as when you are at 20,000 named properties, and you perform the
>following steps, you will still end up at 20,000 named properties?

Yes, you do. The properties are still present in the messages being
move so the named properties are recreated (with different named
property values because they aren't going to be created in the same
sequence) in the target database.

>Create a new mailbox database on the same server or a different Exchange
>server with the Mailbox server role installed.
>Move all mailboxes from the database you need to recover to the new mailbox
>database.
>On the Exchange server that has the mailbox database you need to recover, do
>the following:
>Dismount the mailbox database you need to recover.
>Delete the database file that corresponds to the mailbox database you need
>to recover.
>Mount the mailbox database. This creates a blank database file for the
>mailbox database.
>Move all the mailboxes back to the recovered blank mailbox database.

Moving the mailboxes back doesn't make a lot of sense, does it?
---
Rich Matheisen
MCSE+I, Exchange MVP
From: jim on
I'm not sure what i'd be looking for in the headers. In any event, we've
tried it with multiple external addresses, domains, and email systems, so i
seriously doubt that the all of the headers can be described as odd-ball.
The only commonality is this one Exchange MB in our organization. It's not
happening to any other MB's in that database by the way.

The solution sounds terrible. Move all MB's to a new store??


"Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message
news:b0pc64tndg5fbcqv1v8s4hh3bdfa0t60k7(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.
>
> 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: Rich Matheisen [MVP] on
On Wed, 9 Jul 2008 09:52:56 -0400, "jim" <jim(a)nospam.com> wrote:

>I'm not sure what i'd be looking for in the headers.

Usually headers that begin with "X-".

>In any event, we've
>tried it with multiple external addresses, domains, and email systems, so i
>seriously doubt that the all of the headers can be described as odd-ball.

"Odd-ball" just refers to out of the ordinary.

>The only commonality is this one Exchange MB in our organization. It's not
>happening to any other MB's in that database by the way.

That's because you reached the maximum number of named properties in
that database. It just hasn't happened in the other databases -- yet.

>The solution sounds terrible. Move all MB's to a new store??

Assuming the original emails are no longer in the database that'll
work. If you look at a worst case situation, the target database will
already have close to the maximum number of named properties and your
moving messages to it will result in the same failure before you move
all the mailboxes to it.

The "solution" is a band-aid, and there's no guarranty that it'll work
for you unless the target database is emty at the start and receives
no new messages during the move.
---
Rich Matheisen
MCSE+I, Exchange MVP