After weighing the pros and cons of different solutions I decided to go with creating a GPO that contains system wide environment variables one of which is %TOOLS% that I linked to an OU containing all the computers I use WPKG on.  I'm lucky in that my domain is running at 2008 Domain Functional Level, which means that I get all the new bells and whistles 2008 domains offer, one of which is Group Policy preferences.  In order to take advantage of GP preferences you must have the client side extensions add-on loaded (this applies to XP and VIsta).  GP preferences removes the need for a lot of what I used to do in startup/login scripts.  Here's a sample of what you can set in GP preferences:<br>
<br>* Environment variables<br><br>* File copying<br><br>* INI file changes<br><br>* Registry changes<br><br>* Shortcuts<br><br>* Setting up Network shares & mapping shares<br><br>* Local user/group changes<br><br>* Service changes<br>
<br>* Printer additions<br><br>and the list goes on...  Not trying to sell 2008, but I've been working with Windows domains for quite a number of years now and this is the biggest baddest upgrade yet.  IMO it's definitely worth the $$$.  :-)  <br>
<br>In anycase, after %TOOLS% is defined on each system through my GPO, I can then do the following in packages.xml<br><i><br><install cmd='%TOOLS%\nircmd.exe ...' /></i><br><br>This insures that my tools work within WPKG client and when I call wpkg.js directly.  It also has the benefit of being defined in only one place.  <br>
<br>Thanks again for your help Rainer.<br><br><br><br><div class="gmail_quote">On Thu, Jun 4, 2009 at 1:38 PM, Rainer Meier <span dir="ltr"><<a href="mailto:r.meier@wpkg.org">r.meier@wpkg.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Chris,<br>
<div><div></div><div class="h5"><br>
Chris Allen wrote:<br>
> I'm lost as to how the tools folder is supposed to work.  The<br>
> documentation seems to indicate that when using wpkg.js any EXEs in<br>
> tools would automatically be available for use in the package definition<br>
> files, but this is not the case.<br>
><br>
> Here's what I've tried:<br>
><br>
> * First I copied the tool I want to use: nircmdc.exe to tools<br>
><br>
> * I then edited packages\putty.xml and put a line that calls nircmdc.exe<br>
> in it like so<br>
> /   <install cmd='nircmdc.exe ...' />/<br>
><br>
> That didn't work.  Then I tried this:<br>
> /   <install cmd='tools\nircmdc.exe ...' />/<br>
><br>
> Then this:<br>
>    /<install cmd='%WPKGROOT%\tools\nircmdc.exe ...' />/<br>
><br>
> But that doesn't work either.  I thought maybe %WPKGROOT% would<br>
> automatically be set in the installers environment, but it's not.  What<br>
> is the point of the tools folder?  It seems entirely pointless to me if<br>
> I have to set up a system wide WPKGROOT environment variable myself to<br>
> get to programs I put in tools.<br>
<br>
</div></div>Currently the tools folder is used by WPKG only for one purpose - in case<br>
/rebootcmd:special is used it will run tools\psshutdown.exe from this folder.<br>
<br>
So the folder is used to put some WPKG tools into it. Well, the example within<br>
README.TXT shows what you're describing - it shows a 'wget' command but the<br>
example will not work (at least not with current WPKG implementation) unless<br>
WPKG would be executed within this directory.<br>
<br>
There is no WPKGROOT variable set (at least not to my knowledge) but of course<br>
you're absolutely free to define one in WPKG client which is then available to<br>
all your packages (that's the way I would recommend it).<br>
<br>
In order for the example command to work the tools folder would have to be added<br>
to the PATH. I think you might be able to achieve this by appending the path to<br>
the PATH environment variable. I did not try if adding a variable named PATH<br>
with the value "\\server\share\wpkg\tools;%PATH%" to the variables within WPKG<br>
client.<br>
However I verified that such UNC paths are correctly searched by Windows if the<br>
PATH is extended like this manually.<br>
So you might be able to extend the path using WPKG client or even by adding the<br>
PATH extension to profiles/packages/hosts (using variables).<br>
<br>
I am really not sure if the examples ever worked with any WPKG version. I doubt<br>
because I don't remember that old WPKG versions used the tools directory as the<br>
working directory or extended the PATH automatically. So the tools directory was<br>
always just used for some WPKG-internal tools - or to place tools there which<br>
are referenced by absolute paths.<br>
<br>
<br>
The only way to do this properly would be to extend the PATH variable as I wrote<br>
above and I think the best location to do so would be WPKG client. Especially<br>
because WPKG supports to specify a working directory for each command - so the<br>
commands might actually be run from any directory. So the only way to assure<br>
that the tools are always found if not specified by absolute paths is to add the<br>
folder to the PATH.<br>
<br>
br,<br>
<font color="#888888">Rainer<br>
</font></blockquote></div><br>