Deploying System Center 2012 R2 Configuration Manager – Single Site Server Scenario – Part III – Configuration

Part III – Configuration

Configuring Configuration Manager 2012 R2

In Part I – Infrastructure I walked through my infrastructure needs for my ConfigMgr Deployment at a higher level.  We created our Active Directory security groups, services accounts, and users that we will need.  We installed WSUS and SQL on our primary site server.  We also downloaded all the software we will need to complete the installation of ConfigMgr in Part II.

In Part II – Installing Configuration Manager 2012 R2 I showed how to install and configure our prerequisites for ConfigMgr and then install Primary Site using a single site server scenario for my fictional company Turner & Sons Timer Travel.

I will go into some detail on the steps needed to finish configuring ConfigMgr to officially turn it over to my client for production use in this next blog.  I have now got a working ConfigMgr site server and console.  However, out of the box there is still plenty of work to be done before I can officially hand it over to the IT staff at my client.  This next phase of deploying a configuration manager infrastructure can take some time and will also need a lot of planning between myself and the team at Turner & Sons Time Travel. Depending on what site server roles we will decide to deploy and what features our client will want to use, will play a big part in how we will go about our planning phase.  This will also dictate how long until we are ready to go into production and start managing the many devices at Turner & Sons.  In this next blog I will go into configurations of the most commonly used site roles, how to get the best performance out of their system, and a few other areas that may not be mentioned below:

  • Configure Discovery Options
  • Boundary and Boundary Groups
  • Setup Collections for Computers and Users
  • Setup folder structure within the Source folder
  • Install Site Roles and Configure Site Roles
    • Software Update Point
    • Reporting Service Point
    • State Migration Point
    • Application Catalog roles
    • Asset Intelligence
    • Endpoint Protection
  • Configure Distribution Points
  • Configure Site Components
    • Configure Management Point Component
    • Software Distribution Point Component
    • Software Update Component
  • Configure Hierarchy settings
  • Client Settings Configuration
  • Configuring Endpoint Protection
  • Installing our clients
  • Giving Console Admin Rights
  • Ready for Production
  • Install MDT 2013 (If necessary)

Configuration Planning and Design

Something that sometimes is over looked when various people are planning and designing an organizations ConfigMgr environment are Collections and the folder structure for source files, etc.  This can and will cause some organization issues if we don’t plan this out correctly a head of time with our client.  I will dig a little more into this a little later in this blog and show you how I will do this for my fictional client Turner and Sons and how I normally try and do it for my real clients.  For now, I will start with Active Directory Discovery Options and continue on to boundaries and boundary groups.

Active Directory Discovery Options

There are 6 discovery methods that we can configure within Configuration Manager. Active Directory Forest Discovery, Active Directory Group Discovery, Active Directory System Discovery, Active Directory User Discovery, Heartbeat Discovery, and Network Discovery are the 6 methods. I will go over each a little but will only be focusing on just a few in my lab.

First I would like to talk about considerations you need to plan for when running some of these discoveries.

Active Directory Discovery Considerations

If or when you use an Active Directory Discovery method make sure you run discovery at the site that has a fast network connection to your domain controllers. Run Active Directory System Discovery and Active Directory User Discovery before you run Active Directory Group Discovery. Only specify groups that you will use with your ConfigMgr environment when configuring Active Directory Group Discovery. Also, configure your discovery methods to have longer intervals between full discovery and more frequent delta discovery periods.

Data Discovery Records

Let’s talk about a Data Discovery Record (DDR’s) before we begin as well. These are files that contain information about your device we can manage in ConfigMgr. These files contain information about computers and users. This files are created by the discovery method. The information about the device/resource is entered into the database and then the file is deleted. DDR files are about 1 kb in size.

The Active Directory Discovery Methods

This again is just a high level of the discovery methods available and how to configure them to start discovery devices and users (resources) within your organization.

Discovery Method Information
Active Directory Forest Discovery · Can discover Active Directory sites and subnets, and then create Configuration Manager Boundaries for each site and subnet from the forests that you have configured for discovery. When Active Directory Forest Discovery identifies a subnet that is assigned to an Active Directory site, Configuration Manager converts the subnet into an IP address range boundary.· Supports a user-defined account to discover resources for each forest.· Can publish to the Active Directory Domain Services of a forest when publishing to that forest is enabled, and the specified account has permissions to that forest.
Active Directory System Discovery · Discovers computers from the specified locations in Active Directory Domain Services.
Active Directory User Discovery · Discovers user accounts from the specified locations in Active Directory Domain Services.
Active Directory Group Discovery • Discovers local, global, and universal security groups, the membership within these groups, and the membership within distribution groups from the specified locations in Active directory Domain Services. Distribution groups are not discovered as group resources.
Heartbeat Discovery · Used by active Configuration Manager Clients to update their discovery records in the database.· Heartbeat Discovery can force discovery of a computer as a new resource record, or can repopulate the database record of a computer that was deleted from the database.
Network Discovery · Searches your network infrastructure for network devices that have an IP address.· Can discover devices that might not be found by other discovery methods. This includes printers, routers, and bridges.

Configuring Discovery Options

In this environment I will configure Forest Discovery, System Discovery, User Discovery, Group Discovery, and Heartbeat Discovery. On all but Heartbeat Discovery I will keep the default schedules once I enable them.

Active Directory Forest Discovery

On my Active Directory Forest Discovery I will also allow it to create boundaries based off of Active Directory Sites. Since we have already did a good infrastructure readiness discovery at this client I know the sites are configured correctly. If you are going to do this in a production environment make sure that all your AD Sites are configured correctly. This is very important and if they are not and you are creating boundary groups based off of AD sites you can run into some headaches with client management in the future.

Active Directory Systems Discovery

The next discovery I will configure and enable is the Active Directory Systems Discovery. I will pretty much leave the default settings for this discovery when it comes to the polling tab. 7 days for full and every 5 minutes for a delta discovery. For those that are planning your production environment I would also suggest under the options tab to select the feature to only discover computers that have logged onto the domain in the last 90 days. You shouldn’t need this if your Active Directory administrator keeps Active Directory current. Also, at this point you can configure additional active directory attributes for the computers you want to discover.  For this environment I will discovery everything in entire domain based off of conversations we have had with the client. If you are deploying a production environment you should think about what Active Directory OU’s you are going to have this discovery look in.

Active Directory User Discovery

I will then enable and configure Active Directory User Discovery with the default schedule of 7 days for a full and every 5 minutes for a delta discovery. Also just like Systems Discovery with User Discovery you can discover custom attributes from Active Directory. As with System discovery you can specify which OU this discovery will look in. The client we are working with has given us a go ahead to look into a root OU they created that contains nested OU’s with various users and groups.  I will configure the User Discovery to just look into this User OU. I don’t really want service accounts or built in accounts to be imported into ConfigMgr.

Active Directory Group Discovery

Active Directory Group Discovery is the next discovery I will configure.  I will keep the default polling schedule. On the General tab I will add by Location and select User Groups OU that my client has asked me to include. You will want to add all your OU’s that may have users groups for example HR Groups, IT Groups, etc.

Heartbeat Discovery

The last discovery method I will configure is the only one that is enabled by default. The Heartbeat discovery method checks if a client is alive or not and will also report the status as well. I have always changed the default polling schedule to every 1 day from the default 7.

Network Discovery

I do not ever configure the Network Discovery and really don’t see a need for that discovery. At least for the clients I have deployed and work with. Yes, I know there is a reason for this discovery but have never needed to configure it as of yet.

By now my discoveries have all been configured.  Based off the settings we have set and since I did allow it to do a full discovery which I didn’t mention above we should have users and computer resources in the console now. However since I have not configured Client Push or any other type of client installation method none of those resources will have a client installed. Before we start pushing clients or installing clients we will need to setup and configure our Boundaries and Boundary groups.

Boundaries and Boundary Groups

Quick discussion about boundary groups and boundaries. So, I can tell you the technical description or I can give you my crazy description. Imagine a chicken farm or pig farm. Your pigs and chickens are the devices we will be managing. However, when it comes to feeding time you want them organized in their own pens or coups, correct? So, think of it this way, a boundary is like a chicken coup or a pig pen that keeps specific chickens and pigs within. A boundary group would be the farm that those pens and coups are on. This way when you want to send chicken feed (application or software update) to your chickens that feed is sent to the correct group of chickens and vice versa for the pigs. Can you tell I grew up on a ranch?

Ok, so enough farm talk and on to talking about what boundaries and boundary groups are for and why they are very important. According to the official TechNet description Boundaries represent network locations on the intranet where ConfigMgr clients are located. Boundary groups are logic groups of boundaries that can provide clients access to resources such as Distribution Points, etc.

In my deployments I normally configure boundaries based off of Active Directory Sites as long as Active Directory has been configured correctly and is being managed correctly. You will hear discussion that it isn’t good to use AD sites for boundaries that IP Subnets and IP ranges are a better way to go. I would say yes in some cases but no in others. However for this client I am using Active Directory Sites for my boundaries. A boundary group would then contain various boundaries based off of location, etc. For example, you have a corporate office that has various AD sites workstations, a VPN site, a few more Server AD sites, etc. You would have a separate boundary created for each of those AD sites for your workstations, your VPN AD Site, and your Server AD sites. You would then create boundary groups based off locations of those boundaries in most cases. So Workstation Site A and B would then be in a boundary called Headquarters Workstations, etc. These are basic examples and depending on your infrastructure they will all be different.

For more information on how to create boundaries and boundary groups the following TechNet article goes into more detail.

For this environment they only have a few AD Sites and I have already ran an Active Directory Forest Discovery with it configured to create boundaries based off of AD sites automatically.  I already have a few boundaries setup at this point. I will then create a boundary group called PHX Corp  Boundary Group and add the boundaries that was auto created to this new group.  Since all these sites are based out of one physical location I will only need a single boundary group.   In more complex environments you may have hundreds of boundary groups that you will need to create and manage.

On my boundary group properties under the Reference tab I will select the box “Use this boundary group for site assignment.” I will also verify that the Assigned site is my PHX site we created early when we installed our primary site server. This is where I will also assign my site server to this boundary group by adding it to the section Site System Servers. You will only need to add distribution points and state migration points to this field. Management Points are not contained by boundaries.

So, now we have our boundaries setup and our boundary group setup. In a more complex organization you will need to make sure you have taken time to design and create your boundaries and boundary groups correctly. If not setup correctly clients will not be able to properly get content from distribution groups and state migration points and will be the cause of a majority of your headaches.

Setup Collections for Computers and Users

Do you have those admins that constantly go into a file server and randomly create folders and place various files in various locations? This soon becomes a big unorganized mess. Well, this can happen with your collections if you don’t plan out ahead of time and create naming conventions for your collections. I can’t really tell you how to manage your collections because each environment is always different but I can show you and suggest to you how I usually start a client off.

I normally start off by created 6 folders under Device Collections:

Software Updates
Software Deployments
Operating System Deployments

Software Updates Collections

These folder names should be self-explanatory but I will explain myself. Under Software Updates folder I will create and organize all my software update collections. These collections names usually are based off the Software Update Groups and Distributions that are created in your planning for software updates. I will create a blog in the future with more details on what I suggest is a good Software Update planning policy and procedures. For example I will have created a Software Update Group called SU_Windows_Servers_2013. Which will list all my approved software updates for all my Windows servers for the year of 2013. That in turn will have a default deployment named SU_Windows_Servers_2013 that would be deployed to a collection that we will have created. In my lab environment I would start out by creating the following collections in this folder.

SU_Windows _Servers

In a more advanced production environment I would make sure we had a few different phases that we could deploy updates to one phase at a time. So you might add something like SU_Windows_Servers_Phase_I or something like that. These collections would be mixed between direct memberships and include Collection memberships.

Software Deployment Collections

