Home configuration management it management microsoft endpoint manager system administration

Configuration Manager: Preventing Overwrites to Built-in Collection Changes

Updated: • 0 • min read
Table of Contents

Upgrading Microsoft System Center 2012 Configuration Manager (SCCM) environments can present various challenges, particularly when custom configurations interact with core system components. A notable issue encountered by administrators during the transition to System Center 2012 Configuration Manager Service Pack 1 (SP1) involves the unexpected resetting of built-in collection settings. This article delves into the specifics of this problem, explains its underlying cause, and provides a comprehensive workaround to safeguard your customized collections during the upgrade process. Understanding the fundamental changes introduced in SP1 regarding collection behavior is crucial for maintaining a stable and efficiently managed SCCM infrastructure.

System Center Configuration Manager Collections

Understanding the Problem: Symptoms of Collection Overwrite

The primary symptom of this issue manifests during the prerequisite check phase of the System Center 2012 Configuration Manager SP1 upgrade. If an administrator has previously modified one or more of the built-in collections in their System Center 2012 Configuration Manager installation, the setup process will detect these alterations. Consequently, a specific warning message is displayed, alerting the user to potential data loss.

The warning message typically states:

“One or more of the built-in collections has been modified. If you ignore this warning, these modifications will be overwritten by Configuration Manager setup.”

Should an administrator proceed with the upgrade despite this warning, the built-in collections that were previously modified will be reverted to their default, out-of-the-box settings. This automatic reset occurs as part of the upgrade routine, effectively erasing any custom queries, membership rules, or other configurations applied to these foundational collections. This can lead to significant operational disruptions, as deployments, policies, and reports relying on these customized built-in collections will no longer function as intended.

The Root Cause: Architectural Shift in SP1

The reason for this behavior lies in a fundamental design change implemented in System Center 2012 Configuration Manager SP1. In the original release of System Center 2012 Configuration Manager, administrators possessed the flexibility to modify certain built-in collections directly. While this offered a degree of customization, it also introduced potential instability, as accidental or unmanaged changes to these critical system objects could inadvertently impact core functionalities.

With the release of SP1, Microsoft adopted a more restrictive approach regarding built-in collections. In System Center 2012 Configuration Manager SP1, built-in collections are designed to be read-only by default. This change was likely introduced to enhance the stability, predictability, and integrity of the Configuration Manager environment. By making these core collections immutable, the system ensures that critical operations remain consistent and are not inadvertently broken by unauthorized or unintended modifications. Therefore, when the SP1 upgrade routine encounters a built-in collection that deviates from its default, read-only state, it forcibly resets it to comply with the new architectural design.

Deep Dive into SCCM Collections

To fully appreciate the impact of this issue, it’s essential to understand the pivotal role collections play within System Center Configuration Manager. Collections are logical groupings of users or devices, serving as the cornerstone for targeting management operations. They enable administrators to define specific sets of resources to which various SCCM functionalities—such as software deployments, compliance settings, operating system deployments, and client settings—are applied.

Types of Collections

SCCM primarily utilizes two types of collections:
* Device Collections: These collections contain computers, servers, and other network-connected devices managed by SCCM. They are crucial for deploying applications to specific sets of machines or configuring device-specific policies.
* User Collections: These collections group users and are primarily used for user-centric application deployments or user state migration.

Built-in vs. Custom Collections

Built-in Collections are pre-defined groups provided by SCCM during installation. Examples include “All Systems,” “All Users,” “All Desktop and Server Clients,” and “Unknown Computers.” These collections are fundamental to the operation of Configuration Manager and are often used as a starting point for creating more granular custom collections. In System Center 2012 Configuration Manager, some of these could be directly modified, but as discussed, this behavior changed in SP1.

Custom Collections are user-defined groups tailored to specific organizational needs. Administrators create these collections based on various criteria, such as organizational unit, department, installed software, hardware specifications, or client health status. The ability to create dynamic, query-based custom collections is a powerful feature of SCCM, allowing for automated and precise targeting.

Collection Membership Rules

The membership of a collection is determined by rules, which can be configured in several ways:
* Direct Rule: Manually adding specific resources (users or devices) to a collection.
* Query Rule: Dynamically populating a collection based on a WQL (WMI Query Language) query that identifies resources meeting specific criteria from the SCCM database. This is the most common and powerful method for creating flexible collections.
* Include Collection Rule: Adding the members of another collection to the current collection.
* Exclude Collection Rule: Removing the members of another collection from the current collection.

The modification of built-in collections, often through the addition of complex query rules, could lead to unexpected behavior during the upgrade due to the SP1 read-only enforcement. This underscores the importance of managing custom configurations carefully and understanding how core system components interact with upgrades.

Comprehensive Workaround Strategy

To mitigate the risk of losing custom configurations on built-in collections during the upgrade to System Center 2012 Configuration Manager SP1, a structured workaround is necessary. This strategy involves proactive identification, careful preservation, and post-upgrade recreation of your custom settings.

Phase 1: Pre-Upgrade Preparation and Identification

