If you would like to read the other parts of this article series please go to:
Microsoft has made a number of important enhancements in the entire System Center line of products, including the popular Configuration Manager component. With the 2012 edition of the suite, especially when deployed with the first service pack, Configuration Manager becomes an incredibly powerful method by which IT departments manage their desktop and server environments. Configuration Manager provides organizations with operating system deployment capability, centralized software installation, patch management, endpoint protection, mobile device management and a whole lot more. In this series of articles, you will learn about how to best use SCCM in your environment. This article series assumes that you are running SCCM 2012 with Service Pack 1. Service Pack 1 was released in early 2013.
Because Microsoft and many other sources have created very good installation guides, this article series will skip discussion of system requirements and installation steps. For the purposes here, it’s simply assumed that you have a working SCCM basic installation and you’re able to get access to the SCCM console, which was completely revamped for SCCM 2012.
In the first parts of this series, we’re going to discuss the discovery and client deployment processes. These are, perhaps, some of the most challenging parts of the SCCM deployment process. But, they’re also among the most important. Failure to get things right at this stage can mean a poorly deployed SCCM environment that works against you rather than with you.
In order for client deployment to be successful, three things must take place:
- Appropriate discovery methods must be selected and configured.
- Boundaries and boundary groups must be defined.
- Administrators must choose the client deployment method (or methods) that make the most sense in their specific environment.
This article series will take you start to finish from a brand new SCCM 2012 SP1 installation through to having the SCCM 2012 SP1 client deployed across your organization.
Discovery
If you’re wondering about the purpose of discovery, wonder no more. Discovery is the process by which SCCM locates objects that can be brought into the SCCM database and managed or otherwise used by SCCM to improve IT operations. For example, SCCM is used to locate client computers to which the SCCM client can be deployed. In addition, discovery locates objects such as Active Directory user accounts, Active Directory forests and domains, IP subnets, Active Directory user groups and network devices.
Discovery is a crucial process. Without it, other SCCM tasks, such as boundary creation and client deployment can’t easily take place, if they can take place at all. However, it’s important to note that not all discovery methods are available all the time.
By default, only one of SCCM’s many discovery methods is enabled: Heartbeat discovery. Heartbeat discovery is different from all of the other discovery methods available in that it isn’t capable of locating new resources that can be brought under SCCM’s management auspices. Instead, heartbeat discovery exists only to allow existing clients to occasionally “check in” with SCCM to tell the system that they’re still out there doing their thing.
Figure 1: Heartbeat Discovery Properties
What’s changed since SCCM 2007
If you’ve used SCCM 2007, it’s important to note that Microsoft has made some changes to the discovery methods found in SCCM 2012. First, what used to be called Active Directory Security Group Discovery is now known as Active Directory Group Discovery. Second, the Active Directory System Group Discovery method has been removed from the product.
Perhaps most notably, “delta discovery” has undergone significant improvement in SCCM 2012. Delta discovery is a service that runs on a continuous basis that watches for additions to and deletions from the discovered object database. It works by using the original discovery method to see if an object has been added to, for example, Active Directory and, if it has, adds it to the appropriate SCCM database. Conversely, if an object is removed from Active Directory, it will be removed from SCCM.
Delta discovery is a wonderful tool that further streamlines SCCM 2012 and makes it easier to manage.
In SCCM 2012, delta discovery is now supported by the Active Directory System, User, and Group Discovery methods.
Discovery methods
Because different discovered objects are used for different purposes in SCCM, there are a number of different discovery options that you have at your disposal. When a discovery method locates a supported object, a data discovery record (DDR) is created, which includes fields based on the type of discovered object. DDRs are then written into the Configuration Manager database and then used by SCCM later on.
The discovery methods pertinent to client deployment are described in this article series.
Active Directory System Discovery
No matter what, you’ll use Active Directory System Discovery at some point in your SCCM journey. This is the discovery method responsible for finding the majority of the desktops in your environment. With System Discovery, SCCM scans Active Directory for computer objects. In order for client deployment to take place, you need to have system records in your SCCM database.
When you open the properties page for System Discovery, you will discover that the method has yet to be enabled. However, that situation is quickly rectified by selecting the checkbox next to Enable Active Directory System Discovery.
You also need to ensure that SCCM knows where to find new computer objects. You can tell SCCM to simply find everything it can in Active Directory, or you can limit which Active Directory containers are searched. This can be useful if you plan to deploy SCCM in phases and don’t want to clutter the SCCM database with computer records that you don’t plan to use yet. To add a new Active Directory container to the discovery method, click the yellow star-like button shown in Figure 2.
Figure 2: Active Directory System Discovery – General
Once you do, the screen shown below appears, asking you to provide the path to the Active Directory organizational unit you want to add System Discovery. Click the Browse button and navigate the resulting window to locate the OU you’d like to add.
There are additional options at your disposal, too. If you want System Discovery to search any child containers that you exist in the container you selected, select the checkbox next to Recursively Search Active Directory Child Containers. De-select this checkbox if you want the search process to focus solely on the identified container.
Further, if you’d like to discover objects that exist in Active Directory groups, select that checkbox.
The account you use must have rights to read Active Directory.
Figure 3: Active Directory System Discovery – Specify AD container
On the Polling Schedule tab, you can instruct SCCM to perform a full discovery process on a predetermined schedule. For the System discovery method, the default interval is seven days, as you can see below in Figure 4. If you’d like to change this schedule, click the Schedule button and then tell SCCM what schedule you would prefer. This is also shown in Figure 4.
Note that this discovery method supports delta discovery, a process that can run in between full discoveries so that there isn’t a full week of lag time between a new system being added to Active Directory and it being discovered through a full discovery. You can change the delta discovery time away from the default of 60 minutes.
Figure 4: Active Directory System Discovery – Polling Schedule
SCCM is an incredibly powerful tool that can help streamline IT organizations. It does this through the centralization of information from across the environment. The more information you feed SCCM, the more you can do. On the Active Directory Attributes tab, you can instruct SCCM to gather additional pieces of information beyond the default.
Figure 5: Active Directory System Discovery – Active Directory Attributes
On the final tab in this display – marked Options – are a couple of useful, well, options. Before I get to those, though, let me describe a common situation. Many organizations do a relatively poor job keeping Active Directory clean. As machines come and go, stale records aren’t removed from Active Directory. These records can get in the way of a perfectly good SCCM implementation. While the associated computers are never actually located on the network – since they’re gone – stale records are still discovered by System Discovery.
On the Options tab, you can instruct SCCM to only locate computers that have logged on to the domain within a certain number of days or that have updated their computer account passwords within a certain number of days.
Figure 6: Active Directory System Discovery – Options
If you don’t want to do that or you want to get a list of computers that have not logged into the domain in a long time, you can use PowerShell to gather than information. For my purposes, I downloaded and slightly modified a script that I downloaded from a Spiceworks forum. It’s shown below. This script outputs a list of computers and, for each computer, the date that the computer last logged on to the domain. You can then remove from Active Directory old computer accounts, but make sure you verify the list to make sure you don’t accidentally remove a computer you need.
# Thanks to Ben Lye from the link:
# http://sysadmin-talk.org/2010/02/finding-stale-accounts-in-ad-with-windows-powershell/
# If this is the first time running PowerShell then enter this command to allow you to
# run cmdlets: Set-ExecutionPolicy RemoteSigned
# Now type in the following command to create a file in the desktop with the PC name and
# the last logon time (using the example above that I saved in my user desktop).
# Also you need to replace where it says "myuser" for your username. If you saved the file
# in a different location then replace the path for that location. Here is the command:
# c:\ps-scripts\GetPCLastLogon.ps1 > "c:\ps-scripts\LastLogon.txt"
# Calculate the UTC time, in FileTime (Integer) format and convert it to a string
$LLTSlimit = (Get-Date).ToFileTimeUTC().ToString()
# Create the LDAP filter for the AD query
# Searching for enabled computer accounts which have lastLogonTimestamp
$LDAPFilter = "(&(objectCategory=Computer)(lastLogonTimestamp<=$LLTSlimit) (!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
# Create an ADSI Searcher to query AD
$Searcher = new-object DirectoryServices.DirectorySearcher([ADSI]"")
$Searcher.PageSize = 1000 # Enables script to return more than 1000 objects
$Searcher.filter = $LDAPFilter
# Execute the query
$Accounts = $Searcher.FindAll()
# Process the results
If ($Accounts.Count –gt 0)
{
$Results = @()
ForEach ($Account in $Accounts)
{
$Result = "" | Select-Object Name,OperatingSystemVersion,lastLogonTimestamp
$Result.Name = [String]$Account.Properties.name
$Result.OperatingSystemVersion = [String]$Account.Properties.OperatingSystem
$Result.lastLogonTimestamp = [DateTime]::FromFileTime([Int64]::Parse($Account.Properties.lastlogontimestamp))
$Results = $Results + $Result
}
}
# Output the results
$Results | Format-Table -autosize
Summary
This is just part 1! In part 2, we’ll continue our client deployment journey and I’ll share with you a number of real-world tips that I’ve learned along the way.
If you would like to read the other parts of this article series please go to:
