Installing Microsoft SCCM: Step-by-Step Guide

Note: Microsoft SCCM is now officially part of Microsoft Configuration Manager, but many administrators still call it SCCM because old habits are harder to uninstall than printer drivers. This guide uses both names naturally and focuses on a practical, production-minded installation process for Configuration Manager current branch.

Introduction: Why SCCM Still Matters

Installing Microsoft SCCM is not the kind of task you casually start on a Friday afternoon while sipping coffee and hoping the wizard “just figures it out.” SCCM, now known as Microsoft Configuration Manager, is a powerful enterprise management platform used to deploy software, manage updates, inventory hardware and software, control compliance settings, deploy operating systems, and keep Windows endpoints under control before they begin forming their own tiny rebellion.

Even in a world full of cloud-first tools, SCCM remains important for organizations that need deep control over on-premises infrastructure, complex Windows environments, remote distribution points, operating system deployment, and software update management. When integrated with Microsoft Intune through co-management, Configuration Manager can also support modern endpoint management while preserving the power of traditional client administration.

This step-by-step guide walks through the installation process in a practical way: planning, prerequisites, SQL Server preparation, Active Directory configuration, Windows Server roles, setup wizard choices, post-installation tasks, and real-world lessons that can save you from late-night troubleshooting sessions powered only by panic and vending machine snacks.

What Is Microsoft SCCM?

Microsoft SCCM, or System Center Configuration Manager, is the former name for what is now Microsoft Configuration Manager. It is part of the Microsoft Intune family and is designed to help IT teams manage large groups of Windows devices from a centralized console.

With SCCM, administrators can deploy applications, install Windows updates, run compliance checks, collect inventory, push operating system images, manage endpoint protection settings, and generate reports. For businesses with hundreds or thousands of computers, SCCM acts like the traffic controller, warehouse manager, librarian, mechanic, and slightly grumpy security guard all rolled into one.

Before Installing SCCM: Plan the Environment First

The biggest mistake in an SCCM installation is treating it like a normal application setup. SCCM is not a simple “Next, Next, Finish” product. It depends on Active Directory, SQL Server, Windows Server roles, network ports, DNS, permissions, service accounts, and client communication planning.

Before installation, decide what kind of site you need. Most small and midsize organizations start with a standalone primary site. A Central Administration Site, or CAS, is only needed in larger hierarchies with multiple primary sites. If your environment is not large enough to justify a CAS, do not install one just because it sounds powerful. Extra complexity is not a personality upgrade.

Key Planning Questions

How many clients will SCCM manage?
Will clients be on one network or multiple locations?
Will you deploy operating systems?
Will you use software update management with WSUS?
Will SCCM integrate with Microsoft Intune?
Where will the SQL Server database live?
Which servers will host management points, distribution points, and software update points?

Answering these questions early helps you avoid rebuilding the environment later. SCCM rewards planning and punishes improvisation with logs. So many logs.

Recommended Lab or Production Server Setup

For a simple lab, you can install Configuration Manager, SQL Server, management point, distribution point, and software update point on a single Windows Server. For production, however, separate roles may be better depending on size, performance, and security needs.

Example Small Environment

One Windows Server for Configuration Manager primary site
SQL Server installed locally on the site server
Management point and distribution point on the same server
Software update point installed with WSUS
Active Directory domain already configured

Example Larger Environment

Dedicated primary site server
Dedicated SQL Server
Multiple distribution points across branch offices
Separate reporting services point
Cloud Management Gateway if internet-based client management is required

Step 1: Prepare Active Directory

Active Directory preparation is one of the first major steps in installing SCCM. Configuration Manager can publish site information in Active Directory so clients can find management points, distribution points, and other site resources more easily.

In many environments, administrators extend the Active Directory schema for Configuration Manager. This is a one-time forest-level action. It adds classes and attributes that help SCCM publish important information. The account used for this task must have appropriate permissions, typically Schema Admin rights.

Create the System Management Container

After extending the schema, create the System Management container in Active Directory under the System container. Then delegate permissions to the SCCM site server computer account. The site server usually needs Full Control permissions on the System Management container and its child objects.

