Issues after restoring MOSS to a previous VM snapshot

We restored our VM MOSS farm this morning from a snapshot taken a couple of months ago. Various issues occurred. Please note i am still working through some of the errors and will update this post as i find the answers.

1. I could no longer login to the server because the snapshot was older than 30 days - the computer account for the server had expired and so needed to be reset and reconnected to the domain. See this blog for steps to fix this.
   
2. The MOSS environment although appearing correct in Central Administration was not configured in IIS. The Central Administration site was the only site appearing in IIS even though all the web applications were still there.
   
   To fix this:


1. Delete the old web application using Central Administration.
2. Delete all the SSP web apps & DBs, apart from the default SSP which cannot be deleted.
3. Recreate the web applications with Temp DB names.
4. Recreate the SSPs with new DBs.
5. Change the default SSP to one of the newly created SSPs, then delete the original default SSP inc DB, then recreate it's web app and set back to the default updating any associations as required.
   
   At this point I ran in to some issues recreating the SSP with the following errors. First of all the SSP failed to provision with the error:
   
   Provisioning failed: A transport-level error has occurred when sending the request to the server.
   
   Looking in the Event Log i found the following related errors:
   
   Event ID 5554
   Failure during sweep synch. Exception was A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.).
   
   Event ID 7888
   A runtime exception was detected. Details follow.
   Message: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
   
   Event ID 5586
   Unknown SQL Exception 10054 occured. Additional error information from SQL Server is included below.
   
   A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
   
   Solution:
   http://social.msdn.microsoft.com/forums/en-US/sqldatabaseengine/thread/0671c03b-5488-4be4-bc5a-579849fa0950
   Reboot the server and kill any remaining connections (delete the Admin accounts from local users & groups, reboot, add the Admin accounts back in).
   
   Also in the event log were the following errors:
   
   Event ID 10016
   The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
   {3D42CCB1-4665-4620-92A3-478F47389230}
   
   Solution:
   http://sharemypoint.wordpress.com/2007/12/18/error-event-id-6398-and-6482-about-security-rights-of-osearch-service/
   Add the WSS_WPG, WSS_ADMIN_WPG, Search & Admin accounts to the OSearch DCOM Service
   
   Event ID 6141
   The site /ssp/admin could not be created. The following exception occured: This page has encountered a critical error. Contact your system administrator if this problem persists.
   
   Event ID 6610
   Safe mode did not start successfully. This page has encountered a critical error. Contact your system administrator if this problem persists.
   
   Event ID 5629
   Failed to load the SafeControl assembly paths for web.config. C:\Inetpub\wwwroot\wss\VirtualDirectories\ssp180
   
   Error importing WebPart. Assembly Microsoft.Office.Server.Search, Version=OAssemblyAssemblyVer, Culture=neutral, PublicKeyToken=OAssemblyPublicKey, TypeName. Microsoft.Office.Server.Search.WebControls.ActiveCrawls
   
   
1. I deleted the SSP web apps again.
   
2. Stop the search query & index services.
3. Start the search query & index services.
4. Restart IIS.
5. Recreate the SSP web app.
6. Recreate the SSP & set back to default with any associations required.
   
   Success - the SSP provisioned correctly.
   
   
1. Restore the DB from by opening the Content Database page in Central Administration. Delete the Temp DB then in STSADM associate the original DB:
   
   cd C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
   
   stsadm.exe -o addcontentdb -url http://portal -databasename MOSS_MyDB_WSS_Content -databaseserver MyServer
   
   
3. If you receive the error 'An unexpected error has occured' open the web.config and update as follows:
   http://blog.thekid.me.uk/archive/2007/02/15/a-solution-to-quot-an-unexpected-error-has-occurred-quot-in-wss-v3.aspx
   
1. Change <SafeMode MaxControls=“200“ CallStack=“false“ to <SafeMode MaxControls=“200“ CallStack=“true“…>
2. Set custom errors to 'Off' <customErrors mode=“Off“/>

Event ID 0 - The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found

The Problem:

Event ID 0

The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Unable to open shim database version registry key - v2.0.50727.00000.

The Solution:

KB918642 - A .NET 2.0 application may require Read/Write permission to a registry

Download the hotfix and apply to the server displaying the error - in my case this was the Index server.

Event ID 7888

The Problem:

I found the following error on my Index Server:

Event ID 7888

A runtime exception was detected. Details follow.
Message: Access Denied! Only site admin can access Data Source object from user profile DB.

Techinal Details:
System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.
at Microsoft.Office.Server.UserProfiles.SRPSite.
AdminCheck(String message)
at Microsoft.Office.Server.UserProfiles.DataSource.
_LoadDataSourceDef(IDataRecord rec)
at Microsoft.Office.Server.UserProfiles.DataSource.
_LoadDataSourceDef(String strDSName)
at Microsoft.Office.Server.UserProfiles.
DataSource..ctor(SRPSite site, Boolean fAllowEveryoneRead)
at Microsoft.Office.Server.UserProfiles.
DataSource..ctor(SRPSite site)
at Microsoft.Office.Server.UserProfiles.
UserProfileConfigManager.GetDataSource()
at Microsoft.Office.Server.UserProfiles.
BDCConnector.RefreshConfiguration(String sspName)

The Solution:

1. Open your SSP and navigate to Personalization Services Permissions.
   
2. Select Add User and add your SSP process account with Manage User Profiles permissions.
   
   

Changing MOSS service accounts & passwords

I have been preparing some servers for a bunch of testing with PerformancePoint Server (more to follow on this later) which required me to change our MOSS service accounts. Reading around the steps to update these credentials appeared pretty straight forward but as usual MOSS' idiosyncrasies were all to apparent. Here's what i did and how i managed to solve the issues that arose. Hope it helps someone else with the same challenge.

The accounts to be changed were as follows:

1. old_moss_admin ----> new_moss_admin
2. old_ssp_ap ---->new_ssp_ap
3. old_ap1_process ---->new_ap1_process

I followed the following MS KB instructions: 'How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0'

1. MOSS Admin Account Update

To update the account old_moss_admin to new_moss_admin:

1. Update the password for the account that is used by the Central Administration application pool. To do this, follow these steps:


1. On all servers in the server farm, open a command prompt, type the following line, and then press ENTER:
   cd %commonprogramfiles%\Microsoft Shared\Web server extensions\12\Bin


2. On the server that hosts the Central Administration Web site, type the following line at the command prompt, and then press ENTER:
   stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword


3. On all other servers in the server farm, type the following line at the command prompt, and then press ENTER:
   stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword -local


4. Restart Microsoft Internet Information Services (IIS) 6.0. To do this, type the following line at the command prompt, and then press ENTER:
   iisreset /noforce


2. Verify that the Administration Application Pool Credential Deployment job definition is no longer displayed on the Timer Job Definitions page of SharePoint 3.0 Central Administration. To do this, follow these steps:


1. Open SharePoint 3.0 Central Administration, click Operations, and then click Timer job definitions under Global Configuration.


2. Verify that the Administration Application Pool Credential Deployment job definition is no longer displayed in the list.

Error: My Central Administration is now no longer available with the error: 'Service Unavailable'

• I checked & retyped the password in CA web app pool.
• I checked the WSS_WPG, WSS_RESTRICTED_WPG and WSS_ADMIN_WPG local groups on each of the servers - all seemed to be up to date.
• Restarting the CA web app pool makes no difference.

At this point i rolled back to the previous credentials. I then tried again from the start following the same steps above. Result - my Central Administration was still unavailable with the error: 'Service Unavailable'

• I checked the IIS_WPG local group on each server. The new_moss_admin account was not updated so i added it to the group.

I then discovered a couple of DCOM errors in the System Event viewer.

1. I updated the new CA account 'new_moss_admin' to:


• IIS Admin Service
• IIS WAMREG Admin Service


2. Restarted IIS.

Success: Central Admin is up and running again.

2. SSP Account Update

To update the SSP account old_ssp_ap to new_ssp_ap:

Attempt 1 - The wrong way...

1. Open Central Administration
2. Navigate to the Operations page
3. Select Service Accounts
4. Select the radio button Web app pool
5. Select the web service - WSS Web App
6. Select the App Pool - SSP1
7. Select the radio button Configurable
8. Input the new credentials
9. Ok
10. Restarted IIS on both my servers

Error: This had no effect other than stopping me from accessing the SSP. Checking in IIS the account was not updated to the new credentials. I then tried to update the accout via IIS but this had noeffect either and on opening the App Pool properties again i discovered that the account credentials had changed themselves back to the old account.

