SCCM (System Center Configuration Manager) – Week 1

1. Plan for site system servers and site system roles in Configuration Manager

System Prerequisites for Configuration Manager:

1. Each site system server must be domain joined
2. There should a supported version of SQL Server to host the site database.
3. IIS should be on same server we have SCCM
4. The computer where you install an instance of the SMS Provider must have the required version of the Windows
ADK.

Each Configuration Manager site you install includes a site server that's a site system server. The site can also include
additional site system servers on computers that are remote from the site server. Site system servers (the site server or a
remote site system server) support site system roles.

Site system servers

When you install a site system role on a computer, that computer becomes a site system server. At each site, you can install one or
more additional site system servers.

Configuration Manager site server

This role identifies the server where Configuration Manager setup is run to install a site, or the server on which you install a
secondary site. You can't move or uninstall this role until the site is uninstalled.

Configuration Manager site system

This role is assigned to any computer on which you either install a site or install a site system role. You can't move or uninstall
this role until you remove the last site system role from the computer.

Configuration Manager component site system role

This role identifies a site system that runs an instance of the SMS Executive service. It's required to support other roles, like
management points. You can't move or uninstall this role until you remove the last applicable site system role from the computer.

Configuration Manager site database server

The site assigns this role to site system servers that hold an instance of the site database. Only move this role to a new
server by running setup to modify the site to use a different instance of SQL Server to host the site database.

SMS Provider

The SMS Provider is a Windows Management Instrumentation (WMI) provider that assigns read and write access to the
Configuration Manager database at a site.

• Each central administration site and primary site require at least one SMS Provider. You can install additional
providers as needed.

• The SMS Admins security group provides access to the SMS Provider. Configuration Manager automatically creates this
group on the site server, and on each computer where you install an instance of the SMS Provider

• Secondary sites don't support the SMS Provider role.

This component is used to update all changes done in console.

Distribution point

A site system role that contains source files for clients to download, for example:

• Application content
• Software packages
• Software updates
• OS images
• Boot images

By default, this role installs on the site server when you install a new primary or secondary site. This role isn't supported at a
central administration site

Management point

A site system role that provides policy and service location information to clients. It also receives configuration data from clients.
Logs related to management point reside in SMS_CCM folder.
In %windows installer%\SMS_CCM\Logs

2. Site Publishing in SCCM

SMS/Sccm does not publish objects correctly in Active Directory if the Active Directory schema has not been extended for
SMS/SCCM, or if SMS/SCCM does not have sufficient permissions. Make sure your sites's computer account or the SMS
sesrvice account have full control to the System Management container.

After the appropriate account has full control, it will grant permissions to the management points so the management points can
publish their own information to Active Directory. You do not need to manually grant management points permissions to publish
to Active Directory.
To verify whether your site is publishing or fails to publish , information in Active Directory, verify hman.log and sitecomp.log
Where hman.log is called hierarchy manager, it is for managing hierarchy.
and sitecomp.log is called component manager , it is responsible for managing health of all components.

Default install path of hman.log and sitecomp.log : <INSTALL_PATH>Logs

3. SCCM Discovery Methods to discover clients

A. Active Directory System Discovery

Use this discovery method to discovers computers in your organization from specified locations in Active Directory. In order to
push the SCCM client to the computers, the resources must be discovered first. You can specify to discover only computers
that have logged on to the domain in a given period of time. It runs this discovery to perform Full and Data discovery.

By default, this method discovers basic information about the computer, including the following attributes:

• Computer name

• Operating system and version

• Active Directory container name

• IP address

• Active Directory site

• Time stamp of last logon

Actions for Active Directory System Discovery are recorded in the file adsysdis.log in the
<InstallationPath >\LOGS folder on the site server.
B. Active Directory User Discovery

Use this discovery method to search Active Directory Domain Services to identify user accounts and associated attributes. By
default, this method discovers basic information about the user account, including the following attributes:

• User name

• Unique user name (includes domain name)

• Domain

• Active Directory container names

Actions for Active Directory User Discovery are recorded in the file adusrdis.log in the
<InstallationPath >\LOGS folder on the site server.

C. Active Directory Group Discovery

Use this method to search Active Directory Domain Services to identify:

• Local, global, and universal security groups.

• The membership of groups.

• Limited information about a group's member computers and users, even when another discovery method has not
previously discovered those computers and users.

This discovery method is intended to identify groups and the group relationships of members of groups. By default, only security
groups are discovered.

Actions for Active Directory Group Discovery are recorded in the file adsgdis.log in the
<InstallationPath >\LOGS folder on the site server.

