Skip to content

Embedded Spreadsheets not displaying

I recently had an issue with Excel spreadsheets that were embedded in a page not displaying. Instead of the spreadsheet, users saw an error box with the message “Unable to load the requested workbook.” Users could open spreadsheets in the app, but not in the browser (we have Office Web Applications configured).

There are a lot of reasons why this is happening. Usually Excel Calculations Services is not running. Recycling the application pools in IIS can often fix this issue. But not this time, not for me.

Digging deeper, I went to the ULS logs. I found an interesting error: “#960013: Antivirus scanner timed out.” associated with the page the spreadsheet was hosted on.

We run Forefront Protection for SharePoint on our farm, so I opened up the console. I found the following error: “The SharePoint service is running but the Forefront VSAPI Library is not registered.” Forefront runs on each server on the farm, and this error was only showing up one of the farm servers. Of course it was on the application server, where Excel Calculations Services were running.

Some Googling led me to this: , but the steps listed there to restart the service did not fix the issue. Finally, a reboot of the server got Forefront into a good state, and spreadsheets started working again. Why didn’t I try that first?


SharePoint 2010 Administration Service won’t start

This one had me banging my head against the wall for a while. On our two web front-ends, the SharePoint 2010 Administration Service would not start. The only difference between the WFE’s and the App servers where the service was working, was some firewall rules.

I could not find useful information in the Windows Event logs. A couple errors, the most prominent bein “Error 1053: The service did not respond to the start or control request in a timely fashion” is not very helpful. I also found some Event ID 4656 audit failure errors in the security log that coincide with when I try to start the service. Lots of advice on turning off logging for this particular event, but nothing I found that told me what kind of problem would cause that error.

Finally, I found this blog which was short on details: , but it turned out to be the cause of my pain.

Microsoft patch kb2677070 is an automatic updater of revoked security certificates. It will let Windows Server go out to the internet, get an updated list of revoked certificates, and make security decisions based on that. But if your server is firewalled away in a DMZ and does not have unfettered internet access, this call to the find the updated revocation list will fail. When it does, the SharePoint 2010 Administration service will not start.

To fix this problem, you can uninstall the patch, or disable the network check in group policy. Some have reported that uninstalling the patch does not fix the problem. I couldn’t find the patch in add/remove programs, and I wonder if there isn’t a newer patch that might include this “functionality”. Anyway, disabling the network check fixed the issue for me. Here’s how to do it:

  • Open Group Policy Editor. From start->search box, type in gpedit.msc and hit return.
  • Navigate to Computer Configuration->Windows Settings->Public Key Policies-> Certificate Path Validation Settings.
  • Click on the “Network Retrieval” tab.
  • Check the “Define these policy settings” and uncheck the “Automatically update certificates in the Microsoft Root Certificate Program”
  • Click OK

Now try to start your SharePoint 2010 Administration service.

What web front end am I seeing?

So we have two web front-ends with our SharePoint 2010 farm. Load balancing is not done through Windows NLB, but rather through an F5 BigIP, which is managed by a different group in our IT department. This presents some challenges for me as a SharePoint administrator. When I see issues with a SharePoint site, how can I quickly tell if it is isolated on a specific WFE? Normally, I’d have to contact the group that manages the load-balancer, have them remove one WFE from the pool, then wait for my session to expire, then test the site.

This is such a hassle that I came up with a quick and dirty way of telling which web front end I’m on. And it is so simple, any end user can tell at a glance and let me know over the phone.

I take a graphic that is on the front page of a site. You can use any image that is on your site. For 2010, I use the default site icon. A lot of companies will customize this image, but we use the default.

I save the image to my computer, then I open it up in a graphics editing program. I use GIMP, available for free at . You can use PhotoShop or even Paint, whatever works for you. Then I add a mark – one dot for WFE 1, and two dots for WFE2.


And then I copy the appropriate version of the graphic onto the corresponding WFE. The default location for this graphic is <14 Hive>\TEMPLATE\IMAGES\SITEICON.PNG . I replace the default file with the image with the dot. No IISReset is needed. When you go to your site, you can now quickly see if you are on WFE1 or WFE2.

Some of our site owners customize their sites and don’t display the SiteIcon image. But our root sites all display it. For SharePoint to work properly, the BigIP has to be session-aware. That means, when you initially connect to the SharePoint site, the load-balancer picks a WFE and starts your session with it. All subsequent traffic from your session is routed to the same WFE. Our load-balancer is configured with a 60 minute time-out for sessions. That means, once you start a session, all traffic will be routed to the same WFE, until 60 minutes of inactivity has occurred.

