Contents tagged with Office Web Apps

  • Office Web Apps Server will only be available for Volume License customers shortly

    Tags: Office Web Apps

    Office Web AppsToday the Office Updates blog added a new blog post titled “Web Apps Server Removal from Download Center”. The contents of that blog post is short:

    As of 11-24-2014 Office Web Apps Server will be removed from the Microsoft Download Center.  At that time it will only be available for download under Volume Licensing agreements.  For more information please visit the site Volume Licensing Service Center.

    Office Web Apps Server, used by SharePoint, Exchange and Lync to view, preview and edit Office documents is and has been one of the key features/add-ons of these products and allows for browser based editing and collaboration. It has up until now been available as a free download, free from licensing for reading but requiring Office client licensing for editing.

    So from the 24th of November you will not be able to download Office Web Apps Server (WAC) from the Microsoft Download center. To download it you will be required to have a Volume License agreement with Microsoft and you will only be able to download it from the Volume Licensing Service Center.

    Why this move? I don’t know. I will try to find out though… This will most likely cause a annoyances for developers and when testing, but I assume that most organizations using WAC likely have a Volume License agreement anyways. What do you think?

    [Update 2014-10-29]: The original blog post has been updated with a small FAQ. The interesting things to note there is that for evaluation there will still be a downloadable copy for MSDN subscribers, and “EXISTING [my emphasis] Web Apps Server installations will continue to be licensed for viewing”. That leaves us with the question – will Office Web Apps Server NOT be free for viewing from now on?

  • SPC14: Scripts for Mastering Office Web Apps 2013 operations and deployments

    Tags: Office Web Apps, Presentations, WAC Server, Exchange 2013, SharePoint 2013

    Here’s another post with scripts from my sessions at SharePoint Conference 2014 – this time from the Mastering Office Web Apps 2013 Operations and Deployments session (SPC383). To get a more in-depth explanation of all the details, please watch the recording at Channel 9.

    Let’s start…but first! OWA = Outlook Web App and WAC = Office Web Apps (Web Application Companion).

    Preparing the machine before installing Office Web Apps

    Before you install the Office Web Apps bits on the machine you need to install a set of Windows Features. The following script is the one you should use (not the one on TechNet) and it works for Windows Server 2012 and Windows Server 2012 R2.

    # WAC 2013 preparation for Windows Server 2012 (R2)
    Import-Module ServerManager
    # Required Features
    Add-WindowsFeature NET-Framework-45-Core,NET-Framework-45-ASPNET,`
    # Recommended Features
    Add-WindowsFeature Web-Stat-Compression,Web-Dyn-Compression
    # NLB
    Add-WindowsFeature NLB, RSAT-NLB
    Note, that I also add the NLB features here – it is not required if you use another load balancer.

    Starting a sysprepped WAC machine

    The following script is used when booting up a sysprepped machine that has all the Office Web App binaries installed (including patches and language packs), but no WAC configuration whatsoever. It will simply configure a NIC on the box and then join the machine to a domain and rename the machine. A very simple script that can be automated. Most of the scripts, just as this one, contains a set of variables in the beginning of the script. This makes it much more easier to modify and work with the scripts.

    $domain = "corp.local"
    $newName = "WACSPC2"
    $ou = "ou=WAC,dc=corp,dc=local"
    $ethernet = "Ethernet1"
    $ip = "" 
    $prefix = 24
    $dns = ""
    # Set IP
    Write-Host -ForegroundColor Green "Configuring NIC..."
    New-NetIPAddress -InterfaceAlias $ethernet -IPAddress $ip -AddressFamily IPv4 -PrefixLength $prefix 
    Set-DnsClientServerAddress -InterfaceAlias $ethernet -ServerAddresses $dns
    # Verify 
    # Get creds
    $credentials = Get-Credential -Message "Enter credentials with add computer to domain privilegies"
    # Join domain
    Write-Host -ForegroundColor Green "Joining domain..."
    Add-Computer -Credential $credentials -DN $domain -OUPath $ou 
    # rename
    Write-Host -ForegroundColor Green "Renaming machine..."
    Rename-Computer -NewName $newName
    # Reboot
    Write-Host -ForegroundColor Green "Restarting..."

    Once this script is executed the machine should reboot and be joined to a domain.

    Configure a new Office Web Apps Farm

    Once the machine is joined to the domain it is time to configure Office Web Apps. If you want more information about the variables/parameters I use I recommend watching the session! These variables are solely for demo purposes and you should adapt them to your needs. Also this step requires that you have a valid certificate (pfx file) that conforms to the WAC certificate requirements.

    # New WAC Farm
    Import-Module OfficeWebApps
    $farmou = "WAC"                           # Note the format!!
    $internalurl = "https://wacspc.corp.local"
    $externalurl = ""
    $cachelocation = "c:\WACCache\"           # %programdata%\Microsoft\OfficeWebApps\Working\d\
    $loglocation = "c:\WACLog\"               # %programdata%\Microsoft\OfficeWebApps\Data\Logs\ULS\
    $rendercache = "c:\WACRenderCache\"       # %programdata%\Microsoft\OfficeWebApps\Working\waccache
    $size = 5                                 # Default 15GB
    $docinfosize = 1000                       # Default 5000
    $maxmem = 512                             # Default 1024
    $cert = "wacspc.corp.local.pfx"              # File name
    $certname = "wacspc.corp.local"              # Friendly name
    $certificate = Import-PfxCertificate -FilePath (Resolve-Path $cert) -CertStoreLocation  Cert:\LocalMachine\My -ea SilentlyContinue 
    $certificate.DnsNameList | ft Unicode
    New-OfficeWebAppsFarm -FarmOU $farmou `
        -InternalURL $internalurl `
        -ExternalURL $externalurl `
        -OpenFromUrlEnabled `
        -OpenFromUncEnabled `
        -ClipartEnabled `
        -CacheLocation $cachelocation `
        -LogLocation $loglocation `
        -RenderingLocalCacheLocation $rendercache `
        -CacheSizeInGB $size `
        -DocumentInfoCacheSize $docinfosize `
        -MaxMemoryCacheSizeInMB $maxmem `
        -CertificateName $certname `
        -EditingEnabled `
    (Invoke-WebRequest https://wacspc1.corp.local/m/met/participant.svc/jsonAnonymous/BroadcastPing).Headers["X-OfficeVersion"]

    As a last step I do a verification of the local machine and retrieve the current Office Web Apps version.

    Create the NLB cluster

    In my session I used NLB for load balancing. The following scripts creates the cluster and adds the machine as the first node to that cluster. The script will also install the DNS RSAT feature and add two DNS A records for the internal and external names for the Office Web Apps Server. That step is not required and might/should be managed by your DNS operations team.

    # Create NLB Cluster
    $ip = ""
    $interface = "Ethernet1"
    # New NLB Cluster
    New-NlbCluster -ClusterPrimaryIP $ip -InterfaceName $interface -ClusterName "SPCWACCluster" -OperationMode Unicast -Verbose
    # DNS Bonus
    Add-WindowsFeature  RSAT-DNS-Server  
    Import-Module DnsServer
    Add-DnsServerResourceRecordA -Name "wacspc" -ZoneName "corp.local" -IPv4Address $ip -ComputerName ( Get-DnsClientServerAddress $interface  -AddressFamily IPv4).ServerAddresses[0]
    ping wacspc.corp.local
    Add-DnsServerResourceRecordA -Name "wacspc" -ZoneName "" -IPv4Address $ip -ComputerName ( Get-DnsClientServerAddress $interface  -AddressFamily IPv4).ServerAddresses[0]

    Adding additional machines to the WAC farm

    Adding additional machines to the WAC farm is easy, just make sure you have the certificate (pfx file) and use the following scripts on the additional machines:

    Import-Module OfficeWebApps
    $server = "wacspc1.corp.local"
    $cert = "wacspc.corp.local.pfx"  
    Import-PfxCertificate -FilePath (Resolve-Path $cert) -CertStoreLocation  Cert:\LocalMachine\My -ea SilentlyContinue 
    New-OfficeWebAppsMachine -MachineToJoin $server
    # Verify

    Configuring NLB on the additional WAC machines

    And of course you need to configure NLB and add the new WAC machines into your NLB cluster:

    $hostname = "WACSPC1"
    $interface = "Ethernet1"
    Get-NlbCluster -HostName $hostname | Add-NlbClusterNode -NewNodeName $env:COMPUTERNAME -NewNodeInterface $interface

    That is all of the scripts I used in the session to set up my WAC farm. All that is left is to connect SharePoint to your Office Web Apps farm

    Configure SharePoint 2013

    In SharePoint 2013 you need to add WOPI bindings to the Office Web Apps farm. The following script will add all the WOPI bindings and also start a full crawl (required for the search previews):

    The first part (commented out in this script) should only be used if your SharePoint farm is running over HTTP (which it shouldn’t of course!).

    asnp microsoft.sharepoint.powershell -ea 0
    # SharePoint using HTTPS?
    #$config = Get-SPSecurityTokenServiceConfig
    #$config.AllowOAuthOverHttp = $true
    # Create New Binding
    New-SPWOPIBinding -ServerName wacspc.corp.local
    Get-SPWOPIBinding | Out-GridView
    # Check the WOPI Zone
    # Start full crawl
    $scope = Get-SPEnterpriseSearchServiceApplication | 
        Get-SPEnterpriseSearchCrawlContentSource | 
        ?{$_.Name -eq "Local SharePoint Sites"}
    # Wait for the crawl to finish...
    while($scope.CrawlStatus -ne [Microsoft.Office.Server.Search.Administration.CrawlStatus]::Idle) {
        Write-Host -ForegroundColor Yellow "." -NoNewline
        Sleep 5
    Write-Host -ForegroundColor Yellow "."

    Connect Exchange 2013 to Office Web Apps

    In the session I also demoed how to connect Office Web Apps and Exchange 2013. The important things here to remember is that you need to specify the full URL to the discovery end-point and that you need to restart the OWA web application pools.

    # WAC Discovery Endpoint
    Set-OrganizationalConfig -WACDiscoveryEndpoint https://wacspc.corp.local/hosting/discovery
    # Recycle OWA App Pool
    Restart-WebAppPool -Name MSExchangeOWAAppPool
    # (Opt) Security settings
    Set-OwaVirtualDirectory "owa (Default Web Site)" -WacViewingOnPublicComputersEnabled $true -WacViewingOnPrivateComputersEnabled $true


    I know I kept all the instructions in this blog post short. You really should watch the recording to get the full picture. Good luck!

  • SPC 14 sessions, recordings and wrap-up

    Tags: Presentations, SharePoint 2013, Office Web Apps, Conferences

    Wow, that was an awesome conference! SharePoint Conference 2014 is over and I’m very glad I attended the conference – both as a speaker and attendee. Finally Microsoft and the SharePoint Product Group told us about their future and vision for SharePoint and SharePoint Online. If you knew how long we have waited for this…

    I’m glad they start to sort out the service (ie Office 365) and now can add new capabilities into the platform.
    I’m glad Jeff Teper officially said that there will be at least one more version of SharePoint on-premises.
    I’m glad that the product group is listening to our and our customers feedback.
    I’m glad that we have such a strong community
    I’m excited about the future of SharePoint (to be honest, it’s been some time since I had that feeling).

    My sessions

    As a first time speaker at this event I was a bit nervous, which the ones who attended my sessions might have noticed. I’m proud that so many people turned up on my sessions, especially the Architecture session where we had people standing in the back and we had 90 minutes of Q&A at the end! That was cool! Unfortunately the room where I had all my three sessions suffered from severe microphone issues (which impacts my session ratings), apart from that everything except one demo was a success. Everything was recorded so if you did not have time to attend my sessions or just want to see them again here they are:

    Real-world SharePoint architecture sessions (SPC334)

    Mastering Office Web Apps 2013 operations and deployments (SPC383)

    Designing, deploying, and managing Workflow Manager farms (SPC356)

    Co-presented with Spencer Harbar.


    If you have any questions on my sessions, feel free to post them here. And before you ask – yes, I will post all the PowerShell scripts I used, but in a separate blog post(s).

    If you’d like to watch more videos from SPC14, head on over to Channel 9 and take a look at any of the keynotes and sessions for free. I’m really looking forward to see the what’s up next with SharePoint, I think the next conference (whatever it will be called) will be something very different from this one.

  • Office Web Apps 2013: Excel Web App ran into a problem - not rendering Excel files

    Tags: Office Web Apps, WAC Server


    This is a story from the trenches where Excel Web App in Office Web Apps 2013 refuses to render Excel documents, while other Apps such as Word and PowerPoint works just fine. The end-users are met with the generic error message: “We’re sorry. We ran into a problem completing your request.”

    Houston - we got a problem

    The problem is easy to solve but can be somewhat difficult to locate and in this post I will show you how to find the issue and fix it.


    Whenever Office Web Apps 2013 fails to render a document it shows the end-users a generic error message without any details. Fortunately the Office Web Apps Server contains good logging mechanisms and will in most cases give you an idea on where to solve it and in some cases it’s written in clear text.

    This specific issue, for the Excel Web Apps, shows itself in three different places (except for the error message that is shown in the user interface). First of all “normal” sys admins will see a couple of errors in the System Event Log manifesting itself like this:

    System log

    Event Id 5011:

    A process serving application pool 'ExcelServicesEcs' suffered a fatal 
    communication error with the Windows Process Activation Service. 
    The process id was '2168'. The data field contains the error number.

    Event Id 5002:

    Application pool 'ExcelServicesEcs' is being automatically disabled due to a series 
    of failures in the process(es) serving that application pool.


    Pretty nasty messages which does not give you a clue, except that something is horribly wrong. There are also lots of Dr Watson log entries in the Application log which might cause the admin to start looking up the Microsoft support phone number.

    The more “clever” admin then knows that Office Web Apps actually has it’s own log in the Event Viewer. When checking that log messages like the following are shown for the Excel Web App:

    Event Id 2026:

    An internal error occurred.
       at System.Diagnostics.PerformanceCounterLib.CounterExists(String machine, String category, String counter)
       at System.Diagnostics.PerformanceCounter.InitializeImpl()
       at System.Diagnostics.PerformanceCounter..ctor(String categoryName, String counterName, String instanceName, Boolean readOnly)
       at System.Diagnostics.PerformanceCounter..ctor(String categoryName, String counterName, Boolean readOnly)
       at Microsoft.Office.Excel.Server.CalculationServer.ExcelServerApp.Initialize()
       at Microsoft.Internal.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, 
          TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

    This should actually start to give you an idea – something is wrong with the Performance Counters on this machine. Worst thing to do here is to start fiddling with the registry and try to fix it or start adding users/groups into the performance counter groups.

    The “smartest” Office Web Apps admin then takes a look at the Trace Logs (ULS) (and that admin most likely read my SharePoint post “The Rules of SharePoint Troubleshooting” – if not, he/she should!). This is what will be found:

    Excel Web App                 	Excel Calculation Services    	cg34	Unexpected	Unexpected exception occured 
      while trying to access the performance counters registry key. Exception: System.InvalidOperationException: Category does not 
      exist.     at System.Diagnostics.PerformanceCounterLib.CounterExists(String machine, String category, String counter)     at ...
    Excel Web App                 	Excel Calculation Services    	89rs	Exception	ExcelServerApp..ctor: An unhandled exception 
      occurred during boot. Shutting down the server. System.InvalidOperationException: Category does not exist.     at 
      System.Diagnostics.PerformanceCounterLib.CounterExists(String machine, String category, String counter)     at 
      System.Diagnostics.PerformanceCounter.InitializeImpl()     at ...
    Excel Web App                 	Excel Calculation Services    	89rs	Exception	...atchBlock, FinallyBlock 
      finallyBlock) StackTrace:  at uls.native.dll: (sig=4635455b-a5d6-499c-b7f2-935d1d81cf8f|2|uls.native.pdb, offset=26E32) at 
      uls.native.dll: (offset=1F8A9)	 

    The key thing here is the “Category does not exist” message.

    When the Excel Web App Calculation Services is starting (and the Excel Calc Watchdog) it is trying to read a performance counter. If that performance counter is not found – it will just crash!

    Unfortunately there is no good way to find out which performance counter it is trying to use, except firing up good ole Reflector. Using that tool we can find that it is trying to access an ASP.NET performance counter.


    The fix for the problem is easy – we just need to register/update the performance counters for ASP.NET. This is done using the lodctr.exe tool like this:

    lodctr C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_perf.ini

    Give it a few seconds and then retry to load an Excel file using Office Web Apps and all your users should once again be happy.


    A simple fix to an annoying problem, which could be difficult to locate unless you know where to look (and in this case also have the skillz to read some reflected code).

    This error might not be so common, but it shows the importance of having a correctly installed machine and that you shouldn’t go fiddling with settings or the registry if you’re not really sure on what you’re doing – ok, not even then…

  • Office Web Apps Server: Which version is installed?

    Tags: Office Web Apps, WAC Server

    If you have been working with SharePoint you should know by now how to get the build version of an installation using PowerShell. Knowing the version of the installation is crucial for troubleshooting and knowing what features or limitations the current installation has, given the new release cadence. If you don’t know how to do it then Bing for it and then return here. But how do you do the same for Office Web Apps Server 2013?

    Retrieve the version number of an Office Web Apps Server installation

    Knowing the current version for Office Web Apps Server 2013 (WAC) is also important to know. Just as with SharePoint new features and bugs can and will be introduced over time and you need to know the version to be able to correctly get support and to patch it. Unfortunately there is not such an easy approach as with SharePoint – we cannot use the WAC cmdlets to get the current build version.

    Instead we can rely on another PowerShell method – Invoke-WebRequest. Hmm, that has nothing to do with WAC you might be thinking, which is true. But Office Web Apps returns the current version as an HTTP Header – the X-OfficeVersion header.

    In order to do use this cmdlet and to invoke an HTTP request we also need to send an anonymous request, to avoid 401’s. For this we can use one of the anonymous end-points that Office Web Apps Server exposes, for instance the end-point for the broadcast ping, like this:


    As you can see we request the endpoint, and retrieve the specific version header from the response. This will return the current build version of your WAC farm, for instance “15.0.4535.1000” which is the August 2013 hotfix for WAC.

    Known version numbers

    I have collected the known version numbers of Office Web Apps Server 2013 on this page I will try to continuously update it as the WAC server retrieves new patches and upgrades. As a bonus I also added version numbers for the version that SkyDrive currently uses (interesting!).

  • Office Web Apps Versions

    Tags: Office Web Apps, WAC Server, WAC, SkyDrive, OneDrive, Office Online, OneNote

    This page contains the versions for Office Web Apps Server/Office Online (aka WAC Server) both for the on-premises version and the cloud version used in Office 365 and SkyDrive/OneDrive.

    Office Web Apps Server 2013 (on-premises)

    Version number retrieved using the following method:


    Name Version KB
    RTM 15.0.4420.1007
    March 2013 Public Update (1) 15.0.4481.1005 KB2760445
    April 2013 Update 15.0.4481.1508 KB2810007
    August 2013 Hotfix 15.0.4535.1000 KB2817521
    October 2013 Cumulative Update (2) 15.0.4551.1003 KB2825686
    November 2013 Update (3) 15.0.4551.1005 KB2837634
    December 2013 Hotfix 15.0.4551.1508 KB2850013
    January 2014 Security Update (MS14-001) 15.0.4551.1515 KB2863879
    Service Pack 1 Preview 15.0.4569.1001 n/a
    Service Pack 1 15.0.4569.1506 KB2817431
    Service Pack 1 - Rerelease 15.0.4571.1502 KB2880558
    April 2014 Public Update 15.0.4605.1001 KB2863899
    May 2014 Public Update 15.0.4615.1001 KB2880453
    June 2014 Cumulative Update 15.0.4623.1001 KB2881051
    July 2014 Cumulative Update 15.0.4631.1000 KB2883003

    Version notes

    1. Introduced new WOPI bindings, most significantly for WordPdf
    2. Removal of one WOPI binding; mobileView for WordPdf removed
    3. Includes fix for reported event log id's 1009 and 1150

    OneDrive/SkyDrive/Office 365 (cloud)

    This are found version numbers of the public SkyDrive, which uses Office Web Apps Server. The version number is retrieved using this PowerShell command:


    (Invoke-WebRequest -Uri -Method POST).Headers["X-OfficeVersion"]

    Date detected
    2013-10-15 16.0.1727.1037
    2013-10-17 16.0.1727.1038
    2013-10-30 16.0.1727.1041
    2013-11-07 (1) 16.0.2130.3000
    2013-11-08 16.0.2130.3002
    2013-11-20 16.0.2130.1021
    2013-12-11 16.0.2130.1029
    2014-01-13 16.0.2130.1035
    2014-01-22 (2) 16.0.2430.3006
    2014-01-27 16.0.2430.3106
    2014-01-28 16.0.2430.3008
    2014-01-31 16.0.2430.1009
    2014-02-05 16.0.2430.1010
    2014-02-16 16.0.2430.1013
    2014-02-16 (3) 16.0.2430.3014
    2014-03-12 16.0.2430.1019
    2014-03-14 16.0.2430.3019
    2014-03-19 16.0.2430.1022
    2014-03-28 16.0.2430.3024
    2014-04-03 16.0.2430.1026
    2014-08-05 16.0.3030.3108
    2014-08-05 16.0.3030.1014
    1. Roll out of new real-time co-authoring: Collaboration just got easier: Real-time co-authoring now available in Office Web Apps 
    2. Big update to the user interface
    3. Excel Web App now mentioned as Excel Online in the UI (OneDrive service went live as well)


    (Invoke-WebRequest -Uri -Method POST).Headers["X-OfficeVersion"]

    Date detected
    2013-11-07 16.0.1727.1041
    2013-11-08 16.0.2130.3002
    2013-11-20 16.0.2130.1021
    2013-12-11 16.0.2130.1029
    2014-01-13 16.0.2130.1035
    2014-01-22 16.0.2430.3006
    2014-01-27 16.0.2430.3106
    2014-01-28 16.0.2430.3008
    2014-01-31 16.0.2430.1009
    2014-02-05 16.0.2430.1010
    2014-02-16 16.0.2430.1013
    2014-02-16 16.0.2430.3014
    2014-03-12 16.0.2430.1019
    2014-03-14 16.0.2430.3019
    2014-03-19 16.0.2430.1022
    Stopped tracking

    (Invoke-WebRequest -Uri -Method POST).Headers["X-OfficeVersion"]

    Date detected
    2014-01-31 16.0.2524.3000
    2014-02-11 16.0.2606.1000
    2014-02-13 16.0.2610.1000
    2014-02-18 16.0.2611.1000
    2014-03-12 16.0.2707.3000
    2014-03-14 16.0.2710.3004
    2014-03-19 16.0.2714.1000
    2014-03-28 16.0.2721.1000
    2014-08-05 16.0.3201.1552
    2014-08-25 16.0.3221.1551

  • An explanation to “To start seeing previews, please log on by opening the document.” in SharePoint 2013

    Tags: SharePoint 2013, Office Web Apps

    Overview and background

    To start seeing previews, please log on by opening the document.This post is intended to show and explain why you see the intermittent (and annoying) “To start seeing previews, please log on by opening the document.” message when using previews from Office Web Apps Server 2013 (WAC) with SharePoint 2013. Unfortunately I do not have the magic bullet (yet) on how to solve it completely, this post is more on why you get it and how you can avoid seeing it too often.

    SharePoint 2013 allows you to view and edit Office documents in the browser using the Office Web Apps Server 2013. You also have the benefit that you can see previews of these documents in for instance Document Libraries and Search Results. Sometimes, in some farms more than others, the end users get a message that says “To start seeing previews, please log on by opening the document.”. Most often you resolve the issue by clicking on the link in the message – but this is not a waterproof solution.

    Why this message?

    First of all I need to say – the message have nothing to do with Office Web Apps Server 2013, it’s a SharePoint 2013 implementation issue, and there are two major reasons why this can happen. The message can only happen in these previews (InteractivePreview in WOPI speak) – and if you pay extra attention to the link in the message you will see that the link takes you to another display mode – the view mode (View in WOPI).

    This is the URL that shows the message:

    This is the URL in the link:

    Anonymous Access enabled on the Web Application

    The first reason for this to happen is when you have enable Anonymous Access on the Web Application that hosts the document AND that the current site has not enabled any anonymous access (AnonymousState on the SPWeb is set to Disabled) . This is a hardcoded setting and you cannot work around it. I don’t have the whole background to it, but I do think it’s a security measure to prohibit anonymous users accessing content they should not have access to. One of the reasons behind this thinking is that the WopiFrame.aspx page is actually inheriting from the UnsecuredLayoutsPageBase – a specific class used for Layout/Application pages that does not need any authentication. This of course is a requirement if you would like to show previews on an anonymous site. Unfortunately this issue hits you if you have the need to have something partly anonymous and partly authenticated such as in an extranet.

    The user is not authenticated!

    The second, and by far most common, issue is that the message very randomly appears. SharePoint 2013 has hardcoded the logic, so that if you are not authenticated you should of course see this message – nothing wrong with that. The problem is that we’re using the WopiFrame.aspx page – which can accept anonymous requests.

    Since we’re using Claims Mode authentication for the Web Application (a requirement for WAC) the end users will eventually be un-authenticated when their tokens time out and they need to re-authenticate. The WopiFrame.aspx will not do that for us – it will just say sorry you’re anonymous and show the message.

    Note: A non functional Distributed Cache or not using session affinity can make this problem worse, making the message appear more frequently.

    And now we come to something that I find very peculiar. There is actually another layouts page – the WopiFrame2.aspx file. This one inherits from the LayoutsPageBase which will force us to authenticate and at least check that the user has view and open permissions on the site. This page is not used at all (except in one specific case where the user is not authenticated as above, we’re in interactive preview mode, there is no HTTP context and/or some other crazy stuff – basically you’re not hitting it).

    It’s not much we can do about this either – I think it is partly a logic problem in the SharePoint code base and partly a result of the nature of Claims authentication.


    Unfortunately there is not much we can do about this problem at present, and I do hope that something with that logic could be improved in future releases of SharePoint (I tested it with 2013 June CU this time). The best option would be to always use WopiFrame2.aspx when Anonymous Access is not enabled – but that is just my thought…

    If anyone on the SharePoint Team responsible for the WOPI stuff could chime in I would appreciate it.

  • Office Web Apps 2013 why you can’t and shouldn’t install SharePoint 2013 on the same machine

    Tags: Office Web Apps, SharePoint 2013


    I frequently see one specific question asked on distribution lists, Twitter, Yammer and other social networks: “How do I install Office Web Apps 2013 (WAC) on the same machine as SharePoint 2013”, very frequently also followed by “any hacks accepted”. Those who have tried have noticed that there is a hard block – SharePoint cannot be installed on an Office Web Apps machine and Office Web Apps cannot be installed on a SharePoint machine. This is purely by design and I will in this post show you why and why you shouldn’t try to hack it.

    Office Web Apps 2013 owns IIS on the machines where it is installed

    WAC WebsitesThe heading says it all – on the machine where Office Web Apps 2013 is installed the IIS (Internet Information Services) is very much controlled by WAC. WAC creates two Websites (see image to the right) and numerous Application Pools in IIS. In order to be in good condition, and avoid people fiddling with it, WAC will actually recreate the Websites and Application Pools whenever it boots or the WAC service is restarted. One more time – WAC removes the Websites and Application Pools and creates new ones every time the machine is booted or the WAC service is restarted (Restart-Service WACSM).

    The recreation of the Application Pools also prohibits any hacks to change the accounts of the Application Pools for Office Web Apps – something you never ever should do, it’s not supported and it is a security risk.

    WAC Websites

    The HTTP80 Website is the one that is used for all the WAC stuff (viewing, editing etc). Depending on your configuration that one is configured to listen on port 80 or 443 – for all IP addresses on the box. The other website, HTTP809, is the administration website using port 809 and 810 to synchronize settings within the farm. As you can see the HTTP80 Website will very much likely collide with a SharePoint Web Application (and any other Website for that matter). As you (might) know with SharePoint 2013, Apps and Host Named Site Collections we want a Web Application, without host header listening on port 80 or 443. There’s a collision right there. If we managed to get SharePoint installed on the WAC machine and try to fool WAC to use a host header, that would just be reset for every reboot or restart of the WAC service and our IIS Website would be removed for the SharePoint Web Application.

    What if I add another Website/Web Application and uses host headers?

    So you think you are smart now! What if you added a SharePoint Web Application, without host headers, and then go in and modify the bindings in IIS. Could work in a development environment, but never a good approach in production! Unfortunately this dog won’t hunt either. When you restart the WAC service it will actually not only remove the WAC Websites but also any IIS Website listening on port 80 or 443. Try it – just add a Website on port 80 in IIS, host header or no host headers, dedicated IP or not etc and restart the WACSM service – they will be removed. The only Websites that will remain in IIS are the ones created on ports other than 80, 443, 809 or 810.


    I hope that this little blog post helped you explain why you cannot have both Office Web Apps 2013 and SharePoint 2013 or any other IIS application on the same machine. There’s no hack and there should not be one. If you ever get asked that question again – just send them here.

  • SharePoint 2013, Office Web Apps 2013 and Excel files with Data Connections and Secure Store

    Tags: SharePoint 2013, Office Web Apps, WOPI


    This is a follow-up post on the SharePoint 2013, Office Web Apps 2013 and Excel files with Data Connections post that I previously wrote. That post talked about how you needed to do, so called, WOPI Suppressions if you had Excel files with Data Connections and had those data connections configured to use the authenticated users account. The WOPI Suppression made sure that the rendering of the Excel book was done by Excel Services in SharePoint 2013 rather than with Office Web Apps 2013.

    But if you have Excel documents with external data and do not rely on delegating the account (and don’t do the Negotiate, SPN and delegate dance), but instead like to store the credentials to the data in the connection string (not recommended) or like to take advantage of the Secure Store in SharePoint 2013 – then you actually have the option to not do any WOPI Suppressions. Let’s take a look on how you can get this to work: an Excel sheet with an external data connection using Secure Store to store credentials and then using Office Web Apps 2013 to refresh the data.

    Configuring the Secure Store

    Configuring a Secure Store ApplicationFirst of all we need to have the Secure Store Service Application up and running in our SharePoint farm. Once that is done and you have generated the encryption key, we need to add a new Target Application. To create the Target Application use the New button in the Ribbon. This will take you to a wizard. First of all we need to give the Target Application an ID, this is what we later use to reference this application from Excel (and other sources). Also give it a descriptive name as well as a contact. Then we have to choose what type of Target Application Type to use. Use Individual or Group, where Group is preferred from a management perspective. If you choose Individual you have to set the credentials for each user individually and for Group you have one set of credentials per application.

    On the next wizard page you set up the “fields” for the application. By default it assumes that it is Windows credentials that we would like to store, if that is the case you only need to click Next. Otherwise, if you’re using for instance SQL credentials, you have to set up two new fields using the User Name and Password type of fields. On the final page you give permissions to the Target Application itself and if it is a Group application then you also configure what users/groups that are mapped to the credentials.

    When the application is configured we need to set the credentials for it. For a Group Application you use Central Administration or PowerShell to set the credentials to be used by the group of users. For Individual Applications you need to set the credentials for each and every user through Central Admin or create some custom Web Part or similar that the user can use to fill in it’s credentials. Fortunately most of the plumbing is already done for this. You can use the Layouts page called securestoresetcredentials.aspx to allow the user to set their credentials. This is how it is used:


    You have to pass the TargetAppId as an argument and set the value to the Application ID of the application. Good to know here is that if you don’t use SSL/TLS (HTTPS) on you SharePoint sites you will get messages that will annoy your users, since this data will be sent in clear text. Just another reason to do HTTPS :-)

    By now we should be all set to continue to the next step.

    Create the Excel book with the Data Connection

    Excel Data Connection propertiesNow it is time to create our Excel book. To do this we just add a data connection as normal but in the connection wizard we click on the Excel Services: Authentication button and then choose to use a stored account. In the stored account input box we have to enter the Secure Store Target Application ID, the one we created in the Secure Store Service Application above. Everything else is precisely as normal.

    Now this workbook is ready to be uploaded to a document library in SharePoint. Good thing here is that now you don’t have to do anything more – no SPN’s, no nothing!

    Refresh data using Office Web Apps 2013

    So, let’s see if this works with Office Web Apps 2013! If you fiddled with the WOPI Suppressions as in my previous blog post, make sure to remove them so we have WAC rendering the Excel Sheet instead of Excel Services (this will work in Excel Services as well, but that is not the purpose of this post).

    Click on the document so that it renders in the browser, make sure to update some data in the external data source so that you can see that the data is actually refreshed, then use Data > Reload All Data Connections to update the sheet. Everything should work fine here, your data should be refreshed.

    So, there it is you can actually use Office Web Apps 2013 to render and refresh external data – only thing is that you can’t use any delegation features.


    Didn’t it work? Of course things can go wrong. But a correctly configured environment should work immediately. Here are some of the common errors that you can get:

    External Excel data connections disabled in Office Web Apps

    Your admins (or you) might have turned of the Excel external data. You can check this by running the following command on a WAC machine:


    If it returns false, then you have turned it off. By default when configuring a new farm it is set to true. If set to false and you want to use external data then use the following command:

    Set-OfficeWebAppsFarm -ExcelAllowExternalData

    Note that it can take a couple of minutes before changes like this actually is propagated in the WAC farm.

    If this is your problem then you’re getting an error like this:

    “The trusted location where the workbook is stored does not allow external data connections.”

    The trusted location where the workbook is stored does not allow external data connections

    You’re running SharePoint over HTTP!!!

    The most common problem is that your SharePoint is still using HTTP and not HTTPS (when will you ever learn!). If that is the case you will get an error like follows:

    “An error occurred while accessing application id XXX from Secure Store Service.”

    An error occurred while accessing application id XXX from Secure Store Service.

    This is perfectly normal and good! Since the SharePoint farm is accessible through HTTP this also means that Office Web Apps Server will try to retrieve the credentials over HTTP – in clear text, and you don’t want that.

    But if you are running a development environment that uses HTTP it could be all right to work around this. Or you might be running IPSec (fat chance…) then it also ok to allow this. Otherwise I do recommend you to change your SharePoint content web application to use HTTPS or don’t just use the Secure Store and WAC.

    Anyhow, this is how you configure WAC to allow retrieval of credentials over HTTP:

    Set-OfficeWebAppsFarm –AllowHttpSecureStoreConnections

    Once this command is executed, wait a minute, reload the workbook and you’re golden.

    No credentials configured

    Another common problem, common when using Individual Secure Store applications, is that the application does not have any credentials set. The error you will see then is the following:

    “An error occurred during an attempt to establish a connection to the external data source.”

    An error occurred during an attempt to establish a connection to the external data source

    To fix this you have to set the Group credentials, if it is a Group application type, or make sure that all users set their individual credentials.


    You have now seen that Office Web Apps 2013 can actually render external data, including refreshing it, using the SharePoint 2013 Secure Store service. Just be careful with the security issues I highlighted with SSL/TLS/HTTPS. All this will also work with plain ol’ Excel Services if you need to combine it with delegation.

  • Office Web Apps Server 2013 - machines are always reported as Unhealthy

    Tags: Office Web Apps

    As you might have noticed I have somewhat fallen in love with Office Web Apps 2013, or WAC as we say now that we’ve gotten this close to each other. It’s an amazingly well written server product with the good side benefit that it is also very usable for the end-users. Even though me and WAC has been hanging around for a while and by now know each other pretty well, WAC has constantly been reporting that it is Unhealthy. And from what I’ve seen, heard and experienced in the field I am not alone…

    Office Web Apps 2013 Health Reporting

    Office Web Apps 2013 has a really well written reporting mechanism that constantly monitors and reports issues with your WAC farm and its machines. You can at any time see the Health status of your machines by running the following Windows PowerShell command:


    If you have installed and configured the farm according to the interwebs and/or official sources it is most likely that all your servers are reporting Unhealthy even though your WAC farm is running fine, from the end-user perspective.

    Unhealthy WAC machines

    The health reporting mechanism in Office Web Apps consists of a number of Watchdog processes (FarmStateManagerWatchdog.exe, ImagingWatchdog.exe etc). These processes regularly check for issues with the different WAC services. For instance it makes sure all the servers and service endpoints are responding, it checks if the proofing tools works by actually testing the service with a correctly spelled word and an incorrectly spelled word and so on. If any of these watchdog process reports an error the machine is marked as Unhealthy. (Note: It will check all the reports from the last 10 minutes, so it is a slight delay in this status).

    You can see the Health reports in either the log files (SharePoint ULS Trace Log style) in your log directory on the WAC machines, but you might find it easier (and faster) to look in the Event Viewer of the machine. You will find the logs under Applications and Service Logs > Microsoft Office Web Apps.

    WAC Event Log entries

    In this log you will clearly see all the errors and be able to solve them, well at least most of them can be fixed by reading (and understanding) the log entry.

    Two common reasons for Unhealthy machines

    As I said, most WAC farms I’ve seen are reporting all machines as Unhealthy and I’ve found two major reasons for this. One is related to certificates and the second is related to Windows Server 2012/IIS8 and WCF.

    Correct WAC Farm certificate

    If you have been following the SharePoint 2013 space recently you should be pretty aware of that you should protect your server communication with SSL. Especially Office Web Apps 2013, which sends the AuthN token in clear text over the wire. So you create a certificate for your WAC farm load balanced DNS address, for instance, install it on the WAC machines, set up the farm and everything looks fine. But all the machines are reporting that they are Unhealthy. If you take a closer look at the WAC logs you will see exceptions like this: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

    SSL errors

    It’s not that strange actually. In order to test the endpoints of the different machines the watchdog processes cannot call the load balanced DNS entry ( but instead has to call the individual machines, for instance – and the certificate is not valid for that DNS entry.

    In order to resolve this issue for the farm you have to create a new SAN certificamyte (or optionally a wildcard) containing the name of all the machines and the load balanced DNS entry.

    New SAN certificate

    If you’re creating a new farm just proceed as normal with a certificate like this. If you have an already existing farm and need to update the certificate you just install the certificate on all the machines (before doing anything else) and then use the following PowerShell command to configure the farm to use the new certificate, on one of the WAC machines. Note that you need to restart all the servers in the farm once you have changed the certificate.

    Set-OfficeWebAppsFarm -CertificateName ""

    Once the machines are restarted you can go back to the logs and see if it now reports any issues and if everything is fine your machines should soon (it takes a couple of minutes) start reporting that they are Healthy.

    After this you also need to update the WOPI Proof Key of your SharePoint farm(s), to avoid security errors when using Office Web Apps in SharePoint. This can be done either by removing all WOPI bindings and re-add them or by running the following command:


    WCF .svc endpoints not working on IIS8

    The second thing that I’ve seen is that (once you fix the certificate per above) the logs contains error messages that says it cannot access the Participant.svc file: BroadcastServicesWatchdog_Wfe reported status for BroadcastServices_Host in category '3'. Reported status: Contacting Participant.svc failed with an exception: The remote server returned an error: (404) Not Found. There are other similar error messages. This is a bit strange, if you look in the IIS for that specific for this file it is clearly there but if you try to browse to it you get a 404. Here’s a good way to test if you’re suffering from this issue without reading any logs:

    Tip: this command and/or URL is a very good way to use in your monitoring software or load balancer to check if the WAC farm/machine is up and running.

    If you receive a HTTP status equal to 200 then you’re golden and can quit reading this section but if you get an exception and specifically a 404 you’re suffering from this exact issue.

    When you install/configure IIS8 on Windows Server 2012 using instructions from the internet or TechNet and trying to do a “minimal” installation with as little Server features installed as possible you are most likely not installing the HTTP Activation for .NET Framework 4.5 WCF Services.

    Forgot the .NET WCF HTTP Activation?

    In order for IIS to understand .svc files, and not use the Static file handler, you need to install this Feature on your WAC machines. It can be done using the Add Roles and Features Wizard (as shown above) or using the following PowerShell command. Note that it will at the same time install two other dependent features.

    Add-WindowsFeature NET-WCF-HTTP-Activation45

    If you’re installing a WAC machine from scratch your PowerShell command should look like follows (on Windows Server 2012):

    Import-Module ServerManager
    # Required Features
    Add-WindowsFeature NET-Framework-45-Core,NET-Framework-45-ASPNET,`
        Web-ISAPI-Filter,Web-Includes,InkAndHandwritingServices, NET-WCF-HTTP-Activation45
    # Recommended Features
    Add-WindowsFeature Web-Stat-Compression,Web-Dyn-Compression

    Once the feature is installed, there is no need for any server restart, you should see that your machines are reported as Healthy. Remember it can take up to 10 minutes. You can sometimes speed up the health reporting a bit by restarting the WAC Service:

    Restart-Service WACSM

    If they are no reported as Healthy then you have another issue. Check the logs again, fix it, report to me what you did and why and I’ll update this post.

    Healthy WAC machines

    Another note, you might not see the same status on all WAC machines when you inspect the health status for each machine. WAC machines are not constantly talking to each other, it may take a while before the synchronize. You can always log in to each and every WAC machine and run the following cmdlet to get the actual value of that specific machine:


    Repairing an Office Web Apps Farm

    There is a PowerShell cmdlet in Office Web Apps 2013 that is called Repair-OfficeWebAppsFarm. This command is sounding way better than it actually is. It will not repair anything, it will remove all Unhealthy servers, and nothing more. So unless you have fixed the issues mentioned above, you will have no WAC machines after running that cmdlet. Just a tip…


    Having an Healthy Office Web Apps Server 2013 farm is important. You should constantly monitor the Health status of each and every Office Web Apps Server machine, and if found Unhealthy fix it. Most likely you don’t have a valid certificate for your Office Web Apps Server 2013, one that contains the load balanced name and all the individual server names, and thus you will always have an Unhealthy farm. Get a new certificate for it, so that you can properly monitor the farm.

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...