Office Online Server - discovery returns wrong name


Okay here is our scenario:

Loadmaster with two legs - Internet on 172.16.x.x, Real servers in 10.x.x.x

OOS server on 10.x.x.100

OOS server is part of a domain call foo so has a FQDN of

We have given it a simple name (and extra A record in DNS) of in both internal and external (public) DNS.

We have set the URL on OOS to

If internally we browse directly to then the xml shows us as expected.

If internally we browse directly to http://10.x.x.100/hosting/discovery then the xml shows us presumably because a reverse DNS lookup has occurred.


We configure Loadmaster to offload the SSL and have a redirect in place. I am using with the Lync Office Web App Servers 2013 template.

Sharepoint is set to serve HTTP True with SSLOffloaded to True

If we EXTERNALLY browse via Loadmaster to the xml shows us as if we are browsing via ip address.


I note that the Real Servers entry shows that the IP address resolves to the FQDN so tried adding a hosts file entry via the webadmin. This updated the Real Servers display to show instead. It did not change the resulting xml though. 

We are trying to use OOS with our Sharepoint but this is failing with the SP generated links (which are http - which are then redirected). We believe this is due to the above.

Anyone seen and solved this with OOS or Office Web Apps ?








Tony Vaughan

Hi Ian,

to recap

you have a virtual service that is listening on HTTPS port 443 which uses SSL-Offload to send traffic to the office online server on HTTP port 80
you mentioned that when using Office-Online-Server with SharePoint this is failing with the SP generated links (which are HTTP - which are then redirected)

are the links themselves failing to be created or is it that you expect a different URL?
for example you would expect a HTTPS URL instead of a HTTP URL?


Hi Tony,

Yes, your summary in the first paragraph is correct.

When used internally (sharepoint and OOS - both http, direct) everything works fine.

What we used with Sharepoint via Loadmaster (https redirect) and OOS via loadmaster (https redirect) we get:

...which unfortunately isn't very revealing !

During our diagnosis we noticed that going to (via loadmaster) give us instead of the expected

If we browser internally directly to we get as expected.

Here are my VS setting for OOS

And my redirect


Thanks for the continued help !