In the Install SCCM 2012 article we have through the process of deploying a new SCCM 2012 Server in a lab environment like many other products this is not sufficient to have a functional product as basically our SCCM Server will sit there without doing nothing oblivious to the environment surround it, in this post I will describe the SCCM Discovery Methods which can be used to give SCCM knowledge about our environment.
SCCM Discovery Methods – An introduction
Lot of SCCM functions depend on its knowledge of the environment where it is sitting with the ability to hook into all parts of the “network” like Active Directory and network layout. By default ConfigMgr does not automatically connect to your environment and start collecting needed data this is the Discovery Methods’ job and it is the Administrator’s duty to configure which methods are appropriate for the environment and how often they run striking a balance between data freshness and performances.
You can review available discovery methods via the SCCM Admin Console under Administration → Hierarchy Configuration → Discovery Methods
If you prefer to use PowerShell you can use the following command to achieve the same result with less clicking around (I’ve cut the output for brevity)
PS ALX:> Get-CMDiscoveryMethod
ComponentName : SMS_AD_FOREST_DISCOVERY_MANAGER
FileType : 2
Flag : 6
ItemName : SMS_AD_FOREST_DISCOVERY_MANAGER|SZHV-CM01.mcse.lab
ItemType : Component
Name : SZHV-CM01.mcse.lab
PropLists : {Start On Master Site Control File Changes}
Props : {Enable AD Site Boundary Creation, Enable Subnet Boundary Creation, Run Count, SETTINGS...}
SiteCode : ALX
ComponentName : SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT
FileType : 2
Flag : 2
ItemName : SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT|SZHV-CM01.mcse.lab
ItemType : Component
Name : SZHV-CM01.mcse.lab
PropLists : {AD Attributes, AD Containers, Start On Master Site Control File Changes}
Props : {Days Since Last Logon, Days Since Last Password Set, Discover DG Membership, Enable Filtering Expired
Logon...}
SiteCode : ALX
ComponentName : SMS_AD_SYSTEM_DISCOVERY_AGENT
FileType : 2
Flag : 6
ItemName : SMS_AD_SYSTEM_DISCOVERY_AGENT|SZHV-CM01.mcse.lab
ItemType : Component
Name : SZHV-CM01.mcse.lab
PropLists : {AD Attributes, AD Containers, Start On Master Site Control File Changes}
Props : {Days Since Last Logon, Days Since Last Password Set, Enable Filtering Expired Logon, Enable Filtering
Expired Password...}
SiteCode : ALX
If you have experience working with SCCM 2007 you have surely noticed Microsoft removed and renamed some of the Discovery methods, if you’re new to SCCM fear not as I will go through and each of the discovery methods and explain their function in more detail.
SCMM Discovery Methods Explained
As the description of the various SCCM Discovery Methods can be a lengthy one rather than presenting you with a wall of text I’ve used spoilers to make reading easier, just click on the SCCM Discovery Method name to display the text.
[su_spoiler title=”Heartbeat Discovery” anchor=”[su_spoiler title=”Heartbeat Discovery” style=”fancy” anchor=”Heartbeat Discovery”]
SCMM Discovery – Heartbeat
The heartbeat discovery is the only method enabled by default at installation time, its main function is to run on each client and generate Data Discovery Records (DDR) which contain various information about the client, like NetBIOS Name and Network location, and then submitted to the Management Point then processed by the primary site for the purpose of keeping client’s record in the database or force the discovery of a client that has been removed from the console. By Default Heartbeat Discovery runs every 1 week as a best practice this method should always be enabled and if you feel like you need to change the schedule the value you use should be less than the value that is used for the Delete Aged Discovery Data maintenance task.
In the picture below you can see the default configuration settings for the Heartbeat Discovery Method as it appears in the SCCM Admin Console
[/su_spoiler]
[su_spoiler title=”Active Directory Forest Discovery” style=”fancy” anchor=”AD Forest Discovery”]
SCCM Discovery – Active Directory Forest Discovery
Active Directory Forest Discovery was one of the new, and long-awaited, features in SCCM 2012 and its main role is that of discovering resources in the forest where ConfigMgr resides in addition to any trusted forest.
The real advantage of AD Forest Discovery is that it allows SCCM to automatically configure Site Boundaries based on discovered AD Sites in either the local or trusted forest while this process can be disabled if you decide so it is a time saver and neat feature to be sure your site boundaries are automatically populated
[su_note note_color=”#ffff96″ text_color=”#000000″ radius=”5″]Note: Like with heartbeat discovery AD forest discovery can only be enabled/used on Central Administration (CAS) or Primary Sites [/su_note]
[/su_spoiler]
[su_spoiler title=”Active Directory Group Discovery” style=”fancy” anchor=”AD Group Discovery”]
SCCM Discovery – Active Directory Group Discovery
As the name implies this Discovery method is used to discover users or devices in AD Group you can define the search path which can be either an OU or a group available in the domain, as ConfigMgr 2012 is a user-centric product you can use discovered users to create collections to which target software deployment. Here’s a screenshot of what I am using at the moment in my lab
The default schedule for a full AD group discovery is 7 days while delta discovery runs by default every 5 minutes, in the Options tab you have the ability to discover members of Distribution Groups and computers that logged on to the domain or updated their password in a given timeframe which is very useful to avoid discovering stale resources
[/su_spoiler]
[su_spoiler title=”Active Directory System Discovery” style=”fancy” anchor=”AD System Discovery”]
SCCM Discovery – Active Directory System Discovery
The AD System Discovery allows and administrator to discover AD computers in the domain or in specific OUs
You also have the ability to choose which attributes are discovered by SCCM
and exclude obsolete objects similarly to what we’ve seen in group discovery
[/su_spoiler]
[su_spoiler title=”Active Directory User Discovery” style=”fancy” anchor=”AD User Discovery”]
SCCM Discovery – Active Directory User Discovery
Active Directory User Discovery will allow ConfigMgr to discover… well Active Directory users, similarly to Group Discovery you can limit the scope of search or specify additional parameters in addition to the default ones.
Discovering users is handy to create collection that can in turn be used to target software deployment to specific users within the organization.
[/su_spoiler]
[su_spoiler title=”Network Discovery” style=”fancy” anchor=”Network Discovery”]
SCCM Discovery – Network Discovery
I have left Network Discovery method last for a good reason while it allows you to discover any network resource using an IP address it is considered best practice to enable this discovery method only when all other methods have failed to discover the resource as this method causes significant overhead both in terms of network traffic and database data.
Network discovery is performed querying DHCP Servers, SNMP enabled devices, ARP Tables on routers or AD Domains while this could seem like a good idea it is in reality of little use as SCCM cannot do little with, for example, a router.
SCOM is usually better suited for this type of job and in my experience as consultant have seldom used or even enabled this type of discovery.
[/su_spoiler]
While there are no fixed rules on which SCCM Discovery methods should or should not be enabled as every infrastructure is different, as per experience I can only suggest you to try to limit amount of information gathered and stored in the database so not to bloat it.
Lethe HeloCheck 