Search results for 'app:weblogs' matching tag 'How Do I'

Health Check - Happy New Year to you and your SharePoint servers!

Shane — Tue, 03 Jan 2012 06:00:00 GMT

Happy New Year. Hopefully you have recovered from all of the good times and/or you got some rest on the break.

I figured many of us have SharePoint 2010 deployments at this point that are mature. Which is awesome. But one thing I know about mature SharePoint farms is we often take them for granted. Below I am going to throw a couple of things at you to double check this week and make sure SharePoint is happy.

What is your build number?

You should be running at least service pack 1 at this point. Now if you are not I am not recommending blindly installing it on your production server. You should test it first. J But once you do let's get it on there. How do you check your build number? Todd has a great blog post here that will show you how to find your build number and then tell you what it means. He also has links to the different patches for download. Remember service packs are always good cumulative updates… you should only install them if you have a very specific reason and you have tested.

Check those health rules

We have all gotten used to the big read bar at the top of the page in Central Administration. We know that it is generally there because some of the rules can just never be made happy. But when was the last time you checked to see what problems it was reporting? Especially with some of the updates the rules have gotten better. So take a quick peek at the list today and see if there is anything you can remedy. No reason to have a broken farm.

Check your disk space

What the heck. I know when I was a full time systems guy I had scripts that checked drive space daily and reported back to me. But maybe you don't. Either way RDP into all of those servers and just make sure some rogue log or temp files aren't wasting a bunch of space. It will take you 5 minutes per server and might very well save you from having a bad day in the future.

How is SQL Server doing?

Whether you manage your SQL Server or you have a DBA who does it you need to ask the questions. This isn't a perfect list but off the top of my head I would ask:

How much free space do we have on the data drive? The log drive? The backup drives?
How long is that space going to last us at current growth rates?
When was the last time someone confirmed we can restore from the SQL backups?
Does SQL need any patches applied for general SQL Server health?
Anybody checked the SQL logs for errors?

Remember even though it is easy to say that isn't your job it is. If SQL Server isn't happy then SharePoint isn't happy.

What is your backup/restore plan?

I know you have one in theory but do you have one in actuality? When was the last time you did a practice restore? I will leave at this. You know if you have a bad feeling in your stomach right now or not.

Clearly this isn't an exhaustive list but you get the idea. Spend this slow week making sure that awesome server farm you built is still awesome. Next week you will start getting busy and will go back into firefighting mode. Don't make your next SharePoint touch point require a 4 alarm fire.

Shane

SharePoint Consulting

After SharePoint 2010 database attach upgrade alerts have the wrong URLs

Shane — Mon, 22 Aug 2011 05:00:00 GMT

Database attach upgrades seem to be the norm these days for customers upgrade from SharePoint 2007 to SharePoint 2010. I am assuming the reason for this is because they are very flexible and generally work pretty well. One of the flexible things about these type of upgrades is you can change your web application URL. Some customers are going from short URL to fully qualified (FQDN) like http://portal to http://portal.company.com. And some of our customers are making complete changes going from http://sharepoint.company.com to http://intranet.company.com. The nice thing about making these types of changes is for the most part a content database has no concept of the web application URL. If you go hunting through the database (which you should never do) you will see everything is relative. The site collections know their urls as / or /sites/sitecollection. That way changing the URL doesn't matter.

But then there are alerts. Alerts are hard coded to the web application URL that was used to create the alert. This is why if you have multiple URLs for you SharePoint site your alerts may be inconsistent. If your portal is setup so you can access it as http://portal or http://portal.contoso.com then whichever of those URLs you are browsing the site with when you click create alert will be the URL SharePoint sends out in the alerts. Kind of annoying for some people but it is what it is. The real problem comes if you switch URLs.

If you change your web applications URL (maybe during an upgrade but not necessarily) everything will continue to work great except for existing alerts. When you have an alert sent to you it will still have that original URL you used to create the alert even if that is no longer a valid URL. Boo!

Now if you do a Bing search of the internet you will find lots of people point to this TechNet resource http://technet.microsoft.com/en-us/library/cc508847.aspx which will prompt you to create a Windows PowerShell script to fix alerts. One small problem. The script only works to update the URL of alerts for the root site collection. In their script they confuse the web application URL and the site collection URL. To be fair I don't blame them. When you look at the configuration objects you will see it wants siteUrl and we have been taught that usually inside of SharePoint site = site collection. Unfortunately in this case siteUrl actual means web application URL.

In the beginning when we used their script to update http://portal/sites/old to http://portal/sites/new our alerts had the link as http://portal/sites/new/sites/new/list which has /sites/new twice.

