When installing and deploying Office Web Apps 2013 to a security hardened drive, Office Web Apps may not work correctly if there are permissions missing from the security hardened drive. The default location on most systems is the C drive, but some customers may install to non-system drives (such as a D drive, E drive, etc) and permissions may be stripped from those drives.

The Office Web Apps 2013 installer allows you to choose a path where the code will be installed, and non-system drives are supported. Also some of our configuration settings (such as CacheLocation) default to using the system drive, those can be overridden using the New-OfficeWebAppsFarm or Set-OfficeWebAppsFarm cmdlets. The Office Web Apps installation will still need to put a few small files in the %PROGRAMDATA% folder, which is typically on the system drive.

When deploying Office Web Apps 2013 to a hard drive that is security hardened (permissions are removed), the following permissions need to be present on the installation folders: 

The “CREATOR OWNER” & “SERVERNAME\users” need permissions to the install location on the non-system drive:

More Information

Deploy Office Web Apps Server

http://technet.microsoft.com/en-us/library/jj219455
 
 

In the following blog, I am going help you verify that WAC Server is working via circumventing a WOPI Host (IE ruling SharePoint as the potential culprit).  This is helpful when you want to test Office Web Apps viewing capability independent of SharePoint, Exchange or Lync.

Instructions:

1.   By default the Office Web Apps new farm configuration does not set OpenFromURLEnabled to True.  Set to True by running the command below in Powershell on the WAC Server.

Set-OfficeWebAppsFarm -OpenFromURLEnabled

2.   Add a workbook to a folder (and then Share that folder) on the WAC Server. 

Example: Create a folder called "Test" on the root of C: (C:\Test\Test1.xlsx)

Share the folder with Everyone.

If this location is on another Server (Not the WAC Server), you need to Share this folder with the WAC Server (the Computer Account (follow below screenshot on how to do this)).

After you have chosen Computers, you need to WAC Server name > Check Names (make sure it resolves) > OK

3.   We now need to generate a http:// URL to that folder.  Open IE and browse to http://<ServerName>/op/generate.aspx

Use the URL that is next to "InternalURL" when you perform Get-OfficeWebAppsFarm

If you are not using an "InternalURL" then you will obviously have to use "ExternalURL"

In the below example the URL is: http://wacserver/op/generate.aspx

4.   Enter the UNC location of the workbook. \\<Servername>\test\test1.xlsx

In the below example the UNC location is \\wacserver\test\test1.xlsx

5.   Click " Create Link " and then click "Test this link."

If this works, then you know the WAC Server can render the workbook and something else is configured incorrectly.

If this fails, you may want to considered quickly rebuilding your WAC Server the below blog:

NOTE: This testing feature does not currently work with Windows Server 2012 R2.  Our product team has been notified.

Office Web Apps 2013 - Rebuild your Farm in a few Easy Steps!
http://blogs.technet.com/b/office_web_apps_server_2013_support_blog/archive/2013/12/20/office-web-apps-2013-rebuild-your-farm-in-a-few-easy-steps.aspx

We have been seeing some issues with SharePoint IRM policies applied to a SharePoint document library where users are able to view documents with Office Web Apps 2013, but not edit them.  This is expected behavior:

The issue is that when users attempt to preview the documents using Office Web Apps Server 2013, users will be presented with an error:

"Sorry, Word Web App can't display this embedded document because it's protected by Information Rights Management (IRM)"

Microsoft is aware of this issue and is currently investigating.  Updates will be posted to this blog when more information is available.

Wictor Wilen has written a great blog post about enabling PDF previews in SharePoint 2013 document libraries with Office Web Apps 2013 which can be found here:

http://www.wictorwilen.se/sharepoint-2013-enabling-pdf-previews-in-document-libraries-with-office-web-apps-2013

Wictor provides the WSP to provide PDF preview functionality and this works great, but some customers are running into issues when attempting to click "Open" on PDF previews generated from Office Web Apps 2013.  Users may see the following error:

