Microsoft Sharepoint 2013 : Office Web Apps Configuration Options (part 6) - Binding to a SharePoint Farm Using HTTPS

Binding to a SharePoint Farm Using HTTPS

Now that you have completed building an Office Web Apps farm using the HTTPS protocol, you must bind it to the SharePoint 2013 farm. Creating the binding is relatively straightforward; just keep in mind the previously mentioned SSL complexity included with this configuration. An important consideration in step four is to note the zone you will be setting up is a secure configuration.

New-SPWOPIBinding –ServerName owa.contoso.com

Set-SPWopiZone –Zone "internal-https"

Now that you have completed building an Office Web Application farm using the HTTPS protocol, you must bind it to the SharePoint 2013 farm. Creating the binding is relatively straightforward; just keep in mind the previously mentioned SSL complexity included with this configuration. In this example, you will bind SharePoint to the Office Web Apps farm internally using the Set-New-SPWOPIBinding PowerShell cmdlet. Then the zone for that binding connection is declared using the Set-SPWOPIZone cmdlet. There are four possible zones for Set-SPWOPIZone: internal-http, internal-https, external-http, and external-https. HTTP zones should be reserved for testing, strictly trusted, or fully encrypted internal networks. In production, HTTPS zones are almost always the best choice. For this exercise internal-https was chosen because all the communication is happening internally on the same network. If the communication between the SharePoint farm and the Office Web Applications farm travels over the Internet or any public network, external-https would be more appropriate.

Removing a Binding

Sometimes as a good administrator you like to “tinker” with your SharePoint server. Of course, you always use a lot of VM snapshots and would never “tinker” with a production farm, especially when trying to deploy Office Web Apps, but in case you ever find yourself in a pickle while playing with the two, there is a way to undo most of the damage. You can run the following command from the SharePoint Management Shell to remove the binding:

Remove-SPWOPIBinding -ALL

After running that, you can go back to tinkering with the New-SPWOPIBinding cmdlets from the previous sections.

Scaling Office Web Apps

The Office Web Apps service is a now run as a farm configuration. In the previous examples you created an Office Web Apps farm, but that farm only contained a single Office Web Apps server. This is adequate for most small SharePoint 2013 farms, but it would not be enough for larger, more complex configurations that place a premium on uptime and quick responses. To add scale and provide fault tolerance, you need to leverage a load balancer and multiple Office Web Apps servers. The load balancer addresses the fault tolerance requirement using those same multiple servers. Once you have established an existing Office Web Apps farm, you can use the Office Web Apps PowerShell cmdlets to add additional servers. After installing the Office Web Apps software on the server, you can attach it to the farm by using the following command:

New-OfficeWebAppsMachine –MachineToJoin OWAServer2.contoso.com

Office Web Apps Patching

Another primary advantage of moving Office Web Apps to a standalone farm is evident during the patching process. Because the previous version of Office Web Apps was fully integrated into SharePoint, there was no feasible way to patch the Office Web Apps without causing a major interruption to the SharePoint farm, meaning taking all of SharePoint offline while you patched. It is now possible to patch the Office Web Apps farm with only minimal interruption to any of the applications to which it provides services, such as SharePoint or Exchange. As with everything in OWA patching, it is not performed via a GUI but rather via the Office Web Apps PowerShell cmdlets.

The unique thing about the patching process is that you actually remove a server from the farm, patch it, and then add it back to the farm. Rinse and repeat for all the servers in your farm. So if you build your OWA farm with more than one server, you should be able to avoid any downtime. To patch the master server, you need to use the Set-OfficeWebAppsMachine –Master PowerShell cmdlet.