Exchange 2010 - Outlook 2010 OAB download failes with error 0x80190194 - A troubleshooting approach - blog - Alexander Ollischer | Citrix

Just recently I came across an interesting support case which involved an Exchange 2010 Offline Address Book (OAB) and Outlook 2010 clients trying to download it. The affected users received an error stating: Error 0x80190194 - The operation failed. Problem is, this is a very common error when downloading the OAB and there are many server side problems which can generate this error:

This error can be caused by many a issues, e.g.

missing IIS and/or folder permissions (server-side)
IIS authentication issues (server-side)
IIS misconfigured http redirection (server-side)
file replication service issues (server-side)
missing or misconfigured OAB distribution settings (server-side)
OAB generating mailbox issues (server-side)
DAG replication issues and arbitration mailbox (server-side)
missing or misconfigured proxy settings (client-side)
download issues in terms of BITS (client-side)
et al

Troubleshooting methodology

In order to identify the affected OAB that my users tried to download I first had to get hands on the corresponding OAB GUID by running:

Get-OfflineAddressBook | ft Name,GUID

With the OAB GUID identified I started testing with a browser by navigating to the corresponding URL https://<ServerFQDN>/OAB/<GUID>/oab.xml, checking each server separately. I thereby received an Error 404 - Not Found on one of my servers, which in turn resulted in the aforementioned Outlook error 0x80190194 for my users. This error (which is basically a 404) appeared sporadically depending on the Exchange 2010 Server they were redirected to through our Load Balancer:

Further research on the server showing the Error 404 in particular showed that OAB with GUID 72189f79-62fa-4bcf-82ea-56dc45cfdeb0 is missing in IIS under the OAB node, thus assuming that this particular OAB has not been replicated between my Exchange 2010 Servers:

Missing OABs in the file system ... check the Microsoft Exchange File Distribution Services (MSExchangeFDS) on the affected server

The following location on the Client Access Server can be checked to see if the OAB files have been replicated:

%ExchangeInstallPath%ClientAccess\OAB\<GUID>

Permissions should also be checked. If any of the default permissions are locked or are missing, the OAB files might not be replicated. Have a look at How to solve Internal Error 500 when testing connection to the OAB or Exchange 2010: OAB download error 80190194.

I copied the missing web.config file as well an restarted the MSExchangeFDS service, to no prevail. Then I executed Get-OfflineAddressBook "<OAB Name>" | Update-OfflineAddressBook to no prevail. Finally I execute iisreset to no prevail.

Well, checking the distribution methods for the affected OAB revealed that the 2nd Exchange 2010 Server was missing in the Distribution tab of the OAB's Properties. I should have done this in the first place 🙂

After adding the missing Exchange 2010 Server and restarting the Microsoft Exchange File Distribution service by executing Restart-Service MSExchangeFDS the replication started immediately. The missing OAB showed up in IIS as well as in the folder structure.

Alternatively you could run the following cmdlet to initiate the OAB replication:

Update-FileDistributionService <ServerFQDN> -type oab

But even after a successful OAB replication I still received an http error 500 - Internal Server Error when acessing the OAB via browser in order to verify that everything's fine:

So, back to the web.config file, that was presumably missing the first time around. What does a web.config file actually do when placed in the OAB file directory:

When you configure Http Redirection a web.config file is created in the OAB directory. This file has incorrect permissions. Assign Read and Read & Execute permission to Autheticated Users group then restart IIS using iisreset /noforce.
Now you can try to download the OAB using Outlook. It may be required to download it twice because sometimes the name of the OAB doesn't appear at first try.

Well, that didn't count for me so I checked the web.config and IIS settings to verify whether any settings have been adjusted in the past that I didn't know of. As that wasn't the case I deleted it, but the issue still persisted.

Verify OfflineAddressBook property on the affected user's mailbox and adjust the missing OAB association:

Get-Mailbox <User>| fl Name,OfflineAddressBook
Get-Mailbox <User> | Set-Mailbox -OfflineAddressBook "<OAB Name>"

