I’ve been asked on several occasions over the last 2 years since I’ve written the following post demonstrating how to deploy an Office Web Apps Server:
Deploying Office Web Apps Server on Windows Server 2012 for Lync Server 2013 Enterprise or Standard Pool
http://terenceluk.blogspot.com/2013/01/deploying-office-web-apps-server-on.html
… as to why I never included instructions on how to publish this service externally because the configuration only allows for internal access. I’m not sure why but writing this follow up post seems to have consistently slipped my mind over the past 2 years so without further delay, this post will demonstrate how to configure the Office Web Apps server to serve PowerPoint presentations for both internal and external Lync conference meetings.
I won’t go into the details for the Office Web Apps server install because my previous post demonstrate this so I’ll begin by explaining the URLs I have chosen for internal and external:
Internal URL: wac.domain.com
External URL: wac.domain.com
As shown above, I am using the same URL for both internal and external access. This isn’t a requirement but I chose to do so because the public certificate we’ll be using is actually shared with the other Lync services and it only includes the public URL for the Office Web Apps server service. You could easily use the FQDN of the Office Web Apps server if you put that as a SAN entry into the certificate. It is also important to note that there is no way for you to assign a different certificate to the external URL and internal URL as you are forced to use the same certificate which I hope would change in future versions to give us a bit more flexibility when configuring the farm.
Begin by creating the the Office Web Apps Server object in the Lync Server 2013 Topology Builder and use the external URL as the FQDN:
The following is the certificate the the Office Web Apps server will be using for both the external and internal URL:
Make a note of the friendly name of the certificate as we’ll need it when we create the Office Web Apps farm:
Continue by logging on the Office Web Apps server and launching the Windows PowerShell console and use the following cmdlet to create a new Office Web Apps Farm:
New-OfficeWebAppsFarm -InternalUrl “https://wac.FQDN” -ExternalUrl “https://wac.FQDN” -CertificateName "<Certificate Friendly Name>"
For the purpose of this example, we’ll be using the following cmdlet:
New-OfficeWebAppsFarm -InternalUrl “https://wac.domain.bm” -ExternalUrl “https://wac.domain.bm” -CertificateName "sip.domain.bm"
With the Office Web Apps farm configured, the last items to complete are as follows:
- Create an internal DNS record pointing to wac.domain.bm to the internal IP of the Office Web Apps server
- Allocate a public IP
- Create the external DNS record wac.domain.bm that maps to the public IP allocated in step #2
- Create a NAT rule on the firewall that passes TCP 443 to the internal IP of the Office Web Apps Server
- Test sharing PowerPoint presentations for external with external, external with internal, internal with internal
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Please be advised that this is only one of the ways to configure Office Web Apps for a Lync 2013 deployment and depending on the environment, I may use different URLs for internal and external access while adding an external entry on the certificate.
3 comments:
If you're already using a Reverse Proxy server, it's much more secure to publish it using that service, which also alleviates any issues you may have if you have a different internal namespace.
Simply create an internal SAN certificate with the internal and external names in it, have those two different names as your InternalURL and ExternalURL in the OWA publication, and use your Internal certificate on your OWA server. You bind your Public certificate only on the Reverse Proxy, not the OWA server!
Step by step the secure way: http://technet.microsoft.com/en-us/library/jj204665.aspx
I'm fully aware of the benefits of using TMG to publish the service as I've worked with the product since the Microsoft Proxy Server days but the challenge that I come across more and more often now is that most clients I work with does not have TMG or UAG. I also can no longer propose TMG into an environment because the product is being discontinued.
Post a Comment