How to Add Printers with PowerShell

Posted by Kris Powell

Jul 24, 2014 2:17:00 PM


Nobody likes to manually install printers. This is not fun. People who tell you otherwise are probably, in fact, lying mistaken and must enjoy busy work.

Want to know something that’s definitely more fun? Hiking. Hiking is awesome. But also, installing printers remotely from the comfort of your workstation is awesome.  

Now that we’ve established that, let’s move on to the fun!

(Windows 8.1 / Server 2012 R2 Users: those of you who are using either of these operating systems can follow this link for even more amazing cmdlets in Powershell that make printer management even more of a breeze!)

As for the rest of us, we’ll have to make due with what we’ve got.


  • A printer to install
  • Drivers for above printer

Here is the code. A lot of this may be self-explanatory, but I’m going to explain anyway:

#  Change these values to the appropriate values in your environment.
$PrinterIP = ""
$PrinterPort = "9100"
$PrinterPortName = "IP_" + $PrinterIP
$DriverName = "KONICA MINOLTA bizhub C35P PS"
$DriverPath = "\\UNC_Path\To\My\Drivers"
$DriverInf = "\\UNC_Path\To\My\Drivers\KOBJQA__.inf"
$PrinterCaption = "Konica Minolta C35P"

### ComputerList Option 1 ###
# $ComputerList = @("lana", "lisaburger")

### ComputerList Option 2 ###
# $ComputerList = @()

# Import-Csv "C:\Software\Scripts\Powershell\ComputersThatNeedPrinters.csv" | % {$ComputerList += $_.Computer}

