For Exchange 2016, a couple of things have changed. Namely, Office Web App server is now called Office Online Server which is currently in preview. Outlook Web App is not known as Outlook on the web.
When it comes to installing Office Online Server, it isn’t much different from Office Web App Server installation process. The process is documented here. While the article applies to preview version, I don’t expect it to change much. If you need to configure Office Online Server farm, you can check out my previous article. While it is written for Office Web App server, it is applicable to Office Online Server farms as well. You should also load balance the farm, which I documented previously as well and is still applicable.
So assuming you have Office Online Server farm configured, let’s take a look at how to setup Exchange 2016 to work with it.
Exchange 2016 Greenfield deployment:
In a new Exchange 2016 deployment, you have a choice of configuration. If you want to just test rich attachment preview before releasing it company wide, you may want to configure it per server so that you can control who will see rich attachment preview in Outlook on the web. We will cover this later in this article. For now, let’s check out second option which is to enable rich attachment preview for entire organization. The setting is as simple as running the following:
Set-OrganizationConfig -WacDiscoveryEndpoint https://oos.contoso.com/hosting/discovery
Make sure the Exchange 2016 server can resolve URL oos.contoso.com and can reach the resolved endpoint on the network. This is why the TechNet article refers the URL as oos.internal.contoso.com.
Now you have to let the change replicate, which may take anywhere from mere seconds to a while depending on your Active Directory configuration. The TechNet article also calls for restarting OWA App pool in IIS. I think that applies to those who don’t want to wait and I believe if you wait for configuration to be picked up automatically, you may not need to restart app pool at all. YMMV. Test it instead of hoping it will work in production.
Once the change takes place, you should be able to logon to Outlook on the web, click on email with attachment that contains Office document such as a word file and you should see the document preview in the browser. Here’s what it looks like:
If you have set the Office Online Server farm to allow editing (include -EditingEnabled:$True when creating farm of run Set-OfficeWebAppsFarm -EditingEnabled:$True after the fact), you will also be able to edit the document right in the browser:
Awesome, isn’t it!
Exchange 2016 deployment in co-existence:
Well, so that was greenfield. What about the environment where Exchange 2016 is co-existing with Exchange 2013 servers?
The process here is little bit different. Since Exchange 2016 required Office Online Server for document preview and editing, while Exchange 2013 relies on Office Web Apps servers, you can’t configure WacDiscoveryEndPoint parameter on Exchange organization like you did earlier for Exchange 2016 greenfield environment. If you do, expect problems. You should instead run the following on each server:
Set-MailboxServer “ServerName” –WacDiscoveryEndPoint http://appropriate(wac or oos)serverurl/hosting/discovery
If you want rich attachment preview only on Exchange 2016 servers, run this cmdlet on Exchange 2016 servers and use Office Online Server farm url for discovery endpoint.
If you are also want to enable rich attachment preview on Exchange 2013 servers, run the same cmdlet for Exchange 2013 servers and use Office Web App server farm url for discovery endpoint.
You want granular control so that you can enforce in-browser viewing of attachments when user is on public or private computer, you can configure the setting per server by running Set-OWAVirtualDirectory cmdlet. You can read more details on this TechNet article.
And lastly, if you are deploying Exchange 2016 across multiple datacenters, make sure to create unique namespace for OOS/WAC farm for each datacenter. This will help keep attachment preview related traffic local to where the user mailbox is active, improving performance. Check out document collaboration section on this article from Ross Smith IV on the Exchange Team Blog.