Add-printer doesn't see the local driver when using -connectionname

PowerShell Help
1

I’m attempting to solve printnighmare and get us off of a third-party solution by using Intune to deploy the printer drivers. This blogpost has been the template I’ve been learning from.

I’ve successfully deployed the drivers themselves by using pnputil to add them to the driverstore. I can confirm this with Get-Printerdriver and pnputil.exe /enum-drivers. But when I try to use add-printer -connectionname to map the printer, I’m given

add-printer : The driver needed to connect to this print share cannot be retrieved from the server and must be manually installed.
At line:1 char:1
+ add-printer -ConnectionName \\server\printer
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Add-Printer], CimException
+ FullyQualifiedErrorId : HRESULT 0x80070bcb,Add-Printer

I’ve tried piping Get-printer into Add-printer to use the -Driverpath parameter. But that forces me to create a port and name which bypasses the print server and maps it via IP address.

I’ve tried using the parameter set with -name for the printer and -computername for the server. This was recommended by bingAI, so I’m not surprised on this one.

I know I’ve tried more than this, but this is already a pretty long post.

Is there anything I can do to point add-printer to the locally installed driver when using the -connectionname parameter set? Is there something obvious I’m missing? Do you have any suggestions on how I can handle this differently?

2

You mentioned print nightmare and one of the mitigations early on was to adjust the permissions on the drivers folder. You don’t happen to have this or other mitigation in place that might be causing the issue? Here is a function I wrote early on when we had locked down the driver folder via GPO. We could run this function and complete the install. We then had another function we could run to lock it back down and if that wasn’t done it would just be applied during the next group policy refresh.

Function Unprotect-DriverFolder {
    [cmdletbinding()]
    Param()
    
    $driverfolder = 'C:\windows\system32\spool\drivers'

    $acl = Get-Acl -Path $driverfolder

    $newsddl = $acl.Sddl -replace '\(D;OICI;DCLC;;;WD\)'

    $acl.SetSecurityDescriptorSddlForm($newsddl)

    try{
        Set-Acl -Path $driverfolder -AclObject $acl -ErrorAction Stop
        Write-Verbose "$driverfolder unprotected successfully"
    }
    catch [System.Management.Automation.RuntimeException] {
        [void](echo Y | cacls.exe $driverfolder /S:"$($newsddl)")
        if($LASTEXITCODE -eq 0){
            Write-Verbose "$driverfolder unprotected successfully"
        }
        else{
            Write-Error "Unable to set ACL: $($_.exception.message)"
        }
    }
    catch{
        Write-Error "Unable to set ACL: $($_.exception.message)"
    }
}
3

Thanks for the reply, Doug. This wasn’t something that I had considered.

Looking at the test machine, C:\windows\system32\spool\drivers is set so that everyone has read/execute permissions.

Just to test, I gave everyone full permissions and attempted to add the printer again. It came back with the same error.