Office Web Apps has a setting to enable translation services for Word documents.  Reference MSDN blog: http://blogs.msdn.com/b/alimaz/archive/2012/07/26/translating-office-documents-using-office-web-apps-preview-and-microsoft-translator-service.aspx

By default the "TranslationEnabled" setting = False.  Unfortunately, if you do NOT want the Translate option to appear in the Word Web App >> File >> Info options, you need to take an extra step.

How to Disable Translation in Word Web App

There is an .ini file in the root Office Web Apps Server directory (\Program Files\Microsoft Office Web Apps\WebWordViewer) called Settings_service.ini.  Open that .ini in Notepad and edit this line:

; The switch to turn the word viewer translation feature on/off in the datacenter
WordViewerTranslationIsEnabled=(System.Boolean)True

to this instead:

WordViewerTranslationIsEnabled=(System.Boolean)False

Afterwards, restart the Office Web Apps service via Powershell:  Restart-service wacsm

Result: 
The Word Web App will no longer provide the option to translate the document.

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.

We have run in to several cases lately where customers have FBA authentication enabled in the extended zone, but not the default zone, of the web application, and will receive errors when trying to use the Office Web Apps.

The issue stems from SharePoint and is due to an error in the access token generation when a user tries to load a document in the Office Web Apps.

This is a known issue, but there is currently no timeline on when or if this will be addressed.

The current workaround is to configure FBA authentication in the Default zone of the effected web application

We have seen a number of issues with Office Web Apps 2013 being installed on a Non-System Drive using VMWare.  There are numerous possible symptoms for this issue, and below is an example of an error you might see in the SharePoint ULS logs. 

Here is one example (with ULS entry) of the unusual behavior we are seeing:

"Microsoft Word Web App"

Sorry, there was a problem and we can't open this document.  If this happens again, try opening the document in Microsoft Word."

Here is an example of what we are seeing in the ULS logs:

03/14/2014 14:02:40.53 w3wp.exe (UTMSSP01:0x1620) 0x0BB8 SharePoint Foundation General ai1wu Medium System.IO.FileNotFoundException: The system cannot find the file specified. (Exception from HRESULT: 0x80070002), StackTrace:    at Microsoft.SharePoint.SPWeb.GetList(String strUrl)     at Microsoft.SharePoint.SPWeb.get_SiteAssetsLibrary()     at Microsoft.SharePoint.Utilities.SPWOPIHost.GetHomeUrlForFile(SPFile file, Boolean isAttachment)     at Microsoft.SharePoint.SoapServer.Wopi.RunCheckFile(HttpContext context, CommonRequestData requestData, CommonResponseData responseData)     at Microsoft.SharePoint.SoapServer.Wopi.ProcessRequestCore(HttpContext context, CommonRequestData requestData, CommonResponseData responseData)     at Microsoft.SharePoint.SoapServer.Wopi.ProcessRequest(HttpContext context)     at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()     at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)     at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)     at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)     at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)     at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) 33bd837e-42a2-4d46-89cf-e992045d4964

The Resolution is to uninstall Office Web Apps 2013, re-install (on the C: drive), apply updates and rebuild the farm.

UPDATE:

This is a known issue with VMWare and below is a Knowledge Base article by VMWare to workaround this issue:

Disabling the HotAdd/HotPlug capability in ESXi 5.x and ESXi/ESX 4.x virtual machines (1012225)
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1012225

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 

Today Microsoft released a security patch, MS14-017: Description of the security update for Office Web Apps Server 2013: April 8, 2014 https://support.microsoft.com/kb/2878219 This security patch affects the .rtf file type.  However, the patch will not apply correctly with Office Web Apps 2013 server Service Pack 1.  When you apply the patch to the server, the following message will be presented:
 
 
 
 
 
 
Workaround:
 
The following steps address when the security patch, 2878219, is applied to an Office Web Apps 2013 Service Pack 1 server:
1. This Powershell command will provide the output of your server information to have when adding the Office web apps server back in a later step.: 
Get-OfficeWebAppsFarm >C:\Name_of_Folder_of_your_choice\WAC1.txt
  a. On the Office Web Apps Server that you want to apply the software update to open the Windows PowerShell prompt as an administrator and run the following command.  If you have multiple Office Web Apps servers at Service Pack 1
  b. Example:  Get-Officewebappsfarm shows the following servers: {WAC1, WAC2}.  In this case, WAC1 is the first server, which is the ‘parent’.  WAC2 is considered a ‘child’ server. 
  c. In that case, run the remove command below on WAC2 first, and then run it on WAC1.

   Remove-OfficeWebAppsMachine