Function InstallPrinterDriver {
Param ($DriverName, $DriverPath, $DriverInf, $ComputerName)
$wmi = [wmiclass]"\\$ComputerName\Root\cimv2:Win32_PrinterDriver"
$wmi.psbase.scope.options.enablePrivileges = $true
$wmi.psbase.Scope.Options.Impersonation = [System.Management.ImpersonationLevel]::Impersonate
$Driver = $wmi.CreateInstance()
$Driver.Name = $DriverName
$Driver.DriverPath = $DriverPath
$Driver.InfName = $DriverInf

Function CreatePrinter {
param ($PrinterCaption, $PrinterPortName, $DriverName, $ComputerName)
$Printer = ([WMIClass]"\\$ComputerName\Root\cimv2:Win32_Printer").CreateInstance()
$Printer.Caption = $PrinterCaption
$Printer.DriverName = $DriverName
$Printer.PortName = $PrinterPortName
$Printer.DeviceID = $PrinterCaption
foreach ($computer in $ComputerList) {
CreatePrinterPort -PrinterIP $PrinterIP -PrinterPort $PrinterPort -PrinterPortName $PrinterPortName -ComputerName $computerInstallPrinterDriver -DriverName $DriverName -DriverPath $DriverPath -DriverInf $DriverInf -ComputerName $computerCreatePrinter -PrinterPortName $PrinterPortName -DriverName $DriverName -PrinterCaption $PrinterCaption -ComputerName $computer


PrinterIP - IP Address of the Printer.

PrinterPort - Port of the printer.

PrinterPortName - Name of the printer port.  IP_<IP Address> is standard for TCP/IP port

DriverName - This is the name of the printer as it appears in the *.inf file (case sensitive).

DriverPath - This is the directory where the printer’s install *.inf file is found.

DriverInf - Full path and file name of the *.inf file.

PrinterCaption - Name of printer as it will appear on the workstation.

ComputerList - Names of the computers you wish to install the printer on.  Choose Option 1 or Option 2

(If you decide to use Option 2 to import from a .csv file to populate the computers, please change the highlighted word to the appropriate name of the header in your .csv file.  My .csv file (ComputersThatNeedPrinters.csv)  has a column header named “Computer”)

Import-Csv "C:\Software\Scripts\Powershell\ComputersThatNeedPrinters.csv" | % {$ComputerList += $_.Computer}

A pastebin of the previous code can be found here.
Read More

PDQ Deploy and Spiceworks

Posted by Shane Corellian

Jul 23, 2014 9:00:00 AM


Did you know that you can use Spiceworks' inventory as a target source in PDQ Deploy?

Yep. You can choose targets to deploy software to based on Active Directory (OU's and Security Groups), PDQ Inventory (Collections), Target Lists (text or .csv files) and Spiceworks' Asset Groups.

In order to integrate PDQ Deploy with Spiceworks you will need the following:

  • A running Spiceworks environment
  • A Spiceworks User Account with "Admin" Access.
  • PDQ Deploy

spiceworks-logo-standardPDQ Deploy and Spiceworks do NOT have to be installed on the same machine. You can also integrate with Spiceworks in the free version of PDQ Deploy.

If you already have your Spiceworks environment up and running the open the Preferences window in PDQ Deploy (File > Preferences). Go to the Spiceworks panel. Configure the Spiceworks connection accordingly. You will need to use the appropriate server name (the server running Spiceworks) and the appropriate port. 

The email field needs to be a Spiceworks account that has Admin access. See the video below for a demonstration on setting up and using PDQ Deploy with Spiceworks.




**Note** If you have many computers in your Spiceworks database then loading the Targets window can take a long time. Here is a great How-To in the Spiceworks community on how you can speed up Spiceworks. Note that steps 2 and 3 seem to make a big difference.


Read More

Dear Oracle, Dear Ask

Posted by JJ Bateman

Jul 22, 2014 4:12:00 PM

If you've ever seen Mean Girls, you'll remember Gretchen Weiners' futile resolve to subtly inject the word "fetch" into the group's vernacular. After numerous attempts, Regina finally has enough, and squashes Gretchen's hopes. 


That's how we feel about the online installer of Java trying to get you to install the Ask Toolbar on your machine. (our Java packages DO NOT have Ask Toolbar bundled). Inspired by this reddit post, I decided to write open letters to both Oracle and Ask. 

Before I begin, I'd like to take a moment to announce that our Ask Toolbar uninstaller package no longer requires Pro Mode and is now free for any sysadmin to download and deploy. Use PDQ Deploy to remove Ask from your infected target machines.

Alright, here we go. 

Dear Oracle,
Please stop. Stop trying to make the Ask Toolbar happen. Java is perfectly fine without it. Consumers of Java applets are fine without it. Old people who call their tech savvy grandchildren to remove this red-circle-'Ask' thing from their homepage are especially fine without it. Go back to the days when your runtime was just a runtime, and not packaged with bloat. You can amend your ways. We hope you do.

Dear Ask Toolbar,
If you were an actual person, I'd protect and defend you from the bullying and taunting you so deserve. But you're not a person, you are a bane of society, a wart on the tech community, and you certainly don't warrant any sort of defending, whatsoever. Go away. Go away and never return. If you're a developer or a project manager for the Ask Toolbar, the Ask Partner Network, or whatever your department calls it self: quit. Please. You can find a better job. For reference, a better job includes janitor work, MLM salesperson, Ask Toolbar ex-employee support group leader. Anything. Until then, Admin Arsenal will do everything to make sure that your abysmal loatheware stays as far away from our users' machines as possible.


Dear blog reader,
If you haven't seen Mean Girls yet, and you enjoy the comedy of Tina Fey, then I recommend watching it.

Read More

Topics: ask toolbar, malware

100,000 Downloads of PDQ Deploy

Posted by Annalisa Williams

Jul 21, 2014 9:00:00 AM


We at Admin Arsenal are thrilled to announce that since it's first release PDQ Deploy has been downloaded by 100,000 sys admins around the world! 100,000 Windows sys admins can't be wrong, can they? 

Here are a few thoughts from the founding members of Admin Arsenal responsible for releasing the first download of PDQ Deploy in 2010.

"With all the talk of mobile and cloud, desktops still play the central role in 

Shawn-pose-01-small[1]business computing.

Unlike a consumer app where a single download might apply to one or two computers, our users are IT admins and they support hundreds even thousands of computers. These 100,000 downloads mean that PDQ Deploy has been used to install apps on millions of Windows computers. When employees get to work they don't sit at their desk and start working on their phones. They log into their desktop or laptop and start working. 

We're very pleased with this accomplishment."

-Shawn Anderson, CEO/Co-founder



"This is a great milestone, hitting six figures. It doesn't seem that long ago that we got our first download. It's been a fun ride and I'm looking forward to the next 100k."

-Adam Ruth, Co-founder/Application Developer




“100,000 thank yous for trying out PDQ Deploy.”

 -Gwen Hilyard, Technical Manager





"Wow. People actually use this software?"

-Shane Corellian, Co-founder/Design & Support 

From the whole team here at Admin Arsenal, thank you!

Read More

Topics: Announcements

Powershell: How to Write Your First Powershell Script

Posted by Kris Powell

Jul 17, 2014 1:32:00 PM

“I love spending twice as long and working twice as hard to get half as much done!”  – Nobody ever.kris-151

Everybody loves shortcuts and time savers.  I think this goes twofold for the aggravation that comes with managing computers.

Enter Powershell!

Though there are many great scripting languages out there, we're going to spend our time with Powershell. If you're using a recent version of Microsoft Windows, you've even probably already got a version of it installed.  

Powershell saves scripts in the .ps1 format.  I have created both a file and a folder for our demonstration - C:\Scripts\My First Script.ps1 - but please feel free to use your own custom folder and filenames.

Edit your file and add the following line:

Write-Host “Hello, World!”

Save the file and return to the Powershell window. In order to run the script, the most common method is by calling it:

& “C:\Scripts\My First Script.ps1”

Go ahead and try that command.  You should get an error that says scripts have been disabled on your system.

This is normal behavior. In order to prevent malicious scripts from running on your system, Powershell enforces an execution policy.  There are 4 execution policies you can use:

  • Restricted – Scripts won't run.  Period. (Default setting)

  • RemoteSigned – Locally-created scripts will run. Scripts that were created on another machine will not run unless they are signed by a trusted publisher.

  • AllSigned – Scripts will only run if signed by a trusted publisher (including locally-created scripts).

  • Unrestricted – All scripts will run regardless of who created them and whether or not they are signed.

In order to use our newly-created script, we will have to modify our execution policy to allow our script to run.  Since we have not digitally signed our new script, our options for setting the execution policy are left to “RemoteSigned” and “Unrestricted.”  We are going to change it to RemoteSigned.

In order to change the execution policy, we will need to reopen Powershell as an Administrator (the command will fail otherwise) and run the following command:

Set-ExecutionPolicy RemoteSigned

It will ask to verify that you really want to change the execution policy. Go ahead and select Y for yes, then go ahead and close and reopen your Powershell window.

After restarting the Powershell window, go ahead and try running that script again 

& “C:\Scripts\My First Script.ps1”

It should write back, “Hello, World!” to the window:

Congratulations!  You just wrote your first script for Powershell!    

As this blog series continues, we'll continue to add more helpful tips on how to use Powershell.  In the meantime, you know have the amazing power to create and run your own scripts.

Tune in next week for more scripting adventures.

Read More

Topics: powershell

Locating Large PST Files in Two Steps

Posted by Annalisa Williams

Jul 3, 2014 8:30:00 AM

Big files taking up too much space? One file type you can target for attention is the PST file created by Outlook. PST files can grow extensively in the hands of email hoarders. (At least they're not printing out every email they get anymore, right?)  

To find which computers have large PST files (or really, any large files) you can set up scans and reports to help you locate those computer that have these large files and see exactly where they're located. 

Now, you'll need PDQ Inventory Pro features to use all of these steps. Not to worry if you don't currently have Pro mode (or higher) you can get a free trial key for PDQ Inventory Pro. (Download PDQ Inventory first here.)

1. Set up a Scan Profile 

Go to File>Preferences>Scan Profiles>Add, then give it a name and description. Next Add a File scan profile. You may either specify the C: disk or you can scan all disks and all sub directories. Use your judgment as to where you would like the scanner to search. The more disks and directories you scan, the longer it will take you to get scan results.

In file patterns enter: *.pst, or any other substitute for the file of your choice, or add multiple file patterns (one per line) to search for multiple file types. Click OK and your scan will be underway.

2. Set up a Report 

Once you've allowed the scan time to complete, you'll need to build a report to view the data. Go to  Report>New Report>Basic. Make sure you're in the Design screen. Here you'll name your report and give it a description. The first tab will be Columns where you will specify the information you would like to display. We would suggest the following:


Then under the filters tab, create two filters. One for files containing .pst and one for files greater than (in this case) 50000000 bytes. 


Now you're ready to run the report which will let you know which computers and where on those computers files are located.

You can also watch this video tutorial below which follows these steps. 


Read More

Topics: PDQ Inventory Pro

Silently Uninstall Microsoft Office 2007

Posted by Shane Corellian

Jun 24, 2014 10:00:00 AM

Note: this post follows the process for silently uninstalling Microsoft Office Professional Plus 2007, although a similar procedure could be followed for other versions of Office. Be mindful of differences in paths and IDs between versions of Office. 


Utilizing PDQ Deploy you can deploy a command (with accompanying XML file) to silently uninstall Microsoft Office from any of your computers. 

Create a new package in PDQ Deploy, (delete the default install step) and add a command step. The command should look like this (for Office Professional Plus 2007): 

"%CommonProgramFiles%\Microsoft Shared\OFFICE12\Office Setup Control\setup.exe" /uninstall PROPLUS / dll OSETUP.DLL /config %CD%\config.xml

Where the config.xml is a file you will provide for the silent uninstall. In this example, for MS Office Professional Plus 2007 it will look like this (modify to fit the needs of the version of office that suits your needs). 

<Configuration Product="PROPLUS">
<Display Level="none" CompleteNotice="no" SuppressModal="yes" AcceptEula="yes" />
<Setting Id="SETUP_REBOOT" Value="Never" />

This bit of XML will not show the UI or a completion notice and will accept the End-User License Agreement. It will also not reboot the computer, however you may want to schedule a reboot at a time that won't inconvience your end-user. (See how to schedule a reboot step using PDQ Deploy.) Again, PROPLUS is necessary to indicate the edition of Office, take care to make sure you have the correct product ID before deployment. 

Since we are using the %CD% variable, we need to add the XML file. Add the path to the XML file in the "Additional Files" section provided. 

After you save and exit the package building screen, you are now ready to deploy.



Read More

Topics: microsoft office

Silently Disable Java Auto Update on All Computers

Posted by Shane Corellian

Jun 19, 2014 10:24:00 AM

Hey sysdmins, do you still have computers in your company that have Java Auto Update enabled? Well, worry not. We'll show you how you can A) use PDQ Inventory to find the computers that have it enabled and B) use PDQ Deploy to disable Java Auto Update.

In order to perform all of these steps you'll need to have PDQ Inventory and PDQ Deploy both running in Pro mode or higher. (You can get a free trial of PDQ Inventory and PDQ Deploy.)

Oracle stores the Auto Update configuration in the Windows Registry. This means we need to scan the registries on our Windows computers.

Step One: Add two Registry scanners to a new or existing Scan Profile. In this example, we use the existing Applications scan profile.

Go to File > Preferences > Scan Profiles in PDQ Inventory. Double click on Applications. Click the Add button and select Registry. Use the HKEY_LOCAL_MACHINE Hive and enter the following for the path:



Save the scanner. Add another Registry scanner and use this path (for 64-bit Windows):

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy

Click OK. If you added these scanners to the Applications scan profile it would look like this:


Close the Scan Profile and Preferences windows.

Scan your computers using the scan profile containing the new Registry scanners.

Step Two: Create a new Dynamic Collection

For this example, we used the default Group Filter (All) and created 4 Value Filters. See image.



As long as you have scanned your computers with the Scan Profile you created / modifed above any computer that has Java Auto Update enabled will now be a member of this collection.

Use PDQ Deploy to Delete the Java Update Registry Key

In PDQ Deploy create a new Package. Add two new Command steps. Delete the default Install Step. 

The command for the first step should be:

%SystemRoot%\System32\Reg.exe DELETE "HKLM\SOFTWARE\JavaSoft\Java Update" /f

The command for the second step should be:

%SystemRoot%\System32\Reg.exe DELETE "HKLM\SOFTWARE\Wow6432Node\JavaSoft\Java Update" /f

On the first step go to the Conditions tab. Change the Arcitecture condition to 32-bit. On the second step change the Architecture condition to 64-bit


Now you can deploy this package to the computers in your Java Auto Update collection. View the video below to see an example of accomplishing these tasks. Note that the video also shows how you can create a PDQ Inventory Report as well as a collection. 

You can watch a tutorial that follows these steps on disabling java update below. Just click play to see all three parts played in order.


Read More

Topics: java

Use PDQ Inventory to Install .NET 4

Posted by Shane Corellian

Jun 13, 2014 10:27:05 AM

With the new release of PDQ Inventory 3.1 a new requirement is having .NET 4 or higher on all target computers. Past versions of PDQ Inventory required that all targets had .NET 3.5. This change means that Windows 8, 8.1 and Server 2012 and 2012 R2 can be scanned out of the box. By default, these new operating systems don't have .NET 3.5 enabled.NET_4_is_not_installed_on_the_target_error

On your Windows 7, 2008 and Vista machines we do recommend that you deploy the latest .NET (current 4.5.2). Installing 4.5x also install .NET 4. 

.NET 4.5x is not available for XP and 2003 so you'll need to stick with version 4 of .NET on these systems.

Download .NET 4

Within PDQ Inventory you can deploy .NET 4 to all computers. Go to File> Preferences> .NET Installation. In this panel you will see a button to download the .NET Framework 4. Click Download .NET Now and your installation will be underway. 

Note: You can use the software deployment tool PDQ Deploy to deploy the latest .NET Framework (which as of this post is .NET 4.5.2) it will still install the .NET 4 libraries and work just fine.

Deploying .NET 4 

After you have downloaded it, you have three options for deploying.

  1. In the same window (File>Preferences>.NET Installation) you can select to Automatically Install .NET. When you select this option, anytime any of your computers are scanned it will update to .NET 4
  2. View computers in the All Computers panel, you may 
  3. NET_Installation_Preferences_Windowsee that some of your computers display a warning that .NET 4 is not installed. Highlight the problem computers and go to Computer>Install .NET and Scan
  4. You can also double-click individual computers, which will bring up a new screen (displays additional information about the computer) and in this screen under File, you will see the same Install .NET and Scan option. 



Read More

Topics: pdq inventory

Scan Caching

Posted by Shane Corellian

Jun 4, 2014 9:21:00 AM

Admin Arsenal has released PDQ Inventory Enterprise, which has a new feature that allows system administrators to pull scan data from a stored cache. Why should you utilize scan caching? Scan caching helps your scans to run quicker and thus does not needlessly bog down PDQ Inventory with too many scans. Scan caching is useful if you have multiple sysadmins who are also running scans. Rather than having a scan run multiple times from different admins, when a scan is run recently, the data is cached and made available to other Enterprise users running scans requiring that data.

This way, instead of running a complete scan your console will already have access to the necessary data.

Setting up Preferences

Scan caching preferences windowUnder File > Preferences > Scanning is where you can turn on scan caching and set your settings for your console. 

Read from Cachethis setting instructs PDQ Inventory to get data from the scan cache if that data is available rather than scanning the computer directly. If you select to Use Cache Exclusively then your user account will not run it's own scans and will only utilize data from the Scan Cache. 

If you would like to place data in the scan cache select Write to CacheWhen you run a scan, if the data in the scan cache isn't already current, the data from your scan will be made available in the cache. 

Now, how frequently do you want the scan cache updated? The Scan Age setting allows you control over scan frequency. This setting tells the console to check the scan cache and if the data in the scan cache is older than what is specified in Scan Age, then run the scan.

If you set your scan age to one day and if in the scan cache there is data older than one day, then the scan will be run. For example, if there is data from 2 hours ago, then the console will not scan but will retrieve the data available in the scan cache. 

You need to specify the directory where the scan data will be stored and all Enterprise users who will be utilizing the scan cache data must specify the same directory. You set this in the path field. This must be a shared UNC path. 

Things to Note 

Scan caching does not automatically add computers. When you run a scan and retrieve information from the scan cache, you will only get information for computers you've added in PDQ Inventory. (See video on adding computers to PDQ Inventory) 

In PDQ Inventory Enterprise, you may notice that shared collections and reports are only run against computers you have added. Getting this data shared by other PDQ Inventory Enterprise users within your group only runs and displays your computers, it will not display information for their computers. If you want to see data for those computer, you need to add those computers to your console. 

Read More

Admin Arsenal Blog

Subscribe to Email Updates