Attempt 2 - The right way...

I then tried a different approach:

1. Open Central Administration
2. Navigate to the Shared Services Aministration homepage
3. Hover over SSP1's title and select Edit Properties from the drop down.
4. Scroll down to SSP Server Credentials
5. Delete the old credentials and input the new account username & password
6. Ok
7. I then changed the SSP to be the default SSP.
8. Open Compnent Services and update the DCOM services IIS Admin & IIS WAMREG with the new account.
   
9. Restarted IIS on both my servers.

Checking IIS the account was still not updated to the new credentials and i still could not access the SSP website.

Success: 10 minutes later having searched on Google again and felt thoroughly annoyed at there being no pages I hadn't yet read on this topic I checked the SSP website again and it worked! Checking IIS the accounts have now updated to the new credentials.

At this stage I discovered some new errors in the Event View

1. Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (5d77cabf-3414-40cc-a5ef-f30226a9288b).
   
   Reason: The program attempted to update an object that was updated by another user.
   
   
2. Eventid 6482 - Reason: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied.
   
   This error was now occuring every minute.
   
   The solution to this (and the previous error) can be found in my previous post here: http://bytelab.blogspot.com/2008/02/sharepoint-search-service-cannot-find.html
   

3. Application Pool Process Accout Update

To update the web app pool process account old_ap1_process to new_ap1_process:

1. Open Central Administration
2. Navigate to the Operations page
3. Select Service Accounts
4. Select the radio button Web app pool
5. Select the web service - WSS Web App
6. Select the App Pool - MOSS Portal
7. Select the radio button Configurable
8. Input the new credentials
9. Ok
10. Open Compnent Services and update the DCOM services IIS Admin & IIS WAMREG with the new account.
11. Restarted IIS on both my servers

Success: All updated and working ok.

************************************************************

Useful web sites i visited for this:

• Change passwords for Central Administration and Timer service (Windows SharePoint Services) http://technet.microsoft.com/en-us/library/cc288991.aspx
• How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0 http://support.microsoft.com/kb/934838
• MOSS 2007 Setup Accounts Clayton J http://claytonj.wordpress.com/2007/04/23/moss-2007-setup-accounts/
• How to change service accounts and their passwords in MOSS and WSS 3.0 http://weblogs.asp.net/erobillard/archive/2007/07/06/how-to-change-service-accounts-and-their-passwords-in-moss-and-wss-3-0.aspx
  

SSP Stuck on Unprovisioning

I tried to delete a test SSP the other day via Central Administration. Having selected the options to also delete associated content databases and web applications i hit ok and left it to run. The SSP status changed to 'Unprovisioning' and an hour later was still stuck.

I then followed this example in the hope the SSP would delete.

• http://prequest01.wordpress.com/2008/08/16/unable-to-delete-shared-services/
  
  
1. Tried: stsadm -o deletessp "TestSSP" –force, but this did not work
   
2. Login to SQL server.
   
3. Open SQL Management Studio and expend Databases.
   
4. Expand Configuration Database & Tables.
   
5. Opened table for dbo.object.
   
6. Executed following query in query analyzer: SELECT * FROM [MOSS_CFG_CA_01].[dbo].[Objects]where name like ‘Name of the Shared Services’.
7. Copy the ID of object referenced in objects table of configuration database.
   
8. Open command prompt and changed directory to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN> and executed following command to delete the Shared Services using the ID which was copied: Stsadm -o deleteconfigurationobject -id “id retrieved from object table”

• To clean up we decide to delete the DBs via SQL Management Studio and delete the web applications via Central Administration.

