For some of you this is going to be a no-brainer, but for some reason I’ve been getting more and more questions about how to make User Collections in SCCM based on query rules using AD account properties, like:

  • Job Title
  • Department Name
  • Division
  • City
  • Description

While it’s still fine to use other criteria for Collection membership rules, such as OU path, Security Group names, and so on, it’s always nice to know you have even more options available.

For one customer, they found it unnecessary to add people to security groups when they already have a consistently maintained job “title” for each user account in Active Directory.  When they want to deploy software to employees by their title, why not do that directly, instead of populating a group and adding more work?  In some cases, a group is necessary for other purposes, so it’s a fact of life.  But for this customer, and others like them, they don’t rely on security groups for targeting configuration rules or software deployments.

Best of all, this is really easy (I mean REALLY, REALLY, REEEEEEEEAAALLY easy) to do.

Step 1 – Adjust the Discovery Settings

By default, SCCM collects a fairly good subset of AD account attributes for user and computer objects in a given AD forest/domain.

  • name
  • distinguishedName
  • dnsHostName
  • mail
  • objectGUID
  • objectSID
  • primaryGroupID
  • sAMAccountName
  • userAccountControl
  • userPrincipalName
  • whenCreated

The best thing about SCCM is that it’s flexible.  You can select other attributes to gather from the environment during each discovery cycle.  Just be aware that when you change Discovery settings, it does have some impact on the environment, even if negligible.

For example, when you add more settings to collect, such as discovery information, hardware and software inventory, it means more data being transmitted across the network, and more data being stored in the SCCM SQL database tables.  The impact of a discovery rule change is typically short-lived.  From then on, only delta changes are collected, and network overhead is back to minimal.

For this example, lets add some attributes for User discovery:

  1. In the SCCM admin console, select Administration, and then expand Hierarchy Configuration / Discovery Methods.
  2. Open “Active Directory User Discovery” (or right-click / Properties)
  3. Select the “Active Directory Attributes” tab
  4. Press CTRL and select “department“, “division“, “employeeID” and “title“, then click “Add >>” to move them into the Selected Attributes list.
  5. Click OK

sccm1.png

At this point, you can wait for the next Discovery cycle to run, or force it (get your fully-charged snake prod ready, for when the Network folks come storming in to yell at you for a small spike in network traffic, “caused by your evil SCCM tool thing!!”)  Just kidding.  If they freak over this small blip, offer them some marijuana-infused cookies.  Works every time.

Step 2 – Create a Collection

  1. Select Assets and Compliance
  2. Select User Collections (if you have folders beneath this, expand the appropriate folder, or create a new folder, whatever floats your boat)
  3. Create a new User Collection (right-click or select from ribbon menu)
  4. For this example, I’m going to make a User Collection to identify Sales Managers, because they’re fun to mess with.  We can deploy all sorts of painful things to them as reward for the joy they bestow upon their technical brethren.  So I will name this “Users – Title – Sales Managers”
  5. For Limiting Collection, you can use “All Users”, and click Next
  6. On the Membership Rules panel, check both “Use incremental updates for this collection” and “Schedule a full update on this collection”, because the query-based membership could change as Sales Managers are assassinated by angry coworkers and replaced by more of them stamped from the assembly line.  Just kidding.  But still, check both options.
  7. Click “Add Rule” / “Query Rule
  8. Name the rule “1” (that’s right, a number one.  For the rank of those who annoy us most)
  9. Click “Edit Query Statement…”
    sccm2
    sccm3
  10. On the General tab, check the option “Omit duplicate rows (select distinct)” (which should be selected by default, but whatever, I’m too lazy to upload this tiny request to User Voice).
  11. Select the “Criteria” tab.
  12. Click the weird little asterisk button (new query)
    sccm4.png
  13. On the Criterion Properties form, click “Select”.  On the Select Attribute popup, select Attribute Class “User Resource”, and select Attribute “title”.  Then click OK.
    sccm5
  14. Back on the Criterion Properties form, below the Value box, select the Value… button and choose the title you wish to filter on, such as (equal to) “Sales Manager” or (is like) “Sales%”
  15. Click OK and OK again to complete the process of creating the new Collection.

Now, you (hopefully) have a collection of users with a specific job title (or department, division, location value, employeeID sequence, etc.) which can be used to drive reports, and target software deployments.

Caveats

Because everything in life comes with conditions, this does as well.  First off, it depends on a properly-managed and maintained Active Directory environment.  Whether that is the result of manual effort, scripting, or third-party applications, it doesn’t matter as long as the data is reliable enough to based queries on.  If the data exists in AD, and SCCM discovery can find it, you can leverage it for almost anything.

Advertisements

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s