Difference between revisions of "FAQ:sp"

Revision as of 13:11, 22 November 2010

Este documento en otros idiomas: Inglés

WPKG FAQ (Preguntas frecuentes)

Si tiene respuesta a alguna pregunta importante sobre WPKG, por favor, localícela aquí.

WPKG no trabaja... WPKG no instala mi aplicación... Como asegurarme que WPKG ha trabajado? Por favor, ayuda...

El primer paso para asegurarse si WPKG trabaja adecuadamente es arrancarlo desde la línea de comandos de forma manual con el parámetro "/debug":

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

Esto mostrará en detalle como trabaja WPKG.

Otras cosas que merece la pena verificar:

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

Este archivo contiene la "base de datos" de las aplicaciones intaladas con WPKG (y los scripts que se ejecutarán, etc.).

• Si WPKG se arrancó con el parámetro "/quiet", generará su log en el "Windows Event Log" del equipo.

• Si utiliza WPKG Client, y añade el argumento "/debug" WPKG parámetros y activa el campo

"WPKG user interface -> Show" para ver los interfaces gráficos de los programas arrancados por el cliente WPKG. También puede solicitar la log detallada configurándola en el archivo config.xml. También, en el cliente WPKG, añadiendo algunos comandos como "execute before" (ejecutar antes) y "execute after" (ejecutar después), comandos como "notepad.exe" o "cmd.exe" (esto parará la ejecución hasta que cierre la aplicación.

Intentar iniciar sesión - utilizando WPKG >=1.0 (Descargar):

• editar "config.xml" sus necesidades, en especial: Fijar "log_file_path" a un directorio con derechos de escritura en su servidor:

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

• comprobar el fichero de log (para una configuración detallada vea [1])

He instalado una aplicación con WPKG. Después, he desinstalado una aplicación manualmente, utilizando "Panel de Control/Añadir o quitar programas". WPKG no reinstala estas aplicaciones, ¿porqué?

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.

¿Como puedo desinstalar programas?

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 your installation files are for licensed software then there is probably 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: 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.

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' />