Setting ‘available time’ on a deployment

I’ve had customers over the years use the setting ‘available time’ on deployments.

This option is disabled by default.  It is a perfectly fine option to use as long as it is understood.  Often times it isn’t.

The ‘available time’ defines the specific time at which a deployment set to systems becomes available.  I can hear you saying “thanks Mr. obvious” but keep reading.

To illustrate how this can impact a deployment consider two example deployments of software updates.

Deployment 1
This deployment follows the timeline below.

Deployment created – 2:00 pm
Deployment available time – 5:00 am
Deployment required time – 7:00 am

The thinking of setting things up like this often goes that the administrator wants to create the deployment but doesn’t want the deployment active at all on the systems until it is allowed by the available time.  And that is exactly what will happen.  When configured in this manner the machine will learn about the upcoming deployment when it checks in for policy but will do nothing with it until it becomes available.  And, at the available time (assuming it is far enough ahead) all of the target machines will already have learned about what is coming and at the exact same time will all begin to process it, asking for content, etc.  This can put a very heavy load on the management point(s(s) due to content location requests.  In one case I’ve seen a deployment that was configured this way to 10,000 systems for an update group that had 250 updates, most of which were applicable to the clients in the environment.  You can just imagine the load as each of the 10,000 systems began to check in for up to 250 pieces of content at exactly the same time!  Not a good experience.

Why did this happen?  Because when ‘available time’ is configured the client will learn about policy ahead of time and store it until the moment it becomes available.  Essentially using this option has the effect of defeating the normal content request and download  randomization that would happen naturally if clients were able to learn about a deployment and begin processing that deployment (downloading content) through the randomly staggered policy polling interval (which is why you also need to consider how frequently clients are checking for new policy).  By allowing the natural randomization of policy checking the client load will be more evenly distributed across the environment and control about when to actually begin the deployment is maintained except that the content is now local so there is no network spike.

Deployment 2
This deployment follows the timeline below.

Deployment created – 2:00 pm
Deployment required time – 7:00 am

In this deployment the process of allowing for more natural randomization by allowing clients to request content as soon as they learn about the pending required deployment is followed and is enabled by simply omitting the available time.  Administrators retain control of the required time.  The result is a much better experience for the administrators and the end user.