SharePoint Execute Method Exception (Event ID 6398)

I spent some time today troubleshooting an alert that we received in Operations Manager 2007 from one of the client SharePoint servers that we manage in our Operations Center.  The alert referenced Event ID 6398 which indicates that the execute method of a SharePoint timer job definition had thrown an exception.  I logged onto the client SharePoint server and looked in the Application event log and, sure enough, it was full of the following 6398 event:

Event Type:    Error
Event Source:    Windows SharePoint Services 3
Event Category:    Timer
Event ID:    6398
Date:        11/19/2008
Time:        1:05:53 PM
User:        N/A
Computer:    <ServerName>
Description:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 03d6f1b3-879c-42d9-8921-3f14b9e5678f) threw an exception. More information is included below.

Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.

The System event log contained numerous instances of the following DCOM error as well:

Event Type:    Error
Event Source:    DCOM
Event Category:    None
Event ID:    10016
Date:        11/19/2008
Time:        1:06:26 PM
User:        NT AUTHORITY\NETWORK SERVICE
Computer:    ATI-SHAREPOINT
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{3D42CCB1-4665-4620-92A3-478F47389230}
to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool.

This problem can be resolved by accessing the Component Services applet by way of Start > Administrative Tools > Component Services.  In the task pane expand Component Services, expand Computers, and expand My Computer, and click on DCOM Config.

In the details pane on right, locate and right-click on the OSearch application and select Properties from the menu.  On the OSearch Properties dialog box, click on the Security tab.  In the Launch and Activation Permissions section, select the Customize option and then click the Edit button.

OSearch Launch Permissions

On the Launch Permissions dialog box, add the NETWORK SERVICE user and grant it Local Launch and Local Activation permissions as shown above.  Click the OK button twice and then close the Component Services applet.  You should now have a much quieter and happier event log!

Performance Issues & TCP Chimney

I was recently troubleshooting a performance issue on one of the servers we manage and I came across a posting on Greg Galipeau’s Weblog that covered problems that a couple of network adapters have with TCP Chimney.  TCP Chimney is a concept introduced with Service Pack 2 for Windows Server 2003 and is supposed to increase a server’s performance.  However, two network adapters have a known issue with TCP Chimney:

• BroadCom NetXtreme II
• Hewlett-Packard NC373i Multifunction Gigabit Server Adapter

As it turned out, the server I was troubleshooting had the HP adapter installed so I followed Greg’s instructions, which are outlined below:

1. Disable TCP Chimney from a command prompt by typing Netsh int ip set chimney DISABLED
2. Make a few registry changes to make sure that performance is not hindered by disabling TCP Chimney.  Click Start, click Run, type regedit in the textbox, and then click the OK button.
3. Locate the following registry subkey:  HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
4. Double-click the EnableTCPChimney registry entry.
5. In the Edit DWORD Value dialog box, type 0 in the Value data textbox and then click OK.
6. Double-click the EnableRSS registry entry.
7. In the Edit DWORD Value dialog box, type 0 in the Value data textbox and then click OK.
8. Double-click the EnableTCPA registry entry.
9. In the Edit DWORD Value dialog box, type 0 in the Value data textbox and then click OK.
10. Restart the server.

For additional information regarding TCP Chimney issues, please review Microsoft Knowledge Base article 942861.

How to Rename a SharePoint Site with STSADM

Today I woke up and decided that I did not like the URLs that I had given the site collections in the demonstration portals that I referenced in yesterdays post.  Unfortunately, there is no option to right-click and rename a site but the STSADM utility makes the process quite painless.

1. On the SharePoint server, open a command prompt by selecting Start > Run and typing cmd in the textbox.  Click the OK button.
2. Navigate to the directory that contains the utility by typing cd %systemdrive%\program files\common files\microsoft shared\web server extensions\12\bin at the command prompt and pressing [Enter].
3. Now the original site can be backed up by typing stsadm -o backup -url http://server/sites/site1 -overwrite -filename %systemdrive%\backup.dat at the command prompt and pressing [Enter]. Replace server and site1 as appropriate for your environment.
4. If you are restoring the site to the same virtual server, you must first deleted the original site because the globally-unique identifiers (GUIDs) for SharePoint lists are preserved in the backup file.  The SharePoint content database requires that all list GUIDs be unique.  Delete the original site by typing stsadm -o deletesite -url http://server/sites/site1 at the command prompt and pressing [Enter].   Replace server and site1 as appropriate for your environment.
5. Now the site can be restored to its new site name by typing stsadm -o restore -url http://server/sites/site2 -filename %systemdrive%\backup.dat at the command prompt and pressing [Enter].  Replace server and site2 as appropriate for your environment.

Now your SharePoint site has been fully restored into a new site collection with a new name!

Shared Services Provider Provisioning