So once you view the main page and see the icon, you know what WFE you are on. You can then navigate to a site, and even if it doesn’t have an icon, you know you are on the same WFE.

Hey look, I’m on WFE2!

The next step, forcing traffic onto one WFE or the other, is more complicated, depending on your network and load-balance setup. That is a subject for another post sometime. But this trick can help you quickly identify which WFE you are seeing, and it has been immensely helpful to us in our troubleshooting.


Another SSL issue

But different SSL than the last post. Our problem was intermittent slow-loading pages. Pages would take 15 seconds to load, seemingly randomly. We narrowed it down to a single web front-end. The slow load would usually happen after you visited a page, didn’t touch it for a while, and then navigated away or refreshed it. Using Developer Dashboard, we could see that the delay was consistently occurring when a 3rd party application was loading a web part. The step was always the same, GetServiceSecurityToken. We worked with the 3rd party company, and they swore up and down that the problem wasn’t their software. The GetServiceSecurityToken is a default SharePoint call that their software used, and the problem was with SharePoint.
We had another web application hosting sites that did not run this third party application, and it too would have the issue. In this case, it was with SearchBoxEx.OnLoad, so it did look like this was an issue with SharePoint, not with the third party app.
We finally found the solution here: SharePoint 2010 uses SSL to encrypt intra-farm communication. It should work invisibly, but under the right conditions, it can cause problems, resulting in these 15 second timeouts. SharePoint has its own internal SSL root certificate and its own certificate stores, so you never see this intra-farm encryption unless you go looking for it. But if SharePoint can’t authenticate the SSL certificate it’s using, it will have these 15 second timeouts before loading the page. Under some circumstances, the page won’t load at all.
The fix is to export SharePoint’s SSL cert through PowerShell, then add it to the server’s Trusted Root Authentication Provider store through the MMC’s Certificate snap-in.
To do that, on any server in the farm, open up SharePoint 2010 Management Shell. Enter the following commands:
$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export(“Cert”) | Set-Content C:\SharePointRootAuthority.cer -Encoding byte

This will export SharePoint’s internal root certificate into the C:\ root directory. You can copy this file to all servers in the farm for importing. To import this certificate, open up MMC.
Start-> Run-> MMC-> Enter.
File-> Add/Remove Snap-in
Highlight the Certificates snap-in and click the add button. You will be prompted for which account to run this snap-in under – your user account, a service account, or the computer account. Select Computer Account, as you need this in the server’s store. That way, all accounts and services will use it.
Expand Certificates-> Trusted Root Certification Authorities.
Right-click “certificates-> All tasks-> Import.
Click the browse button and navigate to C:\SharePointRootAuthority.cer
Open-> Next-> Next-> Finish-> OK.
Refresh the view and you should see the SharePoint Root Authority certificate in the store.

Repeat this import for all servers in your farm. Do an IIS reset on all servers.
This fixed the problem for us (though initially, I ran the Certificates snap-in under the farm administrator account rather than the computer account, which resulted in a couple more days of troubleshooting). Pages stopped having the 15 second delay and everyone was happy.

SSL Certificates, Trusts, and SharePoint 2010

We were having a 3rd party migration tool fail at bringing over some web parts from our 2007 farm to our 2010 farm. Looking through the Windows Event Logs on the 2010 server, I found a number of these errors:

Source: SharePoint Foundation

Event ID: 8311

An operation failed because the following certificate has validation errors:\n\nSubject Name:, OU=IT, O=”Contoso”, L=Redmond, S=WA, C=US\nIssuer Name: CN=InternalCertAuthority, DC=Contoso, DC=com\nThumbprint: <biglongGUID>\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

The InternalCertAuthority certificate our company’s own self-signed certificate. I checked, and it is in the Trusted Root Certification Authorities store on all servers in our farm. You can verify that your cert is in the proper store by one of two methods.

In IE, click on Tools->Internet Options. Click on the Content tab and click the Certificates button. Click on the Trusted Root Certification Authorities tab and find your cert.

Alternately, you can use MMC. From the start button, enter mmc in the “Search programs and files” text box. In the MMC window, select File->Add/Remove Snap-in. Highlight Certificates in the left pane, click the Add > button in the middle and click OK. Select My user account and click Finish. Expand the navigation pane “Certificates – current user”->”Trusted Root Certification Authorities”->”Certificates” and find your cert.

