ReadMe
WinINSTALL 9.0
Software Distribution Suite

The information contained in this publication is subject to change without notice. Attachmate Corporation makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Attachmate Corporation shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual.

© Copyright 2007 by Attachmate Corporation. All Rights Reserved.
Migration Engine © Copyright 1998-2006 by Tranxition Corporation. All Rights Reserved.

 


This file contains the latest basic startup information, a brief explanation of the major new features, and the latest listing of known issues.


 

Table of Contents

Startup Tips

Installation Requirements

Starting the Console for the first time

WinINSTALL Agent

Conflict Assessment

Sample Packages

Upgrading from an Evaluation Copy to a Permanent License

Support Forum

 

New Features and Enhancements

Remote Control

Two-Phase Distribution

New Patch Management Facility

Job Creation Wizard

IPC File Transfer

PXE Client Reset Enhancements

Enhanced Checkpoint Restart in Server to Server Replication

 

Limitations and Known Issues

Setup

MSDE DBMS Setup

MSDE DBMS Removal

Evaluation Limitations

Upgrading from an Evaluation Copy

Initializing the WinINSTALL Database

WinINSTALL Agent

Agent Deployment

Agent Configuration

Changing the Database

Error Reading Configuration File

Console

Database

Oracle DBMS Issues

Database Rollup Shares

Server upgrades from 2000 to 2003 Can render WinINSTALL unable to open the database connection dialogue

On XP Pro SP2 RC2 the Database server name does not appear in Database Wizard with local MSDE installed

Cannot uninstall and successfully re-install the product on the same machine.

Active Directory

NetWare

Discover

NAI to MSI Conversion

MSI Validation

Validation on Japanese Systems

Packaging

Scheduling

Scheduling Publish and/or Merge Jobs

Scheduled Job Start and End Times

Installer

Patch Management

Operating System Limitations

Disk Space Requirements

Windows Update Agent Fails to Update

User and Group Restrictions for Remediation Jobs

Update Installation Problems

Windows Vista™

 

Startup Tips 

Installation Requirements

Please consult the WinINSTALL Installation Guide for specific installation requirements for WinINSTALL workstations, servers, shares, and database.

 

Starting the Console for the first time

When you start the console for the first time, you may be prompted by the Default Settings Wizard for the location of your WinINSTALL database and WinINSTALL share.

Please have these items of information available when you start the console.

 

WinINSTALL Agent

To deploy the WinINSTALL agent automatically from the console, the logged-in account must have administrative rights to the machine where you are deploying the agent infrastructure. (The credentials specified in the deployment UI are for the operation of the agents on the target machine, not for deploying the agent.)

Windows 95 machines must have WinSock 2 installed in order to install and run the WinINSTALL agent.

 

Conflict Assessment

You create baselines for conflict assessments on the baseline machines themselves. You run the baseline generator program, WIBaselineGen.exe, which will be found in the \bin directory of the WinINSTALL share.

 

Sample Packages

WinINSTALL provides a number of sample packages for distribution. To avoid inadvertent installations, these packages as supplied are disabled for both install and uninstall. To use one of these packages, please remember to enable the package before distribution.

 

Upgrading from an Evaluation Copy to a Permanent License

If you have an evaluation version of WinINSTALL Software Distribution Suite installed but have purchased a permanent license, you can directly upgrade your installed evaluation version to a fully licensed version. To enter a permanent license key, simply click the Change button on the console Help/About screen and enter the license key on the provided dialog. Doing so will update the product to a permanent license.

It is possible for an evaluation version of the WinINSTALL installer on a client machine to expire, even though the product (share) has been upgraded to a licensed version.  In this case, it will be necessary to uninstall and reinstall the agent on the client machine to prevent or correct this situation.  This operation can be done from the console.

 

Support Forum

Attachmate provides a free forum for support and discussion of all WinINSTALL products at http://support.attachmate.com/solutions.html?prod=wininstall

 

New Features and Enhancements 

The 9.0 release of the WinINSTALL family of products includes many new and improved features designed to make your job as a network administrator easier. The major new features and enhancements are listed below.

Remote Control

WinINSTALL now allows a console user to remotely control any client machine directly from the Machines list through either of two methods:

  • Windows Remote Desktop Connection (RDC).

  • The remote control product of your choice.

 

Two-Phase Distribution

WinINSTALL now offers a new option for delivering application packages to managed workstations.  The new Two-Phase Distribution option delivers the package to the workstation in phase one, and then, in phase two,  installs that package from the local drive.  This feature provides a number of new capabilities to WinINSTALL's industry leading software distribution capability:

  • Local execution of the WinINSTALL Installer.

  • Bandwidth throttling during package delivery.

  • Multicast package delivery option.

  • Checkpoint restart (sub-file level) during package delivery.

  • Package delivery without requiring access to a network share.

  • Decoupling of package delivery from package installation.

TIP: This combination of new capabilities makes Two-Phase Distribution an ideal mechanism for delivering large packages to remote or poorly connected users.

 

New Patch Management Facility

WinINSTALL now provides a comprehensive patch management feature with a number of new capabilities:  

  • Ability to schedule vulnerability scans as well as remediation (patch application) jobs.

  • Ability to view all managed machines with a selected vulnerability.

  • Ability to apply patches (remediations) to all vulnerable machines.

  • Remediation jobs use the new Two-Phase Distribution feature, enabling all the associated advantages and options of that feature.

  • Vulnerability scans and remediation jobs employ the Microsoft Windows Update Agent for maximum reliability and minimum system reboots.

  • The vulnerability database and remediation patches can be automatically downloaded to all WinINSTALL servers, enabling all vulnerability scans and remediation operations to be carried out with no required workstation internet access.

  • Legacy patch delivery through WinINSTALL .nai packages remains an available option.

 

Job Creation Wizard

WinINSTALL now provides a Wizard for job creation.  This Wizard is a new, unified facility for creating both scheduled and immediate jobs, making running tasks on managed workstations easier and more intuitive than ever.

 

IPC File Transfer

WinINSTALL has long used IPC (Inter-Process Communication) for direct interaction between the WinINSTALL console and managed machines.  Now this facility is used optionally or automatically in several additional WinINSTALL operations:

  • IPC file transfer is available as an optional means of transferring configuration and transaction files between the WinINSTALL agent on each managed machine and the WinINSTALL server.  This new option, configured on the WinINSTALL Agent Settings Advanced tab, allows these operations to make more efficient use of network bandwidth and strengthens network security.

  • The new Two-Phase Distribution feature automatically uses IPC file transfer to move packages to the local drive of the target machine before installation.

  • The new Patch Management facility also uses IPC file transfer to move patches to the local drive of each target machine before the patches are applied.

 

PXE Client Reset Enhancements

The PXE-based Client Reset feature of the WinINSTALL Desktop Availability Suite installs Windows operating systems directly from network servers, without loading MS-DOS or running MS-DOS applications.  In addition, administrators can use the built-in integration of WinINSTALL software distribution and personality transfer to optionally include in the reset process installation of any number of application packages and/or Microsoft patches, and the restoration of user data and settings as well.

This release introduces a number of significant enhancements to this major WinINSTALL feature:

  • PXE Reset Queues.

  • Improved automatic OS language detection.

  • Automatic OS detection for drivers.

  • SCSI/SATA driver support.

  • Regional language setting (Locale) support.

  • The UI now enables the hiding of unused languages.

  • Support for disabling the administrator account on PXE reset clients.

 

Enhanced Checkpoint Restart in Server to Server Replication

The server to server replication feature included in  the WinINSTALL Desktop Management Suite and WinINSTALL Desktop Availability Suite has always provided a file-level checkpoint restart capability for interrupted replication jobs.  Now this checkpoint restart capability has been extended to sub-file level, vastly increasing the efficiency of this feature.  For example, if a replication session is interrupted 90% of the way through the transmission of a large file, WinINSTALL will now transfer only the remaining 10% of the file, rather than the entire file, when the session is reestablished.

Note: This enhanced checkpoint restart feature is automatically used in all Two-Phase Distribution jobs as well as in server to server replication and patch management.

 

Limitations and Known Issues

The following list itemizes all known issues with this release, including workarounds, where available. In most cases, subsequent releases are planned to address these issues.

Setup

During setup, you can change the installation directory for the console, but we recommend that you accept the default: [ProgramFilesFolder]OnDemand\WinINSTALL\ .

The WinINSTALL Agent is always installed to [ProgramFilesFolder]OnDemand\WinINSTALL\ and later maintenance of WinINSTALL will be simpler if both the agents and the Console are in the same directory.

 

MSDE DBMS Setup

After installation of the Microsoft SQL Server Desktop Engine (MSDE) database system, the following warning message may appear:

Files that are required for Windows to run properly have been replaced by unrecognized versions. To maintain system stability, Windows must restore the original version of these files. Insert your Windows 2000 Professional CD-ROM now.

The MSDE install, supplied by Microsoft, can replace protected files with other versions of these files. Since Microsoft produces this setup, Attachmate Corporation has no ability or right to change it.

Note that this warning message presents an option to replace the files with the original ones. You can continue the install by simply ignoring the fact that the files have been replaced. WinINSTALL will operate correctly despite these file replacements.

 

MSDE DBMS Removal

If you install WinINSTALL with the MSDE option, and you later want to remove MSDE from your system, be sure that you have first stopped the SQL AD Helper service. Otherwise, you may encounter difficulty removing MSDE.

 

Evaluation Limitations

Evaluation licenses allow you to use the product for a limited number of days. The specific time period varies, depending on the product being evaluated.

Please note that packages built during the evaluation period have evaluation license limitations time restrictions built into them. After the evaluation period expires, installations of these packages will no longer function and will be extremely difficult to repair.

Therefore, we recommend that, during the evaluation period, you limit distribution of these packages to a test environment only. To distribute these packages after the evaluation period expires, you must purchase a copy of WinINSTALL and access each package once from the newly licensed console.

 

Upgrading from an Evaluation Copy

If you have an evaluation version of any of the WinINSTALL 8.7 products installed, you can upgrade to a licensed version of the same product by simply entering the license key into the console on the Help/About screen.

If you have installed the console onto more than one machine during the evaluation, you need to upgrade the console on each of these machines. To do this, from each console machine, simply execute the upgraded WIConsole.msi in the \bin directory of the WinINSTALL share. Setup will start and offer to uninstall the console or to repair it.

You may uninstall it and reinstall it, or you may simply choose Repair. In either case, the console will be upgraded to the fully licensed version. The console should be closed before attempting an upgrade.

 

Cross-product and Evaluation Upgrades

The above procedure may or may not be permitted if you have evaluated one WinINSTALL product but purchased another. In fact, evaluation versions of certain products may not be upgraded to other products at all. For example, if you have evaluated the WinINSTALL MSI Packager Professional but have decided to purchase WinINSTALL Desktop Management Suite , you will have to uninstall the evaluation copy of the MSI Packager product before installing the Desktop Management Suite.

Please consult the chart below to determine whether or not you can upgrade your evaluation version. If you cannot upgrade, you will have to uninstall the evaluation before installing the licensed version.

Evaluation Product:

v9.0 Licensed Product (Upgrade Permitted):

LE

MSI

SDS

DMS

DAS

LE 9.0 Eval

YES

NO

NO

NO

NO

MSI 9.0 Eval

NO

YES

NO

NO

NO

SDS 9.0 Eval

NO

NO

YES

NO

NO

DMS 9.0 Eval

NO

NO

NO

YES

YES

DAS 9.0 Eval

NO

NO

NO

YES

YES

SDS 9.0

NO

NO

N/A

NO

NO

DMS 9.0

NO

NO

NO

N/A

YES

 

 

Initializing the WinINSTALL Database

WinINSTALL includes a database setup wizard, WIDBSetup.exe , located in the \bin directory of the WinINSTALL share. WinINSTALL setup offers the option of executing this wizard at the conclusion of setup, but it can also be executed directly at any time. This wizard will create all the needed tables for the WinINSTALL database in MSDE, Microsoft SQL Server, or Oracle.

 

