So I got called up by a customer about that their search on a standalone machine has suddenly stopped working. No results appeared in the results page. So I asked them to check Central administration and the Shared Service Provider Search log and found the following error for what seemed to be one for each file that already existed in the index.

 

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)

My first thought was of course that something had changed with the Service Account used for crawling, something that got more obvious since they had almost the same error message in the Event View:

 

But when we looked at the Service Account everything seemed ok, the account had not been disabled or expired. Then I suddenly got another call from a customer that had the same problem and she also had another very strange problem since she could not access the SSP settings page. Central Administration worked but she got access denied on the SSP.

Two different environments with almost the same problem. This had to be with some updates on the server, right I was. Both machines had automatic Windows Updates and had therefore got an update that caused problems with use of fully qualified domain name (FQDN) when browsing a local site.

There is a solution for this and you find the Microsoft KB here: http://support.microsoft.com/default.aspx/kb/896861

So what have we learned? Well, first of all, never use automatic updates in production environment and always use a test, QA, staging or pre-production (whatever name you choose) to test all new changes. Things can fail even if it’s not a specific SharePoint update.