Client Machines are sending same UniqueID during Basic Inventory

Products

Deployment Solution IT Management Suite

Issue/Introduction

It was noticed that some newer imaged machines are getting the same computer GUID.

When trying to add this duplicate GUID to the AgentBlackList table it still persisted. The NS logs showed messages like this one:

Host Resource 0480bd38-0229-4465-9d61-446e8529e558 shares guid with another machine: <Computer1>.EXAMPLE.COM. The resource must change its guid

While looking at the ResourceKeyChanged table it is seen that the same machines were swapping around the same GUID.

When using the "aexagentutil.exe /ResetGuid" switch the machines were still getting the same machine GUID. We deleted those machines from the database but they came back with the same GUID, even though the GUID was already in the AgentBlackList table.

It was still seen in the agent logs that those machines where the GUID was reset and the same GUID is coming back from the SMP.

Environment

ITMS 8.5, 8.6, 8.7

Cause

The machines were improperly prepared for imaging capture. There were references of the DSUniqueID. For some reason the image with the DSUniqueID was used to image all those machines.

Resolution

Try the following:

1. Check under the "ResourceKey" table and see if you notice a similar keyvalue being used between these machines.

2. Capture some NSEs when sending basic inventory (KB 180102 "Trapping NSEs on a Windows client") and check if there is a "UniqueID" that is the same between these machines:

Example 1:

Example 2:

3. I there is one that has the same "UniqueID" key, copy the smatool.exe (found under ...\Program Files\Altiris\Notification Server\Tools) and save it in on one of those client machines.

Run the following command from the command prompt: SMATool.exe /AGENT DUMP RESOURCEKEYS

Do the same on another client machine. Compare both outputs and if both returned that "uniqueid" value.

Example of the output results:

C:\>smatool.exe /AGENT DUMP RESOURCEKEYS

Keys:

fqdn: Computer.example.com

name.domain: Computer.EXAMPLE

name.domain: Computer.example.com

uniqueid: ######-a56d-4b82-bbb0-0d0983980963

uniqueid: dm48o2Lm0uKo/ATISfE/Ww==

uniqueid: gejEU1C/W38BThNjmmhIpw==

uniqueid: mYmhJUH3Pw330gioaN/yTg==

uniqueid: O9JOrrHMOuXpKMA/V9ly0Q==

Keys source data:

UUID: ########-####-####-####-############

Motherboard Serial: ########

Board BIOS Serial: ########

NIC 1: Name: Intel(R) Ethernet Connection (4) I219-V

NIC 1: Instance ID: {3F0BCC64-93AC-457F-B3D8-7574CBD36588}

NIC1 :PnPDevNodeID: PCI\VEN_8086&DEV_15D8&SUBSYS_225A17AA&REV_21\3&11583659&0&FE

NIC1 :MAC(permanent): XX-XX-XX-XX-XX-XX

NIC1 :Fingerprintstring: 2BCBB34C-2242-11B2-A85C-87516FE90E31W1KS86S10V048-2A-E3-09-23-2E

NIC2 :Name: Intel(R)DualBandWireless-AC8265

NIC2 :InstanceID: {E9944BE4-97F0-46C7-B094-0DBD3D4D45FC}

NIC2 :PnPDevNodeID: PCI\VEN_8086&DEV_24FD&SUBSYS_00108086&REV_78\D4D252FFFF799E1500

NIC2 :MAC(permanent): XX-XX-XX-XX-XX-XX

NIC2 :Fingerprintstring: 2BCBB34C-2242-11B2-A85C-87516FE90E31W1KS86S10V0D4-D2-52-79-9E-15

In this particular example, uniqueid: ######-a56d-4b82-bbb0-0d0983980963 refers to "DSUniqueID" value generated when the initial image was taken. For some reason the image with DSUniqueID was used to image all those machines.

The problem is that all these computers share the same deployment defined resource key. So, since this key is a merging key, agents keep re-registering with the same GUID from SMP point of view - it is only one agent, causing to blacklist the others or merge them as one. Each agent registration overwrites other agent registrations so they are registering and failing to post events\obtain policies in circle.

4. Look for the following values:

Depending on the SMP version, this "DSUniqueID" can be found either in "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent" and/or in "aexnsagent.ini" located in "C:\windows" or "C:\windows\system32".

Check both places on these affected machines and remove IDs from there. You can remove the whole "aexnsagent.ini" file and any registry value starting with "DSUniqueID".

Note 1: These values could get into an image if the image was created from the OS deployed by DS right after the deployment. These values get removed automatically after one day after the deployment. Also images deployed this way are not designed to be used as a source for another image.

Note 2: If the mentioned duplicate uniqueID (in this case starting with ######-a56d-4b82-bbb0-0d0983980963) looks like a GUID then this is coming from DSUniqeueID. aexnsagent.INI file gets into Windows system folder after the imaging or SOI task. With our ITMS 8.7.1 or 8.7 RTM releases, Deployment Solution has a fix where INI file is deleted when DS task is finished.
Also, there is a new feature in ITMS 8.7.1 - we use machine TPM 2.0 encryption keys to generate one of our unique IDs. This ID is named "tpmid".
When VM machines are being cloned, the TPM keys for the new machines should be changed because VMWare cloning process copies everything including TPM keys.

5. After that, let make sure the duplicate GUID is in the AgentBlackList table and let the client machines check in and get a new GUID.

6. You also will need to do remove references of the "DSUniqueID" and "MachineGUID" regkeys and delete the "aexnsagent.ini" file from the image if you need to continue using it.

Note:
In order to avoid this issue, make sure you properly sysprep your imaging machine, especially making sure the 'Prepare for image capture' task has run (KB 161011 "Preparing Windows 10 to run a 'Prepare for Image Capture' (sysprep) task using Deployment Solution 7.x/8.x" ).

Additional Information

240039 "Agent revocation after Deploying an image with agent included"