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:
from SMS_R_System where DateDiff(dd,SMS_R_System.CreationDate, GetDate()) <1