You make a backup through the Central Administration website, and on your soon to be testing server, you restore the backup.

And then you want to connect the restored Content database, only to discover that SharePoint claims that this database does not contain any sites… Oops?

Scramble to your database server, and look up the newly created content database. In there, there is a table called Sites. Write down the site ID of the sites you want to restore, and go to the Configuration database (SharePoint_Config*) of the server you want to restore your sites on. Open there the SiteMap table, and delete the records which contain the site ID’s you wrote down earlier. Reload the Content Databases page in Application Management, and presto! Your sites appear!

This is not fun.

First make sure you have created a Search Site.  Go to Site Actions, Create and select Sites and Workspaces.  Inthere, create a new site, with the Enterprise template Search Center.  Give it an url such as http://mysharepointserver/search/.

Next, go back to your main site, go into Site Actions, Site Settings, Search Settings and define a custom scope which links to your Search site, in this case /search/.

This will make the search scopes as defined in your Search Settings available, but chances are that your results are incorrect!

Next, you follow the advice written in this thread on the Technet Forums:

Modify C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\OSearchEnhancedFeature\SearchArea.xml with adding the two following lines within the <Control> XML tag:

ShowDD
false

Next, modify C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\osssearchresults.aspx with the modification on line 101:

This turns your search box into a Search site throughout your Sharepoint environment.

The Windows SharePoint Services Search is configured on the Central Administration website, Operations tab and Services on Server section.  There, you can select which server’s services you want to see, and see their running state and if necessary stop them.

I stopped the Windows SharePoint Services Search services, and that was a Bad Idea.

When you do this, and you want to start this service again, Sharepoint might complain that something’s rotten in your database:

WSS_Search_SPSSERVERNAME on DBSERVERNAME contains user-defined schema. Databases must be empty before they can be used.

This does not make anyone happy. Especially not me.

However, it is not bad as it sounds: you can safely delete the culprit database (“WSS_Search_SPSSERVERNAME”) on the database server, and start the service again.  You will lose the index, but if you make sure the index is recreated soon after, you should see starting results pop up again.

If not, be sure to check if the Search Server is defined for your sites in Central Administration, tab Application Management in the section Content Databases.

In your own domain, this will work without a glitch. But not in the other domains!

When working in your local domain, the new name mysite is registered in your DNS.  But visitors from other domains who you give the url mysite.mydomain.tld will see that their http queries do not get resolved, and your web browser might suddenly try to search mysite on Google.

The issue is that Sharepoint employs Alternate Access Mapping, and will rewrite headers to the correct mapping, which is offcourse not correct in your multiple-domain environment.

The following Microsoft TechNet article explains how to adjust your access mappings.  Make sure you make a mapping with the fully qualified domain name, and new http requests will resolve correctly.