Faulting SandboxHost with Office Web Apps

On our new Office Web Apps installation, I was seeing errors in the event viewer repeating every few minutes such as

Faulting application name: SandboxHost.exe, version: 15.0.4502.1000, time stamp:
0x512d262b
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17278, time stamp:
0x53eebf2e

I applied each of the April, May, June and July Cumulative updates, and each time hoped that they would solve the problem. They didn’t.

The key here was taking a closer look at the ULS logs, which have additional detail. This log can be found (default) at C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS

I found a corresponding entry which provided the hint to the real problem

Failed to launch sandbox process, SE_ASSIGNPRIMARYTOKEN_NAME
and SE_INCREASE_QUOTA_NAME privileges are required

This error is typically seen in Sharepoint installations, but the root cause is the same. The service account which is running doesn’t have the necessary permissions.

Office Web Apps uses the LocalSystem account by default. I had changed this to a specialized service account which had permissions into Sharepoint Content databases, in order to isolate a different problem related to Web Apps not working on Sharepoint personal sites.

As a result, it didn’t have the required permissions.

Utilizing this article at Al’s Tech Tips, I made the appropriate changes to the Local Security Policy. Whereas his article talks about the service account running the Sharepoint User Code Host, the one we are concerned about with Office Web Apps Server is Office Web Apps (WACSM)

Office Web Apps Server Required SAN

I’m building out our WAC server, and although the server appeared to be working correctly, it was constantly in an unhealthy state.

This can be checked by issuing the command:

Get-OfficeWebAppsMachine

WAC1

I looked through several articles including the often referenced How to Get Office Web Apps Server 2013 to Report a Healthy Health Status and Office Web Apps Server 2013 – machines are always reported as Unhealthy. I’ve found that Wictor’s articles tend to have the level of detail that I prefer when trying to solve in the problem.

We were experiencing the exact issue that was reported with the Watchdog processes not establishing an SSL connection.

<HealthMessage>BroadcastServicesWatchdog_Wfe reported status for
BroadcastServices_Host in category '4'. Reported status: 
Contacting Present_2_0.asmx failed with an exception:
 Could not establish trust relationship for the SSL/TLS 
secure channel with authority 'machinename.internaldomain.tld'.</HealthMessage>

Initially, we had a certificate issued by GlobalSign. Even though it was trusted it still wouldn’t work. For troubleshooting, I switched to a certificate which was issued by our internal CA – one that I knew would work.

I issued the certificate with the CN=webapps.ourdomain.com and the SAN=machinename.internaldomain.com.

In the past, I’ve never repeated the CN as a SAN.

Both of the articles mentioned having the domain listed as a SAN, but they didn’t explicitly mention needing in both the CN and SAN.

I went ahead and reissued my internal cert, and repeated webapps.ourdomain.com as both a CN and SAN. Lo and behold, the errors with SSL stopped.

Upon further research about the necessity of having a domain name repeated in both the CN and SAN, I learned that its often repeated for best practice for compatibility.

Viktor Varga summarized it very nicely in this Stack Exchange question: SSL – How do Common Names (CN) and Subject Alternative Names (SAN) work together?

Is Excel Missing from Import and Export Data?

 

Recently, a user was trying to import some data from a Microsoft Excel file using the Import and Export Data wizard.  The dropdown choices did not Excel as an option, but they know they had used it in the past.

64bit

The reason for this is that they were running the 64-bit wizard. Since there is no 64-bit version of the Excel driver, it wasn’t on the list.

Running the 32-bit version provided the data sources they were expecting.

32-bit

In addition to Excel, the 32-bit version provides drivers for:

  1. Microsoft Access (Microsoft Access Database Edition)
  2. Microsoft Access (Microsoft Jet Database Engine)
  3. Microsoft Office 15.0 Access Database Engine OLE DB Provider
  4. Microsoft OLE DB Provider for Analysis Servers 11.0
  5. Microsoft OLE DB Provider for Oracle

In our case, we are running SQL 2012, but we’ve installed the SQL 2014 tools in order to use the latest SSMS.

By default the 64-bit SQL Server 2014 Import and Export Data is located at C:\Program Files\Microsoft SQL Server\120\DTS\Binn\DTSWizard.exe.

The 32-bit version can be found at C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTSWizard.exe