PDQ Deploy 1.4: Pull File Copy

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.

Windows Installer Error 1603: Behind the Rage

I'm going to spend some time on this damn error. I swear this error message is the "exit code" dumpster for Windows. It seems, on its face, to be the most useless exit code consistently thrown by Windows.

Well, maybe not. 1st things first, what do those "close" to this error say about 1603?

"Well, we know he grew up in a decent neighborhood. He wasn't incredibly popular but he had a few good friends. He enjoyed listening to RATT and Twisted Sister but he also waited in line for 2 days to get 3rd row seats to see Depeche Mode during the Black Celebration tour.

His given name is: ERROR_INSTALL_FAILURE. His SSN is 1603. His Family Crest is thus emblazoned: A Fatal Error Occurred During Installation.

It was with Windows XP that he went through puberty. All of the normal issues of a maturing American Error Code were present in 1603 during this time. Acne, Braces, Body Odor and, of course, Nocturnal Emissions. Slowly he started losing friends. Within 6 months he was compared to a Steven Jesse Bernstein poem. He was quickly becoming the loner that we know today. 

"He's probably the hardest working error code out there" says Nils Sille, a Sys Admin and part-time error code bounty hunter. "You could say he is the Sasquatch of the Windows world. Every snapshot we have of the adult 1603 is similar: You never get a good look at his face and he's always walking away." 

Fellow 43 year old virgin and part-time Sys Admin, Humphrey Warren, concurs. "If there was ever a time when we need the Bat Signal, it is now."

OK, listen, forget the lore. Forget the sensationalism. Lose the fear. When you run into a 1603 error, don't panic. There are a number of reasons that installations throw this error. Most of the time it is because "someone was expected but never showed up". That "someone" could be another Installation file, inadequate permissions to a directory or file (which you'd expect to see Error Code 5, the standard code for Access Denied events), an expected registry or WMI value, an environment variable, a network drive, etc. Antivirus software has also been known to be the cause of directories or files being unavailable and thus cause a 1603 error.

Let's say that you start an installation. The installation needs to refer to some files on a network share called \\Katrina\SharedDirectory. If SharedDirectory, for whatever reason, becomes unavailable after the installation has started and our installation attempts to access her data, well, your installation will, most likely, throw a temper-tantrum all over your hard drive. Chances are that all you will see at the end littered calling cards all emblazened with "1603".

Microsoft has stated that there are 3 primary reasons for 1603:

1- You are attempting to install to an encrypted drive or directory

2- You are attempting to install to a substituted drive

3- SYSTEM account does not have necessary permissions on the target directory

Of these 3 I've seen number 3 be the culprit the most.

http://support.microsoft.com/kb/834484

http://www.instant-registry-fixes.org/fix-windows-installer-error-1603/

The best 1603 article out there, IMO, is this one from msigeek.

It is very important to take your time with MSI related errors. Read log files. Verify permissions. Attempt an installation manually before you try a deployment. Consider the active protection offered by your antivirus software.

A Bat Signal is really not needed. Common sense and a Robert-DeNiro-in-The-Untouchables-Baseball-bat are really the only tools you need.

---

Install software silently with PDQ Deploy. Get your FREE copy today.

IBM Muppets and the Nerd Herd

After dumping our kids with some family members my wife and I are enroute to Switzerland for a much needed vacation. Our cab is just about to drop us off at DTW for our sojourn to Atlanta > Zurich. The following is a repost from Adam's June 2010 blog on some Jim Henson muppet videos made for IBM. Enjoy the flashback (on two different levels).

Technologizer has arecent article about some internal IBM corporate videos made by Jim Henson back in the late 60s (a couple years before the introduction of Sesame Street.) Some of his characters are already formed, such as Kermit and Rowlf, but in others you can see the proto-Muppets of what they would become. It also looks like Hensen's sense of humour hasn't changed much over the years, though, which is a good thing.

It's also nice to see that IBM had its own sense of humour, at least internally, and they weren't exactly the boring button-down company that we've all come to expect. I suppose it's easy to laugh at yourself a bit if you're among friends. 

You can see a good collection of the videos on the original article, so I'm only going to post a few here. These three are short videos shown during meetings to announce a coffee break. A nice way to break up a boring meeting. Enjoy a trip down pre-memory lane!

---

Twitter Me @AdamRuth

Deploy Pro Beta: Linked Targets

One of my favorite new features in the PDQ Deploy Pro 1.4 beta is Linked Targets. Linked targets allow for a live connection to another source of computers for use when creating schedules or deploying software.  As is usually the case, an example works best to describe it.

Let's say you want to deploy to the computers in an Active Directory container.  You know you're going to be deploying to the computers in the container regularly but don't want to have to maintain a seperate list and keep them in sync manually.  You can just create a Target List and link it to the container.