"Sorry, something went wrong.  An error has occurred on the server."

Upon reviewing verbose SharePoint logs, you may see errors similar to the following:

w3wp.exe (0x3A88)        0x3B28        SharePoint Foundation        WOPI        ah6ud        Unexpected        Exiting GetWOPITargetInternal Early - GenerateWacUrl failed to produce a URL/actionEntry for file <filename>.pdf with extension 'PDF' StackTrace:   at Microsoft.SharePoint.Utilities.SPWOPIHost.GetWOPITargetInternal(HttpContext httpContext, SPWeb web, Object& spPrimeObject, SPWOPIAction& requestedAction, SPRegionalSettings spSettings, String& wopiAppUrl, String& wopiFavIconUrl, String& wopiAccessToken, Int64& wopiAccessTokenTtl, String& errorMessageToDisplay, String& redirectUrl)     at Microsoft.SharePoint.ApplicationPages.WOPIFrameHelper.OnLoadHelper(WOPIFrame frame)     at Microsoft.SharePoint.ApplicationPages.WOPIFrameHelper.OnLoad(WOPIFrame frame)

This issue is resolved by installing the following hotfix package on your SharePoint 2013 servers:

Description of the SharePoint Server 2013 hotfix package (Sts-x-none.msp): October 8, 2013.

http://support.microsoft.com/kb/2825665

Note about viewing PDFs in mobile browsers: 
There is currently no support for PDF viewing in mobile browsers.  You will receive a message "Viewing .PDF files has been disabled in Microsoft Word Mobile viewer".  To allow PDFs to open instead with the mobile browser default action, this capability has been removed as of Office Web Apps October 2013 Cumulative Update: http://support.microsoft.com/default.aspx?scid=kb;EN-US;2825686 
 

If you need to determine your WAC Server build, it is relatively easy.  Paste the below command in Windows Powershell on the WAC Server:

get-content C:\ProgramData\Microsoft\OfficeWebApps\Data\local\OfficeVersion.inc

You can also use the below methods if you have lots of time on your hands :)

Internet Explorer 11:

Browser to this URL: /op/servicebusy.htm">http://<wacservername>/op/servicebusy.htm (change the letters in red to reflect the wacserver name).

Hit F12 key (make sure the "F lock" key is selected).  You will then see the below window.

1. Choose the "Network (Ctrl + 4)" icon.

2. Click the Play button "Enable network traffic capturing (F5)"

3. Click "Details"

4. Click "Response headers"

5. You will see the WAC build next to "MicrosoftSharePointTeamServices".

Internet Explorer 10:

Browser to this URL: http://<wacservername>/op/servicebusy.htm (change the letters in red to reflect the wacserver name).

Hit F12 key (make sure the "F lock" key is selected).  You will then see the below window.

1. Choose the "Network tab.

2. Click "Start Capturing"

3. Click "Details"

4. Click "Response headers"

5. You will see the WAC build next to "X-OfficeVersion".

We have run in to several instances where the Office Web Apps will not redirect back to the expected library.

This is caused by a difference in code behind the SharePoint 2010 document library and the SharePoint 2013 document library.

=========================================================================================

Here is an example situation in a SharePoint environment which has both 2010 sites, and 2013 sites.

-User navigates to a SharePoint 2013 document library.

-User clicks on a Word document, which launches the Word web app in "Read" mode.

-User decides they want to edit the document in the Word client.

-Word client is launched in edit mode

-Meanwhile the browser which was displaying the Word web app has automatically navigated back to the original SharePoint 2013 library.

-User finishes editing the document in the Word client, then saves and closes the Word client.

-User goes back to the browser, which is still on the SharePoint 2013 document library

-User navigates to a SharePoint 2010 document library

-Again the user selects a Word document, which is opened in the Word web app in "Read" mode.

-Again the user elects to edit the Word document in the Word client, which automatically redirects the browser.

-This time the browser redirects back to the SharePoint 2013 library which the user had previously visited, rather than the SharePoint 2010 library which they navigated to most recently.

