How to deal with multiple OAB public system folders of the same type
I recently looked at a case for a customer and I saw something very interesting. The problem they were faced with was they had multiple OAB Version 2 system folders in the public folder store. This problem was only affecting users that were running in Cached Mode. Looking at this from the ESM the system folder view looked like this:
- Folders
- Public Folders
-OFFLINE ADDRESS BOOK
- /o=OABGen/cn=addrlists/cn=oabs/cn=Default Offline Address List
- OAB Version 2
- OAB Version 2
- OAB Version 2
- OAB Version 3a
- OAB Version 4
These extra folders were not replicated in from other sites, they were all from here. The main question at this point to me was how did things get this like, and what would cause this. I myself was able to reproduce this by doing a victim restore in the lab which left me with multiple system folders. Under normal circumstances this should never happen because the OAB Generation process will take care of this for you (by creating the OAB folders that are needed). If the system folders does not exist OABGen will be create them (OAB Version 2, OAB Version 3 and OAB Version 4), if they already exist nothing will happen. Being this is the case, there was a very easy fix for this. there is a catch to this as well and I need to post a warning as here!!
WARNING: Following this fix *WILL* cause full OAB downloads for your Outlook clients because we are removing the OAB folders and the OAB data. I am also currently investigating another fix that a lot less brutal and will allow the correct OAB folders to remain in place, thus not causing a full download. I will keep everybody posted.
Before I get in to the fix I just want to rehash running GUIDGen is a very sore spot for me. This seems to be a common troubleshooting step for administrators and you need to understand that running GUIDGen should not be done unless directed by someone in Escalation Services. GUIDGen resets the Exchange system folders, however there is no need to reset them when you can troubleshoot the problem at hand. Running GUIDGen can and will lead to other problems such as (Free/Busy problems, unable to download any OAB, etc), and I will not cover that in this blog. Ok, enough about GUIDGen, here is how you can fix this!!
Plan 1
1. You will need to download MAPI Editor (formerly known as MFCMapi) if you do not have a copy. Download MAPI Editor here!!
2. Run MAPI Editor and click 'OK'.
3. Select 'Session'.
4. Select 'Logon and Display Store Table'.
5. Select an administrative profile that has full access to the Exchange Server.
6. Select 'MDB'.
7. Select 'Open Public Folder Store' (You need to select Use Admin Privileges)
8. Expand Public Root/NON_IPM_SUBTREE/OFFLINE ADDRESS BOOK
9. Highlight the OAB Version # folder in question.
10. Select 'Actions' from the menu
11. Select 'Delete Folder'.
12. Rebuild the Default OAB or which ever one those folders were under and you will see that we recreate them via the OAB process.
13. Log on with a client after the Offline Address Book has been rebuild and download the files.
Plan 2
1. You can use the Exchange 2003 ESM (Exchange System Manager)
2. Open your administrative group.
3. Open Folders
4. Right click public folders and select 'View System Folders'
5. Open OFFLINE ADDRESS BOOK
6. Select your offline address book
7. Right click the OAB System Folder and select Delete.
Your done!!!
Dave
Comments
Anonymous
August 10, 2006
The comment has been removedAnonymous
April 26, 2007
There are a multiple reasons for why an Outlook client can receive the 0x8004010f sync error. Unfortunately,Anonymous
October 02, 2008
When it comes to downloading an OAB the following error code [ 0X8004010F ] is the biggest pain for everyone,