PDQ Inventory 12 is Now in Beta

Posted on Leave a commentPosted in Uncategorized

PDQ Inventory 12 is now in beta and available to download. To stay on the bleeding edge and be notified of all beta versions, go to File > Preferences > Alerts and check Auto Update Check Enabled as well as Include Beta Versions. To upgrade the version, click the notice A new version is available in the status bar of the console. Here are all the new and exciting features that await you.

Custom Fields Import Wizard*

Are you currently using Inventory but have to maintain a separate spreadsheet to track those little items that Inventory does not gather? Perhaps you have to keep track of Asset Tag numbers, Employee numbers, or even the colors used on that one guy’s cool mechanical keyboard. Whatever the data, your days of separate tracking are about to come to an end. We bring to you the Custom Fields Import Wizard. This very handy tool allows you to import a large amount of custom data all at once from a CSV (comma-separated values) file.

To launch the Import Wizard, click File > Preferences > Custom Fields, then click Import Wizard (or on the Custom Fields page of the Computer window, click Import Wizard).

Select your CSV file and map the fields in the CSV file to any existing Custom Fields in PDQ Inventory or create brand new fields within the wizard. You can also import and overwrite data whenever you update the CSV file.

Tool Details in the Tools Library

The Tools Library now includes a Tool Details sidebar that displays the description, any applicable keyboard shortcuts, required software, and category. This is available to all license types; however, Enterprise mode is required to import tools.

Heartbeat Trigger for Scan Profiles*

We’ve added the ability for PDQ Inventory to start a scan whenever a computer goes from offline to online status so you can always have the most recent data. If the computer registers as offline and online within the Heartbeat interval (default 300 seconds), the computer will not register as offline by the Heartbeat and a scan will not be initiated. This is set up on the Triggers tab of the Scan Profile window found in File > Preferences > Scan Profiles. Open an existing Scan Profile or click New to create a new profile.

New actions available for Files and Registry pages*

The Files and Registry pages of the Computer window have more flexibility than before. Have you ever scanned for file or registry entries and had the results return far too many line items? Or have you changed a scan profile, but the results are still showing? You can now delete individual entries without having to repeat the process of editing your scan profile and scanning the computer again.

Additionally, opening File Explorer to the exact location of a select file is now just a right-click away using the context menu.

More data collected during a scan

  • Current User (User UPN Name), Display Name (AD User Display Names), and Deep Freeze Status* have all been added to the Computer page of the Computer window as well as Collections and Reports.
  • Added From, Deep Freeze Product Code*, and Deep Freeze Version* have all been added to Collections and Reports.
  • SMART Status* has been added to the Disk Drives page of the Computer window as well as Collections and Reports.

Other smaller (but no less important) additions

  • The Computer window of a selected computer can be opened directly from within the Remote Command window using the context menu.
  • The Main Console Toolbar is now arranged more conveniently by task.


*Requires Pro or Enterprise mode

How to Disable Flash on Your Network

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy

In this post, we’ll go over how to disable Flash on IE, Firefox, and Chrome. The video below is the complete recorded webcast in which we cover each browser. In each section, a link is provided that will go to that portion of the webcast or you can watch the webcast in its entirety below.

Is Flash all that bad? Maybe, maybe not. Adobe Flash is a necessary evil for some organizations…a lot of schools often need Flash to run certain educational programs. The objective is to minimize your possible security risks (AKA minimizing your attack surface). If you don’t need Adobe Flash in your environment, disable it. If you need it, get it and make sure you keep it up to date. For your consideration, what would happen in a month without Adobe Flash?

How to Uninstall Flash in Firefox

In the Package Library, there is a deployment package available that will uninstall Adobe Flash (requires an Enterprise license). It will only uninstall the Flash as made available by Adobe. It will not uninstall or disable Flash built into IE (for Windows 8 and higher) or the embedded PPAPI Flash in Chrome. Watch how to uninstall Adobe Flash for Firefox.

Disable Flash in Google Chrome

There are two steps to disabling Flash in Chrome. First there is the embedded Pepper Flash (PPAPI). Straight up, the best and surefire way to make sure the embedded Flash is disabled in Chrome is through a GPO. In order to use this method you need to import the Google ADMX files into your Group Policy environment. You can download the latest ADMX files here. In a new or existing GPO you can configure the new policy. With the example below we have a dedicated GPO called Component Update Disabled.

GPO how to disable flash in chrome

In Settings > Administrative Templates > Google/Google Chrome you’ll be able to see what policies you have enabled or disabled. Right-click on your GPO (on the left pane) and select Edit. With the ADMX template loaded, you’ll have the option to go to Computer Configurations > Policies > Administrative Templates > Google > Google Chrome. From there you can find the setting called Enables component updates in Google Chrome. Which you can then set to disabled. If you do not explicitly set this policy to Disabled then any computers that can access the internet will automatically have the latest embedded Pepper Flash installed.

