This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Hello,
We are planning to migrate our Windows 2012 Print server to Windows Server 2022. We are using HP Universal Print Driver PCL 6, HP Designjet HPGL2 Driver, SHARP MX-5070V PCL6, and SHARP MX-7580N PCL6, all Type 3 drivers.
Does anyone know if it's okay to use Windows Server 2022? Or is it too new? Any compatibility and support issues that we should know running these print drivers and HP printers? I understand that users will be prompted by UAC if they are not administrators. I want to know if there is a hard stop from using this server before we dive in.
Thanks!
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 46%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELF%3C/text%3E%3C/svg%3E)
We have a new Server 2022 Print environment and are currently seeing an issue where all users are being prompted regularly to update the drivers and because they are not administrators UAC stops them from printing.
We have implemented the GPO which should isolate that server as being trusted to install print drivers from but it's not working as expected and we are stuck. Does anyone have any experience with this issue as a google search hasn't brought much back on this problem.
Thanks
@Louis Frazer
The policy with your server names does not override the requirement that the user on the client system needs to have administrative access in order to install the software from the server.
Did you wish to allow the software from the server to be installed by standard users? That's a different policy. You can add a registry setting on the clients also.
This issue does not impact out 2019 Print server estate though where by installing the drivers once as an admin appears to work.
Since moving to Server 2022 we've done this but the drivers regularly reports as "Needing updated Driver" to which it goes to the server to get the update. As this is the standard user trying to do this it prompts for UAC. This is causing many support tickets and with a large user base we can't be expected to put Admin credentials in for every instance of this.
Looking for a fix to this and an understanding why 2022 Print Queues act differently to 2019.
Hopefully as shown in the screen shot from the GPO we've changed the Security Prompts to not show a warning or elevation.
We have this printer driver prompt issue (more like new behavior) before we moved to Server 2022. It's a behavior by design. What we did during the transition is created a registry key to temporarily allow users to install the driver of the printer during the transition, and remove it when they were done. We did this by batch of departments. After the project was done, we closed the registry so we are back to the protection that Microsoft wants. By the way, we are using HP Universal Print drivers for all our HP printers. So once it is installed on the computer, the other printers won't ask again the users even if we close the registry.
On the other hand, the issue we had when we put up Server 2022 is we discovered that the spool folder was getting filled up. It was supposed to clear after the job is out. In our case, we, later on, found out, we have thousands of files in the folder. To fix it, we re-applied the security permissions on the folder. After that, they clear automatically.
Thank you for your response on this one.
So we have gone the other method and installed the driver via an admin credential. However we are regularly being prompted to re-install the driver as it reports on the queue as requiring a Driver Update.
I feel there is something about our 2022 environment that is regularly making changes to the queues and leaving us in this issue.
What driver are you using? In our case, fortunately, we do not see that behavior but probably because we are using universal print drivers. Perhaps that's the difference. Once the driver is installed on the computer (with the help of Admins after UAC prompt) the user is no longer prompted regularly. I would double-check your Group Policy and make sure that your server name is on the trusted list for the print server. I forgot the exact GPO but related to this https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/point-print-restrictions-policies-ignored
If you are not using a universal print driver and are using different drivers for many printers on your print server, that would make sense.
I have not installed this version but the test team where I work now have set up the system as a print server and signed off on this version.
I do not expect many changes to the Print system on the server. Most of the recent spooler changes have been in the client spooler components.
That policy is ignored now unless the client user is admin on the system.
I don't know what the behavior is when setting the policy to allow standard user to install the software from the print server
Print Nightmare KB removed the ability for standard Users to install drivers without elevations. This is also failure for Cyber Essentials + accreditation so the work arounds provided by MS are to install the driver as an Admin or Trust specific identified servers to allow print drivers to install without Admin Privileges. If this has changed it's not obvious anywhere in any guidance online.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(147.20000000000002, 96%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMJ%3C/text%3E%3C/svg%3E)
My understanding and experience is that V4 drivers and IPP drivers allow the standard user to install them if the GP permits it. printer drivers prior to V4 still require Admin credentials. This part is DIFFERENT from the issue being discussed where an admin can install the drivers and the user can print to the printer for a few days then randomly the PC is asking for a new driver to be installed. This is happening to us, now that I moved all my printers to an Azure VM print server. Even worse is that using admin crdentials does not always allow this to get fixed. I have literally had to recreate printers on the print server and use different drivers to be able to get the user to print. This is certainly a bug. Anyone have any additional suggestions? This is getting very old very fast.
Check the C:\Windows\inf\setupapi.dev.log file on the client for the mismatched file. This will absolutely occur when the print server gets an update to core drivers like unidrv and ps5 dlls. The clients will not be able to print. If the driver you use updates some config or data file on the server, this does cause the driver update needed code. Track down which file is the root of the issue. Also confirm the ChangeID registry key is actually different between client and server.
Any change in the files on the server, or mismatch of the files on the client, will trigger the prompt to update driver and this will block printing.
I have no idea why you see this more with Server 2022.
There is a registry key on the server and the client and these need to be the same or the client will go into the update needed state. When the client does not need to elevate priviledges to install the software and the policy above is configured not to let the user know about the new software, then the files will be updated silently and not interupt print tasks.
Are you aware what reg key specifically you're referring to here? I read a thread from many years ago which points to:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers
However when a Print Queue is added which is hosted from a Print Server this doesn't appear in this location. Any advice on where in the registry this would show? Surely its a Current User Key not a Local Machine key?
