How to Get Office Web Apps Server 2013 to Report a Healthy Health Status


I see this a lot in customer environments with Office Web Apps Server 2013 deployed for use with Lync Server 2013, where if you run the Get-OfficeWebAppsMachine cmdlet, the HealthStatus parameter is Unhealthy:

However, even though Office Web Apps Server 2013 reports as unhealthy, as far as Lync Server 2013 is concerned, everything is working fine.  Presenters in meetings are able to upload PowerPoint presentations and attendees can see the presentations.  So what is causing the unhealthy status and how do you fix it?

There are generally two issues that could be causing Office Web Apps Server 2013 to report as unhealthy.  If you look in the Microsoft Office Web Apps Event Log on the Office Web Apps Server 2013 server, you may see an error similar to the following:

<?xml version="1.0" encoding="utf-16"?>
<HealthReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <HealthMessage>BroadcastServicesWatchdog_Wfe reported status for BroadcastServices_Host in category '4'. Reported status: Contacting Present_2_0.asmx failed with an exception: Could not establish trust relationship for the SSL/TLS secure channel with authority 'test-owas1.test.deitterick.com'.</HealthMessage>
</HealthReport>

In this error message, you can see that there appears to be an issue with the certificate being used for the Office Web Apps Farm:

Could not establish trust relationship for the SSL/TLS secure channel with authority 'test-owas1.test.deitterick.com'.

This is because when you create the certificate for the Office Web Apps Farm, you need to include SAN entries for all servers in the farm.  Even if there's only a single server in the farm, if the names that you enter for the ExternalURL and/or InternalURL parameters are different than the server FQDN, you will need to add the server FQDN to the certificate.  In this example, I have a single Office Web Apps Server 2013 server and for the ExternalURL and InternalURL parameters, I've entered:

When creating the certificate for the Office Web Apps Farm, I needed to add the server FQDN as a SAN entry to the certificate:

This may be enough to resolve your issue and get Office Web Apps Server 2013 to report healthy:

Note: It may take awhile for the server to report a HealthStatus of Healthy.

 

If you are still seeing the HealthStatus reported as Unhealthy:

There may still be an additional error showing up in the Microsoft Office Web Apps Event Log:

<?xml version="1.0" encoding="utf-16"?> <HealthReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">   <HealthMessage>AgentManagerWatchdog reported status for AgentManagerWatchdog in category 'Recent Watchdog Reports'. Reported status: Machine health is Unhealthy</HealthMessage> </HealthReport>

This error is generally caused by not having the HTTP Activation feature installed on the Office Web Apps Server 2013 server:

You can install the missing feature using Server Manager or by running the following PowerShell cmdlet:

Add-WindowsFeature NET-WCF-HTTP-Activation45

 

After adding the missing feature, the Office Web Apps Server 2013 should now report healthy:

Note: It may take awhile for the server to report a HealthStatus of Healthy.

