ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

How to track down duplicate machine names?


Article ID: 180828


Updated On:


Management Platform (Formerly known as Notification Server)




The Inv_AeX_AC_Identification.[Client Date] column records the last time the NS receives data from the NSClient but in the NSClients time.  The NS uses UK data and time format but our NSClients use all sorts of date and time formats, which means that we have day/month/year, month/day/year, and year/month/day entries.

The the Inv_AeX_AC_Identification.Guid column represents the legacy GUID and that the Inv_AeX_AC_Identification._ResourceGuid column should be used in the 6.0 world.  I have checked my database and both the Guid and ResourceGUID columns contain the same Guids, so they are being affected by your duplicate machine names within workgroups scenario.

Please refer to the following Knowledge Base Articles that I have created, as they identify the locations of where the MachineGUID will be found within the registry as well as how to modify the registry from within an image.

In order to track down duplicate machine names within your environment, you can use the Inv_AeX_AC_TCPIP Table, as this will contain all reported interfaces from your managed resources.

If you have machines with duplicate Guids, then only one resource is normally created and its data is overwritten each time one of these machines sends data to the NS.

Please investigate the use of the ResourceUpdateSummary Table as this will tell you when a resource first populated a data class as well as when it last modified that data class.

Please refer to the CreateResource.aspx KBA which explians how a machine obtains a ResourceGuid.

The query in the following KBA will allow you to automatically merge your duplicate machines instead of having to manually merge them one resource at a time.

The following information explains processes that assign new GUIDs to machines:

In SP2 the ‘list’ is less extensive than previous builds.  Before SP2 certain events triggered the NS to tell the client to remove its GUID and assign itself a new one, potentially causing a duplicate record.  In SP2 the NS will accept any GUID regardless, and if the event doesn’t have the required information to connect it to a record, it temporarily creates a new record until enough information arrives in the database to tie that event to the right record without making the GUID change request back to the agent that sent it.

Re-imaging causes problems if the name.domain ResourceKey changes, because then the NS has no way to link that machine back to the old record.  If the name.domain are the same, it will assign it the same GUID.

Along the same vein if a GUID exists in the image, that will cause a different sort of problem in that the server will accept that GUID and hook it to the record in the database with that GUID.
Renaming the computer is NOT a problem because it will report with the existing GUID, thus linking it to the correct record and that record will be updated.

Possible problems exists where records are brought in from a different source.  For the most part these other methods don’t provide a GUID, so if the name.domain key doesn’t match exactly what the Agent has reported, there could be a duplicate record.  Normally this doesn’t occur, but it can and has happened:

AD Import
Deployment Server scrape
Resource Discovery
Other import through CSV or other database method

Note that the NS has intelligence when tying information received from an agent to the corresponding record.  Thus if a computer is re-imaged but has the same name and domain, by sending a basic Inventory with name.domain, even without the GUID, the server will search the ResourceKey table for a matching name.domain record.  Once found, it will know what GUID that record has, and assign it back to the client.  This works virtually all the time, but it might be possible that the auto-association fails.

The following two queries will help you identify machines with duplicate GUIDs:
The ResourceKeyChanged table records changes to a resource's key which occurs when more than one resource is using the same GUID.  When basic inventory is sent - the resourcekey info changes and a 'Insert' and 'Delete' occurs in this table.

/* This query simply shows the number of rows for each GUID in particular.  Pretty much, a GUID should not have its resource key changed so rows here do suggest duplicates.  Narrowing down on one Guid and seeing what information is present in the table will confirm. */

select ResourceGuid from ResourceKeyChanged
where KeyName = 'name.domain'
and ChangeType = 'I'
group by ResourceGuid
having count(*) > 1

/* This query will help identify the number of machines using particular GUIDs. */

select Guid,count(*) as [Number of duplicates] from (
select  distinct ResourceGuid as Guid,KeyValue as Name
from ResourceKeyChanged
where ResourceGuid in (
select ResourceGuid from ResourceKeyChanged
where KeyName = 'name.domain'
and ChangeType = 'I'
group by ResourceGuid
having count(*) > 1)
and ChangeType = 'I'
and KeyName = 'name.domain')
group by Guid
order by count (*) desc

If you also have a DS you can use data collected in your express database since it captures NS GUIDS

Select computer_name,domain_name, [ns_guid]
FROM [eXpress].[dbo].[computer]
where  [ns_guid] in
(SELECT [ns_guid]
FROM [eXpress].[dbo].[computer]
group by [ns_guid]
having count([ns_guid])>1)

I have used this with a linked server from the NS to DS to target a collection with a RESETGUID package.  Since any computers with that GUID will get the policy, all of the machines with duplicate GUIDS get reset.  This also allows for ongoing maintenance where I only need monitor activity.