Some of you may have seen me tweet about how the simple threat of Conficker cause more problems than the actual virus itself for one client.  Here’s the full story:

I’ve been working with a client for the past weeks and logged in to their server the morning of April 1, 2009.  I went about what I had to do and then decided to take a peek at the Event Viewer on the server.  A few weeks back I did a clean install and the Event Viewer was clean as a whistle so I was pretty much expecting to see the same.  However, here’s what greeted me that morning:

Lots and lots of 6398 and 6482 errors.  There were some 7076 errors thrown into the mix as you can see.  If you’ve never had the pleasure of seeing the error messages up close here’s what they look like:

For the sake of search engines – the 6398 error message is: The Execute method of job definition Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob (ID 9f6421a3-0828-4a26-9def-977f6e5b959a) threw an exception

The 6482 error message is:  Application Server Administration job failed for service instance Microsoft.Office.Excel.Server.ExcelServerSharedWebServiceInstance (dfb065a4-e326-4619-bb9d-2aff38c9cae6).

Since these errors were related to search I opened up the Search Administration page in my SSP and say the crawl status was showing “Error.”  I’d never seen that before, so I shot over an IM to Shane Young and asked if he’d seen that.  He suggested opening up the Search Settings page which he said normally shows a more detailed message.  However, when I tried to open up Search Settings I got a 403 – Access Denied.

It didn’t take long to realize that this was all related to permissions.  I shot an email to my client asking them if they’d recently made any changes to their server and they confirmed that they had.  They recently made changes to a group policy that locked down the access for Administrators to prevent the Conficker virus from doing any damage.  Honestly, I don’t blame them for making the change – they really had no idea it would have any impact on SharePoint.  But alas, it did.

Everything I uncovered in my searching of the interwebs suggested to do two things:

1. Add the local group WSS_WPG to the c:\windows\tasks folder with Read and Write.
2. Reset the accounts used for WSS search

You might be asking yourself “Why the heck does SharePoint need access to c:\windows\tasks?”  The simple answer is that it needs to be able schedule tasks – without access certain tasks like searching won’t get scheduled and therefore won’t happen.  So I went to modify the permissions on the directory– however, I wasn’t able to modify the permissions on c:\windows\tasks despite my administrator permissions.  We first had to remove the group policy that was applied and reboot the server.  Then I was able to modify c:\windows\tasks. 

The next step was to reset the permissions for WSS search.  I opened Central Administration and went to Operations > Services on Server then clicked on Windows SharePoint Services Search and re-entered the credentials for the Service Account and Content Access account.  The problem was it didn’t fix the problem.  Thinking it must be something else, I asked Shane to take a peek and see what he could come up with. 

I’ll spare you all the details but here’s the important part of this post --- what I did was completely correct except for ONE very minor detail.  Changing the group policy modified the permissions on the server and more importantly some of the permissions SharePoint needed.  Removing the group policy didn’t completely undo all of the changes so the accounts needed to be reset.  Simply re-entering the same username and password like I did doesn’t help because SharePoint thinks “oh, that’s the same one I got – no big deal.  No need to make any changes.”  What Shane had me do was change the identity of the Search accounts to something else and then change it back.  What this does is force SharePoint to rewrite the permissions for the account.

After making the change the server was happy again and looked like this:

In summary – be very careful when applying group policies that restrict access to administrators because it might make SharePoint unhappy.  And in the event you run into a permissions issues and need to reset a password in SharePoint it is often best to change the username and password to something else before changing it back.

Hopefully this post will save someone a few hours :-)