PDQ and Windows Updates

Last year introduced PDQ as way to easily deploy applications to desktops. In the past, applications were either installed in the master clone, thinapp’d or manually installed by remotely connecting to the VM and installing it locally.

This is where I did a POC and proved that this was a time saver and pretty much fool proof.

In the last few months I started looking at using PDQ to install Windows patches. Preliminary tests showed that it worked well. I did look at WSUS, but was limited in terms of scheduling, and without using something like SCCM or SCOM, it would be very hard to manage. I also did not want to put up infrastructure just for patching.

PDQ pushes out Windows patches just like any other application, connects to the target, installs, and reboots, if you choose to. DONE.

However, there was no easy way to snapshot the VM. I came up with a PowerCLI script attached as a Pre-Step, however, I soon discovered that the PowerCLI script also ran on the target computer, and not on the source. One solution presented was installing PowerCLI on all server VMs. Tossed that idea out quickly as I didn’t want to install PowerCLI on all VMs, and with how the script worked, a snapshots of all VMs would occur on all VMs. So if I had 10 VMs in the script, the script would run on all 10 VMs, give me 100 snaps in total.

After some brainstorming, I decided to have the script run as scheduled task. If I had the patching occur at 2AM, I could have the script run at 1:58AM. Early testing showed that this worked just as expected. BINGO!

Only thing I need to make sure of, is to update the server list, so the VMs scheduled for patching gets snapped.

So essentially, have a scheduled task run the script 2 minutes before patch time, and then have the patch schedule run.

Hope this helps other people facing the same or similar problem

%d bloggers like this:
Bitnami