Interestingly enough, @DimitriRodis requested this back in March to deal with NVidia updates, and a similar fix could also work for re-evaluating available updates after a feature update. Here’s what @DimitriRodis proposed:
Release notes
You can now have maintenance items (software / tasks) defer their evaluation for compliance until the execution stage.
Problem to solve
Here is the scenario:
Someone has deployments for the following two things:
Dell Command Update (which updates drivers, including video)
nVidia Driver Installation/Update Task (which updates a video driver needed for rendering/CAD)
Without the “deferred evaulation” feature, here is what happens:
- Evaluation of all maintenance items - ordering, and compliance checks
- –Dell Command Update returns non-compliance because there are driver updates available.
- –nVidia Driver Installation/Update Task returns compliant.
- Execution stage begins.
- –Dell Command Update runs, and installs an inappropriate driver.
- Execution concludes.
- Next maintenance cycle: Evaluation of all maintenance items - ordering, and compliance checks
- –Dell Command Update returns compliant, all is up to date.
- –nVidia Driver Installation/Update Task returns non-compliant because of the driver Dell Command Update installed.
- Execution stage begins.
- –nVidia Driver Installation/Update Task installs the driver and completes.
- Execution concludes.
- Goto Step 1 (forever).
One seemingly obvious “fix” for this is to exclude video driver updates from Dell Command Update–which, although is possible, has been tried. Something else (possibly another driver, such as chipset drivers) can apparently cause this, because it’s happening to Jason.
Proposal
The proposal to “fix” this and other similar situations, while less than completely ideal, would work very simply by implementing a checkbox on all maintenance items (software/tasks) that defers evaluation of compliance until the maintenance item is reached in Immy’s execution stage. So, with this feature implemented, the above session would instead work as follows:
- Evaluation of all maintenance items - ordering
- Evaluation of all maintenance items that do not have deferred execution are performed.
- –Dell Command Update returns non-compliance because there are driver updates available.
- –nVidia Driver Installation/Update Task is present, but compliance check is deferred.
- Execution stage begins.
- –Dell Command Update runs, and installs an inappropriate driver.
- –nVidia Driver Installation/Update Task compliance check is run, returns non-compliance due to the inappropriate driver.
- –nVidia Driver Installation/Update Task installs the driver and completes.
- Execution concludes.
My thoughts:
Are we perhaps over-generalizing a solution to a problem that only happens in very specific scenarios? Would this problem be better solved by making Immy natively understand what an OS upgrade is instead of us shoehorning Feature updates into a Software package? We’re already having to do a lot of trickery to make this work. For example:
- Windows 11’s version is still 10.0.X, so I hacked our Software Inventory script to return a fake “Software” called “Windows 10” or “Windows 11” depending on whether the OS version in WMI is 10.0.22000 or higher. This allows for easier bulk reporting since these inventory scripts run daily, and eliminates the need for a custom detection script for Windows 10, but it is still…hacky.
- I create static versions for each build of Windows 10 with fake download links but then have a custom Download script that uses the Rufus Windows ISO download script to download the actual ISO based on the version. This isn’t a problem necessarily but it does mean that I have to manually add static versions each time a new Feature update becomes available. The real issue is that most people refer to feature updates by their short names of 22H1, 22H2 etc but these aren’t natively sortable like version numbers so the casual enthusiast will find themselves on Wikipedia’s Windows 10 page trying to figure out what the latest version of Windows is that ImmyBot supports. Sure I could add a version “alias” to make it easier for people but it seems like I’m yet again adding an entire feature for one specific edge case.
Moving forward we’re going to be releasing ImmyMDM which gives us access to new Windows Update APIs in Windows. This is going to force us to build out the concept of “OS Updates” in Immy anyway.
But regardless of how we apply the updates, I propose we create an additional “Platform Update” phase of the session that happens before everything else. The logic would work exactly as @James_Harper and @DimitriRodis suggest where both detection and execution of other items is deferred. The only problem here is what to show on emails to the end user. The naive case would be to only show the OS Upgrade and perhaps say “This platform upgrade must be performed before further updates can be evaluated” or something to that effect.
While on that line of thought, I also want to propose the concept of action criticality. I won’t go into detail here but the idea being that you could run less invasive updates on a more frequent schedule than our default of one week.
Anyway, my solution doesn’t fully solve @DimitriRodis 's Dell vs AutoDesk video driver problem. For this I’d also suggest we extend the concept of Software to cover Drivers. We’d start by inventorying installed drivers as well as the hardware they may be bound to. I’d likely start by only inventorying Video and Ethernet drivers/hardware. Then add a “DriverUpdate” actionType that necessitates the specification of the inventoried VEN/DEV IDs or VID/PID for USB devices. This way during detection we can prevent the addition of multiple driver update actions for the same piece of hardware.
This would build on top of a feature we have actively in development that allows for the creation of child actions within the Metascript engine. The concept is to allow Dell Command Update/Lenovo System Update/HP Image Assistant tasks to create individual actions on the session for each of the items they intend to update via a new cmdlet Add-ChildAction or something to that effect.
Now of course the real kicker is resolving the hardware id from the perspective of a generic NVidia Driver installer that contains hundreds of drivers, or perhaps one universal driver that covers thousands of pieces of hardware. This could likely be cumbersome to resolve from the perspective of Dell Command/HP etc but my hopes are that there is enough information in the logs to be able to figure out why it decided an update was available in the first place. Perhaps an easier way to go about this would be to instead look at it from the perspective of the types of hardware we support, Video and Ethernet. We could then implement the concept of Dell Command being a “Driver Provider” capable of updating Video and Ethernet drivers, while NVidia is a “Driver Provider” capable of updating Video drivers. Further, we could scrape together some code I wrote a long time ago for fetching the latest “Autodesk Compatible” drivers and indicate that it is also a “Driver Provider” capable of providing Video drivers.
In this way we could set a policy that says “Computers used by members of the Engineering team should have their video drivers come from the Autodesk Driver provider”