There is a detailed step-by-step path to follow when applying the B2TR to a B2 MOSS installation.

This particular error shows itself when you are upgrading a stand-alone beta 2 installation, and you did not delete the registry keys specified for the Search Service. Interestingly, if you follow the steps - and be sure to delete the registry keys outlined in a stand-alone B2 installation - upgrade, the error does not surface.

Googling the error does not return any real support - and MSFT has shared only that this error can show up when a B2TR upgrade did not complete.

 

I have performed dozens of B2TR upgrades, and I can reproduce this error consistently when I fail to delete the HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\Services\Microsoft.SharePoint.Search.Administration.SPSearchService entry.

 

As you weed through the error entries that come before this specific error - it looks like the service account used to execute the MOSS services actually fails to launch the site. Then there is a parse failure error - followed by this error.

 

What is not clear is how this is related specifically to the registry key that should be deleted BEFORE the psconfig executes for the TR upgrade. It would appear that failing to delete the key - on a stand-alone installation - causes a failure during step 8 of 9 of the upgrade - even though no failure is logged in the event logs or in the Upgrade.log file. Each time I have seen this error I have noticed a slew of timer job entries at the end of the Upgrade.Log file - and then a final entry stating that the job returned a code of 0 - and then no other entries.

 

Take care of perform your upgrade - step-by-step following the instructions on TechNet.

Just when you think you have seen it all - I must share one you have NOT seen yet. Emphasis on YET???

As we forge ahead and architect these awesome solutions using MOSS - I suspect it is fairly easy to become enamored of some basics - you know, the little details that are the life-blood of your solution. :) Like I said - basics.

Basic 1) WSS is a life-blood underpinning of MOSS.

Basic 2) Without basic 1, there will be no basic 2 !!!

 

Today I experienced absolute bliss - from a MOSS perspective :)

 

I am working on an RTM upgrade. The basics are: I have a staging server - beta bits. I create a web application here, then restore a content database in SQL, and add that content database to the newly created web application. Finally, I'll upgrade this to RTM.

 

After a few days of tedious work - I'm flying along and everything is grand. Almost.

 

This morning I create a new web application. I open Central Admin, Application Management --> Create, etc. etc. etc. It creates the web app and returns to the screen where I can create the site collection. Here I navigate back to the Application Management --> Content Databases and I add my existing content database. I noticed something string... The content database added fine - but had zero sites in it. MMmmm I've seen this before. Usually you will notice this if you try to add a content database from 1) a different version of SQL Server, and sometimes 2) when you restore a content database ad add it to a web application with a different name than the original web application. But neither was the case here.

I worked through this exercise 4 or 5 times - thinking surely something simple is being overlooked.

Finally, I fire up another staging server - completely different setup - and start to work on this virtual machine. I see the same exact behavior!!!

Time for a coffee refill. Definitely weird. I had already built out 4 virtual machines and worked through this exercise for 3 days - nothing at all was different. Or so I thought.

Coming back from my cafine fix - I fire up Central Admin and notice right away something strange next to the serverName on the Home tab - there was no WSS service running. MMmmm - I built this out from scratch, setup MOSS, Central Admin site, services, etc. - and saved the staged image - simply to re-use several times. How did the WSS get stopped? Well, that is another issue - but when I started the WSS service - all worked perfectly - just like it should.

 

As an exercise - I stopped the WSS and stepped through the same things I was doing earlier - and sure enough, you can create a web application - and it does not log an iota of an issue - and all appears to be fine - except it never gets created.The really frustrating part is that no error gets logged stating something like, 'Hey dummy, you might want to start WSS before you try this', or 'ID10T to the max' - you know what I mean.

After successfully upgrading MOSS B2TR to RTM (or thinking all was successful) - I started to see this error in the Application Event Log - every 60 seconds. It was preceded by:

The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition - threw an exception. More information is included below.

The device is not ready.

Like many of you before me - and very likely after me, I Googled to my heart's content - and suffice to say my heart was never satisified.

I'd kept a collective 94MB document of each painfully executed step of the upgrade.

1.    The B2TR deployment was pretty much out of the box (OOB)
2.    A single SSP (shared service provider) had been created, leaving the default name SharedServices1 in place, and 2 search scopes created.
3.    I drilled on this for quite some time - invariably finding that a) I was on my own, and b) strangely enough, the RTM upgrade went very well - but hosed the permissions of my search scope? Not entirely - just the permissions of the service account!!! Very interesting.

The error is representative of not being able to create a search index because the scope it is looking for - it cannot get to, or more specifically, it thinks is busy and so it keeps coming back trying to get at it.

Solution / or not? Not finding any meat/potatoes online, I tried the following:

1. stsadm -o osearch -action stop
   1. Warning: The Office SharePoint Server Search service that was enabled on this server will uninstall and all index files for all SSPs will be deleted. Are you sure you want to permanently delete all data in the index for all SSPs? [y/n]
2. NOTE: Only do this if you have not crawled / indexed content that cannot be re-indexed. If this is the case, then you open a support ticket with MSFT and work through it. Otherwise, hit Y
3. Now issue: stsadm -o osearch -action start -role index
   1. You may receive the errror 'start' action failed. Additional information: the handle is invalid. Wait 30-60 secs and re-issue the command. It should go through fine.
