Here’s what we’ve seen some of our other customers do. They push the image, then install the Automox agent and let the new PC go into the Default group. They only use the Default group for new PCs, and they put the policy settings to patch all daily, so that all of the OS and 3rd party stuff will get patched right away. You can also manually kick off any patch installs showing on the device page in the console. There’s no need to wait for each one to finish, and you can click on the multiple “Run on this device” entries one after the other and then let them queue up.

The only other wrinkle is Windows exclusive patches. Those only let that patch install and then require a reboot before any other Windows patches can queue up. Either you’ll have to do a second manual pass on the device, or for an unattended approach, we have some customers who double up on the patch policies so that two attempts to patch will happen in sequence. You just need to make sure that the duplicate policies are at least 30 minutes apart. This trick means that the first policy will trigger and run the exclusive update, then the second policy will trigger and catch any other updates that were pending the installation of the exclusive patch. It’s unusual for there to be two exclusive patches in a row, hence having two duplicate policies usually does the trick. Does that make sense? Let me know if you run into any issues using the above methods and I’ll be happy to help troubleshoot and get support involved if need be.

hoping to move away from wsus, perpetually updating gold images, and sluggish system prep of distant/mobile (non-LAN based) systems, this concern is one of the items i intend to address using automox.

currently, to minimize the impact of Day 1 patching, i am shipping an image to my hardware VAR (updating this image every 30-60 days). the overhead of this process can be prohibitive.

i am interested in seeing how others are addressing this…

Sounds like we’d still be stuck with some manual process. 1) Moving PCs from Default -> Workstation groups after the initial updates or 2) having to manually click deploy (possibly twice). Both are error prone and leave a lot to be desired unfortunately.

A lot of the problem is Microsoft’s fault by forcing a 12 month deadline for feature updates when they support Fall releases for up to 30 months on the Enterprise side. That said I’m hoping someone has figured out some magic here.

i am using worklets to overcome these feature updates…have you checked this out?

Can you explain what you mean?

check this out:

😎

Ah, gotcha, Thanks, I’m less concerned with pushing Feature Updates at the moment but I did see this. I’m aware Automox is working to restore this functionality back into the core product, hoping that happens before our next upgrade.

I wondering if a worklet would be in order for my Day 1 patch problem. Trying to brainstorm what that would look like tough. Maybe I could push a registry value on deployment PCUnpatched=1, have the worklet search for this, execute updates, then change the value to PCUnpatched=0

We do have people using worklets to cobble together some sort of workflow. That does require extra work on your part though. Since there are a lot of people asking for workflows of various kinds, we are planning on adding some of those in the latter half of the year. This sort of deployment situation is one that several customer have asked for, so it’s definitely one we’ll address at some point.

You could certainly use the registry for tracking the status of a PC, if you’re working on a deployment worklet. That should work well. The other approach would be to write to a text file on the local device, rather than putting something in the registry.

You can automate moving devices to groups, using either the API or agent commands. Agreed that it’s error prone. Basically you’d need a script that would wait a couple days and then after the updates have completed, would move it out of Default and into the group of your choosing.