I've set up a Windows Server 2025 print server to replace an existing Server 2016 system. The print queues were migrated with the print migration tool, and Uniflow is used so users must release jobs at the physical printer.
The affected queues use the Canon iPR Svr M20 PS V1.0 US driver, version 6.5.0. The driver is already deployed to Windows 11 24H2 clients through SCCM, while the printers are mapped through Group Policy. Mappings from the Server 2016 print server work normally, but mappings from Server 2025 trigger a UAC prompt to install the driver even though it is already installed on the client.
Switching the queues to Canon's generic driver avoids the prompt. I reproduced the behavior on a separate Server 2025 test system and compared the driver files on the server and clients without finding an obvious difference. Has anyone run into this with Fiery or Type 3 drivers on Server 2025?
3 Answers
Check the Point and Print Restrictions policies and any other PrintNightmare-related Group Policy settings. The older print server may be listed as a trusted driver source, while the Server 2025 host is not. That can cause Windows to request driver installation or elevation even when the package is present locally. Make sure the new server is covered by the approved server list and that the relevant driver-installation policies are consistent.
This is a Type 3 driver, so Windows may treat the driver on the new print server as a different package or source even if the client has matching-looking files. Installing the exact package on Server 2025 as an administrator can sometimes resolve that, but Fiery-based drivers are often picky about package metadata and server-side installation.
A Type 4 driver could avoid some of the Point and Print and driver-installation behavior, but Canon has indicated that one is not available for this device. In that case, the practical options are to fix the trusted print-server and driver-installation policies or move to a supported generic driver, accepting that some device-specific features may be lost.
That seems to be the right direction. After adjusting a couple of the policies, the queue mapped without prompting, although one queue that worked before still needs additional troubleshooting.