One issue you might have encountered after experiencing some Search problems.Although everything looks ok, the crawl schedules are not respected and the crawler fails to index the content at the specified times.

No errors are logged and if you start the crawl manually , everything works great and the items are indexed ( regardless if you run a full or an incremental crawl).

What you need to know is the crawler schedules are monitored by a timer job , specifically the Indexing Scheduling Manager Timer job.

You can find it in the Central Administration/Operations/TimerJobDefinitions.

As you are aware, the search settings are stored in the database, registry and file system, being kept in sync by a search config. sync timer job. If this task fails to execute, then, you may find yourself into this scenario.

This issue will not be solved by a stop/restart of the Search service (which will make you lose the index) , nor by a re- provision of the Search Service in the farm.

To get out of this problem , get the timer job back and restore the crawl schedule functionality all you need to do is compile the following code into a small console application and run it on the indexer server:

//Code starts Here

//This source code is freeware and is provided on an "as is" basis without warranties of any kind,
//whether express or implied, including without limitation warranties that the code is free of defect,
//fit for a particular purpose or non-infringing.  The entire risk as to the quality and performance of
//the code is with the end user.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
using Microsoft.Office.Server.Search.Administration;

namespace searchservinstprov
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                SearchServiceInstance myinst = SPServer.Local.ServiceInstances.GetValue<SearchServiceInstance>();
                if (myinst != null)
                {
                    Console.WriteLine("Starting Synchronize");
                    myinst.Synchronize();
                    Console.WriteLine("Synchronize Finished");
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex);
            }
        }
    }
}

//Code ends Here

Thanks Gyorgy http://blogs.msdn.com/gyorgyh

Additional Reference:

http://msdn.microsoft.com/en-us/library/microsoft.office.server.search.administration.searchserviceinstance.synchronize.aspx

I ran into this while attempting to import the profiles and playing with my managed properties in the SSP.

Here’s what I did and noticed:

Having defined my  BDC as a People Details Repository  the initial purpose of the test was to completely replace all the user details in the search results with the results coming from BDC, because , as in life, the user details like address or office or job role might change and it is more likely that the updates will occur first in the BDC not always in AD.

Starting with the above assumption, I considered the AD properties static and left the default user properties mapping as they are ( eg. Office will be imported from AD) and , since I wanted to replace only the results, I modified the metadata mappings in the search configuration page to map to my BDC values and removed the People metadata from being indexed.

Uncheck “Include values for this property in the search index” in Metadata property definition.

For a list of default values you can check the full comprehensive list at Anne Stenberg’s blog.

http://blogs.technet.com/anneste/archive/tags/crawled+properties/default.aspx

I ran a full profile import and tested the search

After modifying the WorkPhone metadata HighConfidenceDisplay2, mapped by default to  People:WorkPhone(Text) and removed the property from index I ran a full crawl and expected to see the results coming from BDC. To my surprise , no work phone was returned. I checked the BDC database to see if the phone was present. I checked the ActiveDirectory. Workphone ( and alternates) checked out fine. Furthermore, the field in the user properties ( which should have been imported from AD) was empty.

I re-mapped the metadata property to it’s original value and ran a full profile import and a full crawl.The property magically appeared.

Hmmm.I wondered if the behavior is reproducible with other metadata and I modified the Office managed property which, again should get imported from AD.

By default, the People:Office(Text) metadata property mapping is mapped to the following categories:

OfficeNumber, HighConfidenceDisplay2,4,7.

I replaced all the mappings with mapping to my BDC.Office value and unchecked the “Include values for this property in the search index” checkbox.

The result after a full crawl and a full profile import : Office Field was no longer populated with Active Directory value, nor with the BDC value.

Hmmm!

Taking the test further to see if this happens for all the profile properties,  I replaced all the metadata mappings with values from my BDC. The biggest surprise of all came when I modified People:AccountName(Text) ( mapped to HighConfidenceMatching and AccountName) because after a full crawl, the next profile import skipped the accounts altogether.  The profiles did not get imported AT ALL .

After doing some research, I found out the next post which pretty much explains the behavior.

http://blogs.msdn.com/gyorgyh/archive/2009/02/07/how-does-it-work-moss-2007-user-profile-import.aspx