*This will remove the Office web apps configuration from that machine. 

2. Uninstall Office Web Apps 2013 by using Add or Remove programs.  Reboot the server.
3. Reinstall Office Web Apps Server.   
4. After reinstall of Office web apps and before creating the new Office web apps server, then apply the December 2013 Cumulative Update:  http://support.microsoft.com/kb/2850013 
5. Then you may install the Security patch https://support.microsoft.com/kb/2878219 .
6. Restart the Office web apps server.
7. To complete deployment of Office Web Apps, refer to your WAC1.txt file created in Step 1 and the steps described in TechNet article: Deploy Office Web Apps Server:
 http://technet.microsoft.com/en-us/library/jj219455(v=office.15).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.

Yes, Windows Server 2012 R2 is support as of Office Web Apps 2013 SP1
The Planning page TechNet article has been updated to include Windows Server 2012 R2 in the supported OS list. http://technet.microsoft.com/en-us/library/jj219435.  There is an important Windows .NET Framework update you need to install for things to run more smoothly, however.  Read on...

Problem with Office Web Apps viewer testing
With the continued adoption of Windows Server 2012 R2, more issues with Office Web Apps 2013 are surfacing.  One glaring item from a testing standpoint is the inability to use the Office Web Apps test viewer to view Office documents.

Reference:  http://blogs.technet.com/b/office_web_apps_server_2013_support_blog/archive/2013/12/27/how-to-see-if-wac-server-is-working.aspx

No matter what file type, you will get a general "Sorry the <Office Web App> ran into a problem.." message whenever the view.aspx page is invoked by Office Web Apps.  Thankfully, this issue does not affect normal Lync, Exchange or SharePoint integration, but it does make testing nigh impossible. 

Answer:  .NET Framework 4.5.2
As a general practice, it is good to keep servers up with .NET Framework updates.  The 4.5.2 update for .NET Framework resolves the above issue with Windows Server 2012 R2, and may resolve a number of other as-yet-to-be-discovered issues with Office Web Apps.  Currently, using the Office Web Apps test viewer is the only confirmed issue on Windows 2012 R2, but other unconfirmed issues may also be corrected by applying .Net Framework 4.5.2.  If you encounter any Office Web Apps related issue you suspect may be specific to Windows Server 2012 R2, please make one of your first actions to install the .NET Framework 4.5.2.  Remember applying the update will likely require a reboot.

Here is the link:  http://www.microsoft.com/en-us/download/details.aspx?id=42643

Problem:

After upgrading SharePoint Server to SP1 or later, you are no longer able to view Word or PowerPoint documents with Office Web Apps Server 2013.

Symptom:

Office Web Apps give the error of "Sorry, we ran into a problem." and gives the options to Restart, or Exit.

Software combination scenarios we see the issue:

Internet Explorer, Office Web Apps Pre SP1 and SharePoint SP1 or greater

Solution:

Update Office Web Apps Server to at least SP1 (http://support.microsoft.com/kb/2880558)

*Note you must follow the process below to apply updates to Office Web Apps 2013

http://technet.microsoft.com/en-us/library/jj966220.aspx

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.

Increasing the size limit of embedded media for the PowerPoint Web App

Cause:

The Office Web Apps Server is limited to 50MB for embedded media in the PowerPoint Web App

Error:

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

Resolution:

We can increase the size of the limit as shown below:

1. On the Office Web Apps Server(s) edit the following file:

C:\Program Files\Microsoft Office Web Apps\PPTConversionService\Settings_Service.ini

2. Add the following lines at the bottom and save:

PowerPointEditServerMaxFileSizeBytes=(System.UInt64)153600000

PowerPointServerMediaEmbeddedMaxSize=(System.UInt64)153600000

3. Open a Admin PowerShell window on the Office Web Apps Server(s) and run:

Restart-service WACSM

This should allow up to 150MB videos to be embedded. You can adjust the byte value above to meet your needs.

Our team has seen an influx of cases where Office Web Apps Server 2013 is functioning on a global scale (all workbook books are opening in the WOPIFrame), but for some reason (Unsupported Features) workbooks cannot be opened in the browser and the below message is thrown:

We have also seen these errors which is most likely something corrupt in the workbook (like a shape/object).

The question then arises, "Where are these Unsupported Features and what is the  best method to locate these?"  We do have a tool that can analyze the entire workbook:

Excel Services Compatibility Checker Add in - Beta

http://blogs.msdn.com/b/cumgranosalis/archive/2007/06/29/excel-services-compatibility-checker-addin-beta.aspx

Note: Excel will need to be 32-bit and the Click to Run (in my experience) will not load this COM add-in.  Download here.

If you do not see the add-in loaded when you launch Excel, you will need to go to (in Excel) File > Options > Add-ins > Manage: COM Add-ins > Go...

Choose Excel Services Compatibility Checker > OK

You will now see an Excel Services tab, you can now run a Server Compatibility Check to see where these Unsupported Features are.

Now you have proof there are a lot of Unsupported Features.  If you want to remove all the Unsupported Features you can by clicking Quick Fix, but this will remove all unsupported features when this tool was built (2007).  In most case the culprit is a (or several) shape(s)/object(s), but not all of them.  You are probably asking yourself, "Ok, so how do I find which ones are bad?"  I will do my best to explain what I have done.  First off, you could have 10 worksheets and you don't want to remove all shapes/objects from the workbook, cause some could be benign.  I like to pick the workbook apart sheet by sheet.  To do this, right click on a sheet Move or Copy... > (new book) > Create a copy

 
Now upload that workbook (again, containing just one worksheet) to SharePoint.  If that works, you know the culprit (Unsupported Feature - object/shape) is not in that worksheet.  Move on to the next worksheet until you find one that does not load in the browser.  Now, in Excel > Home tab > Find & Select > Go To Special > Objects

You will now see all Objects are selected in that workbook (the border will be selected).  If you click the Delete key all the objects (and shapes) will be removed.  You can then re-upload to SharePoint and test.  If it opens, you know that an object/shape is the culprit.  You will then need to step through each object (delete it and test) to see if you can isolate which object(s) are the culprit.  It is rather lengthy and time consuming, but this is the best solution I have found and can help you from having to remove every object/shape from the workbook or rebuilding the workbook.

Additional Resources:

Differences between using a workbook in Excel and Excel Services

http://office.microsoft.com/en-us/excel-help/differences-between-using-a-workbook-in-excel-and-excel-services-HA010021716.aspx

Excel Services part 12: Unsupported features

http://blogs.office.com/b/microsoft-excel/archive/2005/12/01/excel-services-part-12-unsupported-features.aspx

Excel Services in SharePoint 2010 Feature Support

http://blogs.msdn.com/b/excel/archive/2009/11/19/excel-services-in-sharepoint-2010-feature-support.aspx

Edit a workbook that contains features unsupported by Excel Web App

http://office.microsoft.com/en-us/office-online-help/edit-a-workbook-that-contains-features-unsupported-by-excel-online-HA102540964.aspx?CTT=1

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.

Issue:

Users click command "Copy Link to this Page..." from Onenote Web App to create a shortcut link to a specific page in the notebook.  When that link URL is used, it brings up the notebook but does not navigate to the specific page.

This affects both SharePoint online and on premise.

Cause:

If the URL is greater than 255 characters this feature does not work, if less than 255 characters then all works.

Workaround:

Far from ideal, but if you shorten the name of the notebook section and page name then the URL will be shorter.

Notes:

The product group has been made aware of this issue and it maybe resolved in a future version or patch.

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.

Overview:

You have Office Web Apps 2010 installed, Word and PowerPoint viewing does not work, but the editing does.

The appserverhost.exe process is crashing on startup, with error:

System.ServiceModel.EndpointNotFoundException 
"There was no endpoint listening at net.pipe://127.0.0.1/e31bfd4c-5d98-4dc3-8232-5d2601ca814d that could accept the message. This is often caused by an incorrect address or SOAP action...."

Cause:

The SharePoint third party workflow product Nintex cause this issue.

Workaround:

Stopping all Nintex  Windows services on the SharePoint server that runs the Word Conversion Service.