Prev: 0X8004010F
Next: Outlook Web Access - Password Expired
From: Phil McNeill on 27 Nov 2009 10:09
Came in this morning to a helpdesk call indicating that the user was getting
the following message when trying to open their Outlook 2007 client:

"Cannot open your default e-mail folders. Microsoft Exchange is not
available. Either there are network problems or the Exchange computer is
down for maintenance."

In my Exchange server Application Log I see several instances of the
following related to the affected user's mailbox:

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9646
Date: 11/27/2009
Time: 7:07:14 AM
User: N/A
Computer: PAGE
Description:
Mapi session "/O=Hydro Ottawa/OU=Albion/cn=Recipients/cn=jenniferr" exceeded
the maximum of 32 objects of type "session".

These two things lead me to this KB article about multiple MAPI sessions, or
cached mode in Outlook 2007 causing us grief:

http://support.microsoft.com/kb/842022

Tried the fix there related to cached mode, and it didn't pan out. Then
compared the user's permissions to their own mailbox with that of several
other users and noticed she wasn't explicitly assigned any permission to her
own mailbox. I see the SELF group there, but not her user account. Then I
start looking at other user's accounts and see that some of them have the
SELF group, and some of them have their user account assigned with Read
access and Full Mailbox access.

Anyway, even though she had SELF, as per a portion of my users, she still
couldn't gain access to her mailbox. Once I added her account explicitly,
she could.

So, my questions are:

1. What is the SELF group, and is that what users are supposed to gain
access to their mailboxes with?

2. Any idea why out of the 700 mailboxes we have, some have a permissions
entry for SELF in ADUC, and some have their username explicitly? Presumably
we are doing something to cause the difference?

Thanks!

Outlook 2007 clients
Exchange 2003 SP1


From: Rich Matheisen [MVP] on 27 Nov 2009 11:56
On Fri, 27 Nov 2009 10:09:28 -0500, "Phil McNeill"
<philmcneill(a)REMOVETEXTINCAPShydroottawa.com> wrote:

[ snip ]

>Tried the fix there related to cached mode, and it didn't pan out. Then
>compared the user's permissions to their own mailbox with that of several
>other users and noticed she wasn't explicitly assigned any permission to her
>own mailbox. I see the SELF group there, but not her user account. Then I
>start looking at other user's accounts and see that some of them have the
>SELF group, and some of them have their user account assigned with Read
>access and Full Mailbox access.

Only SELF should be necessary. The "Read permissions" and "Full
mailbox access" are sufficient. If the "Everyone" group has inherited
the "Read permissions" then SELF doesn't nned it (but it won't hurt
anything to have it).

FYI, "Read permissions" doesn't mean "Permission to read the cpntents
of the mailbox", it means "allowed to read the mailbox's permissions".

>Anyway, even though she had SELF, as per a portion of my users, she still
>couldn't gain access to her mailbox. Once I added her account explicitly,
>she could.

It wouldn't be the 1st time I've seen a mismatch between the
permission on the mailbox and the permission the ADUC displayed.
Instead of adding the user account to the mailbox it's sometimes
enough to force the ADUC to rewrite the permission on the mailbox. I
usually do that by giving the SELF account the "Associated external
access" permission and clicking OK enough times to completely close
the ADUC property page for the user. Then go back and remove the AEA
permission and completely close the property pages. That usually sets
things right.

The larger concern is why there are so many open sessions from the
client. If they're using VPN or wireless connection it could be that
the connections is poor and they're abruptly disconnected and then
reconnected (moving between WiFi access points can be a killer).
That'll leave a TCP session open for up to two hours before it's
cleaned up. You can help with this by setting the TCP keep-alive time
to 5 minutes instead of the default 2 hours.

>So, my questions are:
>
>1. What is the SELF group, and is that what users are supposed to gain
>access to their mailboxes with?

SELF is a special object (and SID) that refers to the account to which
the mailbox is assigned. IOW, it's self referential.

>2. Any idea why out of the 700 mailboxes we have, some have a permissions
>entry for SELF in ADUC, and some have their username explicitly? Presumably
>we are doing something to cause the difference?

Is this an organization that's never upgraded Exchange? The presence
of the user's account in the permissions is usually a sign of previous
migrations/upgrades or of people mistakenly putting the account into
the permissions. The expected (and usual) situation is that there's
only the SELF account with "Full Mailbox Access".