If you are using Chrome make sure you don’t have the Adobe Flash Player PPAPI installed. This is important because even if you disable the Enables Component Updates in Google Chrome setting Chrome will use the installed Adobe Flash Player PPAPI if it is installed. You can deploy the Uninstall Adobe Flash Player package from PDQ Deploy’s Package Library to uninstall this application.
edit gpo flash google chrome

If you would prefer to not use a GPO to disable the embedded Flash for Chrome you can use PDQ Deploy to push out a specific registry value to your target computers. Below is a download for a package you can use in PDQ Deploy to deploy this policy’s registry changes. Also below is an accompanying Collection you can import into PDQ Inventory to help you track computers with Flash disabled.

Package – Disable Flash in Chrome

Collections – Flash Disabled

Watch the video on how to disable Flash in Chrome here.

Disable Flash in IE

Every KB that comes out from Microsoft for Flash has a workaround for disabling Flash. Again, GPO is probably the best way to accomplish this, check out this blog post on how to disable Flash in IE using GPO.

We also have a deployment package you can push out here. Make things easy on yourself and deploy to the right computers and use the Collections provided here to track computers that have Flash disabled.


Why disable Flash? Shouldn’t uninstalling it do the same thing?

In some cases you will want to uninstall it. Other situations, however, uninstalling really isn’t an option so you are left with disabling it. Below is a chart showing which OS/browser combinations you can uninstall vs. disable. If uninstalling is an option, you can use the deployment package available that will uninstall Adobe Flash available in PDQ Deploy.

OS Browser Disable/Uninstall
Windows XP to Windows 7 IE Uninstall
Windows 8.1-10 IE Disable
All Firefox Uninstall
All Chrome Disable AND Uninstall
All Opera Uninstall




Deploy Adobe Creative Cloud Using Setup.exe

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy

You’re looking to deploy Adobe Creative Cloud using setup.exe, rather than the MSI. For instructions on using the MSI, check out this blog post. This post will show you how to configure the Creative Cloud Packager and then successfully install the selected Adobe CC products. Be sure to check out the tips for troubleshooting silent installations of Creative Cloud at the bottom of this post.

Configuring the Creative Cloud Packager

1. Download the Creative Cloud Packager by logging in to https://www.adobe.com/ and selecting the appropriate management link. In the management window, select Deployment Tools then select the Download Win > package.

2. This will download the CCPLauncher.exe. Launch the executable.
3. Click on Create Package.

4. Give the package a name, a location where the package should be saved, the architecture (32 or 64-bit) of the applications, the license type, and any special configuration options (mostly update preferences).


5. Click Next.
6. Select the applications and/or updates you wish to build into your installer.

NOTE: As indicated in the image above, for multilingual offices you can also select the Match OS Language, which will install the applications based on OS locale. This negates needing to create multiple packages in specific languages.adobe creative cloud packages

7. Once you’ve made the appropriate application and/or update selections, click Build. And wait. And wait some more. Go to lunch. Wait. Deploy some other things. Wait. Inventory the satellite office in Boca Raton with their 3,478 USB printers. Wait.

You should now have a directory containing an MSI installer and a setup.exe for the Creative Cloud products in the ..\DownloadDirectory\Build\.

setup.exe for adobe creative cloud
Deploy Adobe Creative Cloud Using Setup.exe

In the following example, we are only deploying the 64-bit version, but it is possible to create a 32 and a 64-bit installation. For information on how to do this, see the original KB.

1. In PDQ Deploy, click New Package or Ctrl+N from the toolbar or click on File > New Package or right-click the Packages folder in the navigation tree and select New Package.
2. Name the package something reasonable, and choose the appropriate Copy Mode (see Considerations below) if not already set globally (Pull Copy Mode should be default in your global settings if you have followed the recommendations at the bottom of this article).

Deploy Adobe Creative Cloud Using Setup
3. Click on New Step > Install, and give the step a title. For the Install File, navigate to the directory containing the setup.exe you created above.


  • The setup.exe has a silent parameter, –silent. This must be used when deploying the setup.exe. The full usage statement for setup executable is:
setup [--silent] [--ADOBEINSTALLDIR=<TargetInstallDirPath>] [--INSTALLLANGUAGE=<ProductInstallLanguage>] [{-h, -help, --help}]
  • Make sure to check Include Entire Directory. If this is not checked, the deployment will fail.

silent install parameter for adobe creative cloud
4. Click on the Conditions tab and select the O/S Version. Since Adobe Creative Cloud products will only run on Windows 7 and above, exclude XP and Vista. Exclude servers unless required. Since this package is installing the 64-bit Creative Cloud applications, select 64-bit from Architecture.