The point is, since the profile import is basically a crawl, if we remove the People:xxxxxx() metadata from the index, the filter will discard all these values therefore, discarding the properties imported from Active Directory. If the property discarded is AccountName, naturally the profile will not get imported at all since we cannot have NULL AccountNames.

The solution was to add back the properties to their original mappings, along with the bdc mappings and run a full crawl on the Local Office Sharepoint SitesContent Source.

And the conclusion is : Do Not Remove People:AccountName(Text)  from Index and do not change it's mapping. For that matter, do not remove the People:xxxx (text) from being indexed or you might run into very peculiar behaviors.

Hope it helps.

Noticed something weird the other days:

I was fiddling around managed properties in my search settings and thought of deleting some of them to remove them from being indexed and from the search results. Among other managed properties deleted, I also deleted the “Site” managed property.

What I noticed after running a full crawl was that the “Search This Site:” Scope was no longer returning any results. I could retrieve the results from my search portal on the same SSP, which meant the documents were in fact indexed. however the “This Site “ out of the box scope was not returning any results.

I tried re-creating the “Site” managed property but unfortunately I had no success in bringing the results back.

What in the end I did was re-create the entire SSP and moved on, but here’s a word of advice:

“Do not delete the “Site” managed property.”

How to move an SSP

If you, like me had the chance of re-installing SharePoint (with all the language packs that you might have used before), it is likely that you have encountered this message.

You will most likely see this message when running the configuration wizard , or attempting to create new sites, even in other languages than the installation.

To sort this issue check if the following registry key is present:

HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\ServerLanguage

If it’s not there create it. Add a new String value:

Key name:  1033

Value =””” (empty)

Reference:

http://blogs.technet.com/stefan_gossner/archive/2006/07/11/441127.aspx

A number of issues with crawling content in SharePoint was observed since installing .NET 3.5 SP1.  The behavior, usually is the inability to crawl the content and various permission-related messages in your crawl log.

Among these the most frequent message sounds like:

Check that the Default Content Access Account has access to this
content, or add a crawl rule to crawl this content…

The reason for all these messages is actually a change in the http authentication process implemented in this service pack.  As you are aware, in order to crawl content, SharePoint will attempt to log on by using the default content account, if the logon authority , specifically the Lsa will deny the logon attempt, these errors may occur.

The resolution for that is rather simple described in the following KB article http://support.microsoft.com/kb/896861 . All you need to do is to disable the loopback check

Here, for your reference the changes to NTLM authentication for http web request in version 3.5 SP 1 http://msdn.microsoft.com/en-us/library/cc982052.aspx

Among many features and improvements to the search engine, things brought by the Infrastructure Update, perhaps the most awaited one, search federation, was finally deployed.  With search federation the search results are no longer restricted to the site collection, webs, farms in other words, local search results.  On the same search result page using the same search query term the user will retrieve the results from both the index as well as external search engines. 

But this doesn't mean that you should use  federation ONLY  for the external sites.

As you learn from this blog: http://blogs.technet.com/tothesharepoint/archive/2008/07/18/3090988.aspx federation has it's very well thought place in geo distributed environments, where multiple users from different parts of the globe using services from different SharePoint farms needs to search across multiple farms instead of just their own.

So, how how does one set this up?

First of all the let's assume you have to a server farms , farm A and farm B.  The users accessing these farms reside in the same forest, so the permissions should not be an issue.

You want the users from the farm eight knots to receive only the results from farm A index but also from Farm B ‘s index.  Not to mention you don't want to index the same content twice, so you would set up a Federated connection on farm A to retrieve search results from farm B’s index.

Step one:

Farm A's central administration, SSP settings, let's create a new federation location connector:

Go to your Federated locations page and click on the new location button, type in the location name, display name and the description as you would like to have them.  Scroll down until you reach the location type.

Choose  OpenSearch 1.0/1.1

Now it's time to specify the query template, as you might be accustomed from Internet explorer methods on setting custom search provider's we need to specify an URL, a parameter and the query string.  Four this we should go to farm B search results page, usually something like :

http://… /SearchCenter/Pages/results.aspx?k=TEST

