Forum Discussion
NimbostratusExchange OAB download error
Hi, we are publishing Exchange 2010 through an F5 BIG-IP running v11, and we are having problems with users downloading the OAB at specific periods throughout the day. It seems that whenever the OABGen process runs, it updates the oab.xml file, which tells the client which .lzx files to download. However, because of caching on the F5's web acceleration profile, clients are receiving an outdated oab.xml, which still references stale .lzx files. So, when the clients tries to download the .lzx files, they receive 404 errors from IIS. On the client side, the OAB download error we see in Outlook is 0X80190194. It looks like F5 released version 4.8 of the Exchange deployment guide in May, and page 38 has steps required for excluding specific files from being cached to address this issue. However, we've completed these steps and are still having the issue. Is there anything else we need to do in order to complete the fix? Does something else need to be cleared or restarted? The fix was implemented last week, but we're still having issues. If we wait long enough, once the cache expires and the F5 updates its version of oab.xml, the problem goes away until the next day when the OABGen process creates another new oab.xml. We have also isolated this problem to the F5 by using the hosts file on the clients to bypass the F5 and go direct to the CAS when the issue is manifesting itself, and that always works. Thanks in advance for any help that can be provided.
7 Replies
- Hi Adam, once you've pinned oab.xml to the exclusion list for caching, you should never see that file in ramcache. You can verify this by using the tmsh command "show ltm profile ramcache ".
If you have correctly excluded oab.xml and it is still being cached by BIG-IP, we may have a product bug on our hands. Can you send the output of the command "list ltm profile acceleration "?
Mike 
Adam_Miceli_144Hi Mike, thanks for the good advice. When we run "tmsh show ltm profile ramcache all" it comes back and says "Total records of all profiles returned: 0".
When we run "tmsh list ltm profile web-acceleration", it comes back with:
ltm profile web-acceleration optimized-acceleration {
app-service none
cache-object-max-size 67108864
cache-object-min-size 0
cache-size 6144mb
defaults-from webacceleration
}
ltm profile web-acceleration optimized-caching {
app-service none
cache-max-age 86400
cache-object-max-size 2000000
cache-object-min-size 0
cache-size 10mb
defaults-from webacceleration
}
ltm profile web-acceleration webacceleration {
app-service none
cache-aging-rate 9
cache-client-cache-control-mode all
cache-insert-age-header enabled
cache-max-age 3600
cache-max-entries 10000
cache-object-max-size 50000
cache-object-min-size 500
cache-size 100mb
cache-uri-exclude none
cache-uri-include { .* }
cache-uri-include-override none
cache-uri-pinned none
}
Adam- Hmmm, if oab.xml isn't in ramcache, then that means we aren't caching it. Maybe it just expired?
Anyway, you don't have anything pinned to the exclusions list. It should look something like this:
cache-uri-exclude { /owa/ev.owa oab.xml }
Did you use the iApp to set this up, or configure it manually? I recommend the iApp, specifically the RC3 version available here: https://devcentral.f5.com/wiki/iApp.Microsoft-Exchange-2010-and-2013-iApp-Template.ashx
That version takes care of the exclusions for you.
Mike 
MVAWe had to manually exclude the oab.xml from the Web Acceleration profile "*_caching_profile" (*=name of iApp instance) created by the iApp and this resolved our issue. Here's what our profile looks like from bigip.conf:
ltm profile web-acceleration /Common/MSExchange.app/MSExchange_caching_profile {
app-service /Common/MSExchange.app/MSExchange
applications none
cache-uri-exclude { oab.xml }
cache-uri-include { .* }
cache-uri-include-override none
cache-uri-pinned none
defaults-from /Common/optimized-caching
}
Opened case with F5 and support confirmed this fix.- Adam_Miceli_144Thanks everyone, it seems the steps above resolved it for us, as well, just not immediately. A day or two after my initial post, we stopped seeing the errors, and this was without any additional intervention that I am aware of. Perhaps if we had cleared the RAM cache at the time of the configuration change, we would have had better results.
Rabbit23_116296We are running 11.4.1 and have the same issue. I see in the caching profile oab.xml is excluded.
Can I safely exclude /oab/* from the URI caching exclusion?
- You actually don't want to exclude the OAB file itself, only the manifest (xml) that tells the client that it's been updated. If clients are downloading the OAB for the first time, we want it to be served from cache. Is oab.xml present when you view the ramcache? If it is, try deleting the cache using tmsh delete ltm profile ramcache .