D. Active Directory Forest Discovery

Use Active Directory Forest Discovery to:

• Discover Active Directory sites and subnets, and then create Configuration Manager boundaries based on those
network locations.

• Identify supernets that are assigned to an Active Directory site. Convert each supernet into an IP address range
boundary.

• Publish to Active Directory Domain Services (AD DS) in a forest when publishing to that forest is enabled. The specified
Active Directory Forest Account must have permissions to that forest.

Actions for Active Directory Forest Discovery are recorded in the following logs:

• All actions, except actions related to publishing, are recorded in the ADForestDisc.Log file in
the < lnstaIIationPath>\Logs folder on the site server.
E. Azure Active Directory User Discovery

Use Azure Active Directory (Azure AD) User Discovery to search your Azure AD subscription for users with a modern cloud
identity. Azure AD user discovery can find the following attributes:

• objectld
• displayName
• mail
• mailNickname
• onPremisesSecurityldentifier
• userPrincipalName
• AAD tenantlD

This method supports full and delta synchronization of user attributes from Azure AD. This information can then be used along-
side discovery data you collect from the other discovery methods.

Actions for Azure AD user discovery are recorded in the SMS_AZUREAD_DlSCOVERY_AGENT.log file on the top-tier site
server of the hierarchy.

F. Active Directory Network Discovery

Use this method to discover the topology of your network and to discover devices on your network that have an IP address.
Network Discovery searches your network for IP-enabled resources by querying the following entities:

• Servers that run a Microsoft implementation of DHCP

• Address Resolution Protocol (ARP) caches in network routers

• SNMP-enabled devices

• Active Directory domains

Actions for Network discovery are recorded in the adnetdisc.log file.

G. Active Directory Heartbeat Discovery

Heartbeat Discovery differs from other Configuration Manager discovery methods. It is enabled by default and runs on each
computer client (instead of on a site server) to create a DDR.In addition to maintaining the database record, this method can force
discovery of a computer as a new resource record.
When Heartbeat Discovery runs, it creates a DDR that has the client’s current information. The client then copies this small file
(about 1 KB in size) to a management point so that a primary site can process it. The file has the following information:
• Network location

• NetBIOS name

• Version of the client agent

• Operational status details

Heartbeat Discovery is the only discovery method that provides details about the client installation status.
Heartbeat Discovery actions are recorded on the client in the InventoryAgent.log file in the %Windir%\CCM\Logs folder.
It runs in every 7 days and client sends its response in every 5 mins.
 In configuration manager, we need Discovery data Colloection Cycle to run Heartbeat Discovery.

Note: When we do any activity in SCCM console, following log files gets affected:
SMSadmin.log , SMSdbmon.log , SMSprov.log

To open WMI (Windows management instrumentation) tester, wbemtest.exe is used.

4. Boundary and Boundary Groups in SCCM

A boundary is a network location on the intranet that can contain one or more devices that you want to manage. Boundaries can
be an IP subnet, Active Directory site name, IPv6 Prefix, or an IP address range, and the hierarchy can include any combination
of these boundary types. To use a boundary, you must add the boundary to one or more boundary groups.

A boundary groups is self-explanatory, it’s a group of boundary used for for site assignment and for content location.
Beginning with SCCM 2012 R2 SP1, a boundary group can direct your clients to their Distribution Points for content, State
Migration Point and Preferred Management Point.

 Site Assignment boundary group associate a resource to a site

 Content Location boundary group is used to retrieve its deployment content (applications, packages, images, etc)

OVERLAPPING BOUNDARIES
SCCM 2012 supports overlapping boundary configurations for content location.

When a client requests content, and the client network location belongs to multiple boundary groups, Configuration Manager sends
the client a list of all Distribution Points that have the content.

This behavior enables the client to select the nearest server from which to transfer the content or state migration information .

Fallback

To prevent problems when clients can't find an available site system in their current boundary group, define the relationship
between boundary groups for fallback behavior. Fallback lets a client expand its search to additional boundary groups to find an
available site system.

5. Configuration Manager 2012 R2 Client Installation

Lets look at the methods available for Configuration Manager 2012 R2 Client Installation, we will be deploying the clients using
client push installation in this post.

1) Client Push Installation – Client Push Installation happens when an the SCCM server makes a network connection to the client
(a machine where configuration manager client is to be installed) and then begins the client installation process. For this the
system must be discovered and the administrator should have configured the firewall exceptions. This method requires the
administrator to start the client push installation on selected computers.