If it is not there, you can import it. Get a copy of the certificate from your internal certificate server. It should be in the *.cer format.

Save that file somewhere and open up Central Administration. Go to Security->General Security->Manage Trust. You should see “local” in there, that is SharePoint’s own self-signed certificate. SharePoint uses this to encrypt traffic between servers in the farm. But now, you need to add your company’s self-signed root certificate here. Click the “New” button in the upper left. Give a friendly name to the certificate – “Contoso self-signed” or whatever. Click the Browse button and go to the location where you saved your copy of the certificate. Then click OK.

At this point, everything should be great. You should see your certificate listed on the “Trust Relationships” page.

But you may have gotten an error. Maybe after you clicked OK, you got a message that says “The Root Certificate that was just selected is invalid. This may be because the selected certificate requires a password and we do not support certificates that require a password. Please select another certificate.” How can that be? The cert doesn’t require a password! What is going on?

I’m not sure what is going on, but I know how to get around this error. You can create Trust Relationships through PowerShell, and it is pretty simple. Microsoft’s documentation is here: . For this, you need to save the certificate from your company’s certificate authority somewhere on a server in your farm. On that server, open SharePoint 2010 Management Shell. Type “New–SPTrustedRootAuthority -Name “FriendlyNameForTrust” -Certificate C:\<location of certificate>”

Now, if you go to the Trust Relationships page in CA, you should see the new trust. This fixed our issue with our migration tool and cleared up the errors in the event log.

SharePoint 2010 Service Applications – names and GUIDs

Man, they make some stuff so hard. This is absolutely crazy. You create application pools in Central Administrator. You can give them a nice friendly name, like so:

Then you can go to IIS and see the new application pool:

Oh, wait, which one of those is the new one? Wow, that is really useless. Now I have to open PowerShell.

If the image is too small, the PowerShell command is Get-SPServiceApplicationPool | Select Id,Name

The name/GUID issue was never an issue for me, until we were having an issue with Office Web Applications. I was trying to troubleshoot it, and finding this command ended up being a huge pain and a long digression onto Google.

To decipher similar information in MOSS 2007, check here:

Redirects for SharePoint 2010

Todd Klindt wrote the definitive article on SharePoint redirects. You can find it here:

While most of it still holds true, there are a couple things to watch for with SharePoint 2010. The concept is the same: a user enters a simple URL with a friendly name like and the browser goes to

Here’s how to make it happen:

Open up IIS Manager.

Highlight “Resource Pools” in the connections pane

In the Actions pane, select Add Application Pool…

Create an application pool

Select Classic from the Managed pipeline mode drop-down menu.

Now you have your application pool created. You can use this same application pool for all redirects. Todd Klindt recommends the separate app pool to avoid excess memory usage. I recommend it because the “Managed pipeline mode” can cause trouble if you have it set to something necessary for an actual SharePoint site.

Next, create a redirect site. Highlight Sites in the Connections pane, and then Add Web Site… in the Actions pane. I named all my sites something like “Redirect Foo,” so the names group all the redirects together in the Connections pane. Pick any folder for a physical path. We will change this really quickly, so no matter what you put in there, IIS won’t be using it. For the host name, enter the simple/easy URL that you want users to type into their browsers, the “” or whatever. Click OK.

Site Creation settings

Now, Redirect BigTime shows up in the Connections pane. Highlight it. Then select HTTP Redirect in the IIS section in the center pane. Enter the URL of the actual site, like and click the checkbox for” redirect all requests to exact destination.” Click “Apply” in the actions pane.

You of course have to add a DNS entry for your simple URL and point it at the IP address of your SharePoint server.

Now, give the URL a try. You might see something like this: HTTP Error 500.0 – Internal Server Error Calling LoadLibraryEX on ISAPI filter “C:\Program Files\Microsoft Forefront Protection for SharePoint\FSSPUsernameFilter.dll” failed.

500 error

Well, that’s not so good. Let’s go back into IIS Manager. Highlight the redirect site in the Connections pane and double-click on the “ISAPI filters” icon under IIS in the center pane. This will bring up something like this:

ISAPI Filter - delete everything here

Just delete everything in here. Highlight a choice and click “Remove” in the action pane. This is just a simple redirect. It needs no Forefront or ASP or .NET. Get rid of it all.

Now give the simple URL a try. It should redirect you to your real site with the annoyingly long URL. Success!