Saturday, 12 April 2025

On-premises printing with cloud native devices

In the past year my colleagues and I have helped many customers to prepare their environments for cloud native devices. 

What is a cloud native device? It's a device where all management is provided by the cloud. In the Microsoft world this means a device which is Entra joined and enrolled in Intune. The key here is the authentication. The device must authenticate with Entra. Entra hybrid devices authenticate with Active Directory so they do not qualify as cloud native devices.

Printing is usually one of the challenges organizations face. Often Group Policy Objects have traditionally been used to control access to printers. By default non-administrators are not allowed to install drivers on domain joined devices. This can be managed by allowing users to install driver packages for the classes below, all configured by GPO:

  • {4658ee7e-f050-11d1-b6bd-00c04fa372a7}
  • {4d36e979-e325-11ce-bfc1-08002be10318}
All the users need to do is browse to the print server and double click the printer to add the queue without any elevation.

GPOs are not applied to Entra devices so we need to find another way to deal with printers using Intune. I know, I know we should be using Universal Printing. However many customers have heavy investments in on-premises printing and we need to help them rather than tell them that they are wrong.

There is an equivalent Intune configuration policy where we can allow users to install drivers for the same classes above. However I don't want users to install drivers at all. I want to pre-install all the necessary print drivers to make the device as secure as possible. It's pretty straightforward and involves a couple of scripts. 

Disclaimer: I'm not a master scripter. The scripts don't contain any error checking. However they are functional and they work well. No complaints please 😏😏😏

I've picked an example printer that I worked with recently.


The Canon Image Runner Advanced C256i is a big old expensive printer and was one of the models used by a recent customer. The customer provided the print driver.


Tip: you do not need all the files that are downloaded in a bundle from the vendor website. In this case it contained 47.4MB of data.


You just need the drivers. Typically this is a folder containing .inf and .cab files. This one had 17MB of data. You'll notice a few extra files here. We'll come to them shortly.

First we need to check that these files will add the print driver that I need. Open the .inf file to see what is inside. It's called cnnv4_cb3_fgeneric.inf in this example but the name will be different in each case.


I can see that this .inf file is aware of two print drivers

  • Canon Generic LIPSLX V4
  • Canon Generic UFR II V4
Which one do I need? I had a look in the properties of the queue on the print server and could see that I needed "Canon Generic LIPSLX V4". Now I could get started.

The install.cmd file is a simple script that performs the following actions:
  1. Creates a local folder C:\PrinterDrivers\Canon
  2. Copies all the required files to this folder
  3. Adds the print driver using prndrvr.vbs
What is prndrvr.vbs? It's a Visual Basic script native to the operating system which adds, deletes and lists printer drivers. You can read about it here. 

The script uses the following parameters:
  • a: adds a printer
  • m: specifies (by name) the driver you want to install
  • i: specifies the complete path and file name for the driver you want to install
install.cmd script (you'll need to replace the vendor name, the driver name and the inf filename).

@echo off

mkdir C:\PrinterDrivers\Canon
xcopy *.* /h /c /k /e /r /y C:\PrinterDrivers\Canon

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs" -a -m "Canon Generic LIPSLX V4" -i "C:\PrinterDrivers\Canon\cnnv4_cb3_fgeneric.inf"

I'm going to deploy the solution as a Win32 app. Therefore I also need a detection method. I'm using a custom script for that. The script performs the following:
  1. Executes Get-PrinterDriver
  2. Looks for "Canon Generic LIPSLX V4"
  3. Returns an exit code, 0 = success
Detection_Script.ps1

$driverExists = Get-Printerdriver | Where-Object {$_.Name -like "Canon Generic LIPSLX V4"}

if($driverExists) {
  Write-Host "Success"
  Exit 0
} else {
  Exit 1
}

Next job is to create and deploy a Win32 app using Install.cmd as the installation and Detection_Script.ps1 as the custom detection.


This is the result. The correct print driver is pre-installed. You can see a few others there as well as the Canon.

What happens next? Well, now you can just browse to the print server and double click to add the print queue. The driver already exists so you will not be prompted for elevation.

Alternatively you could create an available Win32 app which could be self-installed via Company Portal. Replace with the name of your print server and queue

Add-Printer -ConnectionName \\printserver.domain.local\Canon_Colour

This will work as the installation script.

$printerExists = Get-CimInstance -Class Win32_Printer | Where-Object {$_.Name -like "\\printserver.domain.local\Canon_Colour}

if($printerExists) {
  Write-Host "Success"
  Exit 0
} else {
  Exit 1
}

This will work as the detection script.

Thanks to my colleague Rahul Jindal for reminding me about prndrvr

I hope this helps. Until next time.....



6 comments:

  1. neat solution, but I'm worried about the vbs dependency with deprecation in 2027

    ReplyDelete
  2. This is all great for small businesses but with 900+ printers we have to rely on a third party solution

    ReplyDelete
  3. I am still trying to understand this. On premise print server joined to active directory. Entra AD managed device and Entra ID user.

    How does the printer server allows the authentication from the endpoint/user when they are unknown? If you tried to navigate to the print share from the entra managed device you wouldn't be able to authenticate and read the available printers, right?

    ReplyDelete
    Replies
    1. It works when the UPN is the same and the password is synced, which is the typical Entra Connect scenario. It doesn't work when you configure Windows Hello for Business and use a PIN. However this is solved by implementing Cloud Kerberos Trust.

      Delete
    2. Ah the first part would work if entra ad account was syncing the user. That would indicate a hybrid identity.

      So cloud trust would potentially solve this issue?

      I appreciate your responses.

      Delete
  4. You only need cloud Kerberos trust if you are using WHfB. If you are using UPN and password it just works out of the box.

    ReplyDelete