In Internet explorer custom search provider settings you would have had to copy this URL and simply put it in, but in SharePoint, the Federated location should have an XML formatted resultset of the search results, therefore to obtain these , click on the RSS feed button in Internet explorer when you have the search results displayed.  You will get a page who’s URL looks similar to this:

http://…/SearchCenter/_layouts/srchrss.aspx?k=TEST

It's easy to notice the keywords test in the second URL(as parameter), copy this URL paste it into your Federated location query template field and the replace TEST with {searchTerms}

A special notes to this : for it to work, the curly brackets and the capitalization on searchTerms keyword should be exactly as here small “s” capital “T”.

In the end, your query template URL would look something like this:

http://…/SearchCenter/_layouts/srchrss.aspx?k={searchTerms}

Now scroll down to complete to the more results link template,which will be in fact the actual results page from the farm B server, of course parameterized  to our search terms

http://…/SearchCenter/Pages/Results.aspx?k={searchTerms}

All you need to do now is a scroll even further down to specify the credentials that would be passed on to the new server search service.  If your users reside in the same forest across multiple domains you can simply specify the credentials :

User:

…

Kerberos Integrated

Which would mean that each time a user logged on to your server in farm A will query the search service in farm B his credentials will be passed on to the farm B search server, allowing for the security trimming of the results to occur.

Click OK and the location should be set .

All that it's left to do is to go to your search results page in a server A and add a federated location web part that will consume the Federated location we just defined here.

I know that reading the above you will say : backup and restore  or export and import .

Perfectly true.

What if the procedure involves moving one BIIIIIIG Site > 15 Gb?

If you have the time to do it, that’s perfect. Just schedule the operations and go ahead.

Here is a method that will save you some time in completing this operation:

Say you have the webapplication http://myportal

Your customers create their sites under http://myportal/customers/subportal

CustomerA  upgraded his contract , which entitles him to a full blown URL like http://MycustomerA  and you need to port his data from Http://myportal/customer/subportalA to http://mycustomerA

Plan:

On the old webapplication:

Create a new content database My_CustomerA_DB

open a command prompt on the Sharepoint Server and navigate to

%COMMONPROGRAMFILES %\Microsoft Shared\web server extensions\12\BIN and run :

stsadm –o mergecontentdbs  -url http://myportal/customers/subportal

   -sourcedatabasename WSSCOntentDB  -destinationdatabasename My_CustomerA_DB

Mergecontentdbs- Stsadm operation (Office SharePoint Server)

After the operation completes, detach the My_CustomerA_DB from the old webapplication

NOTE:

If you have the infrastructure update installed (or later fixes) you don’t need to run the preparetomove command, see: Todd Carter's WebLog - PrepareToMove Away From Running This Command

Create a new webapplication for the Http://mycustomerA URL with a DefCOntentDB

Attach the My_CustomerA_DB to the new webapplication and remove the default DefContent DB

Go

YAN (YET ANOTHER NOTE) :

From:

http://blogs.msdn.com/sharepoint/archive/2009/03/24/possible-issue-with-mergecontentdb-stsadm-operation.aspx

“Under certain circumstances, the mergecontentdb Stsadm operation may fail. These circumstances include combinations of significant site collection size, user traffic, and SQL Server load. When the command fails, both the source and destination databases can be corrupted.

If you use mergecontentdb, make sure that you:

· Always back up both the source and target databases before using this operation.

· Set the site collection to be read-only before using mergecontentdb  to move it.

· Refrain from cancelling the operation (either on the front-end Web server or the server running SQL Server).

· Run the command during off-peak hours, because mergecontentdb places significant additional load on the server running SQL Server.

Alternatively, consider using Batch Site Manager and the method described here. Because the Batch Site Manager works with site collections by using the Stsadm backup and restore operations with the –url parameter, we recommend that you not use Batch Site Manager for site collections larger than 15 GB.

The Batch Site Manager is included in the SharePoint Administration Toolkit:

· Microsoft SharePoint Administration Toolkit v3.0 x86

· Microsoft SharePoint Administration Toolkit v3.0 x64

Related KB:

http://support.microsoft.com/kb/969242”

Here is a procedure that might come in handy when you, for some reason are required to            re-install the binaries of the server.

Scenarios requiring this might include reverting to a previous state, fixing a corrupted farm, etc.