However (there's always one of those!) there are situations where the
account is needed, but not on the mailbox permissions. One of those is
when the person's using POP3 or IMAP4 and trying to send an email.
Sometimes it's necessary to give the account "Send As" permission.

You should be safe removing the account and making sure SELF is
assigned the necessary permission on the mailbox.
---
Rich Matheisen
MCSE+I, Exchange MVP
From: Phil McNeill on 27 Nov 2009 12:30
Thanks for the reply Rich. There are mailboxes on this system that would
have been migrated from an Exchange 5.5 environment 5 or 6 years ago, and
then again from one 2003 server to another 2003 server 2-3 years ago. Then
of course there are other mailboxes that have been created at various times
over the course of that entire time period. Perhaps that's the difference?

Anyway, thanks for the reply. I should have thought of the "permissions
reboot" option, as I've done that many times before when public folder
access wasn't working in practice the way the permissions tree said it
should be. In effect I guess I did do that. Just didn't need the new
account involved.

With the regard to the TCP keep-alives you were talking about, did you mean
keep alives specifically to the Exchange server, or Windows? Registry
setting for that?

Thanks much for the info,

Phil

"Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message
news:pgvvg5dk0b61jatpormdhs32pc1forl9ch(a)4ax.com...
> On Fri, 27 Nov 2009 10:09:28 -0500, "Phil McNeill"
> <philmcneill(a)REMOVETEXTINCAPShydroottawa.com> wrote:
>
> [ snip ]
>
>>Tried the fix there related to cached mode, and it didn't pan out. Then
>>compared the user's permissions to their own mailbox with that of several
>>other users and noticed she wasn't explicitly assigned any permission to
>>her
>>own mailbox. I see the SELF group there, but not her user account. Then
>>I
>>start looking at other user's accounts and see that some of them have the
>>SELF group, and some of them have their user account assigned with Read
>>access and Full Mailbox access.
>
> Only SELF should be necessary. The "Read permissions" and "Full
> mailbox access" are sufficient. If the "Everyone" group has inherited
> the "Read permissions" then SELF doesn't nned it (but it won't hurt
> anything to have it).
>
> FYI, "Read permissions" doesn't mean "Permission to read the cpntents
> of the mailbox", it means "allowed to read the mailbox's permissions".
>
>>Anyway, even though she had SELF, as per a portion of my users, she still
>>couldn't gain access to her mailbox. Once I added her account explicitly,
>>she could.
>
> It wouldn't be the 1st time I've seen a mismatch between the
> permission on the mailbox and the permission the ADUC displayed.
> Instead of adding the user account to the mailbox it's sometimes
> enough to force the ADUC to rewrite the permission on the mailbox. I
> usually do that by giving the SELF account the "Associated external
> access" permission and clicking OK enough times to completely close
> the ADUC property page for the user. Then go back and remove the AEA
> permission and completely close the property pages. That usually sets
> things right.
>
> The larger concern is why there are so many open sessions from the
> client. If they're using VPN or wireless connection it could be that
> the connections is poor and they're abruptly disconnected and then
> reconnected (moving between WiFi access points can be a killer).
> That'll leave a TCP session open for up to two hours before it's
> cleaned up. You can help with this by setting the TCP keep-alive time
> to 5 minutes instead of the default 2 hours.
>
>>So, my questions are:
>>
>>1. What is the SELF group, and is that what users are supposed to gain
>>access to their mailboxes with?
>
> SELF is a special object (and SID) that refers to the account to which
> the mailbox is assigned. IOW, it's self referential.
>
>>2. Any idea why out of the 700 mailboxes we have, some have a permissions
>>entry for SELF in ADUC, and some have their username explicitly?
>>Presumably
>>we are doing something to cause the difference?
>
> Is this an organization that's never upgraded Exchange? The presence
> of the user's account in the permissions is usually a sign of previous
> migrations/upgrades or of people mistakenly putting the account into
> the permissions. The expected (and usual) situation is that there's
> only the SELF account with "Full Mailbox Access".
>
> However (there's always one of those!) there are situations where the
> account is needed, but not on the mailbox permissions. One of those is
> when the person's using POP3 or IMAP4 and trying to send an email.
> Sometimes it's necessary to give the account "Send As" permission.
>
> You should be safe removing the account and making sure SELF is
> assigned the necessary permission on the mailbox.
> ---
> Rich Matheisen
> MCSE+I, Exchange MVP


From: Rich Matheisen [MVP] on 27 Nov 2009 16:41
On Fri, 27 Nov 2009 12:30:26 -0500, "Phil McNeill"
<philmcneill(a)REMOVETEXTINCAPShydroottawa.com> wrote:

>Thanks for the reply Rich. There are mailboxes on this system that would
>have been migrated from an Exchange 5.5 environment 5 or 6 years ago, and
>then again from one 2003 server to another 2003 server 2-3 years ago. Then
>of course there are other mailboxes that have been created at various times
>over the course of that entire time period. Perhaps that's the difference?

Without a doubt. I used to work for a company with about 28K mailboxes
that particitpated in JDP's (the precursor to TAPs) for Exchange 5.5,
2000, and Windows 2000 (and had a multi-domain, single-labled,
empty-root forest to prove it!). They had the same mess you
discovered. When their North American operations were bought by
another company I moved all the mailboxes to the new company and, sure
enough, they also had a similar situation. A little bit of work with
Powershell and it was all straightened out.

Having the account assigned FMA permission doesn't hurt anything, it's
just unnecessary and can cause some unexpected things to happen in
Exchange 2007 (like making a mailbox into a "shared mailbox").

>Anyway, thanks for the reply. I should have thought of the "permissions
>reboot" option, as I've done that many times before when public folder
>access wasn't working in practice the way the permissions tree said it
>should be. In effect I guess I did do that. Just didn't need the new
>account involved.
>
>With the regard to the TCP keep-alives you were talking about, did you mean
>keep alives specifically to the Exchange server, or Windows? Registry
>setting for that?

TCP is a "Windows thing". Exchange is just an application. :-)

