Installing & configuring Office Online Server with Exchange 2016 / 2019

9 min readFeb 1, 2019

In this blog, I will review the installation and configuration process of Office Online Server 2016 (OOS) with Exchange 2016 / 2019 environment.
Using Office Online Server 2016 with Exchange 2016 or Exchange 2019, you will be able to view and even edit Office documents via Outlook on the Web (OWA).
Office Online Server is a very good solution for places where a full Office distribution is a challenge because of old hardware, slow internet connections and other technological challenges.

You to enable In my environment I’m using:

2 Exchange 2019 servers running on Windows 2019 Core servers.
2 Exchange 2016 servers.
1 Office Online Server 2016 running on Windows 2016 Server (November 2018 Version).

Please pay attention, that only Exchange 2019 & Exchange 2016 can work with Office online Server 2016.

Except for the OOS installation and configuration, we will review the steps that needs to be taken within the Exchange 2019 environment and the ways to verify that the collaboration between OOS & Exchange is working.

Preparing for Office Online Server 2016 deployment

Office Online Server can be download from VLSC or MSDN (depends on your needs) in many languages:

There are many things that should be considered before deploying OOS, like Sizing, Virtualization, Ports, Load Balancing for high availability, Firewall and other security considerations.
In this blog I will not review all of those, but you can find all of them at the next link:
https://docs.microsoft.com/en-us/officeonlineserver/plan-office-online-server

Prerequisites:

Office Online Server can run (for now) on Windows server 2012 R2 and Windows 2016 only.
From Windows PowerShell, use this command to install the required roles and services (for Windows 2016 Server):

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,NET-Framework-Features,NET-Framework-45-Features,NET-Framework-Core,NET-Framework-45-Core,NET-HTTP-Activation,NET-Non-HTTP-Activ,NET-WCF-HTTP-Activation45,Windows-Identity-Foundation,Server-Media-Foundation

In addition, install the following prerequisites software:

.NET Framework 4.5.2

Visual C++ Redistributable Packages for Visual Studio 2013

Visual C++ Redistributable for Visual Studio 2015

Microsoft.IdentityModel.Extention.dll

For more information regarding OOS Prerequisites, please visit the next link: https://docs.microsoft.com/en-us/officeonlineserver/deploy-office-online-server

Installing Office Online Server 2016:

After installing the prerequisites, you can continue with the OOS installation, which is very simple and short, just run the ISO file as the next example:

Now choose the installation location in case you would like to change it:

Click on Install Now:

Now click Close to exit the installation:

Configuring Office Online Server 2016:

After installing was completed, you should consider a common name that will be used on your environment, in order to access the OOS “Farm”.
OOS farm is the location where all users will be directed to (behind the scenes) to view and edit Office documents,
In real life you should consider working with a load balancer that will provide high availability to the OOS services.
In my environment, I will use a DNS record named OOS.msft.net that will point to my OOS server named OOS1. In case I would have more OOS servers, I would have created more DNS records that would point the name OOS.msft.net to the other servers.

Certificate:

In order to access OOS services via SSL 443, we need to issue and install a certificate, according to the name we have chosen earlier (OOS.msft.net).
I have already included at my Exchange’s servers certificate the name OOS.msft.net therefore in this example I don’t need to issue a new dedicated certificate, although it is the most recommended way in real life.
In this example, I will install the certificate named mail.msft.net from the PFX (private key) that I prepared in advanced (cert.pfx):

Verify that you choose Local Computer and NOT Current User

Choose the pfx location, than click Next:

Enter the password for the pfx and click Next:

Click Next:

Click Finish:

Click OK

In order to verify that the certificate was installed successfully, open the Certificates on the local computer and check that the certificate is located under the Certificates (Local Computer)\Personal\Certificates

OOS Farm configuration:

In order to configure the OOS farm, open the Windows PowerShell on the OOS server as an Administrator and run the following command, according to the common name you have chosen for internal and external URLs for OOS services and the certificate name you have installed earlier:

New-OfficeWebAppsFarm -InternalURL “https://oos.msft.net" -ExternalURL “https://oos.msft.net" -CertificateName “mail.msft.net”

You can see that the default configuration for editing is set to false (marked with yellow).
For now, I will leave this configuration as is.

Configure Exchange Server 2019 with OOS services

After we have set and configured OOS farm, we need to set the Exchange servers to “discover” the new farm.
We can configure it in two ways:

Configure each server (Exchange 2016 / Exchange 2019):
We will use this option in case we are having Exchange 2013 servers in our environment and not only Exchange 2016 / Exchange 2019.
Since Exchange 2013 is not able to work with OOS 2016 (and it is not supported as well), we will have to rune the following command on every Exchange 2016 / Exchange 2019 and not at the organizational level (like the next example)
Set-MailboxServer MBX -WacDiscoveryEndpoint “https://oos.msft.net/hosting/discovery"
Configure the Exchange organization:
We will use this option in case we are having only Exchange 2016 / Exchange 2019 servers.
Since Exchange 2013 is not able to work with OOS 2016, we will have to rune the following command on every Exchange 2016 / Exchange 2019 and not at the organizational level (like the next example)
Set-OrganizationConfig -WacDiscoveryEndpoint “https://oos.msft.net/hosting/discovery"

As I mentioned earlier, we will run the second option against our Exchange organization:

After you have configured the OOS “discovery” URL at the organizational level, we must refresh the new configuration on ALL Exchange servers using the next command:

Restart-WebAppPool MsExchangeOwaAppPool

Verify that Exchange Servers are able to access & discover OOS services correctly:

After we have set and configured the Exchange organization with OOS services, we must check that the Exchange servers can access & discover the new services.

Check that we can access the WAC discovery end point correctly from the Exchange servers: https://oos.msft.net/hosting/discovery
WAC discovery endpoint is very similar to Exchange’s Autodiscover service which allows other systems to get the information that the server is delivering.
In order to so we should open a browser (On Exchange 2016 / Exchange 2019 with Desktop).
This option is not available on Exchange 2019 which installed on Windows 2019 Core server…..

It is very important to get the discovery output WITHOUT any certificate errors!
In case you are having an issue with a certificate on the OOS servers, you will not be able to access the OOS services!

Check the event viewer of the Exchange servers and verify that events 140 and 140 and 142 exists at the Application event log.

By the way, in case that you are working with Exchange 2019 on Windows 2019 Core server, you can connect to the event log from remote, or check the events using PowerShell:

Event 140:

Event 142:

Testing OOS services:

After we have configured all the settings on OOS & Exchange servers, we can test and see if we can view / Edit Office documents via OWA.
I have sent a word document from Administrator to EXADM.
You can see that now I’m having the option not only to Download the document, but also to Preview:

When I click the Preview option, the document will be opened side by side with the email it was attached to:

In order to edit the document, I just need to click on Edit and Reply:

Since we didn’t allow the option to edit during the OOS Farm configuration.
By the way, we will get the same error in Hebrew, in case you have installed the Hebrew version of OOS:

In case that you would like to allow users to edit Office documents via OWA, run the following command at one of your OOS servers:

Set-OfficeWebAppsFarm -EditingEnabled:$true

Opening OWA again and we can see that the users are able to edit the document:

And also in Hebrew…..

Now, the user can edit the document, change it and send it:

In case that you would like to keep the allow part of the users to edit Office documents, but prohibit another part of the users to edit, you can use the OwaMailboxPolicy option.
OWAMailboxPolicy is not set for any mailbox, unless you as an Administrator configured it.
The default settings for users, is to allow editing documents.

In this case, the OOS Farm set to allow users to edit Office documents.
User Tkolber has an OwaMailboxPolicy which called FileAccess.
You can check it, by running the next command:

Get-CasMailbox Tkolber | fl owamailboxpolicy