WPKG file path (required)

This is where your wpkg.js is located. You can specify its location in several ways:

\\server\wpkg\scripts\wpkg.js
\\192.168.1.1\wpkg\scripts\wpkg.js
W:\folder\wpkg.js

WPKG parameters

Parameters you give to wpkg.js. By default, it is:

/synchronize /nonotify /quiet

You shouldn't change it, unless you know what you're doing.

WPKG path user

This is the username which will access Script file path. It is recommended that you specify here non-privileged credentials - credentials only needed to access wpkg.js and your installers. Avoid specifying privileged credentials (domain admins etc.), as they are not needed here. Examples (NOTE: you have to add WORKSTATION\, WORKGROUP\ or DOMAIN\ before the username):

192.168.1.1\username
DOMAIN\user

WPKG path password

Password for Script file path.

NOTE: unless you understand Windows networking very well, using one single share for both software (installers) and WPKG (wpkg.js, config.xml, package definitions) is the recommended one.

By default, we start all installers as a SYSTEM user. It is the recommended setting. Whatever you put in here, the user almost certainly needs administrative privileges. If your installation scripts require access to parts of your network other than the location where the wpkg scripts are located, then you may want to put in here a user/password that has read access to those network areas in addition to admin privileges on the workstation.

User
Password
Username and password of the user executing WPKG. Must have admin privileges (SYSTEM doesn't need a password).

General

WPKG variables

It is convenient to define a variable for the location of your setup programs. Most of the example silent installer scripts on the WPKG wiki use the variable SOFTWARE, so you should too.

Example:
Name: SOFTWARE, Value: \\myserver\wpkg$\software

When naming the variable, do not put % before and after the name.

Be careful not to add an ending backslash (\\myserver\wpkg$\software\). In the packages.xml, a backslash is added (%SOFTWARE%\my\directory\program). It works with exe files, but it cause a 1619 msi error ("Exit code returned non-successful value (1619) on command 'msiexec ...") with all .msi files.

You can also use these variables in your XML package files.

Additional actions

Execute before
Execute after

You can start your custom programs or scripts before and after wpkg.js is executed.

WPKG user interface

Setting "Show" in "Script user interface" is only needed if you want to see the installers working in the foreground - it's good for debugging.
When the "Show" option is disabled (default), the installers will execute in the background - recommended for normal usage (normal users shouldn't interact with installers).

Logon settings

Maximum logon delay (minutes)

If you enter a maximum logon delay, WPKG will allow the user to log on after the maximum number of minutes, even if installations are still in progress. It is probably a good idea to set a value here, in case you make a bad package that hangs indefinitely.

First message

Second message

The two messages will display alternately while the user logon is being delayed.

Misc settings

Execution priority settings

Here, you can set priority for the service. Default priority (normal) is usually a good choice, but if your workstations are really old, and you don't use logon delay, you may want to choose a lower priority.

Stop the service when all actions are done

If you check this box, the service will stop when everything is executed.

Offline Mode

(previously discussed as the "laptop mode")

Some of you complained that if logon delay is enabled and the server is unreachable (because that client machine is a laptop unplugged from a network), users have to wait for too long. This happens for several reasons - trying to resolve DNS name, wrong routing etc.

The idea with "offline mode" is to try to reach a server for few seconds (3 seconds default, configurable), and if it fails (no connection, no reply etc.), discontinue further execution (skip logon delay, don't execute any actions).

Here we have two configurable options:

• server IP or name, OR
• custom script - execute a custom scrip/program; if it exits with a non-zero code, consider it a failure. The rationale behind a custom script is that a client can have a connection to the server, but it's a slow dial-up connection. Installing something big over a dial-up is certainly not a good idea. Of course, it is up to the administrator to write such a custom script.

Both options can have maximum waiting time specified.

NOTE: the "server IP or name" tries to connect to the server using port 139 - obviously, the server has to listen on this port.

NOTE2: the "server IP or name" will currently report a success if it gets *any* packet back from the server (like RST). It should only report success if it receives a SYN packet - this should change before a final release.

Here, you can import or export an XML file with WPKG Client settings.