MOSS 2007: People Search & All Sites Scopes Missing

I ran into a situation where after creating a new web application, site collection, and configuring the crawler “People Search” and “All Sites” was missing from the search scope. They existed in the top-level site collection search scopes but the only option available was “This Site:Intranet”.

Solution:

Rename the default “Search Dropdown” to something else, and create a new search display group name “Search Dropdown” (assuming your using english language packs). Make sure you specify to include People and All Sites in the scope group, and set your default scope.

Once you have recreated the scope, head into search settings and specify a custom scope page (using the default _layouts/ossearchresults.aspx works fine).

Error installing SharePoint 2010 RTM after uninstall of Beta

I decided to save myself some time by installing SharePoint 2010 RTM on a server that was previously running 2010 beta. Lets just say that it was not so short and simple…

License upgrade in Central Administration. LICENSE UPDATE FAILED

Install RTM over Beta. PSCONFIG FAILED

Uninstall beta and install RTM. PSCONFIG FAILED

Ok… Now what? Lets take a look at the event viewer…

Description:
Failed to create the configuration database.
An exception of type System.InvalidCastException was thrown.  Additional exception information: Unable to cast object of type 'Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection' to type 'Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection'.

Seriously?! A .NET error… Gimmie a break. After reregistering .NET I ran across another blog that addressed the issue.

http://www.sharepointassist.com/2010/07/14/geneva-error-exception-system-invalidcastexception-unable-to-cast-object-of-type-microsoft-identitymodel-configuration-microsoftidentitymodelsection-to-type-microsoft-identitymodel-configura/

SOLUTION:

Open the web.config file (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\Root) and manually update your .NET version from 1.0.0.0 to 3.5.0.0.

<section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

Create a new ConfigDB next time you run PSCONFIG.

Orphaned Application Pool in ConfigDB

I ran across a new type of orphaned data in the config database while at a clients the other day. I was in the process of adding a new SSRS server to a MOSS 2007 farm when it started failing on step 2 with the following error:

09/02/2010 22:17:33  8  ERR                      An exception of type System.InvalidOperationException was thrown.  Additional exception information: 1387
System.InvalidOperationException: 1387
   at Microsoft.SharePoint.Win32.SPNetApi32.NetLocalGroupAddMember(String groupName, String userName)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.AddGroupMember(String username, Int32 group)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionProcessIdentity(String strUserName, SecureString secStrPassword, IdentityType identityType, Boolean isAdminProcess, Boolean isWindowsService, String strServiceName, Boolean dontRestartService)

(After banging my head against my desk for a few hours)I took a look and see if the PSCONFIG wizard added any of the application pool to IIS. I noticed that it was attempting to provision a app pool that doesn’t exist! This typically would not be a problem, except that the identity account it was using was local to their WFE server!

At this point, I attempted to simply change the account to the DOMAIN web application account and re-run the PSCONFIG wizard. Aaannnndddd it failed again as it simply attemped to provision the app pool again with the wrong account. So I returned to the drawing board…

SOLUTION:

If you are still reading this then you really must need to resolve this issue. I will give you two methods. The second method below is to be done at your own risk. Please read carefully and take your time (or you might get yourself into a worse situation).

Your FIRST choice to solving this problem is to disconnect your your contentdb(s) from any production web application, disconnect each SharePoint server from farm, create new configdb, add each SharePoint Server BACK to the farm, recreate your web applications, and connect your content databases to corresponding their web apps.

Unfortunately, there also might come a day when you do not have a proper maintenance window available and you need to resolve this without interuption to your users… Below are instructions that directly query your SharePoint ConfigDB.

Manually query your configdb to retrieve the guid of your orphaned app pool.

select *
from objects
where name is not null

Review the list that returned- under the Name column you will see you orphaned app pool along with. Pay close attention to grab the one that says “SPApplicationPool” and copy the GUID from the ID column.

<object type="Microsoft.SharePoint.Administration.SPApplicationPool, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">

Now that you have your GUID- we can get out of the DB! Lets head to one of the SharePoint Server’s in the farm and run the following STSADM command.

stsadm –o deleteconfigurationobject –id <guid>