Michael Griswold's SCCM Tips and Tricks

Things I have learned and want to share

Fast policy evaluation only for new machines

Fast policy evaluation only for new machines

  • Comments 8
  • Likes

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.



  • 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”



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.



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,



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

  • 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.

  • 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.

  • Nice, this is in my favourites now

  • I noticed that my query got truncated so I fixed that.  That should be one long query line with no carriage returns.

  • 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

  • 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.

  • 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.

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment