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

Issue: You receive"Sorry, something went wrong" when trying to Open/Preview a document in Office Web Apps.

Cause: This was caused by being logged onto the server as the System Account.

If you collect logs and review them, you will see:

Unhandled exception: System.NotSupportedException: Can not create an identity context for system account user token.     at Microsoft.SharePoint.IdentityModel.SPIdentityContext.Create(SPUserToken token

Solution: Make sure you’re not logged in as System Account because you won’t be able to edit or view a document. Log on as a different user and try to access Office Web Apps again.

Configure Office Web Apps for SharePoint 2013
http://technet.microsoft.com/en-us/library/ff431687

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 
 

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.

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

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.

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.

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).

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.

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:

Document preview for SharePoint 2013 search results randomly give an error "To start seeing previews, please log on by opening the document".

CAUSE:

The behavior occurs because the page that we use to show the preview (_layouts/15/wopiframe.aspx) is set up for anonymous access.  Since the user did not browse the site collections from where the documents to be displayed reside, there is no access token which can be presented in order to retrieve the file. If the browser does not supply the authentication token with the request for the page, the user will be authenticated anonymously, which will not have access to the document that is supposed to be shown in the preview.  Now in the case where the user is authenticated, the browser sometimes drops the authentication token so that even though the user is authenticated on the outer page, the wopiframe request does not contain the auth token and we end up with the “to start seeing previews…” message.

RESOLUTION:

For Windows NTLM authentication only, a fix to target this scenario is included May 2014 CU or later.

For other authentication providers including Kerberos, there are a few workarounds:

1.  Use the Wopiframe2.aspx logic in place of Wopiframe.aspx:

     1.        Open the file location C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS
     2.        Locate wopiframe.aspx.  Rename it to wopiframe.aspx.bak.  – This will be our backup copy.
     3.        Locate Wopiframe2.aspx.  Make a copy of it and paste it in the same directory.  Rename it to Wopiframe.aspx.
     4.        Open the file location: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS
     5.        Repeat steps 2 and 3 within the 15\Template\Layouts folder.
     6.        Reset IIS on the box.

               – Possible issues with the above workaround:

                     -Anonymous users may get prompted when looking at document previews.

                     -Wopiframe.aspx could be overwritten and set back to default by a CU.

                     –Previews of Excel files may return message "We can't show a preview of this item". 

2.  Switch to NTLM

3.  Disable the preview functionality

4.  Refresh the browser

Over the past month, we've spoken to many customers regarding our newly released Dropbox integration for Office Online.

The Office announcement blog HERE does a great job of illustrating what the integration does and how it works.

However, our customers brought up some very valid concerns regarding the integration. So we wanted to quell some of the misconceptions and tell you what it can't do, as it's easy to make assumptions about how it all works.

First, let's address the question/concern everyone seems to have. There is no mechanism for users to save Office 365 hosted documents directly to Dropbox via Office Online. The only way this could conceivably happen is if the user saves the document to their local machine and then manually uploads it to Dropbox. It should be noted that saving the document locally with Office Online was always possible, even before Dropbox was in the picture.

Next, let's delve a bit deeper into how Office Online decides where to save the document, and how that relates to the Dropbox integration.

If you're interested in the deeper technical side of how Office Online determines where to save a document, please reference my other blog on the subject HERE. If not, skip ahead to the next paragraph for a high overview.

From a high level, here are the major points to keep in mind when discussing Dropbox integration.

1. If a user is accessing an Office 365 service which is able to utilize Office Online (OneDrive for Business/SharePoint Online/etc.) there is no mechanism in Office Online which allows you to save a document directly to Dropbox. This is because Office Online knows where the document came from, therefore it will try to save it back to that location. The availability of Dropbox integration elsewhere doesn't change this behavior. Please see the screenshot below from Word Online. With Word Online, saving happens automatically in the background, Save As contains no options for Dropbox. Also notice that the default navigation option is set to my OneDrive for Business site by default.

2. The same goes for the inverse scenario. If a user is accessing their Dropbox library, and they open a document for editing, there is no mechanism in Office Online which allows you to save a document directly to Office 365. Again, because Office Online knows where the document came from, it will save it automatically back to that location.  Notice the default location below when opening from Dropbox.

3. The only scenario available where Office Online doesn't have an established default save location is through https://office.live.com. In this instance there is a dropdown menu at the top of the screen which lets you establish a default save location, OneDrive or Dropbox. Once you've chosen where the document will go, the options for saving the file will lock in the same way as if you had opened it from that location. PLEASE NOTE: If you are signed in to office.live.com with a personal Microsoft account, documents will be saved to your PERSONAL OneDrive. If you are signed in with a work/organization/school account, documents will be saved to your OFFICE 365 OneDrive for Business. The dropdown menu will reflect what type of account you're logged in with. Please see screenshots below.