http://msdn.microsoft.com/en-us/library/aa302363.aspx

Look for the "KeepAliveTime" value.

You could alos move the mailbox to another database. That'd close the
connections, too. As would using tcpview to terminate them.
---
Rich Matheisen
MCSE+I, Exchange MVP
From: Phil McNeill on 3 Dec 2009 13:12
Thanks much!

"Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message
news:k5h0h51lsbl7tkceqk3rnra1tcir961idg(a)4ax.com...
> On Fri, 27 Nov 2009 12:30:26 -0500, "Phil McNeill"
> <philmcneill(a)REMOVETEXTINCAPShydroottawa.com> wrote:
>
>>Thanks for the reply Rich. There are mailboxes on this system that would
>>have been migrated from an Exchange 5.5 environment 5 or 6 years ago, and
>>then again from one 2003 server to another 2003 server 2-3 years ago.
>>Then
>>of course there are other mailboxes that have been created at various
>>times
>>over the course of that entire time period. Perhaps that's the
>>difference?
>
> Without a doubt. I used to work for a company with about 28K mailboxes
> that particitpated in JDP's (the precursor to TAPs) for Exchange 5.5,
> 2000, and Windows 2000 (and had a multi-domain, single-labled,
> empty-root forest to prove it!). They had the same mess you
> discovered. When their North American operations were bought by
> another company I moved all the mailboxes to the new company and, sure
> enough, they also had a similar situation. A little bit of work with
> Powershell and it was all straightened out.
>
> Having the account assigned FMA permission doesn't hurt anything, it's
> just unnecessary and can cause some unexpected things to happen in
> Exchange 2007 (like making a mailbox into a "shared mailbox").
>
>>Anyway, thanks for the reply. I should have thought of the "permissions
>>reboot" option, as I've done that many times before when public folder
>>access wasn't working in practice the way the permissions tree said it
>>should be. In effect I guess I did do that. Just didn't need the new
>>account involved.
>>
>>With the regard to the TCP keep-alives you were talking about, did you
>>mean
>>keep alives specifically to the Exchange server, or Windows? Registry
>>setting for that?
>
> TCP is a "Windows thing". Exchange is just an application. :-)
>
> http://msdn.microsoft.com/en-us/library/aa302363.aspx
>
> Look for the "KeepAliveTime" value.
>
> You could alos move the mailbox to another database. That'd close the
> connections, too. As would using tcpview to terminate them.
> ---
> Rich Matheisen
> MCSE+I, Exchange MVP


 | 
Pages: 1
Prev: 0X8004010F
Next: Outlook Web Access - Password Expired