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:

http://social.technet.microsoft.com/Forums/en-US/sharepointadminprevious/thread/5279f8da-2924-461f-8c35-5b81a2329927

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

Cheers

Dave Mc

 

Advertisements

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.

Cheers

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

Cheers

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!
 
Cheers
 
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?

Cheers

Dave Mc

DINIS CRUZ SECURITY TRAINING

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 http://www.ouncelabs.com/securityexperts/, 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 http://www.nxtgenug.net/Course.aspx?CourseID=4 . 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 http://www.nxtgenug.net/Article.aspx?ArticleID=166.
 
Cheers
 
Dave

NXTGENUG PODCAST WITH DINIS CRUZ

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!
 
Cheers
Dave