Critical Servers Receive Patch Policies and Reboot Despite Being Added to a "Never Reboot" Exclusion Group

Products

• IT Management Suite

Issue/Introduction

Administrators reported that critical production servers were unexpectedly rebooted following a patch deployment cycle. These servers were intended to be excluded from patching and reboot actions through a dedicated Organizational Unit (OU) or Resource Target used for "never reboot" systems.

Despite being designated as excluded systems, the affected servers received the patch policy and the associated reboot action.

Symptoms

You may observe one or more of the following:

• Servers unexpectedly receive patch policies.
• Servers configured as "never reboot" systems restart following a maintenance cycle.
• Patch policies appear to ignore exclusion groups.
• Resource Target membership does not appear to reflect recent group membership changes.
• Critical servers receive deployments before administrators finish updating organizational groups.

Environment

ITMS (IT Management Suite) 8.7.x, 8.8.x

Patch Management Solution

Resource Targets, Organizational Groups / Organizational Views

Cause

In IT Management Suite (ITMS), resource target membership calculations are not performed in real time. Membership updates occur asynchronously through scheduled collection updates and target recalculations.

In environments where patch policies rely primarily on exclusion-based targeting, a timing gap can occur between:

1. A computer resource being discovered, imported, or manually created.
2. The resource being added to the exclusion group.
3. The exclusion group's membership being propagated to the final Resource Target.

If the managed computer requests policies during this window, the target evaluation engine may not yet recognize that the resource belongs to the exclusion group. As a result, the computer may temporarily qualify for the patch policy and receive patch deployment and reboot instructions.

This behavior is most commonly observed in environments where exclusion groups are maintained manually and membership updates are dependent on scheduled processing.

 

Possible Causes

1. Resource Target Membership Timing Gap

Resource Target membership calculations are processed asynchronously.

A timing gap may occur when:

1. A computer resource is discovered or imported.
2. The computer requests policy updates.
3. The exclusion group has not yet been recalculated.
4. The Resource Target cache has not yet been refreshed.

During this period, the resource may temporarily qualify for the patch policy.

2. Manual Population of Exclusion Groups

Many environments maintain exclusion groups manually.

Example:

Hosting Servers - Windows

When administrators manually add systems after deployment or onboarding activities, a delay may exist before the updated membership is reflected in downstream Resource Targets.

3. Duplicate Computer Resources

Duplicate computer resources can complicate target evaluation and troubleshooting.

Administrators should verify that multiple computer records do not exist for the same endpoint.

Possible indicators include:

• Multiple resources with identical names
• Historical discovery records
• Legacy imports from previous years
• Resources with different GUIDs representing the same system

While duplicate resources are not necessarily the root cause, they can make target evaluation behavior more difficult to validate.

4. Stale or Inactive Target Membership

If a Resource Target displays a red icon in the Enhanced Console View (ECV), the target may not be actively associated with an enabled policy.

In these situations, membership data may not be refreshed as frequently as expected and administrators should validate the current target status before troubleshooting further.

Resolution

Recommendation 1: Move from Exclusion Logic to Inclusion Logic

Broadcom Support and Engineering recommend using inclusion-based targeting whenever possible.

Less Preferred Approach

All Windows Servers
EXCEPT
Hosting Servers - Windows

Recommended Approach

Production Group A
Production Group B
Production Group C

Only systems explicitly added to approved deployment groups receive the policy.

Benefits

• Provides a fail-safe default state.
• Prevents newly discovered systems from being targeted unexpectedly.
• Reduces dependency on exclusion group timing.
• Simplifies troubleshooting.

---

Recommendation 2: Validate Organizational Group Membership

Verify that the affected system appears in the intended exclusion group.

Steps

1. Open the SMP Console.
2. Navigate to:

Manage > Organizational Views

3. Locate the applicable organizational group.
4. Open the group properties.
5. Confirm the affected server is present.
6. Verify when the membership was added.

As well, from Resource Manager you can verify the affected production computer in what Organizational groups it is in and when that organizational group was modified. 

---

Recommendation 3: Review Resource Audit History

The Audit History can help determine when group membership changes occurred.

Steps

1. Open the SMP Console.
2. Navigate to:

Manage > Organizational Views

3. Right-click the affected Organizational Group.
4. Select Properties.
5. Open the Audit tab.
6. Review membership changes within the relevant time period.
   
   