Next is our Software Deployment folder which will have all our computer collections that will be created based off the application or package name we are deploying? For instance for my Microsoft Office 2013 Professional Plus Application I will have a computer and user collection based off the same name like Microsoft Office 2013 Professional Plus – Computer and one for my User collection but with a – User after. I always create a computer collection and a user collection at the same time for each application/package we plan to deploy or place in our company store.

Computer Devices Collections:

User Device Collections:


Inventory Collections

Inventory is my next folder. This folder holds special collections mostly based off of queries. For instance, I always create the following collections with query based memberships:

All Windows Server 2003 Devices (yes I know but there are a lot of clients that still run Windows 2003)
All Windows Server 2003 R2 Devices
All Windows Server 2008 Devices
All Windows Server 2008 R2 Devices
All Windows Server 2012 Devices
All Windows Server 2012 R2 Devices

All Windows Servers (This has a membership of Include Collection and I add all the server collections)

All Windows XP Devices
All Windows XP x64 Devices
All Windows 7 Devices
All Windows 8 Devices
All Windows 8.1 Devices

All Windows Workstations (This has a membership of Include Collection and I add all the workstation collections)

I also will create Inventory related collections based off of installed applications like Endpoint Protection, Exchange Servers, SQL Servers, etc.

Configuration Collections

My Configuration folder always contains collections that will have configurations assigned to them like Power Settings, maintenance plans, Firewall and Endpoint protection settings, and Client Configuration Settings. For example the following collections would be:

Endpoint Protection – Domain Controllers
Endpoint Protection – SQL Servers
Endpoint Protection – File Servers
Endpoint Protection – Exchange Servers
Endpoint Protection – Workstations

Power Settings – Workstations

Maintenance Plan – Servers
Maintenance Plan – Workstations

Client Settings – Servers
Client Settings – Workstations

The maintenance and power setting plans are default collections I create. I suggest that you create more collections if possible based on needs and your environment.

Operating System Deployment Collections

Operating System Deployment Folder helps me organize my OSD deployments. Here is where we will organize our collections that we deploy our OSD task sequences to. By habit I will always create the following:

Build and Capture
Build Resource
Build Core Image
Test and Development
Production Image Collection

Compliance Collections

Last folder I create is my Compliance Folder. The compliance feature in ConfigMgr is pretty cool yet very rarely used. I don’t create any default collections in this folder until we have had time to discuss compliance goals with my client. For an example we could always create a collection for all non-complaint machines not running your version of Office 2013 or maybe an application you do not want installed on your desktops like Firefox?

Now, all the collections I have shown you have been computer collections. Being from the old school days of SMS and ConfigMgr 2007 I still lean heavily on computer based collections. Yes, I know that ConfigMgr 2012 R2 is based off of being user centric. That is why I will also create folders under the Users Collection as well. The only folder that I create right out of the box for the User Collection is Software Deployment. Just like the Computer Devices I will use this folder to organize all Software Deployments to users.

Now as I said these are my starter Collections that will always be added to or removed. There is an ongoing discussion in the ConfigMgr would that few collections are better or you can be on the side I lean and still use more collections for organization. For more details on how to create the collections you can visit the TechNet link below.

Setup folder structure within the Source folder

Folder structure is a pet peeve of mine. It is hard to walk into a client and see that they have application files spread across many drives and servers, drivers and image files here and there, etc. I prefer having all my ConfigMgr files located in one location for easy management. There are several ways we can do this. I will show you here how I have recently started to create a client’s folder structure. Normally I will start by creating a folder called Source. This will be our root folder for all our other ConfigMgr related folders and files. As you go along with your ConfigMgr infrastructure you will soon see why starting organized is a lot better than trying to become organized.

DFS Share

On a side note, I have started creating a DFS share that points to this folder we will be creating. Why? Well, with all your applications, packages, drivers, etc. they all have a source content location that points back to some place either on one of the folders we are creating or on another server location. If you ConfigMgr server where to die and or you upgraded to another server with a different name all your packages, applications, etc. will be pointing to the \\servername location. Which will in turn cause you grief trying to fix each package/application/etc. Just create a simple DFS namespace called \\domain\ConfigMgr or Source that points to your files. All your applications/packages/etc. will then have that path and then in turn be easier to restore if a critical crash occurs.

ConfigMgr Folder Structure Example

So, here is a look at how I setup my ConfigMgr folder structure for my source files like drivers and software applications, etc.  Throughout time I have changed the way I have created my folder structures based off of a few things, however I would like to give Jason Sandy a ConfigMgr MVP some credit for the way I am currently building out client folder structures.

I have created the E drive with enough space to grow. So for my current client Turner & Sons Time Travel, they have a 300 GB volume.  The ConfigMgr Content Library has been installed on this drive as well as our source folder location.   Remember, your software updates, drivers, images, and application files will start to consume more and more space. Plan out ahead of time.  Here is a table that will show the folders I create and some permissions that are assigned.  For my current fictional client I have created on the E drive a Source Directory that will be setup as a hidden share.



.\Source This folder is shared but usually is hidden. Just another way to keep roaming eyes out of your folders since I always give “Everyone” full permissions on the Share level that is why we hide this share. I will also assign the following NTFS permissions. Local Admins (Full), System (Full), Domain Computers (read), ConfigMgr Admins (Full), <Capture User> (Read), <Network Access Account> (Read) and Help Desk (Read).
.\Source\Captures This is for all the image capturing activities. NTFS permissions will be set at <Capture User><Network Access Account> (Full)
.\Source\Client I copy the client folder from the ConfigMgr installation directory. I also add a hotfix folder and add all client hotfixes here as well.
.\Source\Content All source files will be located here
This is the OSD root folder.
.\Source\Applications Application deployment.  Create a sub-folder for each vendor, then a subfolder for each product, then a subfolder for each version.
.\Source\SoftwareUpdates Software Updates.  One sub-folder for each update grouping.
.\Source\ErrorLogs Start up script error logs





Location to import content from.


DCM/Settings Management.  Created externally.

Driver Import location


