Hi Jason,
M. Jason Stewart wrote:
> More like 200 separate DSL connections. We use Citrix as an
> alternative to individual VPNs. If you're not familiar, just think
> Teminal Services over HTTPS. Users get their applications via a web
> portal, it's like remote desktop for individual applications. As
> such, the client machines are not joined to our domain- they are just
> stand alone PCs.
> Thanks for the links, looks like I have some more reading and
> experimenting to do.
The use case you describe is not fully clear to me yet. Citrix is well-known to
me as a way to remotely access Windows environments. Personally I am using RDP
quite a lot.
But when using Citrix/Terminal services, then the software environment is fully
located on server side (centralized). This is actually exactly the reason for
such services - concentrate all data and environment on a centralized server.
But in this case you don't need WPKG on your road-warrior clients but on the
central server to install software on a central location. If your clients are
using Citrix remote access then the whole software installation is located on
the server.
Well, you could deploy the Citrix client to your workstations using WPKG but I
don't think it's updated very frequently.
In any case WPKG is usually run from an SMB/CIFS share. If you don't have a VPN
then it's unlikely that your clients will be able to access any share. So what
you could do is to install WPKG locally on every client (wpkg.js installed
locally). But WPKG by default reads its configuration (hosts, profiles,
packages) from the same location where it's executed from. Alternatively you can
provide these XML files on an HTTP server (which could be a web-server of your
company which is available via internet).
After you managed this hurdle you cannot fetch the software from CIFS share as
WPKG usually does. However you could use the HTTP-download functionality to
fetch the installer files from a public server (might be your company webserver
too). But remember that licensing might not allow you to publish the packages on
a public internet server (where actually everybody could download it from).
If you really want to use WPKG for this kind of deployment have a look at the
change notes where it's documented how to use the downloading feature....
NEW: Added download extension as initially proposed by Tomasz Chmielewski (with
some changes). A download definition is specified as follows:
<download url="http://server.domain.tld/path/to/file.msi"
target="subdir/file.msi" timeout="7200" />
The 'timeout' attribute is entirely optional. It defaults to the value of
'downloadTimeout' as specified within config.xml (7200 if not omitted).
The value is specified in seconds.
The 'target' attribute specifies a path relative to the 'downloadDir' as
specified within config.xml (defaults to '%TEMP%' if omitted).
NOTE: You need to specify the full file path, including the file name, not
just a directory name!
So to install the package above could be installed by the following
install command definition:
<install cmd="msiexec /qn /i %TEMP%\subdir\file.msi">
and
MOD: Download XML nodes are now allowed as sub-nodes of any command (install/
upgrade/downgrade/remove). This allows you to specify a download which is
only downloaded for a specific command. This was implemented since it
usually makes no sense to download the installation package again right
before the remove commands are executed (which usually runs a local
uninstall command which does not need the original installer).
Specifying a download XML node on the global package level (not below a
specific command definition) is still allowed. Such downloads will be
executed regardless of the command to be executed. So you can specify some
global downloads which are executed in any case.
Note: If multiple install (or upgrade/downgrade/remove) commands are
specified WPKG will download the the files of all command nodes of the
same kind before starting to execute the commands in sequence.
Example:
<package...>
<donwoad url="http://example.org/package.exe" target="package.exe" />
<install cmd="%TEMP%\file.exe some arguments" ...>
<donwoad url="http://example.org/file.exe" target="file.exe" />
</install>
<install cmd="%TEMP%\file2.exe some arguments" ...>
<donwoad url="http://example.org/file2.exe" target="file2.exe" />
</install>
<upgrade cmd="%TEMP%\update.exe arguments" ...>
<donwoad url="http://example.org/update.exe" target="update.exe" />
</upgrade>
</package>
This definition will simply download "package.exe" (global). "file.exe"
and "file2.exe" right before the install commands are executed in
seuence.
In case of upgrade it will download "package.exe" (global) and
"update.exe" before executing the upgrade command(s).
However I am not sure that you need it in case you really use Citrix
remote-desktop solution.
Please also remember that the downloading feature is quite uncommon and not very
widely used, so testing and fixing would probably require some time.
br,
Rainer
|
|