KNOWN ISSUE: Helpdesk is resynchronizing the same users every hour
|Article:TECH17688|||||Created: 2006-08-29|||||Updated: 2008-07-09|||||Article URL http://www.symantec.com/docs/TECH17688|
|NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.|
In looking in the Altiris a.logs, it is discovered that the Notification Server to Helpdesk Asset and User synchronization is causing the same users to keep getting resynchronized every hour.
Other symptoms include an hourly hit in Helpdesk performance because this synchronization executes every hour. Also in looking at the contact table in the Altiris_Incidents database, it is found that several contacts have multiple versions.
This is often seen where multiple domains are imported and there are common users between the domains with the same email address in both domains. Other times, the domain that is imported does not have the same domain information as what the users really logs in with.
Helpdesk Solution 6.0 SP2 through SP4
Various types of imports can create users within the Notification Server that must be synchronized to Helpdesk Solution.
Helpdesk Solution has a rule for contacts that present problems when trying to reconcile user resources from Notification Server to contacts in Helpdesk Solution.
All Helpdesk Solution contacts with NT_IDs must have a unique NT_ID and contacts with an Email address must have a unique Email address. During synchronization, if the Notification Server tries to force a contact to violate this rule, the data that would have violated the rule is reverted back, and the remaining information is updated from Notification Server.
Because the NT_ID or Email is still different from the contact record, every hour (the default synchronization interval) the same user gets included in the list of users that needs to be synchronized again.
A hotfix is being developed that will prevent the performance hit every hour. Even with the hotfix, there is still the possibility that data may be lost. In order to remove the duplicates and ensure a clean synchronization with no lost data you will need to follow the steps below exactly.
The following SQL command helps identify where duplicates users are that are violating the helpdesk contact uniqueness rules.
- Run this SQL command against the Altiris database:
/*Start SQL for finding Sync issues */
select i.Guid as NS_resource_guid, cv.contact_id as HD_contact_id, isnull(i.Email, N'') as NS_contact_email, cv.contact_email as HD_contact_email,
case when wcv.worker_id is not null then 1 end as HD_is_worker, cve.contact_email as DupEmailHD_contact_email, cve.contact_id as DupEmailHD_contact_id,
case when wcve.worker_id is not null then 1 end as DupEmailHD_is_worker, cve.contact_resource_guid as dupemailhd_contact_resource_guid,
(case when i.[Domain] <> N'' and i.[Name]<> N'' then i.[Domain]+'\'+i.[Name] else N'' end) as NS_contact_nt_id, cv.contact_nt_id as HD_contact_nt_id,
cvn.contact_nt_id as DupNTIDHD_contact_nt_id, cvn.contact_id as DupNTIDHD_contact_id,
case when wcvn.worker_id is not null then 1 end as DupNTIDHD_is_worker, cvn.contact_resource_guid as dupNTIDhd_contact_resource_guid
from vResourceItem as vi with (NOLOCK)
left outer join ResourceKey rk with (NOLOCK) on vi.Guid = rk.ResourceGuid and KeyName = 'name.domain'
inner join vUser as i with (NOLOCK) on i.Guid= vi.Guid
left outer join HD_contact_view cv with (NOLOCK) on cv.contact_resource_guid = i.Guid
left outer join HD_WORKER_view wcv with (NOLOCK) on wcv.worker_contact_id=cv.contact_id
left outer join HD_contact_view cve with (NOLOCK) on i.email <> N'' and cve.contact_email=i.email and (cv.contact_id is null or cve.contact_id<>cv.contact_id)
left outer join HD_WORKER_view wcve with (NOLOCK) on wcve.worker_contact_id=cve.contact_id
left outer join HD_contact_view cvn with (NOLOCK) on i.Name <> N'' and i.Domain <> '' and cvn.contact_nt_id=i.[Domain]+'\'+i.[Name] and (cv.contact_id is null or cvn.contact_id<>cv.contact_id)
left outer join HD_WORKER_view wcvn with (NOLOCK) on wcvn.worker_contact_id=cvn.contact_id
where (i.Email <> N'' or (i.Name <> N'' and i.Domain <> N'')) and
((cv.contact_id is not null and (((case when i.Name <> '' and i.Domain <> '' then i.[Domain] + '\' + i.[Name] else N'' end) <> cv.contact_nt_id collate Latin1_General_CI_AS
and cvn.contact_id is not NULL ) or (isnull(i.[Email], N'') <> cv.contact_email collate Latin1_General_CI_AS and cve.contact_id is not NULL))
) or (cv.contact_id is null and (
--No duplicate email address
isnull(cve.contact_resource_guid,0x0) <> 0x0 or
--No duplicate nt_id values
(isnull(cvn.contact_resource_guid,0x0) <> 0x0 and (rk.ResourceGuid is not null or (rk.ResourceGuid is null
and i.Guid not in (select ResourceGuid from ResourceKey rk2 where i.Guid = rk2.ResourceGuid and rk2.KeyName <> 'name.domain')) ) ) ) ) )
/*End SQL for finding Sync issues */
- The first thing to look out for in the result set is to see if the duplicate on the Helpdesk side is also using a non-zero GUID (either from the dupemailhd_contact_resource_guid column or the dupNTIDhd_contact_resource_guid column or both) that is different from the NS_Resource_Guid that is trying to sync up.
This means that Notification Server itself may have a duplicate. Using Resource Explorer, look at both users by pasting in the two different GUIDs (NS_Resource_guid and the duplicate Helpdesk GUID [either the dupemailhd_contact_resource_guid column or the dupNTIDhd_contact_resource_guid column or both]). With Resource Explorer open, switch to the Inventory tab and browse through the different data between the duplicated resources. Verify that they have either both the same email address under the "User General Details" data-class with different "Name\Domain" values under the "Global Windows Users" data-class or have the same "Name\Domain" values with different email address (not common).
If possible, try to identify the source of where User resource was imported into Notification Server so that these duplicate users in the Notification Server can be avoid in the future.
Once both user resources have been identified, then one of the duplicates needs to be deleted. Again, if the source of the duplicate was identified, try to either disable that import or change its definition so that the duplicate does not import again.
After the Notification Server users are cleaned up, then Helpdesk and Notification Server should be synchronized one more time before it is disabled for the remainder of the work. From the Helpdesk server open this URL command:
Once the URL returns, open the registry on the Helpdesk Server and find
Set the value data for "DisableAutoUpdateProcessing" to "true".
Rerun the above finding Sync issues SQL script again and look at the results. Each result displays the data from Notification Server that is trying to update a Helpdesk Contact. Either the email is different from Notification Server or the NT_ID is different from Notification Server. Either way the value that is different remains so because a different Helpdesk contact already contains the same value. This would be the duplicate Helpdesk contact.
Start with those Helpdesk contacts that are also workers. Any duplicate where the Helpdesk contact is a worker and the duplicate is a contact only, the worker contact must be kept and the duplicate is removed. If both the Helpdesk contact and the duplicate contact are a contact only, then either can be chosen to be kept; however, it's best to pick the one with the more recent tickets or the one with the most tickets.
Duplicates that are also both workers will need to be skipped at this point until all the other duplicates are removed.
Once you identified which of the contacts in a row you are keeping and which one is going to be removed then you can proceed.
First the contact to be removed needs to be updated with a blank email and a unique nt_id with a common bogus domain name that can be keyed on later (like "NODOMAIN"). Next the correct nt_id and email info needs to be updated to the contact that is being kept.
Once all the duplicate contacts have been updated, the outdated contacts can be deleted by using the delete contact option and finding contacts with the bogus domain name (like "NODOMAIN" if that's what you used).
This may take a while before helpdesk will finish going through each contact that you have marked to be deleted. All incidents that were associated to the contact at any point in the incidents history are updated to remove that contact.
The remaining duplicate rows, where both the contact and the duplicate contact are both workers, are a little harder to deal with.
Only one of the workers will have the correct nt_id so that is the worker that you will likely need to keep.
Just like before, the worker that will not be used will need to be updated with a unique nt_id with a bogus domain name and the email blanked. In addition this worker will need to be inactivated.
The correct nt_id and email will need to be updated to the worker being kept.
Although the duplicate worker was made inactive the worker's contact side is still active and will also need to be inactivated. To do this, find the contacts that have been updated with a bogus domain name and update each of them to be inactive.
Finally because contacts that are also workers cannot be deleted, they will need to have the imported flags marked as not imported and the Resource Guid set with a 0x0 guid. Otherwise the Notification Server to Helpdesk sync will restore what we have changed. This has to be done by executing the following SQL command against the Altiris_Incidents database. The SQL code does assume that you used "NODOMAIN" as your bogus domain name, you can adjust accordingly.
*Start SQL code*/
update contact set is_imported=0, resource_guid=0x0 where nt_id like 'NODOMAIN\%'
/*End SQL code*/
Rerun the SQL script for finding sync issues at the top again to make sure there are no more duplicates.
|Description||Logged in abqdc01 (Altiris - Albuquerque) database|
Article URL http://www.symantec.com/docs/TECH17688