I have ran into those situations where if you simply click on uninstall would not do much good, so here is a manual removal procedure , should you need it:

First step (required if you want to recover your farm in a supported manner):

If you are able to do so, detach the server from the farm either using the SharePoint Configuration Wizard or by using psconfig –cmd configdb -disconnect

Disable and Stop MOSS Service on the server

-Microsoft Single Sign-on Service
-Office SharePoint Server Search
-Windows SharePoint Services Administration
-Windows SharePoint Services Search
-Windows SharePoint Services Timer
-Windows SharePoint Services Tracing
-Windows SharePoint Services VSS Writer

Note the following registry keys for the location where Sharepoint Binaries are installed :

HKLM\Software\Microsoft\Office Server\12.0
-InstallPath

(default is C:\Program Files\Microsoft Office Servers\12)

HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0
-Location

(default is C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\12)

Delete the following registry hives:

HKLM\Software\Microsoft\Office Server\12.0
HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0
[x32] - HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\OSERVER
[x64] - HKLM
\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\OSERVER

Delete the following folders:
The value of the InstallPath key
The value of the Location key
C:\%CommonProgramFiles%\Microsoft Shared\SERVER12

Uninstall SharePoint using Windows Installer Cleanup utility:

Download the tool from http://support.microsoft.com/kb/290301

Install the tool on MOSS server and run the program from Start > All Programs >
Windows Install Clean up

Select the entries that start with

“Microsoft Office SharePoint *.*” ,“Microsoft SharePoint Service *.*” and “Microsoft.Office*.*” having the same binaries version as the Server and select remove.

NOTE!

If you have Microsoft Office installed on the server, you may find other Microsoft Office Products to remove. Carefully select ONLY the ones having the same binaries version as the SharePoint Server and not the other ones.

Snags you may hit along the way:

_____________________________

Unable to delete some files in the SharePoint install location

As you correctly assume , this can happen if the files are somehow locked and you cannot get a handle.

A very useful tool to overcome the issue is Process Explorer

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Open it, use the Find menu and check if the dll’s you are trying to delete are or not in use.If need be, kill the process locking them.

Once you are done, reboot the server and re-install the binaries.

Attach the server back to the farm.

How to remove Office SharepointServer 2007  on technet:  http://technet.microsoft.com/en-us/library/cc262874.aspx

Hope this helps

You are of course aware of the fact that starting with Service Pack 1 the workflows created in SharePoint designer that should launch under the credentials of the system account will no longer start automatically.

You know what the resolution is for this problem: simply do not to use the system account.

You implemented all the steps written here http://support.microsoft.com/kb/947284 ,but the workflow still does not start.

More interesting, if you email-enable a document library and attach a workflow to it, and set the workflow to start on Item creation, this workflow will never start.

This usually happens because the e-mail is saved into the document library using the sharepoint services timer service account credentials. If an e-mail was created by the system account then the workflow will attempt to start using the system account which is no longer permitted.

As you cannot change the credentials for the for the timer service, what should you do?

The answer is pretty simple: install Infrastructure Update http://support.microsoft.com/kb/953749/(and of course if you are at it, you can update the whole farm to the latest patch level (FEB CU) ) and pay close attention to one small line (made bigger here because of it’s importance) written in the notes part of the knowledgebase article:

To prevent the declarative workflows from impersonating the system account, the workflows will now impersonate the user who created the workflow association.

This basically means that you should create a special account not SHAREPOINT\SYSTEM, that is a site collection owner on the site collection where the workflow is hosted, open the workflow in SharePoint Designer while logged on as this new account and simply save the workflow without modifying anything.

It will effectively change the account that associated the workflow, which will allow it to start.

A !

you should also run

stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true

to enable workflows to start using the impersonation scheme

http://support.microsoft.com/kb/953289/

This might come in handy whenever you (like myself and I am sure thousands of others) see some error in the execution of one workflow and found the completely useless messages like “Error Occurred”

Dig deep and find nothing

first troubleshooting step would be to enable verbose logging on the workflows category and check the SharePoint logs.

If this does not provide you with a clue on what might be going on, you can try the following thing:

Add the following code to the web.config of the site where the workflow is located after this key :

</System.Workflow.ComponentModel.WorkflowCompiler>

