In my past practice I occasionally came across cases where users could not enable Trust Email from my Contacts option in OWA receiving “Junk email validation error.”
The solution I saw references for was to export contacts, run resulting file against scanpst utility , import back etc.
There is a tip that allows the fix to be implemented with less hassle – recreation of Junk email rule via mfcmapi works the magic too.
Been assisting with one issue recently and came up with the following cmdlet.
Hey-hey, glorious PowerShell!
get-mailboxstatistics | where-object {$_.disconnectdate -ne $null} | Select DisplayName,@{Name="TotalItemSize(KB)";Expression={$_.TotalItemSize.Value.ToKB()}} | Export-Csv c:\temp\mbx.csv | foreach {$_.length=($_.length)/1024/1024/1024; $_}
The output is really straightforward.
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.
Being one of the greatest mfcmapi fans around I had a couple of tips to share and now I’d like to share them here as well.
Below are examples of troubleshooting scenarios best performed with MFCMAPI. They are well documented already and I don’t target to cover them in this article. I’d rather go ahead and share less known tips leaving those techniques for the next post.
I refer to the well-known basic operations with MFCMAPI as follows:
a. Deleting corrupted Junk email rules
b. Un-hiding hidden folders (or hide them)
c. Deleting a delegate from mailbox
d. Troubleshooting BlackBerry Enterprise Activation
e. Troubleshooting Out Of Office
f. Checking RefID of a message on BlackBerry
g. Checking if the messages were marked by AV software or Outlook Junk email filter
A couple of tips every mfcmapi fan is aware about –
Always use online mode for a profile and check for a new version occasionally as frequently they contain either new features incorporated or bug fixes or both
I have selected the following techniques to discuss:
1. Signature Issue and OWA Settings
2. Autocomplete cache issue
3. Restore from dumpster
4. Delete/Create folders
5. Restore messages/copy messages from folder to folder
6. Item count
7. Information about deleted items
Starting Monday I’m going to cover them gradually as I’m pretty certain mfcmapi is invaluable when dealing with low level mailbox problem and it’s second to none in such cases.
Stay tuned!
This is a follow up to the article previously posted, already revisited and slightly changed.
As the last update to that revision states the workaround originally offered (previous tricks with switches and mfcmapi’s doodling with views) did not work consistently and thus it would be honestly to say it apparently did not uncover the core of the problem.
The problem was dragging, this dreading issue has been occurring pretty frequently and every time we ended up recreating the mailbox as per Microsoft solution provided in the case we had with them.
Today I’ve had another case escalated with the same problem and I felt it was the right time to best the beast finally.
Having spent a decent amount of time I found a really working method to fix such a problem without mailbox recreation.
Here’s the overview of the process and a little bit of explanation:
1. Key misconception of previous approaches that corruption in such cases is on mailbox level (hence the workable solution was to recreate a mailbox). This is not true as the problem is folder level and we need to remedy the folder in question to fix it (Calendar or Contacts in all cases).
2. Methods we tried included export the data, scanning it against scanpst, import it back – that did not help as the corruption of data is only part of the problem (scanpst took care of that part) while the other one remained untouched – folder corruption. Sometimes we tried purging folders’ content with mfcmapi and it worked – however, emptying the folder is useless when we talk about folder level corruption, attempts to delete this folder and recreate from the scratch were to no avail as when the folder is corrupted even mfcmapi cannot delete it right away popping up with exception error.
3. In order to get rid of corrupted folder we need:
a) create a folder named, say, Contacts2 with mfcmapi
b) change PR_CONTAINER_CLASS to something like IPF.Note to make it pretend it is a simple message
c) Empty items using context menu of mfcmapi
d) correctly quit mfcmapi and re-login to Outlook profile again, try to delete corrupted folder with mfcmapi – it should work this time and it can safely be deleted (granted you have a copy of the data from corrupted folder locally of course). In case it does not get deleted we may leave it hidden for a time being (PR_ATTR_HIDDEN set to True). Pre-requisites for successful deletion may include cleaning all ACL entries too.
4. Once the corrupted folder is gone (or at least hidden) we should import scanned data back, re-grant permissions, re-add shared folder in delegate’s mailbox, re-name newly created folder (I assume it was Contacts2 or something). Important to understand you will not be able to use default folder name as long as the old corrupted folder exists in the mailbox (even if it’s hidden). Without re-adding shared folder to the delegate’s profile you will keep receiving errors like ‘folder cannot be opened’/’folder cannot be displayed’/’you don’t have permissions’ etc. Profile recreation is not needed if the folder is re-added properly.
I believe that’s it. Summarizing the above information that most troublesome part of the process is getting rid of corrupted folder – as it is crippled it does not want to let go easily.
P.S. Quite nice to know MS decided not to bother that much about the same problem when we opened the case regarding this with them. Seems like they also prefer axe rather than scalpel sometimes.
I hope I haven’t skipped anything important and this will be a valuable bit of knowledge.
To follow up on previous life cycle post I’d like to blog a bit on a very interesting issue that has already been acknowledged by Microsoft but yet to be officially documented (in Microsoft public knowledge base).
There is an issue that has been occurring with multiple connections to the same Exchange 2010 mailbox from XP SP3 machines using NTLM authentication.
The problem manifested itself with inability to connect more than 1 client at a time. If users left their Outlook connected to Exchange 2010 mailbox at the office then home connection would fail.
Initially, the workaround found empirically was to set all but one of the Outlook clients to connect using basic authentication. The problem that eventually came up with this workaround is that if the user has opted to allow autodiscover to change the connection settings without prompting them again, the basic authentication setting will be reverted to NTLM each time they restart Outlook.
Upon investigation with Microsoft, it was discovered that the problem only seems to exist when the different machines are connecting to multiple CAS servers, but it cannot be reproduced when connecting to the same CAS server (with all clients connecting via NTLM).
Apparently the resolution until the permanent fix is available may include editing of hosts file to make a machine explicitly connect to a specific CAS server.
The downside to this solution is that if anything happens to the CAS server that someone puts in their hosts file, they will have the potential to lose connectivity to their mailbox.
Apart from that there is another possible workaround that can be implemented (if certain things are in a particular environment):
It is possible to add an A record for the VIP instead of using a hosts file (given Active Directory DNS is used for workstations). Thus internally all machines will use the DNS from Active Directory as an override.
This has not been tested actually but I can’t see anything that may prevent the configuration for seamless work at this time.
There is also a chance the problem will never be resolved by Microsoft as Windows XP has reached EOL for the most part and there shouldn’t be any surprise if that ends up with something like ‘please upgrade your workstations’