.\Source\InstallationUpdates Location for updates downloaded during initial installation and service pack upgrades.
.\Source\MDTLogs MDT Log Files
.\Source\Scripts Script Repository
.\Source\StateMigration State Migration Data. Permissions automatically controlled by ConfigMgr
.\Source\Tools Tools like CMTrace, etc that people will want to use.





Install Site Roles and Configuring Site Roles

  • Software Update Point
  • Reporting Service Point
  • State Migration Point
  • Application Catalog roles
  • Asset Intelligence
  • Endpoint Protection

I am at a point where I will be installing the Site server roles that I had mentioned earlier. I will also configure some of the components that had been installed as part of the ConfigMgr installation.  The roles I will be working with are what I consider the most common features that most organizations use. Here is a quick high level way to install any site system role on both existing site servers and to install to a new site server.

  1. In the Configuration Manager console, click Administration.
  2. In the Administration workspace, expand Site Configuration, click Servers and Site System Roles, and then select the server that you want to use for the new site system roles.
  3. On the Home tab, in the Server group, click Add Site System Roles.
  4. On the General page, review the settings, and then click Next
  5. For System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager only:
    On the Proxy page, specify settings for a proxy server if site system roles that run on this site system server require a proxy server to connect to locations on the Internet, and then click Next.
  6. On the System Role Selection page, select the site system roles that you want to add, and then click “Next”.
  7. Complete the wizard

If you are installing to a new Site Server then you would follow these high level instructions:

  1. In the Configuration Manager console, click Administration.
  2. In the Administration workspace, expand Site Configuration, and click Servers and Site System Roles.
  3. On the Home tab, in the Create group, click Create Site System Server.
  4. On the General page, specify the general settings for the site system, and then click Next.
  5. For System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager only:
    On the Proxy page, specify settings for a proxy server if site system roles that run on this site system server require a proxy server to connect to locations on the Internet, and then click Next.
  6. On the System Role Selection page, select the site system roles that you want to add, and then click Next.
  7. Complete the wizard.


Since we are installing all these roles on a single site server you can install them at the same time.  I will select the following roles and install them at the same time since all of these roles will be installed on the same site server; Software Update Point, State Migration Point, Asset Intelligence Point, Reporting Service Point Role, Application Catalog website points and the Application Catalog Web Service Point, and Endpoint Protection Point.

Software Update Point Role

I always use ports 8530 and 8531 for client communication. Leave everything else default on that window and click next. The next window I will also click next since we will use the Computer Account for permissions. We will keep the default Sync Source of Microsoft. On the sync schedule I will do a sync every night. Yes, a majority of updates come out on patch Tuesday but I would like to catch any revisions. I also will alert when it fails to sync. I also select the option to immediately supersede any expired software updates. On the next few windows I will leave the default classifications remove products. I also will remove all languages except for English. Once we have a successful sync I will go back to this component and start selecting our products. Click the rest of the way through and monitor the installation of this component.  This is also another area to discuss with your security and server teams on which classifications and products they want to see in the catalog.

Next, I am going to select the following roles and install them at the same time since all of these roles will be installed on the same site server, State Migration Point, Asset Intelligence Point, and Endpoint Protection Point.

State Migration Point (SMP)

The installation wizard is asking me is for the State Migration Point (SMP). This role will need a local folder that we will designate for the User Data. Earlier we created this folder E:\Source\StateMigration. We will then specify how long the User Data is kept for, which I normally keep for 7 days, as well as how much space is reserved for this SMP. I normally will reserve a minimum of 10 GB. You will need to specify a boundary group for this SMP. Since we have a small lab it is pretty easy. I have selected the only boundary group we created earlier. This is where boundary groups will start becoming very important. We don’t want our clients at site A to use a SMP at a remote location. We want them to use the SMP at site A. By default the correct boundary group should be listed. If not, we most likely have AD Site issues.

Asset Intelligence Point

The Asset Intelligence Point is pretty basic. Unless you are required to use a certificate you can accept default settings for both windows.

Endpoint Protection Point

The Endpoint Protection Point will need you to accept a Microsoft License agreement. Click the box and click “Next”. On the MAPS window since this is my lab environment I will always send data to Microsoft. In a production environment please make sure your organizations policies allow you to send data to Microsoft.

Click through the summary pages and install your site server roles. You can monitor the installation using the Monitoring Workspace. Click System status, then select Status Message Queries and open the query “All Status Messages.” This will give you some status messages that will show if the component installed or failed. If you want you can dig deeper by viewer the actually log files using CMTrace. I prefer the log files since it will give you more details.

Reporting Service Point Role

Here we will need to specify the Site Database server which is The database name should default to you existing ConfigMgr database. Click Verify to make sure that the information is correct. On the same window leave the Fold Name default. In the Reporting Services server instance select in our server.

Application Catalog Roles

Next we will configure the Application Catalog website points and the Application Catalog Web Service Point. I am going to keep the defaults on most of these settings, ISS Website and Web Application name I will keep default. The port as well, we will keep the default port 80. On the next windows I will just leave the defaults as well. The next window allows you to pick a website theme which is basically just a color and then an Organization Name that will appear on the app store. Click next all the way through and monitor the installation of these new components.

Configuring Distribution Points

Now that we have installed all the site roles there are still some configuration to be done. We need to go back to the Software Update role and configure which product and the type of updates we will want to include in our searches. We also need to go configure our distribution point to handle PXE request. Also, we would like to know if our management point is healthy or not. There are some client and hierarchy configurations we will verify are set as well.

