File locations

It will pull to your PC and then back to the target machine.

As a workaround you can create a batch file to pull directly from the file share and then only the batch file gets pushed to the target machine. Additionally, the Pro version will have more options to deal with WANs.

I am trying out the Pro version right now and we have a large number of remote locations. We do have file servers there and would like to deploy the files from the shares on the servers. Will the pro version also pull the file to the console and then push out to the remote locations ? What about an example for a batch file if that has to be used ?

Thanks.

The current version of Pro does pull the file to the console computer and then push it out to the targets. We will have the ability to avoid this in the next version 1.4.

A batch file that would do a direct copy could be as simple as:

copy \\server\share\installer.msi .
msiexec /i installer.msi /q 

You could even do several installs all at once in the batch.

You don't need to clean up the files as PDQ Deploy does that automatically.

Just tried this this morning on version 1.4 beta 3 and I'm not convinced it worked correctly.

I have copied a 89mb msi file to a location at each site so I don't have to copy the msi file down for each deployment.

I have a deployment defined for each site that I am using.

My installer file is \\locallanpc\c$\TEMP\Win32.msi

and the command line is msiexec.exe /i "Win32.msi" ALLUSERS=1 /q /norestart

The locallanpc and the target pc are on the same subnet/location but the copy was going down at 38k/s - way to slow for a 100mb lan (and not exactly fast for a 1.5t1 connection either!

Andy, pull file copy is not on by default in the current beta.  We may change it, but for now we decided to have it default to the same way that 1.3 works.  You can turn it on in the performance preferences. 

I should have said that I had already turned it on - both in the defaults and in the job setup too (sorry)

Okay, that does sound like something's broken.  Either the pull copy isn't working at all and it's still being pushed from your computer or the pull is working but it's just very slow.

There are a couple of ways to tell which it is.  During a deployment there will be a file called "files.ini" in the Windows\PDQDeployPro directory on the target computer with the paths of the source files.  If that file isn't there, or doesn't include the proper paths, then that would indicate that a push is still going on.

Another possibility is that the bandwidth throttling is being too aggressive.  If you set it to 100% it will disable throttling altogether and you can see if the speed goes to where it should.

Thanks - I'll deploy again tomorrow night and see how if I can get the files.ini.

I don't think the throttling was tweaked - again I'll let you know tomorrow.

Sorry it's taken a while to get back to you. I've just ran another install after verifying it is set to pull. Still downloading at 39k.

I do not have a files.ini in the pdqdeploypro file - just the exe and runner.ini which is pointing to the command to run and then the exec directory.

Bandwidth is set to 50%

However, checking into the exec directory, the file is there almost immediately (so i suspect its showing the final size as opposed to the real size on disk) . yet the status shows 2% at 40k/s currently.

Update just to confirm that manually pulling the msi file from the source pc to the destination pc comes in at about 8 seconds to transfer across the local lan.

Thanks for the update.  Sounds like it's not properly setting the pull file copy flag.  I'll do some research here and get back to you.

ok - just confirming that the problem persists in beta 4 too.

Looks like we found the problem, the flag wasn't being set in all situations (most situations, actually).  I'll send you a download link via e-mail.

Thanks. Downloaded the file and ran. The new deployment seems to be using the local install. Files.ini exists and points to the correct location and it is no longer stuck at copying at a very slow rate. 

My first install (of one computer) went through a lot quicker - thanks.

just a note that my downloads are now running at 3mb/s (4 off) so seems to be working (I think there is a 10mb hub at this remote location!)

Is there ay chance that PDQ Deploy will support installing directly from the remote share? All i deal with is remote locations (18 in all), and i would totally buy the pro version if i wasn't limited to working with batch scripts.

Jeremy,

When you say directly from the remote share, so you mean be able to copy the files directly from the remote share?  If so, that's what the pull copy mode is for in the pro version.  Instead of the console copying the files to the target computer the console sends down a list of files which point to the file share and the target computer does the copy directly.  

What i need is for the file not to come back to me.

For example, if i have an installer on a share in another city, the file will copy from their city to mine, and deploy the file back to their city from my computer. Essentially, i'm transferring a file back to me, only to copy it back x25. Muchos bandwidth and time!

What i need is to allow the deployment to install only from the remote share in that city to the computers selected. Right now i'm using a batch file like you mentioned, but need to follow up with the remote event logs one by one to ensure the installation was successfull.

This is a pro mode feature and currently exists. The feature is Pull File Copy. 

After you provide a pro mode trial key (or full key if you have already purchased) you can set the Pull File Copy at the installer level or at the PDQ Deploy level (Preferences > Performance > Use Pull File Copy.

Then you simply provide a UNC path to your installation file in your installer. 

Here is an image to show how to set this at the installer level (installer level will make Pull File Copy active only for that installer). 

Then you use the UNC path as shown in this image.