SharePoint 2010 : “The search service is not able to connect to the machine that hosts the administration component”

I came across this very annoying message when provisioning the SharePoint 2010 Search Service Application recently, and interestingly it occurred on two farms on the same network.  Both were brand new stand-ups a Test and a Production farm.  Both were two-server farms, a SharePoint and  a SQL Server database.  The message appears when you provision the Search Service Application and then navigate to the Search Service Administration page.  The full message is something like:

Crawl: The search service is not able to connect to the machine that hosts the administration component. 
Verify that the administration component c8519b74 status -<GUID> in search application Search Service 
Application is in a good state and try again."

There are numerous blogs relating to this  post but none of them helped me solved the situation.  So I decided to recreate one of the farms.  This is when I came across another problem initially when trying to create the farm in Powershell, I got the error:

“The given key was not present in the dictionary”

when I tried to create the Central Administration Database. When I used a different account the farm created perfectly OK.  I then tried to create some managed accounts.  Through the UI I got the same error again about the ‘the given key’, but with Powershell it was fine.  On Binging the problem I found the following forums thread:

and the solution suggested which I have seen on other blogs is as follows:

Try this:

  1. Open up “Active Directory Users and Computer”
  2. Select “Advanced features” from the “View” menu
  3. Right-click the relevant account(s) and select “Properties”
  4. Select the “Securities” Tab
  5. Scroll down and select “Authenticated users” in the “Group or user names:” field
  6. Allow “Read” permissions in the “Permissions for Account Operators” field just below
  7. Hit Ok

Sure enough this solved the issue of “The given key was not present in the dictionary”.  I then proceeded to build the rest of the farm, but I still got the original problem of the Search Service being unable to find the administration component.

Eventually I tracked this issue down to there being an installation of IIS 7.5 Express edition having been installed for whatever reason on the SharePoint Server.  Along with this came the .NET 4.0 Client Profile and Extended Profile.  Now I’m unsure exactly which component it was caused the issue, but uninstalling all of then definitely solved the problem on both farms.

So in summary, make sure that IIS 7.5 Express, .NET 4.0 Client Profile and Extended Profile are NOT present on your SharePoint Server when you install.

Hope this helps


Dave Mc



Kerberos Authentication Not Working

Well there could be a large number of reasons why your Kerberos Delegation may not appear to be working, but I’m just going to quickly cover one reason here and it’s to do with DNS names.  I had this issue today and it took me a while to drag it out of my memory, but I got there eventually.

If you have a single-part host header for your website such as http://myintranet then you MUST define two SPNs for your site if you want to run it under Kerberos.  So if your root fully qualified domain name (FQDN) is mydomain.local and your Application Pool account name for your Web Application which you want to run under Keberos is  mydomain\myapppoolaccount, then you must declare the following two SPNs:

setspn -S HTTP/myintranet mydomain\myapppoolaccount
setspn -S HTTP/myintranet.mydomain.local  mydomain\myapppoolaccount

The reason is you don’t have a ‘dot’ in your domain name, so Kerberos decides that the SPN is actually referring to a machine name, even though it isn’t, and sticks the DNS suffix on the end of the transited service, so if you don’t declare the FQDN SPN, Kerberos will fail.

Fell for this one today and cost me some time.  Once I declared the second FQDN SPN everything clicked in.


Dave Mc

Reporting Services Integrated Mode Error

I was getting pretty recently a problem with Reporting Services Integrated Mode with SharePoint 2010, it was this …

I’d set up SSRS to work with Kerberos Authentication in SharePoint 2010 Integrated Mode and it all seemed to be working perfectly in that reports rendered through SharePoint worked perfectly.  I then left it a while and came back to it and started getting “Cannot create a connection to data source” error.  Looking further my data sources were failing to connect with the error “Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.” Oh dear. Kerberos right?  Did some digging around and checking, nothing seemed to be wrong.

Then I logged onto the server hosting the Report Server and navigated to the Report Server URL directly, blow me, the report rendered correctly … hmmm.  Went back to my workstation logged onto the SharePoint site and opened the report in Integrated mode and blow me, report rendered fine.  Did an iisreset and restarted the Reporting Services service, back came the “Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.” error …

The problem?

It came down to the browser in the end. My SharePoint 2010 URL needed to be in the “Local Intranet” Zone.  Once I did this the issue dissappeared and the reports would always render correctly.  Reading around I found this article from 2006 which indicates that this is ‘the’ thing to do. Not too sure about that, certainly in a cross-domain issue it doesn’t seem to work, a combination of Basic Authentication and Trusted Zone seems to work in that particular case.  Anyhow, if you get seemingly temperamental behaviour of Kerberos Authentication with Reporting Services in that now it works, now it doesn’t, try switching your URL to be in the ‘Local intranet’ zone either locally or via Group Policy.

[Update : 14 Jul 2011 Looks like you also have to have the SSRS URL you use in the Trusted Sites Zone – thanks to Paul Lynch for this amendment]


Hope that helps


Dave Mc

Connecting to Analysis Services using Kerberos

Quite often at Ridgian we deploy Analysis Services as part of a BI Solution integrated with SharePoint. We now always use Reporting Services in Integrated Mode and as a result we always configure our farms to use kerberos as the Single Sign On (SSO) method.  If you do the normal configuration for Kerberos, (I put some references on how to do this here) there is one final littel step you might need to do if things are quite working and that is in your connection string to the Analysis Services Database make sure you add in the entry:
SSPI = Kerberos;
this should make things kick in.  It worked for us in Reporting Services and in Excel Services.  Good luck!
Dave Mc

SharePoint “Access Denied” to Read-Only Users

Had the bizaarist of errors last two days on SharePoint.  If a user was in a Read only SharePoint group they would receive a ‘Access Denied” message, not all that odd you might say, but in the end it came down to a single custom control (I did not write it …!) which was accessing the UserProfileManager.  So you’d think that maybe the user needed some permission relating to managing their own profiles?  None of that it came down to being able to Browse SharePoint libraries via SharePoint or WebDav, despite none of that stuff being needed, accessed or even referenced.

Set the relevant permission by creating a custom PermissionSet which was cloned from the Read Permissionset, added the above permission in and the Read Only users could then see the pages. Not quite ideal as some of the Site Actions become available.

Even more odd, the same behaviour was NOT present with the same code on the Test Rig … eh?


Dave Mc


Our good friend Dinis Cruz is it again with Security Training Galore! He’s going to be delivering a couple of great courses over the next couple of months:
The first one’s a course he’s doing with Ounce Labs on 12th and 13th in London at the Thistle Marble Arch. The course is entitled: Source Code Security Training, and covers topics such as Performing Source Code Reviews, Identifying Vulnerabilities in Code and Writing Exploits. This course is aimed at Security Consultants and Senior Developers and full details are at, and it looks pretty good!
The second one is the course we’re (that is NxtGenUG) running with Dinis on 17/18th July at Leamington Spa and is entitled Security Training For ASP.NET Developers, the details are at . This course is similar to the successful one we ran in March, but with more of an accent on Code Scanning. We had some great feedback from the attendees, and a review of the course by one of them, Andy Jacks is at


We’ve just released a stonking podcast with Security Consultant Extraordinaire! Dinis Cruz who talks about OWASP and the threats we’re facing today and perhaps tomorrow.
More to follow!