After a recent deployment of SharePoint Search Server Express 2010 I noticed the following issue picked up by the Health Analyzer.
Clearly something was wrong, my first instinct was to check the site “http://<CentralAdminApplication>:<Port>/Sites/Help” but it was all there and appeared to be happy.
The link itself as shown in the “Remedy” section actually just redirects to the Microsoft SharePoint Website (http://technet.microsoft.com/en-US/sharepoint/default.aspx)
When I ran the PowerShell “Test-SPContentDatabase” command against the database in the Analyzer result I got the same message, here’s the syntax
Test-SPContentDatabase -name <DatabaseName> –WebApplication http://<CentralAdminApplication>:<Port>
And here’s the error message in full for searching purposes
Category : SiteOrphan
Error : True
UpgradeBlocking : False
Message : Database [<DatabaseName>] contains a site (Id = [f1e7b96d-a3e8-4602-9bde-76ae2c9ce0b9], Url
= [/sites/Help]) that is not found in the site map. Consider detach and reattach the database.
Remedy : The orphaned sites could cause upgrade failures. Try detach and reattach the database which contains
the orphaned sites. Restart upgrade if necessary.
The message is telling me that the Central Administration Help site is “not found in the site map”, so using PowerShell I’ve grabbed the database in question using
$DataBase = Get-SPDatabase | where {$_.Name -eq "<DatabaseName>"}
The first thing I tried was the command
$Database.RefreshSitesInCongfigurationDatabase()
Executing the “Test-SPcontentDatabase” command again, resulted in exactly the same error, so the next recommendation is to detach and reattach the database.
I performed this using the command
Dismount-SPContentDatabase $Database
to detach, followed by
Mount-SPContentDatabase $Database -webapplication http://<CentralAdminApplication>:<Port>
To reattach to my Central Administration application
Once, again the “Test-SPContentDatabase” returned the same information so I wanted to see if I could find the site in question. Using the following command
Get-SPSite -ContentDatabase $Database | select url, id
returned the following output;
Url ID --- -- http://<CentralAdminApplication>:<Port> 337dde2c-ced8-4e58-858a-cd2443d34044 http://<CentralAdminApplication>:<Port>/sites/Help afa3a5b4-eba0-45cf-8eac-7b19999cf4f7
If you look at the original error, the Analyzer is complaining about the “/sites/Help” with the id “f1e7b96d-a3e8-4602-9bde-76ae2c9ce0b9” the ID ”Get-SPSite” reported on was “afa3a5b4-eba0-45cf-8eac-7b19999cf4f7” so where is it?
I tried to see if I could discover the site directly by the rogue id so I ran the command
get-spsite -contentdatabase $Database | where {$_.ID -eq "f1e7b96d-a3e8-4602-9bde-76ae2c9ce0b9"}
and yet nothing returned.
Interestingly, using “stsadm.exe” I executed
stsadm -o enumallwebs -databasename $Database
and the output from this indicated there were indeed 3 sites in the database.
Databases> <Database SiteCount="3" Name="<Database_Name" DataSource="<Database_Server>"The site with the id f1e7b96d-a3e8-4602-9bde-76ae2c9ce0b9 could not be found.
It’s also showing that rogue id again, so once again using “stsadm.exe” I ran the following against the database with the rogue id
stsadm -o deletesite -siteid f1e7b96d-a3e8-4602-9bde-76ae2c9ce0b9 -force -databasename <Content_Database> -databaseserver <Database_Server>
and once complete, I re-ran the “Test-SPContentDatabase” command again and the result was clean, went back into “Central Administration” > “Monitoring” > “Review Problems and Solutions“, re-ran the “Missing server side dependencies” rule and the issue was gone.
Stsadm to the rescue and my Monitoring is clean for another day….
