Introduction
Hello everyone and welcome to Techaptic. Today we are kicking off the first episode of our Deep Dive series on the flagship of enterprise system management, Microsoft Configuration Manager. Setting up Configuration Manager properly requires much more than just following a wizard. It requires careful infrastructure preparation and the right permission architecture.
In this video, we will go through every stage of a professional deployment, from hardware planning and Active Directory schema extension to preparing operating system components with PowerShell and configuring the required permissions between computer objects. By the end of the video, you will not only have a working management console, but also a solid enterprise-grade foundation for the management processes that follow. If you’re ready, let’s get started.
Configuration Manager Architecture and Server Roles
First, let’s look at our infrastructure. We have three Windows Server 2025 servers: a Domain Controller, a Configuration Manager server, and a SQL Server. We will install Configuration Manager version 2509 as a stand-alone Primary Site. There is a reason why we are specifically using 2509. Even if a newer Current Branch update is available, a new site installation must start from baseline media, and 2509 is currently the latest baseline version. After the site is up and running, we can move to a newer Current Branch version later through in-console servicing if needed.
We will also keep several site system roles on the Site Server instead of distributing them across separate servers. We are not presenting this as a best practice for every environment. We chose it because it makes management easier in small and medium-sized environments or simpler designs. As the environment grows or becomes more complex, these roles can be distributed to different servers.
For the database, we will use SQL Server 2022. One thing we sometimes see is Configuration Manager and its SQL database installed on the same server. Later, increasing workloads or different requirements can lead to the two being separated. We are placing the database on a separate and dedicated SQL Server from the beginning, so future resource and scaling requirements will be easier to manage.
To keep the video from getting unnecessarily long, I already installed and configured the Domain Controller and SQL Server, but we will still go through the prerequisites and the best practice settings we used one by one. Now let’s move to the prerequisite and infrastructure information.
Configuration Manager Hardware and Software Requirements
On this page, we can see the hardware and software requirements. Especially on the hardware side, I want to make one thing clear from the beginning: these values are not mandatory or minimum requirements, and they can change from one environment to another. But if you are looking for a safe starting point, you can use this table as a baseline.
For the Site Server, we prepared 8 vCPUs, 16 GB of RAM, and two separate disks for the installation files and content such as software and updates. For SQL Server, we start with 4 vCPUs and 16 GB of memory, and we created four separate disks for Data, Log, TempDB, and backups. We formatted the SQL disks with a 64 KB Allocation Unit Size. This is not a magic setting that automatically improves SQL performance, but it fits SQL Server I/O behavior better and is generally accepted as a best practice.
The main reason we separate the disks is that components such as Data, Log, and TempDB have different I/O behavior. Keeping them on separate disks reduces the chance of one workload unnecessarily affecting another. The same idea also applies to the Configuration Manager server. Separating the operating system from content and application data is important to reduce possible I/O bottlenecks. Of course, in a production environment, simply creating different disks in Windows is not enough. The storage behind those disks, disk types, IOPS, and latency are also important.
On the software side, we use SQL Server 2022 Enterprise as our database server, but Standard edition can also be used. We will prepare the required .NET components and Windows features for Configuration Manager and the roles we are going to host on it. Components such as IIS and BITS are not universal requirements for Configuration Manager itself, but some of them are required because of the roles we are enabling in our design.
For operating system deployment, we will install a Windows ADK version supported by Configuration Manager 2509 together with the matching WinPE add-on. Using the newest ADK version is not always the right approach. We need to choose an ADK version supported by the Configuration Manager version we use. Since we are installing version 2509, we will use one of the supported versions. You can check the supported ADK versions from the table linked in the description.
Finally, a supported version of Microsoft ODBC Driver 18 needs to be installed for SQL connectivity. One of the prerequisites for this driver is the Microsoft Visual C++ Redistributable package. Visual C++ x86 and x64 packages are also among the Configuration Manager installation requirements for a Primary Site. They are usually already installed on servers, but if they are missing, we need to install them.
SQL Server Baseline, Memory and Network Requirements
On our last slide, we can see both the SQL Server baseline settings and the network communication requirements. On the SQL Server side, we configured the SQL instance collation as SQL_Latin1_General_CP1_CI_AS. This is a required setting for the Configuration Manager Site Database.
We also set the SQL Server minimum server memory value to at least 8 GB. This does not mean SQL Server immediately reserves 8 GB of memory when it starts. When the system reaches this amount of memory usage, it tries not to go below this value when possible. Microsoft also recommends setting this value to at least 8 GB for Configuration Manager. While configuring this setting, we also should not leave the maximum server memory value unlimited. This helps prevent SQL Server from using system memory without control and leaves enough memory available for the operating system and other processes.
For authentication, we will use Windows Authentication, and we configured a gMSA, or Group Managed Service Account, as the SQL Server service identity. With this setup, Active Directory manages the account credentials for us and changes the password regularly. This gives us a secure service account without manual password management. On the Kerberos side, we also configured the SQL Server SPN records so authentication can work correctly.
In our design, SQL Server is dedicated to this workload. The purpose is to avoid sharing the Site Database workload with databases from unrelated applications on the same SQL instance without control.
Because we are using a remote SQL Server, Configuration Manager Setup needs remote access to some system and configuration information on the SQL Server. For this reason, the Remote Registry service must not be disabled during installation.
On the network side, this is not a complete list of every port used by Configuration Manager. It only shows the main ports we need for the installation in this video. We will use TCP 1433 for Configuration Manager database communication. Because we are using remote SQL, we also need ports 135, 445, and the dynamic RPC ports during the site installation. Finally, the Site Server needs ports 80 and 443 to access some prerequisite and update files over the internet.
Active Directory Schema Extension and System Management Container
Now let’s move to the configuration part, starting on the Domain Controller. We will extend the Active Directory schema so Configuration Manager can publish site information to Active Directory and clients can find this information more easily. This operation is performed once per forest, on the domain controller that holds the Schema Master role, using an account that is a member of Schema Admins.
I already downloaded the Configuration Manager installation files to the server. Open the SMSSETUP\BIN\X64 directory, then open Command Prompt with administrative rights and go to that directory. The application we need is extadsch.exe. Run it, and after a short operation you should see the message “Successfully extended the Active Directory Schema”. That confirms the schema extension completed successfully.
Our next step is to create a container called System Management using ADSI Edit. When Active Directory Publishing is enabled, Configuration Manager publishes site information under this container. This allows clients to find site and related service information from Active Directory as a trusted source.
Open ADSI Edit from Windows Tools, select Connect to, and connect to the Default Naming Context. Under Default Naming Context, expand the directory to System, right-click System, and select New > Object. Choose Container as the class and enter System Management as the value. Make sure the name is entered exactly and without typing mistakes, then finish the wizard.
Next, we need to give the Configuration Manager Site Server computer account the required permissions on this container. Open Active Directory Users and Computers and enable Advanced Features from the View menu. Under System, right-click the System Management container and select Delegate Control. Add the Site Server computer account, making sure Computers is enabled under Object Types.
On the Tasks to Delegate page, select Create a custom task to delegate. On the next page, choose the option that applies the permissions to this folder, existing objects in this folder, and the creation of new objects in this folder. Under Show these permissions, select General, Property-specific, and Creation/deletion of specific child objects, and then grant Full Control. Finish the wizard. If you want to verify the result, open the Security tab in the System Management container properties and confirm the permissions assigned to the computer account.
That completes the Active Directory-side configuration. One small reminder: we will not go into Active Directory port configuration here because our domain member servers already have the required communication with the Domain Controller. If you use a firewall or network segmentation in your environment, make sure the required Active Directory communication ports are allowed.
SQL Server Configuration, gMSA and Permissions
Now let’s move to the SQL Server. First, we will check one of the installation prerequisites, Microsoft ODBC Driver 18. The Visual C++ x64 package also needs to be available for the driver, so let’s check that first. Visual C++ v14 x64 is already installed. Microsoft ODBC Driver 18 is also already installed, so there is nothing else we need to do for these two items.
Now let’s check the services. As I mentioned before, we configured the SQL Server service to run with the gMSA account. The service is running and the gMSA is configured as the Log On account. We do not need the SQL Server Browser service because we are using the Default Instance with a static TCP 1433 port, so it can remain stopped. Let’s also check the Remote Registry service. It is not disabled, which is what we need for this setup.
In the next step, we need to add both the Configuration Manager Site Server computer account and the user account that we will use for Setup to the Local Administrators group on the SQL Server, and we also need to give both accounts sysadmin permissions in SQL Server. The Site Server computer account needs these permissions for the management operations Configuration Manager performs on SQL Server. The Setup account also needs this level of access during installation so it can create the Site Database and perform the required SQL Server setup operations.
Let’s start with the Local Administrators group. Open Computer Management, go to Local Users and Groups > Groups > Administrators, and add the Setup user account. Then enable Computers under Object Types and add the Site Server computer account as well.
Now open SQL Server Management Studio. Under Security > Logins, create a Windows Authentication login for the Setup user and assign the sysadmin server role. For the Site Server computer account, we will use a SQL query to create the login and add it to the sysadmin role. After running the query, refresh Logins and verify that the computer account exists and has the expected server role. That completes the SQL Server preparation.
Site Server Prerequisites, Windows ADK and WinPE
Now let’s move to the Configuration Manager server and complete the prerequisites. To make the process faster, we will install the required Windows components with a PowerShell script. Create the script file, save it with the .ps1 extension, and paste in the script prepared earlier. You can also download this script from our website. Open PowerShell as Administrator and run it.
The required components are installed. I will restart the server once so we can continue with a clean installation. After the restart, let’s check Visual C++. On the Configuration Manager Site Server, both the x86 and x64 packages should be installed. Both are already present, so we can skip any additional installation here.
Now let’s install Microsoft ODBC Driver 18. There are no special settings required for our example, so we can complete the installation with the default options.
Next, we will install the Windows ADK required for Configuration Manager and the WinPE add-on used for operating system deployment. To keep the video shorter, I already downloaded the installation files to the server. We will start with Windows ADK. For our setup, Deployment Tools and User State Migration Tool are enough. Deployment Tools contains the main tools we will use for operating system deployment. User State Migration Tool allows us to move user files and settings to a new system during operating system deployments.
After Windows ADK is installed, we move to the Windows Preinstallation Environment, or WinPE, add-on. WinPE provides the environment where a device can boot and run task sequence and image operations during operating system deployment. We can complete this installation with the default options.
Content Library Disk Configuration
Finally, before we move to the Configuration Manager installation, we will make one small disk-side configuration. When Configuration Manager automatically selects a disk for the Content Library on the Distribution Point, it can use suitable disks based on available free space. We do not want the operating system disk to be used for this purpose.
To prevent that, we will create an empty file with a specific name and extension in the root of the C drive. Configuration Manager will not use a disk containing this file for the Content Library. Open PowerShell with administrative rights and run the small command we prepared. Then go to the C drive and verify that the file exists. It is an empty file, but it is important for controlling where the Content Library can be placed.
With this last step, our prerequisites are complete. Now we can move to the product installation. If you want to try the product, you can use the Microsoft Evaluation Center. If you have a license, you can download the baseline media from the Volume Licensing section in Microsoft 365 Admin Center.
Configuration Manager 2509 Primary Site Installation and Site Settings
Let’s open the Configuration Manager installation files that we downloaded earlier. Double-click Splash.hta to open the starting screen, then click Install to launch the Setup Wizard. The first page reminds us that Configuration Manager has prerequisites that should be checked before installation. We have already prepared them, so we can continue.
On the Getting Started page, Setup tells us it could not detect an existing Configuration Manager infrastructure in the environment, so we will build a new environment from scratch. A Configuration Manager installation can basically start with either a Primary Site or a Central Administration Site, or CAS. A CAS is mainly used in large and distributed environments where more than one Primary Site is required and those sites need to be managed centrally. Clients do not connect directly to the CAS; device management is handled by the Primary Sites under it.
In our environment, one Primary Site is enough, so we will install a stand-alone Primary Site. If needed later, we can expand the hierarchy by adding a CAS. Select Install a Configuration Manager primary site. We will not select Use typical installation options for a stand-alone primary site because we want to configure the SQL Server, installation path, and site role settings ourselves.
The Product Key page is where we enter evaluation or permanent license information. If you want to try the product, select Install the evaluation edition of this product to use the 180-day evaluation version. If you have a product key, you can choose the licensed edition option and enter the key. An evaluation installation can also be converted to a licensed edition later. We will use the evaluation option for this installation.
On the Product License Terms page, accept the required license agreements and continue.
The next page asks whether we want to download the required Configuration Manager prerequisite files now or use files that were downloaded earlier. We already downloaded them, so we will use the previously downloaded files option and point Setup to the appropriate directory.
On the Server Language Selection page, we choose the languages to use in the Configuration Manager Console and reports. More than one language can be added, but we will keep English as the default in our environment. Client Language Selection determines which languages the Configuration Manager client can display. If the selected language matches the client computer’s display language, the client interface is shown in that language. If the client uses an unsupported language, English is used by default. We will select both English and Turkish.
Now we are moving to the Site and Installation Settings. First, we need to define a Site Code. The Site Code is a three-character alphanumeric code that identifies the Primary Site. It must be unique within the hierarchy and cannot be changed later. We will use TEC. The Site Name is a descriptive name that helps identify the site, so we will use Techaptic.
We also need to choose the installation directory. This setting cannot be changed later, so it is important to plan it correctly from the beginning. On the disk reserved for the Site, we will create a folder called Microsoft Configuration Manager and use it as the installation path. Make sure the option to install the Configuration Manager Console is also selected before continuing.
On the next page, Setup asks whether the Primary Site will be installed as a stand-alone site or joined to an existing hierarchy. Since this is a fresh environment, we will install the Primary Site as a stand-alone site.
On the Database Information page, we need to point Configuration Manager to our SQL Server. Enter the SQL Server FQDN in the SQL Server name field. Because we are using the Default Instance, leave the Instance name field empty. For the database name, Setup automatically adds CM_ in front of the Site Code, and we will use that automatically assigned name.
At the bottom, we can also see TCP port 4022 for SQL Server Service Broker. This port is used for database replication between sites in a Configuration Manager hierarchy. Since we are installing a stand-alone Primary Site, we do not have this type of communication right now, so we can leave the default value and continue.
On the next Database Information page, we can see that Setup can connect to SQL Server over TCP 1433 and can correctly read the Data and Log paths. This also gives us a useful connectivity check. We do not need to change anything here.
The SMS Provider is the WMI layer that allows the Configuration Manager Console to access information in the Site Database. By default, it is installed on the Site Server. In our design, we do not need to distribute it to a separate server, so we can continue with the default setting.
Enhanced HTTP, Management Point and Distribution Point
On the Client Computer Communication Settings page, we define how clients communicate with our Site System roles. The option at the top forces client communication to HTTPS and is the most secure choice, but it requires the necessary PKI certificates to be ready on both the server and client side.
We are not going into PKI in this video, so we will continue with Configure the communication method on each site system role. We will also keep Clients will use HTTPS when they have a valid PKI certificate and HTTPS-enabled site roles are available selected. In current Configuration Manager, this choice configures the site for Enhanced HTTP. Enhanced HTTP uses Configuration Manager-generated certificates and token mechanisms to secure specific client communications. It provides a more secure design than classic HTTP without requiring a full PKI deployment, but it is not as comprehensive as PKI-based HTTPS. We will cover PKI and HTTPS separately in later videos.
On the Site System Roles page, we configure the Management Point and Distribution Point. The Management Point is one of the main communication points where clients receive information such as policy and content location. The Distribution Point provides applications, packages, and similar content to clients. Because we are using a simpler design, we will keep both roles on the Site Server, but they can be distributed to different servers later if needed. Since we configured client communication as Enhanced HTTP on the previous page, we will keep Client Connection set to EHTTP.
We can continue through the Diagnostic and Usage Data page. The Service Connection Point is the role that connects Configuration Manager to Microsoft services. Through this connection, product updates and new features can be received from the console. Our server has internet access, so we will use the online option, Yes, let’s get connected.
On the Settings Summary page, we can quickly review the configuration. Everything looks correct, so we can continue.
Configuration Manager Prerequisite Check and Installation
At this stage, Setup checks whether the Configuration Manager prerequisites are met. In our environment, we have three warnings, so let’s review them one by one.
The first warning is related to Software Update Point and WSUS. We are not installing or configuring patch management in this video. We will cover that in a later episode, and the Software Update Point can be configured after the site installation, so we can continue for now.
The second warning is related to SQL Server Native Client. We intentionally did not install SQL Server Native Client before starting Setup. Configuration Manager 2509 Setup can install this package during the site installation, so we chose to let Setup handle it. We will verify it after the installation and address anything missing if necessary.
The third warning is related to SQL Server Security Mode and recommends Windows Authentication for the Configuration Manager setup. I remember configuring it that way, but let’s verify it. Open SQL Server Management Studio, connect to the server, open Properties, and go to Security. Windows Authentication mode is selected, so our configuration is correct. We can continue with the installation.
Click Begin Install. The installation takes some time, so I will fast-forward this part and continue when it is complete.
Post-Installation Site, Roles and Active Directory Publishing Validation
The installation completed after about half an hour. Before checking the rest of the environment, I want to verify whether SQL Server Native Client was installed. It is present, so that dependency was also installed as part of Setup.
Now let’s check the setup log. We can see some messages related to errors while deleting files, but there does not appear to be a critical installation problem in what we are reviewing here. Next, let’s open the Configuration Manager Console.
The console opens and can connect to the Site Database. Now let’s check the site system roles. Go to Administration > Site Configuration > Servers and Site System Roles. Under SRV-CM-01, we can see the Distribution Point, Management Point, and Service Connection Point roles that were created during Setup.
Let’s also verify the Active Directory Publishing configuration we prepared earlier. Under Administration > Site Configuration > Sites, open Site Properties and go to the Publishing tab. Our forest is already selected, so there is nothing else we need to change here. This confirms that the site is configured to publish to that Active Directory forest.
Removing Temporary SQL Server Setup Permissions
One last point is worth mentioning. Before Setup, we added both the Configuration Manager Site Server computer account and the Setup user account to the Local Administrators group on the SQL Server, and we gave both accounts sysadmin permissions in SQL Server.
We do not change the permissions assigned to the Site Server computer account because Configuration Manager still needs them during normal operation. However, if the user account we used for Setup was only used for the installation and no longer needs this level of access to SQL Server, we can remove it from the Local Administrators group and remove its sysadmin permission. This way, we do not leave unnecessary elevated permissions on the account.
And with that, we have reached the end of another video. Thanks for watching. See you in the next video. Take care. Bye.