-----------------------------------------------------

  <system.diagnostics>

      <switches>

          <add name="System.Workflow LogToFile" value="1" />

          <add name="System.Workflow.Runtime" value="All" />

          <add name="System.Workflow.Runtime.Hosting" value="All" />

          <add name="System.Workflow.Runtime.Tracking" value="All" />

          <add name="System.Workflow.Activities" value="All" />

          <add name="System.Workflow.Activities.Rules" value="All" />      

      </switches>

  </system.diagnostics>

-----------------------------------------------------

and before this key

<appSettings>

Try to start the workflow.

You should get a debug-level log file created on c:\windows\system32\inetsrv, workflowtrace.log

Additionally, it might happen that sometimes the workflowtrace.log file is  not created automatically ( maybe some permission issues that I didn’t bother to investigate). Just create the file by hand and start the workflow.

You should have all the information you need to troubleshoot the issue in the file.

Cheers

Official content published here :http://support.microsoft.com/kb/972914

Purpose : To get notified whenever something new gets indexed, based on a search term you specify. Say for instance that you would like to get notified whenever a new “TOP SECRET DOCUMENT” :) gets indexed.

Go to the search page, issue a query and when the results page is displayed, click on the “Alert me“ link, configure the Search: TOP SECRET DOCUMENTS alert to inform you when there are

New items in search result or,

Existing items are changed or,

All changes

and choose the notification type to Daily or Weekly based on your needs,

Now , if your outgoing mail configuration is properly set, you should receive a subscription and you should be all set, but … what if you do not receive the daily summaries ?

Troubleshooting step 1:

Check if the search based alerts are enabled in Central Administration , SSP Settings, .. /ssp/admin/_layouts/enablealerts.aspx

You should have the following message Currently active.

Troublehooting step 2:

Check the alerts timer job status:

Enabled?

stsadm.exe -o getproperty -url http://SiteUrRL -pn alerts-enabled
The expected output is <Property Exist="Yes" Value="yes" > if not, set it with:

stsadm.exe -o setproperty -url http://SiteUrRL -pn alerts-enabled -pv “Yes”

________________

Immediate alerts frequency:

stsadm -o getproperty -pn job-immediate-alerts -url http://SiteURL

Expected Output <Property Exist="Yes" Value="<valid date and time interval>" > if not, set it with:

stsadm -o setproperty -pn job-immediate-alerts -pv "every 1 minutes between 0 and 59" -url http://SiteURL

________________

Daily alerts setup:

stsadm -o getproperty -pn job-daily-alerts -url http://SiteURL

Expected Output <Property Exist="Yes" Value="<valid date and time interval>" > if not, set it with:

stsadm -o setproperty -pn job-daily-alerts -pv "daily between 22:00:00 and 24:00:00" -url http://SiteURL

________________

Weekly alerts setup:

stsadm -o getproperty -pn job-weekly-alerts -url http://SiteURL

Expected Output <Property Exist="Yes" Value="<valid date and time interval>" > if not, set it with:

stsadm -o setproperty -pn job-weekly-alerts -pv "weekly between Fri 22:00:00 and Sat 24:00:00" -url http://SiteURL

where <valid date and time interval>can be any of the following values:

A valid Windows SharePoint Services Timer service (SPTimer) schedule in the form of any one of the following schedules:

• "Every 5 minutes between 0 and 59"

• "Hourly between 0 and 59"

• "Daily at 15:00:00"

• "Weekly between Fri 22:00:00 and Sun 06:00:00"

• "Monthly at 15 15:00:00"

http://technet.microsoft.com/en-us/library/cc262629.aspx

Everything is properly configured but the weekly summary do not appear where to look next ?

Troubleshooting step 3:

Sharepoint logs, usually located at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS.

Increase the level to verbose for the following categories:

Timer

MS Search Query   

MS Search Query Processor    

Open the log when you know your alert should be sent and look for the following message :

AlertsJob processed X daily notifications in X digests, sent X emails, failed to send X emails

if the message is present that means the alert job is running.

You may wonder however why don’t you receive the mails although you can clearly see the message…

Here’s the interesting part, the message will never be sent if :