I will now go to the distribution point since I only have one and it should be fairly easy to configure.

  1. Click Administration work space
  2. Expand Site Configuration
  3. Select Servers and Site System Roles
  4. On the right I will select my primary site server since this is where my DP has been installed
  5. The window below will list all my site roles installed on this server.
  6. Right click and select properties on the Distribution Point Role.
  7. Click the PXE tab.
    1. I will enable PXE support for clients here even through it is in an Azure network.
    2. Select “Allow this distribution point to respond to incoming PXE Request.”
    3. Select “Enable unknown computer support” Hit OK when the information window pops up.
    4. Type in a password. I don’t suggest ever unchecking this option in a production environment or even a lab environment.
    5. I normally change User Device affinity to “Allow user device affinity with automatic approval.” This is a feature that I won’t go into on this blog but is very nice if configured correctly for many purposes.
  8. Under the Multicast tab I don’t usually enable this feature. This is something for you and your network team to hash out.
  9. Under Group Relationships, we haven’t created any Distribution Groups at this time.
  10. The content tab probably at this time only has one item and that is most likely the Client Install files.
  11. Content Validation I will enabled at a lowest priority and on the default schedule.
  12. Verify on the Boundary Groups tab that your current boundary group is listed.
  13. Click OK and you are done configuring the DP role.

Configuring Components

I will finish up by configuring the rest of my components including my Software Distribution Point and my Software Update Point component. The following is a list of the components that we can configure:

  • System Health Validator Point
  • Software Distribution
  • Software Update Point
  • Management Point
  • Status Reporting
  • Out of Band Management
  • Email Notification
  • Collection Evaluation

For this client we will not be configuring the Email Notification. However, you can go into this component and configure it pretty easy to send alerts. The Collection Membership Evaluation and Status Reporting Components I will also leave default. These components just let you get a little more granular on how often your collections are evaluated and what detail level and importance certain status messages are. These are two areas that can help with performance on larger deployments. We are not using Out of Band Management, if you’re interested in that have fun. :) System Health I will leave as default as well. The only two that I will go into detail here are Software Distribution and Software Update Point components.

  1. Click the Administration Workspace
  2. Expand Site Configuration
  3. Select Sites
  4. Right click again on our Primary Site Server and select Configure Site Components
Configuring Management Point Component

I will configure our Management Point. For this we will only need to change one item and that is the alerting on an unhealthy management point. Not sure why this isn’t set for default since it is a very important piece for client communications but hey, we all never truly understand the Microsoft thinking process?

I will now go to our management point since I only have one and it should be fairly easy to configure.

  1. Click Administration work space
  2. Expand Site Configuration
  3. Select Servers and Site System Roles
  4. On the right I will select my primary site server since this is where my Management Point has been installed
  5. The window below will list all my site roles installed on this server.
  6. Right click and select properties on the Management Point Role.
    1. Under the General tab place a check mark in “Generate alert when the management point is not healthy.”
    2. Click OK
Software Distribution Point Component

I will go ahead and click on the Software Distribution Component properties. Here you can set a few settings such as how many packages can be distributed at one time and how many times it will retry if it fails. I am going to leave the default settings here for my lab on this tab. Next I will configure my Network Access Account.

The Network Access Account is used by ConfigMgr clients to access network locations during deployment or during operating system deployments. This is an account I have already created in Active Directory and have already given all the correct rights to the shares and directories it will need to access.

  1. Click on the Network Access Account Tab in your Software Distribution Component Properties window.
  2. Click the bullet “Specify the account that accesses the network locations.”
  3. Click the * to add an account.
    1. Since we have not yet added a Network Access Account you will need to select Add An Account.
    2. Hit Browse and look for the account created in Part I of this blog. I had created an account called svc.networkaccess.
    3. Type in the password for this account.
    4. Click Verify
    5. Select a network share that this account should have rights to.
    6. Select Test Connection
    7. Once it is successfully verifies the account Click OK
  4. Click OK again and we are done configuring the Software Distribution Component.
Software Update Component

I consider Software Update to be one of the most important parts of ConfigMgr. Yes, Software Deployment (Application Deployment), OSD, Compliance, etc. are pretty important as well. However, this is where I feel ConfigMgr shines over its competitors in this area. Don’t get me wrong, ConfigMgr is better for Image deployment, application deployment, etc. than all the products I have touched.

I have already installed the Site Role earlier in my blog. I also left pretty much the default settings for what classifications we will include and what products. During this section we will go over the settings we have already set and configure the classifications and products that we will need to provide and ensure all our endpoints are patched correctly. The Software Update how-to’s are an entire different blog but I will go over the basics once we have configured the component.

  1. Click the Administration Workspace
  2. Expand Site Configuration
  3. Select Sites
  4. Right click again on our Primary Site Server and select Configure Site Components
  5. Select Software Update Point
Sync Settings

The first tab is how we can configure our Sync settings with Microsoft. There are some very rare occasions that I have come across where we wouldn’t sync with Microsoft but an internal WSUS server that another department has control of. Normally in highly secure organizations or some branch of the government.


Here is the list of classifications we can set to include when we sync with Microsoft. I have linked a site that I have obtained a good explanation to what these classifications are. Remember, if you borrow please give the person credit. Yes, I have borrow here and there from TechNet but any personal or professional blog outside of TechNet I will always give credit to.

  • Critical updates:
    Broadly released fixes for specific problems addressing critical, non-security related bugs.
  • Definition Updates:
    Updates to anti-malware or other definition files.
  • Feature Packs:
    New product functionality usually included in the next full product release.
  • Security Updates:
    Broadly released fixes for specific products, addressing security issues.
  • Service Packs:
    Cumulative sets of all hotfixes, security updates, critical updates, and updates created since the release of the product. Service packs might also contain a limited number of customer-requested design changes or features.
  • Tools:
    Utilities or features that aid in accomplishing a task or set of tasks.
  • Update Rollups:
    Cumulative sets of hotfixes, security updates, critical updates, and updates packaged together for easy deployment. A rollup generally targets a specific area, such as security, or a specific component, such as Internet Information Services (IIS).
  • Updates:
    Broadly released fixes for specific problems addressing non-critical, non-security related bugs.

This is an area that you should seriously discuss with your security, desktop, and server teams. However, I will select all of them since I have already talked to my clients about what they wanted.

Note: The sync process doesn’t download the actually update but the catalog and Meta data of each available update.


Here is where we will select what products we want to sync. If you had noticed when I first installed this role that a majority of newer products where not listed. This is why I didn’t configure this section when I installed the role. I waited until we had a successful sync in order for the newest list to download. Here I will check all the products that we want updates for. This again is another area you need to discuss with your Security Team, Desktop Team, and Server Team.

