Computer Asset Status Remains "In Stock" Instead of "Active" After the Resource Merge Process in ITMS

Products

• IT Management Suite

Issue/Introduction

After re-imaging a computer and completing the asset merge process in IT Management Suite (ITMS), the computer's Asset Status remains set to "In Stock" instead of automatically transitioning to "Active." As a result, the Symantec Management Agent (SMA) is not correctly re-registered, and the device is unable to receive or execute tasks until the status is corrected manually.

Environment

ITMS 8.7.x, 8.8.x

Cause

When a new or re-imaged computer is merged with a pre-existing asset record created during a Procurement workflow, the merge operation may incorrectly carry over the manually set "In Stock" status from the source (Procurement) record onto the destination (imaged) record. This occurs because the legacy merge logic in the spResourceMergeInternal stored procedure unconditionally transferred the source resource's Asset Status association to the destination resource, regardless of which record had more current inventory data.

The root cause is a logic gap in the spResourceMergeInternal stored procedure. During a merge, the procedure applies the Asset Status association from the source resource (the "In Stock" Procurement record) to the destination resource (the newly imaged machine) without comparing which record has more current inventory evidence.

Specifically:

• When an administrator manually sets an Asset Status on the source computer, that value is stored as a ResourceAssociation row using Association Type GUID 3028166f-c0d6-41d8-9cb7-f64852e0fd01.
• During the merge, the source resource's status association wins and is carried over to the destination.
• No timestamp comparison was performed to determine whether the destination record (the active, managed machine with fresh inventory) should take precedence.

A secondary contributing factor observed in at least one case: the IsManaged flag in the Vcomputer table was set to 0 on the merged record post-merge, which may prevent the platform from automatically resolving the status to "Active."

---

Diagnostics

Diagnostic Step	Command / Path	Expected Result	Interpretation
Check IsManaged on merged resource	SELECT IsManaged FROM vComputer WHERE Name = '<MachineName>'	1	If 0, agent re-registration or further investigation is required
Confirm Asset Status association on destination	SELECT * FROM ResourceAssociation WHERE ResourceAssociationTypeGuid = '3028166f-c0d6-41d8-9cb7-f64852e0fd01' AND ParentResourceGuid = '<ToGuid>'	No row (defaults to Active) or an Active status row	A row with "In Stock" status confirms the bug is still present
Check AeX AC Client Agent inventory timestamp on destination	SELECT ModifiedDate FROM ResourceUpdateSummary WHERE InventoryClassGuid = '9e6f402a-6a45-4cba-9299-c2323f73a506' AND ResourceGuid = '<ToGuid>'	Recent date/time (post-imaging)	NULL means Basic Inventory has not been submitted — fix logic will not trigger
Confirm source record removed post-merge	SELECT * FROM vComputer WHERE Guid = '<FromGuid>'	No results	Confirms the source "In Stock" record was fully absorbed into the destination
Review SMP logs for merge errors	C:\ProgramData\Symantec\SMP\Logs\	No critical errors during the merge window	Review A*.Log for exceptions related to the merge operation

Resolution

This fix is targeted for inclusion in ITMS 8.8.2. 

A workaround is available via an updated version of the spResourceMergeInternal stored procedure. See attachments section. A manual SQL update is available as an interim workaround for environments currently running ITMS 8.8.

The update introduces a protective timestamp check — if the source Asset Status is older than the destination's most recent inventory submission, the source status is discarded, allowing the destination resource to remain "Active" after the merge.

⚠️ Warning: This resolution requires executing a SQL script against the SMP database. Always back up the database and save a copy of the existing stored procedure before proceeding. Test in a non-production environment first whenever possible.

Part A — Pre-Requisite Checks

1. Open SQL Server Management Studio and connect to the SMP database instance.
2. Retrieve and save the current stored procedure definition as a backup:

SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.spResourceMergeInternal'));

3. Store the output in a .sql file in a safe location in case a rollback is needed.

Part B — Identify Affected Resources Before Applying the Fix

1. Identify a client machine in "In Stock" status to use for testing.
2. Retrieve and record its resource GUID:

   SELECT Guid, Name
   FROM vComputer
   WHERE Name = '<MachineName>';

3. Verify the IsManaged flag on the newly imaged machine (before merge):
    

   SELECT Guid, Name, IsManaged
   FROM vComputer
   WHERE Name = '<MachineName>';

4. Expected before merge: IsManaged = 1 on the newly imaged destination machine.

5. In the Symantec Management Console, navigate to: Resource Manager > [Target Computer] > View > Inventory > Data Classes > Inventory > Basic Inventory Confirm that the AeX AC Client Agent data class has been populated for the newly imaged machine. A populated record indicates a successful Basic Inventory submission — required for the fix logic to function correctly.

Part C — Apply the Updated Stored Procedure

1. Download the updated SQL script: spResourceMergeInternal_updated.sql
2. Execute the updated script against the SMP database. The script will drop the existing procedure and create the updated version:
   
   -- The script begins with: IF EXISTS (SELECT TOP 1 1 FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[spResourceMergeInternal]') AND type in (N'P', N'PC')) DROP PROC [dbo].[spResourceMergeInternal] GO -- Followed by CREATE PROC with the updated logic.

 

Part D — Test the Fix

1. Identify a client machine in "In Stock" status. Record its GUID (this is the source / @FromGuid).
2. Image the machine. Once imaging is complete, confirm all of the following on the newly imaged machine (this will be the destination / @ToGuid):
   • IsManaged = 1 (confirmed via SQL on vComputer)
   • Asset Status is "Active" in the console
   • AeX AC Client Agent inventory data class is populated
3. Record the GUID of the newly imaged machine.
4. Run the Merge process in the Symantec Management Console.
5. After the merge completes, verify the Asset Status on the resulting resource: Navigate to: Resource Manager > [Merged Computer] > Summary Confirm Asset Status = "Active."
6. Confirm the resulting resource GUID is the imaged machine's GUID (destination retained):

SELECT ResourceGuid, Name, IsManaged
FROM vComputer
WHERE Name = '<MachineName>';

Expected outcome:

• Resulting GUID = imaged machine's GUID (@ToGuid)
• The old "In Stock" source record is no longer present as a standalone resource
• IsManaged = 1
• Asset Status = "Active"

---

Interim Workaround — If the SQL Fix Cannot Be Applied Immediately

If the updated stored procedure cannot be applied right away, use one of these workarounds after each merge:

 Use the "Set Asset Status" Task:

1. Navigate to: Manage > Jobs and Tasks > System Jobs and Tasks > Asset Management
2. Run the "Set Asset Status" task targeting the merged computer.
3. Set the Asset Status to "Active."

---

Verification

After applying the updated stored procedure and running the test merge, confirm all of the following:

Asset Status = "Active": Visible in the Resource Manager Summary tab for the merged computer.

GUID is correct: The resulting resource GUID matches the imaged machine's GUID, confirming the destination record was retained as expected.

Source record is removed: The original "In Stock" Procurement record no longer exists as a standalone resource in the console.

Agent is functional: The SMA on the merged computer is registered, visible in the console, and capable of receiving policies and tasks.

IsManaged = 1: Confirmed via SQL query against vComputer.

No regression on existing workflows: Pre-existing re-imaged machines that previously merged correctly continue to behave as expected.