Beware of the SQL rebuild index task in the maintenance plan...

If your SSP Search never Stops crawling and you have the SQL maintenance plan with rebuild index this might be your problem...

Info copied from here - I personally had this problem too.

We recently deployed Microsoft SharePoint Office Server 2007 (MOSS) and ran into an issue with the Office SharePoint Search Service. The Search service was stuck in the "Crawling Full" state. After about 1 week of troubleshooting with Microsoft Product Support, we have resolved our problem. In a nutshell, our Database Maintenance plan included a task to rebuild indexes which had a side effect of removing the ability to allow duplicate keys in the index which SharePoint Search requires. The lesson I learned here is to not include any index maintenance as part of your database back strategy for SharePoint 2007. For more details and how to fix the problem, please read on.


Problem:
The problem appeared when we first noticed that our default Content Source for SharePoint Search was stuck in the "Crawling Full" state. During normal operation, once a crawl is complete, the status should change back to Idle.

The problem occurred because our Database Maintenance plan included a Rebuild Index Task that did not preserve the duplicate keys in the index when it was being rebuilt.

Fix:

To fix the issue, we had to recreate the 2 indexes that were impacted. One is in the Shared Services Search database and the other is in the WSS 3.0 Search database. Please exercise caution when making these changes and make sure to have database backups before your start.

Shared Services Search Database

In the SharedServices Search Database, you must ensure that the IX_MSSAnchorPendingChangeLog index in the MSSAnchorPendingChangeLog table ignores duplicate values:



If this is not enabled, you can follow the steps below to allow duplicate keys:

In SQL Server Management Studio, navigate to the SSP Search database -> dbo.MSSAnchorPendingChangeLog -> IX_MSSAnchorPendingChangeLog index:


Script out the index
Delete the index
Modify the SQL to set IGNORE_DUP_KEY = ON. Here is what our index script looked like (you will need to modify this script to use the appropriate database):
-- TODO: change this to match the name of your SharedServices Search DB!
USE [SharedServices_Search_DB]
GO

CREATE UNIQUE CLUSTERED INDEX [IX_MSSAnchorPendingChangeLog] ON [dbo].[MSSAnchorPendingChangeLog]
(
[CrawlId] ASC,
[TargetDocId] ASC
)WITH (PAD_INDEX = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = ON, ONLINE = OFF) ON [PRIMARY]

WSS 3.0 Search Database
In the WWS 3.0 Search Database, you must do the same as the SSP Search database and ensure that the IX_MSSAnchorPendingChangeLog index in the MSSAnchorPendingChangeLog table ignores duplicate values. If this is not enabled, you can follow the steps below:

In SQL Server Management Studio, navigate to the WSS 3.0 Search database -> dbo.MSSAnchorPendingChangeLog -> IX_MSSAnchorPendingChangeLog index:


Script out the index
Delete the index
Modify the SQL to set IGNORE_DUP_KEY = ON. Here is what our index script looked like:
-- TODO: change this to match the name of your WSS Search Database Search DB!USE [WSS_Search_MOSSWEB01]
GO

CREATE UNIQUE CLUSTERED INDEX [IX_MSSAnchorPendingChangeLog] ON [dbo].[MSSAnchorPendingChangeLog]
(
[CrawlId] ASC,
[TargetDocId] ASC
)WITH (PAD_INDEX = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = ON, ONLINE = OFF) ON [PRIMARY]

The final step, to ensure a clean Shared Services database, we created a new Shared Services Provider and removed the old one. We also removed the offending database maitenance plans

Installing a Solution ended with status "Error"

Today I had a problem with installing a solution... :-)
It may sound silly because all you have to do is use stsadm -o addsolution -filename "Location Of File" and then deploy it thought the central admin but this time I got an "Error" in the solution status instead of the expected "deployed".
I could not re-deploy / remove becouse there was already a timer job related to the solution deploy.
After deleting the timer job the solution got back to not deployed status (and so on again and again...)

In the ULS logs I found this error - Updating SPPersistedObject SolutionOperationStatus Name=SolutionOperationStatus Parent=SPSolutionLanguagePack Name=0. Version: -1 Ensure: 0, HashCode: 38896601, Id: 87c32e71-13f0-4d85-a215-29f1d180d239, Stack: at Microsoft.SharePoint.Administration.SPPersistedObject.Update() at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.SetOperationResult(SPSolutionOperationResult opResult, String msg, SPWebApplication webApp, Int32 updatesPerServer) at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.DeployFilesInstallFeatures(SPWebApplication webApp, Boolean globalInstallWPPackDlls, Boolean installFeatures, Boolean force, Int32 tries) at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.DeployLocalCore(Boolean globalInstallWPPackDlls, Collection`1 webAppl...

After doing some investigation I found that the reason for the error was that the “Windows Share Point Services Administration” was not stated on one of the farm servers. After the service has been started, the deployment worked just fine...

Content Deployment - What you won't find in the books...

I have been dealing with content deployment for some time and I think it's time to share some of my experience, especial tips and tricks and other stuff I found relevant that usually not in the regular documentation...

Content deployment is great but tricky... about the regular problems and errors you can read in the "great" Stefan's blog

Well... Time for the gussy stuff...

Content Deployment Tips from the real world...

1. Since Microsoft allows us to schedule the content deployment jobs only every 15 / 30 / 45 / 60 minutes or once in a day I created a cmd file that runs my content deployment jobs (in specific order one by one using stsadm -o Runcontentdeploymentjob "Job_Name") so this way I can do it whenever I want (4 times a day and one in the weekends for example with the windows scheduler).

2 When you deploy new solution / upgrade / sp / etc you should stop the content deployment, it is easier to do it that way too.

3. If you have a feature in the source and destination, be sure to activate it only in the source, the destination feature should be activated by the content deployment.

4. If you have event receiver / workflow connected to a list remember thagt it will be transferred ti the destination - meaning that usually you will need to remove the workflow / event reciever from the destination lists BUT every time you will do a full deploy it will be transferred again to the destination.

5. Start with blank site from stsadm -o command - don't use the blank template from the gui.

6. You can do 2 way content deployment - use DocAve tool for example.

7. CD is great way to transfer your data between domain's / farms (better then db detach / attach) because it is easier to set up the new permissions and not dealing with "cleaning" them after using db's backup / detach.

8. It's great way to transfer some or all your data from prod to QA if needed. You can script the creation of the new site collection and just get again all the data from scratch if you usually destroy your QA :-)

STSADM all commands filtered

Hi There,
Just saw cool presentation of using silverlight that shows all STSADM options divided (if you like) to catecories like "not in gui", "new in sp2", "new in sp1" , "search related" etc...
Check it out here.