So then I decided to look at things on my own. I created a new alert through the GUI and then used the following script:

Get-SPweb -site http://portal/sites/new -limit all | ForEach-Object {$_.alerts|foreach-object{write-host $_.user $_.properties["siteUrl"] $_.properties["dispformurl"]}}

This gave me a list of all the alerts for the site collection http://portal/sites/new and I saw the value for siteUrl was http://portal. Hooray!

So then I used this script to update just the alerts in that site collection:

Get-SPweb -site http://portal/sites/new -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://portal/sites/new";$_.update()}}

Success! But seemed silly to just fix the one site collection so then I wrote a better script that updates the entire web application:

get-spsite -limit all -WebApplication http://portal | get-spweb -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://portal";$_.update()}}

Now if you compare my script to theirs you will notice I don't bother with mobileUrl because no one I know uses it. Also, they rewrite some other properties. If you want to do the same you can piece together the two scripts to do it but for right now for my customers this is working.

Hope this helps

Shane

SharePoint Consulting and now SharePoint Training

Using PowerShell to export all solutions from your SharePoint 2010 farm and other fun

Shane — Thu, 05 May 2011 05:00:00 GMT

Yesterday my client presented a fun little challenge. They have one 2010 production farm they have been using for the last couple of months. On it they have about 25 WSPs that their developers have created. (Insert funny developer joke here. Probably something about a 1000 developers, a keyboard, and creating a Shakespeare novel.) They wanted to move to a new 2010 farm and they also wanted to provision an integration (aka QA or UAT) farm. When I asked for the WSPs they gave me a pile but they were not sure if those were the actual ones deployed in production. Ugh. So instead we decided to figure out if we could extract the actual WSPs from the running farm. Turns out you can, you just need to use my friend Windows PowerShell. J

After a little playing we came up with this to extract them all from the farm.

Extract all of the Solutions from your farm