This step is easy to overlook, but skipping it can lead to client discovery and publishing problems later. Think of the System Management container as SCCM’s official bulletin board in Active Directory. Without it, clients may spend too much time asking, “Where is everybody?”

Step 2: Prepare Service Accounts

A clean SCCM installation should use dedicated service accounts instead of one magical administrator account that does everything. Service accounts make troubleshooting, auditing, and security management easier.

Common SCCM Accounts

SQL Server service account: Runs SQL Server services if you are not using built-in accounts.
Client push installation account: Used to install the Configuration Manager client on domain computers.
Network access account: Used in certain scenarios where clients need access to content during operating system deployment.
Reporting services account: Used if SQL Server Reporting Services is configured.

Use strong passwords, document each account, and apply only the permissions required. Future you will appreciate this when something breaks six months later and nobody remembers why an account named “SCCMtest2-final-new” exists.

Step 3: Install and Configure SQL Server

SQL Server is one of the most important components in an SCCM installation. The Configuration Manager site database stores configuration data, inventory, deployment information, status messages, and a mountain of operational details.

Use a supported 64-bit version of SQL Server for your Configuration Manager current branch version. Always confirm compatibility before installation because supported versions can change over time. In production, SQL Server should be sized carefully for the number of clients, expected inventory load, reporting needs, and software update activity.

SQL Server Configuration Tips

Install the Database Engine feature.
Use the required SQL collation, commonly SQL_Latin1_General_CP1_CI_AS.
Configure SQL memory limits instead of letting SQL Server eat RAM like it found an all-you-can-buffet.
Place database files, log files, and tempdb on appropriate storage for production environments.
Enable TCP/IP in SQL Server Network Configuration if required.
Make sure the SCCM site server has proper SQL permissions.

For smaller environments, SQL Server can be installed on the same server as SCCM. For larger environments, a dedicated SQL Server may improve performance and make maintenance easier.

Step 4: Install Windows Server Roles and Features

Configuration Manager requires several Windows Server roles and features depending on which site system roles you plan to install. Common requirements include components for IIS, Background Intelligent Transfer Service, Remote Differential Compression, and Windows deployment features.

Common Features Used by SCCM

.NET Framework 4.8
Remote Differential Compression
Background Intelligent Transfer Service
IIS Management Console
Windows Authentication
ASP.NET components where required
WSUS for the software update point role

The exact features depend on your planned roles. A management point, distribution point, software update point, reporting services point, and fallback status point all have different requirements. Before running setup, verify every prerequisite instead of waiting for the prerequisite checker to roast your server configuration.

Step 5: Install Windows ADK and WinPE Add-On

If you plan to use SCCM for operating system deployment, install the Windows Assessment and Deployment Kit, better known as Windows ADK. You also need the Windows PE add-on because modern ADK versions separate Windows PE from the main ADK installer.

The ADK provides deployment tools, imaging tools, and components used to create boot images. Without it, operating system deployment will not work properly. If you are only using SCCM for software deployment and inventory, ADK may not be immediately necessary, but most organizations eventually want imaging capabilities.

ADK Installation Advice

Install a version of Windows ADK supported by your Configuration Manager version.
Install the Windows PE add-on after installing ADK.
Restart the server if required.
Update boot images after SCCM installation if needed.

Step 6: Prepare WSUS for Software Updates

If you want SCCM to manage Windows updates, install Windows Server Update Services before adding the Software Update Point role. WSUS works with SCCM to synchronize update metadata from Microsoft and make updates available for deployment.

In an SCCM environment, do not manage approvals directly in the WSUS console. SCCM should control update deployment. WSUS is there to support the software update point, not to become the second boss in the room.

WSUS Best Practices

Use a dedicated WSUS database when possible.
Do not configure automatic approvals in WSUS.
Let Configuration Manager handle update deployment rules.
Plan WSUS cleanup and maintenance.
Make sure required firewall ports are open.

Step 7: Download Microsoft Configuration Manager

Download the Microsoft Configuration Manager current branch installation media from Microsoft. Evaluation versions are available for lab testing, while production installations require proper licensing.