======================================================================================

When the browser opens up any Office Web App in a SharePoint 2013 environment (on premises or Office 365), it loads the "WopiFrame.aspx" or "WopiFrame2.aspx" page.  This is the page which gives all Office Web Apps a place to display documents.

The "WopiFrame.aspx" or "WopiFrame2.aspx" page depends on the "WOPISessionContext" cookie set by SharePoint to understand where to go when the Web App page needs to be redirected.

In a pure SharePoint 2013 environment, users will not run in to this issue because there is code behind SharePoint 2013 libraries which updates the cookie every time you navigate to a new list/library.

This code does not exist in SharePoint 2010, which is why the "WOPISessionContext" cookie does not get updated, thus explaining the "incorrect" redirect from the "WopiFrame.aspx" or "WopiFrame2.aspx" page.

Summary on IRM with Office Web Apps 2013

When it comes to IRM protected Office document libraries in SharePoint 2013, Office Web Apps 2013 offers read-only capability.  Office Web Apps relies on the document host system (i.e. SharePoint) to handle communication with Rights Management servers since it has no means to directly communicate with Rights Management Server. IRM protection precludes Office Web Apps from allowing editing of IRM protected documents.  Documents that have any IRM permissions modification or protection added from the client application (i.e. Word, PowerPoint, Excel) and stored on a document management system cannot be opened by Office Web Apps. This is also true with IRM protected documents stored on Windows Live, Facebook or other 3rd Party hosts systems.

Limitations
Office Web Apps does not support the following features normally offered for non-IRM protected documents.  These features are currently suppressed from the user interface:

• Edit in browser
• Print
• Save
• Copy selection
• Add comments

No word on when or if these features will be available for IRM protected libraries in an upcoming release.

Typically, we see Office Web Apps Server 2013 paired with a SharePoint 2013 environment. 

However, customers are free to use Office Web Apps Server 2013 with any product which can act as a WOPI (Web application Open Platform Interface) host.

This means, if customers do not want to use SharePoint 2013 to host their files, and they still want to use Office Web Apps, they can!

SharePoint 2013 uses the [wopiframe.aspx] page to communicate with Office Web Apps Server 2013.  This is a SharePoint 2013 hosted page which gives the appropriate web app a place to display content.

Non-SharePoint WOPI hosts use the [view.aspx] page to display the web apps.  This is an Office Web Apps Server 2013 hosted page.

If you're using SharePoint 2013, or any other file hosting solution, chances are you have a lot of files, some of which are large.

Office Web Apps Server 2013 has the ability to let you to adjust the size of Excel files displayed in the web apps.  This is a farm setting called [ExcelWorkbookSizeMax]; the number displayed is in MB.

Please be aware that while the following information may resolve your issue, it is not a solution supported by Microsoft.

When adjusting the [ExcelWorkbookSizeMax] value, the settings will only apply to the [wopiframe.aspx] page.  Obviously this is an issue if you are using a non-SharePoint solution which utilizes the [view.aspx] page.

We looked at this problem from a couple perspectives, and here's what we found.

==============================================================

1. Since we know non-SharePoint WOPI hosts call [view.aspx], rather than [wopiframe.aspx], is there a way to somehow replace [view.aspx] with [wopiframe.aspx]? 

No. Through extensive testing we found there is no way to modify or replace the [view.aspx] page to force it to behave like the [wopiframe.aspx] page.

==============================================================

2. Are there any other modifications we can make to the Office Web Apps server to get it to display large documents?

Yes. There are modifications we can make to portions of IIS on the Office Web Apps server.

==============================================================

Instructions to modify IIS on the Office Web Apps server...

1. In IIS on the Office Web Apps server, you will find a number of directories under the HTTP80 site.  We are looking specifically for the /oh and the /op directories.

2. Open each of these directories in explorer view and you will find a web.config file and a Settings_Service.ini file.

3. Open the Settings_Service.ini file in Notepad.

4. Add "OpenFromUrlMaxFileSizeInKBytes=(System.Int32)500000" to the end of the ini file.  It should look like this...

