The Symantec Management Agent is unable to re-register with the Symantec Management Platform after migration

Products

• IT Management Suite

Issue/Introduction

In a situation where the Symantec Management Agent was migrated from one virtual environment to another virtual environment, the client may fail to re-register with the server.

Policy requests also fail with the error:

The specified resource does not exist: 744af870-3eb3-4b61-8b72-f3abe2516a79
type=493435f7-3b17-4c4c-b07f-c23e7ab7781f
key=[name.domain]
value=[******]
   [UnrecoverableComException @ Altiris.NS.dll]

Example agent log entry:

Operation 'Direct: Post' failed. 
Url: HTTPS://SMPserver.example.net:443/altiris/NS/Agent/GetClientPolicies.aspx 
Connection path: 1* - Direct: [172.##.##.71] -> SMPserver.example.net [172.##.##.85:443] 
Communication profile id: {ac###########129} 
Throttling: 0 0 0 
Connecton stage: Server connect 
Error type: SMP Server error 
Error code: The specified resource or other object does not exist (0x80041003) 
Error note: HTTP Status 200: 200 OK 
Server SSL connection info: 
   Server certificate: 
      Serial number: 6f ############# d2 27 
      Thumbprint: 9a ############ 98 21 
   Client certificate: 
      Serial number: N/A 
      Thumbprint: N/A 
   Cryptographic protocol: TLS 1.3 
   Cipher suite: TLS_AES_256_GCM_SHA384 
   Cipher algorithm: AES 
   Cipher key length: 256 
   Hash algorithm:  
   Hash length: 0 
   Key exchange algorithm:  
   Key length: 0 
Client SSL attributes for server connection: 
   Client certificate: 
      Serial number: N/A 
      Thumbprint: N/A 
   Cryptographic protocol: TLS 1.0, 1.1, 1.2, 1.3
Connection path id: 2bf0ddb812b474ec73f40c7a236e7cbca2cf2680
-----------------------------------------------------------------------------------------------------

When you check the current status on this machine in the SMP Console:
the Configuration Requests has an alert, but with communication and plugins are up to date.

Environment

IT Management Suite (ITMS) 8.8.x

Cause

In some virtualizers (QEMU) agent detects itself as a physical computer, and if previously (in VMWare, etc) it was detected as a virtual computer, it would prevent the client from re-registering with the SMP server.

The primary issue stems from how the Symantec Management Agent detects hardware changes post-migration. In some migration scenarios, virtual machines moved to the Proxmox VE, VergeIO or RedHat Openshift platform are incorrectly identified by the agent as physical computers instead of virtual machines. When a client system that was previously registered in the SMP database as a virtual machine suddenly reports as a physical asset with mismatched hardware identifiers, the SMP server rejects or drops the communication, preventing proper client re-registration and ongoing management.

Resolution

Diagnostics & Evidence Collection

To confirm this issue is occurring, check the Symantec Management Agent logs on the affected client machine or the NS logs.

• Log Locations:

  • NS Logs: C:\ProgramData\Symantec\SMP\Logs\aXX.log (where XX represents the sequential log numbers).

  • Client Agent Logs: C:\ProgramData\Symantec\Symantec Management Agent\Logs\agentX.log

Look for log entries resembling the following during a manual agent connection or registration cycle:

<event date='Jun 04 08:00:00' severity='2' modules='AeXNSAgent' source='CoNetworkTransport' >
  <![CDATA[PostToUrl failed: HTTP status 400: The client registration request is invalid or contains conflicting hardware signatures.]]>
</event>

On the SMP Server aXX.log file, look for blockages related to resource keys:

Class: Altiris.NS.StandardItems.Messaging.RegisterCaptureResource
Description: Failed to process registration request. The resource trying to register reports as a physical computer but matches an existing virtual machine resource GUID.

 

Diagnostics: Identifying the Cause via WMI

To confirm if a client is experiencing this exact issue due to an unrecognized virtualizer (we will use VergeIO migration as example), run the following diagnostic commands from an elevated command prompt or PowerShell instance on the affected endpoint.

NOTE: Do not copy the output from the console window with the mouse. Selecting text in the console adds line breaks and spaces that are not in the real output. Redirect each command's output to a file instead, as shown below.

Step 1: Create a folder for the output files

From an elevated Command Prompt:

mkdir C:\Temp

Step 2: Run the WMIC commands

From the same elevated Command Prompt:

wmic csproduct get UUID > C:\Temp\wmic_csproduct_uuid.txt
wmic path Win32_BaseBoard get * > C:\Temp\wmic_baseboard.txt
wmic path Win32_ComputerSystemProduct get * > C:\Temp\wmic_computersystemproduct.txt

Step 3: Run the PowerShell command

From an elevated PowerShell window:

Get-CimInstance Win32_ComputerSystemProduct -Property * | Format-List * | Out-File C:\Temp\cim_computersystemproduct.txt

Expected vs. Actual Diagnostic Output

Use the table below to cross-reference your diagnostic outputs to confirm the root cause:

Diagnostic Command	Expected Pre-Migration Output (VMware)	Actual Post-Migration Output (VergeIO Issue State)
wmic path Win32_ComputerSystemProduct get Vendor, Name	Vendor: VMware, Inc. Name: VMware Virtual Platform	Vendor: VergeIO Name: Standard PC (Q35 + ICH9, 2009)
wmic path Win32_BaseBoard get *	Returns populated motherboard records (e.g., Intel Corporation, 440BX Desktop Reference Platform).	No Instance(s) Available.

Available Fixes

For those who migrated to Proxmox VE:

This issue has been fixed in ITMS 8.8.1

Workaround:

1. One option is to convert the machine resource type to physical on the server side, which is explained in KB170095
2. Or before migration, install SMA_SMP_8_8_PF_v8 or later cumulative pointifx from CUMULATIVE POST ITMS 8.8 POINT FIXES and upgrade the clients.

 

For those who migrated to VergeIO:

This issue will have a fix under our ITMS 8.8.2 Release

Workaround:

1. One option is to convert the machine resource type to physical on the server side, which is explained in KB170095
2. Or install SMA_SMP_8_8_1_PF_v4 or later cumulative pointfix from CUMULATIVE POST ITMS 8.8.1 POINT FIXES and upgrade the clients.

For those who migrated to RedHat OpenShift:

This issue will have a fix under our ITMS 8.8.2 Release

Workaround:

1. One option is to convert the machine resource type to physical on the server side, which is explained in KB170095
2. Or install SMA_SMP_8_8_1_PF_v8 or later cumulative pointfix from CUMULATIVE POST ITMS 8.8.1 POINT FIXES and upgrade the clients.