Note: If you are going to be using Endpoint Protection make sure you have selected “Forefront Endpoint Protection 2010” updates.

Also, be aware for products that you may not think you have installed on your endpoints. For a good example is Microsoft Live products, Skype, and/or older versions of Lync or some application that may cause a security risk. I suggest you select a little more than not enough.

Sync Schedule

I had already set the Sync Schedule earlier but I will double check that it is still set to run every 1 days. This again is something you need to discuss if setting up a production environment. Make sure that this is also checked to alert you on sync errors.

Supersedence Rules

I allow it to expire superseded software updates. In your environment you may have a security team that wants to research an update first and you may have to manually supersede updates.


I have selected English for both Software Update File and Summary Details. If you are planning a larger deployment across different countries you may consider adding more languages for each update.

Once I am done configuring this component I normally force a sync again. Since the first sync can take some time.

In order to force a sync:

  1. Click on the Software Library Workspace in your ConfigMgr console.
  2. Expand the Software Updates folder.
  3. Right click All Software Updates and select Synchronize Software Updates

Primary Site Settings

Now I will just walk through the Primary Site settings to verify everything is configured the way I would like it to be.

  1. Click the Administration Workspace
  2. Expand Site Configuration
  3. Select Sites
  4. On the windows to the right click the primary site and select properties.

I will not change anything here . However some people will want to enable Wake On LAN, maybe change some of the default ports the clients communicate on, change AD publishing, etc. So I will just list a few things on any tab that may become important later as your deploy your environment.

The only tabs that may be of concern would be the Wake On LAN to enable that feature, Publishing to verify that you are publishing to all your AD forest and Domains, Ports if you need to change the port that clients communicate on, and Client Computer Communication which is where you would change it from HTTP to HTTPS and assign a Trusted Root Certificate Authority if you are going to use PKI client certificates


Configure Hierarchy Settings

Once last configuration of the site that I will look over. There are some important settings that can be changed in the Hierarchy settings for this site.

  1. Click the Administration Workspace
  2. Expand Site Configuration
  3. Select Sites
  4. Click On our Primary Site
  5. At the top along the Ribbon menu there is a Hierarchy Settings option.

Since this is a single site a fallback site isn’t necessary.  Select the Client Approval and Conflicting Records tab. I will leave the default settings here. The next tab is something that you should discuss with your team. In a production environment you should take in some considerations for automatically upgrading your clients.

Just take note, this client upgrade feature only will upgrade your clients if it is a major service pack or revision release. If you install a CU this will not upgrade your client to the currently patched CU level. This also doesn’t give you much control of which clients at which location go and in what order. It is basically an enable or disable with a time period. If you enable this feature the system will randomly schedule the clients over the period of time you have selected. In my clients environment I am going to enable it with a 7 day period. In past clients when I have enabled this we normally changed it to 14 days depending on the size and had no issues.

Client Settings Configurations

The client settings section is basically what it says. It is where we will configure pretty much every setting that will be assigned to the clients. There is a long list of settings that are available to configure but for now I will discuss only a few. For a good resource for breakdown of all the configuration settings included in Client Settings.

Client Settings for Devices

Client settings for users:

Create Custom Client Policy

Let’s create a custom client setting and assign it to our collection in our lab. This is also a good discussion issue. What settings are needed, what they will be deployed to. Normally in a production environment you would have settings for servers and settings for your clients. You would even break down these settings and possible create custom settings such as Endpoint Protection, Computer Restart policies, etc. For now I am going to create a custom client setting for all my servers and a custom client setting for all my workstations and then deploy them to the proper configuration collection that I previously created. Here is a quick step by step on creating a custom client setting and deploying it.

  1. Click the Administration Workspace
  2. Right click on Client Settings
  3. Select Create Custom Client Device Settings
  4. Name the Custom Device Setting and also please please please include a good description. I have created one called Client Settings – Workstations.
  5. For my custom client setting I have selected the following:
    1. Client Policy
    2. Compliance Settings
    3. Computer Agent
    4. Hardware Inventory
    5. Remote Tools
    6. Software Inventory
    7. Software Updates
    8. User and Device Affinity
  6. Click OK
Configure Custom Client Settings

We now have a custom client setting ready to be configured. Also, remember any setting that you don’t select will fall back to the Default Client Setting that is positioned at priority 1000. When the client is installed the default settings will be applied until it has had a chance to check in with the server and get it assigned settings.

Client Policy

Here is how the client computers retrieve policy. Normally I will leave these settings as default unless a client has issues with how often a client polls the management server. However, this is very little traffic.

Compliance Settings

Once again these settings can be set to default.

Computer Agent

These are general settings for communication between the client and the server. I would start by configuring the Default Application Catalog Website point. In my clients environment I have configured it to use the FQDN of the Application catalog which is  I also add the Application Catalog to the local trusted site zones. This is something you should discuss with your security team. I also elevate the trust mode for Silver light applications since the App store does run on Silverlight. You can also type in a name that will be displayed in the Software Center. There are more settings that you should take into consideration. For my lab I have the PowerShell execution polity to be set at Bypass. This may send up a red flag in your organization if you don’t talk to your teams first.

Hardware Inventory

This setting configures the hardware inventory settings on your client computers. Don’t let the name fool you because the hardware inventory also does software inventory which in turn is analyzed by Asset Intelligence. Software Inventory will inventory directly from files that you specify. It will collect file header information from those specified files. So in easy to understand terms, hardware inventory does what it is called and collects hardware information from the client like (CPU, RAM, Servicers, etc.) as well as WMI queries which in turn can include information from add/remove programs, etc.

I always leave hardware inventory enabled and default schedule. If you look at the setting you will also see a line called Hardware inventory classes with an option to Set Classes. In here you can add information from about a boat load of available WMI classes. Take some time and scroll through these. You might find that you want to know what battery is installed on a certain laptop. By default that WMI Object isn’t being reported on. One check and bingo you will now start seeing that in your hardware inventory results.