5. Make sure to update the Settings_Service.ini file in both the /oh and /op directories.

6. Make sure the value in KB, matches the Office Web Apps farm setting in MB.

For this example, we are using 500,000 kilobytes, so the Office Web Apps farm setting would be 488 MB.

Please be aware that this size setting will apply to ALL Office document types in the web apps, not just Excel.

Many users ask the question, "How can I tell if I am using Office Web Apps 2013 versus a SharePoint Service Application (like Excel Services)?".  To answer that, you need to look at the URL of the document when you open it in the browser.
           

Office Web Apps Server 2013 uses the "WOPIFrame.aspx":

Note: If you do not want Office Web Apps Server 2013 to render the workbook run the below command to open the workbook in Excel Services (xlviewer.aspx).

New-SPWOPISuppressionSetting -extension xlsx -action view

New-SPWOPISuppressionSetting
http://technet.microsoft.com/en-us/library/jj219443.aspx

 Excel Services uses the "xlviewer.aspx":

Note: If you do not want Excel Services to render the workbook run the below command to open the workbook in Office Web Apps (WOPIFrame.aspx).

Remove-SPWOPISuppressionSetting -extension xlsx -action view

Remove-SPWOPISuppressionSetting
http://technet.microsoft.com/en-us/library/jj219452.aspx 

As you might know, when Microsoft originally released Service Pack 1 (SP1) for Office Web Apps Server 2013 in April 2014, we discovered a flaw which prevents any public or cumulative updates from being installed.

Because of this flaw, we immediately removed the ability to download the service pack so we could repair it.  More on that here... http://support.microsoft.com/kb/2817431

Once the regression was patched, we published a new KB with the patched version of SP1.  That KB can be found here... http://support.microsoft.com/kb/2880558

If your Office Web Apps server is running on the regressed version of SP1, it is highly recommended you remove it and install the patched version.

The patched version of SP1 is build 15.0.4571.1502.

You can find the build number of your Office Web Apps server in Control Panel > Programs and Features

If you are on an older build than this, it means you are using the regressed version of SP1, or you are on an older Cumulative Update (CU), or an older Public Update (PU), or on the default release (RTM) build.  In any situation, it is highly recommended that you upgrade to at least SP1.

=============================================================================================================

There is also the situation of the PUs & CUs which have been released since the patched version of SP1 was released.  Here are the major points to keep in mind. Download links at the bottom of this section.

-If you have the regressed version of SP1 for Office Web Apps server installed, please reference Jason Haak's blog on how to how to remove the regressed version of SP1, install the patched version of SP1, and install April PU.  http://blogs.technet.com/b/office_web_apps_server_2013_support_blog/archive/2014/04/08/how-to-remove-office-web-apps-2013-with-service-pack-1-and-apply-security-update-2878219.aspx

-Since the June CU is right around the corner, the upgrade path MUST be done in the following order to be completely current with updates.  Patched SP1 > April PU > May PU > June CU.

-Generally when updating Office Web Apps Server, you can install the latest PU and CU, as each PU and CU are roll-ups of all other PUs and CUs before it.  However, in this unique situation, because of the regression with SP1, April PU must be installed before the latest available PU.

SP1 Regressed - http://support.microsoft.com/kb/2817431

SP1 Patched - 15.0.4571.1502 - http://support.microsoft.com/kb/2880558

April PU - 15.0.4605.1001 - http://www.microsoft.com/en-us/download/details.aspx?id=42485

May PU - 15.0.4615.1001 - http://www.microsoft.com/en-us/download/details.aspx?id=42799

June CU - http://support.microsoft.com/kb/2881051

Latest available SP, CU, and PU for all Office/Office related products - http://technet.microsoft.com/en-us/office/ee748587.aspx

=============================================================================================================

As always, please do not use automatic updates to install updates to Office Web Apps Server 2013.

Please follow the best practices outlined in the following TechNet article. http://technet.microsoft.com/en-us/library/jj966220(v=office.15).aspx