Extract the installation media carefully. Microsoft often provides SCCM media as a self-extracting file. Use a reliable extraction tool and store the installation files in a clean folder path without odd characters or unnecessary spaces. This is not the time to name a folder “New Folder Copy Final Actually Use This One.”

Step 8: Run the Configuration Manager Setup Wizard

To begin installation, run Setup.exe from the installation media, usually located under the SMSSETUP\BIN\X64 folder. The Setup Wizard guides you through the process of installing a primary site or central administration site.

Important Setup Wizard Choices

Install a primary site: Best for most standalone environments.
Use an evaluation version or product key: Choose based on licensing.
Download prerequisite files: SCCM needs additional setup files.
Set the site code: Use a three-character code that cannot be changed later.
Set the site name: Use a clear descriptive name.
Choose installation folder: Do not install on the system drive if your design requires separation.
Configure SQL Server settings: Specify SQL Server name, instance, and database name.
Configure SMS Provider: Usually installed on the site server for smaller environments.
Choose client communication method: HTTP, HTTPS, or enhanced HTTP depending on your security design.

The site code deserves special attention. Once selected, it cannot be changed. Pick something meaningful and boring. In infrastructure, boring is good. Boring means nobody has to explain why the production site code is “LOL.”

Step 9: Run the Prerequisite Check

Before installation begins, the Setup Wizard runs prerequisite checks. These checks validate server roles, permissions, SQL Server configuration, Active Directory preparation, firewall access, required components, and other dependencies.

Do not ignore warnings casually. Some warnings may be acceptable in a lab, but production environments should be as clean as possible. Errors must be fixed before continuing. The prerequisite checker is not being dramatic; it is trying to prevent your future headache.

Common Issues Found During Prerequisite Checks

Missing .NET Framework requirements
Unsupported SQL Server version
Incorrect SQL collation
Missing Windows Server roles
Insufficient permissions
Active Directory publishing issues
Firewall or port problems

Step 10: Complete the SCCM Installation

After prerequisites pass, continue with the installation. The process may take a while depending on server performance, SQL configuration, and selected components. During installation, Configuration Manager creates the site database, installs core services, configures the SMS Provider, and prepares the console.

Installation progress can be monitored in the wizard and through log files. SCCM is famous for its logs, and learning where to find them is a survival skill. The main setup log is commonly ConfigMgrSetup.log, and it is one of the first places to check if installation fails.

Step 11: Open the Configuration Manager Console

After setup completes successfully, open the Configuration Manager console. This is where administrators manage devices, collections, applications, updates, compliance settings, reports, and site configuration.

At first, the console may look quiet because SCCM does not magically know your environment. You need to configure discovery methods, boundaries, client settings, and site roles before it becomes useful.

Step 12: Configure Discovery Methods

Discovery methods allow SCCM to find users, groups, computers, and Active Directory sites. Common discovery methods include Active Directory Forest Discovery, Active Directory System Discovery, Active Directory User Discovery, and Active Directory Group Discovery.

Start with only what you need. Overly broad discovery can fill SCCM with stale objects faster than a shared drive fills with files named “final_v7_reallyfinal.”

Recommended Discovery Approach

Enable Active Directory Forest Discovery to detect AD sites and subnets.
Enable System Discovery for targeted organizational units.
Enable User Discovery if user-based deployments are needed.
Schedule discovery intervals carefully.

Step 13: Configure Boundaries and Boundary Groups

Boundaries define network locations such as IP subnets, IP ranges, VPN ranges, or Active Directory sites. Boundary groups connect those network locations to site systems such as distribution points and management points.

This step is critical. If boundaries are misconfigured, clients may fail to find content or may download from the wrong distribution point. That can turn one innocent application deployment into a bandwidth-eating monster.

Boundary Best Practices

Use IP ranges when they more accurately represent client locations.
Assign distribution points to the correct boundary groups.
Create separate boundary groups for remote offices when needed.
Review VPN client ranges carefully.

Step 14: Install SCCM Client Agents

The Configuration Manager client must be installed on managed devices. You can deploy it using client push installation, Group Policy, software update-based installation, manual installation, operating system deployment, or Microsoft Intune co-management scenarios.

