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.

The agent logs still show that those machines where the GUID was reset have still got the same GUID that is coming back from the SMP.

Environment

ITMS 8.5, 8.6, 8.7

Cause

The machines were improperly prepared for imaging capture as they have references to the same DSUniqueID. It was found that the image includes the same DSUniqueID and 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. If 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 the "DSUniqueID" value generated when the initial image was taken. For some reason the image with the DSUniqueID was used to image all of those machines.

The problem is that all of 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 the SMP point of view - it is only one agent and this is causing the blacklist of the others or merging them as one. Each agent registration overwrites the other agent registrations so they are registering and failing to post events\obtain policies in a circle fashion.

Note:
From the Resource Keys output that you get from the mentioned method above is the duplicated one is called "cloudid" resource key, please try running the following on that client machine(s):

Note: The command dsregcmd.exe /debug /leave unjoins a device from Entra hybrid join. You can use this command to troubleshoot issues with Azure AD join.

dsregcmd.exe /debug /leave

Steps:

Open the command prompt as an administrator

Enter dsregcmd.exe /debug /leave

Sign out and sign in to trigger the scheduled task that registers the device again with Microsoft Entra ID

With our ITMS 8.7.2 release, a new resource key has been introduced called "CloudID".

New "cloudid" resource key

The new resource key uniquely identifies computer and user resources across Azure AD tenants and helps merging resources created during Azure AD import and resources created by SMA (Symantec Management Agent).

The new key name is "cloudid" and the value contains Azure AD tenant ID and ID of Azure AD device or Azure AD user account.

Only computer devices joined to Azure AD are currently supported, Azure AD registered devices or so called "workplace devices" are not supported for now and cannot be imported from Azure AD.

The sample of "cloudid" keys are shown below, other resources keys can exist, and they are not shown:

Computer resource key:
<resource typeGuid="{2C3CB3BB-FEE9-48DF-804F-90856198B600}" guid="{5EADDE2C-8244-464E-9D67-0FC84D4E2998}" name="computer_name">
   <key name="cloudid" value="cda05ba8-49ce-4ae9-acf2-15eb38d8b48d.7650B649-D844-4C5D-82EF-3E29C67C5A9C"/>
</resource>
User resource key:
<resource typeGuid="{FD864F19-4437-4A4F-8709-58EB5E3AE0A4}" name="AZUREAD\user_name">
   <key name="cloudid" value="cda05ba8-49ce-4ae9-acf2-15eb38d8b48d.AD5F720C-43BA-4ACE-BD25-40A2CDE664EA"/>
</resource>

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 the 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"