(Get-SPFarm).Solutions | ForEach-Object{$var = (Get-Location).Path + "\" + $_.Name; $_.SolutionFile.SaveAs($var)}

Quickly let's see if we can break this down and explain the pieces.

Get-SPFarm does just that it gets your current farm. When I put it in the ( ) that returns the farm. Then I tack on .Solutions which returns all of the solutions in the farm. From there I pipe the solutions over to old faithful ForEach-Object. ForEach-Object says do everything within the { } to each solution passed from the pipe. Within the { } I use $var = to set the variable's value to Get-Location which returns the current location you are at in the file system. .Path returns that location. (Example output: c:\backupfolder) The + says continue to add to the $var variable. "\" adds a \ to the $var variable. Another + means keep adding to the variable. $_.Name says give me the name property of the current solution. So this ends up setting the value of $var to c:\backupfolder\mysolution.wsp assuming the solution filename was mysolution.wsp and we were running our PowerShell from the folder c:\backupfolder. Finally we have a ; which means we are all done with that line.

We follow up setting the variable with $_.SolutionFile.SaveAs($var). $_.SolutionFile is a property of the current solution. .SaveAs is a method for saving that file. That method needs to know what filename to save the solution to. We give it $var which is the variable we just created.

Boom! Just like that you have exported all of the solutions from your farm to a handy, dandy folder.

Import all of the Solution into another farm

Now because I am naturally lazy I said "I bet we can figure out how to script importing all of those to our farm." After a little playing turns out you can with the following PowerShell.

Get-ChildItem | ForEach-Object{Add-SPSolution -LiteralPath $_.Fullname}

So how does that work? Get-ChildItem returns all of the files in a folder so if you navigate to the folder you copied over all of the solutions to you return them all. For this example we will say we are in the folder c:\copiedfolder. We then pipe those files over to ForEach-Object so we can do everything within the { } to each object. Add-SPSolution is a SharePoint cmdlet for adding solutions to a farm. –LiteralPath is a required parameter where you need to provide the path to the solution to import. $_.Fullname returns the .fullname property of the object. So in this case it returns c:\copiedfolder\mysolution.wsp.

Oh yeah! Just like that all 25 of those solutions are added to our farm.

Deploy all of those Solutions

So we got this far without me having to type in a bunch of crap so surely we can automate this part also. <he he he> (Keep in mind when I explain the developer crap below it might not be 100% perfect but you get the idea.)

Get-SPSolution | ForEach-Object {If ($_.ContainsWebApplicationResource -eq $False) {Install-SPSolution -Identity $_ -GACDeployment} else {Install-SPSolution -Identity $_ -AllWebApplications -GACDeployment}}

Get-SPSolution is pretty easy that returns all of the solutions in the farm. As a side note there are a lot of properties you can play with here. So you could for example find out which ones are already deployed, in our case we didn't have any solutions so we didn't mess with it. ForEach-Object is going to run all of the cmdlets within the { } on each solution. The If cmdlet allows us to evaluate the contents of ( ) if it is true we do the next set of { } if it is false then it will process the { } after the else statement. $_.ContainsWebApplicationResoruces is a true or false property of a solution. –eq checks if the property is equal to $False. $False is a PowerShell system variable that represents false. So this statement checks to see if the solution has web application resources because if it does we need to install the solution a different way. For the solutions that don't have web resources ($false) we run {Install-SPSolution -Identity $_ -GACDeployment} which is the SharePoint PowerShell cmdlet for deploying a global solution. For the solutions that do have web application resources we run {Install-SPSolution -Identity $_ -AllWebApplications -GACDeployment} which just tells SharePoint to deploy those resources to all of the web applications in our farm. I am guessing you don't necessarily have to deploy them all to the GAC (-GACDeployment) but this is the way my customer wanted it so I said ok.

When you run the command you should just be returned to the prompt. You can then go to Central Admin > System Settings > Manage farm solutions. Here you will see your solutions and their current status. If you deploy a lot at once it can take 10 minutes or more for them all to go from deploying to deployed but they will. Just be patient.

Hopefully now you feel equipped to go play. Remember the idea here is for you to learn about the moving pieces. Yes my scripts work as is but I am guessing you can take these and massage them to be much cooler. I am just a PowerShell hack who figures out the first solution that works instead of always figuring out how I can refine it to the most efficient, coolest thing ever. J Though I do think I had it worked out to do the import and deploy in one string of commands but we had to return to real work before we finished that part.

Thanks to Todd for double checking me and making the random edits because I suck at English. And thank you to Jeff Jacobs. He was the customer that helped me pound my way through this fun stuff and laid out the challenge.

Shane – SharePoint Consulting

PowerShell doesn’t show all of your SharePoint 2010 content databases

Shane — Thu, 28 Apr 2011 05:00:00 GMT

Today SharePoint managed to freak me out for a few minutes. I was looking at a customer's farm and when I ran the PowerShell cmdlet Get-SPContentDatabase it was only returning one content databases even though my farm has two content databases. The output looked like this.

So then I thought about it and figured I had the problem where the account I was logged in as didn't have access to the other databases. So then I grabbed Todd's blog post on How to create a SharePoint 2010 admin account and stop using sp_farm because I knew it would jog my memory on how to give my account access to the databases. I ran through it and I still got just the two databases. UGH.

So then I figured when all else fails try Central Admin. When I went in to manage content database sure enough they were all there. But then that is when I saw a clue. The content database I couldn't see was "Stopped".

Surely that isn't the issue? But I try anyway. I quickly set the database back to started and then run my PowerShell again.

That fixed it. Well, I guess you learn something new every day. The more we play with it the more it seems to be a lot of little things that happen when you leave a database in the stopped/offline state. I think as a rule of thumb leaving databases in this state is a bad idea. Some of the weirdness we have seen is with timer jobs, like the profile sync job, don't run against those databases.

Why do people leave databases in the stopped state?

The main reason people do this is because they do not want any additional site collections to be created in that content database. And that is admirable goal if you are trying to control database sizes. The key is the better way to accomplish this is to set the maximum number of site collections to the current number of site collections. Same result without weird behavior like this.

Another way to see all of the content databases regardless of state

This comes from one of my developers named Jonathan Mast. He suggested instead of using Get-SPContentDatabase that I use Get-SPWebApplication | ForEach {$_.ContentDatabases} | Select Name to get all databases regardless of state. That works pretty well.

Todd would like you to know

If you use Get-SPDatabase | Select Name, Status SharePoint will give you a wonderful list of all of your SharePoint databases (config, services, and content) and show you their status. In this case my mystery database would have shown as Disabled. Another nice trick when fighting through a problem like this.

Hope this helps

Shane – SharePoint Consulting

Search Database GUID issue

Shane — Mon, 06 Dec 2010 06:00:00 GMT

So in the quest to have no GUIDs I wrote the blog post How to remove the GUIDs from the SharePoint search service application databases to great fan fair. After reviewing my VM and other servers I have performed the steps on I have found the error message below. (Text and image included to help with the search engines getting you here.)

SQL Database 'NewSearch_DB_e28b777e4e664c479879f5a257b932f9' on SQL Server instance 'CowTown' not found. Additional error information from SQL Server is included below.

Cannot open database "NewSearch_DB_e28b777e4e664c479879f5a257b932f9" requested by the login. The login failed.

(Don't make fun of my server being named CowTown.)

So that seemed kind of scary but made sense because I had deleted that old database. After digging around I found that search seemed to work fine and apparently one of the timer jobs was just trying to check this database once an hour. So first thought I had was "I wonder if SharePoint still thinks that is a database somewhere even though the Search service application isn't using it?"

Well, I know PowerShell to find out the answer to that question. I opened up a SharePoint Management Shell and simply ran:

Get-spdatabase

Which gave me the output below:

Sure enough. The old database is still listed even though Search isn't using it. UGH. (Fifth database from the bottom.)

Another place I saw it that was kind of freaky was Central Administration > Upgrade and Migration > Review database status

Here you can see that it is listed as Not Responding. UGH.

So all of this makes sense. We did delete the database because Search doesn't use it anymore. Now we just need a way to tell the farm to quit trying to reference it. I fought with about 3 different ways to make this work and finally I came up with this one which I believe should be completely supported. J (My other ways may have been a little too direct.)

Getting rid of the error

Open the SharePoint Management Shell
Type get-spdatabase and press enter. This will give the output below.
Find the database in question. You need to then copy the Id for it. You can right click in PowerShell and choose mark.
Type $bad = get-spdatabase <your id> and press enter.
Type $bad and hit enter. This will show you the database you have in the variable. It is your last chance to double check you got the correct database.
Type $bad.Delete() and press enter. No more database.
Type get-spdatabase and press enter. All better.

At this point all of your worries are gone. No more stupid error message. Standard precautions try this in your test world first. You are up a river without a paddle if you do this for the wrong database since it is a pretty violent way to delete the database.

May the force be with you!

Shane

SharePoint Consulting

Getting rid of GUIDs in SharePoint 2010 database names

Shane — Tue, 26 Oct 2010 05:00:00 GMT

It is like your typical battle of good vs. evil. SharePoint 2010 has a secret plot to run the world out of GUIDs and between you and me I think it has a good shot of accomplishing its goal. Well, me and boy wonder (aka Todd) have seen the pain and suffering they are trying to evoke and we have plan to stop it. Creating blog posts to remove as many of the GUIDs as possible.

"But dynamic duo who cares if the world runs out of GUIDs?" Well, to be honest the people it scares the most are the poor developers. And while we generally consider developers second class citizens that doesn't mean we wish them harm. And let's face it, if they didn't have GUIDs they would have nothing to do. And we all know bored developers will wander the halls of your office building aimlessly. Or worse they will congregate in places like the break room and will want to make small talk with you when you go to get an afternoon Mt. Dew. I don't know about you, but nothing ruins my day worse than idle chit-chat with a developer. Yucky.

So this post is your one stop shopping for everything about getting rid of the GUIDs: As Todd or I post new items for removing GUIDs we will update this post.

How to get rid of the Central Admin database GUID by Todd

How to get rid of the SharePoint 2010 Search service application database GUIDs by Shane

How to clear timer job error after renaming the Search Admin database by Shane

Microsoft article on renaming databases (Be careful, it isn't perfect yet)

How to rename the PerformancePoint Database by Shane

Build your farm without getting GUIDs in the first place by Todd

As always remember to test any of these steps on a nonproduction server before attempting on your real servers.

Save the GUID!

Shane

SharePoint Consulting

PS - I don't hate developers. Really, it just seems that way.

Configuring profile import in SharePoint 2010

Shane — Fri, 09 Jul 2010 05:00:00 GMT

So I keep smashing my head into this and it drives me nuts. So I am going to try to throw together some quick nuggets. I have gotten this to successfully work about a dozen times so I have hopefully seen all of the craziness. I have also worked with Todd Klindt to compile some of these notes.

The first one is for goodness sakes read this TechNet article. http://technet.microsoft.com/en-us/library/ee721049.aspx If you read it slowly and do everything it says you can do very little wrong. But no one wants to read it so here are my notes.

The farm account HAS TO BE A LOCAL ADMINISTRATOR. I am sorry but there is no way around this right now so quit trying to avoid it. Having a problem figuring out what account is your farm account? I can help with that.
1. Central Admin > System Settings > Manage services on server
2. Scroll down and find the User Profile Synchronization Service and click Start
3. You will see an account listed. This is the account that must be a local administrator account
4. If you are adding this account to the local administrators group for the first time right now you should reboot your server after you finish. If you don't you will get some nasty DCOM errors that will not go away until you are a local admin and reboot.
The farm account has to be able to logon as a service. By default a local administrator can but just in case you have locked down your server extra tight this might come up as it did for Todd the other day.
This same farm account has to have the Replicate Directory Changes permission in active directory. This is also not optional. I also ran into an issue when the forest functional level in active directory was still 2000 but I cannot find the notes on that. Something about this Replicate Directory Changes not being possible.
An oddity I don't really understand but have seen once. In one case I had to log onto the server as the farm admin account one time before I was able to get the service to start. Most of the time this is the case but once it was. Very odd. This blog post had the same issue.
If you get the service started and then try to manage the user profile service application and get some silly error pop up you just need to do an IISRESET.
A couple of MSDN forum posts and other stuff that I looked at along the way:
If you are getting goofy DCOM issues check out this blog post for getting rid of them.
There are two Forefront Identity Manager (FIM) services that get installed as Windows services by SharePoint. If you are troubleshooting profile imports and see FIM errors they are related to your problem. Don't try to manipulate these services manually.
If you have a multi-server farm you only need to start the service on the server you want it running on, not all of them.
(Added 10/18/2010) You can manually launch the ForeFront client by C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe.
The quick steps
1. Make sure your farm account has all those super permissions, domain admin might be easiest ;)
2. If you had to update your farm account permissions reboot now and save yourself the headache
3. Start the User Profile synchronization service, yes it will take 5 to 10 minutes to start the service
4. Do an iisreset
5. Go to manage your user profile service application
6. Click on Configure Synchronization Connections
7. Create a new connection to your domain
8. Fill in all the info and then select what OUs you want to import and click OK
9. From the manage profile service screen click on Start Profile Synchronization
10. Cross your fingers and be patient. It takes a while

So hopefully my cheat sheet of issues helps you on your quest. I promise to make updates to this cheat sheet as I find them. Heck, I am guessing as soon as Todd gets back from lunch he will remind me of something else we had to figure out. If you run into something you think should be added leave it in the comments. I will try to work those back up into the main blog post and give you the fame and glory you deserve.

Shane – SharePoint Consulting

Install Guide: SP2 for SharePoint (WSS v3 and MOSS 2007)

Shane — Wed, 29 Apr 2009 05:00:00 GMT

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.

Start time 11:11 PM
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.
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.
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.
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.
Launched the WSS SP2 EXE I just downloaded.
Agreed to the license terms and clicked Continue
Started 11:22 PM. Ended 11:24 PM.
When configuration wizard opens click Cancel and Yes at the warning. We will run config wizard after the MOSS update is installed also.
Launched the MOSS SP2 EXE I just downloaded
Agreed to the license terms and clicked Continue
Started 11:25 PM. Ended 11:36 PM.
Configuration Wizard opens automatically when the update finished installing.
Click Next at the welcome screen
Click Yes to stopping IIS, SharePoint Admin Service, and SharePoint Timer Service
Click Next at the completing screen
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.
Click OK.
Start at 11:38 PM. About 3 GB of content in this farm. End at 11:48 PM.
Click Finish
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

Fixing MOSS Search

Shane — Mon, 13 Apr 2009 05:00:00 GMT

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.

Open the SSP Administration page
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:

Go back to the SSP administration page
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:

Go to Central Admin
Click on Operations
Click Services on Server
They choose their Index server
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:

Open a command prompt
Type net stop osearch and press enter
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.

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

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.
Confirm that you have the correct index location. Usually the C: drive is less than ideal.
Click Ok

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

Now click on the Shared Services Provider name to open the SSP admin site.
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.

From the SSP admin screen click Search Administration
From the left hand column (quick launch for those who know terminology) click Reset all crawled content
Select Deactivate search alerts during reset
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.

From your SSP Administration home page click Search Administration
From the Quick Launch bar (on the left) click Content Sources
Hover over your Content Source, click the drop down arrow, and select full crawl
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.

From your SSP Administration home page click Search Administration
In the Quick Launch bar click Crawl rules
Click New Crawl Rule
For path enter your web app URL ex: http://portal.company.com/*
For Crawl Configuration select Include all items in this path
For Specify Authentication select Specify a different content access account
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.
Key step de-select the box to Do not allow Basic Authentication
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.

From your SSP administration home page click Search Administration
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

Install Guide: February Cumulative Updates

Shane — Wed, 11 Mar 2009 05:00:00 GMT

Whoops... because i am a big dummy I screwed up this post. Sorry, hope you weren't using it. :) Install SharePoint SP2 now instead.

Sorry

Shane SharePoint Consulting