The difference to note here is that you can "Import From" or "Link To" the Active Directory container. The difference is that importing pulls the names of the computers once and linking creates a link that is always current with the computers in the container. When you Import From you get a list of computer names which are added directly to the target list, so any future changes to the container will not affect the list.

The way it works under the skin is that when the Target List is used in a deployment PDQ Deploy Pro connects to the target source of data and pulls the computers.  The link isn't "live" in the sense that changes in Active Directory aren't reflected in the target list immediately, as it would be too resource intensive to keep up-to-date with all changes that won't be needed until a deployment is started. A deployment will always have the most current list of computers when it needs them, though, so there is no practical difference in how it works. Schedules will, likewise, use the most current set of computers at the time that a new deployment is created. This makes it easier to set up schedules without having to mannually add new computers to each one.

Target Lists can even be linked to each other which allows for a hierarchy of targets organized inside of PDQ Deploy Pro. As with all linked targets, the ultimate target list is pulled when it's needed so you can have Target Lists linked to other Target Lists which are linked to combinations of Active Directory containers and other Target Lists. The currently available types of Linked Targets are as follows:

• Active Directory Containers - The link can be to the container itself or to the container's subtree (i.e. all of the containers within the container as well)
• Active Directory Groups - Groups can contain computer accounts and other groups
• PDQ Inventory Collections - Collections are baed on filters which use inventory from the most recent scan
• AA Console Collections - Also based on the most recent inventory scan
• Target Lists - Target lists can be linked to each other to any depth

We plan on expanding the concept of linked targets in the future to other systems. If you have a source of computers that you would like to link directly to PDQ Deploy Pro, please feel free to let us know, we love it when our users tell us what to do.

See the Java version on all your company computers

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

Remotely modify the registry

Every now and then you probably find yourself needing to make some modifications to the registry on your local computer. But what about those damn remote computers? No worries, using PDQ Deploy Pro you can make your changes easily.

One of the cool features of PDQ Deploy Pro is the ability to run a command on the target system. All you have to do is create a New Action of the type Command.

In this case after I added a new Command Action I deleted the first Action which is, by default, an Installer. (this is PDQ Deploy Pro after all). You can create as many Actions (Installer or Command as you'd like).

In the case above I am deleting a registry value called AnnoyingApp from the Run key under HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Run. Here is the command

REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v AnnoyingApp /f

Or if you want to add a value:

REG.EXE ADD "HKLM\SOFTWARE\Microsoft" /v SourceDirectory /t REG_SZ /f /d \\Southpark\StansStuff

Of course there are a lot of commands you can run using PDQ Deploy Pro but remember that any command you run remotely cannot be interactive. In other words you don't want to run a command that expects user input after it opens. If the remote command does need user interaction you will basically have a process that is hanging.

I like to use the Command Action to kill running processes (taskkill.exe) prepatory to an installation or perhaps I want to  perform some post-deployment tasks such as removing AutoUpdate registry values or associating additional file types with the newly application.

Think about the commands that you find yourself running. There are likely a bunch. We agree that psexec is an awesome tool, but if you are continually running the same commands on many systems, the ability to simultaneously run the command on all of your computers is a great benefit.

PDQ Deploy Pro 1.4 - Local Credentials

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:

administrator
.\Administrator
.group1\ADMINISTRATOR
.group2\administrator

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).

Future

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).

JZIP - How to silently install the free WinZip alternative

JZIP is a free zip tool based off of the 7-zip utility. It's a good alternative to WinZip.

Deploying JZIP to all of your computers is pretty easy (as deployments go).

Grab the corproate version of JZIP. The corporate version has no add-ons which is nice and clutter free.

I've been doing more and more demonstrations of deployments using our Pro version, but seeing as we're demonstrating a free product, it just seems right that we use our free version of PDQ Deploy.

After you've downloaded your JZIP EXE right click on it and select "Deploy with PDQ".

PDQ Deploy will open up and autocreate a PDQ Installer. Simply give it a name and provide the /S argument in the parameters section.

Select OK and you'll return to the PDQ Deploy console. Simply select the JZIP installer and click "Deploy" and you'll be able to select which target computers to silently push the install to.

You have five methods to select target computers.

1. Manual entry
2. Text file (listing target hostnames, one per line)
3. Active Directory
4. AA Console (if installed)
5. PDQ Inventory (if installed)

Select (or enter) your target systems and select "Deploy". JZIP is a pretty fast install so it shouldn't take too long, depending on the number of systems that your pushing to.

JZIP has a pretty handy command line utility in addition to an intuitive GUI.

JZIP is free, but if you find it useful and especially if you're deploying it to all of your company computer, please strongly consider giving the folks over there a donation.

If you've got an application that you'd like us to demonstrate deploying please let us know.

---

Get your free copy of PDQ Deploy today!

PDQ Deploy Pro 1.4 Beta

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:

Credentials

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

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.

Other Changes

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.

Timeout

A global setting is now available to timeout installers if they run for too long (useful for installers that aren't running silently).

Additional Files

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.