Random users' Outlook hanging

[TexExpat]

I am having problems with very slow access from Outlook to Exchange 2000. This will happen to one user or a very few users while other users are accessing Exchange with no problem. Sometimes, Outlook recovers in a minute or two; other times, the user has to restart Outlook. Then those users will be OK. At a later time, some other user will be affected while other users (including previously affected users) are not affected and are accessing Outlook just fine. According to our help desk, it seems far more prevalent on PC's running Outlook XP on Windows 2000 Pro, but users of Outlook 2000 on Windows 98 are also affected to a lesser degree. I have been tracking log record stalls/sec for the last hour and a half, but there have been no log record stalls recorded.

We had noticed a little bit of random slowness earlier in the summer, but it is much more prevalent since we used Windows update to install all critical security patches other than SP4 on the Exchange Server.

I have a single Exchange Server 2000, SP3 running on Windows 2000, SP3. The server was upgraded in place last spring from Exchange 5.5 SP4 running on Windows NT 4.0 SP6a. It has about 600 mailboxes. I have two DC's; both are GC's and one has DNS as installed by the Domain upgrade procedure when installing the first Win2K DC.

Does anyone have any ideas what may be going on with my server? Is it an issue of interacting with ADS directory information, or is it something with my Exchange Server? Are their any counters in Performance Monitor I should be tracking? What troubleshooting measures should I take?

Thank you very much for any help you can offer.

 

[xmsre]

Usually, when it's specific users, it's something to do with the usr's mailbox. I would check:

1. Permissions. Are there any dead DNs, groups that contain dead DNs, inappropriate or corrupt MSExchMasterAccountSID or MSExchMailboxSecurityDescriptor, and so forth.

2. Excessive cached backlinked, searches, and restrictions. Older versions of blackberry and other CDO apps can cause this.

 

[woodrasj]

We are having the same problem at my company right now and we have narrowed it down to the machines looking at the old exchange server that had 5.5 on it. It will break out of it eventually but takes quite some time to do so. We are in the process of removing the old exchange server from the forest but we get these hanging problems whenever we turn it off.

We cannot find anywhere in the registry though that is pointing to the old server.

John Woodraska

 

[xmsre]

Client profiles not redirecting.

There are really two places. You can manually change the profile to pint to the new server through the properties of the exchange service. Also drop the OAB service, exit, and add it back.

If you don't redirect correctly, the Outlook address book still points to the contacts folder on the old server. Autoresolve will hang forever. By dropping the service from the profile and adding it back, you pick up the PR_EntryID to the contacts folder on the new server.

John
MOSMWNMTK

 

[TexExpat]

Thanks for your reply, xmsre. I don't think that it applies to specific users; it seems rather random. I have heard of a number of users having been affected at one time or another.

How would I check for the DN's, MSExchMasterAccountSID, or MSExchMailboxSecurityDescriptor as you suggested?

Also, we did introduce a Blackberry server about a year ago when we were still at Exchange 5.5. However, many of the users who have experienced these slowdowns are not Blackberry users. Could Blackberry have an effect on the Exchange Server as a whole, or only to users who also have a Blackberry?

Thank you for your help.

 

[xmsre]

Dead DNs will be unresolved on the permissions tab.

Q309222 tells how to check for the MSExchangeMasterAccountSID issue.


If the security descriptior is malformed, SELF is visible in the permissions through the GUI, but when you do an LDIF export of the attribute is does not contain the string "AQEAAAAAAAUKAAAA" [properly formed SELF]. If you try to remove self through the GUI or CDOEXM script, you can't.

The whole issue with exactly what permissions belong on a mailbox is something of a mystery. If you ask MS, you won't get a straight answer. I don't think anyone at MS really knows.

As far as I can tell:

When the mailbox is first created, SELF exists with read and full. When it is instanced, The owner's account gets read and full. If you used the ADC or other programmatic method to populate the permissions, both Self and the owner appear with read and full. If the account is disabled, SELF gets the external associated account box checked, and the ACE for self is copied from MSExchMailboxSecurityDescriptor to MSExchMasterAccountSID. Q309222 deals with when ADClean inappropriately populates MSExchMasterAccountSID. Q317721 and Q329169 deal with cleaning up after flipping a one-way CA to a two-way CA. Q324353 sort of gives up, and describes a way to clear the permissions and start over by using a script to reset the attribute, deleting, then recovering and reconnecting the mailbox. The whole mess is quie frequently seen after a migration. I'd guess that the problem is nearly as widespread as Dead DN issues. The result is slowness, public folder access, and delegate access issues.


Blackberry versions that used older CDO libraries would leave excessive backlinks restrictions and serches on the mailbox. This would be specific to certain users. You can check for the issue with the steps in Q216076. Other CDO applications could do this as well, depending on exactly what version of the CDO libraries they used. For example, OWA in 5.5 was a CDO application.


John
MOSMWNMTK