WinINSTALL Agent

  • Installing the WinINSTALL Agent may result in a reboot of the target machine. The WinINSTALL Agent will replace certain system files if they are not already at or above the necessary minimum level. No reboot will be required if these files have been updated earlier, in the process of installing other software, but if they have not already been updated, then the Agent setup will need to replace them, and the machine will require a reboot to replace these in-use files.

  • The WinINSTALL Agent now requires Windows Installer version 3.1.  If this version of the Windows Installer is not already installed, the Agent deployment will perform the install and A REBOOT WILL RESULT.

  • Installing the WinINSTALL Server Agent on Japanese Windows NT 4 and Windows 2000 machines may result in a reboot because Japanese versions of Windows NT and Windows 2000 include a version of MDAC earlier than that required by WinINSTALL.  As a result, installing the WinINSTALL Server Agent on a machine with either of these operating systems is likely to cause the system to reboot--unless MDAC has been upgraded to at least v2.71.

  • Right-clicking on the WinINSTALL Agent icon in the taskbar may not display the correct product version on Win9x machines. This is a display anomaly only. The product version is actually correct.

  • The default intervals for the various tasks performed by the WinINSTALL Agent should be reviewed and adjusted as necessary. There are a number of default intervals that affect the operation of the WinINSTALL Agents. These defaults are as follows:

  • Transaction file processing interval:

    120 seconds

    Config file processing interval:

    120 seconds

    Merge processing interval (server only):

    120 seconds

    Publish processing interval (server only):

    120 seconds

  • These settings work well for evaluation and testing, but they may be too short for practical use in a large production environment. Your choice of these settings depends on how frequently you want the agent (on each machine) to interact with the share, how much latency you can tolerate between making a change and having it take effect, how quickly you want data to appear in the console from agents, etc.

  • Attempting to start or stop the WinINSTALL agent on a Win9x machine from the Console generates a message, but does not stop the agent. User mode agents cannot be stopped from the console.

  • Agent activity can be logged to the Windows Event Log, the WinINSTALL database or to a local log file. The local log file is really a troubleshooting log, intended for use when you need to have logging activity in an easy to edit format. The file will be created on disk only when a certain buffer limit has been reached. The log will not be created with the logging level set at Standard . If Verbose or Diagnostic is selected, the log will be created in the Windows folder of the client machine and will be named WInn.tmp where nn is a sequential number. Each time the WIAgent service is stopped and restarted a new log file is generated. The log cannot be viewed while the service is running.

  • If you try to deploy the WinINSTALL Server Agent to an NT4 server that does not have IE4+ installed, the deployment will fail. This is because the MDAC component install provided by Microsoft requires SHLWAPI.DLL that is included with IE4+. The solution is to install IE4+ to the NT4 machine and then deploy the agents again. The WinINSTALL Workstation Agent deploys successfully to an NT4 workstation, with or without IE4+.

  • The WinINSTALL Agent options to show the tray icon and allow close are typically used only for Win9x.

  • If you intend to permanently delete a machine from the Console, you should first remove the WinINSTALL Agent or disable it, and then delete the machine from the machine list. Otherwise the machine will re-appear in the machine list each time the agents run.

 

Agent Deployment

  • During server agent deployment to a machine running Windows NT 4, error messages may be logged by the WinINSTALL agent. The errors are caused by the fact that the installation has not entirely completed when the agent is started. Under NT, because of the need to install MDAC, the machine must be restarted to complete the WinINSTALL server agent install. The error messages begin before the machine is restarted and continue, briefly, after the machine is restarted. However, after a few moments, error messages are no longer logged and normal processing continues.

    If you deploy a WinINSTALL server agent to an NT4 machine, ignore the error messages until after the server is running correctly.

  • You cannot deploy an agent using an account that has a blank password.  Attempting to do so will result in a failure of the deploy agent action.  The workaround is to change the password from blank to something that has at least one character.

  • If you deploy a WinINSTALL agent to a machine running Windows 95 and then schedule a job to that machine (or to a group including that machine, such as All WinINSTALL Workstations), it may no longer be possible for a user to log into that machine if the machine is rebooted while the job is still scheduled for the machine.  The only workaround is to uninstall the WinINSTALL agent and then reinstall it.

 

Agent Configuration

Changing the Database

To change the database that your servers and clients are reporting to, the current release of WinINSTALL requires you to perform a multi-step process. If you also want to change the shares assigned to a server, treat this as an entirely separate operation--do not try to effect these changes together.

 NOTE: Changing the shares assigned to a server is a separate operation from changing the database and should be performed separately. Information on changing assigned shares is presented in the Managing Machines chapter of the WinINSTALL Administrators Guide.

To change the database your servers connect to, please carefully follow these steps:

  1. In the console, bring up the settings page for each of your servers (or all together), and enter the new database connection information.

  2. With these servers selected, right click and select Publish. The servers will download their new configuration information and connect to the new database--but because of product issues, the share information will be lost.

  3. After a suitable interval, to be sure that the servers are now connected to the new database, but with the console still connected to the old database, select the servers you have migrated to the new database and run an inventory on those servers (via Run task , not via scheduling). The servers will then populate their inventory information into the new database.

  4. After a suitable interval, to give the inventories time to run and be merged into the new database, connect the console to the new database and verify that the servers have shown up in the machine list.

  5. Select each server's Properties page and verify that all information is present.  You may need to fill in missing share information.

  6. Select each server's (or all the servers') Settings page(s) and verify that all information is present.  You may need to fill in missing database connection information (it may have been lost), along with any other missing information.

  7. If you needed to fill in any missing information in steps 5 or 6, select the servers and run the Publish task.

The workstations will appear in the database as they perform tasks which require them to report to the database. If you want to speed this process up, you can re-connect the console to the old database, select the workstations, and run the Inventory task (do this from the Run task selection, not by scheduling). As the inventories complete, the workstations will appear in the new database.

Error Reading Configuration File

If it so happens that at the exact moment that the WinINSTALL Agent is reading its configuration file, a new copy is being downloaded from the share, the file is unavailable and an error will be logged to the event log, saying that the WinINSTALL Agent is unable to read its configuration file.  The impact is minor, because the file will be read properly at the next interval.

 

Console

When you have an MSI package open on one console, a second console attempting to view the same package will receive the following message:

Someone else is currently working with this file. Opening for read-only access; changes will not be saved.

The way to release the console locks on an MSI package is to refresh (F5) the parent list, not just to click away from the package. This procedure was designed for performance reasons.

 

Database

Oracle DBMS Issues

Oracle databases are case sensitive by default and can cause problems for certain WinINSTALL features. Example: Machine searches using a default Oracle database can return erroneous results. Reports can also be affected in the same way.

 

Database Rollup Shares

WinINSTALL provides the ability to roll up database data from the active database to another. The purpose of this feature is simply to allow decentralized databases to consolidate their data to a central database, which can then be used for reporting. Management of the machines involved must be accomplished from consoles connected to the decentralized databases, not for consoles connected to the rollup database. Attempting to manage machines that have been rolled up to the central database from a console connected to the central database will produce unexpected results.

 

Server upgrades from 2000 to 2003 Can render WinINSTALL unable to open the database connection dialogue

When you upgrade a Windows 2000 Server to Server 2003, you cannot open the database connection dialogue in the WinINSTALL console, making the console inoperable.

When WinINSTALL setup installs MDAC, it installs the file OLEDB32.DLL with a version of 2.71.9042 . When Windows 2003 is installed as a standard install (not an upgrade) the version of this file that is installed is 2.80.1022 . Either of these file versions works properly and will allow WinINSTALL to display the connection properties dialogue.

However, an upgrade install of Windows 2003 installs an older version of OLEDB32.DLL, version 2.70.7713 , which will not allow WinINSTALL to operate. This issue should be resolved in SP1 for Windows 2003.

In the event that you encounter this problem, you can work around the issue by simply obtaining either the 2.71 or 2.80 version of OLEDB32.DLL and copying it to the C:\Program Files\Common Files\System\Ole DB\ folder on the upgraded machine.

 

On XP Pro SP2 RC2 the Database server name does not appear in Database Wizard with local MSDE installed

After installing WinINSTALL with MSDE on Windows XP Pro SP2 RC2 the Database Wizard will not show the local machine's name with instance name in the Database server name drop down.

You can manually type in the database server name, and the Database Wizard will find the local database.

To avoid having to manually enter the database server name, open UDP port 1434.

 

Cannot uninstall and successfully re-install the product on the same machine.

If you have a WinINSTALL installation using MSDE and you uninstall it and then try to install (or re-install) v8.7, database creation will fail with the following message:

Msg 5170, Level 16, State 1, Server servername \ONDSQL, Line 1
Cannot create file 'C:\Program Files\Microsoft SQL Server\Data\MSSQL$ONDSQL\Data\WINSTALL8.mdf' because it already exists.

Msg 1802, Level 16, State 4, Server servername \ONDSQL, Line 1
CREATE DATABASE failed. Some file names listed could not be created. Check previous errors.

Cannot open database requested in login 'WINSTALL8'. Login fails."

Because an uninstall of WinINSTALL will never delete user data, the old WinINSTALL database remains. However, MSDE and SQL Server work in such a way that they will not automatically reconnect to the old database when WinINSTALL is reinstalled.

SQL 2000 Server and MSDE both have the notions of the server instance and the database. ( servername\ONDSQL is a server instance, WINSTALL8 is a database name). When you install MSDE, it creates the server instance only; it does not create a new database nor does it attach to existing databases.

Therefore, if you open the console and point it to the local MSDE, it would return an error saying that the database was not found.

In order that procedure to work, you must first attach the database to the server instance.

This problem has 3 possible workarounds:

  1. Delete the old database files (using Explorer) then rerun WIDBSetup.exe.

  2. Use a different name for the database when re-installing WinINSTALL.

  3. Use the Enterprise SQL Manager Console to attach the existing database to the MSDE server.

Note that the last option would be accomplished by running the Enterprise SQL Manager with the following command line:

osql.exe -S DBInstance -E -Q "exec sp_attach_db @dbname = N'DBName', @filename1 = N'db_path', @filename2 = N'log_path'"

DBInstance and DBName will be known by WIDBSetup.exe, but db_path and log_path are the canonical paths to the database and log files respectively--which must be explicitly provided here.

 

Active Directory

You may encounter problems with multiple DNS servers in an Active Directory environment. WinINSTALL will have problems with Active Directory Group Restrictions when the user has the WinINSTALL server/console pointing to a different DNS server than the one pointed to by the clients in the network. Having more than one active DNS server is an Active Directory configuration issue, not a WinINSTALL product issue.

 

NetWare

Because the console does not include a browser for NetWare credentials, you must be careful to properly specify the NetWare credentials. Examples of valid credentials for both NDS and Bindery are shown below. Note that all credentials are case-insensitive.

NDS:

 

Server/Tree:

Detroit

User:

CN=Bill.O=marketing

Bindery:

 

Server/Tree:

Chicago

User:

Bill

If the share is on a Windows platform (W2K or greater), users will be able to deploy the WinINSTALL Agent to Novell clients from the Console. If the Share is on a Novell machine, they will need to use the command line ( WiDeploy.exe plus an SMD file) to deploy the agent.

 

Discover

  • Discover does not support creation of transforms with unsupported schemas (0.3, 1.0).

  • Before you can create or use Discover's Archive Before snapshots, the operating system for which you want to do this must have the file cabinet.dll installed (usually in the system folder). Some operating systems (Win95) do not have this DLL. If you copy it from a Win98 system to the system folder of your Win95 system, Discover's Archive Before snapshots will work again. If you're missing this DLL, Discover will continue to work, but this feature will be disabled.

  • Discover fails to create a package with Chinese characters for .msi file name and .lst file name. NetBIOS requires the share code page to match the locale of the operating system on the machine running Discover. If the code pages do not match, the following error message will be displayed at the After Snapshot:

Severity 1
Return Code 110
Message:
Failed to Open Database.

  • When F1 is selected while running the Discover utility, the help may not display or may not display properly. This problem is caused by Internet Explorer security settings which prevent the display of HTML help files launched from a remote location such as the WinINSTALL share. See the following Microsoft KnowledgeBase article for details on the problem and possible solutions: http://support.microsoft.com/kb/896054.

    A workaround is to copy the file Discowiz.chm to a local folder and execute the local copy of this file directly, rather than by pressing F1 within Discover.

 

NAI to MSI Conversion

A Dr. Watson error may occur when converting a large NAI to an MSI on an NT4 system. You can possibly work around this bug by using the nai2msi.exe file in the WinINSTALL \bin folder. However, this error can sometimes occur with nai2msi.exe as well. Generally, if you move elements around in the NAI file (for example, reordering the files to copy), the problem will go away.

 

MSI Validation

When you browse to the .cub file that you want to use for MSI validation, the Open dialog does not default to the \bin directory where .cub files are located, but instead opens to the last working directory.

The product currently supports the following ICE (Internal Consistency Error) repairs:

ICE02

Circular File/Registry/Component relationships

ICE05

Required property validation

ICE08

Duplicate component GUID

ICE09

Permanent component validation

ICE10

Child/parent feature advertising validation

ICE14

Child/parent feature relationship validation

ICE15

MIME/Extension circular relationship validation

ICE16

ProductName length <= 63 characters

ICE18

Null component keypath validation

ICE21

Component/FeatureComponents validation

ICE36

Icon bloat

ICE42

Class Inproc/Local server validation

ICE49

Registry default value type validation ( see note 1 )

ICE54

Keypath file version indirection validation

ICE55

LockPermissions validation

ICE73

Reserved GUID validation

ICE74

UpgradeCode/FASTOEM property validation ( see note 2 )

Note 1: WinINSTALL will repair the issue raised by ICE49 by making the component conditional as recommended by Microsoft. However, ICE49 does not check to see if the component is conditional, so it will continue to raise the warning, even if the component is conditional. Also, since WinINSTALL checks to see if the component is conditional first and will not modify any existing conditions, it may be that the component should still be reviewed manually to make sure that the condition is sufficient to not have the component install on Win95.

Note 2: There is currently an issue with how Validation works, such that if the FASTOEM property is in the property table, validation will fail to run because MSI fails to open the package. This will be addressed in the next version such that packages that author the FASTOEM property in error won't fail Validation and can then be repaired. The other repairs related to ICE74 are functional, as is the repair for FASTOEM, but the FASTOEM repair cannot be demonstrated due to the Validation issue.

Validation on Japanese Systems

MSI Validation messages show up in English instead of Japanese.  These messages are derived from the selected cub file, and these files are supplied by Microsoft.  Unfortunately, Microsoft does not provide Japanese-translated .cub files.

 

Packaging

  • When attempting to add an INI file to the Edits|INI Files|Remove Tab for MSI files, you must specify a value before the INI file can be written to the table. Unlike NAI files, MSI files require a value to be specified. INI files and INI file sections cannot exist independently in an MSI package. If an entire section is to be deleted - each value must be present in the Remove side.

  • For new INI File Edits, if a file name is typed in but no path is specified, @WINDOWS will be appended to the beginning of the file name. The user can, however, specify another variable or directory and @WINDOWS will not be appended to the beginning.

  • The Access Denial Message is tied only to the conditions that can be set on the General tab: Password , Environment Variables , and Registry Values . This feature has nothing to do with other condition settings, such as video resolution or disk space.

  • If you add package restrictions to a .nai file or .msi file and then decline to save the changes, the UI may behave as though the group restriction has, in fact, been saved. This is a display anomaly only--the data has not been saved.

    If you leave the Software Distribution area of the product, for example, and then return and select the same package, you may see the restriction you declined to save. Although it looks as though this change has been saved, in fact it has not been written to the package file. If you restart the console or select View/Refresh (F5) and then look at the same package, you will find that the restrictions are not present.

 

Scheduling

Scheduling Publish and/or Merge Jobs

Publish and merge tasks are operations carried out by servers, not by workstations. Nevertheless, you may want to run or schedule a publish or merge operation in order to affect a particular workstation or selection of workstations, without knowing the servers involved. Both the Run Task and the Schedule facilities enable you to do so--without knowing what servers are involved.

You can simply select Publish or Merge as the task to run or schedule, and then select the desired workstations as targets, and WinINSTALL will queue the publish or merge operation to the appropriate servers.

Server-only tasks (i.e., Publish, Merge) may be scheduled to scopes of WinINSTALL servers only or Selected machines . You cannot schedule such operations to a scope of WinINSTALL workstations only or to WinINSTALL workstations and servers .

To schedule a publish action to or merge action from a specific workstation or group of workstations, select a scope of Selected machines and then select the desired workstations.

WARNING: When you schedule a publish or merge task to one or more target workstations (as opposed to target servers), the job can cease functioning if you later change the server assignments of the workstation specified as the target or if you change the server merge/publish responsibilities for the shares involved. In such a situation, the scheduled job will continue to run on the servers for which they were originally scheduled. The job can be shifted to the new servers only by editing the scheduled job in the console and re-saving it.

 

Installer

  • If a WinINSTALL package is configured in the Console for subscribed or unsubscribed WIPL, the package cannot be installed without using the /wipl switch. If a normal package install is desired, all WIPL settings must be disabled in the console.

  • In some cases, setting a system condition on a package such that Installed Memory must be Equal to a specific value will not work correctly. Because each system can report system memory differently, using the Equal to setting could cause a list or package to not install in some cases. To avoid this problem, specify memory requirements using Greater than or equal to or Less than or equal to.

  • Including the /Quiet switch on the command line for the Automatic Installer will suppress any user prompts while an installer is performing an installation. If you include the /Quiet switch on the command line where a distribution package is specified, the automatic installer will reinstall previously installed applications. This is because WinINSTALL is programmed to answer the suppressed prompt " Do you want to reinstall? " with Yes . If you specify a list file rather than a distribution file with the /Quiet switch, WinINSTALL will answer the prompt with No , and the automatic installer will not reinstall previously installed applications. These switches are not case-sensitive and can be used in any logical order. The /Quiet or /Quiet_NoPrompt switch prevents the installer from appearing on the desktop, prompting the user, or raising error messages.

  • In order to enable the operation of the feature that automatically uninstalls an application if a user no longer meets group restrictions, either the Group restriction or the Group policy, or both of these, must be set at the list level, and the Automatic Installer must be run against the list. Only then will the uninstall take place for the user who no longer meets Group restrictions.

 