Edited 6/11: Updated April PU link.  Updated June CU link.

Before we get in to the limitation, here's a little context on what's happening server-side.

In Office Web Apps Server 2013, documents are converted server-side before they are rendered in the browser for editing.

During the conversion process, the document is ripped apart in to mostly .png and .xml files and cached on the Office Web Apps server.

This means that when you are editing a document, you're not actually editing a .xlsx or .pptx, etc. file.  You're editing the converted and cached file.

========================================================================================

In PowerPoint, you can add objects to slides called SmartArt.  SmartArt includes many different options, but the one we'll be focusing on is the Organization Chart.

When you use the Organization Chart you can add objects above or below the currently selected object by right-clicking a shape.

In Office Web Apps Server 2013, the server will not be able to convert the file server-side if the hierarchy is more than 9 levels deep.

Looking at the screenshot below, if we were to add one more level to this hierarchy, the document would fail to load in the browser for editing and we would find conversion failures in the Office Web Apps Server ULS logs.

To avoid this issue, do not create SmartArt object hierarchies more than 9 levels deep.

Scenario:

Consider if you have done the following:

1) Office Web Server RTM installed
2) Office Web Server RTM language packs installed (all of them)
3) Download and install Office Web Server SP1  http://support.microsoft.com/kb/2880558
 
Result: During the setup of Office Web Server SP1, the install will fail with this error:

 
 
Reason: This error occurs because the language packs for 6 specific languages (below) missed making SP1 and because they are installed in the RTM version, SP1 setup tries to upgrade them and fails.

