In order to delete the many Content Deployment Timer Job records that are created during the automated content deployment process follow the steps below:

1. Run the following SQL statement on your SharePoint Config Database to retrieve the unique IDs (GUIDs) of all the Content Deployment Timer Jobs:

    select * from Sharepoint_Config.dbo.[Objects] REM where [Name] like 'ContentDeploymentJobDefinition%'

2. Then, use those unique IDs (GUIDs) to build a batch file to run the following STSADM command:

   STSADM -o deleteconfigurationobject -id "<object id>"

After applying the latest Windows updates for Windows Server 2003, we received many “Timed Out” errors when trying to run content deployment jobs.  The main culprit of there errors seemed to be the OWSTIMER.EXE process and it taking 100% of the CPU… yeah, I know “it’s a pain!”

Anyway, one of the things I did to try and get the issue resolved was to clear out the years of Content Deployment objects that had built up on the target server.

This was a 2 step process:

1. Find all the Content Deployment Job objects in the config database and get their IDs

   select * from Sharepoint_Config.dbo.[Objects]  where [Name] like 'ContentDeploymentJobDefinition%'

2. Run an stsadm command to delete the object based on its ID
   

   STSADM -o deleteconfigurationobject -id "<object id>"

I was able to do some text manipulating and get a really long .bat file that ran for a really long time. When it was done, all the Content Deployment Job objects were gone.

However, it did not seem to fix my issue with OWSTIMER.EXE taking 100% of the CPU.

The solution for that seemed to be narrowing down which Content Deployment Job was causing the issue by disabling them all and then re-enabling them one at a time and deleting the target site collection and doing a full deployment.

I’m not sure which update caused the issue but after doing a Windows Update the OWSTimer.exe job started using 100% CPU on the target server of a content deployment job.

The trace logs showed the following errors:

CSsoResourceManagerCache cannot find SSO connection string value in the registry! Error code is: -2147418113 CSsoResourceManagerCache has set SSO connection string value to be empty …  SSO is not configured any more. Error code is: -2147418113 IResourceManager::Refresh() failed Error code is: -2147024809 ForceRefreshOfSPSResMgr() failed. This may be ok if SSO has not been configured yet and the run-as service gets an access denied Error code is: –2147024809

Thanks to Kerry’s SharePoint Blog for the tip about stopping the SSO service (Microsoft Single Sign-on Service) and setting it to manual.

One of our developers reported to me that the SharePoint Alerts were not sending emails.  The initial notification that the alert was setup was sent but not the alerts themselves.

I was able to find a great article by a MS MVP named Susan Bradley called How to Troubleshoot Alerts in WSS 3.0 / MOSS.

In going through all the steps, I was able to determine that my issue was caused by the permissions setup on the list.

Thanks, Susan!

Below is the contents of the article:

Question:  How to Troubleshoot Alerts in WSS 3.0 / MOSS
Answer:

The most common issue in alert is the user will get the initial email, but will not get when changes are made to the list where he configured the alert.  Check the following settings in order and ensure that it is correct.

1. Is it an upgrade from V2 to V3?  If yes, check the upgrade section at the bottom of this page.

2. If this is a new install of V3 (WSS or MOSS), then do the following

a. Create a new web app and see if the alerts work there.  If yes, you can move the content db of the non-working site to this one. If customer is not ready to do that, then try the following.

b. Open the command prompt and go to the 12Bin folder. Run this command and see whether alerts are enabled for the web application.  

Stsadm.exe-o getproperty -url http://problemsite  -pn alerts-enabled

The expected output is <Property Exist="Yes" Value="yes" />.  If you don’t get this, run the following command to change the value.

stsadm.exe -o setproperty -pn alerts-enabled -pv "true" -url http://problemsite

If the property is Yes and still the alerts are not sent, toggle the property from Yes to NO

and then from No to Yes.  This may delete all the existing alerts and warn the customer

about this.

c. Check the property job-immediate-alerts schedule through command prompt.  Run this command from the 12bin folder.  If we have issues with Scheduled alerts like daily or weekly, then check the property job-daily-alerts and job-weekly-alerts.