Patch Management

Operating System Limitations

  • The new WinINSTALL Patch Management feature (vulnerability scans and remediation jobs) is not supported on operating systems earlier than Windows 2000.  

  • WinINSTALL Patch Management may fail to return all required updates for machines running Windows XP, Service Pack 1.  It is highly recommended to update these machines to Service Pack 2 and then immediately re-scan them to identify any additional vulnerabilities.

  • Although you cannot run a vulnerability scan on Windows 95, 98, or NT, you can determine vulnerability for these systems from the inventory results, and then use the Create patch package feature to distribute patches to these systems through WinINSTALL software distribution, as in prior WinINSTALL releases.

Disk Space Requirements

Be careful about remediating systems with little free disk space.  If you select a large number of patches for remediation, it is possible for a target machine to run out of disk space during the patch download process.  Such a situation will not only fail to execute the remediation; it may also cause the WinINSTALL master agent to crash.

Windows Update Agent Fails to Update

During a Patch Management scan you may receive the error "Failed to update the Windows Update Agent."  If this occurs you may not be able to scan and/or patch the machine until the Windows Update Agent has been updated.  There is very likely nothing wrong.   A second attempt at updating the Windows Update Agent will succeed.  To update the agent you can do any of the following:

  1. Do nothing.  The machine will periodically check if the Windows Update Agent requires updating.  This check occurs no more than once a day.  If you wait, eventually the machine should be updated automatically.

  2. You can manually update the machine by running the Windows Update Agent installers located in your WinINSTALL share.  Run \\server\WinINSTALL\Patches\Microsoft\WindowsUpdateAgent20-XXXX.exe (where 'XXXX' is your hardware; e.g. x64, x86, or ia64).

  3. You can manually update the machine by downloading the Windows Update Agent installer from Microsoft's download web page.

  4. You can manually update the machine by running Windows Update.

User and Group Restrictions for Remediation Jobs

In the current release, user and group restrictions do not work as expected for Patch Management remediation jobs.  This limitation will be corrected in a future release.   In the meantime, you can either distribute the desired patches using WinINSTALL packages (which do work correctly with user and group restrictions) or else avoid using user and group restrictions with Patch Management remediations.

Update Installation Problems

If an update fails to install through WinINSTALL Patch Management (driver updates in particular can prove troublesome), you can usually determine how to get it to install correctly.  Please see the console help file or the Administrators Guide for instructions on how to go about this process.

For certain updates, it may be necessary to run the update as an interactive user.  While this situation is very unusual, it can be accommodated by creating a WinINSTALL package using the Create patch package feature and then distributing that package to the interactive user, rather than to the WinINSTALL agent.  Examples of this situation include KB887472 and KB925850 (for 64 bit Windows).

 

Windows Vista™

Only limited preliminary testing has been done with WinINSTALL on Windows Vista. Our plans are to fully support Vista in the next release of WinINSTALL.  In the meantime, the following issues have been identified with running the current version of WinINSTALL on the final released version of Vista:  

  • On a Vista machine with the Sidebar running, Discover fails in the after snapshot section with a message that states "A sharing violation occurred while accessing \path\WindowsSidebar\Settings.ini."  With the Sidebar turned off (i.e., "Exited"), Discover will complete.

  • By default, Vista doesn't start the Remote Registry service, which can be a security exposure if recommended security practices aren't followed. This service is required for deployment of WinINSTALL agents, so must be started manually before you can deploy to Vista machines (including the console machine). Once deployed, you can stop the service again.

  • By default, Windows Vista will present a warning when the WinINSTALL Installers are executed because these executables are not signed in this release.  A workaround to avoid this warning is to explicitly mark the files in question as authorized to run at the desired security level. You mark applications with requested execution levels by adding entries for the specific applications to the application compatibility database.

For the next WinINSTALL release, we will be doing more comprehensive testing to ensure WinINSTALL works smoothly with Vista, making adjustments where necessary. In the mean time, we welcome your feedback on WinINSTALL and Vista.