Lync 2013 Office Web Apps Server Farm

<Revised 8 Feb 2013>

As Lync 2013 becomes more of a reality to many of us, we must address what is, in my opinion, the biggest change to Web Conferencing:  the requirement for Office Web Apps Server (WAS).  Microsoft has addressed a few display/usability issues in Web Conferencing with the inclusion of  WAS.  WAS is now the PowerPoint presentation rendering engine for Web Conferencing.  You can deploy your pool without it, but your Web Conferences will not do PowerPoint presentations.  Because PowerPoint presentations are a big part of most formal presentations, we need to deploy WAS as part of the pool.  Here are a couple of caveats:

• WAS must be on its’ own server (thank the powers for virtualization, eh?).
• The WAS server cannot have had any office product installed on it, ever.  Do yourself a favor and just make up a new server (see previous comment on virtualization).
• If you want WAS to be highly available, you WILL NEED load balancing in the hardware variety, and this will require HLB w/SSL offloading.

<according to this new documentation on TechNet the comment for requiring SSL offloading appears to have been removed – this may be good news>

• Licensing for this new component is a bit up in the air – once I find out what the final story is going to be, I will update this article.

<As I understand it, using WAS for READONLY does not require a license.  See this, and more importantly, this.  The second link states that “…view-only.  By default, Office Web Apps is view-only.  View-only functionality is provided for free…”  Excellent!  That is all we need for Lync 2013.>

• WAS can be used for Exchange 2013 and SharePoint 2013, so one WAS farm could be used for more than one service.
• WAS is also the rendering engine for external users, so you will need to plan some additional IP and DNS resources.  And don’t forget how you are going to provide Reverse Proxy services because that is the route the external user is going to take to get the PowerPoint content.  Luckily, the client(s) will get the proper URL's via in-band provisioning, so access should be automagic from the user point of view.
• If you are planning a Lync 2010 upwards migration into 2013, then your existing reverse proxy web listener certificate is going to need to have another SAN entry to handle the external WAS traffic.  Alternatively, you can gin up another external, public IP and create a new conduit just for this WAS traffic.

WAS Install Official Instructions

Documentation for this process is NOT contained on the Lync 2013 online help, but rather in the Office Web Apps and SharePoint sites.  Take a look here.  What I found was a fair amount of back-and-forth comparing steps and whatnot, hence this guide which will (hopefully) bring it all into one place.

At any rate, what I am going to show is how to build a WAS farm, complete with HLB.  The tools we are going to use are:  Topology Builder, PowerShell, a squeaky clean set of Windows Server 2012 hosts, an internal PKI CA, and an HLB.  For HLB, I am using my Kemp VLM-100.  Reverse Proxy will be TMG.

A note on the TMG as reverse proxy.  I am making a whole new DNS and IP for this service.  As such, I am going to export the certificate for my LSWASPoolInt which has LSWASPoolExt.tsoorad.net as one of the SAN’s and place it on the web listener.  For a real deployment, I would conserve IP space and just use the existing Lync web listener and add the LSWASPoolext FQDN to the certificate for that listener.  This will require you to plan your external Lync DNS space in advance, along with the IP space.  But you already knew that, right?  DNS and IP planning is crucial to Lync success – this is just another example of that concept.

This is going to have more than a few steps to it, so let’s dive in.

First off, when dealing with WAS, *ALL* WAS related commands are PowerShell.  Here is a handy guide.  Second, and I have not yet figured out how to turn it down, WAS logs a ton of stuff in the event log.  As in 200k entries in one week!!  But, I digress.

If we go along with the official documentation, you are going to need to get into your Lync 2013 deployment plans and define your IP and FQDN requirements because the official documentation says you are supposed to do the HLB setup first.  OK. Here is my WAS setup:

lswaspoolint.tsoorad.net (my internal FQDN for the WAS farm): 1.1.1.45

lswaspoolext.tsoorad.net (my external FQDN for the WAS farm): 10.10.10.58

LS2013WAS1.tsoorad.net: 1.1.1.46

LS2013WAS2.tsoorad.net: 1.1.1.47

WAS Farm HLB

For my load balancer, I decided to just bring all traffic for the WAS straight to the HLB.  So the HLB in my case will only have 1 virtual server and I will bring internal and reverse proxy traffic to 1.1.1.45.

Here is the topology builder viewpoint.

Here is the Kemp HLB virtual server setup.  Note that it is marked as DOWN because we have not yet installed anything!

While you are at it, now would be a good time to envision your external and internal access paths.  Here are the firewall considerations. Ensure that the following ports are not blocked by firewalls on either the server that runs Office Web Apps Server or the load balancer:

• Port 443 for HTTPS traffic
• Port 80 for HTTP traffic
• Port 809 for private traffic between the servers that run Office Web Apps Server (if you’re setting up a multi-server farm)

Host Server Setup

1. Prep your servers.  I used VM’s with 1 CPU core, 1 GB RAM, and 50GB drive space.  YMMV.
2. Install WAS prerequisites appropriate to your host server operating system.

For Server 2008 R2, install the following software:

• Windows Server 2008 R2 Service Pack 1
• .NET Framework 4.5
• Windows PowerShell 3.0
• KB2592525