Further troubleshooting on the client-side:

With a corresponding Event Log entry on the client computer, Event ID 27, Source: Outlook, the issue can be further analyzed by following Microsoft's KB843483 article:

Protokollname: Application
Quelle:        Outlook
Datum:         05.12.2018 12:28:31
Ereignis-ID:   27
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      <Computername>
Beschreibung:
Starting OAB download. (See event data).
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Outlook" />
    <EventID Qualifiers="16384">27</EventID>
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2018-12-05T11:28:31.000000000Z" />
    <EventRecordID>18716</EventRecordID>
    <Channel>Application</Channel>
    <Computer>Computername</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Starting OAB download. (See event data).</Data>
    <Binary>0200000000000000730100007301000073010000000000000000000000000000E9FD00000000000000000000D05B00003C600000306A0000286B0000F8670000601B2E13520B0000000000005C0000002000000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005C0063006F006E0073006F0072007300660069006E0061006E007A002E006400650020002D00200041006C006C006500000031623662323737382D643765332D343732612D616234622D64356335343264343836333000</Binary>
  </EventData>
</Event>

Protokollname: Application
Quelle:        Outlook
Datum:         05.12.2018 12:28:45
Ereignis-ID:   27
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      <Computername>
Beschreibung:
OAB Download Failed. (Result code in event data).
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Outlook" />
    <EventID Qualifiers="16384">27</EventID>
    <Level>3</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2018-12-05T11:28:45.000000000Z" />
    <EventRecordID>18717</EventRecordID>
    <Channel>Application</Channel>
    <Computer>Computername</Computer>
    <Security />
  </System>
  <EventData>
    <Data>OAB Download Failed. (Result code in event data).</Data>
    <Binary>0200000094011980730100007301000073010000000000000000000000000000E9FD00000000000000000000D05B00003C600000306A0000286B0000F8670000601B2E13520B0000000000005C000000200000000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</Binary>
  </EventData>
</Event>

In my case the error messages stated exactly what I tried to achieve:

Result Code 2, i.e. You forced a full .oab file download manually.

Furthermore I checked some other client-side settings and known issues that could cause an OAB download error, such as whether BITS has some kind of problem when trying to download the OAB. An error 0x80200049 is often caused from the BITS job list being full. To fix this, you must clear/reset the BITS job list. Microsoft outlook uses BITS to download the OAB and if the BITS queue goes full it simply stops:

bitsadmin /list /verbose

bitsadmin /reset

The client-side proxy settings, i.e. the client should have unobstructed access to Exchange via https:

netsh winhttp show proxy

netsh winhttp reset proxy

netsh winhttp set proxy <proxy>:<port>

In the end the last thing I had to ensure and configure was to enable GlobalWebDistribution for all my Exchange 2010 OABs in order to prevent server-specific connections when clients try to download the OAB:

Get-OfflineAddressBook | Where {$_.ExchangeVersion.ExchangeBuild.Major -Eq 14} | Set-OfflineAddressBook -GlobalWebDistributionEnabled $True -VirtualDirectories $Null

In my particular case that did it: the issue was resolved and setting the VirtualDirectories property to $Null reverted my solution attempt that I suggested previously 🙂 And I can tell you why: because my environment consisted of Exchange 2010 and Exchange 2016 Servers due to being in the middle of a migration.

Update:

With Exchange 2013 onward the CAS role proxies the OAB download request to an appropriate Mailbox role server. The CAS role maintains a log of each request it handles in the log files, present in folder %ExchangeInstallPath%\Logging\HttpProxy\OAB\. These log files are an excellent tool to identify which mailbox server the CAS chose to serve the request. Download issues can be analyzed with log files found in %ExchangeInstall%\Logging\OABDownload. The OAB generation logs can be found in the \Logging\OABGeneratorLog folder.

Maybe one of the steps outlined above will help you, too, to get rid of issues with downloading OABs for good.

Exchange 2010 – Outlook 2010 OAB download failes with error 0x80190194 – A troubleshooting approach

Leave a Reply Cancel reply