April 2009 - Posts

Service Pack 2 was released today (as I am guessing the whole world knows by now). Instead of making that profound announcement I would recommend you check out this post on the SharePoint Team blog for the official announcement. I will spare you the crazy details other than you should install it. J

Just like when the last updates came out I figured I would write a quick guide on the steps I am taking to install. Something to ponder before you get started. When was the last time you did a backup? Knock on wood as you answer.

  1. Start time 11:11 PM
  2. I am checking Windows Update for the latest patches. Looks like SQL Server 2008 SP1, IE8, and a random other Office update is waiting to install. I think I will let them sit for another evening; I have to get up early in the morning.
  3. This environment is a single box with both MOSS Enterprise and SQL Server 2008. MOSS is currently running the February cumulative updates build 12.0.0.6341.
  4. Downloading WSS SP2. 32.9 MB in 29 seconds. Make sure you download the 32bit or 64bit version you need. Both are available from the linked page.
  5. Downloading MOSS SP2. 270 MB in 3 minutes 54 seconds. Make sure you download the 32bit or 64bit version you need. Both are available from the linked page.
  6. Launched the WSS SP2 EXE I just downloaded.
  7. Agreed to the license terms and clicked Continue
  8. Started 11:22 PM. Ended 11:24 PM.
  9. When configuration wizard opens click Cancel and Yes at the warning. We will run config wizard after the MOSS update is installed also.
  10. Launched the MOSS SP2 EXE I just downloaded
  11. Agreed to the license terms and clicked Continue
  12. Started 11:25 PM. Ended 11:36 PM.
  13. Configuration Wizard opens automatically when the update finished installing.
  14. Click Next at the welcome screen
  15. Click Yes to stopping IIS, SharePoint Admin Service, and SharePoint Timer Service
  16. Click Next at the completing screen
  17. You will get a popup warning that you need to install the updates on all servers in your farm before continuing. Be sure to do that if you have multiple servers.
  18. Click OK.
  19. Start at 11:38 PM. About 3 GB of content in this farm. End at 11:48 PM.
  20. Click Finish
  21. Looks like I am left with build 12.0.0.6421

Remember these are the steps I took on my server. They are put here to give you basic guidance, if you feel you want to read about applying updates in excruationing details then check out these links from the Team blog.

Deploy software updates for Windows SharePoint Services 3.0
http://technet.microsoft.com/en-us/library/cc288269.aspx
Deploy software updates for Office SharePoint Server 2007
http://technet.microsoft.com/en-us/library/cc263467.aspx

OK so a question for you. Do you like these update install guides with so many details or would you prefer I leave out everything and just make it quick. You really don't care about my Windows updates or how long it takes to install?

Shane SharePoint Consulting

Posted by Shane | 15 comment(s)
Filed under: , ,

Had a client today (last week now) who broke search all the way. And in their attempts to straighten it out they changed some pieces that weren't broken. Then while they were in the process of trying to put it all back together I called and said let me at it so they just stopped. Needless to say I picked up the farm in an odd state or more exactly Search was dead.

