Configuration Manager 2012 R2 Deployment Notes


I want to share with you my experience in deploying System Center Configuration Manager 2012 R2 in a live environment and on Windows 2012 R2.

My setup will consist of three servers:

  • SCCM_Site : Site server, management point, distribution point
  • SCCM_WSUS : SUP and WSUS server

Microsoft recommends simplifying the SCCM hierarchy, and if possible, sticking to one site when possible. I like this idea of consolidating the complex hierarchies we used to have in previous versions of SCCM, to one big SCCM site. After all, simplicity is the key of success in my opinion.
Microsoft and many MVPs recommend to consolidate the SQL with the site server. I was in TechEd 2014 when I shared my design of separating the SQL instance in backend cluster configuration for better performance, and everyone there recommend having the SQL and SCCM site server in same box when possible. I am considering this in my new design.
I am separating WSUS to different server along with the SUP, just because WSUS is a different product and from a governance perspective, I decided to locate it in different server. Also, I love to have WSUS using pots 80 and 443 and by separating it in a different box, no conflict with the IIS roles required by SCCM.



The following users:

  • SCCM_Network: used as a network access account in SCCM. This account is used as the security context to access content in distribution in case the client cannot authenticate using its computer account (in case of workgroup scenario for example).
  • SCCM_Site: used to install other SCCM server roles from the SCCM console.


Create the following groups

  • ALL SCCM Servers: contains the SCCM three servers
  • ALL SCCM Admins: contains:
    • ALL SCCM Servers
    • SCCM_Network
    • SCCM_Site
    • Your admin accounts


I have also downloaded the following software:

System Management Container:

If you extended the schema and want to publish SCCM data into active directory, do not forget to create the System Management container in AD with ALL SCCM Servers configured with full access in that folder and child folders.

Site Server Setup

I will be preparing a Windows 2012 R2 server with 16 GB RAM (12 GB RAM for SQL, and the rest for SCCM), and the following drives:

  • F Drive: for database files.
  • G Drive: for database logs.
  • H Drive: for database temp files.
  • I Drive: for SCCM files.
  • J Drive: for SCCM Content Library files.

I have also placed a file (no_sms_on_drive.sms) on the C, F, G, H and J drives to prevent SCCM setup from throwing files there.
In case that you have a firewall enabled on the server, just allow everything for now inbound and outbound for now.
After patching the server with all windows updates, I configured a group policy to configure the administrator group in all three servers to be “ALL SCCM Admins”.
One of my worst tasks in SCCM deployment is the software prerequisites as there is so much to do. To install the software prerequisites, I checked the TechNet Documentation and personally I use this GUI tool to check if all my prerequisites are fine.

Next, is the folder structure for the J drive. I used this blog site to build my folder structure on the J drive as it shows a nice and well-designed folder structure along with share configuration and NTFS permissions.

Here is a script I wrote that will create the folder structure on the J drive. You can change the $ScriptFilesPath variable on the script to choose the drive of your choice.

$ScriptFilesPath = "J:\"

$Source_Directory1 = Join-Path $ScriptFilesPath "Source"
$Source_Directory2 = Join-Path $ScriptFilesPath "Source\Captures"
$Source_Directory3 = Join-Path $ScriptFilesPath "Source\Client"
$Source_Directory4 = Join-Path $ScriptFilesPath "Source\Content"

$Source_Directory5 = Join-Path $ScriptFilesPath "Source\Content\OSD"
$Source_Directory6 = Join-Path $ScriptFilesPath "Source\Content\OSD\BootImages"
$Source_Directory7 = Join-Path $ScriptFilesPath "Source\Content\OSD\Drivers"
$Source_Directory8 = Join-Path $ScriptFilesPath "Source\Content\OSD\MDTSettings"
$Source_Directory9 = Join-Path $ScriptFilesPath "Source\Content\OSD\MDTToolKits"
$Source_Directory10 = Join-Path $ScriptFilesPath "Source\Content\OSD\OSImages"
$Source_Directory11 = Join-Path $ScriptFilesPath "Source\Content\OSD\Source"

$Source_Directory12 = Join-Path $ScriptFilesPath "Source\Content\Software Deployment"
$Source_Directory13 = Join-Path $ScriptFilesPath "Source\Content\Software Updates"

$Source_Directory14 = Join-Path $ScriptFilesPath "Source\Import"
$Source_Directory15 = Join-Path $ScriptFilesPath "Source\Baselines"
$Source_Directory16 = Join-Path $ScriptFilesPath "Source\Drivers"

$Source_Directory17 = Join-Path $ScriptFilesPath "Source\InstallationUpdates"
$Source_Directory18 = Join-Path $ScriptFilesPath "Source\MDTLogs"
$Source_Directory19 = Join-Path $ScriptFilesPath "Source\Scripts"

$Source_Directory20 = Join-Path $ScriptFilesPath "Source\StateMigration"

$Source_Directory21 = Join-Path $ScriptFilesPath "Source\Tools"
$Source_Directory22 = Join-Path $ScriptFilesPath "Source\Error Logs"

