We're pleased to announce the availability of Beta 1 of PDQ Inventory 1.1.2. As always, you can download it from here. This beta is mostly fixes and a few features.
- Uninstall Applications
Applications can be uninstalled from the Applications Panel. This requires that the application have a silent "Uninstall String" value, which most will. This command can be executed with PDQ Inventory or copied and pasted to PDQ Deploy. We will improve the integration with PDQ Deploy in a future version.
- Integration support with the upcoming PDQ Deploy 2 beta. Deploy is moving to .NET 4 in version 2 and this requird changes to PDQ Inventory for the integration to work, so versions of PDQ Inventory earlier than this beta won't work with PDQ Deploy 2.
- Fixed a crash when upgrading from version 1.0.
- Fixed an issue with sending Wake-on-LAN to computers with multiple NICs.
- A few other small fixes, which can be viewed here.
As always we hope you enjoy the software and please let us know what more we can do in our Feature Request Forum.
Get the latest PDQ Inventory Beta
We're pleased to announce the availability of Beta 3 for PDQ Deploy 1.5. You an get it here and try out the new features and changes.
- Schedules can be configured to stop deploying to successful computers, or to computers that have failed a number of times past a certain threashold. This has been one of our most requested features and we're glad to have it available.
- Computers will be deployed to in the order that deployments were created. Prior to this beta, it was possible for a deployment to "jump the queue" and deploy to a target before an earlier deployment got the chance to.
- Schedules can now be set to always use the "default" user, so that they will change if the default user changes. This setting is now the default.
- Allow multiple deployments to the same computer. This will allow more than one user to deploy to the same computer at the same time. This will be expanded in beta 4 to remove the dreaded "Failed to clean-up target directory" error when a prior deployment is still locking files on the target.
Feel ready to give it a go? Download the beta from here and sign up for e-mail updates when new versions are available.
We're pleased to announce the first beta release of PDQ Inventory 1.0.2. It's available now for download.
There are a couple of larger features that should be highlighted:
- Active Directory collections are now available.
For those of you moving from AA Console, this will probably be a welcome addition. Computers that are in Active Directory are automatically placed within these collections, which are themselves automatically generated.
- New data grids.
We've moved over to the same data grids which we introduced in the last PDQ Deploy beta. These grids have a number of nice features for filtering and grouping, as well as doing a better job of printing.
- Copy and paste of scanners and scan profiles.
- Additional options for deleting computers during an AD Sync.
Deleting computers during a sync has always been a bit problemmatic, and now we have 2 deleting options. One option is for when you have a mix of sync'd and manually added computers, and the other for when you have only computers from Active Directory.
- Computer tools can now be used from reports.
Not all reports can use computer tools, because each row doesn't resolve down to a single computer, but most reports will work fine.
In addition to these features there are a number of bug fixes. You can get all of the juicy details in the Update Notes.
As always, we hope you enjoy the changes and we look forward to getting your feedback.
Download Latest PDQ Inventory Beta
Sign up to receive e-mail notifications of new updates
We're pleased to announce the second beta release of PDQ Inventory 1.0.1. It's available now for download now.
This beta focuses mainly on bug fixes but there are a couple of small new features.
- When the console starts it will check the PDQ Inventory's credentials and make sure that they are set correctly, restarting the service if needed.
- Added a desription to collections. The description shows up in the header on the collection page.
- Renamed the Scan Date column on computers to Attempted Scan Date to better reflect the value. The next beta will include Successful Scan Date which will contain the date of the last successful scan.
- Added collection filters for Local Users, Local Groups, Local Group Members, and Shares.
The big new feature, however is SQL Reports. Now there are 2 types of report: Basic, using the report builder, and SQL which allows for reports to be created using any valid SQL. Please give it a try and let us know what you think.
Our next scheduled beta will be Beta 2 of PDQ Deploy and Deploy Pro. This beta is taking a bit longer because of one large change. This new version will combine PDQ Deploy and PDQ Deploy Pro into one product. It will work like PDQ Inventory in that it will have a Free and Pro mode. We're going to use the PDQ Deploy product name and it will actually be released as version 1.5.0 (Beta 1).
It's taking some more time to test because the software needs to upgrade both PDQ Deploy and PDQ Deploy Pro. Since it's using the PDQ Deploy name it will install over PDQ Deploy and along side PDQ Deploy Pro, so that you can still run PDQ Deploy Pro while testing PDQ Deploy 1.5.
Thanks again for all of your help with testing the betas.
Download PDQ Inventory 1.0.1 (Beta 2)
Sign up to receive e-mail notifications of new updates
After all of the great feedback we got on our most recent beta (thanks again to everyone who participated) we've made a small change to our release cycle to keep the feedback alive. It's mainly for those of you who like to keep on top of the latest developments and enjoy the wild and crazy life on the bleeding edge. We have so many great new suggestions to implement that we want to make sure to get them into the hands of users as soon as possible, but without causing unnecessary headaches for users who want or need things to stay more stable.
To this end we're introducing a new "rolling beta" system. Under this new system all of our products will have a new beta release every couple of weeks (plus or minus a few days). Some of these releases will be fairly minor with only a few small tweaks for fixes, and others will introduce new and larger features. We'll try to keep them as small enough that they don't introduce too many changes at once, but large enough to make it worthwhile to download them and give them a try. Getting the betas will be very simple, no need to do anything special, no special licenses required, no sign-up, and no expectations to provide feedback or bug reports (but they're always welcome). If you want to keep working only with stable releases, then there's nothing to do as the betas are entirely "opt-in".
Getting the Betas
The first of these rolling betas will have already come out by the time you read this. To get them you can follow one of these links below. These links will always get the most recent betas.
PDQ Inventory Beta | PDQ Deploy Pro Beta | PDQ Deploy Beta
If there isn't currently a beta available because the latest stable release is more recent, these links will get that release instead. In essence, these links will always be the freshest.
You can always access the Update Notes for the most recent betas using these links.
PDQ Inventory Update Notes | PDQ Deploy Pro Update Notes | PDQ Deplo Update Notes
Getting Notifications of New Betas
Our products have always included an optional Auto Update Check which can notify you within the application that a new version is available. When running a release version of the software this auto check will only look for newer stable releases (and skip betas). Beta versions also check for new betas and starting now (in the current betas) you can set an optional flag to always look for new betas even when running a release version (available in the preferences).
Additionally, you can sign up to receive e-mail notifications of new betas. You can then decide whether the changes in the beta are something you want to try.
As mentioned above, feedback is always welcome. We have always followed a "squeaky wheel" policy, as some of our sequakiest wheels know. We're not always able to get to suggestions right away, especially for the larger or more complicated features, but rest assured that we take all feedback very seriously and everything gets logged into our database for implementation in the future. You know your jobs better than we do. There hasn't been much that we've discarded, though sometimes we do combine ideas or make changes so that the ideas work more generally. And don't be shy about suggesting something twice or bringing it back into our attention, it'll help us to gauge the need and prioritise.
Feedback on betas can come in using any of our support channels but the best way is to use our Forums as this will let other users see the suggestions and comment or add to them.
We're hoping that keeping this second method of public releases alive will provide a good balance between stability and a faster feedback loop. We may make adjustments as time goes on depending on how things go (speeding up or slowing down updates, or maybe adding a third type of release). We want to provide a way for you to feel a part of the development cycle, and hopefully this will provide that.
PDQ Inventory Beta | PDQ Deploy Pro Beta | PDQ Deploy Beta
We are pleased to announce that the PDQ Inventory beta will go public in the next few days. This first beta will combine PDQ Inventory and PDQ Inventory Pro into a single application instead of being separate applications as was initially planned. This will keep the functionality of both the free and pro versions more closely in-line and make our entire development turn around much faster. No more lag time between features going into pro that also go into free. PDQ Deploy will soon be following suit with this design as well.
The application will run in two modes: Free and Pro. Free mode has a subset of the features available and the rest can be unlocked by entering a Pro mode license key. All beta testers are entitled to a license key which will be valid for the duration of the beta. At the end of the beta license period the application will revert to Free mode. You can then enter a 30-day free trial or full license key to go back to Pro mode without losing any data or settings.
Sign up to be notified when the beta starts and receive a free beta key
There are a few features that didn't make the cut for the first beta, but we will be adding them over the next couple of weeks along with some of the suggestions we will certainly be receiving. We're very excited to get this product into your hands as it will allow us to tackle many of the feature requests of AA Console that have been held off until the release of PDQ Inventory Pro. You can expect to see a lot of new features coming out quickly over the next few months.
This new beta will be called "Beta 9" to keep it in sync with the current Beta 8 of PDQ Inventory. If you are currently running Beta 8 of PDQ Inventory then it will update itself to Beta 9 of PDQ Inventory Pro.
Thank you to all those users who have been testing PDQ Inventory and we hope you like the new Pro features we've added and will be adding.
If you've used both AA Console and the beta for the new PDQ Inventory you may have noticed a couple of differences in collection filters. The biggest difference is how filter fields are structured.
In AA Console each field is searched individually, which makes the filter engine simple but does lead to some consequences in that you may not get the computers you're looking for. So, for example, let's say you have a single computer in the database and it has 2 applications in inventory, thus:
If you want a collection showing computers with Adobe Reader versions other than 10 you might create the following filter:
This seem like like an obvious way to get what you're looking for, but once you realize that it's matching the applications individually, you see a problem.
||Matches filter 1
||Matches filter 2
You would expect your computer to not match the filter because it has version 10.1 of Adobe Reader, but it does because it has another application that doesn't have 10.1. We got around this in AA Console by adding a new field called Application Name and Version which concatenates the name and version in a single value to allow for them to be matched together. But this doesn't help with all of the other fields that you might want to work with.
PDQ Inventory resolves this problem by grouping fields underneath their respective types of inventory data. Now, to implement the logic above you would just create a single application filter:
The new architecture of the PDQ Inventory filters allows this to be done easily and logically. You can even add more Application filters to the same collection to combine the varous filters.
This issue has been one of the more confusing in AA Console and we're glad to finally be able to clear it up with our new software. If you haven't had a chance to try out PDQ Inventory, please give the beta a try. The software is free to use just like PDQ Deploy and we hope you find some good use for it.
One of the new options in PDQ Deploy 1.4 (available in public beta) is Pull File Copy. This new option overcomes a drawback of PDQ Deploy Pro 1.3.
Push File Copy
Prior to version 1.4, the only way to get installer files to target computers was through push file copy. With this method, PDQ Deploy Pro would copy files down to the target computer's ADMIN$ share. Since PDQ Deploy Pro runs on a single computer it meant that the files all went through the connection betwee the PDQ Deploy computer and the target. If the target computer was on the other end of a thin WAN pipe it meant that all files were going through that same thin pipe. This was a particular problem if the source files were also on the other end of the pipe because the files would be copied up the WAN to the PDQ Deploy computer and then back down to the targets. Not an ideal scenario.
Enter Pull File Copy
Pull copy gets around this problem by only pushing down to the targets a list of files to copy, which the target computer uses to get the files it needs. A good solution to this problem, it is also something that needs to be used with care.
By default, Pull File Copy is turned off. This is because push file copy is more robust, even if it can be slower. For installer files to be pulled to the targets they must be available over the network via a UNC Path. PDQ Deploy Pro does its best to make UNC paths available to all target computers for use in pulling files. If the files used by PDQ Deploy Pro are on public shares then there should be no problem. However, if the files are on local disks, or through mapped drive letters, then there could be a problem accessing them through pull copy. For example, a file called "C:\Installers\Installer.msi" would not be visible to a target, it would be converted to "\\Computer\C$\Installers\Installer.msi" which may not be accessible to the target (because of a firewall, permissions issue, or name resolution problem). As long as all installers are using well known public paths, then all should work well.
Pull file copy can be turned on for the entire system or for each installer individually. Each installer can use either push, pull, or the system-wide setting (which is the default). In a future version we're looking at making pull vs. push be made automatically on a per-computer or per-file basis. Please let us know if this option is useful to you, and how it can be exted to make the system work even better.
Photo by Bohman
One of the most asked for features in PDQ Deploy Pro is the ability to use local administrator credentials for deployments. Local, in this case, meaning local on the target computer. This is necessary to allow for deployment to non-Active Directory computers and can also be useful when using a domain.
As I mentioned in my post last week announcing the beta for PDQ Deploy Pro 1.4 we now have this feature. I'm going to go over a few things to keep in mind when using local administrator accounts.
Specifying Local Admin
The simplest way to use a local administrator account is to simply leave off the domain name. When the user name has no domain then it is treated as a local account and the connection to the target computer is made directly. This operates the same as though you had used the target computer's name as the domain. In fact, you can use the target computer's name instead of a domain, but that would limit the credentials to be used only on that one computer.
Omitting the domain name is fine for most situations, since it's common practice to use a single administrator account name and password throughout a given network. But this won't work when a different password is used on different sets of computers. For this situation you can us a dot prefix (or period or full stop depending on your language persuasion). Any domain name that starts with a dot will be treated as though there is no domain in the user name. For example, all of the following user names are treated as the same local account:
Each of those users can have a different password.
Network Resources and Pull File Copy
Local administrator accounts present special problems for deployments that require access to network resources, such as batch or script deployments that need to copy files or when using the pull file copy method in version 1.4. Local administrator accounts can have access to network resources provided that there is a matching local administrator account on the computer with the resource. That is, the name and password must be the same.
You can avoid the need to access network resources by using push file copy and the new Additional Files option within an installer (which copies files to the target computer that would otherwise need to be read off of the network).
There are still things that can be done for the next version of PDQ Deploy Pro with credentials, such as computer specific credentials for situations where the local admin passwords vary across the network. We're still narrowing down the list of features for 1.5, so please feel free to let us know what else you would like to see with credentials (or anything else, actually).
I'm pleased to announce the availability of PDQ Deploy Pro 1.4 Beta 1. This upgrade is packed with new features, most of which have come from the user community. Please feel free to download it and let us know what you think. If you've participated in betas in the past you may need to get a new license key for this beta, which you can get from the above link.
Now, on to what's new. There are three major changes in this beta, and quite a few smaller ones. The big three are:
Version 1.4 can now store multiple sets of credentials for use in different deployments and schedules. These credentials can be in different domains or be non-domain (i.e. workgroup). When creating credentials simply don't enter a domain name and the credentials will treated as a local account on the target computers.
This new change also means that the PDQDeployPro service doesn't need to run under a user account, it sticks to Local System which makes the installation and operation of the service much simpler.
Target lists have two main capabilities. First, they allow for storing lists of computer targets within PDQ Deploy Pro making it easy to maintain groups of computers for various deployments.
Second, and perhaps most useful, is Linked Targets which creates a link between PDQ Deploy Pro and other systems. For example, a schedule can link to an Active Directory container so that when the schedule runs it always gets the most up-to-date set of computers.
Pull File Copy
This feature is probably our most requested one. Now there is an option to have PDQ Deploy Pro pull files to the targets rather than push them. The main benefit is for those who are connecting to computers over a slow connection where the installation files are also on the other end of that slow connection. The PDQ Deploy Pro service will send a list of file paths to the target computers instead of the files themselves.
For this to work all of the files that make up an installer must be readable by the target computer and the credentials used by the deployment. Pull copy is turned off by default, it can be turned on in the Performance section of the preferences. This global setting can be overriden by any individual installer.
There are many other changes as well. A couple of the bigger ones are listed below.
Improved Deployment Status
The deployment status display has been revamped. Now there's no need to open a second window to view the status of a deployment. More detail is also provided including the speed of the file copy.
Improved Schedule Details
Schedules now display how long until their next deployment and how long since their last deployment. Deployments also display which schedule started them making easier to see how well the schedule is working. Additional information is also logged to the application event log when schedules run.
A global setting is now available to timeout installers if they run for too long (useful for installers that aren't running silently).
Installers can now include additional files without including all fo the files in the same directory. Makes it easier to include configuration or transform files without affecting how the installer files are organized.
There were many other new features that we wanted to get to in this version, but we had to draw a line. Rest assured, any request that you've made in the past is still on our list and we're looking forward to a big 1.5 in a few months.
We hope you enjoy this new version and as always we will be giving away free licenses to users that provide useful feedback, especially bug reports.