SMP Server has a duplicated communication profile

Products

• IT Management Suite
• Client Management Suite

Issue/Introduction

After migrating a Symantec Management Platform (SMP) server to a new hostname while retaining the existing database (as described in Migrating a Stand-Alone ITMS 8.5 RU4 Instance to the Latest ITMS Version), a duplicate communication profile may appear for the SMP Server.

This is most commonly observed when the SMP Server is configured with additional roles such as Task Server or Network Boot Server (NBS).

The duplicate profiles can be found under:
Settings > Agents / Plug-ins > Symantec Management Agent > Symantec Management Agent Communication profiles > Site Server Communication Profiles

Symptoms

• Duplicate Communication Profile
  • Two profiles exist with the same FQDN and web application path.
• Delete Option Not Available
  • Right-click > Delete is not visible or does not work.

• Validation Error

  Existing profile '[Server Name]' contains the same FQDN and web application path. Existence of non-unique profiles can lead to connection problems if some outdated profile will be used by the NS agent.

• Log Errors (Tickle / Decryption Failures)

  (socket) failed to process incoming tickle connection: #14
Failed to decrypt data[471] from client ('10.10.10.1:XX' (#14749102))

   
• Operational Impact
  • Task Server communication issues
  • Multi-step tasks may not progress
  • Agent-to-server communication inconsistencies

Environment

ITMS 8.x

Noticed after off-box migration with new hostname and existing database.

Cause

How Communication Profiles Are Created 

Communication profiles for Site Servers are automatically created when:

• Certificate data is received by the Notification Server (NS)

• Data is inserted into:

  Inv_AeX_AC_Web_Server_Info

   
• A server is configured with Site Server roles (Task Server, NBS, etc.)

Each detected server identity results in a communication profile.

Inventory-Driven Population

Communication profile values (such as FQDN, hostname, and URLs) are automatically populated using inventory data sent by the Site Server.

This information is derived from:

• Inv_AeX_AC_TCPIP
• Inv_AeX_AC_TCPIPv6
• Inv_AeX_AC_Identification

When inventory is received, these values may be updated automatically to reflect the reported system identity.

Expected Behavior:
The SMP Server should NOT create a Site Server communication profile for itself.

This issue is not caused by the duplicate profile itself, but by a combination of system behaviors introduced during migration.

---

Primary Root Cause

• GUID inconsistency between:
  • Symantec Management Agent (SMA or Altiris Agent) GUID (Computer ID)
  • NSResourceGuid (Core Settings)
  • NSResourceGuid (ServerSettingGuids table in database)

Additional Contributing Behavior

• Inventory-driven automatic profile creation
• Automatic profile synchronization during communication with NS

When these conditions exist:

1. The SMP Server is interpreted as a different system identity
2. A new communication profile is automatically created
3. Duplicate profiles with identical FQDN/path appear
4. The system continues recreating the duplicate after deletion

---

Why the Profile Reappears

Even after manual deletion:

• Basic Inventory or certificate updates trigger profile recreation
• NS background schedules (e.g., NS.Quarter Hour) reprocess data
• The system detects inconsistent identity and recreates the profile
• Communication profiles are refreshed when the Site Server communicates with the Notification Server

Important:
Deleting the profile without correcting GUID mismatch will NOT resolve the issue.

Clarification:
This behavior is expected when underlying identity and inventory data remain inconsistent.

---

Additional Contributing Factors

Registry Artifacts (Common in migrations)

Stale entries under:

HKLM\Software\Altiris\Communications\Servers

HKLM\Software\Altiris\Communications\ConnectionProfiles

Example:

• Old hostname
• Deprecated port (e.g., 444)

These can trigger automatic recreation of the duplicate profile.

---

Log Errors Explanation

Tickle and decryption errors are "side effects", not the root cause.

They occur because:

• Symantec Management Agent (SMA or Altiris Agent) encrypts data using one identity (GUID/key)
• SMP Server attempts to decrypt using a different identity

Result:

• Decryption failure
• Task communication issues

 

Resolution

Follow the steps in the order below.

Table of Contents

• Step 1 – Validate GUID Consistency
  • 1. Agent GUID (on your SMP Server)
  • 2. Core Setting (NSResourceGuid)
  • 3. Database Value
• Step 2 – Correct GUID Mismatch
• Step 3 – Remove Duplicate Profile
• Step 4 – Clean Registry (Prevent Recreation)
• Step 5 – Validate Fix
• Important Notes
• Additional Recommendations (Migration Scenarios)
• Troubleshooting Summary

Step 1 – Validate GUID Consistency

Verify the following values:

1. Symantec Management Agent (SMA) GUID (on your SMP Server)

• Open Symantec Management Agent UI
• Go to Agent Settings
• Record Computer ID value

2. Core Setting (NSResourceGuid)

1. Navigate to:
   Settings > Notification Server > Core Settings

    
2. Search for:
   
   NSResourceGuid
   
   
3. Record its Value

3. Database Value

1. Run the following query against your Symantec CMDB database:
   
   select * from ServerSettingGuids
where Name = 'NSResourceGuid'
2. Take note of the Result

    

    

Expected Results from all 3 Values

All three values must be identical

---

Step 2 – Correct GUID Mismatch

If values are different:

• Update CoreSettings.config
  
  1. Navigate to:
     Settings > Notification Server > Core Settings
  2. Search for:  NSResourceGuid
  3. Replace NSResourceGuid with SMA GUID (Computer ID) 
     
     
• Update Database
  
  Run the following query against your database:
  
  update ServerSettingGuids
set value = 'SMA_GUID' --Replace it with the SMA GUID (Computer ID)
where Name = 'NSResourceGuid'

Restart Services

• Altiris Service
• Symantec Management Agent
• Altiris Object Host Service
• Altiris Client Task Data Loader Service

---

Step 3 – Remove Duplicate Profile

Browse to Settings > Agents / Plug-ins > Symantec Management Agent Communication Profiles > Site Server Communication profiles

1. Identify the correct duplicate profile (be sure that this profile is not currently in use by agents/site servers)
2. Right-click on the communication profile and select "Properties"
3. Copy the GUID of the communication profile
4. Paste the following query into SQL and run, replacing the capitalized section with the appropriate GUID:
   
   Update Item
set Attributes = 0
where Guid = 'GUID OF PROFILE TO DELETE'
   
   
5. Go back to the communication profile page, refresh, and you can then right-click and delete the profile

IF the delete option is still not available after running the query above, try the following: 

Check that the Attributes is 0:

select Attributes, * from Item
where Guid = 'GUID OF PROFILE TO DELETE'

If Attributes are NOT 0, go back to step 4 above and set the Attributes to 0 again.  If Attributes are 0, add the GUID to the ItemToDelete table

insert into ItemToDelete 
select  guid, GETDATE() 
from item where guid = 'GUID OF PROFILE TO DELETE'

After the NS.Quarter Hour schedule runs which is every 15 minutes (Or execute this task manually from windows Task Scheduler on the SMP) the item should be removed from the database.

Refresh the Console and see if the Duplicate Communication Profile has been removed.

 

IF the Communication Profile is NOT visible in the console

IF the Communication Profile is not visible in the Console, your error message may say: Existing profile '' contains the same FQDN and web application path.  This indicates that the Communication Profile does not have a name in the database and so it is not visible in the Console. 

To find these Duplicate Profiles run this SQL Query (exactly as shown):

select Name, GUID, State, *
from item
where State like '%<Name of the server FQDN or profile having issue>%'
order by 1

Search through the list to find the Communication Profile that does not have a name.  Use this GUID in the queries above for Step 1.

---

Step 4 – Clean Registry (Prevent Recreation)

Remove stale entries from SMP Server registry:

 

HKLM\Software\Altiris\Communications\Servers

• Delete entries referencing:
  • Old hostname
  • Deprecated ports
    
    

Clean connection profiles:

 

HKLM\Software\Altiris\Communications\ConnectionProfiles

• Remove entries matching duplicate GUID

---

Step 5 – Validate Fix

Refresh SMP Console

Send Basic Inventory

Confirm:

• Duplicate profile does NOT reappear
• No validation errors
• No tickle/decryption errors

Final Outcome

Once GUIDs are synchronized and stale references removed:

Duplicate profile will not return

Communication stabilizes

Task Server functionality is restored

---

Important Notes

Deleting the communication profile alone will NOT resolve the issue.

Always update BOTH:

• CoreSettings.config
• ServerSettingGuids table

---

Additional Recommendations (Migration Scenarios)

After off-box migration:

• Validate GUID consistency immediately
• Review registry for stale entries
• Confirm correct certificate binding (IIS 443)
• Ensure SMP Server is not incorrectly registered as a Site Server

---

Troubleshooting Summary

Symptom	Root Cause	Fix
Duplicate profile	GUID mismatch	Align GUIDs
Profile reappears	Identity + inventory mismatch	Fix GUID + registry
Tickle errors	Encryption mismatch	Fix GUID
Cannot delete profile	System attribute flag	Use SQL cleanup

 

Additional Information

How Site Server Communication Profile is populated?

Site Server Communication Profiles are not generating properly