4. Open Central Admin - select your SSP
5. Check / validate your search service configuration.

After all of this - and all looking fine, normal, just dandy! I continued to see errors regarding the 'device' that was not ready for a search indexing service run. Interesting.

Finding nothing else online and getting no immediate feedback - I took the plunge.

1) Within the Central Admin - I stopped both search service/server processes.

2) I re-created these - basically using the same service account as before.

3) When to the event log and validated that all is now operating normally.

Invariably, what I found is that my service account simply did not have permission to run the job any longer. I did not have to re-create a service account - I simply stopped (essentially terminating and deleting existing indexes in my search database), and re-created the search database.

 Please feel free to share your experience in this area - if / when you hit it.

You may see this error - more than once - when working with your Microsoft Office SharePoint Server (MOSS) 2007 deployment. This animal / error generally shows itself after you have applied an upgrade to an existing deployment. For example, when upgrading from B2 MOSS to B2TR MOSS - or when applying a special service pack from MSFT - you may begin to see a lot of these errors pop up in the SYSTEM event log.

The error CLSID is followed by a class ID for the DCOM+ application that the service account trying to activate that application - does NOT have permission to activate.

For example, let's say I installed MOSS on a server, and used the account mossService as the service account (a least privileged, user account you created to run the MOSS service(s))., when I get this error, I could very well see an error like the following:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{61738644-F196-11D0-9953-00C04FD919C1}

to the user <serverName>\mossService SID (S-1-5-21-<serviceSID>). This security permission can be modified using the Component Services administrative tool.

Copy the GUID following the CLSID above, and Start-->Run-->regedit

With the registry editor open, ensure that your cursor is on the computer at the beginning of the tree (make sure you are not in the middle of some previous edit session in the registry editor).

Edit-->Find and paste in the GUID. It'll stop at the application entry - and you will want to note the application name on the right side pane. In this example, it was the IIS WAMREG admin service that popped up.

Now, open Component Services (typically, from the server - Start-->Administrative Tools-->Component Services), expand Component Services, Computers, My Computer, DCOM Config. Scroll down and find the application (IIS WAMREG in this case). Right-Click-->Properties and select the Security tab. You'll have some options here - the first block Launch and Activation Permissions - ensure that the Customize radio button is selected, and click Edit. Now, add your service account - giving it launch and activate - and in some requirements - remote launch / activate permission.

Restart IIS and continue on.

NOTE: This is not applicable to MOSS setups only - and hopefully this will help someone else that sees these annoying DCOM errors in their SYSTEM event log.

Regards...

Just an FYI...

As you forge ahead into the world of MOSS and deploying / configuring MOSS sites with actual service accounts - you may very well run into this error. The PRIMARY cause of this error has to do with the service account. When you created the service account, you set a password for it. Did you document that with your client? If you did not, it is very possible that someone in IT at the client site will change it to something THEY know and want to manage. Alas, all things SharePoint begin to fail - at least for those application pools that were using the service account.

NOTE: Service account - a least privileged user account you created to run the MOSS Central Admin and varying AppPools.

HTH's...

I have been reviewing and generally beating away at Office Live Beta, and working with the Essentials package, I am moderately impressed with where MSFT is going here. During the beta the Essentials package was the Premium package - alas - things have changed.

 

Rolling out of Beta they will be charging for a monthly service fee - and I'm going to continue the venture for the next year. You can review our initial setup at MSFT Blogs.

 

After reading through all of their marketing about what Office Live has to offer, I wanted to share some key things that include:

 

Most of us use Live Spaces for what it is - a fantastic free service!!! HOWEVER - Freedom does come wtih some costs

 

I have blogged for roughly 18 months with GeeksWithBlogs as MHamilton - and there I have never run into a resource or space issues. Here however, I cannot post most of my entries - so you will frequently see a link reference to the complete articile - if in fact, the article is too long for Live Spaces Blog.

 

Regards...

I recently had the unexpected pleasure of losing my IIS Admin server - altogether!!! Translate - 150% !!!

Now, before this - everything was going great - except. During an upgrade of MOSS (Microsoft Office SharePoint Server) I encounted an issue that forced me to restore a VPC image - essentially bringing over another copy of the VHD and firing the server back up.

Interstingly, during that reboot - which for all intents should have gone fine - I see a hoard of DSKCHK processes running. Invariably, something got out of wack on the NTFS volumn between my shutting the image down and bringing it back up. During the 'fixing' process - a number of files invaribly can become corrupt - and the Metabase.xml - the blood-life of your IIS Admin service - is no exception. SO

Check in C:\Windows\System32\Inetsrv and you'll find a 'History' folder. Within here - hopefully - you'll find fairly recent backups of the Metabase.XML and MBSchema.XML objects. Before doing the following - be sure to backup the existing Metabase.xml and MBSchema.xml from C:\Windows\System32\Inetsrv first.

Now, rename a recent backup from the 'History' folder - renaming a recently Metabase.XML object, and then a recent MBSchema.XML object. Copy / Paste each of these to the C:\Windows\System32\Inetsrv.

Ahh, not quite done.

Now do a IISRESET from a command prompt.

Hopefully this will get you back to where you need to be.