Sunday 12 April 2009

SharePoint Search - Access is Denied - Myths Dispelled

Over the last couple of days I've been setting up Microsoft Office SharePoint Server 2007 Search on my development box and encountering some issues. I have a fairly straightforward setup running MOSS 2007, SQL 2008 and Windows Server 2008. I have been trying to set up a simple search of my environment so that my Site Collections are crawled and indexed.

I went through and set up the environment based on the principal of least privileges. Despite following setup procedures to the letter when I ran the Search crawl to create the index I found the following error in the crawl logs:-
Access is denied. Verify that either the Default Content Access Account has
access to this repository, or add a crawl rule to crawl this repository
This led me on an internet search with a number of false pointers to 'recommended' solutions on forums and blogs. Because of this, I spent a fair amount of time implementing these 'solutions' before finding the true issue.

So here are some of the myths I came across that are not needed:-


Myth #1 - The Default Content Access Account needs to be granted rights to the Site Collections

I gave the content access account full control through the SharePoint UI permissions screens. This did not solve the problem and is not required.


Myth #2 - The Default Content Access Account needs to be granted read rights to the content database

I opened SQL Server Management Studio and went to Server - Security - Logins - Content Access Account then viewed the properties of this account. I selected 'User Mapping' to view the access the account had to the content databases. The content access account had no direct permissions on the content databases and just had public access inherited from its permissions to the database in general.

It was recommended by a number of forum posters that the content access account needs explicit read permissions to the database. One poster goes as far as saying I should grant db_datareader, db_datawriter and db_ddladmin roles to the account. I did this and I still experienced the 'Access is Denied' error.

I can safely say that, given the same setup, you should NOT need to manually add any extra role permissions to the SQL content database for the content access account.


Myth #3 - Turn on the WSS Search service and associate content databases with the search service

In the Central Administration - Operations - Services on Server screen it shows that 'Office SharePoint Server Search' is started but 'Windows SharePoint Services Search' is stopped. At first I wondered if the MOSS Search had a dependancy on the WSS Search. So, as described in a blog post, I started the Windows SharePoint Services Search. I then went in to the Central Administration - Application Management - Content Databases screen. I clicked on the content database and associated the database with the WSS Search Service that I just started.

After this, I reran the crawl, but once again it failed with the 'Access is Denied' error.

There is NO dependancy between the 'Office SharePoint Server Search' and 'Windows SharePoint Services Search'. Also, you DON'T need to associate the 'Office SharePoint Server Search' service with the content databases in the Central Administration - Application Management - Content Databases screen.


Myth #4 - The Content Access Account needs to be the same account as the account running the Office SharePoint Server Search service

One blog post I found told me that the content access account must be the same as the account used to run the MOSS Search service. I tried changing the content access account to the account running the MOSS Search service. Once again, 'Access is Denied'.

There is NO need for the Content Access Account to be the same account as the MOSS Search service account.


So, with all those myths busted, what was the solution for the 'Access is Denied' error when crawling content databases?

In Windows Server 2003 SP1 a security hole was plugged. This stopped you accessing content on the local machine from the local machine using a host name thats mapped to the loopback IP address (127.0.0.1). As the indexer runs on the local machine in a development environment and crawls the content which is also hosted on the local machine access is blocked.

To get around the issue we can make an addition to the registry (read as: be careful!). This allows us to add exceptions to the rule or turn the rule off. We really don't want to turn off this rule as it is there for a good reason. So we want to apply Method #1 from this Microsoft knowledge base article on the subject:-

http://support.microsoft.com/kb/896861

As a word of warning though, I stumbled across a small issue when applying this. My web application's host name is intranet (so accessed using http://intranet/). So I added 'intranet' to the registry key, but I was still receiving the 'Access is Denied' error. I then realised that this was because 'intranet' was not the fully qualified domain name. I opened a command prompt and ran an nslookup on intranet which showed that the FQDN for this entry was intranet.domainName.local. Once I entered this in to the registry key, hey presto, no more 'Access is Denied'! Hurray!!! :-)

Special Mention: Many thanks to Andrew Woodward of http://www.21apps.com/ for his help!

1 comment: