After doing a migration from Microsoft Exchange 2013 to Exchange 2016 I noticed that my Offline Address Book (OAB) wasn’t being made available to Outlook clients.
When trying to perform a manual download (Send and Receive -> Download Address Book), it wasn’t in the list. Also when using the “Test EMail AutoConfiguration..” (by holding CTRL and right click on Outlook System Tray icon) to examine the AutoDiscover information, there was no OAB URL (OABUrl in XML) being sent to the clients.
I spent 3 hours trying to find out why this was happening (I assumed it was configuration and/or IIS authentication related). All my virtual directories and URLs were fine, and the OAB was being generated fine without any issues. It simply wasn’t being passed to Outlook clients. I couldn’t find any references of this occurring to other users.
I finally discovered that the “WebDistributionEnabled” configuration flag was marked to False, when it needs to be marked as True. This flag when set to true, allows it to be distributed (Note/Fun Fact: There’s a separate and different flag for older Exchange versions where the OAB is inside of the Public Folder Store). There’s also a different flag “GlobalWebDistributionEnabled”, which is recommended to be enabled as well on Exchange 2016. When setting this second flag to True, it also sets the first one above to True as well.
To fix it we’ll use Exchange PowerShell:
Let’s find the name of your Offline Address Book by running the command below:
Get-OfflineAddressBook
Now let’s set the “GlobalWebDistributionEnabled” flag to True using this next command:
Set-OfflineAddressBook -Identity “Default Offline Address Book (Ex2016)” -GlobalWebDistributionEnabled $true
And finally let’s confirm to make sure the changes take effect and look for the values of “GlobalWebDistributionEnabled” and “WebDistributionEnabled” using the command:
Get-OfflineAddressBook | fl
After making the above changes I recommend issuing an “iisreset” or restarting your Exchange Server. There will also be a delay where you’ll need to wait for your Outlook clients to refresh their autodiscover configuration. You can run the “Test Email AutoConfiguration…” to see if the OAB is now being passed to your clients.
While most of us frequently deploy new ESXi hosts, a question and task not oftenly discussed is how to properly decommission a VMware ESXi host. Some might be surprised to… Read More
This guide will outline the instructions to Disable the VMware Horizon Session Bar. These instructions can be used to disable the Horizon Session Bar (also known as the Horizon Client… Read More
Normally, any VMs that are NVIDIA vGPU enabled have to be manually migrated with manual vMotion if a host is placed in to maintenance mode, to evacuate the host. While… Read More
You may experience GPU issues with the VMware Horizon Indirect Display Driver in your environment when using 3rd party applications which incorrectly utilize the incorrect display adapter. This results with… Read More
Today we're going to cover a powerful little NAS being used with VMware; the Synology DS923+ VMware vSphere Use case and Configuration. This little (but powerful) NAS is perfect for… Read More
Today we'll go over how to install the vSphere vCenter Root Certificate on your client system. Certificates are designed to verify the identity of the systems, software, and/or resources we… Read More
View Comments
Thank you Stephen. None of the other "fixes" fixed this. Yours did!
That did the trick for me too!
Thanks Stephen.
Thanks a lot for the info. I scratched my head a lot on this one.
I can supply the following bonus info. When the WebDistribution isn't activated after a migration the Outlook client will receive this not very helpful error, when trying to download the OAB:
"Task '' reported error (0X8004010F): 'The operation failed. An object cannot be found."
Enabling WebDistribution again fixed the problem, and the OAB could again be downloaded.
worked like a charm!
thanks.
Thanks a lot my man! The amount of articles I have read before finding yours. Such a simple fix. Why it was turned off in the first place is a mystery.
Glad it helped!
I think it's just from upgrade after upgrade after upgrade, and maybe it was forgotten and left behind .
Cheers!
Just want to say thanks for this. I migrated from Ex 2013 to Ex 2019 and couldn't figure out why my OAB wasn't downloading!! Cheers
This post is awesome. Like others, I stumbled upon it after researching the 0X8004010F error for a couple hours. I suspect this problem is widespread, and other Exchange shops are resolving the problem by creating a new Offline Address Book instead of using this simple fix to the current OAB. I suggest adding the text of the 0X8004010F error to your original post so that it is picked up quicker by Search Engines: 0x8004010F : The operation failed. An object cannot be found.
Thanks David! Appreciate you posting the error code!
That worked for Us. I just waited for the GAL to update in the middle of the night. Checked it the next morning and no Error message when downloading the GAB in Outlook Clients and everyone else updated automatically. As a Bonus, this also fixed the issue of Users unable to Send As in Outlook Client Cache Mode when they have the Authority in a Distro Group. Many Thanks!
This post save my A**! Thanks you! I have been trying to figure out for months why the OAB looked good on the server but none of the clients could update it. Once I found out it was not showing up in the Autodiscover.xml, my search brought me here. Again, a big thank you for posting this information for everyone to see!
Thank you. Our cause was different (disaster recovery, basically), but this gave me the information I needed to discover how to fix it. Thanks
Ran into the same issue after upgrading from Exchange 2013 to 2019. The OAB by default had these parameters set to false and after awhile end users running in Outlook cached mode had address list issues. Thanks for sharing.
Thank you very much.
It works for me.
Enabling GlobalWebDistribution (which also enables WebDistribution as you stated) did the trick. Can't tell you how many other places I looked for this solution. Many thanks!
I had the same issue going from Exchange 2013 to Exchange 2019. Once we removed the old exchange 2013 Server and we had to do it through ADSIEDIT because it would not uninstall we lost client connectivity to the GAL. I ran the commands above, Did an IIS reset waited 20 Min and it began working again. Thank you for posting this as I spent 1/2 my day trying to get this to work..
Great Job.
It works for us perfectly fine.