The situation
A previous printer rollout had left hybrid PCs with the wrong driver state, while cloud-managed devices needed a self-service path. The “printer” was a virtual queue rather than a conventional device, and the final connection had to exist in the signed-in user’s profile even though the driver work belonged at system level.
What I found
There was no single deployment state to fix. Some endpoints needed a failed local queue removed, hybrid PCs needed the correct driver applied automatically, and cloud-managed devices needed an on-demand Company Portal workflow. Detection also had to distinguish the device-side driver from the user-side printer connection.
What I changed
I split the work into specialised components: estate-wide cleanup, an automatic hybrid-PC driver fix, and a self-service deployment for cloud-managed devices. The main script bridged SYSTEM and USER context with a controlled scheduled-task handoff, while separate detection scripts verified the driver and user connection independently. For the small Win32 packages, I kept the driver payload self-contained rather than adding another dependency chain.
What happened
The partly failed configuration became a controlled deployment model. Affected hybrid PCs received the required driver correction automatically, cloud-managed users could install the virtual queue on demand, and logging, cleanup and independent detection made the result easier to troubleshoot and support.
What I’d do differently
The overall split still makes sense. The small tidy-up I would make is structural: keep the driver payload in a dedicated Drivers subfolder and resolve it through $PSScriptRoot. Same deployment idea, slightly cleaner package.