Review:

• Who modified the group
• When the change occurred
• Whether the change happened before or after the patch deployment

 

---

Recommendation 4: Investigate Duplicate Resources

Steps

1. Open Resource Manager.
2. Search for the affected server.
3. Verify that only one active resource exists.
4. Review historical discovery records.
5. Remove or merge duplicate resources when appropriate.

Validate:

• Computer Name
• Resource GUID
• Discovery source

---

Validation

After implementing changes:

1. Confirm the server appears in the correct organizational group.
2. Confirm Resource Target membership has been updated.
3. Verify the patch policy no longer applies to the excluded system.
4. Run a test policy update on the endpoint.
5. Confirm no patch deployment policy is received.

Expected Result:

The server does not receive the patch deployment policy and no reboot action is initiated.

---

Troubleshooting Matrix

Symptom	Possible Cause	Recommended Action
Excluded servers receive patch policies	Membership timing gap	Move to inclusion-based targeting
Newly created servers receive policies unexpectedly	Target recalculation delay	Verify group membership propagation
Resource Target does not reflect recent changes	Membership cache not refreshed	Validate collection and target updates
Isolated systems ignore exclusions	Duplicate resources	Review and clean duplicate records
Resource Target displays red icon	Inactive or disabled policy association	Verify policy and target status

---

Advanced Troubleshooting (Optional)

Important: The following information is intended for advanced troubleshooting and investigation purposes. Any database customizations, triggers, or auditing solutions are customer-owned modifications and are not officially supported by Broadcom Support. Customers should fully test any database customization in a non-production environment before implementation.

Internal Membership Processing Tables

The platform uses transient internal tables to process collection and Resource Target membership changes.

CollectionMembershipChanges

Tracks membership changes at the collection or organizational group level.

Column	Description
Id	Unique transaction identifier
CollectionGuid	Collection or group GUID
ResourceGuid	Resource GUID
Removed	0 = Added, 1 = Removed

 

ResourceTargetMembershipCacheChanges

Tracks membership changes at the final Resource Target level.

Column	Description
Id	Unique transaction identifier
ResourceTargetGuid	Resource Target GUID
ResourceGuid	Resource GUID
Removed	0 = Added, 1 = Removed

Because these tables are transient and processed by the platform, historical data may not remain available for long-term investigation.

NOTE:
Organizations requiring historical tracking may choose to implement their own auditing solution using SQL-based monitoring or custom logging. Such implementations, like creating your own tables or/and triggers, are customer-managed and outside the scope of Broadcom Support troubleshooting.

Database triggers can introduce additional overhead because they execute whenever the underlying table is modified. The performance impact varies depending on the volume and frequency of changes, which is why triggers are generally avoided unless there is a specific requirement that cannot be addressed through other means.

In this particular case, the ResourceTargetMembershipCacheChanges table is already populated by the built-in trigger trgMonitorResourceTargetMembership. Adding another trigger to process data generated by an existing trigger is technically possible, but it introduces additional complexity and should be carefully evaluated.

It is also important to understand that ResourceTargetMembershipCacheChanges is a temporary working table. Entries are processed and removed by the SMP services as membership changes are detected and internal caches are updated. The table is not intended to serve as a long-term audit repository.

If a custom audit table is implemented, consideration should be given to data growth and maintenance. Large-scale target membership recalculations can generate a significant number of records, potentially resulting in millions of rows over time. A strategy for retention, cleanup, and ongoing maintenance should be established before implementing such a solution.

For most environments, detailed historical tracking of every target membership change is not required. Solutions of this type are typically intended for troubleshooting or short-term auditing scenarios rather than as a permanent component of the SMP infrastructure.

---

Additional Considerations

• Resource Target memberships are calculated asynchronously.
• Manual group population introduces administrative timing dependencies.
• Inclusion-based targeting provides a safer operational model for critical systems.
• Duplicate resources should always be investigated when target membership behavior appears inconsistent.
• Audit History should be reviewed whenever membership timing is suspected.

Additional Information

IT Management Suite Documentation

https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint-security-and-management/it-management-suite/ITMS.html

Resource Targets Documentation

https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint-security-and-management/it-management-suite/ITMS/Administration/Configuring-Resource-Filters-and-Targets/about-resource-targets-v18722401-d846e16487.html