1. Azerbaijani - Latin script (az-latn-az
2. Bosnian - Latin script (bs-latn-ba)
3. Dari (prs-af)
4. Irish Gaelic (ga-ie)
5. Macedonian (FYROM) (mk-mk)
6. Welsh (cy-gb)
 
Workaround: 

Uninstall the six RTM language packs prior to applying SP1.  Then SP1 will install successfully. Finally, after SP1 is installed you may then install the six RTM language packs.

Behavior of using Office Web Apps Server 2013 and SharePoint 2013 with multiple zones

Issue:

Configuration of Office Web App Server with multiple alternate access mappings and zones in SharePoint Server 2013.

Behavior:

Office Web App Server 2013 will use the default zone set in SharePoint Server 2013 for the respective web application.

Example:

The default zone URL is http://sp2013t ,so this is the URL that Office Web Apps will use to contact the SharePoint Server.

You can test and make sure the URL is accessible from the Office Web Apps server, if it is not you will need to correct the connectivity here or Office Web Apps will not work correctly.

Scenario

We have seen a number of support incidents with intermittent errors when viewing Office documents using Office Web Apps 2013.  All Office file types are affected, most often PowerPoint and Word.  Often, the same document will display at one time, then throw an error at another.  The errors seen by users are varied and are frankly too generic to bother with a comprehensive list.  Instead, let's jump into the cause and current resolution.

If you turn up logging to Verbose using the -LogVerbosity "Verbose" parameter in Powershell, you will see in Office Web Apps server ULS logs reference to "ConversionError" and/or "Conversion failed".

Cause

Antivirus (AV) network monitoring processes that monitor the *\Program Files\Microsoft Office Web Apps\" folder and all executables (.exe) in each subfolder can potentially interfere with the file conversion functionality.  To display documents, each document is "converted" into image files that are cached on the Office Web Apps servers.  The process responsible for this conversion is called AppServerHost.exe.  Numerous instances of this subprocess are opened and closed by Office Web Apps repeatedly, and AV monitoring software can detect this activity as a threat or otherwise cause these processes to terminate unexpectedly.  This in turn leads to a corrupted cached file and the error condition results.

Resolution

While attempts to manually/programmatically clear the Office Web Apps cache have had limited success, so far the AV programs that cause this behavior must be reconfigured to allow Office Web Apps to freely create and sustain its AppServerHost.exe processes (and all relating subprocesses).  Here are some configuration guidelines:

1. Exclude any monitoring of the .exe processes inside ANY subfolder within *\Program Files\Microsoft Office Web Apps\
2. Exclude monitoring or lower the "risk level" for the AppServerHost.exe process and the "wacsm" Windows service.
3. If the previous two guidelines don't help, please contact your Antivirus software support for further assistance.

Below is a basic list of the Office Web App Server 2013 processes that you should be excluding. This is a basic list only, you may have other processes depending on what is installed.

AgentManagerWatchdog.exe
AppServerHost.exe
broadcastwatchdog_app.exe
broadcastwatchdog_wfe.exe
DiskCacheWatchdog.exe
EditAppServerHost.exe
EditAppServerHostSlim.exe
excelcnv.exe
FarmStateManagerWatchdog.exe
FarmStateReplicator.exe
HostingServiceWatchdog.exe
ImagingService.exe
ImagingWatchdog.exe
MetricsProvider.exe
Microsoft.Office.Excel.Server.EcsWatchdog.exe
Microsoft.Office.Excel.Server.WfeWatchdog.exe
Microsoft.Office.Web.AgentManager.exe
Microsoft.Office.Web.WebOneNoteWatchdog.exe
OneNoteMerge.exe
ppteditingbackendwatchdog.exe
pptviewerbackendwatchdog.exe
pptviewerfrontendwatchdog.exe
ProofingWatchdog.exe
SandboxHost.exe
SpellingWcfProvider.exe
ULSControllerService.exe
WordViewerAppManagerWatchdog.exe
WordViewerWfeWatchdog.exe

Scenario

Users are redirected to the wrong OneDrive site after saving a newly created document in Office Web Apps 2013.

Cause

We've discussed how the wopisessioncontext cookie works with the Office Web Apps 2013 in the past here...

http://blogs.technet.com/b/office_web_apps_server_2013_support_blog/archive/2014/01/22/office-web-apps-2013-web-apps-redirect-to-incorrect-sharepoint-library.aspx

In this situation we are seeing users being redirected to the last OneDrive library they visited, rather than their own.

Here is an example situation.

-User 1 navigates to User 2's OneDrive site.
-User 1 opens a document shared on User 2's OneDrive site in Office Web Apps 2013.
-User 1 closes the document which redirects them back to User 2's OneDrive site library.
-User 1 navigates back to their own OneDrive site
-User 1 creates a new document using the Office Web Apps.
-User 1 saves the document by clicking the "X" in the upper right corner of the web app.
-User 1 is redirected back to User 2's OneDrive site library, rather than their own.

Resolution/Workaround

At this time there is no direct resolution to this specific issue, as the issue has been raised to the Office Web Apps product group and they have elected to focus their efforts elsewhere.

One workaround we have found is to click File > Save on the document (if available), as this will update the wopisessioncontext cookie to the appropriate library.

We have also found that this issue does not reproduce in SharePoint Online using the Office Online web apps.

Scenario

You would like to utilize custom fonts with Office Web Apps Server 2013

Resolution

We have seen several instances of customers using custom fonts with Office Web Apps Server 2013; here is our compiled list of information surrounding using custom fonts.

-Font files must be .otf files.  We have tested extensively with .ttf files and they will not work with Office Web Apps Server 2013.
-The .otf files must be installed on the user's local machines, as well as every Office Web Apps server in the farm.
-Office Web Apps Server 2013 utilizes the Windows Font Cache for its fonts.
-The font files must be installed by an Administrator, and must be installed by right-clicking the font file and clicking Install.  You may not simply drag the font file(s) into the fonts folder.
-Each Office Web Apps machine in the farm will need to be fully restarted before the fonts will take effect within the web apps.
-If you are viewing a document in the web apps that already has the custom font in use, the font will show in preview, view, and edit mode in the browser.  Additionally, you will find the custom font in the font drop-down menu within the web app.
-If you are creating a new document in the web app, the custom font will not show in the default list of fonts.  However, you may search for the font using the search feature within the font drop-down.  Note that you must spell the font name exactly as it appears or the font will not be used.  For example if the actual custom font name is "Fonts", and the user searches for "Font", the custom will not be utilized.

While rendering office documents through Office Web apps 2013, you may receive a 404, or Server Error, when on Mobile devices. This is more likely to occur when attempting to render the documents through Search results and then using Search Refiners. This is because the URL can become very large and increase as more refiners are added to the search query.

There is a two part fix to allow for large query strings to be based to Mobile devices.

The first hurdle is a default limit set in IIS, and you will see a similar error as seen below (Figure 1).

Figure 1

You may see 404.15 in the IIS logs.

To resolve this go to the Office Web Apps Server and modify the IIS ApplicationHost.Config file, located here <c:\windows\system32\inetsrv\config>.

Add the following inside the 'requestFiltering' tag. If you already have these elements, increase the value to the specified values below.  

 <requestFiltering>

                <requestLimits maxAllowedContentLength="2147483647" maxUrl="2147483647" maxQueryString="2147483647" />

 </requestFiltering>

There is similar IIS documentation here.

http://support.microsoft.com/kb/942071

Now that the limitation in IIS is increased you may notice that the error changes, similar to Figure 2.

Figure 2

To resolve this we need to add the httpRuntime element to the Office Web Apps Root site.

On the Office Web Apps RootWebSite (Port 80 site), open the web.config file. This is located here, <c:\program files\Microsoft Office Web Apps\RootWebSite>.

Add the following inside the <configuration> tag.

   <system.web>

      <httpRuntime maxRequestLength="400000" maxUrlLength="40960" maxQueryStringLength="16048" />

   </system.web>

Reset IIS on the Office Web Apps Server.

For the past several months I have worked on an issue with the Excel Interactive Preview throwing the error:

"Server Error
404 - File or directory not found.
The resource you are looking for might have been removed,
had its name changed, or is temporarily unavailable."

When refining a SharePoint Search:

We have determined the root cause and this will be fixed in the SharePoint 2013 May Public Release.

SharePoint patching demystified
http://blogs.technet.com/b/stefan_gossner/archive/2014/08/19/sharepoint-patching-demystified.aspx

ISSUE:

The RTM installer of Office Web Apps will also create a folder on the C drive called “OneNoteMerge” when installing to another drive. The folder is not created on the specified non C drive path. This is one root cause of the unhealthy status and some event log errors.

FIX:

This has been fixed in the most recent version of the installer that is slipstreamed with SP1

WORKAROUND:

To correct the issue on an Office Web Apps server that was installed with the RTM installer you can perform the following steps:

1. Stop the Office Web Apps service (stop-service wacsm)
2. Move the following folder and all of its contents from the C drive to the correct installation path you specified. (C:\Program Files\Microsoft Office Web Apps\OneNoteMerge)
3. Start the Office Web Apps service (start-service wacsm)
4. The health status should now show healthy and errors for the OneNoteMerge ping check should no longer appear

NOTE:

We do not recommend installing on a non system drive if you are using VMWare, unless you perform a VMWare workaround

(Source)

If you are planning to deploy an Office Web Apps Farm, the following data could be useful for you in case you are encountering the "Microsoft Office Web Apps Server 2013 Encountered an error during setup" error while running the installation package.
It specifically happens on virtual environments with Windows Server 2012 (R 2) and the error looks like in the screenshot bellow:

In the Event Viewer this error is recorded with following data:

  "Microsoft Office Web Apps Server 2013 Encountered an error during setup"
In the event viewer is reported the following log:
Faulting application name: MsiExec.exe, version: 5.0.9600.17415, time stamp: 0x54505262
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17415, time stamp: 0x54505737
Exception code: 0xe06d7363
Fault offset: 0x0000000000008b9c
Faulting process id: 0x78c
Faulting application start time: 0x01d098872e5fe7d6
Faulting application path: C:\Windows\System32\MsiExec.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll

Also if you take a look into the installation logs you can see the following entries:

---------------------------------------------------------------------------------------------------------

[DATE] [TIME] ::[PID] MSI(INFO): 'CustomAction ArpWrite returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)'

|

|

|

[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT_PROBLEM = If problem persists, contact Microsoft Product Support Services (PSS) for assistance.  For information about how to contact PSS, see C:\Users\UserName\AppData\Local\Temp\2\Setup000007c4\PSS10R.CHM.'
[DATE] [TIME] ::[PID] MSI(INFO):'Property(S): ERRORSUPPORTTEXT_PERMISSION = Verify that you have sufficient permissions to access the registry or contact Microsoft Product Support Services (PSS) for assistance.  For information about how to contact PSS, see C:\Users\UserName\AppData\Local\Temp\2\Setup000007c4\PSS10R.CHM.'
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT = Contact Microsoft Product Support Services (PSS) for assistance.  For information about how to contact PSS, see C:\Users\UserName\AppData\Local\Temp\2\Setup000007c4\PSS10R.CHM.'
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ArpWrite = CacheLocation;Contact;Comments;DisplayIcon;DisplayName;DisplayVersion;HelpLink;HelpTelephone;InstallLocation;ModifyPath;NoElevateOnModify;NoModify;NoRemove;NoRepair;PackageRefs;ProductCodes;ShellUITransformLanguage;SkuComponents;SPPSkuId;SystemComponent;UninstallString;URLInfoAbout;URLUpdateInfo;VersionMajor;VersionMinor'

|

|

|

[DATE] [TIME] ::[PID] MSI(INFO):'Property(S): SETUPSUPPORTURL = http://support.microsoft.com/?kbid=xxxxxx'
[DATE] [TIME] ::[PID] MSI(INFO):'Property(S): ERRORSUPPORTTEXT_RETAIL_DEFAULT_PROBLEM_PRE = If problem persists, contact Microsoft Product Support Services (PSS) for assistance.  For information about how to contact PSS, see '
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT_RETAIL_DEFAULT_PROBLEM_POST = .'
[DATE] [TIME] ::[PID] MSI(INFO):'Property(S): ERRORSUPPORTTEXT_RETAIL_DEFAULT_PERMISSION_PRE = Verify that you have sufficient permissions to access the registry or contact Microsoft Product Support Services (PSS) for assistance.  For information about how to contact PSS, see '
[DATE] [TIME] ::[PID] MSI(INFO):'Property(S): ERRORSUPPORTTEXT_RETAIL_DEFAULT_PERMISSION_POST = .'
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT_RETAIL_DEFAULT_PRE = Contact Microsoft Product Support Services (PSS) for assistance.  For information about how to contact PSS, see '
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT_RETAIL_DEFAULT_POST = .'
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT_OEM_DEFAULT = Contact your computer manufacturer's product support for assistance.'
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT_OEM_DEFAULT_PERMISSION = Verify that you have sufficient permissions to access the registry or contact your computer manufacturer's product support for assistance.'
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): ERRORSUPPORTTEXT_OEM_DEFAULT_PROBLEM = If problem persists, contact your computer manufacturer's product support for assistance.'
[DATE] [TIME] ::[PID] MSI(INFO): 'Property(S): InstalledByServerCatalyst_Ref = 0'

|

|

|

[DATE] [TIME] ::[PID] MSI(INFO): Error: Failed to install product:  C:\OWA\wacserver.ww\wacserver.MSI ErrorCode: 1603(0x643).

|

|

|

[DATE] [TIME] ::[PID] MSI(INFO):Catalyst execution finished: [Date][Time].  Return code: 1603.

---------------------------------------------------------------------------------------------------------

CAUSE:

The BIOS SETTINGS  on server or the POWER OPTIONS profile on machine (or both), are set to "BEST PERFORMANCE" or "HIGH PERFORMANCE"

WORKAROUND:

Set the BIOS SETTINGS  on server or the POWER OPTIONS on machine (or both), to the BALANCED ( performance/power profile).