SCCM Console Workspaces

💻 SCCM Devices & Collections

🗂 Devices

Devices show all systems managed by SCCM. [cite: 27, 28] You can:

• View inventory
• Run client actions
• Check client health
• Deploy apps and updates

📖 What are Collections in SCCM?

In SCCM, Collections are logical groupings of users or devices (computers). [cite: 28, 29] They are used to target deployments like applications, updates, OS, configuration baselines, and more.

• Device Collections: based on devices (workstations, servers)
• User Collections: based on Active Directory user accounts

⚙ How Collections Work

Rule Type	Description
Direct Rule	Manually add specific devices/users
Query Rule	Dynamically include members based on criteria
Include/Exclude Rule	Include or exclude other collections

💻 Step-by-Step: Create a Device Collection

1. Open SCCM Console: Assets and Compliance → Device Collections
2. Right-click → Create Device Collection
3. General Tab:
   • Name: Windows 10 Workstations
   • Limiting Collection: All Systems
4. Membership Rules → Click Add Rule:
   • Direct Rule: manually select devices
   • Query Rule: dynamic based on criteria
5. Example Query:

   Attribute class: System Resource
   
   Attribute: Operating System Name and Version
   
   Operator: is like
   
   Value: %Windows 10%
               

6. Complete the wizard → Update Membership after creation

👤 Create a User Collection

1. Go to: Assets and Compliance → User Collections
2. Right-click → Create User Collection
3. Limiting Collection: All Users
4. WQL Query Example:

   SELECT * FROM SMS_R_User 
   WHERE SMS_R_User.UserGroupName = "DOMAIN\\GroupName"
               

🔍 Example: Windows 11 Devices Query

SELECT * FROM SMS_R_System
WHERE SMS_R_System.OperatingSystemNameandVersion LIKE "%Windows 11%"
    

✅ Best Practices

• Use clear naming (e.g., COL-Apps-Win10)
• Use incremental updates for dynamic collections
• Avoid full updates unless needed
• Test with pilot collections before wide deployment
• Limit use of Direct Rules

🐚 Common Issues & Troubleshooting

Issue	Resolution
Collection not updating	Use Update Membership, check if incremental is enabled
Device not showing	Check WQL query and discovery methods
Duplicate devices	Clean up client duplicates in SCCM
Slow collection updates	Simplify WQL queries

🎯 Bonus Tips

• Use collections to stage deployments: Pilot → Test → Production
• Use maintenance windows with collections
• Assign collection variables for task sequences
• Never deploy to All Systems or All Users directly

← Hide Details

💊 Client Health Monitoring

💾 Overview

This section allows you to monitor the health and activity of SCCM clients in your environment. [cite: Microsoft Docs on Client Health]

Ensuring client health is critical for successful SCCM management. Healthy clients can reliably receive policies, install software, and report inventory.

💾 Key Monitoring Capabilities

SCCM provides several tools to monitor client health:

• Client Health Status: Provides an overview of client health in the environment.
• Client Activity: Tracks client communication with the SCCM site.
• Client Check Results: Shows the results of client health evaluation.
• Client Remediation: Automates the process of fixing unhealthy clients.
• Client Deployment Status: Monitors the deployment of the SCCM client agent.

⚙ Client Health Evaluation

SCCM performs client health evaluation to assess the state of the client agent and its dependencies.

This evaluation involves a series of checks to ensure that the client is functioning correctly.

💻 Configuration Steps: Configuring Client Health Settings

1. Open SCCM Console: Go to Administration → Client Settings.
2. Select or Create Client Settings:
   • You can either modify the Default Client Settings or create a new custom client settings policy. Creating a custom policy allows you to apply specific health settings to a subset of your clients (e.g., a test group).
   • To create a custom policy, right-click and select Create Custom Client Device Settings.
3. Select Client Health: In the settings policy (either Default or custom), select Client Health.
4. Configure Settings:
   • Enable Client Health Evaluation: Ensure this setting is enabled (usually it is by default).
   • Schedule Client Health Evaluation:
     • Set the schedule for how often clients perform health checks.
     • You can configure a simple schedule (e.g., every day) or a custom schedule.
     • Consider the impact of frequent evaluations on client performance and network traffic.
   • Engine Failure Thresholds:
     • Configure the thresholds for client health failures that will trigger alerts or remediation actions.
   • Remediation:
     • Enable Automatic Remediation: SCCM can automatically attempt to fix certain client health problems. You can enable or disable this.
     • Remediation Actions: SCCM has built-in remediation actions, such as restarting services or repairing the client agent.
   • System Center Endpoint Protection:
     • If you use Endpoint Protection with SCCM, you can configure client health settings related to antimalware.
5. Deploy Custom Client Settings (if applicable):
   • If you created a custom client settings policy, you need to deploy it to a collection.
   • Right-click the custom settings policy and select Deploy.
   • Choose the target collection.

✅ Best Practices for Client Health

• Regular Monitoring: Regularly review the client health dashboard in the SCCM console to identify any trends or issues.
• Start with Default Settings: Begin by using the default client health settings and adjust them as needed based on your environment.
• Phased Deployment of Changes: If you make significant changes to client health settings, deploy them to a test collection first to assess the impact.
• Address Inactive Clients: Investigate and address inactive clients promptly. They may indicate network connectivity issues, client agent problems, or machines that are no longer in use.
• Review Client Logs: Use the SCCM client logs on individual machines to troubleshoot specific client health issues.
• Balance Frequency: Balance the frequency of client health evaluation with the need to minimize performance impact.

🐚 Troubleshooting Client Health

• Clients Reporting as Unhealthy:
  • Check the client logs for specific error messages.
  • Verify network connectivity between the client and the SCCM site.
  • Ensure that the client agent services are running.
  • Check for conflicting software or policies.
• Clients Not Reporting:
  • Verify client agent installation.
  • Check client-to-management point communication.
  • Check network discovery.
• Excessive Client Activity:
  • Review the client health evaluation schedule.
  • Check for any custom scripts or applications that might be causing excessive client activity.
• Remediation Failures:
  • Examine the client logs to determine why remediation actions failed.
  • Ensure that the client has sufficient permissions to perform remediation tasks.

← Hide Details

👷 Compliance Settings (CIs & Baselines)

💾 Overview

Compliance Settings in SCCM allow you to assess, track, and remediate the configuration of devices and users in your environment. [cite: Microsoft Docs on Compliance Settings]

This is crucial for ensuring that systems meet your organization's security, software, and configuration requirements.

💾 Key Components

Compliance Settings rely on these core components:

• Configuration Items (CIs): Represent a specific setting or condition that you want to evaluate.
• Configuration Baselines: Groups of CIs that define a desired configuration state.
• Compliance Rules: Within CIs, rules specify the criteria for compliance.
• Remediation: Actions that SCCM can take to automatically correct non-compliant settings.
• Compliance States: The result of an evaluation (e.g., compliant, non-compliant).

⚙ How Compliance Settings Work

1. Create CIs: You define CIs to represent the settings you want to manage (e.g., a registry key, a file version, a service state).
2. Create Baselines: You group CIs into baselines to represent a complete configuration policy (e.g., "Windows 10 Security Baseline").
3. Deploy Baselines: You deploy baselines to collections of users or devices.
4. Evaluate Compliance: SCCM clients evaluate their settings against the CIs in the deployed baselines.
5. Report Compliance: SCCM reports the compliance state of each client.
6. Remediate (Optional): SCCM can automatically remediate non-compliant settings if you've configured remediation.

💻 Configuration Steps: Creating a Configuration Baseline

1. Open SCCM Console: Go to Assets and Compliance → Compliance Settings → Configuration Baselines.
2. Create Baseline: Right-click → Create Configuration Baseline.
3. General Tab:
   • Name: Provide a descriptive name (e.g., "Windows Firewall Settings Baseline").
   • Description: (Optional) Add details about the baseline's purpose.
4. Configuration Items: Click Add → Choose the type of CI you want to add:
   • Existing Configuration Item: Select a CI that you've already created.
   • Create/Import Configuration Item: Create a new CI or import one.
   • **Software Updates:** Add compliance rules for software updates.
5. CI Settings (Example): If creating a CI for a registry setting:
   • General:
     • Name: (e.g., "Firewall Profile Enabled").
     • Description: (Optional).
   • Settings:
     • Setting Type: Choose "Registry Value".
     • Hive: Select the registry hive (e.g., "HKEY_LOCAL_MACHINE").
     • Key: Specify the registry key path.
     • Value: Enter the registry value name.
     • Data Type: Select the data type of the value (e.g., "REG_DWORD").
   • Compliance Rules:
     • Click New to create a rule.
     • Name: (e.g., "Ensure Firewall Domain Profile is Enabled").
     • Rule Type: Choose "Value".
     • Operator: Select the comparison operator (e.g., "Equals").
     • Value: Enter the expected value (e.g., "1" for enabled).
     • Non-compliance Severity: Choose the severity level if the setting is non-compliant.
     • Remediate noncompliance when supported: Check this box to enable automatic remediation (if possible).
6. Deployment: Deploy the baseline to a collection:
   • Right-click the baseline and select Deploy.
   • Choose the target collection.
   • Configure the evaluation schedule.

✅ Best Practices for Compliance Settings

• Plan Carefully: Before creating CIs and baselines, carefully plan your desired configuration and the settings you need to manage.
• Modular Design: Create smaller, modular baselines for specific areas of configuration (e.g., "Password Policy Baseline," "Antivirus Settings Baseline"). This makes them easier to manage and update.
• Descriptive Names: Use clear and descriptive names for CIs and baselines.
• Test Thoroughly: Always test baselines in a lab environment before deploying them to production.
• Use Remediation Wisely: Automatic remediation can be very helpful, but use it cautiously. Ensure you understand the potential impact of remediation actions.
• Monitor Compliance: Regularly monitor the compliance reports to identify non-compliant systems and take corrective action.

🐚 Troubleshooting Compliance Settings

• Clients Reporting Non-Compliant:
  • Verify the CI settings and compliance rules.
  • Check the client logs for errors.
  • Ensure that the baseline is deployed to the correct collection.
  • Check for conflicting policies.
• Remediation Not Working:
  • Not all settings can be automatically remediated. Check the CI properties to see if remediation is supported.
  • Ensure that the client has the necessary permissions to make changes.
  • Review the client logs for remediation errors.
• Baselines Not Evaluating:
  • Verify that the baseline is deployed and that the evaluation schedule is configured.
  • Check client-to-management point communication.
• **Performance Issues:**
  • Complex or large baselines can impact client performance. Design baselines efficiently.
  • Avoid overly frequent evaluation schedules.

← Hide Details

🔐 BitLocker and Endpoint Protection

💾 Overview

This section allows you to manage and monitor disk encryption using BitLocker and endpoint security through Endpoint Protection (if integrated with SCCM). [cite: Microsoft Docs on BitLocker Management, Microsoft Docs on Endpoint Protection]

These features are crucial for protecting your organization's data and systems from unauthorized access and malware.

💾 BitLocker Management

BitLocker Drive Encryption helps protect data by encrypting entire volumes. SCCM provides tools to manage BitLocker policies and recovery.

💾 Endpoint Protection

Endpoint Protection (if you have it integrated with SCCM) provides antimalware capabilities to help protect clients from viruses, spyware, and other threats.

⚙ How BitLocker Management Works

1. Configure BitLocker Policies: You create and deploy policies that define BitLocker settings (e.g., encryption methods, key protectors).
2. Deploy Policies: SCCM deploys the BitLocker policies to targeted collections.
3. Encrypt Drives: Clients apply the policies and encrypt their drives.
4. Manage Recovery: SCCM helps you manage BitLocker recovery keys, which are essential for recovering data if a drive is locked.
5. Monitor Compliance: SCCM reports on the BitLocker encryption status of your clients.

⚙ How Endpoint Protection Works

1. Deploy Antimalware Policies: You create and deploy policies that define antimalware settings (e.g., real-time protection, scans, updates).
2. Install Client: The Endpoint Protection client software is installed on managed devices.
3. Protect Clients: The client software provides real-time protection, scans for malware, and updates its definitions.
4. Monitor Status: SCCM reports on the antimalware status of your clients, including detected threats and protection levels.
5. Remediate Threats: SCCM helps you respond to malware threats and take remediation actions.

💻 Configuration Steps: Configuring BitLocker Management

1. Open SCCM Console: Go to Assets and Compliance → Endpoint Protection → BitLocker Management.
2. Create BitLocker Management Policy: Right-click → Create BitLocker Management Policy.
3. Recovery:
   • Configure how recovery information is stored (e.g., in the SCCM database, Active Directory). Storing recovery information securely is critical!
   • Choose which recovery methods are available to users.
4. OS Drive:
   • Configure settings for encrypting the operating system drive.
   • Specify the encryption method and cipher strength.
   • Configure key protectors (e.g., TPM, password).
5. Fixed Data Drive:
   • Configure settings for encrypting fixed data drives (e.g., hard drives other than the OS drive).
6. Removable Data Drive:
   • Configure settings for encrypting removable data drives (e.g., USB drives).
   • You can enforce BitLocker To Go policies.
7. Compliance:
   • Configure compliance settings and how non-compliance is reported.
8. Deploy Policy: Deploy the BitLocker Management Policy to a collection of devices.

💻 Configuration Steps: Configuring Endpoint Protection

