An interesting collision of Outlook views that I’ve lately come across -
sporadically I’ve begun receiving complaints that migrated users (both Exchange 2003 and 2007 to Exchange 2010) are having problems with default view of different shared folders (e.g Contacts or Calendar).
The problem manifested itself in the form of disappearing default view that was replaced by generic Outlook Today view.
The user who shared folders was not able to see such a behavior and only delegates were able to replicate it.
A couple of similar cases ended up with mailboxes recreation that I considered too harsh for such a problem and decided to take a deeper look into it.
The problems outlined in the incidents which ended up with mailbox recreation were lacking a few key troubleshooting techniques that I’d like to engage.
Mailbox recreation apparently is way too brutal and I personally would use it as the last resort only.
This is pretty crucial for successful troubleshooting to figure if this is the global issue for all delegates set for a specific mailbox (I wouldn’t hesitate to add a test one in case there’s only one existing originally) or the problem of view rendering for a specific delegate.
I believe this is a logical must to separate the problem into 2 possible clauses:
1. Shared folder problem
2. Delegate’s problem
I decided to go this way as I’m not that kind of mailbox recreation junkie.
It turned out the problem was not reproducible on other delegates’ accounts and was absolutely isolated to a specific person trying to open a shared folder. Apparently with this in mind you’ll never say ‘go’ to mailbox recreation.
You may find some solutions on the Internet involving running /resetfolders switch that will never help in such issue or rebuilding user account (like this link from Experts Exchange) -
“I resolved the problem for my situation by rebuilding the user account. First I exported the entire mailbox to a .pst then from Exchange
Management Console I removed the mailbox and associated user account. I recreated the account with the same name and after granting access
to the Contacts folder everything works as it should. Note: the profile on the user’s computer will detect a new user account so you will
need to copy user info into the new profile. ”
The right way is to use /cleanviews switch that does its job just fine. This needs to be run against the profile setup with cache mode off. There is a way to take care of views problems with mfcmapi but this requires some more experience with it in order not to destruct the mailbox occasionally. For end users running the switch is absolute no brainer (compared to mfcmapi tricks:)).
As a resume, expediting a bit more on possible way of resolution may help us avoid mailbox recreation unless it’s absolutely necessary. Scalpel is way better than the axe, huh?
UPDATE:
Just had the same issue on other mailbox and the steps outlined above were of no help. The problem persisted even after mailbox move and running the appropriate switches.
Given the repeated nature of the problem the case with Microsoft was opened and here are the brief details -
First off, the recommendation was to run the following cmdlet against the database where the delegate was resided:
Isinteg –s “server name” –fix –test alltests
Secondly if we still have the issue then we have to export the delegate’s mailbox data to a pst file and delete the mailbox. Recreate the mailbox and import the data back.
Since the first step required bringing the entire database online that was not acceptable at that time we proceeded with the second step that did the needful and the problem was resolved.
A few days ago I drove a training for Tier 2 techs at the company devoted to the most common scenarios when we have to rely on mfcmapi heavily to fix the issue.
