I just wanna learn!


Renewing the expired Office Online/Web Apps Server farm certificate

Certificates sometimes expire... it happens! 🙂

But what happens if the certificate for your Office Online Server (OOS) or Office Web Apps Server (OWAS) farm expires and your farm is not available anymore?

Obviously, OOS farm and your Skype for Business, Exchange & SharePoint integration stops working. Next thing to do will be to renew the expired certificate.

But how?

My MVP colleague Andi Krüger did a nice blog post on updating the farm certificate, and it's fairly simple - Set-OfficeWebAppsFarm -CertificateName "RenewedOOSInternalCertificate" should do the trick... if your farm is running.

If things got out of hand and your farm is not running anymore and you cannot use the Set-OfficeWebAppsFarm cmdlet (you'll see that Office Online (WACSM) service is Stopped and cannot be brought back up with the expired certificate and your machine is showing that it's no longer part of the farm), you'll need to take a different approach, because you'll be getting errors when running the above mentioned command (like "It does not appear this machine is part of an Office Online Server farm." or similar).

WACSM Service is Stopped and and your machine is showing that it's no longer part of the farm

One of the possible solutions would be:

  • make a note of the Friendly Name of your old (expired) certificate (MMC or PowerShell) (in my case it's called "OOSInternalCertificate")
  • remove the expired certificate
  • renew/request/install the new certificate
  • change the Friendly Name of a new certificate to match the previous one
  • start the Office Online (WACSM) service or restart the machine
  • (copy the certificate/do the procedure on other farm members, if needed)

Everything is back normal

Your farm operations should now be restored and you can run Get-OfficeWebAppsFarm cmdlet normally:

Or you can open up the farm's discovery URL - if it's rendering again, everything should be OK (in my case "https://oos.myfarm.local/hosting/discovery"):

Even the discovery works



Basic SharePoint load balancing

I’ve recently created a simple lab which gave me some answers around load balancing a SharePoint 2016 farm with SSL offloading.

To start, I’ve created a couple of virtual servers (on top of my “supercool home Windows Server 2016 Hyper-V PC” Smile) – a domain controller, a SQL server and two SharePoint servers. I’ve also downloaded a KEMP LoadMaster appliance (there is also a free one here, which would have been just enough for this lab) and prepared my DigiCert wildcard certificate (there is no need for the wildcard option, but this is the one I already have, so I’ve decided to use it).

So… I’ve prepared a domain controller, joined all the other servers to the domain and then installed SQL Server 2016. After that, on SharePoint servers, I’ve ran a preparation wizard and created a new SharePoint farm from the first node… with second node joining to it later. At the end, I’ve done the “Farm configuration” wizard and was all set to do the load balancing part. (And yes – I know that clicking “Next” is lame, but… it works. Smile)

The networking configuration for this lab is pretty simple. I have two VLANs – 111 (backend, where all the servers are residing) and VLAN 101 (frontend, where my LB virtual servers are).

I’ve created a new virtual machine for the load balancer, attached it to the two mentioned networks and also added the virtual disk downloaded from KEMP’s website.


After that, I’ve done the initial configuration wizard of LoadMaster which is actually straight-forward (setting the password, IP addresses, and importing a certificate afterwards).

With this done, we can create our virtual service(s) – there is actually a great guide for configuring the SharePoint load balancing virtual servers with KEMP LoadMaster.

I’ve used the following basic (manual) settings for my virtual service:


HINT: When troubleshooting load balancing – make sure that you have only one node behind the balancer… it makes things so much easier to troubleshoot! Smile

One last thing that wasn’t working with this “Next, Next, Next…” configuration was the Alternate Access Mappings (AAM) part – to be able to access a SharePoint farm over HTTPS and a public name, AAM should “know about it”. There is a great guide about AAM available – make sure you read it.

Default AAM settings for my farm were:


After (a lot) of troubleshooting and research, they were changed to this:


And… that’s it – it works! Smile

My totally awesome SharePoint 2016 site, located behind a load balancer and published with a trusted certificate (with SSL session terminating on my virtual KEMP load balancer), was alive:


To conclude - in all the configuration that was done, setting the AAM right was something that gave me most of the headache (load balancing/redirections not working right, troubleshooting what’s happening, etc.). Pay special attention to it! Once you figure it out, you’re done. Smile