Monthly deployments, offline targets to heartbeat instead of retry?
Our domain consists of about 85% laptops, 10% desktops, and 5% servers. Our laptops go in and out of the office online and offline at any given time anywhere in the world.
I'm trying to minimize the version disparity that exists in our environment, so I would like to set up a monthly update routine; that way at least most of the time our machines will run the same software versions.
Using Deploy and Inventory Enterprise, I would like to accomplish this in the following way:
- Monthly check for new package versions (I have a nested "Baseline" package consisting of a dozen packages from the library) and approve them automatically, say every last Friday at 8 PM (not sure if possible).
- Monthly deploy schedule, say every first Monday at 9 AM (easy enough).
- For offline targets and other failures, skip the retry queue and use a Heartbeat schedule instead (not sure if possible).
Is this possible, or is there an other clever way to accomplish this?
To be clear, I know I can set an approval schedule, but if new versions come out during the monthly cycle, they'll be deployed to the machines in the "retry heartbeat", in stead of the desired monthly approved version.
Comments
I would always link the schedule to a (old) collection in combination with the heartbeat trigger, this gives the best result.
To prevent a wrong deloyment, copy the official old/latest collection and build a custom one and link the schedule to this one.
Example: I have a custom "Firefox esr (old)/(latest)" collection, because PDQ offers the wrong language for us. If a new Firefox ESR version comes out, i download the right language version and i replace the .exe in the package. Then i change the version number in my custom collection.
This way the heartbeat trigger don't kicks in if PDQ says there is a new version, it kicks in after i changed the version number in my custom collection.
Hi Christian, thanks for the ideas.
Sounds like a good workaround; although I would still love to see a "move failed/offline deployments to a Heartbeat" as an option.
How do you make sure your heartbeat schedules don't interfere with each other? Installing multiple new packages at the same time results in errors. Or do you use 1 heartbeat schedule with all the relevant packages attached to it?
Heartbeat schedules don't interfere with each other because only one package can be run on a device at the same time. The other deployments are queued and processed in a sequence until all are deployed.
As long as there are no dependencies between the packages, everything works automatically.
If you have dependencies like "you need Net Framwork 4.7 before you install paint.net", build a custom package with nested package steps (first Net Framework, second paint.net) or use the "pre-Steps" option inside the original paint.net package to make sure you have the right install sequence.
I would love to have a heartbeat retry trigger for offline computers too,
would be very usefull for laptops and would make more sense than retrying again and again.