Client push installation is common in domain environments. It requires proper firewall rules, administrative permissions on target machines, and healthy name resolution. When client installation fails, check logs such as ccmsetup.log on the client device.

Client Installation Example

A typical client push configuration might target computers discovered from a specific Active Directory OU. Once installed, the client reports back to the management point, receives policy, and appears in the SCCM console as an active managed device.

Step 15: Add Site System Roles

After the primary site is installed, add the site system roles your environment needs. The most common roles are management point, distribution point, software update point, reporting services point, and fallback status point.

Common Site Roles

Management Point: Handles client policy and client communication.
Distribution Point: Stores content such as applications, packages, updates, and boot images.
Software Update Point: Integrates with WSUS for update management.
Reporting Services Point: Provides reports through SQL Server Reporting Services.
State Migration Point: Supports user state migration during operating system deployment.

For branch offices, distribution points are especially important. They keep content close to clients and reduce WAN traffic. Without them, one large deployment can make the network team suddenly appear at your desk with questions.

Step 16: Configure Software Updates

Once the Software Update Point role is installed, configure synchronization settings, product categories, classifications, and sync schedules. Start small. Select only the products and classifications you actually need.

For example, if your organization only manages Windows 10, Windows 11, Microsoft 365 Apps, and Microsoft Edge, do not synchronize every possible Microsoft product. More metadata means more database load, longer synchronization, and a console that feels like it is walking through wet cement.

Software Update Tips

Use Automatic Deployment Rules for predictable monthly patching.
Create pilot collections before broad deployment.
Use maintenance windows for servers.
Review compliance reports after deployments.
Maintain WSUS and the SCCM database regularly.

Step 17: Create Device Collections

Collections are used to organize devices and users for deployments, reporting, and policy targeting. You can create direct membership collections or query-based collections.

For example, you might create collections for Windows 11 laptops, accounting department computers, pilot testing devices, servers, or machines missing a specific application. Good collection design makes SCCM easier to operate. Bad collection design turns the console into a junk drawer with a search bar.

Step 18: Deploy a Test Application

Before rolling out major software packages, deploy a small test application to a pilot collection. This validates client health, distribution point content, detection methods, and deployment settings.

Basic Application Deployment Flow

Create an application in the SCCM console.
Add deployment type information.
Configure installation and detection rules.
Distribute content to distribution points.
Deploy the application to a test collection.
Monitor deployment status.

Detection methods are especially important. SCCM needs to know whether the application is already installed. A weak detection rule can cause repeated installation attempts, false failures, or software that behaves like it forgot it already moved in.

Step 19: Configure Backup and Maintenance

After installation, configure backup and maintenance tasks. A Configuration Manager site contains critical operational data, and recovery planning should not begin after a server failure.

Enable the built-in site backup maintenance task or use a supported SQL backup strategy. Document recovery steps, backup locations, service accounts, SQL configuration, and installation media versions.

Maintenance Tasks to Review

Site backup schedule
Delete aged discovery data
Delete aged inventory history
Rebuild indexes
Update statistics
WSUS cleanup
Distribution point content validation

Step 20: Monitor Logs Like a Professional

SCCM troubleshooting depends heavily on log files. The good news is that Configuration Manager logs usually explain what is happening. The bad news is that there are many of them, and they do not care about your weekend plans.

Useful SCCM Logs

ConfigMgrSetup.log: Site installation details.
hman.log: Hierarchy Manager activity.
sitecomp.log: Site component installation activity.
distmgr.log: Distribution manager activity.
mpcontrol.log: Management point health.
wsyncmgr.log: Software update synchronization.
ccmsetup.log: Client installation activity.
LocationServices.log: Client site and management point location.

Use the Configuration Manager log viewer, CMTrace, to read logs more easily. It highlights errors and warnings, making it far better than staring at Notepad while questioning your career choices.

Common SCCM Installation Mistakes

Installing Without a Clear Design

SCCM should be designed before installation. Decide where roles will live, how clients will communicate, how content will be distributed, and how updates will be managed.

Choosing the Wrong Site Code

