To configure SharePoint 2013 to use Office Web Apps, there are two essential references.
- Deploy Office Web Apps Server (http://technet.microsoft.com/en-us/library/jj219455(v=office.15).aspx)
- Configure SharePoint 2013 to use Office Web Apps (http://technet.microsoft.com/en-us/library/ff431687(v=office.15).aspx)
According to them, the configuration looks like very straight forward. However, the devil is in the details. Here, I am trying to list some issues that I experienced recently with the RTM version of SharePoint 2013 and Office Web Apps so I don’t forget them soon.
1. .NET Framework 3.5
When you install Office Web Apps on Windows Server 2012, you usually run the PowerShell script in the above articles to prepare the roles and features of Windows. That script doesn’t install .NET Framework 3.5 Core. However, at some points it looks like the Office Web Apps still needs the .NET Framework 3.5 Core. Without it, you may see the event error below.
Server Error in ‘/m’ Application
Warning: ASP.NET 4.0 – Event code: 3008 – Event ID: 1310
Could not load file or assembly ‘Microsoft.Build.Utilities, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified. (C:\Program Files\Microsoft Office Web Apps\BroadcastServices_Host\web.config line 44)
To avoid it, you can add the .NET Framework 3.5 Core feature, or run the following PowerShell script:
Add-WindowsFeature NET-Framework-Features, NET-Framework-Core
The only thing to notice is that Windows Server 2012 wasn’t shipped with .NET Framework 3.5. So you must have an Internet connection on the server so the core can be added successfully with the above method.
2. Office Web Apps Host
In case Office Web Apps don’t work after you finish the configuration and verified everything including the WOPI zone, you have to check the error log of the Office Web Apps. The default location of the log is C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS.
At some points, if you see the following error:
WOPI – CreateWopiHttpRequest failing due to invalid host
It means the domain name or the host name of the SharePoint site is not trusted by Office Web Apps. You have to use the following PowerShell script to add the name into the host list.
New-OfficeWebAppsHost -Domain <String>
The name of the parameter may lead to some confusing. You may think it is the name of the domain which your SharePoint server belongs to, but it is not. For example, the name of your domain may be contoso.com, but the url of the SharePoint site may be http://sharepoint. In this case, you should put “sharepoint” instead of “contoso.com”.
Based on my testing, when configuring Office Web Apps over HTTP, you have to configure the host list. When configuring over HTTPS, the host list can be empty.
Again, the TechNet article may lead to some misunderstanding to this option. According to the article, it looks like this option should be True when Office Web Apps are configured to use HTTP, and False when they are configured to use HTTPS. However, it is not true based on my testing. This option is more like depending on the configuration of the SharePoint site. If the SharePoint site is using HTTP, this option should be True no matter if HTTP or HTTPS is used by Office Web Apps.
If you see the “HTTPResponseCode forbidden” error in the Office Web Apps log, in most of case it is because of the incorrect setting of this option.
4. Word Doc Corrupted
At some points, you may see the following error in the Office Web Apps log.
[AppServerHost.exe] Word failed to open the document (Error Code = 0x80040266)
It is very like the Word document you are trying to open with Office Web Apps has been corrupted. You can upload a good document to test and confirm it.
One scenarios which may create such a corrupted Word doc is that you choose to create a new Word doc in SharePoint site with Office Web Apps. However, for some reason Office Web Apps don’t work normally. In this case, you get a corrupted Word doc in SharePoint document library.