Today I began creating a MOSS 2007 portal for our sales team to use for demonstration purposes.  I installed MOSS and created the Web application in SharePoint Central Administration.  The next step involved creating the Shared Services Provider (SSP) for the Web application.  When I clicked the OK button to create the SSP, MOSS began provisioning the SSP, displaying a status of “Provisioning in progress”.  Having created a few portals with MOSS 2007, I quickly realized that the provisioning process was not going anywhere.

I began troubleshooting by searching the Internet with Google.  I came across a post on Serve’s SharePoint Blog that described my problem exactly.  He resolved his problem by starting the Windows SharePoint Service Timer service which had stopped for some unknown reason.  I opened the Services applet on my server and, sure enough, the WSS Timer service was not running.  I tried to start it but it failed to start due to a logon failure.  I reset the logon credentials and the service start successfully.  Within a few minutes, my Shared Services Provider had been provisioned and I was able to proceed.

SharePoint Portal Server Uninstall Error

So you try to uninstall SharePoint Portal Server using the Add/Remove Programs applet but receive the following error:

Application has generated an exception that cannot be handled.
Process id=0xb60 (2912), Thread id=0×1dc (476)
Click OK to terminate the application.
Click CANCEL to debug the application.

This error occurs if you do not uninstall SharePoint Portal Server and Windows SharePoint Services in the correct order.  SPS must be uninstalled prior to uninstalling WSS.  Also, if it is installed on the server, Microsoft SQL Server Desktop Engine (MSDE) must be removed last.

I encountered this problem today while trying to remove an old SharePoint installation from one of our servers.  Someone had previously uninstalled WSS so my attempt to uninstall SPS failed.  I did a little research and found a Microsoft Knowledge Base article that provided the following workaround:

1. Log onto the server as a member of the local Administrators group.
2. Click Start, and then click Run.
3. In the Open box, type cmd, and then click OK.
4. Switch to the drive where SharePoint Portal Server is installed.
5. Type the following line, where CDImage is the path of the shared folder that contains the SharePoint Portal Server CD files, and then press Enter:

   msiexec /qb /i <CDImage>\WSS\Sts.msi /L*v <full path>\STS_Install.log LAUNCHEDFROMSETUPSTS=1

6. Switch to the drive where Windows is installed.
7. Type the following line, and then press Enter:

   cd %programfiles%\Common Files\Microsoft Shared\Web Server Extensions\60\Config
   

8. Type the following line, and then press Enter:

   copy Web.config Web.config.bak

9. Type the following line, where CDImage is the path of the shared folder that contains the SharePoint Portal Server CD files, and then press Enter:

   msiexec /qb /I <CDImage>\SPS\Sps.msi /L*v <full path>|SPS_Binary_Upgrade.log REBOOT=ReallySuppress

10. Type the following line, where CDImage is the path of the shared folder that contains the SharePoint Portal Server files, and then press Enter:

    msiexec /qb /fvm <CDImage>\SPS\Sps.msi /L*v <full path>\SPS_Repair.log REBOOT=ReallySuppress DONTSTARTSERVICE=1

11. When Setup completes and you are prompted to restart the server, click No.
12. Use the Add/Remove Programs applet to remove, in this exact order, SharePoint Portal Server, Windows SharePoint Services, and MSDE (if installed).

SharePoint Single Sign-On Blues

I am in St. Louis, MO this week attending a Microsoft Office SharePoint Server 2007 Technology Specialist bootcamp.  One of the topics that I had hoped would be covered in some detail is Single Sign-On (SSO), which has caused me a great deal of frustration in our SharePoint Portal Server 2003 implementation at work.  Unfortunately, SSO was barely mentioned in today’s session.  You gotta love Microsoft Official Course material!

During our lunch break I stayed in the classroom and attempted to configure SSO on the virtual PC used for my class labs.  By the way, no lab in the curriculum dealt with SSO.  I received the same error that I have received previously in SPS 2003 – You do not have permission to perform the operation.  I was logged in with a Domain Admin account which, by the way, I had used to install MOSS – what more permissions should I need!!

I did a quick search of the error on the Internet and came across a blog, Grossmann IT GmbH, created by Frank Grossmann, which offered a solution.  The GUI in SharePoint Central Administration says, in the Account name box, type the name of the group or user account that can set up and manage the single sign-on service. This account must be a member of the same domain to which the single sign-on service account belongs.  If you do this, you receive the permissions error.  Frank’s solution is to use the service account you created for the Microsoft SSO service to log on to the machine (which normally is not recommended), access the SharePoint Central Administration website and enter the account. 

I tried this method and was able to create the Single Sign-On Administrator account successfully.  This is as far as I have gotten with SSO configuration and Microsoft Office SharePoint 2oo7 but will post the final results soon (hopefully).