Partager via

Fast policy evaluation only for new machines

  • Article

10/13/14 - updated to add restart info

Many of my customers are in similar situations where they do not include application deployment in their OS imaging process but instead rely on Configuration Manager to deploy apps after the OS is up and running.  The biggest complaint I hear is about how slow ConfigMgr is to do this and thus people try to speed it through various things like faster collection update intervals and more aggressive client policy polling intervals.  The downside of these more aggressive practices is that there is more churn and load on the network and server infrastructure, just to support these few new machines as they are initially built out.

 

In a discussion with one of my customers I hit upon a solution to this situation using the new capabilities of the ConfigMgr 2012 product.  The general idea is to have aggressive schedules only for machines in the process of being setup but less aggressive schedules for the rest of the machines.

 

Overview:

  • Set (only) necessary collections to do incremental updates
  • Enable delta discovery for systems
  • Set default client agent settings to policy interval of 5 minutes
  • Set "standard" client policy interval to 60 minutes, precedence of 2
  • Set "setup" client policy interval to 5 minutes, precedence of 1
  • Set "setup" client policy to have shorter reboot notifications (1 and 5 minutes perhaps)
  • Deploy “setup” interval at collection with members created in last X days
  • Deploy “standard” policy to a collection of all clients, such as “all systems”

 

Outcome:

A new machine will get the aggressive default policy polling interval of 5 minutes and keep checking for new software deployments.  Once AD discovery picks up the machine via delta discovery it will be added to the collections via incremental updates to start getting software.  It will also join the “setup” collection and get a policy that keeps its policy polling interval at 5 minutes.  It will also have its reboot notification schedule shortened to allow for faster deployments when multiple reboots are necessary. After a set time (1 day in my example below) when setup should be complete it will move out of the setup collection but get the standard policy which puts it back on a normal 60 minute policy polling interval and regular reboot notifications, causing less churn and more notification time to the end user.

 

Details:

The key to this setup is the collection query rule for the setup collection.  The following query should give you all machines added to Configuration Manager in the last day:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,

SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,

SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client

from SMS_R_System where DateDiff(dd,SMS_R_System.CreationDate, GetDate()) <1

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    MSD_Guy - I haven't tested that scenerio, but I agree with your logic.  It should apply to any process that creates a new record in ConfigMgr.

  • Anonymous
    August 10, 2012
    Michael does this also cover computers that already existed in CM but are being reimaged? I am guessing it does if the query is based on the client creation date and not the computer object creation date.

  • Anonymous
    September 12, 2012
    Nice, this is in my favourites now

  • Anonymous
    July 03, 2013
    I have a collection that has a custom client settings deployed to it.  The polling of this collection is set to 5 mins here and then i use the membership rule below.  Providing your updates target the collection, they will be pushed to your new clients within 5 mins.  After 24 hours of SCCM seeing the computer, it is removed from the collection! select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where DateDiff(dd,SMS_R_System.CreationDate, GetDate()) <1

  • Anonymous
    July 02, 2015
    Very useful stuff here - thanks. I had a need to bring in only new computers created in the past 4 hours. The key here was of course to change the dd to hh and the <1 to <4... but in addition - it seems the Creation Date in SCCM is done in UTC so to be more accurate you also need to change GetDate to GetUTCDate. You wind up with this:

    SMS_R_System where DateDiff(hh,SMS_R_System.CreationDate, GetUTCDate()) <4

    I think folks may benefit from using GetUTCDate instead of GetDate in your query as well.

  • Anonymous
    July 02, 2015
    CJ - Good observation. I had to factored in UTC but you are correct, internally most things in ConfigMgr are in UTC since multiple sites in a hierarchy could be in multiple time zones.

  • Anonymous
    July 08, 2015
    If when re-imaging a device you are not deleting the device out of SCCM first, adding SMSUUIDChangeDate into the where clause will capture both previously unknown new devices and existing devices

    where DateDiff(dd,SMS_R_System.CreationDate, GetDate()) <1 or DateDiff(dd,SMS_R_System.SMSUUIDChangeDate, GetDate()) <1

  • Anonymous
    January 23, 2016
    For the life of me I could not get GetUTCDate to work properly in the query. We have a global hierarchy and this would be useful. Anyone have luck with the SMSUUIDChangeDate and GetUTCDate? The query editor just spits back a syntax error when using GetUTCDate() instead of GetDate().

  • Anonymous
    April 13, 2016
    Thanks for the great article, I have the collection and setup client policy configured and working. Just tackling the last piece, faster DDR updates for OU changes. I get that is what delta discovery for systems is meant to address. I am currently only using heartbeat discovery (also updates DDR). Client is installed by GPO on our systems.

    I have approx 16,000 clients on a single primary site. I am concerned about load on my SCCM server as I approach this problem.

    Does anyone else enable AD System Discovery with delta discovery and not follow through with client push since it is handled by GPO? Will this potentially overload my server? It sounds like delta discovery will update system OU properties very quickly with this feature.

  • Anonymous
    April 14, 2016
    I just turned on AD System Discovery with delta changes, no noticeable performance impact.