PrintNightmare & Point and Print, Part II

UPDATE 1: After further testing with AADJ devices, I’ve found that it seems to work as expected with Package Point and Print settings. Details below.

UPDATE 2: More Package Point and Print details

PrintNightmare, it’s the gift that keeps on giving. After lots of discussion in the WinAdmins community, I’m back with three additional items that I wanted to go over: the impact on Azure AD joined devices, Remote Desktop printer redirection, and V4 printer drivers.

Azure AD Joined (AADJ) Devices

After some discussion in the WinAdmins community, Johannes mentioned that he was seeing the Point and Print settings completely ignored. After a bit of troubleshooting with no changes, I made the realization that he most likely testing things on a AADJ client, because he is way ahead of the curve on moving to modern management 😁. This prompted me to rebuild the two test VMs I had been using previously as AADJ only (as well as fixing my Autopilot configuration and Intune enrollment settings in the process). Here’s what I found:

  • An AADJ device pre-2021-08 CU will install printer drivers from any server, regardless of P&P settings
  • An AADJ device post-2021-08 CU will require admin rights if the new registry item “RestrictDriverInstallationToAdministrators” has not been created, or set to 1
  • An AADJ device post-2021-08 CU will behave like it did pre-CU if the registry item “RestrictDriverInstallationToAdministrators” is set to 0

The conclusion that I’ve come to is that AADJ devices ignore all configured Point and Print policies, which I somewhat understand. Point and Print is a domain-centric configuration. I should note that in my previous testing during my last post, both of my VMs were Hybrid Azure AD joined (HAADJ). It seems that the only solution with AADJ devices is to stop printing completely (good luck with that), implement V4 drivers, or implement Universal Print.

UPDATE 1: After some more testing, I’ve found that AADJ devices work as expected after applying Package Point and Print settings, since I was testing things with package-aware drivers. Unfortunately, I have not been able to get this setting to apply via configuration profile. Setting the registry items manually appears to work, so this could easily be configured in a Proactive Remediation to apply the necessary settings.

UPDATE 2: After applying the 2021-09 LCU (or the 2021-08 preview CU), bringing the OS patch level to .1200 or higher, Package Point and Print settings now work successfully via the Settings Catalog.

Intune Configuration Profile – Settings Catalog Point & Print Settings

The new registry item RestrictDriverInstallationToAdministrators will need to be controlled via Proactive Remediation; there is a working example of this on the WinAdmins GitHub.

2024-03-21 Update: The RestrictDriverInstallationToAdministrators` setting is now configurable via Settings Catalog profile, so no more need for a Remediation!

Remote Desktop Printer Redirection

If you utilize RDP printer redirection in a VDI scenario, so users can print to local printers, based on my quick investigation, you shouldn’t see any issues. Printers redirected via RDP utilize the generic “Remote Desktop Easy Print” driver inside the RPD session, which is included with Windows.

V4 Drivers

V4 drivers, also known as Type 4 drivers, seem to be the ideal solution to this entire problem. Microsoft has a good deal of documentation on V4 drivers here: V4 Printer Drivers, but for a high-level overview:

  • V4 drivers use a model-specific driver on the print server side.
  • When clients connect to a printer on a server using a V4 driver, they do not download any driver. Instead they use a generic preloaded driver named “Microsoft enhanced Point and Print”.
  • Client printer connections using the “Microsoft enhanced Point and Print” driver rely on an external application being installed to provide advanced printer functionality and support.
  • In my testing, on an AADJ client, with the 2021-08 CU installed, and the “RestrictDriverInstallationToAdministrators” registry value not created, all printer connections are blocked except ones using V4 drivers.
Client-side driver used with a V4 printer connection

The downside to V4 drivers is vendor support. My experience with them is specifically with Xerox devices, and they work well. Clients utilize the “Xerox Desktop Print Experience” application to provide advanced functionality, which can be easily deployed via ConfigMgr or Intune. It was mentioned in the WinAdmins Community that Ricoh also supports V4 drivers. As for other vendors, you may need to do some investigation.

I would also recommend doing application-specific testing if you plan to implement V4 drivers. I have run into applications in the past that did not play nice with them for one reason or another. Another issue with V4 drivers is OS inter-op; macOS and Linux clients do not play nice with them.

Universal Print

Universal Print is a relatively new cloud technology by Microsoft that can also be used to get around all of the issues of PrintNightmare. I have zero experience with it, but I wanted to mention it as a potential solution, and something to look at for the future. Microsoft documentation about it can be found here: What is Universal Print?

Related Posts

9 thoughts on “PrintNightmare & Point and Print, Part II

  1. Just starting today, we’re now getting reports from users that print to Xerox printers that are using V4 drivers. When they print, the job fails and they get a print out that says, “this job was not printed because the XPS option is not enabled.”. The printer is installed on 2012 print server with the V4 driver. The client side sees the driver as the Microsoft Enhanced Point and Print. This wasn’t an issue last week. The only way I can get the users to print is to remote control their computer (VNC) and install a printer as a local IP printer, and not use the Print Server at all. Not a great solution for a company with 500 users and hundreds of computers.

  2. I recently found out that at a customer site the Printer driver files timestamps are off by 1 hour, this can also trigger the ‘Update driver” mechanism.
    Drivers were preloaded on the workstations a long time ago, and the version on the server and the workstation was identical except for a timestamp mismatch.
    The cause of the problem was an old 7ZIP bug that changes the timestamp when unpacking the driver files:

    This triggers the mechanism that is described in this bulletin:

    The files being compared are the drivers within the spool folder, usually in C:\Windows\System32\spool\drivers\x64\3 on both the print client and print server. The driver package being offered for installation will usually be in C:\Windows\System32\spool\drivers\x64\PCC on the print server. After the files in the \3 folder are compared between devices, if they do not match, the package in PCC is installed. If the files in the print server’s \3 folder are not from the same printer driver that PCC offers to the client, the print client will compare the files and find the mismatch every time it prints.

    1. I have that exact issue. Great spot. Is it safe to extract the files from the CAB file in the PCC folder and copy them to C:\Windows\System32\spool\drivers\x64\3 (all on the print server)? This should fix the datetime discrepancy, but would it work?

  3. In regard to Type 4 print drivers, I can’t find a Type 4 Universal Print Driver from HP. I’ve tested the Konica Universal Print driver that is Type 4 and many functions don’t work like stapling etc. So not a workable solution for me thus far.

    1. Yep, V4 drivers can be hit and miss, and all dependent on vendor support. I am only really familiar with Xerox myself, and their support for V4 drivers is pretty decent. Have you also installed the Konica Print Experience app? That might be necessary to gain access to more advanced printer functionality in conjunction with a V4 driver.

      1. I haven’t been able to locate a V4 Global Driver for Xerox. Is this something you have found?

Leave a Reply