1. There are NO new items to be informed about (now new TOP SECRET DOCUMENTS indexed since the last alert)
2. You do not have permissions on the TOP SECRET DOCUMENTS (dough! ;) )

Both cases should generate a message from the Query Processor Search alert: '0' results

However the processing of the alert WILL generate the message as above.

A short “how-it-works” explanation: when generating search based alerts, the SharePoint Services Timer process will generate a query in your stead to retrieve the most recent resultset based on the Query you defined when you created the alert. After the result set is generated it will be security trimmed based on your permission level and if the resultset itemcount is >0 will send an e-mail.

If for whatever reason  the query will return no results,( no results, no permissions, even a possible error in generating the resultset) you will not receive any notification.

To summarize : configuring the search based alerts involves three things:

SSP configuration

Timer job timings

Resultset generation.

IMPORTANT : While generating the mail , the timer service will try to access the DC for the domain where the Server resides via MSRPC. If the user account for the Windows Sharepoint Services Timer Service does not have permissions to access the DC via RPC , the whole operation will fail.

Solution : use a domain account with enough permissions or add the user to a domain group with the respective permissions (test with Domain Admins, to see if it works)

Helpful tools to check the alerts definitions (alert time, definition, etc):

SharePoint Diagnostics, part of the Administration Toolkit v3.0

Download details: Microsoft SharePoint Administration Toolkit v3.0 x86 ...

Download details- Microsoft SharePoint Administration Toolkit v3.0 x64

SharePoint Manager

SharePoint Manager 2007 - Home

Good troubleshooting blogs on the topic:

http://weblogs.asp.net/mellota/archive/2007/10/11/sharepoint-2007-task-notification-alert-emails-not-working.aspx ( where you can find also information on the databases used by the alerts  – “look but don’t touch”  :) )

http://glorix.blogspot.com/2007/10/alerts-not-working-all-time.html

V

In the past few months , I have come across quite a big number of issues who’s only supported solution (other than rebuilding everything) was to create a new Shared Service Provider.
Easier said than done, an SSP change raises a very valid question:
What data can be transferred between SSPs and what data cannot be moved?

A short answer would be all the data that lies in the content database of each respective webapplication will move without problem and without manual interaction whereas all the data that stored in the SSP DB and SSP Search DB needs to be migrated.Some of it can be migrated (copied), for some of it we do not have tools yet (scopes), some of it doesn’t make sense to migrate because is internally bound to the SSP and would not make sense into the new SSP.

Here are the main components that need to be ported between SSPs

• my sites
• search settings.
• Excel Services settings
• Business Data Catalogs and applications.
• other configurations.

Looking at the above list the most manual work would need the profiles (because, not everything is automatically imported from AD) and the search managed properties, crawled properties.

The rest of the configurations might need additional work but not that time consuming as the above. Here is my approach on the matter:

Basic steps:

Create a new web application that will host the administrative site host for the new SSP

Create a new web application that will serve as repository for the “my sites”  (this may be deleted afterwards, see Note 1)

Create the new SSP

Moving the data (profiles)

1: Install administration toolkit on the server

(Microsoft SharePoint Administration Toolkit)

2: Download, compile Moss Profile Replicate from Codeplex

http://www.codeplex.com/MOSSProfileReplicate

3. Use MOSSProfileReplicate to export the properties from SSP A

4. Use MOSSProfileReplicate to import the properties into SSP B

5. Use Sharepoint Administration Toolkit Replication manager to instrument Full replication between servers.

Moving the data (managed properties, crawl properties and relevent categories)

1. Download, compile and run (export in A import in B)

SharePoint Shared Services Search Provider Property Creation

It will move (export/import): Content Sources Crawled properties Managed Properties, Search Scopes

The rest of the configurations in the SSP , you will need to migrate manually as no tools are (yet) available to do so.

Here’s what’s left:

Excel services ( do not forget to port the Kerberos related settings for delegation on this new ssp)

How to configure SharePoint Server 2007 and Excel Services for Kerberos authentication

BDC applications

Scopes (non - shared scopes, as the shared ones will be exported/imported by the above tool)

Audiences.

Final check of  all the settings

Now that you successfully migrated all the SSP data from A to B, all that’s left to do is to associate the web applications from SSP A to SSP B  and set this as default.

Notes:

1. If you do not want to change the web application hosting  the my sites, before changing the association, edit my site setting for SSP B, set the my site to point to the old my sites URL and delete the temp my site web application, then perform the association

2. If you start from having just one web application that hosts all the sites (portal, ssp administration site host, my sites) here’s what you need to do to separate them:

Scenario :

portal url : http://portal

Administration site host for the ssp http://portal/ssp/admin

mysites host http://portal/personal……

Issue A:  you cannot change the association for the administration site host of an ssp

i : create a new web application to host the administration site for the OLD SSP

http://newsite:10000

backup the site at http://portal/ssp/admin 

stsadm –o backup –url http://portal/ssp/admin –filename c:\sspadmin

ii. create a managed path (explicit inclusion) in the new site to point to /ssp/admin

http://newsite:10000/ssp/admin

restore the backup you just created at this location

stsadm –o restore –url http://newsite:10000/ssp/admin –filename c:\sspadmin –overwrite

change the ssp administration site host from http://porta/ssp/admin to http://newsite:10000/ssp/admin

stsadm –o editssp –title “your old ssp name” –sspadminsite “http://newsite:10000/ssp/admin”

Now you can change the portal association between the SSPs

Issue B:

how to move the mysites from http://portal/personal to a new webapplication at http://mysite ?

(mysite web application was created either when creating the new SSP as the new mysite host or manually using My Site Host template, in which case you need to add an wildcard inclusion to /personal manged path)

backup and restore

enumerate all the mysites that were already created (output it to a file for easier work):

stsadm –o enumsites –url http://portal/personal/ > c:\mysites.txt

edit the txt file and create 3 batch files ot of it:

one for backing up the mysites, one for creating the destination mysites , one for restoring from backup at the destination:

for instance, the following line from the initial file resulted (mysites.txt)

<Site Url=http://portal/personal/username Owner="Domain\username" SecondaryOwner="Domain\administrator" ContentDatabase="ContentDBName" StorageUsedMB="0.4" StorageWarningMB="80" StorageMaxMB="100" />

will become (in 3 bat files):

stsadm -o backup -url http://portal/personal/username -filename c:\backup\username.dat

stsadm -o createsite -url http://mysite/personal/username -sitetemplate SPSPERS -owneremail username@domain.com -ownerlogin "Domain\username"

stsadm -o restore -url http://mysite/personal/username  -filename c:\backup\username.dat –overwrite

same for the rest of my sites

HTH

Office Server Search Service cannot be started because it does not exist.

One of the most simple problems I’ve seen lately is :

Why can’t I start the Office Server Search Service in my MOSS install.I have the right key , the right CD and the latest fixes.I installed it and it is simply not there.

I have checked the NT Services and the service is there but Even if I start it it does nothing

What should I do?

As you can probably guess, there’s nothing wrong with your PC or Cd or key, you simply did not installed the server in the correct way to receive all the services.

One quick check:

Open regedit and check the value under the  following key :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\

ServerRole

Possible options:

WFE

APPLICATION

SINGLESERVER

Each option means :

WFE - Windows SharePoint Services Web Application (no search , no excel, no ssp, no cool stuff J, just web server)

APPLICATION –Everything (and you can add the server to a farm)

SINGLESERVER –Everything (but you cannot add the server to a farm , and most probably  you have MSDE or SQL Server Express on the box too)

To change the installation mode for the server (even if you managed to create webapplications and set-up your sharepoint config db), here’s the procedure:

Detach the server from the farm

Uninstall Sharepoint

Reboot the server

Re-install Sharepoint in Advanced mode and select your desired server role.

Run the configuration wizard and re-attach the server to the original farm (config_db)

You should get the applications back and everything else in place, as they were but with new services in the farm.

Joel Oleson has a very concise explanation on what are the server roles http://blogs.msdn.com/joelo/archive/2007/12/03/sharepoint-server-topology-server-roles-and-services-on-server.aspx, enjoy.

This is concerning an error found encountered in Sharepoint Designer based workflows after installing the October Cumulative updates.

The behavior you will encounter is the following:

Create a simple list with two fields:

Title (default)

User type Person/Group Lookup

Create a Sharepoint Designer Workflow attached to this list , set it to start manually.