Note: When we push client , log come in picture on server side is CCM.log

2) Automatic Sitewide Client Push Installation – In Automatic sitewide Client Push Installation method you can configure client
push installation for a site, and client installation will automatically run on the computers that are discovered within the site’s
configured boundaries when those boundaries are configured as a boundary group.

3) Software update point installation – This method installs the client by using the Configuration Manager software updates
feature. No prior discovery of system is required in this method.

4) Manual Installation – This method allows you to install the configuration manager clients manually. The installation can be
initiated by copying the CCMSetup.exe file on the system and running it with an user account which has enough permissions to
install the software. This program and its supporting files can be found in the Client folder of the System Center 2012
Configuration Manager installation folder on the site server and on management points in your site.
5) Group Policy based Installation – As the name says you can install the Configuration Manager client using group policy.
When you assign the Configuration Manager client to computers by using Group Policy, the client installs when the computer first
starts. When you publish the System Center 2012 R2 Configuration Manager client to users by using Group Policy, the client
displays in the Control Panel Add or Remove Programs for the computer for the user to install.

6) Using Logon Scripts – Configuration Manager 2012 R2 supports logon scripts to install the System Center 2012 R2
Configuration Manager client software. You can use the program file CCMSetup.exe in a logon script to trigger the client
installation.

7) Using Computer Imaging – You can preinstall the Configuration Manager 2012 R2 client software on a master image computer
that will be used to build computers in your enterprise. When computers are imaged from this master image, they will contain the
Configuration Manager 2012 R2 client and must complete site assignment when installation is complete.

8) Upgrade Installation – This method uses your existing software distribution infrastructure to upgrade the client. Upgrade
installation requires prior discovery and site assignment
of the system.

The above methods are some of the ways where the SCCM admin can use for Configuration Manager 2012 R2 Client Installation.
In this post we will install the Configuration Manager 2012 R2 Client by enabling the automatic sitewide client push installation
method. For Client push installation you can check this post.

From the Configuration Manager Console Click Administration, Under Site Configuration, Click Sites, at the top ribbon
under Client Installation Settings, click Client Push Installation.

Following files are used to install client:

CCMSetup.exe and mobileclient.tcf
MobileClient.tcf and Ccmsetup.exe, are located in the SMS\bin\I386\ folder. These files are downloaded to the %windir%\
ccmsetup folder on the client computer
Once client is installed, service CCMSetup changes to SMSAgenthost.

6. Client Registration in SCCM

Client send request to SCCM DB and after client installation there would be three things on client : Software center , services
and control applet.
When client is not registered, there would be only two cycles:
 Machine policy retrieval & evaluation cycle.

 User policy retrieval & evaluation cycle.

After registering it gets all cycles:

ClientIDManagerStartup.log
[Creates and maintains the client GUID and identifies the tasks performed during registration and client assignment.]

LocationServices.log
[Finds management points and distribution points] Client Side

CCMMessaging.log……………………
[Records the activities related to the communication between the client and the management points]

MP_RegistrationManager.log
[ ] Server Side

SQL DB
 To Uninstall Client:
Path : <Install Path>\CCMSetup\CCMsetup.exe\Unistall

Client Certificate
The certificate is used to authenticate the distribution point to an HTTPS-enabled management point before the distribution point
sends status messages.
Certificates are Self signed and PKI certificates.

7. Managing conflicting records and duplicate GUIDs in Configuration Manager

General

ConfigMgr uses an ID that is generated on the Client to identify a machine inside the ConfigMgr hirarchy. This ID, also known as
SMS GUID is generated during ConfigMgr Client installation.
An Algorithm, which combines the Timestamp (Time of ConfigMgr Client Installation) and the Universally Unique Identifier (UUID)
is used to generate a unique Identifier.
A Client generates a new SMS GUID if the following things change

 the SMBIOS serial number

 the Machine SID
 the Hardware ID (see appendix)

There are several scenarios that may lead to problems with records in the ConfigMgr database.

Conflicting Records

Reinstallation of the operating system or changes to the Hardware components. In these cases a new SMS GUID is generated
by the client and Conflicting Records are created. Conflicting records in ConfigMgr mean multiple DB records for one machine

Conflicting records are created only in sites that run in ConfigMgr mixed mode. While in native mode, clients authenticate via
certificates and thus when reinstalling a native mode client it gets a new certificate which contains the same subject

In these cases the new HardwareID implies creation of a new SMS GUID what is why we get multiple entries in the ConfigMgr
DB for just one machine.

8. Deploying SCCM using Group Policy

