SharePoint & Microsoft 365

Office Online Server Says This Machine Is Not Part of a Farm

Diagnose an Office Online Server farm-membership error safely, recover the supported topology, and avoid destructive rebuilds based on guessed settings.

Collab365 Team · 23 December 2016 · Updated 24 August 2026 · 3 min read

“It does not appear that this machine is part of an Office Web Apps Server farm” means the local server cannot return a valid farm configuration. Do not immediately create a new farm. First establish whether this is an old Office Web Apps Server deployment, a current Office Online Server farm, or one unhealthy node in a multi-server topology.

This is an on-premises server article. It does not apply to Office for the web in Microsoft 365.

Start with the service boundary

Office Web Apps Server was succeeded by Office Online Server. The product provides browser viewing and editing to SharePoint Server and other on-premises products. Its farm is separate from the SharePoint farm.

Record:

  • the product and installed build on every node
  • whether the farm has one server or several
  • internal and external URLs
  • certificate subject, expiry and thumbprint
  • load-balancer pool and health-check configuration
  • the SharePoint WOPI binding
  • the last known working time and recent patches

Do this before changing the topology. A guessed New-OfficeWebAppsFarm command can produce a different farm that appears healthy locally but no longer matches DNS, certificates or SharePoint bindings.

Check whether the machine can read its farm

Open the Office Online Server PowerShell console as an administrator and run:

Get-OfficeWebAppsFarm
Get-OfficeWebAppsMachine

If another farm node is healthy, run the same commands there and preserve the output. Compare services, event logs, certificates, bindings and installed updates.

Also check:

  • relevant Office Online Server services
  • Windows Event Viewer
  • IIS application pools and sites
  • free disk space and certificate validity
  • whether endpoint security or policy changed
  • whether every node received the same supported update

High CPU or repeated WerFault.exe processes are symptoms, not a diagnosis.

If the problem started during patching

Microsoft's Office Online Server update procedure is topology-aware.

For a single-server farm, Microsoft says to remove the server from the farm, apply the update, and recreate the farm. Users cannot use Office Online during that maintenance.

For a multi-server farm, Microsoft describes removing a server from the load balancer and farm, updating it, creating the updated farm, and then moving the remaining nodes through the process. Follow the full procedure for your topology rather than patching every node simultaneously.

Turning off operating-system or product updates is not a safe fix.

Decide the recovery route

A healthy node still exists

Use the healthy node as the source of truth. Cleanly remove an unhealthy node with the supported cmdlet where possible, update it to the farm's required level, and join it back using the documented configuration.

Microsoft notes that Repair-OfficeWebAppsFarm removes servers flagged as unhealthy from the topology, but does not clean up their local services and web applications. Prefer a clean removal from the unhealthy server when that route is available.

No node can return the farm

Recover the original parameters from configuration records, certificates, DNS, load-balancer settings and backups. Then use Microsoft's deployment procedure to rebuild deliberately.

Do not copy an example -InternalURL, -ExternalURL, -CertificateName or -AllowHttp value into production. Those values define the trust and traffic boundary.

Prove the service, then prove the integration

After recovery:

  1. confirm Get-OfficeWebAppsFarm returns the intended topology
  2. check the discovery endpoint through the same route SharePoint uses
  3. confirm the load balancer sees every expected node as healthy
  4. open supported Word, PowerPoint and Excel files from SharePoint
  5. test view and edit paths with representative user permissions
  6. inspect Office Online Server, IIS and SharePoint logs

A successful farm command proves local configuration can be read. It does not prove that SharePoint, certificates, DNS and the load balancer are correctly integrated.

Sources

For practical on-premises and Microsoft 365 administration discussions, join the SharePoint & Teams Admins Space.