High CPU usage when adding printers

Question

We are working to investigate an issue with adding shared printers from a Windows print server to users on a Remote Desktop Session Host server, both servers are Windows Server 2019. We have an environment where we have to deploy a large number of printers to each person logging in due to them moving around quite a bit in a warehouse environment and needing access to many printers. We are handling printer deployment via GPO. We have tried both a GPO deploying the printers to all users of a given OU as well as another GPO that uses item-level targetting to deploy printers to those who are members of a given security group. The behavior is the same in both scenarios, however.

The situation is that when a new user logs in for the first time, or if we have to deploy a large number of new printers, that CPU usage for any given user spikes up very high for several minutes while the printers are added. Mind you, we pre-seed the drivers on the Remote Desktop Session Host and they are the exact same drivers that are on the print server. We are also only dealing with about 4 different printer driver types (but around 40 printers deployed per user now). What we observe when using a tool like Process Explorer is that many "drvinst.exe" processes will spawn while printers are being added after the user logs in and we also see the print spooler "spoolsv.exe" process spike up and down quite a bit. On top of this, any anti-virus that is installed (have tried with Sophos and Windows Defender) will also spike a lot. We have added printer related exceptions to our anti-virus, but this doesn't seem to matter, but also it doesn't seem to matter if we even disable anti-virus entirely. Even when AV is all removed/disabled, the CPU usage is still very high for the drvinst.exe spawned processes and spoolsv.exe (just not quite as bad, but still very bad). The one plus side is that this only happens on the first login / after adding new printers. Subsequent logins are just fine after the printers are added.

The boiling point happened a few days ago when we had to add 20 new printers for everyone and we rolled them out per usual with a GPO. Once the GPO started refreshing for users and it picked up that there were new printers, it pegged the CPU usage on the server to 100% and made it unusable. After 20-30 minutes, we had to abandon and kill the spoolsv.exe process just to get the server settled down. We rolled back the GPO printer deployment before restarting the print spooler. Needless to say, this caused a major problem with the warehouse operations and stopped work for a while until this was fixed. The server only had a small handful of people on it at the time, too.

My big question is--why is some driver install process spawning for adding each printer when the driver is already there? Are we possibly doing something wrong with adding the new printers that causes it to overwork this drvinst.exe process with each printer addition for each user? I don't feel like adding new printers should be an affair that kills the processor when the driver already exists on the print server and the Remote Desktop Session Host. I need some insight if there is something else that I can do to alleviate this behavior, or if not to have it confirmed to me that this is expected behavior that we have to deal with.

Thanks.

Answer 1

I found what the issue was. It was related to the "Packaged" setting of the driver and whether it was true or false for one given printer driver. We had one specific model of Zebra printer of which there are about 30 different printers of the exact same model that are installed for each user. Typically when we seed the drivers on a server that someone works from in a Remote Desktop Session Host environment, we Install the printer and driver first on the print server, then we browse to the print server as an admin from the RDSH server and seed the driver by installing the printer from the share on the print server once so we can get the driver pulled over from the print server (we block users from installing drivers, so an admin needs to seed the driver initially on the servers).

The behavior that we found, and it seemed to only be happening with this Zebra print driver, was that it was changing the "Packaged" flag on the driver from true (on the print server it was true) to be false on the Remote Desktop Session Host servers when we seeded the driver like this. Mind you, other different printers didn't seem to exhibit this behavior when seeding the driver from the print server by browsing to the print server as an admin and adding the printer once for a particular given printer model / driver. When I removed the print driver from the RDSH servers that was seeded like this and then manually re-added the driver back to the server via using the extracted source drivers (the same ones I used to set up the printer and drivers initially on the print server), the flag was changed back to true for the "Packaged" setting so that it was now true both on the print server and the RDSH servers.

After making this change, the 50+ printers being added to new users logging in went from taking about 4 minutes and using far more CPU cycles went down to taking about 20-40 seconds, depending on other variables. The higher CPU spike is still there during the GPO phase where printers are being added, which is expected for adding that many printers, but at least now it's getting the printers added much more quickly and is less disruptive to the server.

Answer 2

hi ,
did you install printer driver on your client or on the server? here is a thinking of the compatibility between printer driver and server version.
and you can have a check if there is known issue and hotfix in this version.
and also recommand you try to update the printer driver to the latest.

Answer 3

Hi,

only as additional information regarding your question "why is some driver install process spawning for adding each printer when the driver is already there?"

Imagine the following scenario. Example : You have installed HP Printer Driver 1111, 2222, 3333 on your Server and your clients already got these drivers. If you now install later HP Printer Driver 4444 the shared components between these printer drivers gets updated again and your client will get all the drivers for HP Printer Driver 1111, 2222, 3333 again.

Vendors which are using shared components between different models of printers replaces the shared components even if it is the same version. The spooler detects these changes and retrieves the driver again.

Installing all the drivers at once could solve your problem.

Regards,
Cengiz Kuskaya