Adding your own custom data to PDQ Inventory

  

 Email Article  

Tweet  

  

  

With our 2.1 release of PDQ Inventory came a frequently requested feature: adding custom data.

Some data cannot be extracted from computers using an inventory scan. Below are some examples of custom data that you may want to track.

• Purchase Date
• Warranty Expiration
• Cost Center
• Corporate Asset Tags
• etc

Creating Custom Items

In PDQ Inventory (running in Pro Mode) go to File > Preferences > Custom Items.

Click New Item and enter your information. 

Adding Data for Custom Items

In PDQ Inventory, double-click on a computer and click on the Custom Items in the left pane. You can then select the item that you just created in the earlier step and add the data specific to this computer.

Coming in a future release will be the ability to do mass custom data entry for multiple computers.

Deploy software to your Spiceworks collections

  

 Email Article  

Tweet  

  

  

Deploying software to Spiceworks collections is a very common request among Spiceheads. That's why we added Spiceworks to the list of options to add target computers to deployments. 

Before you can deploy you need to tell PDQ how to talk to your Spiceworks server.

Spiceworks Login

Step 1: Go to your PDQ Deploy Preferences (File > Preferences)

Step 2: Enter your server hostname, port, and Spiceworks user credentials.

Step 3: Test your connection

Once you have successfully tested your connection, you're ready to do some deployments.

Seeing your Spiceworks Computers

Choose which package you want to deploy from your list of Packages in PDQ Deploy. Click Deploy... button and select Deploy Once.

Click the Choose Targets button and select Spiceworks. 

NOTE: If you have a large environment, displaying your Spiceworks collections may take awhile. If this happens, you may want to check out this post on speeding up Spiceworks, and this post on speeding up in one easy step.

PDQ Inventory 2.1.1 Released

  

 Email Article  

Tweet  

  

  

The betas for the new version of PDQ Inventory have concluded. PDQ Inventory 2.1.1 has been released. (Download)

Here is a run down of the changes in the new version.

Features

• Same interface for Collections and Reports
• Custom Data fields for manual entry (Service Tags, etc.)
• Product Key for Windows and Office now collected
• BIOS Asset Tag added
• Default collections for memory
• Built-in collection for IE 10
• Configure Windows Service Manager TCP Connection
• Ability to not add disabled computers during AD sync
• Added Printer Driver column to reports and collections

Fixes

• AD Sync no longer imports Windows 2000 computers
• Fixed an issue importing collections with relative date filters.
• Improved exporting to Excel to use proper column widths.
  
• Improved display of process memory to make more readable.
  
• Fixed an issue where the upgrade could reset the background service credentials to Local System.
  
• Fixed an issue where renames in AD could cause sync issues.
• Default WMI timeout increased from 45 to 90 seconds.
• Fixed an issue reading the proper name for certain Intel processors.
• Fixed an issue with extra spaces in some processor names.
  
• Fixed scan user issue when importing from AD.
• Fixed issue when importing collections where filters referenced other collections.

What's installed. What's not installed.

  

 Email Article  

Tweet  

  

  

Here are some new videos showing which apps are installed (or not installed) on your company computers. The look and feel of creating Collections and Reports has changed quite a bit from previous versions of PDQ Inventory.

These examples are done using a beta version of PDQ Inventory 2.1. Go ahead and download it.

See which computers have Adobe Reader installed.

See which computers do not have Adobe Reader installed.

Show which computers do not have Adobe Reader installed AND are not servers.

Silent Java Install Failures

  

 Email Article  

Tweet  

  

  

Every now and then you will run into a situation where Java (JRE) won't successfully deploy to a computer. This generally will happen when you attempt to apply a Java update. There can be several reasons for Java failing to install. 

When you go to the Package Library in PDQ Deploy you may notice that we have an extra Java package available. A recent addition is the ALTERNATE package. 