architecture type for adobe cc
5. Save the package.
6. Deploy and enjoy.

IMPORTANT: While we make every effort to test on multiple platforms and architectures, it is highly recommended you test the deployment before a general release into production. Given the possibility of the package being substantially sized, testing will provide important information on bandwidth limitations and deployment times. In our tests, an install consisting of Adobe Acrobat, Photoshop, and Dreamweaver took anywhere from 6 – 20 minutes to deploy.


  • In order to download the Creative Cloud Packager from Adobe, you will need to be an administrator of an Adobe Creative Cloud account.
  • You cannot deploy using Creative Cloud for Individuals (requires Team, Enterprise, or Education Creative Cloud plans).
  • While the deployment method outlined in this article can be accomplished using PDQ Deploy in free mode, changes will need to be made to create separate deployments based, for example, on OS architecture


  • The guidance in this article is focused on Creative Cloud for Teams. The steps for Creative Cloud for Enterprise and Education vary, but should be intuitive enough to allow successful deployment given the general instruction expressed in this article.
  • Since the size of a Creative Cloud package can be significant, it is recommended you use the Pull copy mode instead of the default Push copy mode (File > Preferences > Performance). This will also require placing the Repository on an accessible file share. For more information, see: PDQ Deploy: Understanding Push and Pull Deployments
  • For the greatest level of performance where multiple file servers exist and the deployment audience is greater than 30 machines, the use of Distributed File System Replication (DFSR) is highly recommended. For more information, see: PDQ Deploy and Microsoft DFS.
  • If users do not have local admin access on their respective machines and therefore do not have access to the Creative Cloud App Panel, the Creative Cloud Package can also be used to push out updates to machines with installed Creative Cloud products.

Troubleshooting Your Deployment

If the package deployment fails and/or you receive a 1603 error, please try the following.

  • Machines should be fully patched and not in need of a reboot.
  • Check to ensure sufficient space is available on the drive where Adobe CC will be installed. Some Creative Cloud deployments can be several gigabytes in size, which includes the files copied to the target and the installed size.
  • Clear out %WINDIR%\Temp directory.
  • Review the troubleshooting steps in This Article.

Error: “Setup.exe returned error code N”:
Adobe has a great Creative Cloud Troubleshooting Guide. There should be a log file on the target machine called PDApp.log, usually in C:\Windows\Temp. At the end of the log or near the end, there should be an error code. That error code can then be used to diagnose the particular issue. For example, PDQ Deploy reports, “setup.exe returned error code 4”. Reviewing the log file shows, “The Bootstrapper Process return code is (82).Stopping the installation process.” Reviewing the Troubleshooting Guide, error 82 is caused by AAM running and can be solved by closing all Adobe processes and/or renaming the PDApp folder.

Error: “Setup.exe returned error code 6”:
Usually the programs will have installed, but the error will still be thrown and the deployment will show as failed. There can be a few causes for the error code 6, which are outlined here as well as in the Troubleshooting Guide. This can also be caused by insufficient disk space or any number of other environmental conditions.

How to Remove AppX Packages

Posted on 3 CommentsPosted in PDQ Deploy, PowerShell

A common request we have is how to remove AppX packages, or in other words, remove Windows 10 default applications. First, you’ll see how to write and deploy a script to remove the applications, then we’ll look at an option for removing the application for all users on a workstation.

Building the Script to Remove Appx Packages

To successfully remove AppX packages you’ll need two separate PowerShell scripts: one to remove the application(s) and one to prevent it from installing when a new user logs onto the desktop.

Remove Windows 10 Default Applications

To remove the existing software you need to decide which apps you would like to remove first. You can remove a single package with a one line script.

Get-AppxPackage |where {$_packagefullname -like "*zune*"} | Remove-AppxPackage

If, however, there is an entire list you would like it becomes a little more involved, you will need to create an array for each application you want to remove. For example:

$appname = @(

ForEach($app in $appname){
Get-AppxPackage -Name $app | Remove-AppxPackage -ErrorAction SilentlyContinue

You can add however many apps you like to the array and this script will cycle through and remove them. To get a full list of software you can remove you can run the following script on a Windows 10 machine:

Get-AppxPackage -AllUsers | select PackageFullName

Preventing Applications from Installing for New Users

The process for preventing the software from installing in the future is very similar. The only difference in the command is “provisioned” is added to the command name (Get-AppxProvisionedPackage). Here is how you get the list:

Get-AppxProvisionedPackage -online | select PackageName

And then to remove them from the preinstall list use the following script:

$appname = @(

ForEach($app in $appname){
Get-AppxProvisionedPackage -Online | where {$_.PackageName -like $app} | Remove-AppxProvisionedPackage -Online -ErrorAction SilentlyContinue


Running the PowerShell Script Remotely

Now that we have the script we want we need to deploy it to the machines that you want to remove AppX packages from. This is where it starts to get tricky, if you create a package and run it with the default settings it will look like it did not do anything. The reason is the remove command does not have any ability to specify a specific user, so if you run it as the deploy user it will try and uninstall that software for the deploy user on that machine.

If you are in a work environment has one computer per user you can run this as the logged on user and it will work as you are hoping as long as the users are logged in at that time.


For the AppxProvisionedPackage you can create the package with the defaults and it will still work as it is machine based and not user based.

Why These Scripts Do Not Remove Apps For Every User

If you have reached this point, you have been looking at this for awhile and you have found a lot of examples that say (incorrectly) if you run this command, then it will remove for every user:

Get-AppxPackage -AllUsers | Remove-AppxPackage

If you run it you’ll see nothing actually is removed. The reason has to do with the information that pipes over between the two commands. The first command (Get-AppxPackage) has an attribute (-AllUsers) that will look at each user on the computer, while the second command (Remove-AppxPackage) does not. That command while it does find packages for every user, it only passes over the name of the package, therefore it will only attempt to remove the package for the user running the script.

Alternative Solution

The challenge everyone runs into it is how do we remove AppX packages from all users that have logged into the machine previously without having to catch them while they are logged in. If all of your end users are local admins the very quick answer is add the PowerShell script as a logon script in Group Policy. If they are not local admins it takes a little work, but you can do it with PDQ Deploy.

Step 1: Build the PowerShell script. At the bottom I added two lines that will delete the script and batch file once the process is complete.

$appname = @(

ForEach($app in $appname){
    Get-AppxPackage -Name $app | Remove-AppxPackage -ErrorAction SilentlyContinue

Remove-Item -Path "$env:USERPROFILE\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\startup\test.bat"  -Force
Remove-Item -Path "$env:USERPROFILE\AppData\local\removeappxpackages.ps1"  -Force

Step 2: Create batch file to start the new script and run it all silently

@echo off
start Powershell.exe -executionpolicy remotesigned -windowstyle hidden -File  %userprofile%\AppData\Local\removeappxpackages.ps1 /min

Step 3: Create a new package in PDQ Deploy with a PowerShell step (get a free Enterprise trial here) that will copy the PowerShell script and batch file into each user profile that has had an interactive login.

$users = Get-ChildItem -Path "C:\Users"

foreach($user in $users){
  $path = "C:\Users\$($user.name)\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"
    if(test-path $path){
        Copy-Item -Path test.bat -Destination "$path\test.bat" -Force -ErrorAction Silentlycontinue
        Copy-Item -Path removeappxpackages.ps1 -Destination "C:\Users\$($user.name)\AppData\Local\" -Force -ErrorAction Silentlycontinue

Step 4: Add the files you created into the package.

addfiles Remove AppX Packages

Running this will make it so any user that has logged into a machine will have these applications removed the next time that they logon. They will not see anything and it removes them in under a minute. Running the remove-appxprovisionedpackage script from earlier will prevent it from installing these applications for all new users so you don’t have to run this script again.

Track Anti-Virus Software Versions with PDQ Inventory

Posted on Leave a commentPosted in PDQ Inventory, Scanning

PDQ Inventory is especially useful for keeping tabs on application information. Building dynamic collections in PDQ Inventory can answer questions like: “Are all of our devices up to date?” and “Which devices are most vulnerable right now?”. For some examples, we will use PDQ Inventory to find computers that have multiple anti-spyware applications installed and, of course, which computers have our preferred anti-spyware installed. In this example, we will use WebRoot SecureAnywhere as the preferred application.

Start by making two basic dynamic collections:

  1. A collection for your organization’s preferred anti-virus software
  2. A collection for devices with potentially unwanted anti-virus software.

The latter is important to track because no user is perfect—a hasty “whatever, just click install” mindset usually results in unwanted applications getting installed somewhere along the line. Having multiple anti-spyware applications on a single device can cause conflicts that can even result in BSODs and disabled anti-virus protection—something no admin, or even end user, wants to see.

Finding Unwanted Anti-Virus Installations

Set up an unwanted anti-virus collection to catch big-name applications that your organization does not use—just use the Any filter as shown below. It will help to add a few basic keywords to catch lesser-known or junk applications that might slip through. Experiment with application name/publisher values until you’ve covered all the bases, then uninstall unwanted applications at will!

Track Anti-Virus Software Versions

Having good anti-virus software only goes so far in keeping your organization’s devices safe. Mismanaged or undermanaged anti-virus software is a security risk.  PDQ Inventory makes it easy to track anti-virus software versions and to identify devices with out-of-date protection or other software problems.

Handling Mismatched Anti-Virus Version Counts

Sometimes, the numbers of out-of-date and up-to-date versions will not match up to the number of devices in the parent collection. For example, you might have 200 devices in the parent collection, but 175 show up with the current software version and 50 show up with older versions. Mismatched version counts could result from an updated version failing to uninstall previous versions. This would cause two or more versions show up on one device. Multiple installed versions might be something to handle on a case-by-case basis via remote uninstall commands in PDQ Inventory or with a custom uninstall package in PDQ Deploy.
There are a lot of old versions reported in the group of collections below, due in part to mismatched version counts. Old versions are especially likely to show up in larger numbers for cloud-based anti-virus applications. If the version number from cloud-based software looks like it’s severely out of date, it may just be the version number of the agent installed, not the actual update protecting the device.


In this case, the endpoint device can be checked to verify that it is receiving updates from the cloud. Below is how the agent version from PDQ Inventory/Programs List could differ from the cloud-based update protecting a device.

AA-WRSAEndpoint (1)

Collections for different versions are simple to make, though, especially when you put variables to use.

Maintaining Software Versions in Collections

Variables help you easily change up-to-date and out-of-date version numbers. The benefit of variables is you can change them all in one place, rather than have to edit multiple collections. I set several variables to separate the previous version from all other older versions to separate devices that failed to update once from devices that failed to update several times. Name your variables and set appropriate values, then use them in dynamic collections.



Once your collections are built and you’re confident that they’re accurate, it’s time to put them to good use. Use PDQ Deploy to build a package with the most recent version of the anti-virus software your organization uses, then deploy it to the most vulnerable (out-of-date) targets.  When new versions of anti-virus software are released, all you need to do is update the variables you set in Preferences. Your dynamic collections will then reflect the changes.

Once your out-of-date anti-virus pile is down to zero, treat yourself to a little dance and then make sure other applications and plugins that affect security are up to date!


Disclaimer: For demonstration purposes, cloud-based software was treated as hosted/on-premise software. Keep in mind that the nature of your anti-virus software (cloud-based or hosted/on-premise) can affect how the software’s version information shows up in PDQ Inventory.

See What’s New in PDQ Deploy 12

Posted on 3 CommentsPosted in PDQ Deploy

PDQ Deploy 12 is now available. To update your console, click the “A new version is available” notice in the status bar of your console. If the update link is not visible, go to File > Preferences > Alerts to enable update notices.

New in the PDQ Deploy 12 Release

Use PDQ Inventory Scan User Credentials in PDQ Deploy

Use the scan user credentials from PDQ Inventory (in Enterprise mode) for your deployment credentials in PDQ Deploy. In previous versions of PDQ Deploy you were limited to using one set of credentials for all target computers per deployment. This meant that computers that required different Deploy User credentials had to be broken down into different deployments. That all changes in PDQ Deploy 12. This new feature requires you to have PDQ Inventory 11.2 or higher and PDQ Deploy 12 both in Enterprise mode. When you create or schedule a deployment, under the options tab you can select to use the PDQ Inventory scan user credentials first, if available. If the target does not exist in PDQ Inventory, the default PDQ Deploy credentials will be used instead.

Wake-on-LAN/Ping Settings Are More Versatile

The Offline Settings have, historically, been global. We have now made it so you can modify your Offline Settings at the Package and Deployment / Schedule levels. In addition to your current global settings (found in File > Preferences > Deployments), you can now ping targets or send Wake-on-LAN (WOL) per package, Auto Deployment package, schedule, or deployment. For example you could have your global settings to only deploy to computers that are online (PDQ Deploy pings the targets and only deploys to the computers that respond) but change a particular deployment to override that setting and attempt to use WOL (Wake-ON-LAN) for the offline computers.

To ping a target or send a WOL per package (including Auto Deployment package):

Package > Properties > Offline Settings


To ping a target or send a WOL for a schedule:

Schedule > Offline Settings



Some Improvements…

Post Schedule Notifications

If you are already a fan of using Post Deployment Notifications, you will enjoy this addition. You can now set Post Schedule Notifications to send only one email upon deployment completion of the entire schedule rather than multiple emails when using a Post Deployment Notification. You also have more options for customizing your emails and can now use variables in the subject line and email body. Set up a Post Schedule Notification very similarly to a Post Deployment Notification in File > Preferences > Mail Server.

You can add additional custom variables to use in notification emails (and other areas in PDQ Deploy) in File > Preferences > Variables.


Nested Package Run As Options

When adding a nested package, you can now select to use the Run As option of the nested package. You can change this setting by selecting the nested step and going to the Options tab.


Initiating Deployments and Scans Using PowerShell

Posted on 2 CommentsPosted in PDQ Deploy, PowerShell, Scanning

Utilizing the CLI interface (available in both PDQ Deploy and PDQ Inventory) we showed you initiating deployments and scans using PowerShell in this webcast. Why use the CLI? There are a few scenarios this can be handy, such as if you are on a remote computer and cannot access the console. Perhaps you want to script out something with scheduled tasks.

You may want to refer to this post from our webcast on preparing your environment for remote PowerShell.

Below are the PowerShell scripts, examples, and other files used in the webcast. Join our next webcast live, sign up for email notifications here

Webcast Bonus Content: Initiating Deployments and Scans Using PowerShell

How to: Enable TCP for Background Service

XML Imports

PDQ Deploy Package-Example Package

PDQ Deploy Schedule-The One  Schedule

Task Schedules – PDQ McTask

PowerShell Scripts

PDQ Deploy – Remotely initiating deployments.ps1

PDQ Inventory – Remotely Trigger a Scan

Reg File

Background Service – Enable TCP on port 7777.reg

Remotely Activate Office: Defending Against Mayhem and Horror

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy

It is the nature of things that seemingly straightforward recipes such as those to remotely activate Office can sometimes fail. Realizing that your 14,783 deployments of Office didn’t activate correctly and that 14,783 ravenous, ill-tempered, and thirsty (assume for blood) users will be walking into the office in less than twelve hours to face the Microsoft Activation Wizard, you need protection from the great unwashed mob, spray tanned, clad in cheap polyester ties and pencil skirts spilling forth from their Philistine fingers a Biblical flood of helpdesk tickets filled with recipes for your demise and foul language expressed IN ALL CAPS WHAT IS THIS WIZARD S___ AND WHY ARE YOU STILL EMPLOYED??? THE WEBSITE IS DOWN! DIE! DIE! DIE!, & etc…

office activation bad

What to do?

There are options beyond unplugging your phone and hanging dreamcatchers from your monitors to capture evil spirits and the results of horse-leavings. First, it’s assumed you’ve done a test deployment to a few machines, logged in to confirm Office was installed, opened Word to see if it’s the real deal or if it exists only in some purgatorial reduced functionality mode. Most importantly, do you get the Activation Wizard?

If you do get the Activation Wizard, there is help. This help assumes you’ve entered the correct KMS or MAK keys in the OCT.

Using the Office Customization Tool (OCT)

First, open the MSP file you created with the Office Customization Tool (OCT) and navigate to the Add installations and run programs section. You’ll want to add the following target:


Arguments, based on architecture and Office bitness*:

Office 2016:

"%ProgramFiles(x86)%\Microsoft Office\Office16\ospp.vbs" /act
"%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /act

Office 2013

"%ProgramFiles(x86)%\Microsoft Office\Office15\ospp.vbs" /act
"%ProgramFiles%\Microsoft Office\Office15\ospp.vbs" /act 

Office 2010:

"%ProgramFiles(x86)%\Microsoft Office\Office14\ospp.vbs" /act
"%ProgramFiles%\Microsoft Office\Office14\ospp.vbs" /act

OCT wizard


Like other things within the OCT, sometimes this doesn’t work. This is why we recommend testing. Each environment is different, and each deployment interacts with those environmental differences differently.

Remotely Activate Office without the OCT

If the OCT option doesn’t work, you can add these steps at the end of your deployment in PDQ Deploy to remotely activate Office (depending on architecture and Office bitness*):

remotely activate office

A note of some importance: if your Office deployment is one of those twee Click-to-Run products (C2R), there’s no Activation Wizard, so whew; the user signs in like anything else on the internet. Unless you’ve done some dark magic with Azure Active Directory, but that’s beyond the scope of this article. The AUTOACTIVATE element for Office 365 ProPlus is not necessary since activation is already automatic. For Visio and Project C2R products, you can use AUTOACTIVATE Value=”1″ to activate those products.

Checking the Activation Status of Office

If you’re curious about the activation status of your Office deployment but don’t want to login to a representative sample of end-user computers to test, you can run the tests safely from within PDQ Deploy.

For example, the following will return the activation status of the Office install. You should change the Program Files  and OfficeXX directory to correspond to the bitness of Office/Windows and the version of Office (2010 – 2016).

%windir%\system32\cscript.exe "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /dstatus


Some of the results you can get back from the Output.log of the deployment are:

Office Professional Plus 2016, unlicensed (and of course, not ACTIVATED):
ERROR CODE: 0xC004F009
ERROR DESCRIPTION: The Software Licensing Service reported that the grace period expired.

Office 365 Professional Plus 2016. Licensed and therefore ACTIVATED:
ERROR CODE: 0x4004FC04 (for information purposes only as the status is licensed)

Office 2016 Professional Plus (KMS). Installed, but NOT ACTIVATED (running in the grace period):
ERROR CODE: 0x4004F00C

Office Professional Plus 2016, licensed (and ACTIVATED):


*Unless your users are rocket scientists that do all their orbital mechanics calculations in Excel, you probably don’t need (or want) 64-bit Office. If you can’t think of a concrete technical reason you need 64-bit Office, 32-bit is what you want.

See Also:
Active Directory-based Office Activation
The ospp.vbs Script
Methods of activating Office 2013

Silently Installing TightVNC 2.8.5 To Your Windows Computers

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy

If you have access to the PDQ Deploy Package Library you can use our pre-built package for silently installing TightVNC to all of your Windows computers. If you’d like to build your own TightVNC package you can follow the steps outlined below. In fact, building this package is an excellent exercise for learning how to build complex packages.  It is assumed that you have PDQ Deploy version 10 or higher running in Pro or Enterprise mode.

In this example we are only going to deploy the TightVNC “Server” portion. TightVNC is broken down into two components: Server and Viewer. There really is no need to deploy the Viewer to all of your computers unless you expect your end users to remotely control other computers. Since we only want the ability to initiate a remote control session against our target computers we will only need to install the Server portion.

Silently Installing TightVNC: Building the Deployment Package

You will want to download the TightVNC Installers (64-bit and 32-bit depending on your targets). In this exercise we are using the .msi installer files. Copy these files to an appropriate location. In our example we are placing these files in our PDQ Deploy Repository folder.

Open PDQ Deploy and create a new package. Add the following steps. Please note that these steps won’t necessarily match the exact steps in our TightVNC package that is available in the Package Library.

Package Steps

Step 1 – Create a Command step. This step contains one line. It stops any existing TightVNC Service.

net stop tvnserver

Set the Success Codes to 0,2 (Error code two is returned if the services doesn’t exist or is already started). You want to count these occurrences as a success.

Under the Options tab set the Error Mode to Continue.

Step 2 – Create a Command step. This will uninstall old TightVNC that wasn’t installed with an MSI. This is important so that you don’t have two versions of TightVNC installed. The MSI will upgrade existing TightVNC installations that were also installed via MSI. Type in the command below into the Command field of the Details tab.

"%ProgramFiles%\TightVNC\unins000.exe" /VERYSILENT

Go to the Conditions tab. Expand the File condition. Click the Exists radio button. In the directory field type in %ProgramFiles%\TightVNC and in the Filename field enter unins000.exe. By doing this you are ensuring that you only will run this step if the unins000.exe file is found in the designated directory.

Step 3 – Create a Command Step. This step will be identical to Step 2 except we are going to account for previous 32-bit TightVNC installations (non-MSI) that were installed on 64-bit targets. You will need to use the following command:

"%ProgramFiles(x86)%\TightVNC\unins000.exe" /VERYSILENT

Also, make sure to add the file condition like you did in Step 2 but use the %ProgramFiles(x86)% variable instead. Also, in the Conditions tab change the O/S Architecture to 64-bit. The images below show the contents of the Details and Conditions tabs.



Add Install Files

Step 4 – Create an Install step. In this step we run the 32-bit installer on 32-bit systems only. In the Install File field navigate to the 32-bit TightVNC MSI file.

Now, the parameters are extremely important for this step. You need to determine which parameters are important to your environment. I will provide the basics but you may want to tweak these a little. You can find the available parameters in the documentation. Below are the parameters we provide with our TightVNC package.


Notice that we are setting the password value. You will want to pass this HOWEVER we have seen some instances where this value is not honored. We get around this in a later step by running a PowerShell script that forces the password change on the target. In this example we are setting the password to the word “helpdesk” without quotes. Please note that TightVNC passwords can only have up to eight characters. More appropriately, only the first eight characters of a provided password will be used.

In the Conditions tab set the O/S Architecture to 32-bit.

Step 5 – Create an Install step for 64-bit targets. Use the same parameters supplied in the previous step. Just change the O/S Architecture condition to 64-bit and, obviously, change the Install File to the 64-bit installer.

Finishing TightVNC Setup

Step 6 – We recommend placing a Sleep step here. The Sleep step is used when you want to pause a deployment for a certain number of seconds. Don’t go too crazy, 5 seconds should be enough.

Step 7 – Stop the TightVNC Service. A simple Command step can be used. Just run the following command:

net stop tvnserver

Don’t forget to set the Success Codes to 0,2.

Step 8 – Install DFMirage Driver (OPTIONAL) –  If you want to deploy the mirage driver to your computers then this would be a good time to do it. Create an Install Step. You can grab the install from the TightVNC download link mentioned before Step 1. Just a few notes. Make sure you don’t install the driver more than once on a target. We will show you how to prevent this. Also, according to the documentation the driver is compatible on OSes from XP – Windows 7. As a result we recommend using the O/S condition on this Install Step. Only include the appropriate OSes.

Please note on the Conditions tab that we (in addition to excluding later OSes) also have a File condition. We simply look for the file unins000.exe in the path %PROGRAMFILES%\DemoForge\Mirage Driver for TightVNC. Check the Does Not Exist radio button. This is one way you can prevent this step from installing the driver again.

The parameters we used to make the driver install silently are:


Here is a screenshot of the Details tab on the Install Step.

Silently Installing TightVNC blog-tightvncstep8dfmiragedetails

Here is the Conditions tab for the same step.


Setting the TightVNC Password

Step 9 – Set TightVNC password. Create an Install Step. (You could also use a PowerShell step but we’ll just show you the Install Step method here)  {{Download this file: tightvnc-password-fix}}.  Kris Powell, our PowerShell rock star, wrote this script. We use this script because the password parameters in the install steps don’t consistently set the password for TightVNC. The parameters you will need to use for the script.

-Password "NewPassword" -Force

Step 10 – Create a Command Step. This step will simply start the TightVNC service. The following command should do the trick. Set the Success Codes to 0,1056,1058.

sc start tvnserver

There you go. Don’t forget that you can initiate VNC remote control sessions from within PDQ Inventory.

Silently Change Firefox Default Search Engine

Posted on Leave a commentPosted in Deployment Examples, PDQ Deploy, PowerShell

Oh, Yahoo! when will you learn you can’t buy friends? Firefox set the default search engine to Yahoo! back in 2014. Since then sys admins have been battling the forced setting. Looking to silently change Firefox default search engine in your network? Can do.

Changing search engines on an individual basis is simple. To make the change on your own home computer read this. If you manage a network of computers, read on.

Silently Change Firefox Default Search Engine

PDQ Deploy Package LibraryPDQ Deploy has a ready-to-deploy, silently installing deployment that will change the Firefox search engine to Google for all your users. In PDQ Deploy, go to the Package Library and import Mozilla Firefox – Set Google as Search Engine. Send this package to any of your target Windows computers that have Mozilla Firefox installed. Upon reboot, your users will have Google set as their browsers. You can choose targets from Active Directory, PDQ Inventory, Spiceworks, etc. How do I use the Package Library?

But let’s break down what’s in the package.

Using PowerShell – Silently Change Firefox Default Search

The package uses the following PowerShell script to make the change. This PowerShell script is provided by the illustrious Kris Powell. (Check out his PowerShell blogs.) This script updates all user profiles on the target computer, if a Firefox profile folder exists for a user. Your users will see the change after they restart their Firefox browser.


$disclaimer = "By modifying this file, I agree that I am doing so only within Firefox itself, using official, user-driven search engine selection processes, and in a way which does not circumvent user consent. I acknowledge that any attempt to change this file from outside of Firefox is a malicious act, and will be responded to accordingly."
$Pattern    = "{`"\[global\]`"\:{`"current`"\:`"(.*)`",`"hash`"\:`"(.*)`"}}"
$Encoding   = [System.Text.Encoding]::UTF8
$Hasher     = New-Object ([System.Security.Cryptography.SHA256]::Create())

Get-ChildItem -Path "$env:public\..\*\AppData\Roaming\Mozilla\Firefox\Profiles\*" | Where-Object { $_.PSIsContainer } | ForEach-Object {

    $result = [System.Convert]::ToBase64String($Hasher.ComputeHash($Encoding.GetBytes($_.Name + $SearchProvider + $disclaimer)))
    $File   = "$($_.FullName)\search-metadata.json"
    $Data   = "{`"[global]`":{`"current`":`"$SearchProvider`",`"hash`":`"$result`"}}"
    $SearchJsonMozlz4 = "$($_.FullName)\search.json.mozlz4"

    If (-Not (Test-Path $File)) {New-Item -Path $file -ItemType file}

    (Get-Content $File) | Foreach-Object {
        If ($_ | Select-String -Pattern $Pattern) { 
            $_ -replace $Pattern, $Data
        } else {
    } | out-file $File -Encoding utf8
   If ((Get-Content $File) -eq $Null) {
        $Data | Out-file $File -Encoding utf8
    If (Test-path $SearchJsonMozlz4) {Remove-Item $SearchJsonMozlz4 -Force}

What if I Want Something Other Than Google?

You can use any installed search provider as a value to update. By default in the US-version of Firefox, these values include:

  • Amazon.com
  • Bing
  • DuckDuckGo
  • Google
  • Twitter
  • Wikipedia (en)
  • Yahoo

Put your choice of search engine in place of Google. (Images below show the script in a PowerShell step within PDQ Deploy)

powershell change firefox default
The script (as it currently is written) supports a $SearchProvider parameter with a default value.  You can change script every time or just change the parameter when calling the script. Changing both is not required.

firefox search engine powershell

If you used the package from the Package Library, you would simply open up the imported package and edit the parameter field to your desired search engine.

silently change Firefox default search engine