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:
After adding the missing feature, the Office Web Apps Server 2013 should now report healthy:
Thanks for sharing
Thank you for this article.
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.
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.
@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).
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.
@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.)
@John Lemoine As Bjorn mentions, the .NET 4.5 install on Windows Server 2008 R2 installs everything that's needed.
Hi, <br/>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?<br/>Thanks!<br/><br/>This is the error that I'm receiving:<br/><br/> <?xml version="1.0" encoding="utf-16"?><br/><HealthReport xmlns:xsd="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>" xmlns:xsi=";<br/> <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 <a href="https://officewebserver.contosco.local/m/Present_2_0.asmx">https://officewebserver.contosco.local/m/Present_2_0.asmx</a>. 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><br/></HealthReport></Data><br/> </EventData><br/></Event>
@Codamnet<br/><br/>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.
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.
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.