Remote Tools

This feature has returned with some added capabilities from the time between SMS 2003 and ConfigMgr 2007. Now you can configure the Remote tools policies per setting and not just the entire site. Which means you can have multiple Remote Tools polices deployed throughout your site depending on who need access to what systems.

Software Inventory

Once again like I mentioned in Hardware Inventory, Software Inventory inventories specific files that you specify. It can also collect a certain file type for you as well. This will not give you an accurate view of what is installed on your clients.

Software Updates

Normally I leave the default settings. I might bump up the deployment re-evaluation depending on the client. With R2 you can now allow Software Updates to deploy with priority over all other deployments once it has reached its deployment deadline.

User and Device Affinity.

This feature is nice. I won’t go into it much here but you really need to look into taking advantage of User and Device affinity. This is really good for advanced software deployments and more. I will change it to allow the system to automatically configure user’s devices from the stats it collects.

These are the basic client settings that I would focus on before deploying any agents. You should sit down and plan your client settings and how you want to deploy those settings to what group of clients.

Deploying Custom Client Settings

Now we need to deploy this custom setting to our collection we have created our configurations.

  1. Right click the Client Settings – Workstation custom setting and select Deploy.
  2. Navigate to the folder Configuration Settings that we created earlier. ON the left window you should see our Client Settings – Workstations collection. Select it and click OK.

Configuring Endpoint Protection

I will run through setting up Endpoint Protection on a higher level in this blog. You should really focus later on your Endpoint policies and make sure you have then setup to help protect your clients and servers. I have heard that Microsoft now recommends only installing anti-virus on specific server with certain roles installed. Anything your user’s endpoint will access like File Servers, etc.

You can get to your Endpoint Protection policies, better known as Antimalware Policies here:

  1. Click on the Assets and Compliance Workspace.
  2. Expand the Endpoint Protection Folder
  3. Select Antimalware Policies.

Once we have our Endpoint Protection role installed we will need to make sure we configure the client settings to enable or disable Endpoint Protection on our resources. There are many ways one can get to a final solution but I am going to give you mine. I had gone over earlier in my blog creating collections based off of configurations, inventory, etc. This is where one of those configuration collections will come into the picture. I will try to mimic how I would suggest a client to setup their Endpoint Client settings and collections. In my example here have already setup the Endpoint Protection – Workstations collection that has a membership rule to include all Windows Workstations. Since we want to make sure all our workstations (endpoints) have the client installed. In a production environment you may create more Endpoint Protection settings for specific reasons outside of your server policies of course.

Let’s create an Endpoint Protect setting and assign it to our collection in our lab.

  1. Click the Administration Workspace
  2. Right click on Client Settings
  3. Select Create Custom Client Device Settings
  4. I will name it Endpoint Protection – Workstations
  5. Type in a description. Please!!!!! Document what and why this setting is there!!!!!!
  6. Select Endpoint Protection
  7. Click OK.

Now that we have our Endpoint Protection custom setting created I will edit the setting to fix out needs.

  1. Right click the newly created Endpoint Protection Custom Setting
  2. On the left column click on Endpoint Protection.
  3. Under Custom Device settings in the left window we will find all the configurations that we can set for this policy. This doesn’t configure how the client will handle viruses and malware. That is in the Antimalware Policy section.
    1. Manage Endpoint Protection client on client computers. Change this to Yes. Now you will notice that more options are selectable and no longer greyed out.
    2. Install Endpoint Protection client on client computers. I will keep this at Yes.
    3. Automatically remove previous installed antimalware software. I will keep this at Yes. A quick note, this feature is pretty good and can uninstall a very long list of existing software out there currently.
    4. Allow Endpoint to restart. I always say No to any restart questions.
    5. Pretty much the rest of the options here are default. However, the last option is an interesting one and depending on your patch management policies as well as your bandwidth from your sites may or may not be important. I will normally suggest that you disable alternate sources for definition updates and only allow the clients to download from the closest distribution point. However there may be a need to allow clients to grab from Windows Update directly. There are more settings that can be set within the Malware policy that will tell the client after a certain amount of time when the definition on a client is old it can go out to another source.
  4. Click OK

Now we need to deploy this custom setting to our collection we have created for Endpoint configurations.

  1. Right click the Endpoint Protection custom setting and select Deploy.
  2. Navigate to the folder Configuration Settings that we created earlier. ON the left window you should see our Endpoint Protection – Workstations collection. Select it and click OK.

On a high level we now have the Endpoint Protection role installed, configured and deployed to our workstations. There is still a lot to do here if you plan to use this environment f or production. However, for our lab we are done except for creating a Server Custom setting and deploying that as well.

Install our clients

OK, so now we have a majority of the configuration settings completed for the roles that we have installed. We are now ready to talk about how we will install the client to our systems. There are different ways of getting the client installed to your systems. I will configured my lab to use the Client Push Installation to install a client to all discovered systems. This option sometimes isn’t always configured with clients I have worked with. There also is the install client from console option as well. I stay away from these first two as much as possible to avoid the over load of errors that will fill our logs file we will monitor. Don’t get me wrong, there are times when you will want to install the client from the console. Each client has been different and it always depends on how the other teams involved would like to see the client deployed. You can deploy the client via GPO and logon script as well. The two later are pretty much what a lot of clients have selected to use and some have enabled the automatic client push to install the rest. If there is an existing WSUS environment you can also install the client using the Software Update-based Client installation feature as well. I also can’t forget the good old fashion manual method of just running a script or typing out the command line.

I won’t go into the logon script or GPO installation methods in this blog. There are plenty of great resources out there that can help you create a logon script and a GPO. I will be honest, I use to not suggest GPO or logon scripts but after some time in the field I have found it is a pretty good way to get a high percentage of your machines installed.

Today in my blog I will cover how to configure the “Client Push Installation,” how to configure the “Software Update-Based Client Installation and how to install the client using the console.

