Category: Office Web Apps Server 2013

Office Web Apps Server unhealthy status


While deploying OWAS in our environment, we came across the “unhealthy” status of the machines in the farm issue. While we reviewed all the possible configuration options and search the Internet for an unknown factor that could explain this behavior, we remained clueless.
Although you can find very good article regarding the configuration and common issues with OWAS, this specific one isn’t documented anywhere.


  • Windows Server 2012 MSI
  • Office Web Apps Server 2013
  • 2 different URLs for the internal and external  OWAS access
  • Dedicated CNAME records for the URLs (Server’s FQDN isn’t used as the main OWAS URL)

Quick note for the configuration, I highly recommend you check out Wictor Wilén’s blog for very interesting explanation of OWAS mechanics. I also underline his blog for the reason that we initially had the issue of the certificate not including the server’s FQDN which created the static unhealthy report (see Machine are always reported as Unhealthy).

The culprit

S0, even with a correctly configured OWAS farm, the machines will kept being flagged as “Unhealthy”. What I found out is that I modified one setting from its original state : Log Verbosity. By our standard, we usually set them at “unexpected” (for SharePoint and OWAS) in order to save disk space and mitigate disk IOPS. If you check attentively a default OWAS farm, this setting will be set at … nothing. The value is actually empty.


After some testing, I found out that the least level of verbosity to get Healthy machines must be Medium.

With the culprit found and knowing how to fix it, I digged a little more to understand.
By looking in the OWAS folder installation located in drive:\Program Files\Microsoft Office Web Apps, a file named “uls.config.dynamic.xml” is stored in the subfolder AgentManager. From my understanding, this file is the template used by OWAS each time it starts to configure the current logging setting and save a copy of the configuration in drive:\ProgramData\Microsoft\OfficeWebApps\Data\local\ULSConfig.
You can easily validate this fact by changing the log verbosity (E.g.:Set-OfficeWebAppsFarm -LogVerbosity 'Unexpected') of the farm and review the changes within the template file.

The workaround

First of all, keep in mind this is not an official fix and am not responsible of any issues it could create.

2 possible workarounds :
1/Reset the log verbosity of the farm to either “Medium” or nothing
2/ In order to have the machines in a healthy state while having “Unexpected” log verbosity, you must change the log configuration template file.

  • Make sure your farm’s logging level is set at its default value which is literally nothing.
    Set-OfficeWebAppsFarm -LogVerbosity ''
  • Restart the service so that changes are applied
    Restart-Service WACSM
  • Make a copy (for backup purpose) and then open the file located here : `drive:\Program Files\Microsoft Office Web Apps\AgentManager\uls.config.dynamic.xml`.
  • Find and replace all entities of “Medium” by “Unexpected”.
    This will change the ULS tracing level from the Out-Of-The-Box “Medium” to “Unexpected”
  • Find the category “**Uls Controller Watchdog**” under the “Services Infrastructure” area.
    Set the “**TraceThreshold**” option to “Medium”

    <Category Name="Uls Controller Watchdog" TraceThreshold="Medium" EventThreshold="Verbose" />
  • Restart the OWAS service
    Restart-Service WACSM
  • Be patient. The watchdog processes may take 5 to 10 minutes before changing the state. Here’s a quick one-liner :
    While((Get-OfficeWebAppsMachine)[0].healthStatus -eq 'Unhealthy'){write-host '.' -NoNewline;Start-Sleep -Seconds 30}

Ironically, the TechNet article states this about the log verbosity (under the LogVerbosity Parameter) :

 Leaving the LogVerbosity at a low level for a long time will adversely affect performance.

Knowing that, for healthy servers report,  the highest  level you can set is “Medium”, just one level above “Verbose” which is kind of awkward.

ULS Error message related to this bug

We're about to trace a string for category MsoSpUlsControllerWatchdog at level Info and we expect to find in the log later, but it appears that the category has been throttled. We will never be able to find the string and this watchdog will always fail.

Health report by UlsControllerWatchdog: Agent: UlsController, eventId: 1204, eventType: Error, categoryId: 1, eventMessage: &lt;?xml version="1.0" encoding="utf-16"?&gt;  &lt;HealthReport xmlns:xsd="" xmlns:xsi=""&gt;    &lt;HealthMessage&gt;UlsControllerWatchdog reported status for UlsController in category 'Verify Trace Logging'. Reported status: Could not find trace string in ULS logs in C:\SPDisks\Logs\ULS.&lt;/HealthMessage&gt;    &lt;ComponentOwner&gt;ServicesInfrastructure&lt;/ComponentOwner&gt;  &lt;/HealthReport&gt;