Difference between revisions of "Screenshots"

From WPKG | Open Source Software Deployment and Distribution
Jump to: navigation, search
(CLI / command line mode)
(CLI / command line mode)
Line 38: Line 38:
 
  msiexec /qb /i WPKGSetup.msi SETTINGSFILE=\\server\deploy\settings\settings.xml ALLUSERS=1
 
  msiexec /qb /i WPKGSetup.msi SETTINGSFILE=\\server\deploy\settings\settings.xml ALLUSERS=1
  
it is important to set the ALLUSERS variable, or at the first wpkginst run the permisisons/ACL of the folder %PROGRAMFILES%\WPKG will be totally blanked.
+
it is important to set the ALLUSERS variable, or at the first wpkginst run the permisisons/ACL of the folder %PROGRAMFILES%\WPKG will be totally blanked preventing the wpkg service to run at next boot.
  
  

Revision as of 13:36, 5 February 2007

Installation

GUI / graphical client installation mode

The WPKG-installer will create a windows service on the client machine. The service will run at system boot, and read the configuration xml files from the wpkg network share. The service will be created to run as the local SYSTEM user (the other user credentials discussed below are different).

As an administrator, we run setup.exe, and choose where WPKG should be installed...

Install1.png


And then, we configure its parameters...

Parameters1.png

The "Script path user" credentials are used to gain access to the network share where the wpkg.js script and the configuration xml files are located. A directory to hold installation files is often also placed in the same share, as shown in the example below. If the share is set up to accept guest read access from anyone, then these credentials may not matter.

The "Script execution context" user is the user that "executes all commands". This user probably has to have administrative privileges on the local machine to be able to do most interesting installs. By default, WPKG-install sets this to SYSTEM (no password needed), which works fine as long as it does not have to access other network shares. If any of your installation scripts require access to network shares (other than the share where the script and configuration files are) then you can set this to a user that has administrative privileges on the local machine and also read (or read/write) privileges on the necessary network shares.


Next we set some advanced settings...

Parameters2.png


After that, installation and configuration on the client is complete! Reboot the machine to start the service and see if it correctly finds the configuration files and so forth. Check the Windows Events log for details of its actions.

You can later change the parameters by running "WPKG Parameters" shortcut placed on Administrator's desktop.


Install3.png

CLI / command line mode

You can also install WPKG from command line - for scripted, silent/unattended installation.

Use this one for initial deployment:

msiexec /qb /i WPKGSetup.msi SETTINGSFILE=\\server\deploy\settings\settings.xml ALLUSERS=1

it is important to set the ALLUSERS variable, or at the first wpkginst run the permisisons/ACL of the folder %PROGRAMFILES%\WPKG will be totally blanked preventing the wpkg service to run at next boot.


And this one if you want to update settings:

%PROGRAMFILES%\WPKG\wpkginst.exe --SETTINGSFILE=\\server\deploy\settings\settings.xml


You can generate the settings.xml file by pressing the "Export settings..." button (see screenshots above).

Usage

WPKG starts when the system starts.

It can start all the programs/installers totally in the background (recommended), or in the foreground (not recommended, as users can interact with the installers; but recommended for debugging).

Logon1.png

Logon can be delayed until all applications are installed.

Applications are being installed in the background.

Messages appearing can be localized.

Here, a Windows XP system that is not a part of a domain.

Logon2.png