Next, open the Windows PowerShell prompt as an administrator and run the following example commands to install the required roles and services.  You may find it helpful to set the execution policy in PowerShell to remotesigned or unrestricted.

Import-Module ServerManager

And then run the follow example command:

Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support –restart

I always tack on the “-restart” so if servermanager wants to reboot it will without asking.

For Server 2012 - Server 2012 already has what it needs so you just need to do the following:

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,InkandHandwritingServices,NET-Framework-Features, NET-Framework-Core, NET-HTTP-Activation, NET-Non-HTTP-Activ, NET-WCF-HTTP-Activation45 -restart

Run windows update to get patched.  Your call on this step, but I always do it just to claim due diligence.

Get a PKI certificate that will be trusted by all players.  I used my DigiCert.com utility to generate the CSR – I wanted to include the internal and external URL’s which means I needed a SAN entry or three.  In my case, I used the following:

CN= LSWASPoolint.tsoorad.net

DNS Name=LSWASPoolint.tsoorad.net
DNS Name=LSWASPoolext.tsoorad.net
DNS Name=LS2013WAS1.tsoorad.net
DNS Name=LS2013WAS2.tsoorad.net

This certificate needs to be on each member server and also the HLB to support the SSL Offloading that is required for a WAS farm.  I am not absolutely sure that the certificate actually needs to be on the farm member servers, but in the interest of simplicity and for future single server farm use, I put it on each – remember that you need to generate the certificate on just one server, then export it for use on the other server and the HLB. 

WAS Install

Finally, we are ready to actually install Office Web Apps Server.  You can get the Office Web Apps server install from here.  There is not a lot to note on this install… I just banged through all the defaults.  However, I will note that I needed to execute the setup.exe as an Administrator to get it to run through properly. 

Once you have your WAS installed, now is a good time to remember that there is NO GUI – this thing is PowerShell only.

Now, the point to this article is to create a WAS farm; but so far, we have not done anything that can’t be used for a single server farm.  So here is the command to run on your first server if you want to create just a single server farm.  Note that there is a dependency on the certificate friendly name.

OK, from a PowerShell prompt:

New-OfficeWebAppsFarm -InternalURL "https://lswaspoolint.tsoorad.net" –ExternalURL “https://lswaspoolext.tsoorad.net” -CertificateName "FRIENDLYNAME"

If you are doing a two server farm, here is what you need.  I ran the first command on ls2013was1.tsoorad.net; this affects the syntax on the second server command!

On the first server:

New-OfficeWebAppsFarm -InternalURL "https://lswaspoolint.tsoorad.net" –ExternalURL “https://lswaspoolext.tsoorad.net” –ssloffloaded

Note that the “–ssloffloaded” is different – which implies that the certificate is not needed.

Then, on the second server:

New-OfficeWebAppsMachine –MachineToJoin ls2013WAS1.tsoorad.net

Let’s take a look at our new farm.  Note the AllowHTTP, SSLOffloaded, and Machines attributes.

Also note that now the HLB is showing the farm as “up”…

To further test that we have a viable WAS farm, we will hit the following URL in a browser:  https://lswaspoolint.tsoorad.net/hosting/discovery/.  The actual response is a good deal longer than the screen cap I am showing…of course you will want to test your HLB to ensure that each server is actually responding.

Reverse Proxy Setup

Alright, now to configure TMG as our reverse proxy so external users can enjoy the WAS goodness too.

First, get the WAS pool external URL SSL cert installed onto the TMG.  In this case, I am going to use my internally generated certificate; in real life, you will need to have a certificate that is trusted by any and all users – typically that means a public certificate.

Next, if you have a unique IP address for your external services, create a new listener with a new cert just for your WAS pool external URL.  If you are using URL redirects via TMG Website Publishing rule, then you will need to add the WAS pool external URL to the cert you have and re-work your listener just a tad. 

I am using the same listener with a revised certificate.  So, what we need now is a just a new TMG Website Publishing rule that takes the URL “lswaspoolext.tsoorad.net” and send it to our WAS VS on 1.1.1.45:443. Here is a link to the official document for completing this task.  Note that these instructions assume you are going to be making a new web listener – you may have to do a little judicious reading between the lines to accomplish this task for your environment.

Also, note that my rule in TMG did not test “good” but it works “good.” The sharp-eyed reader will also note that my current login does not trust the lab domain CA – hence the certificate error showing here.

Summary

• Office Web Apps Server (WAS) is a required element of Lync 2013.
  
• WAS setup is PowerShell only.
  
• The prerequisite setup is different from Server 2008 R2 to Server 2012.
  
• A WAS farm is one or more servers.  A single server needs to be HTTPS.  A two (or more) server farm is SSL offloaded to a hardware load balancer.  WNLB is not a supported option.
  
• Understand and plan your DNS and IP space before starting.
  
• Reverse Proxy (or something) is strongly suggested to separate the outside world from your WAS farm.  You will need to have a DNS setup to support external access along with certificates that past the public trust test.
  
• Overall process:
  
  
  
  • Lync Topology Builder
    
  • HLB setup
    
  • Server Prep
    
  • WAS Install
    
  • TMG (or some other reverse proxy solution)

As always, YMMV.