Mixed computer environments are pretty common, so it was pretty clear out the gate that we needed to include a way for admin to use multiple credentials when using PDQ Inventory to collect inventory.
A common setup is an organization that has most, but not all, of its Windows computers managed in Active Directory. The non-domain computers also need to be scanned. Another situation that we see quite a bit is the multi-domain environment.
In this video Shane demonstrates setting up multiple credentials in PDQ Inventory and assigning which accounts are for which computers.
Remember, PDQ Inventory requires admin privileges on all the computers that it scans.
Collections are the secret to making PDQ Inventory one of your favorite admin tools.
Shane put together a video which shows a step by step into creating multiple collections which server many purposes. He uses computers with or without Silverlight in his example.
Remember that with the pro mode of PDQ Inventory you can sync with Active Directory.
We've written several articles on deploying Adobe Reader to your systems.
These articles contain deployment methods that certainly work however let's get a little more advanced this time. Basically, we want to leave the stone-age of brute force deployments and only deploy the latest Adobe Reader to systems that don't already have it installed. So, assuming you have PDQ Deploy installed and you have built your installer for Adobe Reader (see the above articles) let's move forward. Oh, you'll need to install PDQ Inventory as well. If you aren't using it yet, no worries, it's free to use.
Now, we can accomplish what we want by creating the necessary Inventory Collections which break down which systems do or don't have Adobe Reader and which systems have older versions of Adobe Reader.
Open PDQ Inventory. Make certain your computers have recently been scanned. You can import the Collections or you can just create your own from scratch. To import the collections, extract the XML file from the zip archive and import via PDQ Inventory. (Go to File > Import or hit CTRL+i).
Here is what our Adobe Collection hierarchy will look when we finish.
Our first Collection is called Adobe Reader. It has only one filter which includes all systems which have any application whose name contains "Adobe Reader".
Our next Collection will contain all systems which have Adobe Reader X (version 10)
Now let's break it up a little more. Let's create a collection which contains ALL systems that have Adobe Reader version 10 BUT don't have the latest version of 10.1.3. To tdo this we will use the "version between" comparison. BTW, when you use "version between" the beginning and ending numbers ARE INCLUDED in the range.
Let's create a collection which contains all systems that have the latest version of Adobe Reader. At this writing the latest version is 10.1.3. This way we can expect membership in this collection to increase as we deploy the latest 10.1.3 (and the targets are subsequently scanned).
This collection will contain computers which have Adobe Reader but the version is lower than 10. (e.g. Adobe Reader 9)
Now let's create a collection to contain all Servers that do NOT have ANY version of Adobe Reader. The collection below will probably be confusing. Look at it carefully. Notice that we have changed the Match Criteria (highlighted in yellow) from the default "Match All" to "Don't Match Any". Normally the Collections filter IN systems which match the filters. In the case below we will change the behavior to filter OUT systems which match the filters.
We also have created 2 different filters. The first is an Operating System filter. In it we say that the Operating System Name does not contain the word "server". Normally (using Match) this would mean that only Windows workstations would be members. However, since we are filtering OUT (Don't Match) the filters the opposite will happen. Only machines that have the word Server in their OS Name will be included.
The second filter is an Application filter. In it we say that an Application name contains Adobe Reader. Once again, this would normally include computers which have this application however our Don't Match changes that. Now we filter OUT systems which have Adobe Reader.
OK, you may be asking "Hey Shane, why don't you just have two filters where the first says Operating System contains server and the other says Application Name does not contain Adobe Reader?"
This logic is understandable but it is flawed. When you create an application filter that says "Name does not contain Adobe Reader" you are effectively saying that you will include any computer which has any application where the name doesn't contain "Adobe Reader". This means that a computer that has an application called "Microsoft Office 2010" would be included in the collection EVEN IF IT ALSO HAD ADOBE READER. This is expected in SQL logic. Let's say that I have a computer called Butters with 3 applications installed. The installed applications are Microsoft Office 2010, Adobe Reader and Mozilla Firefox. This filter would be applied 3 times (once for each application) and if it found an application that didn't contain "Adobe Reader" the test would pass. If you were typing the raw SQL n a query you would resolve this problem by using the Group By clause NOT HAVING. Well, by changing the Match to Don't Match we are doing the same thing as using a NOT HAVING. Therefore by having a filter that says "Name contains Adobe Reader" we would find all systems that had any application called Adobe Reader but changing Match to Don't Match (but keeping the filter the same) we would strip out any computer that passes the filter "Application Name contains Adobe Reader".
The collection below is similar to the example above except in this one we are showing only Non-Server systems that don't have Adobe Reader. Note, however, that I added a third filter. This filter will effectively remove any computer that has never been successfully scanned by Inventory.
Why is the third filter important in this case? Well, let's say we have a computer called Homer. Homer has never had a successful inventory scan. With no inventory Homer would pass the filters below. Think about it. It would pass the first filter because it does, strictly, have an OS that doesn't contain an OS name containing the word "server". It passes the second filter because it doesn't have an application called Adobe Reader. According to Inventory it doesn't have ANY applications so, once again, it passes the test. I want to filter out Homer (and any other computer that has never had a successful inventory scan) until I know for sure what applications exist on Homer.
In my lab these are the systems which are in this collection.
Now let's see what happens when I remove the Computer Never Scanned filter. Note that I have two computers, Homer and Malory, that have never been scanned. Since they both pass the collection filters they show up.
OK, now I can deploy Adobe Reader to the appropriate computers. If I wanted to deploy version 10.1.3 to my workstations that are missing Adobe Reader I would simply right click on the collection and select Tools > PDQ Deploy. (You need to have PDQ Deploy installed). Select your Adobe Acrobat Reader installer in PDQ Deploy.
After you select your installer you will see that the computers in your selected collection are added to your Deploy Now window.
Follow @admarsenal on Twitter to get more tips and tricks
We've enjoyed our association with the folks from the Professional IT Community Conference (PICC) the last couple of years. It's nice to see local IT sys admins taking control of local conferences.
Local conferences are great, and I'd like to see more of them pop up. It's always a plus to network with local sys admins who are facing some of the same challenges that you are. Plus, it's just plain nice to attend a conference without needing to jump on a plane or pass a kidney stone when you see the hotel room mini-bar prices.
I had the opportunity to exchange some info with John Boris, a past attendee who will be making it to PICC 2012 in New Brunswick, NJ.
Q: What are the three reasons you continue to attend PICC?
1. Low cost Training in my back yard. You can't beat the price. Getting a full day of training runs twice that much and you can get two days. The instructors have been top notch so it is a no brainer for me.
2. Community experience. Besides the training and presentations there is the Hallway track and dinner. You get to meet a lot of people during the breaks and meals. It is neat to have exchanged emails with a person for a year and then meet them face to face.
3. To learn new things. I live my work life at a command prompt on an operating system that is way past end of life. So being able to get somewhere and see what is going on is a plus. Getting to see how someone else solved a problem or handle an issue is something that you can find at PICC.
Q: Do you feel that there are differences between local sys admin
conferences and national conferences? If so, will you list one or two?
The one big difference between a national conference and a local one, in my opinion, is the closeness of the venue. The training sessions may not be as diverse as a week long conference but at PICC you will most likely meet and speak to every attendee at the conference. That is something you would not do at a big National conference.
Q: As a sys admin, what have you learned from past PICC conferences that
you implemented into your daily workflow?
One main thing I have learned at PICC is Time Management through Tom Limmoncelli's Time Management for System Administrators class. From his class and his book I implemented a Request Tracker (RT) system at work to handle my Tecj support calls and practically everything that I need to track goes into that system. The use of RT in my work has streamlined my desk and has kept me on track. This is coming from an person who has to support 500 users, 25 servers over a five county area plus an office of administrators.
Thank you to John for taking the time to share his thoughts on PICC. If you are interested in attending a conference in your local area check out The League of Professional System Administrators (LOPSA) which lists local IT conferences.