The site code cannot be changed later. Use a simple three-character code that fits your naming standards.

Ignoring SQL Server Sizing

SQL Server performance affects the whole SCCM environment. Do not starve it of memory, storage performance, or maintenance.

Misconfiguring Boundaries

Boundaries control how clients find services and content. Poor boundary planning causes deployment failures and network pain.

Synchronizing Too Many Updates

Selecting every product and classification in software updates creates unnecessary load. Choose only what your organization uses.

Real-World Experience: Lessons From Installing SCCM

Installing SCCM in the real world is a little different from installing it in a perfect lab guide. In a lab, every server responds, every permission works, DNS behaves like a responsible adult, and the firewall is either open or politely documented. In production, you may discover an old domain controller nobody mentioned, a forgotten subnet from 2014, and a branch office connected by a network line that apparently runs through a potato.

One of the most useful experiences from SCCM installations is learning to slow down at the beginning. Many failed deployments are not caused by the setup wizard itself. They are caused by assumptions. For example, an administrator assumes the SQL Server collation is correct, assumes the site server has permissions in Active Directory, assumes ports are open, and assumes client machines can resolve the management point. SCCM has a special talent for finding every assumption and turning it into a red error message.

A smart approach is to build a checklist before touching the installer. Confirm the operating system version, SQL Server version, SQL collation, .NET Framework, Windows Server roles, AD schema status, System Management container permissions, DNS records, firewall rules, service accounts, and disk layout. This sounds boring, but boring checklists are cheaper than emergency troubleshooting.

Another lesson is to start with a pilot group. Do not install the SCCM client across the entire company on day one. Begin with IT test machines, then a small group of friendly users, then a larger pilot collection. Watch client health, policy retrieval, inventory reporting, software deployment, and update compliance. A pilot group gives you room to fix mistakes before they become company-wide “learning opportunities.”

Distribution points also deserve more attention than they usually receive. In one common scenario, an organization deploys SCCM successfully at headquarters but forgets that remote offices have limited bandwidth. The first large application deployment then crawls across the WAN and everyone blames SCCM. In reality, SCCM was doing exactly what it was told. Good boundary groups and local distribution points can prevent this problem.

Software updates are another area where patience matters. New administrators sometimes synchronize too many products and classifications because “more coverage” sounds safer. The result is a bloated update catalog, slower scans, longer sync times, and more maintenance. A better strategy is to select only the required Microsoft products, create pilot deployment rings, and review compliance before expanding.

Logs are the final survival skill. SCCM is not silent; it tells you what it is doing through logs. Client installation problems often appear in ccmsetup.log. Update synchronization issues appear in wsyncmgr.log. Distribution problems show up in distmgr.log. Management point issues often appear in mpcontrol.log. Once you become comfortable reading logs, SCCM feels less mysterious and more like a very detailed coworker who writes everything down.

The best SCCM installations are not the flashiest. They are clean, documented, monitored, and boring in the best possible way. The server names make sense. The service accounts are documented. The boundaries match the network. The collections are organized. The SQL database is maintained. The backup process is tested. That kind of installation may not look exciting, but it lets IT teams sleep at night, which is the true luxury feature.

Conclusion

Installing Microsoft SCCM, or Microsoft Configuration Manager, is a serious infrastructure project that requires careful preparation. The installation wizard is only one part of the journey. A successful deployment depends on planning your hierarchy, preparing Active Directory, configuring SQL Server correctly, installing required Windows components, setting up ADK and WSUS when needed, validating prerequisites, configuring discovery and boundaries, deploying clients carefully, and maintaining the environment after installation.

When done well, SCCM becomes one of the most powerful tools in an IT department’s toolkit. It can automate software deployment, simplify patch management, support operating system deployment, improve reporting, and bring order to thousands of endpoints. When done poorly, it becomes a noisy machine full of failed deployments, confused clients, and logs that read like a mystery novel.

The secret is simple: plan first, install second, test carefully, monitor constantly, and document everything. SCCM may be complex, but with the right approach, it is absolutely manageable. And yes, once it is running smoothly, you are allowed to feel like an endpoint management wizard.