Welcome back. If you’ve read the first two posts in this series (Part 1, Part2), then your caught up. If not, I’d suggest you go back to those before proceeding on with this one. In this post, we’re going to talk about some new information about OOS, and some points I missed in the first two parts.

Office Online Server and Exchange Versions

While reviewing the first two posts in this series, I notice I didn’t really specify the supportability statement for OOS and Exchange versions. I’ll correct that omission here; Office Online Server is only supported to work with Exchange 2016.

In Part two, I stated that one of the last deployment steps for OOS is to set the WAC discovery endpoint via the Set-OrganizationConfig PowerShell command as below:

 Set-OrganizationConfig –WACDiscoveryEndPoint https://oos.mcsmlab.com/hosting/discovery

While that command will work, this new information about OOS only being supported for Exchange 2016 presents a bit of a problem for that command. Set-OrganizationConfig is, obviously, a command that applies to all Exchange servers in your Active Directory forest. If you’re in a coexistence scenario with Exchange 2016 and either Exchange 2010 or Exchange 2013 then it’s not a very good idea to run this command as those older versions of Exchange should not try to use OOS.

The solution to this problem is to use a different, more specific, PowerShell command to configure your Exchange 2016 servers to use your new Office Online Servers. Below is the command to set a single Exchange 2016 server to use your Office Online Server:

 Set-MailboxServer MBX –WacDiscoveryEndpoint "https://oos.mcsmlab.com/hosting/discovery"

Once that is done, you’ll need to restart your application pool as below:

 Restart-WebAppPool MsExchangeOwaAppPool

Of course, the downside to making this configuration server by server is that you may forget to run it on one or more servers. Take care to make sure you don’t make that mistake during your Exchange 2016 deployments to ensure a consistent experience for you users.

Multi-site deployments

In the first two parts of this series, I explained how to deploy Office Online Server in a single site. I didn’t really address it as such, but I didn’t make any specification for deploying OOS in more than one site. Here I’d like to correct that omission, and talk about the considerations for deploying OOS in support of a multi-site Exchange deployment.

The Exchange Preferred Architecture recommends an unbound namespace for Exchange 2016 deployments. That means using mail.contoso.com as the endpoint for all Exchange servers in a multi-site deployment instead of using east.mail.contoso.com and west.contoso.com namespaces.

Office Online Server, however, will not support an unbound namespace. For OOS, you’ll need to deploy a bound namespace for each datacenter. This is another reason to set your WacDiscoveryEndpoint at the server level and not the organization level.

Load balancer configuration

Another consideration is that Office Online Server requires cookie-based load balancer persistence. Exchange 2016 still does not require any form of persistence, but you’ll need to ensure it is setup for OOS.

Hybrid Configuration for Office Online Server

As I stated in Part 1, you don’t need on-premises SharePoint 2016 to get the modern attachment features to work with Exchange 2016. Instead, you can use SharePoint Online as the document store for your Exchange 2016 attachments.

I have recently learned that Microsoft recommends a full Exchange Hybrid configuration be done from your Exchange 2016 server to get this scenario setup. This might seem a bit excessive if you do not intend to move mailboxes to Office 365 and just want to use SharePoint Online to support modern attachments with your on-premises Exchange 2016 servers, but the Hybrid Configuration Wizard really is the best way to get the necessary OAuth configuration done.

The requirements for this configuration are as follows:

• All user’s mailboxes need to be on Exchange 2016 to get the modern attachment experience.

• The Hybrid Configuration Wizard needs to be run to configure OAuth. It is technically possible to configure OAuth without using the HCW, but it’s not recommended.

• Users must be licensed for SharePoint Online or OneDrive for Business within Office 365.

The steps to configure modern attachments after these requirements are met are:

1. Setup the Outlook on the web mailbox policy with PowerShell

   Set-OwaMailboxPolicy NewPolicy -InternalSPMySiteHostURL https://Contoso-my.sharepoint.com -ExternalSPMySiteHostURL https://Contoso-my.sharepoint.com

    

2. Next apply the new web mailbox policy to the users you want to have the modern attachment experience, or make it the default for all mailboxes

   Set-OwaMailboxPolicy NewPolicy –IsDefault

   Or

   Set-CASMailbox <user mailbox> -OwaMailboxPolicy NewPolicy

    

3. Restart the web application pool to ensure these settings take effect immediately

   Restart-WebAppPool MSExchangeOWAAppPool

    

4. After the configuration is done, you can check the details via

   Get-OWAMailboxPolicy | FL *wac*, *SPMY*

If there are no mailbox policies setup, the virtual directory settings will apply.

Troubleshooting Office Online Server

While it seems unlikely, more so for you who have read all my excellent deployment guidance, there is an outside possibility that someone will eventually have some sort of problem with Office Online Server that will require troubleshooting.

My first advice if you find yourself in this situation would be to go back through the deployment steps and ensure you’ve got everything setup properly.

After verifying your Office Online Server is properly deployed, the places you can look for troubleshooting information include event viewer logs and client side traces (from tools like fiddler). Since OOS is still a pre-release product, you can expect better troubleshooting guides to come in the future.

If you have any questions, please let me know in the comments below.

-Nathan