SharePoint 2013: How to Enable Office Web Apps to Work in both Internal and External Environments
SharePoint folks did complain about the poor performance of their SharePoint machines in the past at the time when Office Web Apps were tightly integrated in SharePoint Server 2010. Office Web Apps services must be started in every SharePoint machine for end-user to be able to view and edit supported Microsoft Office products (Word, Excel, PowerPoint, OneNote) directly on their browser. Thankfully with the new release of Microsoft Office system, Office Web Apps is no longer integrated in SharePoint 2010. It’s now a separate commercial product and can’t be installed in any server where SharePoint Server 2013 instance is installed. This significant change allows you to only have a server that is able to function to any SharePoint farm that connects to the OWA server. This improves performance a lot. The burden to your organization is that you have to prepare either a dedicated machine for OWA or install it on a non-SharePoint machine and purchase its license. This surely costs lots of money for both hardware and licensing. I’m not going to go around the pros and cons of OWA Server 2013 in this article. To see more about the enhancement and new changes, read here.
One of the very common questions I’ve seen in the MSDN forum is the setup of OWA working in both internal and external environments. This thread has inspired me to write my note in this article to answer to the question. Below is the word-for-word question:
“I have successfully installed SharePoint 2013 and Office Web Apps on Azure VMs inside an Azure Virtual Network (IaaS model). Everything is working well. However, my testing has shown that external users and internal users can’t use Office Web Apps at the same time.
Office Web Apps, installed on its own vm, accommodates an external and internal URL quite well. However, SharePoint 2013 appears to only allow one setting for WOPI Zone, either internal or external but not both. I’ve set the WOPI zone to Internal-HTTPs (Set-SPWOPIZone –Zone “internal-https”). OWA works just fine if accessed from inside the Azure Virtual Network. However, if I try to access from outside the Virtual Network, from the Internet, Office Web Apps fails. The exact opposite is also true. I can set WOPI Zone to External-HTTPS and accessing from the Internet works fine, but accessing inside the Virtual Network fails.”
In this case, let’s say you have completely deployed and configured OWA in your internal environment. End-users from local network have access to SharePoint through the internal URL e.g. http://sharepoint/ and are able to view and edit shared documents directly in Internet Explorer. However if end-users access SharePoint from Internet using the Internet-published domain e.g. http://sharepoint.abc.com, OWA doesn’t work because it from Internet routes to the internal URL you have set (e.g. http://owa). This happens many times when you don’t setup WOPI zone correctly. In my environment, there are two machines: app03 and app04. The app03 machine has SharePoint Server 2013 installed and the app04 machine is running Office Web Apps Server 2013 instance. These have already been joined to the domain controller with the name availys.lab. Note that all of these machines are hosted in my development/testing environment. Your environment may be different from mine. The SharePoint farm is virtualized inside Hyper-V and each machines has been assigned an internet-public IP.
On the SharePoint machine, if you haven’t configured Alternate Access Mapping setting yet, open it in your Central Administration site. (Application Management > Configure alternate access mappings). In my case, the name of the web application I’ve created is http://app03. Now I need to edit its public URL to make it accessible from the Internet using my public URLhttp://ecodemo.availys.com. To tell you my guidance is actually correct, I have to be using the real domain name and the current configuration of the SharePoint farm in this article.
On the Alternate Access Mappings page, click Edit Public URLs then select web application atAlternate Access Mapping Collection setting. Under the Internet setting, enter your public URL. You then don’t necessarily have to edit binding setting in IIS if you aren’t using multiple addresses running in the same port.
http://i1235.photobucket.com/albums/ff428/thuansoldier/aam-sp2013_zps5fda5b27.png
After that, check the internal URL from local network while opening the public URL from the Internet. Make sure you have done configuring your Internet domain name to point to the public IP of the SharePoint machine. This can be done via domain control panel and depends on what hosting provider you are using, such as GoDaddy. In my case, I’m able to accesshttp://app03 in local network while obviously being able to access http://ecodemo.availys.comfrom the Internet as below.
http://i1235.photobucket.com/albums/ff428/thuansoldier/OWA_testing_zps7fa2bdc4.png
Now open OWA machine to create a new WAC farm.
| 1 | New-OfficeWebAppsFarm –InternalUrl "http://app04" -ExternalUrl "http://198.xxx.xxx.xxx" -EditingEnabled |
Because I’ve not configured my OWA machine to be published to the Internet so I have to use its Internet-public IP. It’s not a recommended best practice. In your case, the external URL would be http://owa.abc.com. Above I’m not using SSL certificate to encrypt data over the Internet. Just add CertificateName parameter if you want to use whether CA-issued certificate or self-signed certificate. Finally, check both internal URL (http://app03/hosting/discovery) and external URL (http://198.xxx.xxx.xxx/hosting/discovery) to confirm everything is working well. Your screen should display XML structure.
Now you need to re-bind all SharePoint machines to WAC farm using New-SPWOPIBinding (http://technet.microsoft.com/en-us/library/jj219441.aspx). Next, you just need to set the WOPI zone for external use even there is an internal use in your SharePoint environment.
| 1 | Set-SPWOPIZone –zone “external-http” |
Finally, configure Excel service and then upload an Excel workbook into a document library and check it. Below are the screenshots of OWA working on both internal and external environment.
http://i1235.photobucket.com/albums/ff428/thuansoldier/owa_testing1_zps9ba8b643.png
As you see, there is no cheat that we used to use when playing game in childhood. The key thing here to note is that the FQDN of my SharePoint server isn’t published to the Internet because the domain controller and DNS is configured and run locally. Only Internet domain points to the public IP of the SharePoint machine. This would be the flickering light you would need to consider for SharePoint publishing portal. The lesson learnt here is not to use the real name of domain controller if you plan to use it over the Internet. For example, the FQDN domain controller shouldn’t be named abc.com, abc.net…etc. Ideally it should be something like abc.local. Microsoft wrote an article about naming conventions in Active Directory.
If you are using Windows Azure IaaS service to build and host SharePoint virtual machines, there are many required steps before deploying Office Web Apps. First, you need to create a virtual network to make your virtual machines possible to communicate with each other in the local network. Second, create endpoint with TCP protocol in conjunction with port 80 to allow your SharePoint machine to be able to communicate with others over the Internet. Below are some references that could help:
- 20 Key Scenarios with Windows Azure Infrastructure Services (IaaS): Deploy Web Server Solutions (IIS or Apache) in the Cloud
- How to Set Up Communication with a Virtual Machine
- Step-by-Step: Build a FREE SharePoint 2013 Dev/Test Lab in the Cloud with Windows Azure Infrastructure Services
Working with network stuffs in Windows Azure looks like a night mare no ITPros want to see in their dream.
In real-world scenarios, your environment may have firewall or reverse proxy (Forefront TMG, UAG, F5, Astaro..etc) put at the front-gate. OWA server should be published through firewall for better secure. This is always a good recommendation.