stsadm.exe -o getproperty -url http://ProblemSite  -pn job-immediate-alerts

The expected output is

<Property Exist="Yes" Value="every 5 minutes between 0 and 59"/>.  If you don’t get this, run the following command to change the value.

stsadm.exe -o setproperty -pn job-immediate-alerts -pv "every 5 minutes

between 0 and 59" -url http://ProblemSite

d. Confirm the above step through the UI. Central adminàOperationsàTimer Job Definitions and ensure that a job named Immediate Alerts is present for the web application.

e. Configure the alert for a user in a list.  Instead of typing the domain name user name, type the email address of the user and see if he gets initial email.  Then make a change to the list and see whether he gets the mail related to the change.

f. If he gets the alert as expected, then create a new alert and this time select the user from the people picker or type the domain nameuser name. 

g. If the alert is not working after doing the above step, then check the ImmedSubscriptions / SchedSubscriptions table of the content db of the web application depending on the type of alert and see a new record is added and ensure that the email field for the user is populated correctly.  If not, check whether the email address is present in the user’s profile through the SSP admin page.

h. The initial alert is not security trimmed. So irrespective of whether the user has privileges on the list or not, the initial alert will be sent.  If the user is not getting alert for any changes, then check whether the user has Read permission on the list.

i. This also happen if there is some issue in their mail provider (third party email providers.  In this case, capture the ULS log with all information events in the verbose mode and check for lines which says Alert has been sent.

j. Email enabled security groups can also be used for configuring alerts.  If the changes are not notified to the members of the group, check whether the group is added to the list with minimum Read permission.  Also some email providers block email groups if the number of members are more than certain number.

k. Open SQL Query Analyzer; connect to the content database of problematic site. Run the following query.

Select * from timerlock

This server is responsible for processing the timer service.  You can follow this KB –

http://support.microsoft.com/kb/934838 to sync the accounts and password across the

Farm

The internal working mechanism of how an alert should work in v3:

The EventCache table records the SQL level events as they occur and the EventData and ACL columns are not NULL for an alert event.  There is an alerts timer job that runs periodically to process the records in the EventCache. After the alerts timer job runs, it nulls out the EventData and ACL columns. Then, it will log an event into the EventLog table.  So check the following in SQL.

select * from eventcache where EventData is not null

This will output all of the subscriptions which have not been processed yet. We can see if there are some alerts which are not processed.

select * from eventlog where ListID = ‘xxx’

You can get the ListID from the EventCache table by running

Select * from EventCache and check the documents which correspond to the problematic list.

If you cannot find any record, perform the following tests:

Run filemon on the MOSS server which is responsible for the timer service and check if the Timer

service picks up the alert template during the whole process.

             Upload a new document to the document library which is supposed to have the alerts. Begin running 

             the filemon and analyze the logs.

p. select * from eventcache order by EventTime DESC

Check if the latest log is the one corresponds to your uploaded document. Make sure the EventData and ACL columns are not NULL.

After 5 minutes or more minutes, check the EventCache table again to see if the EventData and ACL columns are NULLed.

If so, stop filemon after the EventData and ACL columns are NULLed . Review log.

Upgrade from V2 to V3

1. Check this KB – http://support.microsoft.com/kb/936759/en-us

2. If no alerts are getting triggered even for a new web app, then run the Psconfig Wizard without changing any options. 

The timer job displayed an older date because the upgrade job was hung

3. If the alert works on new web apps, then you can move the site collections from the upgraded web app to the newly created web app through stsadm –o backup / restore or stsadm –o export / import.  This action will be useful only if you have fewer site collections and this is only a workaround.

Case Study

ERROR MESSAGE:
================
Running the psconfig wizard fails immediately with "Unable to upgrade SharePoint
Products and technologies because an upgrade is already in progress"
No psconfig process in task manager

CAUSE:
=======
The timer job displayed an older date because the upgrade job was hung
RESOLUTION:
============
Sharepoint central administration page->Operations->Timer job definitions
Asked client to delete the "Upgrade job"
Now the psconfig wizard ran fine
Timer job definition showed all the jobs with the latest date. Especially the
Immediate alerts job