Installing printers with Intune & PowerShell

On the surface, installing printers on end user devices seems like a fairly simple process that’s been solved for decades – a nice combination of Group Policies and PowerShell has made this a non-issue.

But what if our devices aren’t domain joined?

When I first had to tackle this problem, I figured it would be a simple as running “Add-Printer” as the end user and moving on.

The problem arises however, when the printer requires drivers to be installed – the dreaded administration UAC prompt appears and ruins any chance of getting out of work early!

By default, Windows doesn’t trust printer drivers – It’s understood there are inherent security risks involved in blindly allowing drivers to be installed on your computer and as such, requires admin approval if a device wants to install one.

This issue was previously resolved by clearly defining via the Point and Print Restrictions group policy exactly what servers could be trusted by the devices, which would allow us to suppress any elevation prompts that would invariably appear.

“OK, cool – but can’t I just do that with an Administrative Template via Intune?” I hear you ask…

Here’s the rub – there’s actually two policies you need to define and one of them currently doesn’t appear in the administrative templates available to us in Intune.

No worries though – with PowerShell, we can solve this issue!

Let’s move onto the solution – This will be split up into two segments – Configuring the Point and Print Policies and installing the printers.

Point and Print Policies

As mentioned above, there are actually two policies that need to be configured to allow implicit trust for printer driver installation, the Point and Print Restrictions policy and the Package Point and Print – Approved Servers policy.

We define our restrictions for Point and Print in the PnP Restrictions policy, and then we define our allowed servers for those restrictions to be applied to in the Package PnP Approved Servers policy.

Luckily, both of these policies are quite easy to configure with PowerShell.

First let’s set up how we want to configure the restrictions policy.

This is a simple array of configuration settings – all we are doing is replicating the same settings as shown in the first screenshot of this post.

Now let’s add the configuration of Package PnP – Approved Servers policy to our script..

Now with a little help from a very simple function I’ve created, we can import all of the settings to the registry..

Now if we open up RegEdit on our device, we should see the configuration in the HKLM:\Software\Policies\Microsoft\Windows NT\Printers path.

All we need to do now is deploy the script to our users via Intune, making sure to deploy it as the System to avoid any permissions issues to the registry.

Installing printers with PowerShell

Now that the difficult part is out of the way, let’s move on to installing the printers.

Hopefully you’ve already got all of the print queue names documented (and the names of the printers AND the queues are the same…) – if not, do it now..

Got your printers? ok, great – let’s set them up in an array.

Finally, as in the last section, with the help of a simple function I’ve created for this scenario, we will force the printers to install on the devices. Unlike last time, we don’t need admin access, so we will run this as the user.

The function above isn’t doing anything special – it’s primarily just making sure that we can access the network path and that the printer isn’t already installed. The only cool thing to mention is line 26.

& cscript /noLogo C:\windows\System32\Printing_Admin_Scripts\en-US\prnmngr.vbs -ac -p $printerPath

Windows has come bundled with a bunch of printer administration scripts since Windows 7 and it’s amazing. You can read more about how it works here. These sorts of tools are super handy to know about, as it saves us having to “re-invent the wheel” so to speak.

So that’s it! two scripts – once run as system to configure the device, and one run as user to map the printers.

Full examples of the code referenced in this article is, as always, available on my GitHub, and I can be reached on twitter if you have any questions. I love the distraction!


  1. Mark
    June 1, 2020 at 10:35 pm

    Great blog post and I wasn’t aware of the prnmngr scripts.

  2. Huw Weatherhead
    July 16, 2020 at 8:31 pm

    When running these two scripts from Intune what happens if the second one runs first? I guess it will work when Intune tries for the second time assuming the first script succeeded on the first attempt?

    • Ben
      August 18, 2020 at 1:37 am

      Good question – it will more than likely fail. The use case for the second script is to generally integrate it with a logon script solution, thus it should never run before the first script anyway, as the deployment method would simply be to configure the logon script and place the media where it needs to go.

      • Greig Menzies
        September 2, 2020 at 6:47 pm

        Ben, this article has been extremly helpful for our rollout to Intune, printing was a bugbear for us. How would you best integrate this into a logon script solution via Intune? Thanks for your help

Comments are closed.