The Default Contact That Wasn't Blank

We recently ran into a problem on our helpdesk where the information stored about the default contact was changed from blank to a real name and email address. Now knowing that we have seen this in the past I was not initially concerned with it. We only have to go into the database and update the offending fields to the empty string. This time was a little different since the issue was reported to me after the helpdesk managed attempted to delete the offending contact from the database.

Since the built in contact delete process, reassigns all tickets from the contact being deleted to the default contact (ID 1), and due to the fact the contact in question was id 1. What we ended up with was the system in a loop where it would try setting any incidents with a contact id of 1 to id of 1.

In this article I will identify and resolve the following issues.

• Contact ID of 1 is messed up.
• We have some job running that is perpetually resetting the contact to the same thing.
• We need to figure out how this is happening and stop it form happening in the future.

Let's start by fixing the contact ID 1:

Login to SQL management and open a new query on the Altiris_Incidents database.

Type and run the following Query

select * from contact where id =1

This will return the ID 1 record. Verify the following fields are blank (empty string)

external_id
nt_id
name
email
title
company
department
phone
cell_phone
pager
pager_email
location
password

If any of these fields have a value other than the empty string you will need to run an update to reset them back to the empty string. I have also added changing the status to 'a' since we have seen this set incorrectly.

update contact
set name = ''
, external_id = ''
, nt_id = ''
, email = ''
, title = ''
, company = ''
, department = ''
, phone = ''
, cell_phone = ''
, pager = ''
, pager_email = ''
, location = ''
, password = ''
, status = 'a'
where id = 1

After you update the Contact ID 1, your default contact will now display as expected.

The case of the loping job:

Now this one was a little tricky. First run the following, a new query in, SQL Management Studio:

select * from jobqueue where jobqueue_status = 'p'

Hopefully this will return nothing and you can skip the rest of this section and move on to the next. If you do get some rows to return we'll need to get the batch job id (jobqueue_batchjob_id) and run a query against the batchjob table.

select * from dbo.batchjob where batchjob_id = xxx

Replace the xxx with the batchjob_id returned from the previous query.

Look at the batchjob_target_query in the returned values if it something like this:

workitem_number IN 
(select distinct number from workitem where contact_id IN (1) 
OR created_by_worker_contact_id IN (1) 
OR modified_by_worker_contact_id IN (1))

Then you have the contact loop delete issue.

To correct the problem we first have to disable any queued deletions or multi-edits by unchecking that option Process deletions and multiple incident edit in the Incident Settings page (Altiris Console > Configuration > Server Settings > Notification Server Settings > Incident Settings).

Next you'll need to delete the offending Batchjob. Be sure to backup the batchjob table prior to deleting. Replace xxx with the batchjob id we got earlier.

delete batchjob where batchjob_id = xxx

Now we'll need to delete the records from the jobqueue table that refrenced this job. Once again backup up the jobqueue table prior to deleting the records.

delete jobqueue where jobqueue_batchjob_id = xxx

Now log back into the console and reenable Process deletions and multiple incident edit, and you should be all set.

Now let's stop this from happening in the future:

After seeing this problem three times we needed to figure out why it was happening. We were able to track the issue back to the user that changed the default contact, and apparently the contact ID of 1 is not blocked for editing and any worker can edit the contact and set this process off.

We can reproduce the problem by editing an incident with a blank contact, and clicking on the View Contact Properties button.

Click to view.

Once the contact properties are opened any worker can edit the default contact info.

Click to view.

To fix this we'll have to edit the code on the subWorkItemEditContact.ascx page. First off, well have to create or modify the custom.config file to include our new page, and then copy the subWorkItemEditContact.ascx page to our new location. Once copied open the file and look for the following section of the code.

Public Overrides Sub LoadDataSources()

Add the following lines directly below the line above.

	
if DataStore("Contact").Current.contact_id = 1 Then
	btnContactOK.Visible =False
	tbContactName.Text = "DEFAULT CONTACT"
tbContactComment.Text = "This is the default contact and can not be edited. Please click Cancel to return to the prior screen."
	Else

Then right above the End Sub line add an end if.

Your finished Subrouteen should be as follows:

Public Overrides Sub LoadDataSources()

	if DataStore("Contact").Current.contact_id = 1 Then
	btnContactOK.Visible =False
	tbContactName.Text = "DEFAULT CONTACT"
	tbContactComment.Text = "This is the default contact and can not be edited. Please click Cancel to return to the prior screen."
	else

	if DataStore("Organizations") is nothing then
		DataStore("Organizations") = New ListDataSet("OrganizationList")
	end if

	DataBind()

	if Altiris.Helpdesk.Services.Configuration.Current.ShowDecryptedContactPasswords then
		tbContactPassword1.TextMode = TextBoxMode.SingleLine
		tbContactPassword2.Visible = false
	else
		tbContactPassword2.Visible = true
	end if
	' Set password fields first - hence any password passed in is ignored
	tbContactPassword1.Text = DataStore("Contact").GetContactPassword()
	tbContactPassword2.Text = DataStore("Contact").GetContactPassword()

	hlIncidents.AddParam("title", GetString("sidIncidentsAssociatedWith") & " " & DataStore("Contact").Current.contact_name)
	hlIncidents.AddParam("where", "contact_id = " & DataStore("Contact").Current.contact_id)

	Console.Current.Focus = tbContactName
	Console.DefaultSubmitButton = btnContactOK
  end if

End Sub

Now save your edits and restart IIS. Now when trying to edit the default contact the user will get the following screen.

Click to view.

Notice that the Save button is disabled and we have put some discriptive text in the name and the comment. All the user can do from the new screen is click cancel.