1. Open SCCM Console: Go to Assets and Compliance → Endpoint Protection → Antimalware Policies.
2. Create Antimalware Policy: Right-click → Create Antimalware Policy.
3. General Settings:
   • Provide a name and description for the policy.
4. Real-time Protection:
   • Configure real-time protection settings, such as behavior monitoring and network inspection.
5. Scan Settings:
   • Configure scheduled scans, including scan type and schedule.
6. Update Settings:
   • Configure how the Endpoint Protection client receives definition updates (e.g., from SCCM, Microsoft Update).
7. Default Actions:
   • Configure the actions to take when malware is detected (e.g., quarantine, remove).
8. Real time and scheduled exclusions:
   • Configure file and folder exclusions from real time and scheduled scans.
9. Advanced:
   • Configure advanced settings like performance options.
10. Deploy Policy: Deploy the Antimalware Policy to a collection of devices.

✅ Best Practices

BitLocker Management

• Plan Recovery Carefully: Carefully plan how you will store and manage BitLocker recovery keys. Secure storage is paramount!
• Test Policies: Test BitLocker policies in a lab before deploying them to production.
• Phased Deployment: Deploy BitLocker in phases to minimize disruption.
• Monitor Compliance: Regularly monitor BitLocker compliance to ensure that drives are properly encrypted.

Endpoint Protection

• Keep Definitions Updated: Ensure that antimalware definitions are updated frequently.
• Regular Scans: Schedule regular scans to detect malware.
• Monitor Alerts: Monitor antimalware alerts and respond to threats promptly.
• Exclusions (Use with Caution): Use exclusions sparingly and only when necessary, as they can reduce protection.

🐚 Troubleshooting

BitLocker Management

• Encryption Issues: Check the client logs for errors during encryption.
• Policy Application: Verify that the BitLocker policy has been applied to the client.
• Recovery Problems: Test the recovery process to ensure that you can recover data.

Endpoint Protection

• Malware Detections: Investigate malware detections and take appropriate remediation actions.
• Update Failures: Troubleshoot definition update failures.
• Client Issues: Troubleshoot issues with the Endpoint Protection client software.
• **Performance Issues:**
  • Excessive scans can impact client performance. Optimize scan schedules.

← Hide Details

👤 User Discovery & Client Remediation

💾 Overview

This section covers how SCCM discovers user accounts in your environment and how it addresses issues with the SCCM client agent. [cite: Microsoft Docs on User Discovery, Microsoft Docs on Client Remediation]

User discovery is essential for deploying software and configurations to users, while client remediation ensures that SCCM can effectively manage devices.

💾 User Discovery

User discovery methods find user accounts in Active Directory or Azure AD, making them available in SCCM.

💾 Client Remediation

Client remediation involves identifying and fixing problems with the SCCM client agent on managed devices.

⚙ How User Discovery Works

SCCM uses various methods to discover user accounts:

• Active Directory User Discovery: Queries Active Directory for user objects based on specified containers or organizational units (OUs).
• Azure AD User Discovery: Discovers user accounts in Azure Active Directory, which is useful for hybrid or cloud-managed environments.

Discovered user accounts can then be used in user collections for targeted deployments.

⚙ How Client Remediation Works

SCCM can automatically or manually remediate client agent issues:

• Automatic Remediation: SCCM can automatically attempt to repair client health issues based on predefined criteria.
• Manual Remediation: Administrators can manually initiate client repair actions from the SCCM console.

💻 Configuration Steps: Configuring Active Directory User Discovery

1. Open SCCM Console: Go to Administration → Overview → Hierarchy Configuration → Discovery Methods.
2. Configure Active Directory User Discovery: Right-click Active Directory User Discovery and select Properties.
3. General Tab:
   • Enable Active Directory User Discovery: Check the box to enable the discovery method.
4. Discovery Scopes Tab:
   • Click the yellow star icon to add a discovery scope.
   • Specify the Active Directory container(s) or OU(s) to discover users from.
   • You can choose to discover users within a specific OU and its subcontainers or only within the OU itself.
5. Polling Schedule Tab:
   • Configure the schedule for how often SCCM will run the discovery method.
   • You can set a simple schedule (e.g., daily) or a custom schedule.
6. Options Tab:
   • Configure options to discover user relationships.
7. Account Tab:
   • Specify the account that SCCM will use to query Active Directory.
8. Click OK to save the configuration.

💻 Configuration Steps: Configuring Client Health Evaluation and Remediation