We prefer that you deploy the regular (non-alternate) Java package. However if you experience problems (such as the ol' 1603 error) when you update targets then you may need to grab the Alternate. What is the difference? 

By default Java will, during an installation, attempt to uninstall previous Java versions of the same family. (i.e. Java 7 Update 17 will attempt to uninstall Java 7 Update 15 but it won't touch Java 6 since versions 6 and 7 are in different families). If Java is unable to fully uninstall a previous update then the installation will either hang or it will fail with a 1603 error.

In these cases the most common culprit is that the uninstall is not complete and there are a few remnants of the previous update that are preventing any new installations of Java.

This is where the Alternate package comes in. Deploying this package will attempt remove these remnants (registry keys) which are preventing the upgrade. After these keys are deleted the upgrade is attempted again.

The reason we recommend using the Alternate package only when it is needed is because the additonal steps we take will remove only the registry keys which are preventing the upgrade. Other items from the previous install (files and other registry components) may still exist on the target. It's just kind of a housekeeping thing. We really want Java to perform the uninstall / upgrade because we trust that it is cleaning up after itself. 

Set Protected View in Adobe Reader to Mitigate Zero Day Vulnerability

  

 Email Article  

Tweet  

  

  

We've all heard about the Adobe Zero Day vulnerability in Acrobat and Reader. Adobe has released this document describing which changes are needed to force protected view in Adobe Reader. While we wait for Adobe to release the patch we decided to follow their instructions on mitigating this vulnerability.

We've incorporated these steps into a single PDQ Deploy package. This package is available in our Package Library.  In PDQ Deploy, select Package Library from the left pane. In the search field type "protected" and you'll see the entry. (If you don't see the entry, be certain that you are running PDQ Deploy 2.1 or greater and then hit F5 in your library to refresh.)

Download the free mode version of PDQ Deploy here. 

The Ugly Details

If you look at section 2.2.3 of the Adobe document (mentioned above) you will find what we are looking for. One registry value to rule them all. You can enable this via a GPO but I will discuss using PDQ Deploy to push this change out to your affected computers immediately. Also, for purposes of this article I am only addressing Adobe Reader 11. The vulnerability affects Adobe Acrobat 10 and Reader 9, 10 and 11. I chose Reader 11 because it is the most recent release and also due to time contraints.

After you install PDQ Deploy, go to your Package Library node. Select the package called "Force Protected View for Adobe Reader 11". Now most of the packages you see do require a subscription. I took it upon myself to make this one available without a subscription (at least for the time being).

This package is very simple. It only calls a small batch file. When you deploy this package to target computers it will run this batch file which will, quite simply, check to see if Adobe Reader 11 has been installed and then add/modify the necessary registry value as described in the Adobe file mentioned above. 

Select the downloaded package (it's under the Package folder in PDQ Deploy) and hit the Deploy... button. Select your target computers. You can manually enter the names of the computers or you can import the targets from PDQ Inventory, Active Directory, Spiceworks, etc.

If a target computer does NOT have Adobe Reader 11 then the package will fail with Error Code 2. 

If you want a quick refresher on how you can deploy via PDQ Deploy, check out our youtube videos.

Automatically Perform an Inventory Scan After Deploying Software

  

 Email Article  

Tweet  

  

  

Hey PDQ Admins. PDQ Deploy can now initiate a scan in PDQ Inventory following a deployment.

Just about any sys admin who has deployed software has wanted their Inventory product to reflect the results of the deployment ASAP. Generally we have all had to manually perform an inventory scan of the target computers after the deployment.  In order to do this you must be running Pro mode for both PDQ Deploy (2.2 or higher) and PDQ Inventory 2.0 Release 4 or higher. (PDQ Deploy 2.2 is currently in a public beta). 

Here is a video demonstrating how to this.

To configure the Scan After Deployment feature open PDQ Deploy and go to File > Preferences > Deployments.

Just a note. You don't have to create a new Scan Profile (as was demonstrated in the video). You can just stick with deploying your current default profile. I just wanted to help streamline the process and only scan for changes in installed applications.

To configure automatic inventory scans following software deployments you will need the following:

• PDQ Deploy 2.2 or higher. 2.2 is, at this time, in beta. You can obtain the latest beta here. (Remember, beta releases will have more bugs!)
• PDQ Inventory 2.0 Release 4. If you are running an earlier version of Inventory please go to Help > Check for Update. If you don't currently have PDQ Inventory you can get it here.
• Pro mode for both products. If you aren't running in Pro mode you can get a 14 day trials for PDQ Deploy and PDQ Inventory.

Find Computers Running an Old Version of Java 7

  

 Email Article  

Tweet  

  

  

Which Java versions are on my network?

Let's find all the Windows computers on our network that have an old version of Java 7.

Download this zipped collection. Unzip it and import the java.xml into your PDQ Inventory console. (From PDQ Inventory, File > Import).

(Download your free copy of PDQ Inventory here if you don't already have it).  

In this example we are using PDQ Inventory 2.0 Release 3.

After you import the collection (and scan your computers) you'll see which computers have Java 7, and which of those are running an older version.

All done. You can stop reading unless you want to see how we created the collection. (It's pretty cool stuff and you'll probably get some ideas for other collections in PDQ Inventory that you want to create.)

Creating The Java Collections in PDQ Inventory

These collections may be a little more complex than you are used to. This is due to the way that Oracle lists the installed Java applications names. Most collections won't be this tricky. This collection will also involve sub (or Child) collections.

It is also important that your computers have received a recent Inventory scan. If they haven't been scanned in a while, take a few minutes to initiate a scan.

Create a new Dynamic Collection called "Java 7"

In this collection add an Application filter. In this filter populate the following Comparisons. Name STARTS WITH Java

Version starts with 7

Close this Collection.

Create a sub-collection

To do this, right-click on your new Java 7 collection and select New Dynamic Collection. This will make a sub collection. Call it something like: Java 7 32-bit (Old Version). Add an Application filter. You will use two comparisons again but they will be slightly different than the first collection.

Name matches expression ^java\(tm\) 7(?!.*64)|^java 7(?!.*64)

Version version between 7 and 7.0.100

Go ahead and close the new collection. This collection should now include computers that are running 32-bit Java 7 Update 10 or below.

Create another dynamic collection under Java 7

Call this one Java 7 64-bit (Old Version)

Using the Application filter use the following comparisons:

Name matches expression ^java\(tm\) .+\(64-bit\)|^java .+\(64-bit\)

Version version between 7 and 7.0.100

Close the collection. 

 Your collections should look something like this.

It's important to remember that when Oracle releases the next Java Update you will need to modify your Version comparisons to reflect the new version.

Now you know which computers needs to be updated with the latest update of Java 7. If you are using PDQ Deploy then you can download the Java 7 Update 11 package. Then, simply right click on Java 7 32-bit (Old Version) collection and select Tools > PDQ Deploy. When the Select Package window appears simply select the Java 7 Update 11 package and say OK. The Deploy Now window will automatically be populated with the machines which have an old version of 32-bit Java. Repeat on the 64-bit collection using the 64-bit Package from PDQ Deploy. 

Extra Credit

If you would like to understand the Regular Expressions that we used in this example please read on.

In the 32-bit collection we used the Name matches expression comparison in the Application filter:

^java\(tm\) 7(?!.*64)|^java 7(?!.*64)

We need to use this so that this collection doesn't include computers that only have an old version of 64-bit Java. Notice that we also have to prepare for the application name to start with either "Java(TM) 7" or "Java 7" since early versions of Java 7 included the (TM) in the name. The later updates have removed (TM).

I will quickly break down what this regular expression is doing:

^java\(tm\) 7 means that the application name needs to start (^) with the characters: Java(TM) 7. But if we stopped here we would have some problems because this would match systems running either 32-bit Java 7 or 64-bit Java 7. Why? Because of how Oracle stores the application names. Here are two examples of how Oracle stores the Java name for Java 7 Update 11.

For 32-bit: Java 7 Update 11

For 64-bit: Java 7 Update 11 (64-bit)

Here is a computer which has two installations of Java 7. One is 32-bit (up to date) and one is 64-bit (needs to be updated). 

So the question is how do we NOT include computers that only have a 64-bit version? We use what is known as a Negative Lookahead (?!) to exclude any string that contains the numbers 64 after Java(TM) 7. 

The expression "^java\(tm\) 7(?!.*64)" would match the following examples

Java(TM) 7 Update 1

Java(TM) 7

But it would NOT match

Java(TM) 7 Update 1 (64-bit)

Anytime you see a regular expression with a PIPE | this means OR.

^java\(tm\) 7(?!.*64)|^java 7(?!.*64)

With the Pipe symbol you can say OR match xxx. Since some Java names start with "Java(TM) 7" and others start with "Java 7" we need to be able to match either. 

Note that since the name Java(TM) includes parentheses (which are considered special characters in expressions) we need to escape them with a preceding backslash in order to properly evaluate. That is why the (TM) looks like \(tm\).

Also note how Oracle stores the Java versions.

7.0.0  - Java 7 with no updates

7.0.10 - Java 7 Update 1

7.0.90 - Java 7 Update 9

7.0.100 - Java 7 Update 10

7.0.110 - Java 7 Update 11

When we use Version version between 7 and 7.0.100 we are saying "show me versions from Java 7 through Java 7 Update 10".

The expression that we used with the 64-bit collection was slightly different.

^java\(tm\) .+\(64-bit\)|^java .+\(64-bit\)

We aren't using a negative lookahead we are simply stating that the characters "(64-bit)" must be in the string after Java or Java(TM).

That's it. Simple, huh?

Silently Uninstall Java

  

 Email Article  

Tweet  

  

  

"How do I uninstall old versions of Java across my network?" This is a very common question that we hear from Sys Admins.

In this article we will walk through a few options to removing the Java Runtime Environment (JRE) from a single computer as well as from all of your computers. 

We'll post a video at the end of the article.

Uninstall Java from a single computer

If you only have one or two computers that you need to uninstall Java on, you may want to just use PDQ Inventory (pro mode) which allows you to do uninstalls to single computers. 

In PDQ Inventory, locate the computer to uninstall and double-click on the computer name. Select the Applications panel. 

Locate the Java update that you wish to remove, right-click and select "Uninstall" from the pop-up menu.

A new window will appear where you can verify credentials, change timeout settings, etc.

Click the "Run" button at the right of the Command field. The uninstall will automatically begin. 

Uninstall Java from multiple computers

There are two ways to do this:

1. Download our pre-made uninstall Packages from the Package Library. (Advanced subscription required)
2. Create your own PDQ Package and manually enter the steps to uninstall each Java update
   

The screenshot below shows shows 3 versions of Java installed on the computer named Grant. (This data came from PDQ Inventory).  

In this example we are going to uninstall Java 6. We are going to download our pre-made Java uninstall package from the Package Library. 

NOTE: Because this is a multi-step process the Package will require the pro mode version of PDQ Deploy. 

After downloading the uninstall Package into PDQ Deploy, simply select it and click the "Deploy..." button. This will allow you to select your target computers for the Java install.

A Note About Java Uninstalls

The uninstall command varies for each Java update. For example, to uninstall Java 6 Update 31 we used this command:

MsiExec.exe /qn /X{26A24AE4-039D-4CA4-87B4-2F83216031FF} /norestart

However the command to uninstall Java 6 Update 37 is:

MsiExec.exe /qn /X{26A24AE4-039D-4CA4-87B4-2F83216037FF} /norestart

If you are building the package manually you will need to add the uninstall string for each update that you have on your network.

By the way, that's the beauty of using the Package Library. You don't have to do the research on which strings will uninstall which Java update. We do that for you. With dozens of steps to run the package looks pretty daunting. Worry not, it runs quickly.

Video of Uninstalling Java from both single and multiple computers

We recommend viewing this video is High Definition (720p).

Need PDQ Deploy Pro? Request a trial today. NOTE: A pro mode trial does not include a trial of the package library. We do provide some free packages, but to access all the packages, including the Uninstall Java package, will require a subscription. You may get monthly or annual subscriptions. Prices for the Advanced level are $29.00 per month.

Windows 8 Challenges with Patching Adobe Flash

  

 Email Article  

Tweet  

  

  

Windows 8 and Flash are making strange bedfellows. 

Any company that is using Windows 8 is almost certainly still using Windows 7 (or earlier). Supporting multiple versions of Windows can be daunting enough but with Microsoft's decision to patch Flash for IE via it's Windows updates, running both Win8 and Win7 can cause some additional challenges. (Note that Microsoft has only taken over Flash on Windows 8. Flash updates for earlier versions of IE or other browsers such as Chrome and Firefox are still provided from Adobe)

Usually a sys admin hears about a new version of Flash Player and he/she simply obtain the update from the PDQ Deploy Package Library and deploy it to their computers. Done. They check it off their list and move on to some other must-be-done-now-or-you'll-be-fired task. But with Flash and Windows 8, it's now a multi-step process, and quite often, a process that isn't finished in a single day. One option is to just apply the Flash updates to your computers and then wait for WSUS to take care of Windows 8.

Since Adobe and Microsoft are not on the same release schedule, a critical patch provided by Adobe may not make it into the MS patching schedule for several weeks. 

You may deploy patches to your Windows XP/Vista/7 systems and then patiently (or impatiently) wait for MS to release the version for Windows 8 and IE 10. 

This has a multi-platform feel to it that many SMB's may not be used to. Afterall, if your business decides to have Linux/Windows/Mac systems, then you are already used to different releases, different vulnerabilities, different... everything. 

As long as you are sticking with Windows 7 and moving gradually to Windows 8, just be aware that you will likely be doing Flash updates on different schedules. 

For our part, we'll keep the Package Library as up to date as we can. You'll likely notice Flash for pre-Win8 will be out sooner than its counterpart. As an example, we made the IE and Plugin packages for Flash 11.5.502.135 available last week. We are still waiting to obtain the Flash Update for Windows 8 (11.3.377.15). Once we have that we will add it to the Library.