Comments (22)

  1. albandrod says:

    is it possible that in a Office Web Apps Server which status is "Unhealthy" only ppt and pptx documents cannot be previsualized? The rest of the documents works without problem

  2. dodeitte says:

    @Andy Heywood & @Bryan Marks

    Depending on where you decide to put the WAC server (internal or DMZ), you could potentially use an internally issued certificate. In the case that the WAC server is in the internal network, which is what I mainly see in customer environments, you’d use some type of Reverse Proxy to provide access externally. The Reverse Proxy would have the certificate from the public CA on it. The server FQDNs only need to be on the certificate that is on the WAC server(s).

  3. dodeitte says:

    @John Lemoine As Bjorn mentions, the .NET 4.5 install on Windows Server 2008 R2 installs everything that’s needed.

  4. Anonymous says:

    Thanks for sharing

  5. dodeitte says:

    @Codamnet

    Make sure that you’re certificate has the new FQDN and you may need to remove and recreate the farm. I’ve never tried to change the full computer name of a machine that’s been joined to AD, so that might be causing you some issues as well.

  6. Anonymous says:

    @Alan Coulter

    If your server FQDNs are using a non-public TLD, then you are correct that getting a certificate from a public CA is going to be an issue. You can consider using a certificate from on internal CA if you have one available.

  7. Abhilash says:

    Thank you for this article.

  8. Andy Heywood says:

    Great article and I never realised that you need the server names on the certificate before. Is that documented on TechNet and I’ve missed it? This brings about a question though as most SSL certificate providers now will not let you purchase a certificate with an internal name on now so this might cause a problem for a few people.

  9. Bryan Marks says:

    To echo Andy’s comment after 2015 cert authorities will not put local names on certificates and they are starting to make it harder now.

  10. John Lemoine says:

    How do you enable .Net 4.5 HTTP Activation in WCF on a Windows 2008 R2 server, the server admin interface is not the same as on Windows 2012 servers. I have not been able to find much documentation on managing these features on the older platforms.

  11. Bjorn Clysters says:

    @John: You need to enable the http activation under .net 3.5 and reinstall/repair your .net 4.5 installation. The installation for .net 4.5 automaticly activates the features you’ve activated under .net 3.5 on a 2008R2 machine. (This also fixes an issues
    with Lync 2013 – 2010 clients sharing a powerpoint.)

  12. Codamnet says:

    Hi,
    I changed the suffix of my computer from contosco.local to contosco.com but I still receive error that my Office Web server can not reach the https://officeserver.contosco.local/. I can ping my server with new suffix and I’m also able to see that it was changed
    the FQDN on my Active directory server. I’m able to open documents using Office web apps but I getting a lot of log error. Is there a way that I can change it?
    Thanks!

    This is the error that I’m receiving:

    <?xml version="1.0" encoding="utf-16"?>
    <HealthReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=";
    <HealthMessage>BroadcastServicesWatchdog_Wfe reported status for BroadcastServices_Host in category ‘4’. Reported status: Contacting Present_2_0.asmx failed with an exception: An error occurred while making the HTTP request to
    https://officewebserver.contosco.local/m/Present_2_0.asmx. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could
    also be caused by a mismatch of the security binding between the client and the server.</HealthMessage>
    </HealthReport>

  13. Travis Walls says:

    Thanks for posting this. I was missing the HTTP activation component and had the second error. Would be nice if they’d include that on the TechNet documentation for installing the product. I also found that NET-Framework-Features and NET-Framework-Core were added to the list of required components for 2012. These were not on the list when I did my install last summer.

  14. Anonymous says:

    Update 1/12/13 – Updated with additional information. Update 11/10/13 – Updated with links to updates

  15. Anonymous says:

    I’d like to add that if you install OWAS outside of C:, it will also report as unhealthy. This is not in any OWAS documentation, but has been confirmed by our MS Acct Rep.

  16. Aleem says:

    HI,
    I have issue with my new OWA setup – please help to fix the issue – URGENT

    I have issued public SSL cert for OWA server & deployed in its store and configured OWA as

    New-OfficeWebAppsFarm -InternalUrl "https://WACservername&quot; -externalurl "https:// WACservername.Ad.oak.ox.ac.uk" -CertificateName " WACservername " –EditingEnabled

    All deployment ,WOPI , discovery are fine but when I test office files I get error

    -=-=
    Microsoft Word Web App

    Sorry, there was a problem and we can’t open this document. If this happens again, try opening the document in Microsoft Word.
    –=-=
    – – (Get-OfficeWebAppsFarm).Machines —
    Unhealthy
    —PS Y:> Get-OfficeWebAppsFarm | Format-List externalurl,Internalurl

    ExternalURL : https://WAcservename.ad.oak.ox.ac.uk/
    InternalURL : https://WAcservename/

    I tried also deploying OWA without cert and still the same error comes

    Please guide me or advise me on this your help is greatly appreciated
    Thanks
    Aleem

  17. Oleg T. says:

    Thanx, very helpful! in my case it will be a HTTP Activation…Used this article
    http://technet.microsoft.com/en-us/library/jj219455(v=office.15).aspx

  18. Arimaze says:

    Thank you for sharing it helps me a lot !!

  19. Alan Coulter says:

    With the issue relating to the server FQDN needing to be added to the certificate for officewebapps.contoso.com via the Subject Alternative Name list, it appears that you can no longer do this for public certificates. In my case I could see that even though
    I registered the OWA farm to use (say) officewebapps.contoso.com, under the covers the event log was reporting an error and was trying to connect to owaserver.contoso.local. As I was using Windows 2012 R2 I updated the IIS bindings to have a host header for
    officewebapps.contoso.com. This seems to get rid of the error, but the health status is still reported as unhealthy (and every other alternative in the article has been verified). Any suggestions?

  20. toneman says:

    So SAN FQDN is required for my internal CA cert even if it is a single server farm? What about the use of a internal CA wildcard cert?

  21. dodeitte says:

    @toneman

    Yes, if the farm FQDN and the server FQDN are different. I’m not sure what the support position is on wildcard certs with Office Web Apps Server 2013.

  22. DOUG TO THE RESCUE!!