In step 1 add an Action : Update List Item (or set Field Value to)

Update the User Field to a specific User

------------------------------

Create a new item in the list and start the workflow.

The resulted output is an Error Occurred Message in the Workflow History and the following error being logged in the Sharepoint logs:

Microsoft.SharePoint.SPException: Invalid data has been used to update the list item. The field you are trying to update may be read only. ---> System.Runtime.InteropServices.COMException (0x80020005): Invalid data has been used to update the list item. The field you are trying to update may be read only. at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(...

Apparently, the same behavior occurs if you are trying to use the Set Field In Current Item Action instead.

To overcome this unwanted behaviors, here are the workarounds that can be implemented (if you choose not to go and install the latest updates or they do not work in your case):

1. Instead of updating the username with the AccountName of the User, as usual in Sharepoint Designer (DOMAIN\AccountName) use the following pattern Id;# Name of the User, or just ID , where Id is the Id of the user as in the site collection.

2. Develop a custom workflow in Visual Studio

3. Develop a custom Sharepoint Designer Activity to perform the same action, specifically, update the list item with the pattern we know is accepted.

4. Use another activity to retrieve the User's ID and then Update the custom field using the default action

Let's take them one by one , shall we ?

1. You can try updating the username by specifying an ID in Sharepoint designer but only if you already know the ID of the respective user.When it comes to dynamically retrieving it, it might not be such an easy task to implement.

2. Yeah right.( Like if you already have the skills to develop Visual Studio workflows you would still use Sharepoint Designer to do it :) )

3. Not so easy and, as above, if you have the skills ...

Anyway, for those of you wanting to have a go at this option, see the following materials on how this can be achieved, implemented and successfully developed:

Building Custom Activities for Use in SharePoint Designer 2007

Microsoft SharePoint Designer Team Blog : Adding Activities to SPD

4. Here is the simpler approach to get the functionality back until a fix will address the issue:

First, you need to download the codeplex project Useful Sharepoint Designer Custom Workflow Activities

NOTE! This project is at alpha stage and is provided "as-is" under the Microsoft Permissive License (MS-PL ) v1.1

Second, install it on the server where you want to get the functionality

Third, you need to adjust the workflows as it follows:

Replace the original Update List Item activity with  two activities:

1. Lookup User Information (part of the tools you just installed)

Lookup ID for user DOMAIN\Username , store in Variable:UserID              

"Domain\username" can be manually specified or looked up , if you were wondering :)

2.  Update List Item

Update item in this List  (Set User Field to WorkflowData. Variable:UserID from above)

Ignition, Start !

NEWSFLASH !!! February Cumulative Update were released !!!

Among other things, a patch for the issue is comprised .

http://blogs.msdn.com/joerg_sinemus/archive/2009/02/25/february-cumulative-update-for-wss-v3-and-moss-2007.aspx

Among other things solved by the August Cumulative Updates, here is an issue which arosed after installing this patch.

One of those issues is that if you modify a default list form (Editform.aspx, DisplayForm.aspx) using Sharepoint Designer 2007 and on this modified form you had an inpage user picker control, when you try to access this page in internet Explorer you will get the error from the title of this blogpost.

Type 'Microsoft.SharePoint.SPFieldUserValueCollection' in Assembly 'Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' is not marked as serializable.

The explanation for the message is,  taken from http://msdn.microsoft.com/en-us/library/ms182350(VS.80).aspx ,"To be recognized by the common language runtime as serializable, types must be marked with the SerializableAttribute attribute even if the type uses a custom serialization routine through implementation of the ISerializable interface."

The error appers only when using the Sharepoint Designer modified form.

The workaround for the behavior consists in replacing the modified forms wih the default ones, which might not be a feasible approach because you really  need the customized templates.

A quick and easy fix is to remove the user control from the page and replace it with a label.This works fine if you are just DISPLAYING the control.But what can you do if you want to use the control in the editform and allow the user to search for a person ?

The easiest fix is: Install the December Cumulative Updates where this issue is addressed.

 The December Cumulative update information is posted at http://blogs.msdn.com/sharepoint/archive/2008/12/17/announcing-december-cumulative-update-for-office-sharepoint-server-2007-and-windows-sharepoint-services-3-0.aspx