If such an application in your service desk system causes a twitching eye and a drop in tone, then you probably have not yet set up a convenient centralized management of printers. It is time to correct this discrepancy.

The article is more likely for those who do not have this spherical corporate in a vacuum, with virtual printers, attaching a print pass to the HP M8xx, or even Ricoh Pro 8xxx. As usual, we stock up on scripts, GPO and once again scripts.

We collect printers in one point of connection

As a first measure to make life easier, I recommend having a print server where you can deploy all the printers in your organization. Ideally, this is a separate virtual machine, where all printers are networked and displayed in a separate VLAN with access only from the print server. If it is impossible to use a network printer, then as a last resort it is possible to turn a computer with a USB \ LPT printer into a print server. For example, using the rawprintserver utility.

In addition to the ease of maintenance, the configuration with a single print server will allow you to easily implement “knee-shaped” print reports by disassembling the Microsoft-Windows-PrintService / Operational magazine. I hope that with the solution of this problem will help our material “ Verify logs as we want - analysis of logs in Windows systems” , and as an example I will offer the following PowerShell script:

$events = Get-WinEvent -FilterHashtable @{LogName = "Microsoft-Windows-PrintService/Operational"; ID = 307} | foreach{ New-Object PSobject -Property @{ Time_Created = $_.TimeCreated Document_Number = $_.Properties[0].value Document_Name = $_.Properties[1].value UserID = $_.Properties[2].value Printer = $_.Properties[4].value PagesCount = $_.Properties[7].value } } $events | select userid, printer ,pagescount 

The result of the script.

In addition, it is possible to do some work on optimizing the speed of a single print server, merging printers into a cluster. In general, have fun whatever you like - at least monitor the printers via SNMP and notify employees in advance about the ending cartridges.

Let's move on to connecting printers to users: the options are intricate and not very.

We connect printers at the entrance

Using logon scripts is an old and proven tool that works always and everywhere. When a user logs in, a script is triggered that connects the desired printer and sets it by default - everything is simple and stable. On cmd, the script will be:

 rundll32 printui.dll,PrintUIEntry /in /n\\servername\printername /y 

You can read more about the cmd command for working with printers in the Microsoft documentation .

Lovers of vbs will have to use objects, and the printer connection will look like this:

 On Error Resume Next Set WshNetwork = CreateObject("WScript.Network") WshNetwork.AddWindowsPrinterConnection "\\servername\printername" WshNetwork.SetDefaultPrinter "\\servername\printername" 

Similarly, the problem is solved on PowerShell:

 $net = new-object -com wscript.network $net.AddWindowsPrinterConnection("\\servername\printername") $net.SetDefaultPrinter("\\servername\printername") 

You can read about the features of the Wscript.Network com-interface in TechNet's WshNetwork Object , and about managing printers with PowerShell in the documentation of PowerShell Working with Printers .

If everything is straightforward with a printer connection, as long as the driver is on the computer, then selectively connecting printers will require architectural keenness. Let me give you a couple of options that met in the vast admin activities.

Each printer has its own security group. Only she is allowed to print on the printer in its properties. Each security group has its own logon script and its own group policy with a security filter.

Need more group policies.

The option is not bad, but when you add a new printer, you have to create a new security group, a new group policy, and a new script to connect. Of course, this can be automated not without the help of our material “Immersion in templates and taming Windows GPO ”, but the solution still looks far from elegant.

Another option is to create a single script that checks any attribute of a user or computer and, depending on it, connects the desired printer. The attribute can be a location, a description, or even membership in a security group.

The correspondence between the attribute and the name of the printer is either hard-coded in the body of the script, or is written in an external data source, such as a text file or even a SQL table. This option is slightly easier to maintain - in which case you need to edit only one script or an external data source.

 Set WshShell = WScript.CreateObject("WScript.Shell") Set objSysInfo = CreateObject("ADSystemInfo") strComputer = "." Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") strUserDN = objSysInfo.userName Set UserObj = GetObject("LDAP://" & strUserDN) '      ' iGroup = 0 For Each GroupObj In UserObj.Groups iGroup = iGroup + 1 Redim Preserve strArrayUserGroups(iGroup) strArrayUserGroups(iGroup) = Replace(GroupObj.Name, "CN=", "") Next '    ' For i = 1 To iGroup AddPrintersByGroup strArrayUserGroups(i) Next Function AddPrintersByGroup (strGroup) Set WshNetwork = CreateObject("WScript.Network") Select Case strGroup Case "Add Printer HP2055BUH2" WshNetwork.AddWindowsPrinterConnection "\\servername\HP2055BUH2" WshNetwork.SetDefaultPrinter "\\servername\HP2055BUH2" Case "Add Printer HP2055HR" WshNetwork.AddWindowsPrinterConnection "\\servername\HP2055HR" WshNetwork.SetDefaultPrinter "\\servername\HP2055HR" ... End Select End Function 

