Migrating LiveState Delivery packages from a live server.
This is the main purpose of the utility. Multiple packages can be migrated at once. Converted packages appear as Software Delivery Solution packages in the Notification Server console. With the exception of packages that include reboots, most converted packages can be executed without additional modifications.
New "hidden desktop" execution mode.
The package conversion tool contains an option to specify that the converted packages should be executed in "hidden desktop" mode. This means that execution of the package will be completely hidden and will not be visible to any logged on user. This is useful for Transcript Recorder packages, which normally display UI and require that the user be prevented from interacting with the desktop for the duration of execution. When executed in "hidden desktop" mode, packages execute in the background and do not interrupt the logged on user's work.
This is the preferred mode for executing migrated Transcript Recorder packages because it overcomes the previous LiveState Delivery limitation of having to log off the current user and log in with mouse and keyboard input locked.
Note: There may be some packages that won't work in "hidden desktop" execution mode due to limitations of the executable used. In such cases, the "legacy" execution mode can be used.
"Legacy" execution mode.
"Legacy" execution mode emulates the legacy LiveState Delivery behavior of logging off the user, logging on with a special "smeclnt" account, and locking mouse and keyboard input during package execution. This uses parts of the old LiveState Delivery agent infrastructure to achieve the auto-logon functionality.
While "legacy" execution mode is an available option, migration to the Altiris Notification Server Software Delivery paradigm is encouraged and recommended.
SLD parameter migration.
Administrative parameters from the LiveState Delivery server are migrated and stored in a "params.zip" file in each migrated package. Default parameters, profile parameters and individual client parameters are stored in the "params.zip" file. During package execution on the client, the correct parameter values are extracted from the archive and applied.
Migrated package parameter editor.
A GUI editor for the migrated package parameters is provided. The editor can be used to open "params.zip" files for purposes of editing existing parameters and client records. The editor can also be used to add new parameters and clients.
Password parameters are not sent in clear-text.
Parameters containing the word "password" (configurable through config file) will be obscured using a reversible masking algorithm, so that they will not be transmitted or stored in clear-text.
The conversion tool itself supports running on Windows Vista. Migrated packages may not be able to run under Vista on managed clients. General rule is that if package did not run under Vista previously with LiveState Delivery, then it will not run under Vista after migration.
Known issues are recognized problems that are not listed in the documentation. They include problems that may be resolved in future and problems for which a workaround exists. Design limitations are documented in the individual functional specifications.
Some packages may not be able to run in hidden mode
It is possible that some programs may not be compatible with running in a hidden desktop (the "hidden" mode of execution using the RunHidden.exe tool). This may be occur in cases where the program is written in a manner that relies on access to a visible user desktop.
One known case involves install programs that use shell dialogs like the common File Open or File Save As dialogs. Since these dialogs cannot be displayed on a hidden desktop, the package execution will hang. This is an unusual case though, because it is not appropriate to use Transcript Recorder to browse through File Save/Open (as it may be different on each machine), and it is better to use a variable to set the filename text box instead.
There may also be occasions in which the selected user security context (in the Notification Server program execution options) may result in unexpected behavior when the package is executed in "hidden desktop" mode. One such case involving the Nero installer was identified in the lab. When running under a specific user context in a hidden desktop, the Nero installer halted. This was solved by changing the user context to run as SYSTEM user.
Packages that refer to absolute paths may not run correctly after migration
If a migrated package script refers to an absolute path like "C:\_integra" or "\\depot", then it is most likely will not run straight away when migrated to Notification Server. After migration, the scripts (which will be on the Notification Server share) should be reviewed to verify that any specified paths are valid for execution in the Notification Server context.
Packages that refer to tools outside of the package may not run correctly
If a migrated package script refers to a tool outside of the package files, (e.g. tools distributed with the LSD agent like "smecp"), those tools will not be available in Notification Server environment. The workaround is to include the tool in the package depot (or development) files.
Note: "awk" will be included if used. Also, wininter.exe is not affected by this limitation, because it is always included in package development files.
Custom-Gina prerequisite package must be installed on clients before any "legacy" mode package can execute
This is as designed. Custom GINA DLL is necessary for autologon to work and will be installed on the client.
"Legacy" mode setup might not work if clients still have old LiveState Delivery agent installed
This should not really happen. As part of the migration process, the old LiveState Delivery agent should be removed from clients and replaced by the appropriate Altiris agents. Failure to remove the LiveState Delivery agent could result in a conflict between the custom GINA DLL prerequisite package and the old LiveState Delivery agent.
Error 1721 during install if .NET 2.0 installed and not .NET 1.1
Version 1.1 of .NET is required for the client-side components of the Altiris Administrator SDK. The installation of the Altiris Administrator SDK may fail and generate a 1721 error in cases where .NET 1.1 is not installed on the target computer. This is true even if .NET 2.0 is installed on the target machine. Version 1.1 of .NET 1.1 must be installed on the target computer before installing components from the Altiris Administrator SDK.
Able to uninstall while tools are running
The product's uninstall does not verify whether any of its tools are currently running before proceeding with the uninstall process. In cases where some of the tools are running at the time that the uninstall process is begun, the uninstall may fail to remove some files. Please close all running instances of the tools before uninstalling.
When reporting a problem or defect with the product, please provide detailed information about the environment, the actions required to replicate the problem, and any applicable debug and log files.
Please provide the following:
Operating System used
Version of the tool (can be seen on Welcome page or About box)
Steps to reproduce the behavior
Log files (.dbg and .log)
Depending on the problem, the development team may request the package being used at the time. This will help resolve the problem, but is left to your discretion, as some packages may contain sensitive data.
Imported Document ID: DOC1580
Subscribing will provide email updates when this Article is updated. Login is required.