Configuring the Client Push Installation Method
  1. Click the Administration Workspace
  2. Expand Site Configuration
  3. Select Sites
  4. Select our Primary Site
  5. On the menu ribbon click “Client Installation Settings”
  6. Select “Client Push Installation”
  7. Check “Enable automatic site-wide client installation.”
General Tab

On this tab is where we will enable the automatic site-wide push installation. There some decisions that should be made by your server teams here that may affect what options you select in a production environment. However, for my fictional client I am going to place a check mark for Servers, Workstations, and Configuration Manager Site systems servers. Also, I will select the bullet “Always install Configuration Manager Clients on domain controllers” since we have already talked to the client and confirmed this is what they would like. In a production environment I wouldn’t normally select this option. I would hand off the task to the server admins or AD admins depending on how large of an organization.


Here is where I will add my Client Push account I created earlier. Since I have not yet added a Client Push account to my ConfigMgr I will need to add a new account just like we did for the Network Access Account.

  1. Select the * and select add new account
  2. Browse and select the account created. I will be using svc.clientpush that has already been setup in Active Directory and already has been assigned the correct permissions on all my servers and workstations via a GPO.
  3. Verify the credentials work
  4. Click OK.
Installation Properties

Since Client Push settings are site specific under the Installation Properties tab you should already have SMSSITECODE=PHX listed. If not you can add it here. You do not need to add anything else to this list.

Software Update-based Client Installation method
  1. Click the Administration Workspace
  2. Expand Site Configuration
  3. Select Sites
  4. Select our Primary Site
  5. On the menu ribbon click “Client Installation Settings”
  6. Select “Software Update-Based Configuration Manager Client Install”
  7. Check “Enable Software update-based client installation.
  8. Click Ok

Once you have configured your installation methods you should shortly see in your Devices view your resources reporting the client installed. At this point your clients should be running a full Software and Hardware Inventory, running your Software Update evaluations, and checking if they have any Software Deployments deployed to them, etc. If you have configured Endpoint Protection and enabled the role you will also see the Endpoint client starting to pop up and your existing anti-virus software should be removed. Give your new client some time before assuming that something is not working. Check your log files and monitor what is really going on with your clients at this point.

Giving Console Rights

I won’t go to deep into Role Based Administration here on this blog but I do need to assign the ConfigMgr Admin Group to the proper group within ConfigMgr. If I don’t then the only user that has access to the console is currently my ConfigMgr Admin user account. I would suggest reading up on Role Based Administration which is pretty dang cool with ConfigMgr 2012 R2. For now I will walk you through adding our ConfigMgr Admins Security group.

  1. From the ConfigMgr Console click on the Administration Workspace.
  2. Expend the Security Folder
  3. Right click on Administrative Users and select add group
  4. Browse for your ConfigMgr Administrator Group
  5. Click the Add button
  6. Place a check in the Full Administrator in the Add Security Role Window.
  7. Click OK
  8. Under the “Assigned Security Scopes and collections” section make sure the bullet “All instances of the objects that are related to the assigned security roles” are selected.
  9. Click OK

Note: I would advise against adding any user directly to this ConfigMgr group. Use your AD group to manage who has admin rights. Also, don’t just throw anyone in this group. Especially if you plan on breaking down the roles later.

Ready for production

At this point I should have given you enough information to have a fully functional production environment. As you go about finishing your configurations and installing other site roles you will learn that my way isn’t always the best way compared to your way. What I have done in this blog works for me and is a good starter for my clients. There are so many other configurations and areas that I could talk about. We just hit the tip of the ice berg. For instance, more detailed client settings for different policy requirements, Role Based Administration so your Desktop team can only see their collections, their applications, their deployments, etc. As well as only allowing the server team to view their reports, collections, deployments, etc. We can talk about Configuration Settings for compliance and security concerns. We can go deeper into Software Updates and how to make sure you are compliant in that area. Application deployment alone is a full time job in a lot of organizations. Also, OSD, one of my favorite features in ConfigMgr, being able to truly image a machine with limited touch and knowing that as soon as that image is deployed it is 100% ready for a user to us. We can also talk about Power management and maintenance windows settings. Reporting and many more areas of ConfigMgr that we can go on and on and on. So please keep my blog saved and when I have time I will blog about a lot of these features. I even plan to re-write this blog into a more high level step by step and less talk blog for those that just want the how to version.



Install MDT 2013 (If necessary)

Before I finish I would like to walk through the Microsoft Deployment Toolkit integration with ConfigMgr console. I won’t go into depth on the product or how to use it as a standalone solution for imaging or even how to use it after you integrate it into your console.

For this environment I am going to install MDT on the primary site server for the added functionality to my ConfigMgr console. In a production environment and if you decide to use MDT to build your reference and core images I would suggest building a dedicated server for those task. You will still need to install MDT on any box that you plan to use these features from within ConfigMgr.

  1. Start by downloading the installation files from Microsoft.
  3. Double click the MDT Installation file.
  4. On the MDT Splash Screen click Next.
  5. Select location where MDT will install installation files. I will place mine on D:\Program Files\Microsoft Deployment Tools\
  6. Click Next
  7. Click Next on Customer Experience Improvement Program.
  8. Click Install
  9. Click Finish
  10. Go to your Apps menu (I am using Windows Server 2012 R2)
  11. Click Configure ConfigMgr Integration in the MDT Section.
  12. On the Options Window, verify that the bullet “Install the MDT extensions for Configuration Manager” is selected. Verify that there are checks in the two boxes in that section.
  13. Verify that your FQDN for your ConfigMgr Server is in the Site Server Name field. My site server I will enter is
  14. Verify that your correct Site code is entered. My site code I have selected is PHX.
  15. Click Next.
  16. Click Finish after successful install.

At this point you have installed MDT 2013. I suggest looking at my future blog on how to use MDT 2013 but for now you can Bing and find plenty of resources on MDT 2013.



Part I – InfrastructurePart II – Installation

One thought on “Deploying System Center 2012 R2 Configuration Manager – Single Site Server Scenario – Part III – Configuration

Leave a Reply

Please log in using one of these methods to post your comment: Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s