If you are planning to deploy SCCM clients using GPO then you must make sure that in the client push installation
properties, Enable Automatic site wide client push installation is not checked. If this is checked then the client would get
installed on all the systems after its discovery. So first uncheck the option Enable Automatic site wide client push
installation and proceed.

1. Open Group Policy Management console. Choose OU, for which new GPO will be created (or you may link it later);

2 Right Mouse Button click and click Create GPO in this domain, and link it here

3. Enter Name and click OK;

4. Click at newly created policy, in pop-up window click OK;

5. Right Mouse Button click at policy and click Edit;

6. Navigate to Computer Configuration\Policies\Administrative Templates. Right Mouse Button click and click Add/Remove
Templates
 9. SCCM Client Installation in Workgroup

PREREQUISITES

 The client must be able to resolve the FQDN of the management point.
o Depending on network security, it might not actually ping. The important is that it can associate the FQDN to the IP of the
management point.
o Adding an entry to the Host file might be required.
 Port
o Client -> Management point : TCP 80 or 443
o Client -> Software Update Point : TCP 8530 or 8531
o More details on SCCM ports requirement, here
 Manual installation of the SCCM client
o There is no way to use the Client Push Installation for workgroup computers
o Management Point must be provided in the install command line, as the client will not be able to find it in Active Directory
o Site code must be provided in the install command line

SCCM CLIENT INSTALL WORKGROUP COMPUTERS

 Copy the source of SCCM client locally on the computer

 Open a command prompt as Administrator

 Set the working directory and run the CCMsetup command line

ccmsetup.exe /mp:<Management Point FQDN> SMSSITECODE=001 SMSMP=<Management Point FQDN>

DNSSUFFIX=<domain suffix>

Validate Management Point configuration and communication

When a client can’t resolve the FQDN of the management point, it might show up empty

Important logs at this point are

 C:\Windows\CCM\Logs\ClientLocation.log
 C:\Windows\CCM\Logs\LocationServices.log
 Those logs provide details to the connection to the management point
 If you see any error at this point, you are missing connection prerequisites of some sort.

10. SCCM Client Settings

Client settings are used to configure your deployed agents. This is where you decide any configuration like:

 Enabling hardware inventory agent

 Enabling power settings options
 Set scan schedules
 BITS throttling
 In previous versions of SCCM, client settings were specific to the site. You had 1 client settings that applied to all your
hierarchy. In SCCM 2012 you can specify clients setting at the collection level. You can have different settings for specific
collections, overlapping settings are set using a priority setting.

When you modify the Default Client Settings, the settings are applied to all clients in the hierarchy automatically. You do not
need to deploy the Default Client Settings to apply it. By default it has a 10000 priority value (This is the lower priority). All
others custom client settings can have a priority value of 1 to 9999 which will always override the Default Client Settings.
(The higher Priority is 1).

11. What are SCCM client Certificates (where are they stored)
When you install SMS or SCCM client,clients need to authenticate their management point prior to establishing communications to
prevent attackers from inserting rogue management points and redirecting clients to them to get it .

sometimes,client will fail to identify its management point which is tracked in locationservices.log file which requires attention could
be issues like boundaries etc.

there are cases,where client might require to assign from its current hierarchy to different hierarchy but the certificates might be
exist with old hierarchy and you mush reset it before it communicates with New.

To remove the trusted root key

 On the client computer, run CCMSetup RESETKEYINFORMATION = TRUE.

some info about What is the trusted root key?

The trusted root key provides a mechanism for clients to verify the authenticity of the management point and its certificate if they
cannot query Active Directory Domain Services. Every primary site server generates a trusted root key, even if the site is running in
native mode and even if Active Directory Domain Services publishing is enabled. If the primary site is joined to a parent site, the
child site eliminates its own trusted root key and instead trusts the trusted root key of the parent site.

Clients require the trusted root key only if they cannot query the Global Catalog for Configuration Manager 2007 information, either
because they are in a workgroup or remote forest, or because the Active Directory Domain Services schema is not extended for
Configuration Manager 2007. The trusted root key is stored in WMI in the root\ccm\locationservices namespace.

12. Collections in SCCM

Collections are groupings of users or devices. Use collections for tasks such as application management, deploying compliance
settings, or installing software updates. You can also use collections to manage groups of client settings or use them with role-
based administration to specify the resources that an administrative user can access.

Collection rules

There are different rules that you can use to configure the members of a collection in Configuration Manager.

Direct rule