if(Test-Path $Source_Directory1 ) {
 throw " Directory Exists $Source_Directory "
 if(!(Test-Path $Source_Directory1 )) {
 New-Item -ItemType directory -Path $Source_Directory1
 New-Item -ItemType directory -Path $Source_Directory2
 New-Item -ItemType directory -Path $Source_Directory3
 New-Item -ItemType directory -Path $Source_Directory4
 New-Item -ItemType directory -Path $Source_Directory5
 New-Item -ItemType directory -Path $Source_Directory6
 New-Item -ItemType directory -Path $Source_Directory7
 New-Item -ItemType directory -Path $Source_Directory8
 New-Item -ItemType directory -Path $Source_Directory9
 New-Item -ItemType directory -Path $Source_Directory10
 New-Item -ItemType directory -Path $Source_Directory11
 New-Item -ItemType directory -Path $Source_Directory12
 New-Item -ItemType directory -Path $Source_Directory13
 New-Item -ItemType directory -Path $Source_Directory14
 New-Item -ItemType directory -Path $Source_Directory15
 New-Item -ItemType directory -Path $Source_Directory16
 New-Item -ItemType directory -Path $Source_Directory17
 New-Item -ItemType directory -Path $Source_Directory18
 New-Item -ItemType directory -Path $Source_Directory19
 New-Item -ItemType directory -Path $Source_Directory20
 New-Item -ItemType directory -Path $Source_Directory21
 New-Item -ItemType directory -Path $Source_Directory22

 } # if(!(Test-Path $ScriptFilesPath ))

 Description for each folder along with share and NTFS permissions


Also, I have disabled UAC on the box as it may cause some trouble. Check out this post.

SUP Server Setup

One of the most confusing point for me was SUP and its integration with WSUS. So I will try to share my understanding here about how configuration manager can integrate with WSUS to distribute software updates.

With configuration manager 2012 and 2012 R2, Microsoft is pushing people to consolidate their complex SCCM hierarchy in previous version to a simpler one. Usually one site is enough for most environment, but again this depends.

Even you deploy one SCCM site in 2012 or 2012 R2, the recommendation is to consolidate the SQL with the SCCM site server. Usually having the SCCM Site server, MP and distribution point along with the SQL is a welcome thing in terms of keeping thing simpler.
When it comes to integrating WSUS with SCCM in that context, you have to add a role called Software Update Point (SUP), which is the interface that SCCM uses to control WSUS simply. Think of SUP as the API that SCCM uses to communicate with WSUS.
I see people installing WSUS and SUP in the same box as the SCCM site server itself. This means that you are installing WSUS using custom site and different ports. I do not like personally to use custom websites and ports other than 80 and 443 for HTTP and HTTPS, so I will be installing WSUS and SUP in different server. The below chart demonstrate my setup.

You can see that I have two servers, one that has the SCCM 2012 R2 site role, management point, distribution point and SQL, and another server that I will install WSUS and later SUP on it. This way, I can install WSUS on the default web site and maintaining the 80,443 bindings. I recommend to make the computer account of Server1 an administrator on Server2, because SCCM site server will use by default its computer account to install SUP on Server2. The other requirement is that you have to install only the WSUS console on Server1, so that the SCCM site server can administer the WSUS settings on server2.

On Server2, install WSUS services, and when the installation finish, do not (again DO NOT) configure the WSUS here. In fact, if you are prompted to start the WSUS configuration wizard, just close it. This is because SCCM site server (Server1) is the only one that should configure WSUS.

If you are running Windows 2012 R2 on server2, which I do in my setup, WSUS version 4 get installed. SCCM will always mention that WSUS 3.0 SP2 should be installed to support SUP. Just ignore this fact.

When you install WSUS on Server2, by default the WSUS will be configured with ports 8530 and 8530. I then will open IIS on Server2, and leave those bindings, and add another binding for http on port 80. The reason why you should not remove the default bindings on ports 8530 and 8531 is that SUP component that will be installed later on Server2, will try to validate the health of WSUS using those ports always. So the IIS site that hosts WSUS on Server2 will have bindings on 8530 (http), 8531(https) and 80(http).

I also just for making things perfect, I installed a certificate using my local PKI infrastructure for and bind it to the IIS site hosting WSUS on server2 using port 443. This is not a required step as we will not enable https on WSUS at least in this scenario.

Now, I will log on to Server1, and install SUP component on Server2 (make sure the computer account of Server1 is member of the local administrators group in Server2).

Then, go to the SCCM management console, Administration, Site Configuration, Sites and click Configure Site Components, Software Update Points, and configure the settings of WSUS.



Now go to the SCCM management console, Administration, Servers and Site System Roles, click on Server2, and down you can see the components installed on the server. Right click Software Update Point and choose Properties, and make sure 80 and 443 are there.


In the same place, right click the Site system components (while Server2 is chosen), and check the properties. Check the properties there.

5 comments on “Configuration Manager 2012 R2 Deployment Notes

  1. Pingback: Configuration Manager 2012 and WSUS/SUP – How Windows Updates Works | Ammar Hasayen - Blog

  2. Hi,
    I have a question. SCCM Server backend database is Microsoft SQL Server.
    Instead of SQL Server Can we use Big DATA (If it is a database). If I wrong leave.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s