Signed in with a personal Live ID:

Signed in with an Office 365 organization ID:

4. As far as the messaging regarding the availability of Dropbox is concerned, at this time there is no way to turn the messaging off for your tenancy.  The Office Online product group's current position is that they won't be providing any mechanism to turn the messaging off.  Simply clicking "Got it" will close the message and it will never return for that user.

As always, feedback is welcomed and encouraged in the comments below.

EDIT 7/10/15:

Due to customer feedback The Office Web Apps product group has removed the ability to open documents from Dropbox from office.live.com if you are signed in with a work/school account.

Please see the screenshot below where a user is signed in with a work/school account. The Dropbox integration is unchanged if you are logged in with a personal Microsoft account.

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).

With the Application Request Routing service becoming more widely used it was felt that it would be good to touch on how this can be used as a reverse proxy for Office Web App deployments. (this does not cover how to install the ARR software on the server or configuration for external sharepoint use).

1. To start open IIS

2. The first step is we need to add your web app servers to the configuration. So go to "Server Farms", right click and select "Create Server Farm"

 a. Server Farm Name should be a friendly name or a name that allows you to differentiate between your web apps servers and lync servers or sharepoint servers

 b. Server addresses should be the FQDN

 c. the end result resembling below.

3. Once added to the server farms the next stage is to configure your url routing. This is the portion that looks at the traffic coming in and routes specific types of traffic to different servers i.e. separating sharepoint traffic from office web apps traffic

 a. Select the root location from the navigation pane in IIS

 b. now select "url rewrite"

  1. you will see a rule has been created for the server you added doubleclick that rule and it will take you to  "edit inbound rule"

  2. Requested URL should be "matches the pattern" Using should be changed to "Regular Expression" and the Pattern should be the following (.*) Ignore case should be checked

  3. We need to now add a condition.

   a. Input should be {http_host}

   b. Type should be Matches the pattern

   c. Pattern should be as follows ^prefixofexternalurl\.domainofexternalurl\.com$  an example being ^share\.contoso\.com$ (this is what tells the ARR to reroute this specific traffic when it's sent)

Once all of the above is done you should be able to run an IIS reset and test. Again the above is only the ARR configuration settings. Your external users will not work unless you've configured the sharepoint wopi zones correctly and routed public traffic via public dns to this servers public IP address.  A good way to test to verify that you have everything configured correctly for your office web apps would be to have an external resource attempt to access your externalurl for office web apps hosting discovery i.e. share.contoso.com/hosting/discovery. If you're able to see an xml page then everything should be configured correctly.

Hello Everyone,

The point of this blog is to help you understand your options when configuring OWA to work with external users.

There is one major configuration issue with this, that is that office web app calls need to be passed through, seemingly, without being challenged. In lync 2013 there are articles that talk about the configuration of your TMG reverse proxy. It is suggested that you leave the web apps portion accessible anonymously. This is considered acceptable because if everything else is https that leaves very little in the way of security vulnerabilities.

The reason for this is because office web apps need to be able to communicate via OAuth from client to host (user pc to sharepoint).

The above just means that your web apps calls need to be anonymous OR they can be pre-authenticated(so any auth challenge is passed along without issue).

So if you’re using sharepoint and your users are logging in there first you just need to make sure that the session cookie issued applies to your web apps as well. This should stop a second authentication attempt from taking place.

Best way to test this is to first go to your hosting/discovery page via http(s)://<wacexternalurl>/hosting/discovery, you should see something like the below.

If you get an auth page then you want to test by first going to your sharepoint site > leave that page open >then test the above. If you have a session cookie configured correctly it should open without issue.

If you still get redirected to an authentication page then you want to look at the security token being issued by your authentication provider. Whatever is being issued isn’t covering the traffic to the web apps server as well.

If you can get the above to work, but are still having issues try reaching the http(s)://<wacexternalurl>/op/generate.aspx page. This page allows you to test a client machines ability to display rendered owa documents.

Once you’ve configured your security to allow for seamless travel with pre-auth or anonymous you should be able to now view documents in browser.

Problem:

When using .NET 4.6+ the Office viewers or op/generate.aspx will not work and give the following “This page can’t be displayed” error.

Cause:

The new .NET Framework version 4.6 and higher includes a new Just-In-Time (JIT) compiler.

Solution:

A couple of workarounds are detailed here (https://github.com/Microsoft/dotnet/blob/master/docs/testing-with-ryujit.md#net-framework-46—troubleshooting-ryujit)

The easiest workaround identified is to use the following registry key to disable the new JIT compiler on the Office Web Apps server that will be using op/generate or the Office viewers.

Using Registry Editor (regedit.exe), find either of the following subkeys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
Then, add the following:
Value name: useLegacyJit
Type: DWORD (32-bit) Value (also called REG_WORD)
Value: 1