We had a feature request in our PDQ Inventory Feature Requests forum yesterday. The request was asking us to provide a feature that was already available in the current product. On one hand, many developers, ISV's and Sys-Admins would be happy to have such a wonderful turn-around time. "Hey, that feature already exists. Now pat me on the back with a Green Monster drink and tell me that I am, in fact, a god." Instead the requester was, as he always is, very gracious as he replied: "You are 100% sir. I realized this when I happened to look at reports. Sneaky, hidden function."
"Sneaky, Hidden Function"? This observation showed me what I have long feared: Our usability isn't as awesome as we think it is.
To this requester (and to others who didn't realize this feature existed) I simply say "D'oh!"
The easy answer is, of course to provide a video tutorial on running inventory reports. Well, I'm always one for an easy answer so the video is included in this post. Tomorrow we will release another video on how to create your own report.
The harder answer is that we at Admin Arsenal need to do a much better job of making our software more intuitive. Hey JJ, pour two pints of Guinness. We're gonna be here a while.
Already using PDQ Inventory in Free mode? Well kick it into gear and unlock the Pro mode features.
In a previous article I introduced the Package Library from PDQ Deploy. We spoke briefly about the Repository. I want to elaborate a little more about this Repository.
Repository. What is it and what can I do with it?
The Repository is simply a directory on the console computer (or a network share) where installation files can be stored. Any PDQ Deploy Package that you obtain from the Package Library will automatically reference the Repository via the $(Repository) variable.
When we decided to implement the Package Library we knew that we would run into one problem: Location, Location, Location.
We didn't want to have to direct our users to have to choose where to store their respective installation files. In order to get around this dilemma we decided to implement the Repository. After some fairly aggressive testing we decided that the DEFAULT location of the repository would be in the All Users Documents folder. For Windows Vista, 7, 2008 and 2008 R2 this is accessible by going to %PUBLIC%\Documents. In Windows XP and 2003 (there is no declared PUBLIC variable) we effectively use %AllUsersProfile%\Documents.
Change the default location of the Repository.
To change your Repository location, simply go to your Preferences window (File > Preferences) and navigate to the Repository panel. Type in the new path for your Repository in the field provided. Keep in mind, if you use the Pull Copy Mode (available in Pro mode) then your Repository MUST exist on a UNC available share. For example if you wanted to have your Repository in a Windows Share called Install on the server called Dexter you could use
At this time you will need to actually copy (or move) the files in the previous Repository to the new location. A future version of PDQ Deploy will attempt to move the existing installation files when the Repository location is changed.
Custom Packages and the Repository
All of you will have your own Packages that aren't provided by the Packages Library. You can, if you wish, have your installation files also exist in the Repository. You just need to reference the $(Repository) variable in your Package File field.
Our convention for storing installation files is simple. $(Repository)\VENDOR\Application. For example, Adobe Reader install files would be kept in $(Repository)\Adobe\Reader and Google Chrome install files would exist in $(Repository)\Google\Chrome. You can follow this convention if you wish but it's not mandatory. Just remember that Packages provided from the Package Library will use this convention.
So what are you waiting for? Go get your free copy of PDQ Deploy today.