referencing additional files in install command - file location
HI I am installing a file with the following custom command and it is working how I want it.
msiexec.exe -i "installerfile.msi" CONFIGFILE="%SystemRoot%\PDQDeployRunner\1\exec\configfile.conf" /qn
The documentation says that additional files go to "%SystemRoot%\PDQDeployRunner\exec\" so when I referenced the file in that location it did not apply my custom config as it could not find it. I monitored the folder as I performed a deployment an noticed that it creates a "1" folder in PDQDeployRunner.
Will this folder path ever change from computer to computer, will it always be "1\exec"? I want to make sure I can leave the path as is for all deployments.
Is there a better way to reference my custom configuration file? I also tried the command below and it did not work.
msiexec.exe -i "installerfile.msi" CONFIGFILE="configfile.conf" /qn
Comments
hmm... situations like this, i believe referencing a network share would be your best bet.
Although i haven't tried it this way except when running office installations (referencing xml), keeping the conf file in a share so that you can centrally manage the file instead of having to modify/delete/change the file on every workstation.
Since the answer hasn't been given in regards to the folder path remaining consistent, there would be other ways around this.
In your command line, adding a step to copy the main conf file to a "Temp" folder, then deleting it after you're done with it.
Have you tried using a UNC path to the conf file somewhere on the network?
e.g. msiexec.exe -i "installerfile.msi" CONFIGFILE="\\server\share\configfile.conf" /qn
Or creating another folder in program files if you want to keep the file on the local workstation.
Thanks for the reply. I am currently using the free version, so I am a bit limited on what I can do, hopefully I can grab the pro version next week.
I will see if the Temp folder will work out
I did try to use a UNC for the config file and was unable to get it to work, it looked exactly as you listed it. The UNC not working during the install could be another issue I need to look into, although I verifed I can access the UNC from the target work station.
Hopefully someone can chime in on if the folder changes or not, if it does not change, it's going to keep working great. But because the folder is named "1" it makes me think it may change if installing multiple applicatons.
I would also like to know where the command is started from, because just refrencing the file without a path does not work, it would be nice if the command was kicked off from the exec folder.
yep, when i had the free version using batch scripts was my best friend since i could call upon several different "steps" all at once.
But of course, that would require one to understand and be comfortable with command line.
in your instance, just to get going for now...
using the copy command, to copy ALL installation files to a specific folder of your choosing, then being able to again use the command line to call those files/folder to do the bidding for ya.
Mind you, batch scripts will only get you so far.
Once you get into it, you'll want to purchase the pro version, but that's me.
It's got plenty of benefits i didn't think i needed until it was there. :)
good luck bud
The %WINDIR%\PDQDeployRunner\1\exec directory isn't guaranteed to be correct. It is safe to say that the directory 1 is usually used but it could be 2, 3, 4 and so on. The number has to do with concurrent deployments as well as previous deployments which may not have been cleaned up.
You may see concurrent deployments when there is more than one PDQ Deploy console used in your environment. If two different consoles deploy to the same target then you would see two directories:
%WINDIR%\PDQDeployRunner\1\exec
%WINDIR%\PDQDeployRunner\2\exec
Also, if a previous deployment fails to clean up after itself subsequent deployments could use different directories.
You can find some good information on this "Under The Hood" forum post.
Thanks for the info, I will make changes as necessary to my packages.
Shane, I just cranked up a package I wrote some time ago, and it failed because the path to additional files had changed. I found this thread while researching the problem. I am obviously missing something, because it seems that additional files are of limited use if I cannot reference them in a step. In my case, my install step is running psexec to start an AutoIT script that is used to interact with dialog boxes during installation. Maybe adding an environment variable during execution containing the path would be useful???
Old thread but commenting as I struggled with this and found a working solution that might help others. For me using the %cd% variable correctly referenced the current working directory where the files were copied using the include sub directories option.