Use to choose the users or computers that you want to add to a collection. This membership doesn't change unless you remove a
resource from Configuration Manager. Before you can add the resources to a direct rule collection, Configuration Manager must
have discovered them or you must have imported them. Direct rule collections have a higher administrative overhead than query
rule collections because they require manual changes.
Query rule

Dynamically update the membership of a collection based on a query that Configuration Manager runs on a schedule. For
example, you can create a collection of users that are a member of the Human Resources organizational unit in Active Directory
Domain Services. This collection is automatically updated when new users are added to or removed from the Human Resources
organizational unit.

13. Management Point

A management point is a site system role in Configuration Manager. The management point provides policy and service location
information for clients and it also receives configuration data from clients .

There are two log files we check in management point:

MPSetup.log- Records the management point installation wrapper process.

MPmsi.log – Records details about the management point installation.

The service used in it is SMSAgenthost

SMS Agent Host : This is the agent for Microsoft SMS this refers to systems management server (in your case the systems
management server in use is SCCM . SMS can be used to collect inventory, apply patches, deploy software, etc. This shouldn't be
on a machine unless you have SMS deployed.

Flow of Management Point:

SMSAdminUI.log
[Records the local Configuration Manager console tasks when you connect to Configuration Manager sites.]

Smsprov.log
[ Records WMI provider access to the site database.]

Smsdbmon.log
[Records database changes ]

Hman.log
[ Records site configuration changes, and publishes site information in Active Directory Domain Services. ]

Sitecomp.log
[ Records maintenance of the installed site components. ]

MPSetup.log
[ Records the management point installation wrapper process. ]

Mpcontrol.log – Records the registration of the management point with WINS. Records the availability of the management
point every 10 minutes.

To check this log :

Check IIS and make sure that you have virtual directory named SMS_MP under default website.
Check mpcontrol.log and find if you have below sucesses status message (Status Code 200).

Call to httpsendrequestsync succeeded for port 80 with status code 200 text ok
http test request succeeded

The log files can be viewed with a tool called CMTrace tool located in the path : < SCCM setup DVD>SMSSETUP/TOOLS. The
client logs are located in the path : %WINDIR%System32/CCM/Logs folder.

14. Inventories in SCCM

1. Software Inventory
2. Hardware Inventory

Software Inventory in SCCM. You use software inventory to collect information about files on client devices. It can be a specific
file, files with specific extension or all files on the computer. In addition software inventory can also collect files from client
devices and store them on the site server. If you enable the option to collect files, you might see increase in disk activity and CPU
usage.

After software inventory is enabled, clients run a software inventory cycle. The client sends the information to a management point
in the client’s site. The management point then forwards the inventory information to the SCCM site server. This information is
stored in the site database. And that is how you pull the information via reports.

When software inventory runs on a client device, the first report is a full inventory. In the next run, the reports contain only delta
inventory information. The site server processes delta information in the order received. If delta information for a client is missing,
the site server rejects further delta information and instructs the client to run a full inventory.

Hardware inventory is an interesting feature in configuration manager. When you configure hardware inventory, it collects
information about the hardware configuration of client devices in your organization. Hardware inventory settings are located in the
client settings. In other words Enable hardware inventory on clients setting must be enabled in client settings.
We force full hardware inventory on SCCM clients.

In hardware inventory we have three types :

1. Full , when there is a change in major version

2. Delta , when there is a change in minor version
3. Resync

Hardware Inventory Cycle:

Smscliui.log
[Records usage of the Systems Management tool in Control Panel.]

InventoryAgent.log
Full, delta, Resync
[ Creates discovery data records (DDRs) and hardware and software inventory records. ]

CCM

Incoming

MP_Hinv.log
[Converts XML hardware inventory records from clients and copies the files to the site server.]
[ xml-mif ]
If there is an issue with MP_Hinv.log then it checks Dataldr.log

Dataldr.log – Processes Management Information Format (MIF) files and hardware inventory in the Configuration

Software Inventory Cycle:

Smscliui.log
[Records usage of the Systems Management tool in Control Panel.]

InventoryAgent.log
Full, delta, Resync
[ Creates discovery data records (DDRs) and hardware and software inventory records. ]

CCM

Incoming

MP_Sinv.log
[ Converts XML hardware inventory records from clients and copies them to the site server. ]

Sinvproc.log
Records client software inventory data processing to the site database in Microsoft SQL Server . ]

Note :
LocationServices.log – Finds management points and distribution points.

WSUS Server Log Files

Change.log – Provides information about the WSUS server database information that has changed.
SoftwareDistribution.log – Provides information about the software updates that are synchronized from the configured update
source to the WSUS server database.