Posted by Shane Corellian on Mon, Aug 15, 2011
The ability to group your computers in pretty much anyway imaginable is only a few minutes away. Since I know that all of you have mastered typing and using your mouse with one hand - for various reasons I shan't delve into - you don't even need to put down your Mountain Dew to get things started.
First, though. Why would you want to have different groupings for your computers? A lot of reasons. It's pretty much the same way you may organize your music, videos, finances and pr0n. I have so many great dynamic and static Playlists in iTunes and, for the most part, any of my 35,000 songs are always near to hand. PDQ Inventory Collections, like their AA Console predecessors are just as useful and easy to create.
Here is a quick video where we demonstrate building the two types of collections: Static and Dynamic. You will also see how to create sub (or child) collections.
The examples shown in that video were performed using the free version of PDQ Inventory. We will also show video examples of how to use some the better, more comprehensive, features available in the Pro version of PDQ Inventory.
Please give us examples of what types of tutorials you'd like to see. Having a difficult time with a feature? Have you run into a problem that you think you can solve with PDQ Inventory or PDQ Deploy but you just don't know how? Well, send us an email or, better yet, post your question on our support forum.
Posted by Adam Ruth on Mon, Jul 18, 2011
If you've been using the PDQ Inventory Beta and creating your own collections you've probably run into the filters for Date & Time data. These filters have some interenting features that you will want to be aware of in order to narrow right down on the data you want.
There are two ways to enter a date filter, either by typing in the value in the box:
or by using the ... button to open an edit window:
Fixed and Relative Dates
You may have noticed in that screen shot above the Fixed and Relative options. Fixed dates are pretty self explanatory, i.e. the filter is based on a single date & time. Relative dates are where these filters get really interesting.
Filtering based on relative dates creates a "sliding window" of time that computers are either inside or outside of. These are the only type of filter that can change collection membership without a rescanning of inventory. As the window of time moves, computers are moved around collections as needed.
Getting computers not rebooted in the last 30 days or computers where the last scan is more that a certain age is a snap.
Text Format
When entering a date / time filter as text (as in the first screenshot above) there are a number of different ways to enter the values to get just what you want.
Fixed
Fixed dates and times can be entered however your system will recognize them. Any of the following below work on my Australian formatted dates:
5/3/2011
March 5, 2011
5 Mar 2011
5/3/11 5:00 pm
Relative
Relative times can be entered in two different ways. First, written out:
30 days ago
1 hour from now
30 minutes ago
The time unit can be one of Day, Hour, Minute, or Second (either singular or plural) followed by either "ago" or "from now." You are limited to a single time unit, though, so "1 hour 30 minutes" must be written as "90 minutes".
For a bit more flexibility, you can use the more compact time span expression:
3.4:13 [3 days, 4 hours, 13 minutes]
1:25:30 [1 hour, 25 minutes, 30 seconds]
The system tries to be as flexible as possible, but it should be pretty easy to determine the format to enter. As always, the pop-up editor can be used if you're not certain.
So, now that you know how to use date/time filters, go forth and create the perfect collections!
Posted by Shawn Anderson on Fri, Jun 17, 2011
We often do posts on installing Java updates, but recently we've had some users who need to know which version of the JRE is installed on their computers.
So I'm going to demonstrate using some new tools that are still in beta, but are generally available should you choose to be a tester.
First off I'll be using beta 2 of PDQ Inventory.
Once PDQ Inventory is installed, import this Java collection.
This will give you a parent folder (Java) with three children collections. The children collections are all dynamically populated following the inventory scans.
To see which version your systems are at just click on the collection folder. You can then deploy Java 6 Update 26 (or the most current version of the JRE) to these systems.
From here you're ready to fire up PDQ Deploy or PDQ Deploy Pro to push the updated JRE to your computers.
I'll post instructions for the Java 6 Update 26 later, but the instructions should be similar to the one found in update 25 (see link above).
Get your free copy of PDQ Deploy
Get the Beta of PDQ Inventory
Posted by Shane Corellian on Mon, Mar 28, 2011
In this article we will create a Custom Inventory Report inside of Admin Arsenal. This report will show all computers that do NOT have Symantec Antivirus service installed / configured.
From the main window in Admin Arsenal select "New Report..." item in the Reports menu.
Now we write our query. I used the Fields dropdown menu to select the appropriate Table / Field.
This query simply requests that the Computer Name, AD Description, OS Name and Last Inventory Scan Date be returned for every computer that does NOT have a Windows Service called Symantec Antivirus.
Click here to download the video if you cannot access the YouTube version above
Another Example
If you want to see a list of all Oracle software and versions on all servers you can use this SQL:
select
Computer.Name as "Computer",
Software.DisplayName as "Software",
Software.DisplayVersion as "Version"
from Computer inner join
Software on Software.ComputerId = Computer.ComputerId
where Software.Publisher like '%oracle%' and
computer.osname like '%server%'
This is an updated post from 2010.
Posted by Shane Corellian on Wed, Oct 20, 2010
Check out our Admin Arsenal Tips and Tricks forum on our Support site. We have added some more queries that give System Administrators even more visibility to their network inventory. We are going to keep throwing new reports in these forums. If you have particular need to find or report a new aspect of Inventory, let us know by posting the question on our Support Forum.
Recently added: Show which accounts (Group or User) are in your various local Administrators groups.
Also: Show which computers have shared directories which have non-administrative users granted Full Control. The video below will guide you through adding the custom report to Admin Arsenal.
If you don't use Admin Arsenal, hey, give us a try. Admin Arsenal has been around for almost 4 years and our small group of banditos have been Sys Admins since the early 90's. We offer a full-functional 30 day trial. If you don't like what you see (you'll like what you see) then no hard feelings and we won't even mention it at the next family reunion.
Posted by Shawn Anderson on Wed, Sep 29, 2010
Remotely Install Vista Service Pack 2 in only 5 Steps
This step-by-step, and the included video, will demonstrate a remote installation of Vista SP 2 to multiple computers, simultaneously.
NOTE: Vista SP1 must be installed before applying Vista SP2.
NOTE: If you aren't certain of the version of Vista service packs that are currently installed, you can use a free 30-day trial of Admin Arsenal, our system admin product which scans computers for installed software.
Now, let's get to work and install Vista Service Pack 2.
Step 1: Select the Vista SP2 install executable
Click on the elipses button and navigate to your downloaded exe for SP2. Since this installation requires only one file, you do not need to select the "Include Entire Directory".
Step 2: Enter the Command Line Parameters
Enter the parameters into the Command Line Parameters field (shown above).
/quiet /norestart
Here is a list of all the command-line options available when remotely deploying Vista SP2.
Step 3: Select Target Computers
Select the button "Create Deployment". The next screen appears and you are now able to enter (or select) the target computers to deploy Vista SP2 to.
You have four methods of selecting target computers.
- Manual Entry
- Import a Text File
- Active Directory
- Admin Arsenal
Step 4: Select Authentication Account
Select "Next Step" to choose an account to perform the installation. By default your current account is selected.
Step 5: Deploy Vista SP2
Click "Next Step" and you'll see a verification page for this deployment. If everything looks good then you may start the deployment by clicking "Deploy Now".
Your computers will now receive the upgrade. The status will be shown within PDQ Deploy.
This installation is moving a lot of data, plus the installation itself is rather involved. Plan on between 30-60 minutes for each computer.
NOTE: The command line parameters that we supplied suppress any required reboot. It is highly recommended that you reboot your workstations as soon as possible following the service pack installation. If you are able to do the installation off-hours then you may wish to use the /focerestart option.
You know, working after hours reminds me of a maintenance window I performed about eight years ago. Another sys admin was joining me and we had arranged for him to bring in some food for the long night ahead of us. He brought me 20 tacos from Del Taco. TWENTY. They weren't for both of us, they were for me. Just me. I was floored. I think I was able to eat maybe two of them.
I never found out why he brought me so much. Perhaps he had spatial issues and had a difficult time correlating the size of my gut to the sheer amount of ground corn and beef that constitutes twenty tacos.
Anyway, I digress... we're done with the deployment of Vista SP2.
If you are using the free version of PDQ Deploy, the installation will continue in increments of eight computers.
Using PDQ Deploy? It's free and available right now.
Follow me on Twitter:@ShawnAnderson
Posted by Shane Corellian on Wed, Jun 16, 2010
Photo by Jean-Michel Folon
It still amazes me how many system administrators don't feel the need to understand the under-pinnings of Systems Management. I push a button and software gets installed on a remote computer. I run an inventory scan and suddenly I have a list of installed software.
I'm constantly reminded of the Sidney Harris cartoon "Then a miracle occurs". How did that software get installed? Where does SCCM extract the list of installed software on each machine? How does Admin Arsenal know if a laptop has a smart-card reader?
If I have a prayer of performing any meaningful troubleshooting when problems occur, then it is essential to understand the How, Where, and What of the my environment.
You can, very quickly, determine if a person troubleshooting a problem has a good understanding of their environment. If they don't understand what's going on under the hood, then their troubleshooting amounts to little more than memorization. If "problem A" occurs, then "solution A" is the answer. "See, it's clearly written in this KB article." But what happens when the correct answer isn't, in fact, "solution A" ? What happens when the problem doesn't even have a description in the knowledge base?
I know, for example, that Tivoli retrieves its Installed Software list from two sources: A) Data stored in the "Uninstall" key of the registry; and B) Signature data where software names, publishers and versions are mapped using a file name and its corresponding file size.
If some software that I am expecting to see listed as being installed doesn't show up in an inventory report, then I should know exactly WHERE (on the target computer) that data is supposed to be found. I will be able, therefore, to troubleshoot more effectively. If I know HOW the scanned data is expected to move from the registry of the target computer to its ultimate entry in a database, then I can more effectively determine when and where any errors are occurring during transit.
My next few blog posts will be about some of the under-workings of common systems management tools.
Follow me on Twitter @ShaneCorellian
Posted by Shawn Anderson on Fri, Feb 05, 2010
Photo by Rennett Stowe
Last Friday I elaborated on the first four mistakes made by windows administrators in their collection of PC inventory. Today I conclude by jumping into more detail on numbers 5-7.
To refresh, here is the list.
- Limiting inventory collection to entries in Add/Remove Programs
- Excluding important registry entries
- Giving them what they 'ask for'
- Limiting inventory scans to .exe files
- No master baseline table to compare against
- Data is static
- Poor reporting
Let's jump into number 5. If you scan for all files that are executable and do a count search on any random PC you'll discover that the average workstation will contain well over 10,000 of these types of files. Gathering this much information will make you data rich but information poor. Make your data meaningful by comparing what you collect against what you are expecting (or what constitutes a vulnerability if performing a security scan).This is done by storing an expected baseline in a database table.
Number 6 is the static problem. This usually results when your reporting (or collection) is stored on spreadsheets. This is especially true if data is manually gathered. Be careful with this method - remember that your decisions are only as good as the data that they were based on. A good automated scanning solution writing to a relational database is the most desired method.
Ahh, number 7. This last item is perhaps the most dangerous because it impacts organizations that have the best inventory scanning solutions as well as those who only collect manually. It's the inability to report what you have.
SQL skills are essential when you're dealing with data stored in a relational database. I learned this years ago when I had a organization level manager ask for a report of all installed software on his computers. When I provided him the list he quickly stated that it was wrong. It was too granular (see item 3). He didn't want to see every Microsoft hotfix listed. He also only wanted to see one entry for Microsoft Office, rather than each component (Excel, Word, Powerpoint).
In short he wanted an inventory summary rather than an installed software report, even though he specifically asked for "what was installed on his computers." Remember, what they want and what they ask for are sometimes quite different.
SQL knowledge as well as a baseline of expected software (see item 5) would've done the trick. Instead of listing all the hotfixes installed I should have compared against a table listing required patches and reported the discrepencies.
On the Microsoft Office issue certain components discovered could be compared against a table to reflect the Office installation as a whole.
The frustrating outcome is that this manager concluded that we didn't know what was installed. Even though we were scanning registries, looking for many types of executable files, and even scanning for .exe header information, without the reporting skills I wasn't able to show what we knew. In a way he was right. I resolved to make reporting a central feature of inventory collection.
Afterall, if you can't show someone what you know, you might as well not know it.
Posted by Shawn Anderson on Fri, Jan 29, 2010
Photo by Rennett Stowe
Windows administrators are often bearers of news. Sometimes good, sometimes bad.
When the news is good, you look like a hero. When it's bad you offer suggestions on how to a) deal with repurcussions, and b) avoid the problem next time. While no one likes to give bad news there is something worse... not knowing.
When it comes to knowing what software is installed on the computers that you manage there are myriad ways to discover. Here are the 7 reasons a windows administrator might not know what is installed on their systems:
- Limiting inventory collection to entries in Add/Remove Programs
- Excluding important registry entries
- Giving them what they 'ask for'
- Limiting inventory scans to .exe files
- No master baseline table to compare against
- Data is static
- Poor reporting ability
Number 1 is quite common. Software inventory is much more than what is listed in Add/Remove. While true that most of what you'll need to report on will be gleaned from this section, sometimes the data you need isn't a stand-alone program per se, but rather a file or group of files that together may cause a vulnerability.
The solution is to determine what you are looking for and then find the right solutions, be they over the counter or custom scanning ability. Keep reading to see some common mistakes made by admins on the quest for too much information.
Number 2 isn't answered easily. The registry is a big place and it's easy to get lost. You need to know what you're looking for before you create a custom scanner to glean registry data. That said, sometimes the registry is the only place to get the data, especially when you are looking for the configuration of specific applications.
Number 3 is a fun one. We all know that what a customer asks for isn't necesarily what they want. I'll elaborate a bit more in the end of the artcile, but suffice it to say that gathering every piece of information on the computer won't help much if you can't put it into their perspective.
Number 4 is a common mistake made when an admin tries to venture beyond Add/Remove. Simply put, they scan for all .exe's while forgetting that there are many files that are executable.
Keep an eye out for some of the following (certainly not an exhaustive list):
The next mistake is looking for too much, which takes us to number 5, which I will cover in next Friday's blog post.
Posted by Shawn Anderson on Wed, Jan 06, 2010
A recent slashdot article on IT Administrator abuse might more appropriately be titled IT Administrator Biases. It brings up an excellent point which highlights the known fact that, generally speaking, IT departments are horrible at eating their own dogfood.
The example in the article points to the blocking of forums or discussion groups, but leaving wide open the access for Digg, Fark, and Slashdot.
My experience points to management deference. They either don't understand or don't want to understand the nuances of IT life. They will often accept point blank what their IT guys say. In a way this is beneficial. Afterall, most companies don't make money from their IT departments.
While it could generate bad will among the rank and file within a company I think little is likely to change.
It goes much deeper than website blocking. IT admins will commonly install software on their systems that has not passed internal security checks or is not documented or even (gasp) licensed.
I recall running a software inventory scan for a client only to find several sys admins who had sniffer applications installed. To say that 'it' hit the fan would be an understatement.
All in all it will build a stronger environment if the IT department eats the same dogfood, but then again, how would we get anything done if that were the case?