Before initiating the upgrade to SP1, it is imperative to identify and document any modifications made to built-in collections. This phase is critical for ensuring no custom configurations are lost.

  1. Identify Modified Built-in Collections:

    • Open the Configuration Manager console.
    • Navigate to Assets and Compliance > Device Collections or User Collections.
    • Review the properties of built-in collections (e.g., “All Systems,” “All Users”). Look specifically for changes in the Membership Rules tab. Any added query rules, direct rules, or include/exclude rules indicate a modification from the default.
    • Recommendation: Focus on collections that show a “Type” of “Built-in” and have a custom icon or any indication of modification.

  2. Document Custom Changes:

    • For each identified modified built-in collection, thoroughly document its custom membership rules.
    • If query rules are used, copy the exact WQL query text.
    • If direct rules, list the specific resources added.
    • Note any other relevant settings, such as limiting collections or schedules.
    • Tip: Screenshots can be invaluable for visual reference during recreation.

  3. Copy the Modified Built-in Collections:

    • The most effective way to preserve your custom logic is to create new custom collections that replicate the functionality of your modified built-in ones.
    • Method 1: Manual Recreation:
      • Create a new device or user collection (e.g., “My Custom All Systems”).
      • Manually add the exact same membership rules (queries, direct rules, include/exclude rules) that were present in the modified built-in collection.
      • Ensure the limiting collection and refresh schedule are also replicated accurately.
    • Method 2 (Advanced): Export/Import (Limited Use for Built-in): While SCCM allows exporting custom collections, directly exporting a modified built-in collection can be problematic due to its protected nature. However, once you’ve copied the rules to a new custom collection, that new custom collection can be exported as a Managed Object Format (MOF) file for backup. This MOF file can then be imported post-upgrade.
    • Important: After creating these new custom collections, update any existing deployments, task sequences, or configuration baselines that previously targeted the modified built-in collections to now target these new custom collections. This ensures continuity of service during the upgrade and makes the transition seamless.

  4. Perform a Full SCCM Database Backup:

    • Before any major SCCM upgrade, performing a complete backup of your Configuration Manager site database is a critical best practice. This provides a rollback point in case of unforeseen issues during the upgrade process.

Phase 2: The Upgrade Process

With your custom collection configurations safely transferred to new custom collections and your environment thoroughly backed up, you can proceed with the System Center 2012 Configuration Manager SP1 upgrade.

  1. Initiate the Upgrade: Run the SP1 setup wizard.
  2. Acknowledge the Warning: During the prerequisite check, you will likely encounter the warning message about modified built-in collections. Since you have already copied these configurations to new custom collections, you can safely ignore this warning and proceed with the upgrade. The built-in collections will be reset, but your critical configurations are now protected within your custom collections.
  3. Monitor the Upgrade: Closely monitor the upgrade process to ensure it completes without errors.

Phase 3: Post-Upgrade Remediation and Verification

Once the upgrade to SP1 is complete, you will need to verify the state of your environment and potentially finalize the transition.

  1. Verify Built-in Collections are Reset:
    • After the upgrade, open the Configuration Manager console and check the properties of the built-in collections. You should observe that they have reverted to their default, read-only settings, and any previous custom modifications are no longer present.
  2. Verify New Custom Collections Functionality:
    • Confirm that your newly created custom collections are populating correctly and accurately reflecting the membership rules you configured.
    • Verify that deployments, policies, and task sequences that were re-targeted to these new custom collections are functioning as expected.
  3. Clean Up (Optional but Recommended):
    • Consider removing any lingering references to the old, modified built-in collections if they are no longer needed, to prevent confusion.
    • Review your overall SCCM environment to ensure all components are healthy and operational.

Best Practices for SCCM Collection Management

The issue of built-in collection overwrites highlights several best practices that administrators should adopt for robust SCCM management:

  • Avoid Modifying Built-in Collections: As a general rule, it is highly recommended to never modify built-in collections. Instead, create custom collections for all your specific targeting needs. This provides greater flexibility, prevents unexpected issues during upgrades, and simplifies troubleshooting.
  • Leverage Custom Collections Extensively: Design your collection structure around custom collections. Use query rules to create dynamic groups based on your organizational hierarchy, device types, software installations, or any other relevant criteria.
  • Document Everything: Maintain comprehensive documentation of your SCCM configuration, especially custom collections, deployments, and settings. This ensures that you can always recreate your environment if necessary and aids in knowledge transfer.
  • Test in a Lab Environment: Before performing any major SCCM upgrade or significant configuration change in a production environment, always test it thoroughly in a dedicated lab environment that mirrors your production setup. This allows you to identify and resolve potential issues without impacting live operations.
  • Regular Database Backups: Implement a robust database backup strategy for your SCCM site database. Regular, verified backups are your last line of defense against data loss and ensure rapid recovery in disaster scenarios.
  • Understand SCCM Version Changes: Stay informed about the changes and new features introduced in each SCCM (now Microsoft Endpoint Configuration Manager - MECM) version and service pack. Understanding these architectural shifts can prevent unexpected issues during upgrades.

The Evolution of Configuration Manager

The behavior observed with System Center 2012 Configuration Manager SP1 regarding built-in collections is a testament to the continuous evolution of Microsoft’s management solutions. This shift towards making core components more immutable for stability purposes carried forward into later iterations. Microsoft Endpoint Configuration Manager (MECM), the successor to SCCM, continues to emphasize a robust, reliable foundation, with a strong focus on cloud integration and a faster release cadence. Lessons learned from issues like the collection overwrite helped shape the design principles for future versions, ensuring a more predictable and secure management platform for enterprises worldwide. By adhering to best practices and understanding the nuances of each version, administrators can effectively leverage MECM to manage their diverse endpoint environments.

This issue underscores the importance of thorough planning and understanding the implications of system changes during upgrades. By adopting the workaround described and integrating best practices into your daily SCCM operations, you can ensure a smoother, more reliable management experience.

Have you encountered similar challenges during SCCM upgrades? What strategies or best practices have you found most effective in managing your Configuration Manager collections? Share your experiences and insights in the comments below!

Post a Comment