Sharepoint 2013 : The Office Web Applications for Sharepoint - Topology

Office Web Apps has moved from an exclusive SharePoint service onto its own standalone server. This change is critical to how you configure and architect Office Web Apps to service the SharePoint 2013 farm. The primary benefit of this topology change is that Office Web Apps can offer its services not only to SharePoint 2013, but also to Lync 2013, Exchange 2013, and anything else that can be connected through its WOPI interfaces.

Because it is separate, Office Web Apps are served up from their own farm, much like SharePoint. This enables you to build and scale your OWA infrastructure to meet your needs. Much like a SharePoint farm, your OWA farm can be configured with everything on one server or separated onto multiple servers. If you have multiple servers in a farm, they must leverage a hardware or software load-balancing solution, however, as OWA does not include that capability with the product. Each server within the Office Web Apps farm contains a copy of the farm settings, but only one server can act as the authoritative Master Machine for the Office Web Apps farm. A copy of the farm settings from the Master Machine is made available to other subordinate Office Web Apps servers within the farm on a regular basis.

Office Web Apps Logical Configuration

Now that Office Web Apps 2013 has been moved from the SharePoint farm to its own standalone farm, a separate logical container is required. This logical container concept is based in the Web application Open Platform Interface (WOPI). It enables the Office Web Apps farm to act as a WOPI app, and other server programs such as a SharePoint 2013 farm act as a WOPI host. While this may be contrary to what you typically conceptualize as a host and app relationship, it actually reflects the scheme quite accurately. Consider that the users of SharePoint never directly interact with Office Web Apps servers, which need the SharePoint 2013 farm to act as host, which in turn consumes the WOPI app from the Office Web Apps farm. This logical configuration enables the integration with not only SharePoint 2013, but also Exchange 2013, Lync 2013, Windows files shares, and even custom third-party applications.

Office Web Apps Farm Guidelines

Whether you have one server farm or multiple farms, it is important to keep the following guidelines in mind:

• Keep the Office Web Apps farm close to its servicing applications. If separated by any distance, such as separate data centers, you will see a degradation of performance when opening and editing documents.
• Servers within the Office Web Apps farm must be within the same geographical area. Typically, one farm will be able to accommodate most configurations, but security might require an isolated configuration with its own Office Web Apps farm.
• All servers in an Office Web Apps farm must be able to communicate with each other. This is addressed in greater detail in the section “Firewall Considerations for Office Web Apps.”
• All servers in an Office Web Apps farm must be in the same Active Directory organization unit (OU).
• Servers in an Office Web Apps farm may be virtualized. The following section provides greater detail.

Roles for Office Web Apps Servers

In large and highly customized Office Web Apps farms, consider giving each Office Web Apps server a specific role. By default, every Office Web Apps server has all roles installed and ready for use. However, you can limit, or specialize, a specific Office Web Apps server to a specific role. This should only be done if your farm has a particular performance requirement. For example, maybe your SharePoint 2013 farm has a high demand for Excel Web App services because Excel is used extensively throughout the farm.

In general, it is recommended that you allocate Office Web Apps servers to specific roles only when your farm exceeds 10 Office Web Apps servers and you have noticed performance degradation. As you might expect, an Office Web Apps server can be specialized into the following roles:

• Front End
• Excel Back End
• Word Back End
• PowerPoint Back End

These role names are self-explanatory. For example, an OWA server dedicated to the Word Back End role would process requests only for the Word Web App. The specific role of the Office Web Apps Front End server is to control the communications of the Farm State traffic between the servers within the farm.

Security Considerations

The Office Web Apps can leverage either the HTTP or the HTTPS protocols. Using the HTTP protocol may be appropriate for test configuration farms, but for live production data it is recommended that you use the secure HTTPS protocol. If HTTPS is chosen as the primary communications mechanism, then each Office Web Apps server must contain the appropriate valid SSL certificate, or it must be offloaded via a properly configured load balancer. The Office Web Apps farm can communicate with SharePoint 2013, Lync 2013, and Exchange 2013 over HTTPS. Whereas SharePoint 2013 and Exchange 2013 will work on the HTTP protocol, Lync 2013 only allows HTTPS.

You can further control your Office Web Apps farm, preventing exposure of sensitive documents. The first step is to set your Office Web Apps farm’s allow list. Using the New-OfficeWebAppHost cmdlet, you can add entries to the allow list as shown here:

New-OfficeWebAppsHost –domain "contoso.com"

Once this Office Web Apps PowerShell command is executed, only requests from the contoso.com domain will be honored. Conversely, using the Remove-OfficeWebAppHost cmdlet removes entries in the allow list. If the Office Web Apps’ allow list is left empty, it will respond to any request regardless of originating domain. This is an important consideration if the Office Web Apps farm is exposed to the Internet.

Next, you can leverage a specific Active Directory organization unit (OU) for your Office Web Apps servers. Once implemented you can prevent a rogue Office Web Apps server from joining the farm by using the FarmOU parameter with either the New-OfficeWebApps cmdlet when building the farm or the Set-OfficeWebAppsFarm cmdlet of an existing farm, as shown in the following example:

New-OfficeWebAppsFarm –InternalURL https://server.contoso.com -EditingEnabled:$true
 –FarmOU "OU=OWA Servers,DC=Contoso,DC=com"

The preceding example builds a new Office Web Apps farm for internal use only using a secure URL protocol, https://server.contoso.com. It also enables editing, and limits access to Office Web Apps servers that are specifically in the “OWA Servers” OU.

The next example assumes you already have an existing Office Web Apps farm in place. In this case, you are specifying that all Office Web Apps servers must be part of the “OWA Servers” OU:

Set-OfficeWebAppsFarm –FarmOU "OU=OWA Servers,DC=Contoso,DC=com"

Virtualizing Office Web Apps Servers

Virtualization is commonplace in many data centers, and Office Web Apps 2013 has no problems running in this type of configuration. While not requirements, the following recommendations should be followed:

• No other server software should be installed on the Office Web Apps server. This includes SharePoint, Exchange, or even the workflow engine. The server should be dedicated to OWA.
• You can, as needed, install Office Web Apps server as a guest on the same physical server (host) that has a SharePoint guest.
• When redundancy is a concern, each virtual instance of the Office Web Apps server should be hosted on different physical servers (hosts).

Firewall Considerations for Office Web Apps

Firewalls that block traffic are often the source of communications issues that prevent Office Web Apps from offering its services. Keep the following guidelines in mind when setting up an Office Web Apps farm:

• If unsecure communications exist between the SharePoint farm and Office Web Apps server, keep port 80 open for HTTP communications.
• If secured communications exist between the SharePoint farm and Office Web Apps server, keep port 443 open for HTTPS communications.
• If there are multiple servers in an Office Web Apps farm, ensure that port 809 is open between Office Web Apps servers to allow for proper operation.

Load Balancing an Office Web Apps Farm

If you have multiple servers within an Office Web Apps farm, it is important to provide a mechanism for load balancing. Whether your load balancing solution is software of hardware, it should include the following features:

• Layer 7 routing
• Client affinity, or so-called sticky session
• SSL off-loading

DNS Requirements

As you might expect, proper DNS can be critical for Office Web Apps services. When setting up an Office Web Apps farm using HTTPS, the DNS must be configured to a fully qualified domain name (FQDN) — either the single Office Web Apps server or the virtual IP of the load balancer servicing the Office Web Apps farm. When using nonsecure communication, the same DNS routing applies, but a FQDN is not required.