Pre-stage patches with a separate task

Usage and Config Patch
1

Is it possible to pre-stage a baseline to end-points with this post Pre cache a baseline for Patching, and then a few days later run that baseline with automation using those pre-staged patches?

Thank you
-Brian

2

Absolutely, we do it all the time. We make sure the local relay at the site has sufficient space to accommodate the downloads. Then we run an action with pre-fetches only targeting the relay in the remote site. We verify that the clients are using the appropriate local relay, then when we run the real full baseline on them a few days later, everything is local, so it runs fast.

We also like to combine this strategy with throttling so that large packages can trickle to remote locations over several days without adversely impacting the WAN connection.

3

JonL, What about going down to the endpoint level also? We have some remote servers and I’d like to push the patches to the node a few days ahead of time, then when the patch job is sent everything is on the server.

Thank you
-Brian

4

Usually for this, it’s simplest to just create a normal action a few days ahead of time, set the ‘Action Start Time’ to the beginning of your maintenance window, and check the ‘Begin downloads before constraints are satisfied’ checkbox.

That’s a built-in way of doing what it sounds like you’re trying to accomplish. Patches begin downloading to the endpoint now, but nothing executes until your ‘Action start time’ arrives.

1 Like
5

Jason,
We do this in a few places. We are struggling with the Automation plans we run. With change control and support controls, we are reluctant to push a job/plan a few days ahead of time. If we could schedule a “prefetch” job days ahead of time, and then a few minutes ahead of the change window submit the automation plan task, we could see a huge decrease in change windows.

Thank you
-Brian

6

Another way to do it would be to break it into two tasks. The first would contain the prefetches and save the contents to a local folder (such as c:\temp\NewAppInstall). Then the second task would run the installer from that location (c:\temp\NewAppInstall) vs the normal __Download.

That approach does work, but it does require more effort to split things apart.