Better policies for connecting printers can only be other policies

With the advent of Group Policy Preferences or group policy preferences, it has become possible to do without scripts at all. Indeed, the connection to printers can be configured in the section “User Configuration - Settings - Control Panel - Printers”.

Connect to a new or old printer.

It is not necessary to set policies on the number of printers in the domain using the Targeting tool on the General Settings tab. In fact, this tool resembles wmi-filters in group policy, only it has previously created a ready-made set of options besides filters.

Possible targeting options.

A good option would be to configure the filter by security group. Then it will be enough to create the required number of security groups, configure permissions to printers on the print server, and bring these printers into the group policy.

When automating add-changes, you can use the fact that the group policy preferences settings themselves are located in the Group Policy folder in the Preference subfolder. In the case of printers, this will be the xml file Printers.xml in the subfolder Printers.

The physical location of the printer settings.

If you open it, you can see that the xml structure is quite simple:

 <?xml version="1.0" encoding="utf-8"?> <Printers clsid="{1F577D12-3D1B-471e-A1B7-060317597B9C}"> <SharedPrinter clsid="{9A5E9697-9095-436d-A0EE-4D128FDFBCE5}" name="HP2055BUH2" status="HP2055BUH2" image="2" bypassErrors="1" changed="2018-03-21 13:47:25" uid="{9E6F08F9-1C6B-49EB-A985-25A722ADD9C1}"> <Properties action="U" comment="" path="\\servername\HP2055BUH2" location="" default="0" skipLocal="0" deleteAll="0" persistent="0" deleteMaps="0" port=""/> <Filters> <FilterGroup name="Domainname\Printer_Add_2055_Buh" localGroup="0" primaryGroup="0" userContext="1" sid="" not="0" bool="AND"/> </Filters> </SharedPrinter> </Printers> 

And if you want, you can carefully add \ change parameters manually or by scripts. Of course, reinventing the wheel and crawling with unwashed hands in xml is fun and entertaining, but it is not necessary at all - in the TechNet script gallery there is already a ready-made Add-Printer-IN-GPO script that will add printers to group policy targeting security groups.

At the end of the article I will tell you about one interesting way that I once had to implement.

In the piggy bank of strange ways to connect - scheduled tasks

The customer received a task - to create a tool to automatically connect printers to the user. At the same time, the reaction time should be minimal and no relogs are unacceptable, so the classic options like logon scripts and group policies immediately shallow.

The nuance was that users worked on terminal servers in the farm and without a farm. Needle on fiction is tricky, so I had to remember possible options for running commands on a remote computer under different sessions - some of the options are described in our article “1000 ++ way to run commands on a remote computer ”. The best was the option with assigned tasks.

Since I love batch files and use them when I can do without using PowerShell, I used only cmd to solve the problem.

The main problem was the need to run commands to connect the printer directly to the user's session, and not knowing his password, the usual methods are not very effective. Just for this, I used the opportunity to set the username when creating a scheduled task with this command:

 schtasks /create /S computername /SC ONCE /ST 00:00 /RU domain\username /TN taskname /tr "rundll32 printui.dll,PrintUIEntry /in /nPrintername" 

The second problem was to find the computer on which the user is working at the time of the call. I used the qwinsta utility and a list of possible computers in a text file. Of course, there are other ways - for example, taking the name of a computer from an Active Directory attribute or from a text file. But this procedure will require additional logon scripts. As an example of implementation, I can advise how to:

As a result, a script appeared that takes the name of the user and the connected printer as a parameter. Next to the script you need to put a text file with a list of servers on which the user can work.

 @echo off rem     ... for /F %%i in (servers.txt) do ( rem    qwinsta /SERVER %%i | find "%1" && call :subroutine %%i %1 %2 ) GOTO :EOF :subroutine rem C   schtasks /create /S %1 /SC ONCE /ST 00:00 /RU domain\%2 /TN printer_%2 /tr "rundll32 printui.dll,PrintUIEntry /in /n%3" rem   schtasks /run /S %1 /TN printer_%2 rem   schtasks /delete /S %1 /TN printer_%2 /F GOTO :EOF 

Of course, there are companies where users themselves are able to connect to the desired printer, select it by default and not pull the IT service for this. Unfortunately, not all are so advanced.

I suggest in the comments to share how things are with network printers and their management in your organizations.