A week later I discovered that one of our servers had rebooted itself with the following log (don't yet know if this is related):

System Failure: Stop error
Reason Code: 0x805000f
Bug ID:
Bugcheck String: 0x000000c5 (0x00000004, 0xd0000002, 0x00000001, 0x8089bce3)
Comment: 0x000000c5 (0x00000004, 0xd0000002, 0x00000001, 0x8089bce3)

I then discovered that the search was no longer working. Submiting a query returned the following error:

Cannot connect to the search service

The status of the test SSP i had tried to delete was still stuck on 'Unprovisioning'. Also the other SSPs 'Edit Properties' pages in Central Administration were no longer available and returned the following error:

An unhandled exception occurred in the user interface.Exception Information: Cannot open database "xxx" requested by the login. The login failed. Login failed for user 'xxx'.

In the event log on the server I found multiple instances of the following error:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (e6a1ecb4-3aa8-45cd-a179-d7e053aa927a).

Reason: Cannot open database "xxx" requested by the login. The login failed.
Login failed for user 'xxx'.

Solution:

1. Restart the Office SharePoint Server Search service in via the Computer Management console - Search still not working.
2. I retried the STSADM CMD
   stsadm -o deletessp "TestSSP" –force

Operation was successful this time and the SSP has now gone. The event log is now clear of all errors and the unavailable pages in Central Administration are now available again.

MOSS Search Broken

MSS search has been broken for a few weeks now. One of the issues with the fault has been that MOSS had stopped writing to the error logs so we had no way of finding specific error inforation. I logged a call with Microsoft because of this and they suggested that i recreate the SSPs as they must be coorupt.

I tested this by creatiing a new SSP and true enough it did allow search queries and returned results. But, recreating our SSPs is no small job because once you do so you have to recreate all your customisations as well. This means redeploying custom webparts and setting them up on your sites. Recreateing audiences and resetting targeted content on the sites, etc etc. Depending on your set up this can take quite an effort.

Before heading down the last resort of recreating the SSPs i decided to try and solve the issues first. For info I am running a standard installation with 3 servers:

• MOSS01 - Index
• MOSS02 - WFE
• MOSS03 - Query & Central Admin

Take note that it took a weekend of digging around and trying the same steps over and over again to finally fix everything. There's a list of the errors and how to fix them at the bottom of this post. I have tried to put the main steps that i followed into order below - i hope this helps someone...

******************************************************

Attempt 1

1. Reboot Index server
2. Reboot Query server
   
3. Propagate the Index file to a new location using STSADM
   stsadm -o osearch -propagationlocation

Result: Index moved to new location sucessfully. Search not working.

Attempt 2

1. Start the Indexing service on the MOSS Index server using Computer Management / Services
   
2. Stop the Search Services (Index & Query) using STSADM
   stsadm -o osearch -action stop
3. Start the Search Services (Index & Query) using STSADM
   stsadm -o osearch -action start

Result: Search not working.

Attempt 3

1. Reset the Indexer in each SSP to the Index server via Central Admin SSP Proerties page
2. Add the process accounts to each SSP on the Edit Properties page - http://ssp/admin/_layouts/searchsspsettings.aspx
3. Set the security for C:\Windows\Tasks to read & write for the WSS_WPG account:
1. On the Index server make sure that you can see the Sharing and Security tab in the Windows tasks folder (usually C:\Windows\Tasks) by open a command prompt and type attrib –s %windir% \tasks.
2. Browse to C:\Windows\Tasks in explorer, right click and select properties. Grant the WSS_WPG group Read and Write permissions on the tasks folder.
3. Open a command prompt and type attrib +s %windir% \tasks to reset the tasks folder to its default view.
4. Delete the content index in each SSP
5. Start a full crawl in each SSP

Result: Search now returning results correctly in 2/4 SSPs. MOSS event logs are now populating.

• SSP1 status - Propagating to new Query server. Search index status 'Computing ranking'. Search not working. When I manually started a crawl, there's a pop up message saying 'Crawling might be paused because a backup or an index move operation is in progress. Are you sure you want to resume this crawl?' Selected 'Yes'.
  
• SSP2 status - Propagating to new Query server - Search not working
• SSP3 status - Propagating - Search is working
• SSP4 status - Idle - Search is working
  

Attempt 4

1. Reboot Index & Query servers
   
2. Stop the Search Services (Index & Query) using Central Administration
   
3. Recreate the Search Services (Index & Query) using Central Administration
   
4. Reset the Indexer in each SSP to the Index server
5. Set the security for C:\Windows\Tasks to read & write for the WSS_WPG account
6. Reset the content index in each SSP
7. Start a full crawl in each SSP

Result: Search working in all SSPs.

One remaining error in the event log is now: Tracing Service failed to create the trace log file directory 'D:\MOSS\12\LOGS'. Error 3: The system cannot find the path specified.

******************************************************

General Error List

Some of the errors i have worked through are listed here:

• Your search cannot be completed because of a service error. Try your search again or contact your administrator for more information
• Reassociating the indexer and search service with the ssp under application management on the central administration site
  
• Content index on Portal_Content could not be initialized. Error The content index is corrupt.
• Query server not responding
• http://brijesh.spaces.live.com/blog/cns!BFBD772FBDA58C6D!194.entry
1. stsadm.exe –o osearch –propagationlocation index file path
2. Run a full crawl
   
• Could not create a database session
• http://social.technet.microsoft.com/Forums/en-US/sharepointsearch/thread/e277cc4f-03d9-4424-af1a-a167fd3c6186/
1. Open Central Admin
2. In the Application Tab go to Create or Manage this farm's shared services
3. Click the drop down of the SSP you want to edit, and click edit
4. Add the Indexing server
• Error trying to access the SSP search settings page: http://ssp/admin/_layouts/searchsspsettings.aspx - 403 FORBIDDEN
  
• See next solution below http://support.microsoft.com/kb/926959
• Error when you try to edit the content source schedule in Microsoft Office SharePoint Server 2007: "Access is denied"
• http://support.microsoft.com/kb/926959
  To work around this issue, you must add the WSS_WPG group to the Tasks folder. To do this, follow these steps:
1. Use an account that has administrative permissions to log on to the computer that is running the Office SharePoint Server 2007 indexing service.
2. Click Start, click Run, type cmd, and then click OK.
3. At the command prompt, type the following command, and then press ENTER:
   attrib –s %windir%\tasks
   Note In this example, %windir% is the path of the Windows folder. For example, the path can be C:\Windows.
   Note If Windows Explorer is open when you make this change, you will not see the extra tab in Windows Explorer. If Windows Explorer is already open, close and then reopen it before you perform step 4.
4. In Windows Explorer, right-click the Tasks folder, and then click Properties.
5. In the Tasks Properties dialog box, click the Security tab, and then click Add
6. In the Select Users, Computers, or Groups dialog box, type WSS_WPG in the Enter object names to select box, and then click OK.
7. Grant the following permissions for the WSS_WPG account, and then click OK: Read & Write
8. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
9. In Internet Information Services (IIS) Manager, right-click ComputerName (local computer), click All Tasks, and then click Restart IIS.
10. Click Start, click Run, type cmd, and then click OK.
11. At the command prompt, type the following command, and then press ENTER:
    attrib +s %windir%\tasks
    Note This resets the Tasks Property back to the default view.
    
• The search service is currently offline. Visit the Services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress.
• http://www.sharepointblogs.com/jasonmedero/archive/2008/09/15/moss-2007-error-when-moving-indexing-role-the-search-service-is-currently-offline-visit-the-services-on-server-page.aspx
1. Stop and start search services on new index server and all servers running the query role
2. Then restarted the search service via central administration under operations tab>>Services
3. Went into Services.msc and found the Office Search Service and restarted it manually
4. Checked to make sure that the search service account had correct rights to SQL.
• None of the above worked so...
  
1. Going into the SSP settings (clicking on SSP administration not the SSP link itself) within the left quick launch navigation from within central administration.
2. Selecting the dropdown arrow next to the SSP where I was having the search issue
3. Select edit properties
4. Within the properties screen of the SSP look for the “Process accounts”
5. Make sure that your search account is in there!
   
• Test Shared Service Provider stuck on 'Unprovisioning' after trying to delete it and associated databases.
• http://www.synergyonline.com/blog/blog-moss/Lists/Posts/Post.aspx?ID=19
• Tried: stsadm -o deletessp –force, but this did not work
  
• http://prequest01.wordpress.com/2008/08/16/unable-to-delete-shared-services/
1. Login to SQL server.
   
2. Open SQL Management Studio and expend Databases.
   
3. Expand Configuration Database & Tables.
   
4. Opened table for dbo.object.
   
5. Executed following query in query analyzer: SELECT * FROM [MOSS_CFG_CA_01].[dbo].[Objects]where name like ‘Name of the Shared Services’.
6. Copy the ID of object referenced in objects table of configuration database.
   
7. Open command prompt and changed directory to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN> and executed following command to delete the Shared Services using the ID which was copied: Stsadm -o deleteconfigurationobject -id “id retrieved from object table”
• The search request was unable to connect to the Search Service
• http://anuraj.wordpress.com/2007/10/25/the-search-request-was-unable-to-connect-to-the-search-service/
1. Start the Indexing service, which is disabled by default.
2. Go to Services from Control Panel > Administrative Tools > Services
   
3. Select the Indexing service, right click and choose the option start

SharePoint RSS Viewer Error

Having added the SharePoint OOB RSS web part on to my site and configured it to point to a feed i received the following error in the log:

RssWebPart: Exception handed to HandleRuntimeException.HandleException System.Net.WebException: Unable to connect to the remote server

Found the solution here: http://yasirbutt.spaces.live.com/blog/cns!A8677D5751E6B4DA!1409.entry

The following needs adding to the site web.config file (at the bottom of the file):

<system.net>
<defaultProxy>
<proxy usesystemdefault = "false" proxyaddress="http://proxyservername" bypassonlocal="true" />
</defaultProxy>
</system.net>

SharePoint Search Service cannot find hosts file

I have been trying out various scenarios on a dev farm consisting of 2 SharePoint servers and a SQL box to see what happens...

If you start mucking around with search services and stop or change your search index server you may come accross the following error:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance Reason: Could not find file 'C:\WINDOWS\system32\drivers\etc\HOSTS'.

This is because the Sharepoint Timer job deletes the hosts file after you modify the web front end the crawler is pointed to. I created a new hosts file in 'C:\WINDOWS\system32\drivers\etc\' and then came across the next error:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance Reason: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied.

To solve this update the permissions on the 'C:\WINDOWS\system32\drivers\etc' directory for the WSS_Admin_WPG account allowing the following advanced permissions:

• Traverse Folder / Execute File
• List Folder / Read Data
• Read Attributes
• Read Extended Attributes
• Create Files / Write Data
• Read Permissions
• Delete Permissions

The delete permission also needs to be given because the timer job actually deletes and recreates the hosts file.

Duplicate Site ID Error in the Application Event Log

After rebuilding our farm environment onto a new server with SP1 we started receiving these errors on the hour every hour. It relates to a database that was renamed and thus disassocoated with its web application, then reassociated with it using STSADM -addcontentdb.

Failure trying to synch web application d9ba0571-84d0-40c1-add9-3be5a5a5a443, ContentDB 4606754f-fb82-4829-bda1-878869c2a450 Exception message was A duplicate site ID 18318f24-21f6-4b45-95c3-5479fe6f99dc(http://ssp4dev/ssp/admin) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

The solution

stsadm -o sync -DeleteOldDatabases 0

Refer to MS for the full STSADM sync command info.

stsadm -o sync

-excludewebapps
-synctiming
-sweeptiming
-listolddatabases
-deleteolddatabases

Application Server Administration job error Hotfix

We have been getting variations on this error constantly...

************************************************************************************
An exception occurred while executing the Application Server Administration job.

Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
************************************************************************************
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchAdminSharedWebServiceInstance (9c35167a-a25e-4661-8d9e-2f762609ee06).

Reason: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
************************************************************************************
The Execute method of job definition Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob (ID 2bcd5c2c-6f34-4a70-b53a-669b337c2b3e) threw an exception. More information is included below.

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
************************************************************************************

Hoorah, there is now a solution!

This comes from: http://www.sharepointfusion.com/2007/12/part-8-of-sharepoint-2007-setup-and.html

Update #1: 1/17/2008

Microsoft has now fixed the issue. See KB946517.
Summary: The root cause is the Internet Information Services (IIS) Active Directory Service Interfaces (ADSI) provider. The issue occurs when you have a process with more than one thread and two threads access IIS 6.0 at the same time. In MOSS 2007, this problem is likely to occur for OWSTimer.exe. When it occurs, you may expereince the following symptoms:
• In SharePoint Server 2007, tasks that are scheduled do not run.
• When you try to manage IIS 6.0 by using Server Manager, you receive a blank page, or you receive the following error message: the path specified cannot be used at this time
When this problem occurs, you must restart IIS 6.0, or you must restart the process that uses the IIS ADSI provider.
To apply the hotfix, you must have Windows Server 2003 SP1 or SP2 installed.

Update #2: 1/17/2008

Brummy21 posted a solution to the issue in Microsoft SharePoint forum:
a. Update .NET 2.0 to Service Pack 1
b. Update MOSS2007 to Service Pack 1
c. Apply hotfix as per KB923028.
Important - the problem was only fixed by applying the hotfix after the service packs - service packs alone did not cure.