So the first step always when Search is broke is to go to the SSP Admin and check out things.

  1. Open the SSP Administration page
  2. Click on Search Administration and see what it has to say. (if you don't see Search Administration this means you have not installed the infrastructure update. I would highly recommend at a minimum you have that installed. Get the latest update install guide here)

When I opened the page I saw a Crawl status of Error. That is about worthless.

That is pretty much as generic as they come. You get the same Error when the server is on fire as you do when there is small hiccup. So a much better thing to do is:

  1. Go back to the SSP administration page
  2. Click on Search Settings (which is what we used pre infrastructure update)

This page does a much better job of giving you tangible errors. Here is what I got:

 

Error: An indexer is not assigned to the Shared Services Provider 'SharedServices1'.

Link to: Configure an indexer and a search database for this Shared Services Provider

Well that is fixable but how did they end up like this? They stopped the Indexing service in the farm by:

  1. Go to Central Admin
  2. Click on Operations
  3. Click Services on Server
  4. They choose their Index server
  5. Then clicked Stop to the right of Office SharePoint Search Service

This doesn't just stop the service. This actually removes the service completely. This also removes the Index server from any SSP configured to use it. Now if you did want to just start and stop the service there is a way to do this:

  1. Open a command prompt
  2. Type net stop osearch and press enter
  3. Type net start osearch and press enter

This will cycle the search service. Usually the only time you need to do something like this is after installing a new ifilter but sometimes it makes you feel better to give it a shot and see if that helps your problem. I do it more often than I should just for that reason.

Back to the task at hand clearing up that error! I double checked and they had already reconfigured the Office SharePoint Search Service on the Index server so all I need to do is go back to the Index server and re-associate the indexer.

  1. From Central Administration click on Shared Services Administration from the left hand side of the page.
  2. Hover over the SSP name, click the drop down arrow and click Edit properties

  1. Scroll to the bottom of the page and select your Index server from the Index Server dropdown. If you see No Indexers in red you need to go back to your Services on Server and make sure you have the Office SharePoint Search service started and configured for the Index role.
  2. Confirm that you have the correct index location. Usually the C: drive is less than ideal.
  3. Click Ok

The SSP is now configured with an Indexer. Let's go make sure Search is happy.

  1. Now click on the Shared Services Provider name to open the SSP admin site.
  2. Click Search Settings

Don't be surprised if you get this error:

Error: The search service is currently offline. Visit the Services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress.

Typically this is because the wheels of Search can move slowly. I have seen this error come up for 10 minutes or so in some farms. What Search is really telling you is it is busy getting the index and the database ready to go so you can start indexing. Be patient grass hopper. At the client this was gone after about 2 minutes.

Once I was able to get to a happy Search Settings page I went ahead and reset the Index back to zero. Not always necessary but they had 33,000 items in the index and 140,000 or errors. I thought better to start everything back to 0.

In order to reset the Index.

  1. From the SSP admin screen click Search Administration
  2. From the left hand column (quick launch for those who know terminology) click Reset all crawled content
  3. Select Deactivate search alerts during reset
  4. Click Reset now

Now you have a completely blank index. Why did we choose to deactivate search alerts? This is to keep from annoying the users. We don't want them all to get new alerts when new content is discovered when we recrawl in a minute. Once the index is back to normal we will re enable the alerts for them.

Ok so now the next step should be doing a full crawl. So let's try that.

  1. From your SSP Administration home page click Search Administration
  2. From the Quick Launch bar (on the left) click Content Sources
  3. Hover over your Content Source, click the drop down arrow, and select full crawl
  4. Now go back to the home page of Search Administration and watch to see if the crawl is running

Unfortunately in our case after about a minute I was left with 0 items in the index and 3 errors. After checking the errors I got Access Denied. L If you haven't done any monkeying around with changing your default content access account then it should have been automatically granted full access to your content source. You can confirm this by checking your Policy for web application in Central administration. If you forget how to do that check this blog post for a reminder. http://msmvps.com/blogs/shane/archive/2007/01/21/become-administrator-of-the-entire-web-application.aspx

If that checked out ok then the next thing I would check is to make sure your web application is set to integrated authentication and not basic authentication. MOSS will not pass basic authentication by default. So if you changed your web application from integrated to basic, so people users don't have to enter their domain for example, then you need to setup a custom crawl rule to pass basic authentication.

  1. From your SSP Administration home page click Search Administration
  2. In the Quick Launch bar click Crawl rules
  3. Click New Crawl Rule
  4. For path enter your web app URL ex: http://portal.company.com/*
  5. For Crawl Configuration select Include all items in this path
  6. For Specify Authentication select Specify a different content access account
  7. Now fill in username and password remembering your domain\username form. I would recommended using your normal search account as you know it already has read access to the content.
  8. Key step de-select the box to Do not allow Basic Authentication
  9. Now do a full crawl. Also, remember if you have multiple web apps you may need more than one of this rules.

For the client this was not this issue but it is an important and often over looked troubleshooting step so I thought throwing it in here would be helpful.

The next thing I take a look at is the dreaded loopback fix. I showed this one to Todd Klindt one time and he wrote a nice post on the issue and a like to the KB for fixing it. http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=107 It is all but a guarantee these days if you have the WFE and Index role on the same server you are going to need to do this. A lot of farms have ran fine for a long time and just recently they have started requiring it. Must have been a Windows update that is causing this to be needed more but I haven't identified it. Another note even though this fix is only listed as applying to Windows 2003 it also applies to Windows 2008, had a different client need it last week. J

Loopback fix in and the server rebooted I tried another Full crawl. Success! Seems this was the root of their issues but as is often the case that happens to all of us, trying to fix it only made the problem worse. LOL

Don't forget to re-enable those search alerts.

  1. From your SSP administration home page click Search Administration
  2. In the System Status section in the center of the page click Search alerts status Enable

Another troubleshooting step I skipped, because the client had already done it was resetting search permissions. Read the blog post John Ross did summing up the steps to get permissions back on the up and up for the Search Service. http://www.sharepoint911.com/blogs/john/archive/2009/04/03/change-to-group-policy-broke-sharepoint-search-–-thanks-conficker-scare.aspx

Something I learned that was new

I am guessing since I didn't realize this is an option (or more probably I knew and forgot) you probably didn't either. So run stsadm –o help like below and take a look at the output.

Use Stsadm.exe from the 12 hive (c:\program files\common files\Microsoft shared\web server extensions\12\). Actually 12\bin to be exact.

C:\ >stsadm -help osearch

stsadm -o osearch

[-action <list|start|stop|showdefaultsspadmin>] required parameters for 'start' (if not already set): role, farmcontactemail, service credentials

[-f (suppress prompts)]

[-role <Index|Query|IndexQuery>]

[-farmcontactemail <email>]

[-farmperformancelevel <Reduced|PartlyReduced|Maximum>]

[-farmserviceaccount <DOMAIN\name> (service credentials)]

[-farmservicepassword <password>]

[-defaultindexlocation <directory>]

[-propagationlocation <directory>]

[-cleansearchdatabase <true|false>]

[-ssp <ssp name>] required parameter for 'cleansearchdatabase'

So really very similar to the options you have available to you from the GUI. The reason I used it was one of the Query servers was stuck in the starting state. In the GUI there is no stop until the service gets too started, not even a reboot will help. With stsadm you can do a stop and get out of the perpetual starting. J A very helpful trick.

If you are still fighting with Search here are couple of other Search troubleshooting things I wrote a while back

Hope you enjoy what feels like a small book

 

Shane – SharePoint Consulting

Posted by Shane | 1 comment(s)