FAQ:en

This document in other languages: Spanish

---

WPKG FAQ

If you think you have an answer to an important question regarding WPKG, please place it here.

Unable to install WPKG client on Vista/Win7 (or: `Error 1722 in log file')

Windows UAC (User Account Control) can cause the client installation to fail with a message like the following:

You must have an administrative privilege to run this tool.

This happens even when being launched by an `Administrator'. The WPKG logs show this:

Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action _A9459942_EE79_497A_9080_F39DDA8A7B80, location: C:\Program Files\wpkg\wpkginst.exe, command: --SETTINGSFILE=

The solution is to launch a command window with elevated privileges and use that to start the installer. Quoting from one post of many:

Install

1. Make shortcut to cmd.exe
2. Right click on it and select runas administrator
3. "cd" to path where installer is, e.g. cd C:\Users\Myname\Downloads
4. Run your msiexec command.
   1. msiexec /i "WPKG Client 1.3.14-x32.msi"
   2. For network, enter full path i.e msiexec /i "\\server1\MyShare\WPKG Client 1.3.14-x32.msi"

Install Alt

1. For install across network or localy use "psexec" from Systeminternals with localhost and "-h" parameters, eg. "psexec -h localhost msiexec /le wpkg_error.txt /i WPKG_Client_1.3.14-x64.msi"

WPKG doesn't work... WPKG doesn't install my application... How can I make sure WPKG works? Please help me...

The first step to make sure if WPKG works properly is to start it from the command line manually with "/debug" flag:

C:\>cscript \\server\wpkg\wpkg.js /synchronize /debug

This will display in detail what WPKG does.

Other things worth checking:

•  %SystemDirectory%\wpkg.xml (typically, C:\Windows\system32\wpkg.xml)

This file contains a "database" of apps installed with WPKG (and scripts executed, etc.).

• If WPKG was started with /quiet flag, it will log to Windows Event Log.

• If you use WPKG Client, add a /debug flag to WPKG parameters and check

"WPKG user interface -> Show" switch to see GUI of programs started by WPKG Client. You will also want to configure detailed logging in config.xml. Also, in WPKG Client setup, add some command as "execute before" and "execute after" (commands like notepad.exe or cmd.exe) - it will pause executing until you close their windows.

Try logging - using WPKG >=1.0 (Download):

• edit config.xml to your needs, especially: set log_file_path to a writable directory on your server:

<param name='log_file_path' value='\\\\server\\share\\dir' />

• check the log file (for configuration details see [1])

I installed an application with WPKG. Then, I uninstalled that application manually, using Control Panel (Software Add/Remove). WPKG doesn't reinstall those applications, why?

You probably uninstalled a package which does not supply appropriate package checks. WPKG offers the possibility to verify the package installation-status by checking the uninstall entries as they show up in the control panel. If you remove a package where you did not define any check WPKG has no possibility to verify if the package is still installed properly. To prevent having to re-install the package each time a local settings file (wpkg.xml) will be maintained by WPKG. This file keeps track of all packages installed.

Therefore you should make sure that if ever possible your package contains meaningful checks which allows WPKG to detect an uninstalled package in a reliable way. In most cases an uninstall check or a file check on an essential application binary (e.g. the main executable) would do the job.

Again: If you do not specify any checks WPKG cannot verify the install state of a package. Therefore it will not be re-installed after manual remove. WPKG simply trusts the package entry within wpkg.xml. If you specify checks then it allows WPKG to detect a removed package.

Of course you can also manually remove the corresponding entry within wpkg.xml but this is not recommended. Instead you should probably provide a new version of the package with appropriate checks. WPKG will then detect that the new version is available and do an upgrade.

How can I uninstall programs?

Just remove the entry of a previously with WPKG installed program from the respective profile in the profiles.xml. Next time the client synchronizes, the program will be uninstalled (if there is a valid uninstall command).

Is there a GUI for WPKG?

Yes. If you think about a management tool, then check WPKG Web Interface for details.

If you want a tool which lets you deploy WPKG on clients, check WPKG_Client site.

I modified WPKG a bit and added a feature. Can I contribute it?

Sure! Don't hesitate to inform us - if you want to contribute to development of WPKG, join the mailing list and let us know!

Do you have any examples of how to setup installing/uninstalling of programs using WPKG?

There are basic examples in the WPKG package if you download it.

You will find working examples in the Silent Installers category (you may need to modify paths to match your setup of course).

I'm getting "Unable to load specified XML document from \\server\wpkg\packages.xml" error. But packages.xml is there!

If you already checked that this file is really there, check this file for errors / typos. A common error could be missing quotation-marks ( " ), or if they are in a wrong place, or if there are two of them in a place only one is needed, or...

Try running WPKG with a /debug flag:

cscript \\server\wpkg\wpkg.js /synchronize /debug

And it will tell you where you made an error/typo.

I'm getting a Scripting host error "Automation server can't create object" and then WPKG exits

One cause for this is missing the MSXML2.domdocument.3.0 object. This will occur on a fresh install of Windows 2000 with IE5. Installing IE6 is the easiest solution - it will install the required component automatically.

Or if you are running xp sp2 and getting this than your WMI's repository is corrupted. This might fix it: rundll32 wbemupgd, UpgradeRepository

I'm getting an error "Event log file is full", and then WPKG exits

When you run WPKG as Administrator, it gives you an error, and doesn't run:

C:\>cscript \\server\wpkg\wpkg.js /synchronize /quiet /nonotify
\\server\wpkg\wpkg.js(2276, 5) (null): Event log file is full.

Users of German version of Windows will get "Die Ereignisprotokolldatei ist voll". Users of French version of Windows will get "Le journal d'�v�nements est plein".

As the error say, your Event log is full. Either clean it, or don't log what WPKG does to the Event Log.

WPKG logs to the Event Log when /quiet flag is used. So, don't use this flag, and start WPKG like below:

cscript \\server\wpkg\wpkg.js /synchronize /nonotify >nul

It is generally a good idea to start most of the <install cmd commands in a quiet way (there are sometimes quiet switches), or redirect their output to >nul. Examples of such commands are copy, xcopy, robocopy, del etc.

The problem can be avoided by changing the default settings for Windows logging, which are too small. Open the Event Viewer, select the Application Log, and choose Properties from the Action menu. You can increase the maximum log size and change the setting to overwrite events, so the log file will not get filled. You can probably set up a silent install package to make these changes on all your workstations by editing registry keys. See HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\logfile.

WPKG is very slow (taking hours) in copying or unzipping files

This is just a different symptom of the same problem as the previous question: If your command (xcopy, robocopy, unzip) is generating a lot of output, WPKG will need to capture it and this will take a lot of time.

I'm getting an error 'Input Error: There is no script engine for file extension ".js".', and WPKG won't start

If you have an HTML editor that has associated Javascript Source files (.JS) to it, then the CSCRIPT or WSCRIPT engine won't know which engine to use for the .js file. So, issue the following command from the command prompt to get it to work

C:\>ASSOC .JS=JSFile

Important: Make sure you have the capitalization correct... or else it could yell at you... especially the ".JS=JSFile".

Silent installs and the %SOFTWARE% Environment variable

Many of the silent installs are listed with %SOFTWARE% as a placeholder for the location of the installation files. If you wish to use the silent installs from this wiki, you must set the variable yourself. One way to do so is to add something like the following to one of your profiles:

<profiles>
  <profile id="Base">
    <variable name="SOFTWARE" value="\\SERVER\path\to\installers"/>
  </profile>
</profiles>

It can also be set directly in the WPKG Client under the second tab called "Variable, actions". Click the New button, set the name to SOFTWARE and the value as a UNC path such as \\server\WPKG.

If your installation files are for licensed software then there may be something in the license that says you have to control access to the install files. If you set the %software% environment variable globally then any command prompt will reveal the location of these files. You can prevent this by setting the variable in the wpkg-start.bat batch file so that it only affects that "session". It also keeps all the environment variable settings for WPKG as part of the WPKG script and ensures the variable is set before the script runs.

Logging

Logging: How to change the amount of log output?

WPKG 1.0 and up supports a logging feature where you can write a log file. You can use the /logLevel:<level> switch to change the amount of output written to the log file. The log level is actually defined using a bitmask. This allows you to independently enable logging of

• errors
• warnings
• information
• audit success
• audit failure

However in productive environment it is recommended to use a logLevel setting of 3 to log errors and warnings only (some might also use a value of 7 to add informational output as well). Higher log levels will lead to lots of ugly debug output which is probably only useful for package debugging.

Note: You might set the logLevel="3" attribute at the profile node as well. This allows you to apply a different (probably debug-level) logLevel to the profile you're using in your testbed while keeping the default log level of 3 for productive use.

Please also note that the logLevel will only influence the amount of output written to the log file. It does not affect the amount of output written to the console. If you're running WPKG from the command-line logLevel will not have any effect on the output there. To receive debug output on the console you need to use the /debug command-line switch. This allows WPKG client to run WPKG in the background as a service without using the /debug flag but using the /silent switch so no output is written to an invisible console - instead administrators can control the amount of output written to the logs by specifying logLevel either on the called command line or (more convenient from my point of view) within config.xml.

Logging: How can I customize the granularity of log-files?

You can enable/disable logging of the following log severities:

• errors
• warnings
• information
• audit success
• audit failure

There has been some proposals on Bugzilla to introduce several levels of debug logging in order to allow fine-grained control on the amount of logs written to the log files in debug mode. Even some patches have been posted to Bugzilla already.

However I am personally completely against such an "enhancement". From my point of view the log levels above are completely sufficient. In productive environment you will log errors, warnings and probably informational messages. On your test machines and for WPKG developers you will most probably enable debug logging to trace exactly what's happening inside WPKG. It looks like some people tried to use debug output in productive environment and of course there is too much output on debug level. So some people asked for a fine-grained debug-level setting.

Unfortunately such multiple debug levels create a maintenance nightmare. Even within a short discussion thread it showed that everyone has hes/hers own point of view how much output should be logged. I personally think that it would be impossible to satisfy the needs of everybody. Especially if there are no clear rules what exactly needs to be logged to which debug level which is an impossible thing to define for all future enhancements. Just imagine a new feature to be added to WPKG; the programmer adds some debug output - to which debug level should it be attached? I am absolutely sure if you're going to ask 10 people you will get as many different answers as log levels are available. Just a simple example is the logging of a list of packages read from the XML files. Somebody might argue that this should be printed within the lowest debug level since it's absolutely crucial for WPKG operation that the packages are correctly read. Somebody else might think this just blows up the log file with useless information since you know your XML files are correct and there will be no problem here. As a result WPKG developers and administrators who need to debug will anyway use the highest available log level to debug in order to make sure not to miss the important parts. Such (technical) people are usually also able to handle such a huge amount of output using search, grep and other tools.

Another big drawback of a high amount of log levels is that log-files can show a huge amount of different detail level. Support requests posted to the WPKG support team might contain enough information for the administrator but not for the WPKG developers. So it will be anyway crucial to get a log file with the highest possible log level.

The log file size on a typical system (tested on my installations) is about 20-50kB. This size is still easily parseable and searchable.

Disadvantages of multiple debug log-levels:

• If you really have to find a bug you will anyway set the log level to the highest available level in order to make sure you don't miss the important parts.
• Everybody will anyway have a different view how much detail should be logged within a specific debug level.
• The result is that administrators and developers will anyway use the hightest available log level to make sure all information is available.
• Log files posted to the WPKG support (mailing list/Bugzilla) would potentially contain too less information.
• Full debugging log is not that huge so it is still possible to handle it - so no need to reduce the amount of output.

Logging: Can I keep more than just the last execution log?

Yes you can. By default WPKG writes a log file using the name pattern "wpkg-[HOSTNAME].log". This will overwrite the same log on each execution. This was desired in order to prevent filling up the HDD with lots of log files. However if you use a pattern like "wpkg-[HOSTNAME]-[YYYY]-[MM]-[DD]_[hh]-[mm]-[ss].log" will write a new log file if WPKG is executed one second later again (and it's very unlikely to execute it twice within the same second).

It's clear that using such a pattern you will get lots of log files within the log file folder. Therefore it's recommended to have some cleanup tasks running on that folder (log rotation, log aging) - see the question about log rotation.

Some people also asked for log file appending instead of overwriting. I have chosen the overwriting approach in order to prevent the log file growing to infinite. Additionally appending changes the modify date of a log file which creates some problems with some log rotating scripts. So it's much better to write a new log file on each execution.

Logging: What about log rotation?

WPKG itself does not contain built-in log rotation. I personally think this is a bad idea. Log rotating is not a core functionality of WPKG. Additionally there are numerous tools available which are specialized on rotating log files created by any application. Almost any Linux box already comes with a rotating tool like 'shrotate'.

Additionally there is a huge amount of ways to rotate log files. Some examples:

• based on size
• based on date
• based on name
• based on attributes
• any combination of the ones above

Well rotating is a very complex thing and needs to be very flexible to fit the needs of each environment and the flavor of the administrator. There is a big amount of tools out there which can do the rotation independently of WPKG. These tools are dedicated to log rotation. It's an illusion that WPKG will ever be as flexible as such a tool. Additionally I am against re-inventing the wheel and incorporating code into WPKG which is unnecessary and is prone to errors and bugs.

So the suggestion is clearly to use an external log rotation script if you would like to retain several log files. Personally I am perfectly fine with the default settings to just keep a log of the last execution per machine so I can see all the messages and errors produced by that machine at the moment. I am not really interested to know what happened during an installation months ago - I am just interested in the current system state - which is actually represented by the local wpkg.xml and the last execution log.

Variables

Why aren't my variables showing up ("expanding") in my logs?

The issue with variables showing up "raw" in logs and other output is intentional, as stated in a post to the wpkg-users mailing list. If you need to verify what a variable is expanding to, the recommended solution is to create a simple package whose install commands dump the variables to file, like this:

<install cmd="%ComSpec% /c echo Software: %SOFTWARE% > %TMP%\info.txt" />

What is the precedence order for variables?

As of version 1.3.0, the priority of variable assignments has changed to the following (from lowest to highest: assignments done in locations listed first will be overridden by ones listed later):

1. Operating system environment variables
2. The "Variables, actions" tab of the wpkginst.exe client utility
3. Host XML files
4. Profile XML files
5. Package XML files

For example, if you assign a variable named foo in a Profile (priority 4), it will override any existing definitions in the Host (priority 3), or by variables on the client machine (priorities 1 and 2). It can, however, be overridden by an entry in the Package definition (priority 5).

In version 1.2.x and prior, the precedence order was as follows:

1. Operating system environment variables
2. The "Variables, actions" tab of the wpkginst.exe client utility
3. Package XML files
4. Profile XML files
5. Host XML files

See also Variables#In_which_order_are_they_applied for some code examples, and instructions on simulating the 1.2.x behavior in versions 1.3.0 and above.

WPKG Client: I configured WPKG Client to access a network path as "user" - it doesn't work. Why?

Do you get such message in the Event Log when trying to start the WPKG service?

WNetAddConnection2-> A specified logon session does not exist. It may already have been terminated.

You have to configure WPKG Client to access any network path as "DOMAIN\user" or "WORKGROUP\user" (see this screenshot for an example).

It will not work if you use just "user" without the DOMAIN (WORKGROUP).

Where does the WPKG / WPKG Client log to

By default WPKG Client logs to the Windows Event Log.

WPKG (wpkg.js) log location is configured in config.xml:

<param name='log_file_path' value='%TEMP%' />
<param name='logfilePattern' value='[HOSTNAME]-[YYYY]-[MM]-[DD].log' />

My install command just stalls and never finishes

Unfortunately there is a limitation of WSH which causes an executed child process to stall if the console buffer is full. The process stalls until the buffer is flushed. WPKG tried to implement proper buffer flushing to prevent this. Unfortunately the methods to check whether the buffer is empty is blocking too which means WPKG would stall when checking whether the buffer is to be flushed. Thus WPKG would be blocked and unable to check whether the command reached its timeout.

A discussion on this topic was held on Bugzilla: [2].

As a simple work-around just make sure your commands do not print anything on the console or
redirect the output to a file or NUL by appending ">NUL 2>&1" to the command. For example

 <install cmd='%SOFTWARE%\my-installer.exe /S' />

can be turned into:

 <install cmd='%SOFTWARE%\my-installer.exe /S &gt;NUL 2&gt;&amp;1' />

or re-directing the output to a file:

 <install cmd='%SOFTWARE%\my-installer.exe /S &gt;%TEMP%\install-log.txt 2&gt;&amp;1' />

This effectively prevents the buffer to fill up and your commands will finish properly.