*(Note: These steps are similar to those in the "Client Health Monitoring" section, but I'll reiterate them here for completeness.)*

1. Open SCCM Console: Go to Administration → Client Settings.
2. Select or Create Client Settings: Choose the Default Client Settings or create a custom client device settings policy.
3. Select Client Health: In the settings policy, select Client Health.
4. Configure Settings:
   • Enable Client Health Evaluation: Ensure this is enabled.
   • Schedule Client Health Evaluation: Set the schedule for health checks.
   • Engine Failure Thresholds: Configure thresholds for failures.
   • Remediation:
     • Enable Automatic Remediation: Enable or disable automatic repair.
     • Remediation Actions: SCCM has built-in repair actions.
5. Deploy Custom Client Settings (if applicable): Deploy custom settings to a collection.

✅ Best Practices

User Discovery

• Scope Discovery: Carefully scope your Active Directory User Discovery to avoid discovering unnecessary accounts. Discovering too many objects can impact performance.
• Regular Discovery: Schedule user discovery to run regularly to ensure that SCCM has up-to-date information.
• Account Permissions: Use an account with appropriate permissions for Active Directory User Discovery.

Client Remediation

• Monitor Client Health: Regularly monitor client health to identify and address issues.
• Phased Remediation: If possible, test remediation settings in a lab or pilot environment before applying them broadly.
• Review Client Logs: Use client logs to troubleshoot remediation failures.

🐚 Troubleshooting

User Discovery

• Users Not Discovered:
  • Verify that Active Directory User Discovery is enabled.
  • Check the discovery scope configuration.
  • Ensure that the discovery schedule is configured.
  • Verify the account permissions.
  • Review the SCCM logs for discovery errors.
• Discovery Performance Issues:
  • Reduce the scope of discovery if possible.
  • Adjust the discovery schedule.

Client Remediation

• Remediation Failures:
  • Check the client logs for error details.
  • Verify that automatic remediation is enabled.
  • Ensure that the client has the necessary permissions.
• Clients Still Unhealthy:
  • Investigate the underlying cause of the client health issues.
  • Manual remediation might be necessary in some cases.

← Hide Details

🖹 Applications & Legacy Packages

💾 Overview

This section covers how SCCM manages software deployment, including both modern Applications and older Legacy Packages. [cite: Microsoft Docs on Applications, Microsoft Docs on Packages and Programs]

SCCM simplifies the process of distributing software to client computers, ensuring consistency and control.

💾 Applications

Applications are the modern way to deploy software in SCCM. They offer advanced features and flexibility.

💾 Legacy Packages

Packages and Programs are an older deployment method. While still supported, they are less flexible than Applications.

⚙ How Applications Work

1. Create Application: You define the application in SCCM, including installation files, detection methods, requirements, and deployment types.
2. Deployment Types: You can create multiple deployment types for different scenarios (e.g., MSI installer, script installer, virtual application).
3. Detection Methods: SCCM can automatically detect if the application is already installed on a client.
4. Requirements: You can specify requirements that must be met before the application is installed (e.g., operating system version, free disk space).
5. Deploy Application: You deploy the application to collections of users or devices.
6. Installation: Clients install the application, and SCCM monitors the installation status.

⚙ How Legacy Packages Work

1. Create Package: You define the package, including the files to distribute and the program to run.
2. Create Program: You define how the package should be installed (e.g., command line, installation options).
3. Distribute Content: You distribute the package content to distribution points.
4. Deploy Package: You deploy the package to collections.
5. Installation: Clients download the package and run the program to install the software.

💻 Configuration Steps: Creating an Application

1. Open SCCM Console: Go to Software Library → Application Management → Applications.
2. Create Application: Right-click → Create Application.
3. General Tab:
   • Automatically detect installation information for this application: You can select an installation file (e.g., MSI) to automatically import some information.
   • Manually specify the application information: Choose this if you want to configure all settings manually.
4. Specify information about this application:
   • Name: Provide a descriptive name for the application.
   • Publisher: (Optional) Enter the software publisher.
   • Software version: (Optional) Enter the software version.
5. Specify content location:
   • Specify the location of the installation files.
6. Specify the installation program:
   • Specify the command line to install the application.
7. Specify the uninstall program:
   • Specify the command line to uninstall the application.
8. Specify the detection method:
   • Configure how SCCM detects if the application is already installed (e.g., file existence, registry key).
9. User Experience:
   • Configure installation behavior (e.g., install for user, install for system).
10. Requirements:
    • (Optional) Specify requirements (e.g., operating system).
11. Dependencies:
    • (Optional) Specify dependencies on other applications.
12. Summary: Review the settings and complete the wizard.

💻 Configuration Steps: Creating a Legacy Package and Program

1. Open SCCM Console: Go to Software Library → Application Management → Packages.
2. Create Package: Right-click → Create Package.
3. Name: Provide a name for the package.
4. Description: (Optional) Add a description.
5. Manufacturer: (Optional) Add a manufacturer.
6. Source folder: Specify the location of the package files.
7. Create a standard program: Check this option to create a program for the package.
8. Program Name: Provide a name for the program.
9. Command line: Specify the installation command line.
10. Run: Configure how the program runs (e.g., normal, minimized).
11. Program can run: Specify whether the program can run only when a user is logged on, or whether it can run whether or not a user is logged on.
12. Drive mode: Specify whether the program requires a specific drive letter.
13. Requirements: (Optional) Specify requirements.
14. Environment: Configure environment settings.
15. Advanced: Configure advanced settings.
16. Windows Installer: Configure Windows Installer settings.
17. Distribution Settings: Configure distribution settings.

✅ Best Practices

Applications

• Use Applications for New Deployments: Whenever possible, use Applications for new software deployments. They offer more features and flexibility than Packages.
• Leverage Detection Methods: Use detection methods to avoid reinstalling software that is already present.
• Use Requirements: Use requirements to ensure that applications are only installed on supported systems.
• Plan Deployment Types: Plan your deployment types to support different scenarios (e.g., different installation methods, user vs. system context).
• Software Center: Utilize the Software Center for user-initiated installations.

Legacy Packages

• Minimize Package Usage: Limit the use of Packages to older applications that cannot be easily converted to Applications.
• Standardize Programs: Standardize your program command lines and options to ensure consistent installations.
• Document Packages: Thoroughly document your Packages, as they can be more complex to troubleshoot than Applications.

🐚 Troubleshooting

Applications

• Installation Failures:
  • Check the client logs for detailed error messages.
  • Verify the installation command line.
  • Check for any missing dependencies.
  • Ensure that the client meets the application requirements.
• Detection Issues:
  • Verify the detection method configuration.
  • Manually check if the detection criteria are met on a client.
• Deployment Issues:
  • Verify that the application is deployed to the correct collection.
  • Check the deployment status for errors.

Legacy Packages

• Installation Failures:
  • Check the client logs for error messages.
  • Verify the program command line.
  • Ensure that all necessary files are included in the package.
• Distribution Issues:
  • Verify that the package content has been successfully distributed to distribution points.
• Program Errors:
  • Check the program's exit codes for clues about the failure.

← Hide Details

📢 Software Updates (SUGs, ADRs)

💾 Overview

This section is dedicated to managing and deploying software updates to your managed devices. [cite: Microsoft Docs on Software Updates]

Keeping systems updated is crucial for security, stability, and feature enhancements. SCCM provides tools to automate and control this process.

💾 Software Update Groups (SUGs)

Software Update Groups (SUGs) are collections of software updates that you deploy together. [cite: Microsoft Docs on SUGs]

You can manually select specific updates (e.g., security patches for a particular application) and add them to a SUG.

SUGs are useful for one-time deployments or when you need precise control over which updates are installed.

💾 Automatic Deployment Rules (ADRs)

Automatic Deployment Rules (ADRs) automate the process of identifying and deploying software updates based on defined criteria. [cite: Microsoft Docs on ADRs]

ADRs reduce administrative overhead by automatically handling the selection, download, and deployment of updates.

⚙ How ADRs Work

When an ADR runs (on a schedule you define), it performs the following actions:

1. Identifies Updates: The ADR searches for new software updates in the SCCM software update catalog that match the criteria you've specified (e.g., product, classification, severity).
2. Optional: Creates or Adds to SUG: The ADR can either create a new SUG for the found updates or add them to an existing SUG.
3. Downloads Content: SCCM downloads the update files from Microsoft Update (or your WSUS server).
4. Deploys the SUG: SCCM deploys the SUG (containing the updates) to the target collections you've defined.

💻 Configuration Steps: Creating an ADR

1. Open SCCM Console: Go to Software Library → Software Updates → Automatic Deployment Rules.
2. Create ADR: Right-click → Create Automatic Deployment Rule.
3. General Tab:
   • Name: Provide a descriptive name (e.g., "Windows 10 Critical Updates - Monthly").
   • Description: (Optional) Add details about the ADR's purpose.
   • Collection: Select the target collection for the updates (e.g., "Windows 10 Workstations"). Important: Start with a test collection!
   • Deployment Settings: Configure the deployment type (Required, Available) and other settings.
   • Software Update Group: Choose whether to create a new SUG or add to an existing one.
4. Deployment Schedule:
   • Set the schedule for when the ADR runs (e.g., "Run after synchronization").
5. Software Updates:
   • This is where you define the criteria for selecting updates.
   • Product: Choose the products to include (e.g., "Windows 10").
   • Classification: Select the update classifications (e.g., "Critical Updates", "Security Updates").
   • Severity: (If applicable) Specify the severity of updates.
   • Date Released or Revised: Define a timeframe for updates (e.g., "Released in the last 1 month"). This is crucial for automation!
6. Evaluation Schedule:
   • Set how often the ADR evaluates its rules. This might be more frequent than the deployment schedule.
7. Deployment Package:
   • Choose an existing deployment package or create a new one to store the update files.
8. Download Location:
   • Specify where to download updates from (e.g., "Internet").
9. Deployment Options:
   • Configure options like Wake-on-LAN, if needed.
10. Alerts:
    • Set up alerts for deployment success or failure.
11. Download Settings:
    • Configure download behavior on client.
12. Summary: Review your settings and complete the wizard.

✅ Best Practices for ADRs

• Start with Test Collections: Always deploy new ADRs to a small test collection first to verify they are working as expected.
• Clear Naming: Use descriptive names for your ADRs to make them easy to identify (e.g., "Win10-CritSec-Monthly").
• Careful Criteria: Define your update selection criteria carefully to avoid deploying unwanted updates. Pay close attention to the "Date Released or Revised" setting.
• Regular Evaluation: Schedule ADRs to evaluate regularly to ensure new updates are captured.
• Maintenance Window Awareness: Consider maintenance windows to control when updates are installed on client computers.
• Monitor Deployments: Monitor the deployment status of your ADRs to identify and resolve any issues.

🐚 Troubleshooting ADRs

• Updates Not Deploying:
  • Verify that the ADR is enabled and scheduled to run.
  • Check the ADR's evaluation schedule.
  • Review the update selection criteria.
  • Examine the deployment status for errors.
  • Check the client logs for issues.
• Unwanted Updates:
  • Refine the update selection criteria in the ADR.
  • Check for any supersedence rules that might be affecting the updates.
• Download Failures:
  • Verify network connectivity.
  • Check disk space on the distribution point.
  • Examine the SCCM logs for download errors.

← Hide Details

💼 Operating System Deployment (WIM, TS)

💾 Overview

This section focuses on deploying and upgrading operating systems on your managed devices. [cite: Microsoft Docs on OS Deployment]

SCCM provides powerful tools to automate the OS deployment process, reducing manual effort and ensuring consistency.

💾 WIM Images

Windows Imaging Format (WIM) files are image-based files that contain the operating system files and structure. [cite: Microsoft Docs on WIM]

You import WIM files into SCCM to use as the source for OS installations.

💾 Task Sequences (TS)

Task Sequences (TS) are a series of steps that automate the OS deployment process. [cite: Microsoft Docs on Task Sequences]

TS are the heart of SCCM OS deployment, allowing you to customize the installation and configuration of the OS.

⚙ How OS Deployment Works

1. Prepare WIM Image: Obtain or create a WIM file containing the desired OS version and configuration.
2. Import WIM into SCCM: Import the WIM file into SCCM as an Operating System Image.
3. Create Task Sequence: Design a task sequence that defines the steps to install and configure the OS.
4. Boot Image: Use a Windows PE boot image to start the target computer and initiate the task sequence.
5. Deploy Task Sequence: Deploy the task sequence to a collection of devices.
6. Install OS: The target computers boot into Windows PE, run the task sequence, and install the OS.

💻 Configuration Steps: Creating a Task Sequence for OS Deployment

1. Open SCCM Console: Go to Software Library → Operating Systems → Task Sequences.
2. Create Task Sequence: Right-click → Create Task Sequence.
3. Create a New Task Sequence: Choose an appropriate template:
   • Install an existing image package: For deploying a standard OS image.
   • Build and Capture: To create a new OS image from a reference computer.
   • Deploy a Windows upgrade package: To upgrade an existing OS.
   • Custom Task Sequence: To create a sequence from scratch.
4. General Tab:
   • Name: Provide a descriptive name (e.g., "Deploy Windows 10 x64").
   • Description: (Optional) Add details about the task sequence.
5. Task Sequence Steps: This is where you configure the actions the task sequence will perform. Common steps include:
   • Partition Disk: Configure disk partitions.
   • Apply Operating System Image: Select the WIM image to install.
   • Apply Windows Settings: Configure OS settings (e.g., computer name, time zone).
   • Apply Network Settings: Configure network settings (e.g., join domain).
   • Install Configuration Manager Client: Install the SCCM client agent.
   • Install Applications: Install software applications.
   • Apply Drivers: Install device drivers.
   • Setup Windows and ConfigMgr: Finalize Windows setup and SCCM client configuration.
   • Restart Computer: Restart the computer.
   • Install Updates: Install software updates.
   • Run Command Line: Run custom scripts or commands.
6. Boot Image: Select the boot image to use.
7. Schedule: Configure a schedule for the task sequence (if needed).
8. Distribution Points: Specify distribution points to distribute the task sequence content.
9. Summary: Review the settings and complete the wizard.

💻 Configuration Steps: Importing a WIM Image

1. Open SCCM Console: Go to Software Library → Operating Systems → Operating System Images.
2. Add Operating System Image: Right-click → Add Operating System Image.
3. Data Source: Specify the path to the WIM file.
4. General:
   • Name: Provide a name for the image.
   • Version: (Optional) Enter the OS version.
   • Comment: (Optional) Add a comment.
5. Summary: Review and complete the wizard.

✅ Best Practices

• Standard Images: Use standardized WIM images to ensure consistency.
• Modular Task Sequences: Design modular task sequences with reusable components.
• Driver Management: Implement a robust driver management strategy.
• Testing: Thoroughly test task sequences in a lab before deploying them to production.
• Phased Deployments: Use phased deployments to minimize disruption.
• Documentation: Document your task sequences and OS deployment process.

🐚 Troubleshooting

• Task Sequence Failures:
  • Check the client logs (smsts.log) for detailed error messages.
  • Examine the task sequence steps to identify the failing step.
  • Verify the WIM image integrity.
  • Check driver compatibility.
  • Ensure sufficient disk space.
• Boot Image Issues:
  • Verify that the boot image is correctly configured.
  • Check network connectivity in Windows PE.
  • Ensure that the boot image contains necessary drivers (e.g., network, storage).
• Driver Problems:
  • Use appropriate drivers for the hardware.
  • Manage driver packages effectively.

← Hide Details

💻 Boot Images, Drivers, Scripts

💾 Overview

This section provides the tools to manage essential components for OS deployment and client management. [cite: Microsoft Docs on Boot Images, Microsoft Docs on Driver Management, Microsoft Docs on Scripts]

These components include boot images (used for starting the OS installation process), device drivers, and scripts for automation.

💾 Boot Images

Boot images are Windows PE (Preinstallation Environment) images used to start a computer in a minimal OS environment. [cite: Microsoft Docs on Boot Images]

They are essential for OS deployment task sequences, allowing the computer to connect to the SCCM infrastructure, access the WIM image, and perform installation tasks.

💾 Drivers

Device drivers are software components that enable the operating system to communicate with hardware devices. [cite: Microsoft Docs on Driver Management]

In SCCM, you can manage driver packages and driver catalogs to ensure the correct drivers are available during OS deployment.

💾 Scripts

SCCM allows you to manage and deploy various types of scripts (e.g., PowerShell, VBScript) to automate tasks on managed clients. [cite: Microsoft Docs on Scripts]

Scripts can be used for custom configurations, software installations, or data collection.

⚙ How Boot Images Work

1. Windows PE Environment: A boot image loads a minimal version of Windows (Windows PE) into the computer's memory.
2. Network Access: Windows PE provides network connectivity, allowing the computer to communicate with the SCCM distribution point.
3. Task Sequence Execution: The boot image is used to start the task sequence, which then performs the OS installation and configuration steps.

⚙ How Driver Management Works

1. Import Drivers: You import driver files into SCCM.
2. Create Driver Packages: You group drivers into driver packages for easier deployment.
3. Apply Drivers in Task Sequence: You use task sequence steps to apply the appropriate drivers during OS deployment.
4. Driver Catalog (Optional): You can use a driver catalog to categorize and manage drivers.

⚙ How Script Deployment Works

1. Create Script: You create the script (e.g., PowerShell script) to perform the desired task.
2. Create Package or Application: You can deploy the script using a package or an application.
3. Deploy Script: You deploy the package or application containing the script to a collection.
4. Run Script: Clients execute the script.
5. Monitor Results: You can monitor the script execution results in SCCM.

💻 Configuration Steps: Creating a Boot Image

1. Open SCCM Console: Go to Software Library → Operating Systems → Boot Images.
2. Create Boot Image:
   • SCCM typically provides default boot images. You can modify these or create new ones.
   • To create a new one, right-click and select Create Boot Image using Windows ADK.
3. Source: Specify the source for the Windows PE image (usually the Windows ADK).
4. General:
   • Name: Provide a name for the boot image.
   • Version: (Optional) Enter the version.
   • Comment: (Optional) Add a comment.
5. Optional Components:
   • Add any necessary Windows PE optional components (e.g., support for specific network adapters or storage devices). Adding the correct drivers here is critical for Windows PE to function!
6. Drivers:
   • Add any drivers that Windows PE needs to function correctly (e.g., network adapter drivers, storage controller drivers).
7. Customization:
   • Configure any customizations (e.g., prestart command).
8. Images:
   • Specify architecture (x86 or x64).
9. Data Source:
   • Specify the data source.
10. Summary: Review and complete the wizard.

💻 Configuration Steps: Importing and Managing Drivers

1. Open SCCM Console: Go to Software Library → Operating Systems → Drivers.
2. Import Driver: Right-click → Import Driver.
3. Specify the location to import driver: Specify the folder containing the driver files.
4. Driver Details:
   • Review the driver details (e.g., manufacturer, model).
5. Options:
   • Choose whether to add the driver to a driver package.
   • Select driver categories (optional).
6. Summary: Review and complete the wizard.
7. Create Driver Package:
   • Right-click Driver Packages → Create Driver Package.
   • Add the necessary drivers to the package.

💻 Configuration Steps: Deploying a Script

*(These steps vary depending on whether you deploy the script using a package or an application. I'll provide a general outline using a package.)*

1. Open SCCM Console: Go to Software Library → Application Management → Packages.
2. Create Package: Right-click → Create Package.
3. Name: Provide a name for the package (e.g., "Run PowerShell Script").
4. Specify the source files for this package: Specify the folder containing the script file.
5. Create a standard program: Check this option.
6. Program Name: Provide a name for the program (e.g., "Execute Script").
7. Command line:
   • Specify the command line to execute the script (e.g., powershell.exe -ExecutionPolicy Bypass -File "ScriptName.ps1").
8. Deploy Package: Deploy the package to a collection.

✅ Best Practices

Boot Images

• Minimal Boot Images: Keep boot images as small as possible to improve performance. Include only the necessary components and drivers.
• Driver Compatibility: Ensure that boot images contain the correct network and storage drivers for the target hardware.
• Update Boot Images: Update boot images when you update the Windows ADK.

Drivers

• Driver Organization: Organize drivers logically (e.g., by manufacturer and model).
• Driver Packages: Use driver packages to simplify driver deployment.
• Driver Validation: Test drivers thoroughly before deploying them in production.
• Driver Updates: Keep drivers updated.

Scripts

• Script Versioning: Use version control for your scripts.
• Error Handling: Implement robust error handling in your scripts.
• Testing: Test scripts thoroughly before deploying them.
• Security: Be mindful of script security, especially when running scripts with elevated privileges.

🐚 Troubleshooting

Boot Images

• Boot Failures:
  • Verify that the boot image is correctly assigned to the task sequence.
  • Check network connectivity.
  • Ensure that the boot image has the necessary drivers.
  • Examine the client logs in Windows PE.
• Driver Issues in PE:
  • Add the required drivers to the boot image.
  • Verify driver compatibility.

Drivers

• Driver Installation Failures:
  • Check the client logs for driver installation errors.
  • Verify driver compatibility.
  • Ensure that the driver package is correctly deployed.
• Missing Drivers:
  • Identify missing drivers and import them into SCCM.
  • Ensure that the task sequence is configured to install the drivers.

Scripts

• Script Execution Failures:
  • Check the client logs for script execution errors.
  • Verify the script syntax and logic.
  • Ensure that the script has the necessary permissions.
  • Test the script manually on a client.
• Script Deployment Issues:
  • Verify that the package or application containing the script is correctly deployed.
  • Check the deployment status.

← Hide Details

📈 Global Conditions & Requirements

💾 Overview

This section allows you to define reusable conditions and requirements that can be applied to various deployments in SCCM. [cite: Microsoft Docs on Global Conditions, Microsoft Docs on Requirements]

This helps to standardize and simplify the process of specifying criteria for software installation, compliance settings, and other configurations.

💾 Global Conditions

Global conditions are reusable conditions that you can use to specify requirements for applications, configuration items, and task sequences. [cite: Microsoft Docs on Global Conditions]

Instead of creating the same condition multiple times, you can create a global condition once and then reference it in different deployments.

💾 Requirements

Requirements are rules that define the conditions that must be met before software or a configuration is installed or applied. [cite: Microsoft Docs on Requirements]

Requirements can be based on various criteria, such as operating system version, hardware specifications, or registry settings.

⚙ How Global Conditions Work

1. Create Global Condition: You define a global condition, specifying the criteria to evaluate (e.g., operating system version, available disk space).
2. Reference Global Condition: You reference the global condition in the requirements for an application, configuration item, or task sequence.
3. Evaluation: SCCM evaluates the global condition on the client to determine if the requirement is met.

⚙ How Requirements Work

1. Define Requirement: You define a requirement, specifying the condition that must be met (e.g., "Operating system equals Windows 10").
2. Apply Requirement: You apply the requirement to an application, configuration item, or task sequence.
3. Evaluation: SCCM evaluates the requirement on the client to determine if it is met.
4. Action: If the requirement is not met, SCCM may prevent the software from installing or the configuration from being applied.

💻 Configuration Steps: Creating a Global Condition

1. Open SCCM Console: Go to Software Library → Overview → Global Conditions.
2. Create Global Condition: Right-click → Create Global Condition.
3. General:
   • Name: Provide a descriptive name for the global condition (e.g., "Minimum Disk Space").
   • Device type: Select whether the condition applies to devices or users.
   • Condition type: Choose the type of condition to create (e.g., "Operating system", "Free disk space", "Registry setting").
4. Specify condition: Configure the specific settings for the chosen condition type.
   • Example (Free disk space):
     • Property: Select the drive to check (e.g., "System drive").
     • Operator: Choose the comparison operator (e.g., "Greater than or equal to").
     • Value: Enter the required disk space (e.g., "1024" MB).
5. Summary: Review and complete the wizard.

💻 Configuration Steps: Adding a Requirement to an Application

1. Open SCCM Console: Go to Software Library → Application Management → Applications.
2. Select Application: Select the application to which you want to add a requirement.
3. Properties: Right-click and select Properties.
4. Requirements Tab:
   • Click Add to add a new requirement.
   • Category: Choose "Custom" to use a global condition.
   • Condition: Select the global condition you created.
   • Rule type: Choose "Value".
   • Configure any additional rule settings (e.g., operator, value).
5. Summary: Review and complete the wizard.

✅ Best Practices

• Use Global Conditions: Use global conditions to standardize and simplify the creation of reusable requirements.
• Descriptive Names: Use clear and descriptive names for global conditions and requirements.
• Test Requirements: Thoroughly test requirements to ensure they function as expected.
• Document Requirements: Document the purpose of your requirements.
• Combine Requirements: Combine multiple requirements to create complex conditions.

🐚 Troubleshooting

• Application Not Installing:
  • Check the client logs to see if any requirements are not met.
  • Verify the configuration of the global conditions and requirements.
  • Manually test the requirements on a client.
• Unexpected Behavior:
  • Carefully review the logic of your requirements to ensure they are evaluating the correct conditions.
  • Simplify complex requirements for troubleshooting purposes.
• Global Condition Issues:
  • If a global condition is not evaluating correctly, test it independently to isolate the problem.

← Hide Details

📃 Deployment Status (Apps, Updates, OS)

💾 Overview

This section provides tools to monitor the deployment status of software, updates, and operating systems in your SCCM environment. [cite: Microsoft Docs on Monitoring Deployments]

Effective monitoring is crucial for ensuring successful deployments, identifying issues, and troubleshooting problems.

💾 Monitoring Application Deployments

SCCM allows you to track the progress and success of application installations on client computers.

💾 Monitoring Software Update Deployments

You can monitor the compliance and installation status of software updates deployed to clients.

💾 Monitoring OS Deployments

SCCM provides tools to monitor the progress of operating system deployments, including task sequence execution and installation status.

⚙ How Deployment Status Monitoring Works

1. Deployment Creation: You create and deploy software, updates, or an OS using SCCM.
2. Client Action: Clients receive the deployment policy and attempt to install the software, update, or OS.
3. Status Reporting: Clients report their installation status back to the SCCM site.
4. Console Display: The SCCM console displays the aggregated deployment status information.

💻 Configuration Steps: Monitoring Application Deployment Status

1. Open SCCM Console: Go to Software Library → Application Management → Applications.
2. Select Application: Select the application you want to monitor.
3. Monitoring:
   • You can often find deployment status information in the "Monitoring" workspace or by right-clicking the deployment and selecting "Show Status".
   • SCCM provides various views and reports to display deployment status, including:
     • Compliance Status: Shows the percentage of clients that have successfully installed the application, failed to install, or are in progress.
     • Error Details: Provides information about specific installation errors.
     • Client Status: Shows the status of the deployment on individual clients.

💻 Configuration Steps: Monitoring Software Update Deployment Status

1. Open SCCM Console: Go to Software Library → Software Updates → Software Update Groups or Deployments.
2. Select Deployment: Select the software update deployment you want to monitor.
3. Monitoring:
   • SCCM provides detailed reports and views on software update compliance, including:
     • Compliance Percentage: Shows how many clients have installed the updates, how many are still required, and how many have failed.
     • Update Status: Displays the status of individual updates within the deployment.
     • Client Details: Provides granular information about the update installation status on specific clients.

💻 Configuration Steps: Monitoring OS Deployment Status

1. Open SCCM Console: Go to Software Library → Operating Systems → Task Sequences.
2. Select Task Sequence: Select the task sequence deployment you want to monitor.
3. Monitoring:
   • SCCM allows you to monitor the progress of OS deployments, including:
     • Overall Status: Shows the number of successful, failed, and in-progress deployments.
     • Task Sequence Steps: Displays the status of individual steps in the task sequence.
     • Client Progress: Provides detailed information about the progress of the OS installation on specific clients.
     • Logs: You can often access client logs (e.g., `smsts.log`) directly from the SCCM console for troubleshooting.

✅ Best Practices

• Proactive Monitoring: Monitor deployments regularly to identify and address issues promptly.
• Use Reports and Dashboards: Utilize the built-in SCCM reports and dashboards to visualize deployment status.
• Drill Down for Details: Drill down into specific deployments or clients to get detailed information about errors or failures.
• Analyze Logs: Use client logs to troubleshoot complex deployment problems.
• Set Up Alerts: Configure alerts to be notified of critical deployment failures.

🐚 Troubleshooting

• Failed Deployments:
  • Examine the client logs for error messages.
  • Verify the deployment configuration.
  • Check network connectivity.
  • Ensure that the client meets the requirements for the deployment.
• Stuck Deployments:
  • Investigate clients that are stuck in a particular deployment phase.
  • Check for conflicting processes or software.
  • Restart the client or the SCCM client agent.
• Inconsistent Status:
  • Refresh the SCCM console to ensure you have the latest status information.
  • Check for any delays in status reporting.

← Hide Details

🛢 SCCM Site & Component Status

Maintaining a healthy SCCM environment requires regular monitoring of the Site Status and Component Status. These sections provide insights into the overall health and functionality of your SCCM infrastructure.

🛢 Understanding Site Status

The Site Status node in the SCCM console provides a high-level overview of the health of your SCCM site(s). [cite: SCCM documentation on site health] It displays critical information about the site server, database, and replication links (in a multi-site hierarchy).

• Site System Health: Indicates the operational status of each site system role (e.g., Management Point, Distribution Point).
• Database Status: Shows the health and synchronization status of the SCCM site database.
• Replication Status: (For hierarchies) Displays the status of data replication between parent and child sites.
• Critical and Warning Alerts: Summarizes any active critical or warning alerts related to the site.

🚀 Monitoring Component Status

The Component Status node provides detailed information about the individual SCCM server components and their operational status. [cite: SCCM documentation on component monitoring] These components are responsible for various functions within SCCM, such as client communication, software distribution, and inventory processing.

• Component Health: Shows the current status (OK, Warning, Critical) of each SCCM component.
• Message Details: Provides specific error or warning messages, along with timestamps, for each component.
• Troubleshooting Information: Often includes details helpful for diagnosing and resolving component-related issues.
• Performance Counters: Some components provide performance counters that can be monitored for potential bottlenecks.

⚙ Step-by-Step: Checking Site and Component Status

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Monitoring: Go to the Monitoring workspace in the bottom left corner.
3. Check Site Status:
   • Expand the Overview node.
   • Click on Site Status.
   • Review the status of your site(s). Pay attention to the Status column, which indicates the overall health.
   • Double-click on a specific site to view more detailed information, including the status of individual site system roles.
   • Examine the Component Status tab within the site details for a summary of component health on that site.
4. Check Component Status:
   • In the Monitoring workspace, expand the Overview node.
   • Click on Component Status.
   • Review the list of SCCM components and their current Status.
   • Pay attention to components with a status of Warning or Critical.
   • Double-click on a component with a warning or critical status to view detailed messages in the bottom pane.
   • Examine the Messages tab for specific error or warning details, including the description, time, and component.

🔍 Interpreting Status Messages

Understanding the messages in the Component Status is crucial for troubleshooting. Messages often provide specific error codes or descriptions that can help pinpoint the cause of an issue. You can use these messages to search for relevant knowledge base articles or documentation.

• Informational: Indicates normal operation or successful completion of a task.
• Warning: Suggests a potential issue that might impact functionality in the future if not addressed.
• Error: Indicates a problem that is currently affecting or has prevented a component from functioning correctly.

✅ Best Practices for Monitoring Status

• Regularly Check Status: Make it a routine to check both Site and Component Status daily or at least a few times a week.
• Configure Alerts: Set up alerts for critical and warning status messages to be proactively notified of potential issues.
• Investigate Warnings Promptly: Don't ignore warning messages, as they can often escalate into critical errors if left unaddressed.
• Review Message Details: When troubleshooting, always examine the detailed messages associated with a component's status.
• Understand Your Environment: Familiarize yourself with the expected status of your site systems and components to quickly identify deviations.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Site System Role in Critical Status	Review the SMS_SITE_COMPONENT and other relevant logs on the site server and the affected site system. Verify network connectivity and permissions.
Component in Warning or Critical Status	Examine the detailed messages for the component. Check relevant log files (usually located in the <ConfigMgr Installation Path>\Logs directory). Restart the SMS Agent Host service or the specific component if necessary.
Replication Link Degraded	Use the Replication Link Analyzer tool to diagnose and repair replication issues between sites. Check network connectivity and SQL Server status.
Database Synchronization Issues	Review SQL Server logs and the rcmctrl.log on the site server. Ensure the SQL Server Agent is running and healthy.

← Hide Details

🔔 SCCM Alerts & Basic SQL Queries

Leveraging Alerts and understanding basic SQL Queries can significantly enhance your ability to proactively manage and troubleshoot your SCCM environment. Alerts provide notifications for critical events, while SQL queries allow you to extract valuable information directly from the SCCM database.

🔔 Understanding SCCM Alerts

SCCM Alerts are notifications generated based on predefined conditions or thresholds within your environment. [cite: SCCM documentation on configuring alerts] They help you stay informed about potential issues, status changes, and important events without constantly monitoring the console.

• Built-in Alerts: SCCM comes with a range of predefined alerts for common scenarios (e.g., low disk space on distribution points, client health issues, software update deployment failures).
• Custom Alerts: You can create custom alerts based on specific criteria using queries or status message filters to monitor aspects unique to your environment.
• Alert Severity: Alerts are typically categorized by severity (e.g., Informational, Warning, Critical) to help prioritize responses.
• Alert Actions: When an alert is triggered, you can configure actions such as sending email notifications, writing to the event log, or running a script.

⚙ Step-by-Step: Configuring SCCM Alerts

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Monitoring: Go to the Monitoring workspace.
3. Expand Alerts: Expand the Alerts node.
4. View Existing Alerts: Click on Active Alerts to see currently triggered alerts.
5. Configure Built-in Alerts:
   • Right-click on the Alerts node and select Configure System Health Alerts or Configure Software Update Point Health Alerts, etc., depending on the area you want to monitor.
   • Review the available alerts and enable/disable them as needed.
   • For each enabled alert, you can typically configure thresholds (e.g., trigger a low disk space alert when free space falls below a certain percentage).
6. Create Custom Alerts (using Query):
   • Right-click on the Alerts node and select Create Alert.
   • General Tab: Provide a name and severity for the alert.
   • Trigger Tab:
     • Select Query based alert.
     • Click Edit Query Statement... to define a WQL query that will trigger the alert when results are returned. For example, to alert on devices not reporting hardware inventory in 7 days:

                     SELECT *
                     FROM SMS_R_System
                     WHERE DATEDIFF(dd, LastHWScan, GETDATE()) > 7
                     

   • Actions Tab: Configure actions to take when the alert is triggered (e.g., send an email). You'll need to configure email notifications in SCCM settings beforehand.
7. Create Custom Alerts (using Status Message Query):
   • Right-click on the Alerts node and select Create Alert.
   • General Tab: Provide a name and severity.
   • Trigger Tab:
     • Select Status message query based alert.
     • Click Edit Query Statement... to define criteria for status messages that will trigger the alert (e.g., specific error codes from software update deployments).
   • Actions Tab: Configure alert actions.

📖 Basic SQL Queries for SCCM

The SCCM database (usually named `CM_XXX`, where `XXX` is your site code) stores a wealth of information. Using SQL queries in SQL Server Management Studio (SSMS) allows you to retrieve specific data for reporting, troubleshooting, and analysis. Use caution when running queries that modify the database; stick to SELECT statements for information retrieval.

• Connecting to the Database: Use SSMS and connect to the SQL Server hosting your SCCM database with appropriate credentials.
• New Query: Open a new query window and ensure the correct SCCM database is selected in the dropdown.
• Basic SELECT Statement: The foundation of most queries.

        SELECT * FROM v_R_System; -- Select all columns from the view for devices
        SELECT Name0, Operating_System_Name_and0 FROM v_R_System; -- Select specific columns
        

• Filtering with WHERE Clause: To retrieve specific data based on conditions.

        SELECT Name0, Operating_System_Name_and0
        FROM v_R_System
        WHERE Operating_System_Name_and0 LIKE '%Windows 10%';
        

• Joining Tables/Views: To combine data from multiple sources (using views is generally recommended). For example, to get device name and the primary user:

        SELECT sys.Name0 AS DeviceName, users.Full_User_Name0 AS PrimaryUser
        FROM v_R_System sys
        INNER JOIN v_GS_SYSTEM_CONSOLE_USAGE cons ON sys.ResourceID = cons.ResourceID
        INNER JOIN v_R_User users ON cons.LastLoggedOnUser = users.User_Name0;
        

• Ordering Results with ORDER BY: To sort the retrieved data.

        SELECT Name0, LastLogonUserName0
        FROM v_GS_SYSTEM_USERS
        ORDER BY LastLogonUserName0;
        

• Counting Records with COUNT: To get the number of items matching certain criteria.

        SELECT COUNT(*) AS TotalWindows11Devices
        FROM v_R_System
        WHERE Operating_System_Name_and0 LIKE '%Windows 11%';
        

🔍 Example: Alert for Failed Application Deployments

You can create a custom alert to notify you when an application deployment fails. This would typically involve using a status message query to look for specific error status messages related to application deployments.

✅ Best Practices for Alerts and SQL Queries

• Be Specific with Alerts: Avoid creating too many generic alerts that can lead to alert fatigue. Focus on critical issues.
• Configure Alert Actions Wisely: Ensure that alert actions (like email notifications) are sent to the appropriate personnel.
• Test Custom Alert Queries: Before deploying a custom alert, ensure your WQL or status message query works as expected.
• Use Views for SQL Queries: SCCM provides numerous views (prefixed with `v_`) that simplify data retrieval and are less likely to be affected by database schema changes compared to direct table queries.
• Understand the Database Schema: Familiarize yourself with the SCCM database schema and the available views to write effective queries. Microsoft provides documentation on this.
• Start Simple with SQL: Begin with basic SELECT and WHERE clauses and gradually explore more complex joins and functions as needed.
• Never Use Unverified SQL for Modifications: Only use SELECT statements for data retrieval unless you have a thorough understanding of the database and the implications of your modifications.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Alerts Not Triggering	Verify that the alert is enabled, the trigger conditions are met, and the associated queries (if any) are correct. Check the SMS_ALERT_MANAGER component status.
Too Many Alerts	Review your alert configurations and disable or adjust thresholds for less critical alerts. Consolidate alerts where possible.
SQL Query Errors	Double-check the syntax of your SQL query, ensure you are querying the correct database and view/table names, and verify that the columns you are referencing exist.
Slow SQL Queries	Optimize your queries by using appropriate indexes (though you typically don't create indexes in the SCCM database), limiting the number of columns selected, and using efficient filtering criteria.

← Hide Details

👤 SCCM Client Operations & Script Results

SCCM provides powerful capabilities for performing Client Operations directly from the console and for deploying and managing Scripts on client devices. These features are invaluable for remote management, troubleshooting, and enforcing configurations.

🚀 Understanding Client Operations

Client Operations allow you to initiate various actions on individual or collections of managed devices without physically being at the machine. [cite: SCCM documentation on client actions] These actions can help with immediate tasks like inventory updates, policy retrieval, and remote control.

• Policy Retrieval & Evaluation: Forces the client to immediately download and evaluate the latest policies.
• Hardware Inventory Cycle: Initiates an immediate hardware inventory scan.
• Software Inventory Cycle: Initiates an immediate software inventory scan.
• Software Metering Cycle: Triggers an immediate software metering data collection.
• Application Deployment Evaluation Cycle: Forces the client to re-evaluate the requirements and status of application deployments.
• Software Updates Scan Cycle: Initiates an immediate scan for applicable software updates.
• Endpoint Protection Scan: Triggers a malware scan using Endpoint Protection (if installed).
• Remote Control: Allows you to remotely view and control a client machine (requires Remote Control to be enabled).
• Resource Explorer: Provides a real-time view of hardware and software inventory on a client.
• Client Diagnostics: Runs various diagnostic tests on the client.

⚙ Step-by-Step: Performing Client Operations

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Devices: Go to the Assets and Compliance workspace and click on Devices.
3. Select Target Device(s): Choose the device(s) on which you want to perform an operation. You can select multiple devices.
4. Initiate Client Operation:
   • Right-click on the selected device(s).
   • Go to Client Operations.
   • Select the desired operation from the submenu (e.g., Start → Policy Retrieval & Evaluation Cycle).
5. Confirmation (if applicable): Some operations may prompt for confirmation before execution. Click Yes to proceed.
6. Monitor Status: The results of some client operations can be monitored in the Monitoring workspace under Client Operations or by checking the client logs on the target machine (e.g., PolicyAgent.log, InventoryAgent.log).

💻 Managing and Viewing Script Results

SCCM allows you to create, approve, deploy, and monitor PowerShell scripts to managed devices. [cite: SCCM documentation on running PowerShell scripts] This is a powerful way to automate tasks, gather information, and remediate issues remotely.

• Script Creation and Approval: You can create PowerShell scripts within the SCCM console. For security, scripts typically require an administrator to approve them before they can be deployed.
• Script Deployment: Scripts are deployed to collections of devices. You can specify parameters to be passed to the script.
• Real-time or Scheduled Execution: Scripts can be run immediately or scheduled to run at a specific time.
• Viewing Script Output: SCCM provides a mechanism to view the output of scripts run on client devices, allowing you to verify the results and identify any errors.

⚙ Step-by-Step: Running and Viewing Script Results

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Scripts: Go to the Software Library workspace, expand Scripts, and click on Scripts.
3. Create or Select a Script:
   • To create a new script, click Create Script in the ribbon. Provide a name, select the language (PowerShell), and paste your script code. Click Approve in the ribbon after reviewing the script.
   • To run an existing approved script, select it from the list.
4. Run Script: Click Run Script in the ribbon.
5. Target Collection: In the Run Script wizard, click Browse... and select the target device collection.
6. Parameters (if applicable): If the script has parameters, provide the necessary values.
7. Run: Click Next and then Run to initiate the script execution on the target clients.
8. Monitor Script Status:
   • Go to the Monitoring workspace, expand Scripts, and click on Script Status.
   • Find your script in the list. The Overall Status will indicate the progress (e.g., Compliant, Error, Pending).
   • Double-click on the script to view detailed status for each target device.
9. View Script Output:
   • In the Script Status details view, select a specific device.
   • In the bottom pane, click on the Output tab. This will display the output generated by the script on that client.
   • You can filter the output or export it for further analysis.

🔍 Example: Running a Script to Get Installed Applications

You could create a PowerShell script to retrieve the list of installed applications on a device and then run it on a collection. The output in the Script Status would show the installed software for each device in the target collection.

  Get-WmiObject -Class Win32_Product | Select-Object Name, Version | ConvertTo-Json
  

This script uses WMI to get installed applications, selects the name and version, and outputs the results in JSON format for easier readability in SCCM.

✅ Best Practices for Client Operations and Scripts

• Use Client Operations for Immediate Tasks: Leverage client operations for on-demand actions and troubleshooting.
• Target Operations Carefully: Be mindful of the scope when performing client operations, especially on large collections.
• Approve Scripts Before Deployment: Always review and approve scripts to ensure they are safe and perform the intended actions.
• Test Scripts in a Pilot Environment: Thoroughly test scripts on a small group of devices before deploying them to a wider audience.
• Use Meaningful Script Names and Descriptions: Make it easy to identify the purpose of each script.
• Handle Script Output Appropriately: Design scripts to provide clear and informative output that is useful for monitoring.
• Consider Security Implications: Be cautious when running scripts that make system changes and ensure appropriate permissions are in place.
• Monitor Script Status Regularly: Keep track of the execution status of your scripts to identify any failures or issues.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Client Operation Fails	Check client health, network connectivity, and client logs on the target device. Ensure the SCCM client agent is running correctly.
Script Not Running on Clients	Verify that the script is approved, the target collection is correct, and the client has received the policy to run the script. Check the ScriptExecution.log on the client.
Script Output Not Showing	Ensure the script is designed to produce output (e.g., using `Write-Output` in PowerShell). Check the MaxScriptOutputReturnSize setting in SCCM if the output is very large.
Client Not Responding to Operations	This could indicate a client health issue. Try restarting the SMS Agent Host service on the client. Verify firewall rules are not blocking communication.

← Hide Details

👤 SCCM Client Operations & Script Results

SCCM provides powerful capabilities for performing Client Operations directly from the console and for deploying and managing Scripts on client devices. These features are invaluable for remote management, troubleshooting, and enforcing configurations.

🚀 Understanding Client Operations

Client Operations allow you to initiate various actions on individual or collections of managed devices without physically being at the machine. [cite: SCCM documentation on client actions] These actions can help with immediate tasks like inventory updates, policy retrieval, and remote control.

• Policy Retrieval & Evaluation: Forces the client to immediately download and evaluate the latest policies.
• Hardware Inventory Cycle: Initiates an immediate hardware inventory scan.
• Software Inventory Cycle: Initiates an immediate software inventory scan.
• Software Metering Cycle: Triggers an immediate software metering data collection.
• Application Deployment Evaluation Cycle: Forces the client to re-evaluate the requirements and status of application deployments.
• Software Updates Scan Cycle: Initiates an immediate scan for applicable software updates.
• Endpoint Protection Scan: Triggers a malware scan using Endpoint Protection (if installed).
• Remote Control: Allows you to remotely view and control a client machine (requires Remote Control to be enabled).
• Resource Explorer: Provides a real-time view of hardware and software inventory on a client.
• Client Diagnostics: Runs various diagnostic tests on the client.

⚙ Step-by-Step: Performing Client Operations

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Devices: Go to the Assets and Compliance workspace and click on Devices.
3. Select Target Device(s): Choose the device(s) on which you want to perform an operation. You can select multiple devices.
4. Initiate Client Operation:
   • Right-click on the selected device(s).
   • Go to Client Operations.
   • Select the desired operation from the submenu (e.g., Start → Policy Retrieval & Evaluation Cycle).
5. Confirmation (if applicable): Some operations may prompt for confirmation before execution. Click Yes to proceed.
6. Monitor Status: The results of some client operations can be monitored in the Monitoring workspace under Client Operations or by checking the client logs on the target machine (e.g., PolicyAgent.log, InventoryAgent.log).

💻 Managing and Viewing Script Results

SCCM allows you to create, approve, deploy, and monitor PowerShell scripts to managed devices. [cite: SCCM documentation on running PowerShell scripts] This is a powerful way to automate tasks, gather information, and remediate issues remotely.

• Script Creation and Approval: You can create PowerShell scripts within the SCCM console. For security, scripts typically require an administrator to approve them before they can be deployed.
• Script Deployment: Scripts are deployed to collections of devices. You can specify parameters to be passed to the script.
• Real-time or Scheduled Execution: Scripts can be run immediately or scheduled to run at a specific time.
• Viewing Script Output: SCCM provides a mechanism to view the output of scripts run on client devices, allowing you to verify the results and identify any errors.

⚙ Step-by-Step: Running and Viewing Script Results

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Scripts: Go to the Software Library workspace, expand Scripts, and click on Scripts.
3. Create or Select a Script:
   • To create a new script, click Create Script in the ribbon. Provide a name, select the language (PowerShell), and paste your script code. Click Approve in the ribbon after reviewing the script.
   • To run an existing approved script, select it from the list.
4. Run Script: Click Run Script in the ribbon.
5. Target Collection: In the Run Script wizard, click Browse... and select the target device collection.
6. Parameters (if applicable): If the script has parameters, provide the necessary values.
7. Run: Click Next and then Run to initiate the script execution on the target clients.
8. Monitor Script Status:
   • Go to the Monitoring workspace, expand Scripts, and click on Script Status.
   • Find your script in the list. The Overall Status will indicate the progress (e.g., Compliant, Error, Pending).
   • Double-click on the script to view detailed status for each target device.
9. View Script Output:
   • In the Script Status details view, select a specific device.
   • In the bottom pane, click on the Output tab. This will display the output generated by the script on that client.
   • You can filter the output or export it for further analysis.

🔍 Example: Running a Script to Get Installed Applications

You could create a PowerShell script to retrieve the list of installed applications on a device and then run it on a collection. The output in the Script Status would show the installed software for each device in the target collection.

  Get-WmiObject -Class Win32_Product | Select-Object Name, Version | ConvertTo-Json
  

This script uses WMI to get installed applications, selects the name and version, and outputs the results in JSON format for easier readability in SCCM.

✅ Best Practices for Client Operations and Scripts

• Use Client Operations for Immediate Tasks: Leverage client operations for on-demand actions and troubleshooting.
• Target Operations Carefully: Be mindful of the scope when performing client operations, especially on large collections.
• Approve Scripts Before Deployment: Always review and approve scripts to ensure they are safe and perform the intended actions.
• Test Scripts in a Pilot Environment: Thoroughly test scripts on a small group of devices before deploying them to a wider audience.
• Use Meaningful Script Names and Descriptions: Make it easy to identify the purpose of each script.
• Handle Script Output Appropriately: Design scripts to provide clear and informative output that is useful for monitoring.
• Consider Security Implications: Be cautious when running scripts that make system changes and ensure appropriate permissions are in place.
• Monitor Script Status Regularly: Keep track of the execution status of your scripts to identify any failures or issues.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Client Operation Fails	Check client health, network connectivity, and client logs on the target device. Ensure the SCCM client agent is running correctly.
Script Not Running on Clients	Verify that the script is approved, the target collection is correct, and the client has received the policy to run the script. Check the ScriptExecution.log on the client.
Script Output Not Showing	Ensure the script is designed to produce output (e.g., using `Write-Output` in PowerShell). Check the MaxScriptOutputReturnSize setting in SCCM if the output is very large.
Client Not Responding to Operations	This could indicate a client health issue. Try restarting the SMS Agent Host service on the client. Verify firewall rules are not blocking communication.

← Hide Details

📊 SCCM Reporting with SQL Server Reporting Services (SSRS)

Reporting is a crucial aspect of managing an SCCM environment. SQL Server Reporting Services (SSRS) provides a robust platform for creating, deploying, and managing a wide variety of reports based on the data stored in the SCCM database. [cite: SCCM documentation on reporting]

📊 Understanding SCCM Reporting Services

SCCM leverages SSRS to offer pre-built reports and the flexibility to create custom reports tailored to your organization's specific needs. SSRS integrates seamlessly with the SCCM console, allowing easy access to reporting functionalities.

• Predefined Reports: SCCM includes a comprehensive set of built-in reports covering various areas like hardware and software inventory, compliance, deployments, client health, and more. These reports are ready to use and can often be customized with parameters.
• Custom Reports: You can create your own reports using SQL Server Data Tools (SSDT) or Report Builder, leveraging the SCCM database views to retrieve the desired information.
• Report Deployment: Once created, reports are deployed to the SSRS Reporting Point role within your SCCM infrastructure, making them accessible through the SCCM console and a web browser.
• Report Viewing and Exporting: Users with appropriate permissions can run reports, view the results, and export them in various formats (e.g., PDF, Excel, CSV).
• Report Scheduling: SSRS allows you to schedule reports to run automatically at specified intervals and deliver the results via email or to a shared folder.

⚙ Step-by-Step: Accessing and Running SCCM Reports

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Reporting: Go to the Monitoring workspace and click on Reporting, then Reports.
3. Browse Reports: The Reports node displays a categorized list of available reports. You can browse through the folders to find the report you need.
4. Run a Report:
   • Select the desired report from the list.
   • Double-click on the report or right-click and select Run.
   • Enter Parameters: Many reports require you to enter parameters (e.g., collection name, date range) to filter the data. Provide the necessary values.
   • Click View Report to generate the report.
5. View Report Results: The report will be displayed within the SCCM console or in a separate Report Viewer window.
6. Export Report: To export the report, look for the export icon (usually a floppy disk or an arrow) in the Report Viewer toolbar. Select your desired format (e.g., PDF, Excel) and save the file.

⚙ Step-by-Step: Finding the Right Predefined Report

With a large number of predefined reports available, finding the right one can sometimes be challenging. Here are some tips:

1. Use the Search Function: In the Reports node, there is often a search bar that allows you to look for reports based on keywords in their name or description.
2. Browse by Category: The reports are organized into folders based on functional areas (e.g., Asset Intelligence, Client Status, Software Distribution). Explore these categories.
3. Review Report Descriptions: When you select a report, its description is usually displayed, providing more details about the data it presents.
4. Run Reports with Different Parameters: Experiment with different parameter values to see if a report can provide the specific information you need.

⚙ Step-by-Step: Basic Custom Report Creation (Conceptual)

Creating custom reports typically involves using SQL Server Data Tools (SSDT) or Report Builder. Here's a high-level overview of the process:

1. Launch Report Builder or SSDT: These tools provide a graphical interface for designing reports.
2. Connect to the SCCM Database: You'll need to establish a connection to the SQL Server hosting your SCCM database.
3. Create a Dataset: Define a SQL query that retrieves the data you want to display in your report. You'll primarily use SCCM database views (e.g., `v_R_System`, `v_GS_INSTALLED_SOFTWARE`).

         SELECT
             sys.Netbios_Name0 AS DeviceName,
             os.Caption0 AS OperatingSystem,
             COUNT(sw.ProductName0) AS InstalledAppCount
         FROM
             v_R_System sys
         INNER JOIN
             v_GS_OPERATING_SYSTEM os ON sys.ResourceID = os.ResourceID
         LEFT JOIN
             v_GS_INSTALLED_SOFTWARE sw ON sys.ResourceID = sw.ResourceID
         GROUP BY
             sys.Netbios_Name0, os.Caption0
         ORDER BY
             sys.Netbios_Name0;
         

4. Design the Report Layout: Use the reporting tool's features to arrange data fields, add tables, charts, and other visual elements.
5. Add Parameters (Optional): Allow users to filter the report data by specifying parameters.
6. Deploy the Report: Once the report is created, you'll deploy it to the Reporting Services Point in your SCCM environment. This usually involves specifying the SSRS server and the target folder for the report.
7. Access the Report in SCCM Console: After deployment, the custom report will be available in the Reports node under the specified folder.

✅ Best Practices for SCCM Reporting

• Understand the SCCM Database Schema: Familiarize yourself with the available views and their columns to write effective custom report queries.
• Start with Predefined Reports: Before creating a custom report, check if an existing report can meet your needs, possibly with parameter adjustments.
• Optimize Custom Report Queries: Write efficient SQL queries to ensure reports run quickly and don't put unnecessary load on the database.
• Use Parameters Effectively: Allow users to filter report data to focus on specific information.
• Secure Reports Appropriately: Ensure that only authorized users have access to sensitive reports. SSRS security settings can be configured.
• Schedule Reports for Regular Delivery: Automate the generation and distribution of frequently needed reports.
• Test Custom Reports Thoroughly: Verify that your custom reports retrieve and display the correct data before deploying them to a production environment.
• Document Custom Reports: Provide clear documentation for any custom reports you create, including their purpose, parameters, and underlying queries.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Cannot Access Reports	Verify that the Reporting Services Point role is installed and configured correctly. Check user permissions and ensure the user has access to the Reports node.
Report Fails to Run	Examine the SSRS log files for error details. Check the SQL query within the report for syntax errors or issues with the database objects. Verify the Reporting Services server is running.
Report Data is Incorrect	Review the SQL query used by the report and ensure it is retrieving the intended data with the correct filtering and joining logic. Check the parameters passed to the report.
Slow Running Reports	Optimize the SQL query used by the report. Consider adding indexes to the SCCM database (with caution and understanding of the implications). Limit the amount of data being retrieved if possible.

← Hide Details

💻 SCCM Site Roles & Servers (MP, DP, SUP)

A functional SCCM environment relies on various Site Roles installed on dedicated or co-located Servers. Understanding the purpose and configuration of key roles like the Management Point (MP), Distribution Point (DP), and Software Update Point (SUP) is crucial for effective SCCM management. [cite: SCCM documentation on site system roles]

📎 Management Point (MP)

The Management Point (MP) is a fundamental site system role that acts as the primary point of contact between SCCM clients and the SCCM site server. [cite: SCCM documentation on Management Point] Clients communicate with the MP to:

• Submit discovery data records (DDRs).
• Request client policy.
• Send inventory data (hardware and software).
• Report client status.
• Receive application deployment assignments.
• Locate distribution points for content.

A primary site can have multiple MPs for load balancing and redundancy. Clients are automatically assigned to an available MP within their boundary group.

🚗 Distribution Point (DP)

The Distribution Point (DP) hosts the source files for content that you deploy to clients, such as applications, software updates, operating system images, and boot images. [cite: SCCM documentation on Distribution Point] Clients download content from the DPs to install software or updates.

• Content Location: DPs store the actual installation files and packages.
• Bandwidth Control: You can configure bandwidth throttling and scheduling on DPs to manage network usage.
• BranchCache Support: DPs can be configured to support BranchCache, optimizing content delivery in branch office scenarios.
• Pull-Distribution Points: In environments with limited network bandwidth, you can configure pull-DPs to retrieve content from other DPs.
• Cloud Distribution Points: For managing internet-based clients, you can deploy cloud-based DPs in Microsoft Azure.

💡 Software Update Point (SUP)

The Software Update Point (SUP) integrates with Windows Server Update Services (WSUS) to provide software updates to SCCM clients. [cite: SCCM documentation on Software Update Point] The SUP synchronizes metadata for software updates from Microsoft Update or an upstream WSUS server.

• WSUS Integration: The SUP role relies on WSUS to manage and store update metadata.
• Synchronization: The SUP synchronizes update information based on configured classifications (e.g., Critical Updates, Security Updates) and products (e.g., Windows Server, Microsoft Office).
• Scan Compliance: Clients scan against the SUP to determine which software updates are applicable to them.
• Deployment: The SUP works in conjunction with DPs to distribute the actual update files to clients for installation.
• Multiple SUPs: You can have multiple SUPs in a primary site for load balancing and redundancy.

⚙ Step-by-Step: Checking Site Role Installation and Health

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Configuration: Go to the Administration workspace and expand Site Configuration.
3. Select Servers and Site System Roles: Click on Servers and Site System Roles.
4. Review Servers: In the middle pane, you will see a list of servers in your SCCM environment.
5. View Site Roles:
   • Select a server from the list.
   • In the bottom pane, under the Site System Roles tab, you will see the roles installed on that server.
   • Look for the Management Point, Distribution Point, and Software Update Point roles.
6. Check Component Status for Role Health:
   • Go to the Monitoring workspace and expand Overview.
   • Click on Component Status.
   • Look for components related to the specific site roles:
     • Management Point: SMS_MP_CONTROL_MANAGER, SMS_MP_FILE_DISPATCH_MANAGER, SMS_MP_POLICY_MANAGER
     • Distribution Point: SMS_DISTRIBUTION_MANAGER, SMS_PACKAGE_TRANSFER_MANAGER
     • Software Update Point: SMS_WSUS_CONTROL_MANAGER, SMS_WSUS_SYNC_MANAGER
   • Review the Status column for each component. A status of "OK" indicates the component is healthy. Warnings or critical errors should be investigated.
   • Double-click on a component with a warning or error status to view detailed messages.
7. Check Site System Status for Overall Server Health:
   • Go to the Monitoring workspace and expand Overview.
   • Click on Site System Status.
   • Review the status of each site system server. Pay attention to any servers with warning or critical status.
   • Double-click on a server with a warning or error status to view more details and any affected roles.

✅ Best Practices for Site Roles and Servers

• Plan Role Placement Carefully: Consider network topology, client locations, and load balancing requirements when deciding where to install site roles.
• Monitor Role Health Regularly: Proactively check the status of your MPs, DPs, and SUPs to ensure they are functioning correctly.
• Ensure Adequate Server Resources: Allocate sufficient hardware resources (CPU, memory, disk space) to servers hosting site roles, especially DPs that may serve large amounts of content.
• Configure Boundary Groups Appropriately: Ensure that clients are associated with the correct boundary groups to enable them to communicate with nearby MPs and DPs.
• Secure Site System Servers: Follow security best practices for hardening the operating systems and network access to your SCCM site system servers.
• Regularly Review WSUS Synchronization: Monitor the SUP synchronization process to ensure that your environment has the latest software update metadata.
• Distribute DPs Strategically: Place DPs in locations close to client populations to minimize network traffic and improve content download speeds.
• Consider Dedicated Servers for Key Roles: For larger environments, consider installing MPs, DPs, and SUPs on dedicated servers to improve performance and scalability.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Clients Cannot Communicate with MP	Verify network connectivity between clients and the MP server. Check the MP component status and IIS configuration on the MP server. Review client logs (e.g., LocationServices.log, ClientLocation.log). Ensure the MP is listed in DNS and accessible.
Clients Cannot Download Content from DP	Verify network connectivity between clients and the DP server. Check the DP component status (Distribution Manager). Ensure the content is distributed to the DP and the DP is in the client's boundary group. Review client logs (e.g., ContentTransferManager.log, DataTransferService.log). Check firewall rules.
SUP Synchronization Fails	Check the WSUS server status and configuration. Verify internet connectivity from the SUP server (if synchronizing with Microsoft Update). Review the WCM.log and WsyncMgr.log on the site server. Ensure the WSUS service is running and the WSUS database is healthy. Verify proxy settings if applicable.
Site Role Not Installing	Review the ConfigMgrSetup.log on the server where you are trying to install the role. Check prerequisites for the role. Ensure the site server can communicate with the target server. Verify permissions of the account used for installation.

← Hide Details

📍 SCCM Boundaries & Boundary Groups

Boundaries and Boundary Groups are fundamental concepts in SCCM that define the network locations of your managed devices and control how clients locate site system servers like Management Points (MPs) and Distribution Points (DPs). [cite: SCCM documentation on boundaries and boundary groups]

📍 Understanding Boundaries

Boundaries are network locations on your intranet that you configure in SCCM. [cite: SCCM documentation on boundaries] They are used to determine which clients are within a specific network and enable site assignment and content location.

SCCM supports the following types of boundaries:

• IP Subnet: Defined by one or more IPv4 or IPv6 subnets.
• Active Directory Site: Defined by one or more Active Directory Domain Services (AD DS) site names.
• IP Address Range: Defined by a starting and ending IPv4 or IPv6 address.
• IPv6 Prefix: Defined by one or more IPv6 prefixes.

You can create multiple boundaries of different types to accurately represent your network infrastructure.

👤👥 Understanding Boundary Groups

Boundary Groups are logical groupings of one or more boundaries. [cite: SCCM documentation on boundary groups] You associate site system servers (MPs, DPs, SUPs) with boundary groups. When a client within a boundary group needs to communicate with a site system, it is directed to a server within that same boundary group.

Boundary groups provide the following key functionalities:

• Site Assignment: Clients use boundary groups to find an assigned primary site.
• Content Location: Clients use boundary groups to find DPs that contain the content they need.
• Management Point Selection: Clients use boundary groups to find a suitable MP to communicate with.
• Cloud Management Gateway (CMG) Fallback: You can configure boundary groups to allow on-premises clients to use a CMG when other MPs are unavailable.
• Preferred Management Points: You can designate preferred MPs within a boundary group to prioritize client communication.

⚙ Step-by-Step: Creating Boundaries

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Boundaries: Go to the Administration workspace, expand Hierarchy Configuration, and click on Boundaries.
3. Create Boundary: In the ribbon, click Create Boundary.
4. General Tab:
   • Name: Enter a descriptive name for the boundary (e.g., "Hyderabad Office Subnet").
   • Boundary type: Choose the appropriate boundary type from the dropdown (IP Subnet, AD Site, IP Address Range, IPv6 Prefix).
5. Boundary Properties (Specific to Type):
   • IP Subnet: Enter one or more IP subnet addresses (e.g., 192.168.1.0).
   • Active Directory Site: Select one or more AD site names from the list.
   • IP Address Range: Enter the starting and ending IP addresses for the range.
   • IPv6 Prefix: Enter one or more IPv6 prefixes (e.g., 2001:db8:1::/64).
6. Click OK to create the boundary.
7. Repeat steps 3-6 to create additional boundaries as needed.

⚙ Step-by-Step: Creating Boundary Groups and Assigning Boundaries and Site Systems

1. Navigate to Boundary Groups: Go to the Administration workspace, expand Hierarchy Configuration, and click on Boundary Groups.
2. Create Boundary Group: In the ribbon, click Create Boundary Group.
3. General Tab:
   • Name: Enter a descriptive name for the boundary group (e.g., "Hyderabad Office BG").
4. Boundaries Tab:
   • Click Add...
   • Select the boundaries that belong to this boundary group from the list.
   • Click OK.
5. References Tab:
   • Use this boundary group for site assignment: Check this box if you want clients within this boundary group to be able to be assigned to the current site (typically checked for primary sites).
   • Associate site system servers with this boundary group: Click Add... and select the site system servers (MPs, DPs, SUPs) that should serve clients in this boundary group.
     • Choose the server and the role (e.g., `.domain.com` - Management Point, `.domain.com` - Distribution Point).
   • Preferred management points: (Optional) Select preferred MPs for clients in this boundary group.
   • Allow fallback source locations for content: Configure fallback behavior for content download if needed.
   • Allow clients to use a cloud distribution point when the current or neighbor boundary group does not contain any valid source locations: Configure cloud DP usage if applicable.
6. Click OK to create the boundary group.
7. Repeat steps 2-6 to create additional boundary groups as needed.

✅ Best Practices for Boundaries and Boundary Groups

• Plan Your Boundaries Carefully: Accurately represent your network topology with appropriate boundary types. Avoid overlapping boundaries unless specifically intended.
• Use Boundary Groups for Site System Association: Always associate site system servers with relevant boundary groups.
• Align Boundary Groups with Physical Locations: Typically, you'll create boundary groups that correspond to your physical offices or network segments.
• Consider Overlapping Boundaries for Roaming Clients: If you have many roaming clients, you might need to carefully plan overlapping boundaries to ensure they can always find site systems.
• Test Boundary Group Configurations: After creating or modifying boundary groups, verify that clients are correctly assigned to sites and can locate content and management points. Check client logs (LocationServices.log).
• Use Active Directory Sites Where Possible: AD Sites often provide an accurate and automatically updated representation of your network topology.
• Review Boundary Group Relationships (for hierarchies): In a multi-site hierarchy, understand how boundary groups influence client behavior across different sites.
• Avoid Assigning All Site Systems to All Boundary Groups: Be specific about which site systems should serve clients in each boundary group to optimize traffic and control client behavior.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Clients Not Finding a Management Point	Verify that the client's network location is covered by a boundary. Ensure that the boundary is part of a boundary group that has an associated MP. Check the health of the MPs in that boundary group. Review client logs (LocationServices.log, ClientLocation.log).
Clients Not Finding a Distribution Point for Content	Verify that the client's network location is covered by a boundary in a boundary group associated with a DP that has the content. Check the DP status and content distribution status. Review client logs (ContentTransferManager.log, DataTransferService.log).
Clients Assigned to the Wrong Site (in a Hierarchy)	Review your boundary group configurations and ensure that the "Use this boundary group for site assignment" option is configured correctly for the intended primary sites. Check for overlapping boundaries that might be causing unexpected site assignment.
Slow Content Downloads	Ensure that there is a DP within the client's boundary group or a neighbor boundary group with a configured relationship. Check network connectivity and DP health. Consider enabling BranchCache or configuring download settings.

← Hide Details

👤 SCCM Client Settings & Discovery Methods

Client Settings and Discovery Methods are foundational elements of SCCM that determine how clients are managed and how information about your environment is gathered. Properly configuring these aspects ensures that your devices are correctly managed and inventoried. [cite: SCCM documentation on client settings and discovery]

👤 Understanding Client Settings

Client Settings define the configuration and behavior of the SCCM client agent on managed devices. [cite: SCCM documentation on client settings] You can configure default client settings that apply to all clients in the hierarchy, and you can create custom client settings that you deploy to specific collections of users or devices.

Key areas configurable through client settings include:

• Agent Settings: Configuration of the SCCM agent itself, such as polling intervals and user interaction settings.
• Computer Agent: Settings related to software installation, maintenance windows, and power management.
• Software Deployment: Options for application deployment evaluation and installation behavior.
• Software Updates: Settings for software update deployment evaluation, scanning, and installation.
• Hardware Inventory: Configuration of the hardware inventory scan schedule and the hardware inventory classes to collect.
• Software Inventory: Configuration of the software inventory scan schedule and the types of files to collect.
• Endpoint Protection: Settings for managing Microsoft Defender Antivirus (if used).
• Power Management: Settings for configuring power plans on client computers.
• Remote Tools: Configuration of remote control, remote assistance, and client status reporting.
• Client Cache Settings: Size and location of the SCCM client cache.

⚙ Step-by-Step: Configuring Client Settings

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Client Settings: Go to the Administration workspace, expand Client Settings, and click on Client Settings.
3. Configure Default Client Settings:
   • Select Default Client Settings.
   • In the ribbon, click Properties.
   • Review and modify the settings in each section (Agent Settings, Computer Agent, etc.) according to your organizational requirements.
   • Default client settings apply to all clients that are not targeted by a custom client setting.
4. Create Custom Client Settings:
   • Right-click on the Client Settings node and select Create Custom Client Device Settings or Create Custom Client User Settings.
   • Name: Provide a descriptive name for the custom settings (e.g., "Pilot Workstation Settings").
   • Select the specific settings you want to configure in this custom policy (e.g., Hardware Inventory, Software Updates).
   • Click OK.
   • Select the newly created custom client setting in the console.
   • In the ribbon, click Deploy.
   • Choose the target device or user collection to which you want to apply these custom settings.
   • Click OK.
5. Custom client settings override the default client settings for the members of the targeted collection. If a client is a member of multiple collections with conflicting custom settings, the setting with the highest precedence (typically the one deployed later) will apply.

🔍 Understanding Discovery Methods

Discovery Methods are used by SCCM to find devices, users, and network infrastructure within your environment. [cite: SCCM documentation on discovery methods] Configuring appropriate discovery methods ensures that SCCM is aware of all the objects you want to manage.

Commonly used discovery methods include:

• Active Directory Forest Discovery: Discovers AD forests and establishes boundaries.
• Active Directory Domain Discovery: Discovers organizational units (OUs), computers, users, and groups within specified AD domains.
• Active Directory System Discovery: Discovers computer objects in specified AD OUs.
• Active Directory User Discovery: Discovers user accounts in specified AD OUs.
• Active Directory Group Discovery: Discovers security and distribution groups in specified AD OUs.
• Network Discovery: Discovers network infrastructure devices (routers, switches, printers) and potential client devices by querying network segments. This method should be used cautiously as it can generate significant network traffic.
• Heartbeat Discovery: Runs on SCCM clients and periodically sends discovery data records (DDRs) to the management point, keeping the client record active in the SCCM database. This is the primary method for keeping client records up-to-date.
• Boundary Group Discovery: Discovers clients based on their IP address and boundary group membership.

⚙ Step-by-Step: Configuring Discovery Methods

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Discovery Methods: Go to the Administration workspace, expand Hierarchy Configuration, and click on Discovery Methods.
3. Configure Active Directory Forest Discovery:
   • Right-click on Active Directory Forest Discovery and select Properties.
   • Enable the method and configure discovery schedules and forest publishing options.
   • Specify the AD forests you want to discover.
4. Configure Active Directory Domain Discovery:
   • Right-click on Active Directory Domain Discovery and select Properties.
   • Enable the method and configure the discovery schedule.
   • Click Add... to specify the AD domains and OUs you want to discover. Configure run as account if needed.
5. Configure Active Directory System Discovery:
   • Right-click on Active Directory System Discovery and select Properties.
   • Enable the method and configure the discovery schedule.
   • Click the yellow star icon to add AD containers (domains or OUs) to discover computer objects from. Configure run as account if needed.
6. Configure Active Directory User Discovery:
   • Right-click on Active Directory User Discovery and select Properties.
   • Enable the method and configure the discovery schedule.
   • Click the yellow star icon to add AD containers (domains or OUs) to discover user accounts from. Configure run as account if needed.
7. Configure Active Directory Group Discovery:
   • Right-click on Active Directory Group Discovery and select Properties.
   • Enable the method and configure the discovery schedule.
   • Click the yellow star icon to add AD groups to discover membership from. You can configure recursive discovery. Configure run as account if needed.
8. Configure Network Discovery:
   • Right-click on Network Discovery and select Properties.
   • Enable the method and configure discovery scopes (network segments, SNMP devices, DHCP servers). Be cautious with this method in large environments.
9. Heartbeat Discovery: This method is enabled by default on clients and typically doesn't require manual configuration unless you need to adjust the schedule (found in Client Settings → Agent Settings).

✅ Best Practices for Client Settings and Discovery

• Customize Client Settings Judiciously: Only create custom client settings when you have specific configuration requirements for a subset of clients. Avoid creating too many conflicting policies.
• Test Custom Client Settings: Deploy custom settings to a pilot collection first to ensure they have the desired effect without unintended consequences.
• Enable Necessary Discovery Methods: Configure the discovery methods relevant to your environment to ensure all manageable objects are discovered.
• Schedule Discovery Methods Appropriately: Set discovery schedules based on how frequently your environment changes. Avoid overly aggressive schedules that can impact domain controllers or network performance.
• Use Active Directory Discovery Primarily: Leverage AD discovery methods as they are generally the most accurate and efficient way to discover devices and users in a domain-joined environment.
• Use Network Discovery Sparingly: Exercise caution when using Network Discovery, especially in large or complex networks. Limit the scope to specific network segments if necessary.
• Monitor Discovery Processes: Regularly check the status of discovery methods in the SCCM console to ensure they are running successfully. Review relevant log files on the site server (e.g., adforestdisc.log, adsysdisc.log).
• Consider Security Implications: Ensure that the accounts used for discovery have the necessary permissions to query Active Directory.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Clients Not Being Discovered	Verify that the appropriate discovery methods are enabled and configured correctly. Check the discovery schedules and ensure they have run successfully. Review the discovery logs on the site server for errors. Verify network connectivity and firewall rules if necessary. Ensure the discovery account has sufficient permissions in Active Directory.
Incorrect Client Settings Applied	Review the deployed custom client settings and the collections they are targeted to. Check the precedence of conflicting client settings. Use the Resultant Client Settings feature on a client to determine which settings are being applied. Review the PolicyAgent.log on the client.
Duplicate Records in SCCM Console	This can sometimes occur if multiple discovery methods find the same object. Review your discovery configurations and consider enabling name resolution during discovery. You can also manually reconcile or delete duplicate records.
High Network Traffic Due to Discovery	Review the schedules of your discovery methods, especially Network Discovery. Reduce the frequency or scope of discovery if necessary.

← Hide Details

🔑 SCCM Security: Role-Based Administration (RBAC), Security Scopes, and Security Roles

Security in SCCM is managed through a robust Role-Based Administration (RBAC) system. [cite: SCCM documentation on RBAC] This system utilizes Security Roles and Security Scopes to define who can access what objects and perform which actions within the SCCM console.

🔑 Understanding Role-Based Administration (RBAC)

RBAC in SCCM allows you to grant specific administrative permissions to different users or groups based on their job responsibilities. This ensures that users only have the necessary access to manage the aspects of SCCM relevant to their tasks, enhancing security and reducing the risk of accidental or malicious changes.

The key components of RBAC in SCCM are:

• Security Roles: Define a set of specific permissions that can be assigned to administrative users. These roles determine what actions an administrator can perform (e.g., deploy applications, manage software updates, view inventory).
• Security Scopes: Define the set of objects that an administrative user has permissions to manage. Scopes limit the administrators' access to specific devices, users, collections, applications, etc.
• Security Users: The administrative users or groups to whom security roles and scopes are assigned.
• Collections: Collections of users or devices are often used to define the scope of management.

🔐 Understanding Security Roles

Security Roles are collections of permissions that grant administrative users the ability to perform specific tasks in SCCM. [cite: SCCM documentation on security roles] SCCM provides several built-in security roles, and you can also create custom roles to meet your organization's unique requirements.

Examples of built-in security roles include:

• Full Administrator: Has permissions to manage all aspects of the SCCM site.
• Application Administrator: Can manage applications and application deployments.
• Software Update Manager: Can manage software updates and deployments.
• Endpoint Protection Administrator: Can manage Endpoint Protection policies and monitoring.
• Read-only Analyst: Can view all objects and settings but cannot make any changes.

When you assign a security role to an administrative user, you grant them all the permissions associated with that role.

🔒 Understanding Security Scopes

Security Scopes control which objects an administrative user can view and manage. [cite: SCCM documentation on security scopes] Without a scope, an administrator assigned a role might have the permissions to perform an action but wouldn't be able to see or act upon the relevant objects.

SCCM provides the following types of security scopes:

• All objects: Grants access to all manageable objects in the SCCM site.
• Default: A built-in scope that typically includes commonly managed objects.
• Collection-based scopes: Limit access to the members of specific device or user collections. This is a common way to segment management responsibilities.
• Object-based scopes (Tag-based): You can assign security tags to individual objects (e.g., a specific application or deployment) and then create scopes based on these tags.

When you assign a security scope to an administrative user, their actions are limited to the objects within that scope.

⚙ Step-by-Step: Assigning Security Roles and Scopes to an Administrative User

1. Open SCCM Console: Launch the Configuration Manager console.
2. Navigate to Administrative Users: Go to the Administration workspace, expand Security, and click on Administrative Users.
3. Select or Create an Administrative User:
   • If the user or group already exists, select it.
   • To add a new administrative user, right-click on Administrative Users and select Add Administrative User. Search for and select the Active Directory user or group you want to grant permissions to.
4. Assign Security Roles and Scopes:
   • Select the administrative user.
   • In the ribbon, click Assign Security Roles.
   • In the Add Security Role Assignment window, click Add...
   • Select the security roles you want to assign to this user (e.g., Application Administrator, Read-only Analyst). You can select multiple roles.
   • For each selected role, you need to specify the associated security scopes. In the Associated Security Scopes section, click Add...
   • Choose the security scopes that this user should have access to for the selected role (e.g., All objects, Default, a specific collection).
   • Click OK on the scope selection window and then OK on the role assignment window.
5. Review the assigned roles and scopes for the administrative user in the details pane.

⚙ Step-by-Step: Creating a Custom Security Role

1. Navigate to Security Roles: Go to the Administration workspace, expand Security, and click on Security Roles.
2. Copy an Existing Role (Recommended): Select a built-in role that has similar permissions to what you need for your custom role. Right-click and select Copy. This simplifies the process as you can then modify the copied role.
3. Name and Description: Provide a unique and descriptive name and description for your custom security role.
4. Configure Permissions: Review the list of available permissions, categorized by SCCM features (e.g., Applications, Collections, Operating System Deployment). Check or uncheck the boxes to grant or revoke specific permissions for this role.
5. Click OK to save the custom security role.
6. You can now assign this custom security role to administrative users and associate it with appropriate security scopes.

⚙ Step-by-Step: Creating a Collection-Based Security Scope

1. Navigate to Security Scopes: Go to the Administration workspace, expand Security, and click on Security Scopes.
2. Create Security Scope: In the ribbon, click Create Security Scope.
3. Name: Provide a descriptive name for the security scope (e.g., "London Devices Scope").
4. Click OK.
5. Select the newly created security scope.
6. In the ribbon, click Add Members.
7. In the Add Members window, select Collections from the dropdown.
8. Choose the device or user collections that you want this security scope to apply to (e.g., a collection of computers in the London office).
9. Click OK.
10. Now, when you assign a security role with this scope to an administrative user, they will only be able to manage the objects within the specified collections.

✅ Best Practices for SCCM Security

• Follow the Principle of Least Privilege: Grant administrative users only the minimum permissions necessary to perform their job duties.
• Utilize Built-in Security Roles Where Possible: Leverage the predefined roles as a starting point and create custom roles only when absolutely necessary.
• Use Collection-Based Scopes for Granular Control: Limit administrator access to specific sets of devices or users using collection-based security scopes.
• Regularly Review Security Role Assignments: Periodically audit the security role assignments to ensure they are still appropriate and aligned with user responsibilities.
• Use Security Groups for Administrative Users: Assign security roles and scopes to Active Directory security groups rather than individual user accounts to simplify management.
• Test Custom Security Configurations: Thoroughly test custom security roles and scopes to ensure they function as intended and do not grant unintended access.
• Document Your Security Model: Maintain clear documentation of your custom security roles and scope assignments.
• Separate Administrative Accounts: Use dedicated administrative accounts for SCCM management rather than using personal accounts with elevated privileges.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
Administrator Cannot Perform a Task	Verify that the administrator has been assigned a security role that includes the necessary permissions for the action. Check the associated security scopes to ensure the administrator has access to the relevant objects. Use the "Show Effective Permissions" tool in the SCCM console to analyze a user's permissions on a specific object.
Administrator Has Too Much Access	Review the assigned security roles and scopes for the administrator. Remove any unnecessary role assignments or narrow down the security scopes to limit their access. Consider creating a more restrictive custom security role.
Problems Creating or Modifying Security Roles/Scopes	Ensure you are logged in with an account that has sufficient permissions to manage security settings (typically a Full Administrator). Review the SMSAdminUI.log file for any errors.
Unexpected Behavior Due to Security Settings	Carefully review all assigned security roles and scopes for the affected administrative users. Pay close attention to overlapping scopes and the cumulative effect of multiple role assignments. Test with a dedicated test account if necessary.

← Hide Details

🌀 SCCM Cloud Services: Cloud Management Gateway (CMG) & Co-management

SCCM offers powerful integration with Microsoft Azure cloud services through features like the Cloud Management Gateway (CMG) and Co-management. [cite: SCCM documentation on cloud services] These capabilities extend SCCM's management reach to internet-based clients and enable a hybrid management approach with Microsoft Intune.

🌂 Understanding Cloud Management Gateway (CMG)

The Cloud Management Gateway (CMG) is a cloud service in Azure that acts as a proxy between your on-premises SCCM infrastructure and clients that are not connected to your internal network. [cite: SCCM documentation on CMG] This allows you to manage internet-based clients without requiring them to connect via VPN.

Key benefits and functionalities of CMG include:

• Manage Internet-Based Clients: Extends SCCM management to devices outside your corporate network.
• Content Distribution: Allows internet-based clients to download content (applications, updates) from cloud distribution points or on-premises DPs configured for CMG.
• Policy Management: Enables internet-based clients to receive policies and report compliance status.
• Software Update Management: Facilitates software update scanning and installation for off-network devices.
• Endpoint Protection Management: Allows management of Microsoft Defender Antivirus on internet-based clients.
• No VPN Required: Clients can communicate with SCCM without establishing a VPN connection.
• Azure Authentication: Uses Azure Active Directory (Azure AD) for client authentication.

⚙ Step-by-Step: Deploying a Cloud Management Gateway (High-Level)

Deploying a CMG involves several steps, primarily within the Azure portal and the SCCM console. Here's a high-level overview:

1. Prerequisites:
   • An Azure subscription.
   • Azure AD tenant.
   • A server certificate for the CMG service in Azure.
   • Configuration of Azure Services in SCCM.
   • At least one Cloud Management Point role installed on an on-premises server.
   • Optionally, a Cloud Distribution Point for content delivery.
2. Create the CMG in Azure Portal: Use the SCCM console to guide the creation of the CMG cloud service in your Azure subscription, specifying the region, resource group, and other settings.
3. Configure CMG Connection Point in SCCM: Install and configure the CMG connection point site system role on an on-premises server to manage communication with the CMG in Azure.
4. Configure Cloud Management Point: Ensure you have at least one management point configured to communicate with the CMG.
5. Configure Boundary Groups: Associate boundary groups with the CMG to allow clients within those boundaries to utilize the CMG.
6. Verify Deployment: Monitor the status of the CMG in the SCCM console and Azure portal. Check client logs (CMGConnector.log, CCMMessage.log) for communication status.

👤👥 Understanding Co-management

Co-management is a feature that allows you to concurrently manage Windows 10 or later devices using both SCCM and Microsoft Intune. [cite: SCCM documentation on co-management] This provides a bridge to modern management and allows you to transition workloads gradually to the cloud.

Key benefits and functionalities of co-management include:

• Hybrid Management: Manage devices with both the traditional SCCM agent and the modern Intune MDM agent.
• Gradual Workload Transition: You can choose which workloads (e.g., device compliance, software updates, client apps) are managed by Intune, SCCM, or both. This allows for a phased migration to modern management.
• Conditional Access Integration: Leverage Intune's device compliance policies for Azure AD Conditional Access.
• Modern Provisioning: Utilize Windows Autopilot for streamlined device enrollment.
• Single Pane of Glass: View co-managed devices and their status in both the SCCM console and the Microsoft Endpoint Manager admin center (Intune portal).

⚙ Step-by-Step: Enabling Co-management (High-Level)

Enabling co-management involves configuring settings in both SCCM and Intune (Microsoft Endpoint Manager admin center). Here's a high-level overview:

1. Prerequisites:
   • Microsoft Intune subscription.
   • Azure AD Connect configured for hybrid identity.
   • Devices must be Azure AD joined or hybrid Azure AD joined.
   • SCCM current branch environment.
   • Configuration of Azure Services in SCCM for Cloud Management.
2. Configure Co-management in SCCM Console: Navigate to the Cloud Services workspace and configure the Co-management settings, including connecting to your Azure AD tenant and Intune subscription.
3. Configure Enrollment Settings: Define how clients will be enrolled into Intune for co-management (e.g., automatic enrollment for hybrid Azure AD joined devices).
4. Pilot Co-management (Recommended): Deploy co-management settings to a pilot collection of devices first.
5. Configure Workloads: Gradually transition workloads to Intune management (e.g., Intune for device compliance, SCCM for software updates initially). You can change the management authority for each workload over time.
6. Monitor Co-management Status: Monitor the enrollment status and workload management authority of your co-managed devices in the SCCM console and the Microsoft Endpoint Manager admin center.

✅ Best Practices for Cloud Services

• Plan Your CMG Deployment Carefully: Consider the number of internet-based clients and the expected network traffic when sizing your CMG in Azure. Secure your CMG with appropriate certificates.
• Use Cloud Distribution Points for CMG: For optimal performance and cost-effectiveness, consider using Azure-based cloud distribution points to serve content to internet-based clients managed via CMG.
• Pilot Co-management: Start with a small pilot group of devices to test your co-management configuration and workload transitions before deploying to a wider audience.
• Strategically Transition Workloads: Choose your co-management workloads based on your organizational needs and readiness for modern management. Start with less critical workloads and gradually move towards managing more aspects with Intune.
• Monitor Cloud Service Health: Regularly monitor the status of your CMG in the Azure portal and the CMG connection point in the SCCM console. Monitor co-management enrollment and workload status.
• Utilize Azure AD Groups for Targeting: Leverage Azure AD groups for targeting co-management policies and workloads.
• Keep SCCM Current: Ensure your SCCM environment is running a current branch version to take advantage of the latest cloud integration features and improvements.

🐚 Common Issues & Troubleshooting

Issue	Possible Resolution
CMG Not Healthy	Check the CMG status in the SCCM console and the Azure portal for errors. Review the CMGConnector.log and SMS_CLOUD_PROXYCONNECTOR.log on the CMG connection point server. Verify the health of the underlying Azure services. Ensure the CMG certificate is valid.
Internet Clients Not Communicating with CMG	Verify network connectivity from the internet clients to the CMG endpoint. Ensure the clients have a valid PKI certificate or are Azure AD joined. Check client logs (CCMMessage.log, LocationServices.log). Verify boundary group associations with the CMG.
Co-management Enrollment Failures	Review the co-management enrollment status in the SCCM console and the Microsoft Endpoint Manager admin center. Check client logs (CoManagementHandler.log, MDMEnrollment.log). Ensure devices meet the prerequisites for co-management (Azure AD joined, SCCM agent installed).
Workloads Not Transitioning as Expected	Review the co-management workload configuration in the SCCM console. Check client logs (CoManagementHandler.log) to see which management authority is active for each workload. Ensure policies are correctly targeted in both SCCM and Intune.

← Hide Details