ReadMe
WinINSTALL 8.70.0400
Desktop Management Suite and
Desktop Availability 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 2006 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, a list of the major issues resolved in this release, 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

Replication

Sample Packages

Upgrading from an Evaluation Copy to a Permanent License

Support Forum

New Features and Enhancements

PXE-Based Client Reset

Machine Ping from the Console

Ability to Suspend Scheduled Jobs

WinINSTALL Software Distribution Suite (SDS)

MSI Packaging Improvements

Wake on LAN

Improved support for Workgroup Environments

Improved Agent Deployment and Monitoring Capabilities

Configurable Share Selection

Multiple Patch Download Capability

License Management Improvements

Improved CD Wizard

Job Scheduling to User Accounts

Global Jobs and Defaults

Client Reset Improvements

New Release of the Personality Transfer Engine

SQL Server 2005 Support

Problems Resolved

Active Directory

Wake On LAN (WOL)

WinINSTALL Agent

Agent Deployment

Agent Status

CD Wizard

Console

Discover

Help and Documentation

Installers

Publisher

Client Reset

PXE Client Reset

Personality Transfer

Replication

Reporting

Scheduling

Share Proximity Determination

Limitations and Known Issues

Setup

MSDE DBMS Setup

MSDE DBMS Removal

Evaluation Limitations

Upgrading from an Evaluation Copy

Initializing the WinINSTALL Database

WinINSTALL Agent

Secure Manual Deployment

Agent Deployment

Agent Configuration

Changing the database

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

Inventory/View Application File Relations

Discover

NAI to MSI Conversion

MSI Validation

Packaging

Scheduling

Scheduling Publish and/or Merge Jobs

Scheduled Job Start and End Times

Installer

NoNetNoGo

PXE Client Reset

Windows 95/98 Limitations

NLS (Non-English) Operating Systems

Client Reset

Replication

Personality Transfer (Desktop Availability Suite only)

Personality Repository Security

Personality Transfer Character Limitations

User Account Handling During Migration

Policy Distribution

Migration Can fail when attempting to migrate to Windows XP

Personality Transfer Restore jobs may not follow file overwrite setting specified when creating the job.

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.

Replication

Replication is possible only between machines assigned the role of WinINSTALL server. That is, both source and target machines must be WinINSTALL servers and must have WinINSTALL agents deployed.

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 Desktop Management Suite or Desktop Availability 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.

Support Forum

Attachmate provides a free forum for support and discussion of all WinINSTALL products at http://bbs.ondemandsoftware.com

New Features and Enhancements 

The 8.7 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.

PXE-Based Client Reset

The WinINSTALL Desktop Availability Suite (DAS) now includes an exciting new client reset facility based on PXE (Preboot eXecution Environment). This facility is extremely easy to configure and use, and it does not use DOS or any other operating system other than the one being installed on the target machine.

PXE reset server files, including operating system files, drivers, and post-install utilities, are available to be replicated from one PXE server to another using WinINSTALL's built-in replication feature.

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.

WinINSTALL PXE Client Reset installs Windows operating systems using the original setup programs supplied by Microsoft, driven by a configuration file so as to streamline the process and make it operate entirely unattended. Using the vendor setup program to install the operating system enables use of a single set of operating system files for many configurations, while avoiding having to create and maintain separate images for each desired configuration. In addition, the WinINSTALL PXE reset process has been optimized to the point where install times are very fast.

The seamless integration of PXE Client Reset with WinINSTALL's powerful personality transfer and software distribution capabilities provides unmatched power and simplicity to desktop management. The full integration of these features makes it a simple matter to right-click on a machine, or group of machines, in the WinINSTALL Console, and with a single command, back up the user data and settings, reboot the PC, format the hard disk, install a new copy of Windows 2000, XP, or 2003, followed by a series of patches and application packages, and conclude with a restoration of the user data and settings. WinINSTALL PXE Client Reset provides an easy, efficient, and convenient method of rebuilding any PC or group of PCs on your network--remotely, while the PCs are unattended.

WinINSTALL PXE Client Reset allows you to reset a client in any of three ways:

  1. You can select the desired client and invoke an immediate reset.

  2. You can configure a reset to occur on a machine's next reboot.

  3. You can schedule PXE Client Resets to occur at a set time in the future, or even on a regular, recurring basis!

When you invoke an immediate reset or schedule a reset (methods 1 and 3, above), WinINSTALL's PXE Client Reset feature will automatically employ Wake-on-LAN to execute the reset, if needed.

Machine Ping from the Console

With WinINSTALL Software Distribution Suite, Desktop Management Suite, and Desktop Availability Suite, the WinINSTALL console now provides a built-in ping capability which allows you to test connectivity between the console and any machine or selected group of machines. The WinINSTALL ping feature can test single or multiple machines at once and is completely configurable to assure effective operation in your environment.

To use the WinINSTALL ping feature, you simply select the desired machine(s) in the machine list, and then select Ping... from the Machines menu or the right click context menu.

The WinINSTALL ping feature can test single or multiple machines at once and is completely configurable to assure effective operation in your environment.

Ability to Suspend Scheduled Jobs

You can now temporarily halt execution of any scheduled task. Suspending a scheduled task does not cancel the task, nor does it delete it from the WinINSTALL database. Instead, it simply suspends, temporarily, the execution of the task. Execution can then be resumed at any time, without having to re-create the scheduled task.

WinINSTALL Software Distribution Suite (SDS)

WinINSTALL is now available in a version providing software packaging and distribution capabilities only, for those environments where inventory, replication, operating system deployment, and other advanced capabilities are not needed.

The new WinINSTALL SDS product is a perfect fit for those environments which require the power and simplicity of WinINSTALL packaging and distribution but are not ready for the advanced feature set of the full WinINSTALL Desktop Management Suite or WinINSTALL Desktop Availability Suite products.

WinINSTALL SDS is designed for those organizations in need of complete, flexible software packaging and distribution but not requiring inventory, license and asset management, operating system deployment, package replication, or personality transfer capabilities.

MSI Packaging Improvements

WinINSTALL's MSI packaging capabilities have been enhanced in numerous ways, including the addition of the following features:

  • WinINSTALL now provides the ability to store within the MSI file itself a history of modifications made to it in the WinINSTALL console.

  • WinINSTALL now provides the ability to easily prompt a user for the value of a Windows Installer property. Simply enter a name for the dialog to be presented, the prompt to present to the user, and the property in which to place the text entered by the user.

  • WinINSTALL now allows the creation of transforms by simply comparing two MSI files. The difference between the two is automatically converted into a transform. When this transform is applied to an installation of the first MSI file, it matches an installation of the second.

Wake on LAN

WinINSTALL Software Distribution Suite, WinINSTALL Desktop Management Suite, and WinINSTALL Desktop Availability Suite now provide the ability to wake machines from a sleep state through Wake-On-LAN functionality. You can issue a Wake-On-LAN command immediately or schedule it for a specified time in the future.

If you are using either the WinINSTALL Desktop Management Suite or the WinINSTALL Desktop Availability Suite, you have the additional option of adding the Wake function to any scheduled job.

Improved support for Workgroup Environments

WinINSTALL Software Distribution Suite, WinINSTALL Desktop Management Suite, and WinINSTALL Desktop Availability Suite all offer improved workgroup networking support, including the addition of a new Console setting to enable seamless browsing of non-Active Directory, non-Domain environments.

Improved Agent Deployment and Monitoring Capabilities

This release of the WinINSTALL suite products introduces automatic network deployment of the WinINSTALL Agent, plus a number of additional enhancements to the agent deployment and monitoring capabilities:

  • Account credentials can now be securely re-used for multiple deployment operations without having to re-enter them for each operation.

  • The Agent Activity window displays the progress of deployment and other machine operations in real time, and roll-over tool tips provide extra status information.

  • Agent status now includes additional states and diagnostic information.

  • The Machine/General tab now shows the current status and activity of each WinINSTALL sub-agent.

  • The Machine/General tab now provides the ability to configure the behavior of the agent status refresh feature.

  • Secure Manual Deployment (SMD) deployment has been enhanced to permit the contents of the SMD file to be overridden in some circumstances. The primary purpose is to enable the deployment share to be specified at the time of deployment, which can allows a single SMD file to be used enterprise-wide.

Configurable Share Selection

WinINSTALL now provides the ability for each workstation to determine on boot up which WinINSTALL share, among a pre-defined group, is the optimal share to use.

The advanced operations provided in DMS and DAS are particularly helpful for laptop users who visit multiple locations within the organization. In this situation, such users can automatically attach to the nearest WinINSTALL share at whatever location they find themselves, rather than always pointing back to a "home" share.

Of course, administrators can configure the order in which shares are considered and the criteria by which the nearest share is determined.

Multiple Patch Download Capability

The WinINSTALL suite products now permit easier management of Microsoft patches, including the ability to download and automatically create packages for multiple patches at once, and (via a special WinINSTALL utility), access to patches in all Microsoft-supported languages.

License Management Improvements

The WinINSTALL DMS and DAS License Management capability has been expanded and improved in a number of ways. For example, you can now see at a glance how many licenses you have, how many are in use, and how many remain available.

Improved CD Wizard

The WinINSTALL CD Wizard (available in WinINSTALL Software Distribution Suite, Desktop Management Suite, and Desktop Availability Suite) enables an administrator to very quickly and easily stage applications and lists of applications for burning onto a CD or DVD. It's also very simple to include one or both WinINSTALL Installers and to create an AutoRun file to execute on insertion of the media.

In this release, the CD Wizard has been streamlined and simplified for quicker, easier, and more trouble-free creation of application package CDs and DVDs.

Job Scheduling to User Accounts

When scheduling jobs to specific users and/or user groups, the WinINSTALL suite products now check each target machine to determine whether or not any specified target user has an existing account profile on the machine. If so, the job is executed.

This behavior is a change from previous versions, where the only account evaluated was the account under which the WinINSTALL Agent was operating.

Global Jobs and Defaults

WinINSTALL now provides an easy method to schedule a job to execute on all workstations, including workstations which have not yet joined the network.

In addition, this release makes it easy to change settings on all workstations and to change the default settings for all machines in your network.

Client Reset Improvements

The Client Reset feature available in the WinINSTALL Desktop Availability Suite now includes enhanced capabilities extending beyond installing or restoring operating systems on workstations.

  • Machine names are now automatically preserved across reset operations.

  • Dynamic List Files, automatically created after an inventory, enable the automatic restoration of the entire set of pre-reset installed applications.

  • Advanced operations include application mapping (substitution of new post-reset applications for specified pre-reset applications). This feature enables automatic application upgrades as part of the reset process.

  • Personality backup and restore can easily be included into an automated reset process, enabling a full client reset in a single operation: backup, followed by a reboot, hard drive reformat, OS install and application set install, and concluding with user data and settings restoration.

  • Virtual floppy packages enable drag and drop or scheduled resetting of single workstations or groups of workstations.

New Release of the Personality Transfer Engine

WinINSTALL Desktop Availability Suite now includes the Tranxition Personality Transfer Pro™ 4.60 engine, with improved performance and full extraction and injection capabilities for a large number of common applications and Windows settings.

SQL Server 2005 Support

WinINSTALL now supports Microsoft SQL Server 2005, including all available editions.

WinINSTALL database support now includes the following database management systems:

  • Microsoft SQL Server 2000 Desktop Engine (MSDE 2000)

  • Microsoft SQL Server 2000

  • Microsoft SQL Server 2005

  • Oracle 9i and later

 

Problems Resolved

The WinINSTALL 8.70.04 release includes resolutions to a number of issues uncovered in prior versions. The most important of these fixes are listed below, according to the main area of the product affected.  Fixes in earlier versions of 8.7 are also listed, noting the specific release where the fix first appeared.

Active Directory

Active Directory entries containing embedded commas are now fully supported in the product. However, such entries are displayed in the Package Restrictions area with a backslash character ("\") preceding each comma. This is a display issue only. (8.70.01).

Wake On LAN (WOL)

WOL messages were not being sent to the subnet of the client machine when Directed broadcast method was specified under Agent Settings in earlier releases.  This problem has now been addressed, meaning that Directed packets MAY cross routers, but only if the routers involved are so configured.  Because of security reasons, they rarely are, but this option allows administrators to send WOL packets from one subnet to another, provided their routers allow it. (8.70.04).

WinINSTALL Agent

  • The WinINSTALL Agent no longer retrieves global configuration files at every Configuration Files Interval.  In earlier releases, this erroneous behavior caused unnecessary network traffic.  Now the files are copied only if they have changed. (8.70.04).

  • Originally, the global SlSites file was re-published, even when server properties had not been changed. Such publication causes all machines to re-download the file, and to purge and reload the share proximity cache. This problem has been resolved. (8.70.03).

  • In situations where the WinINSTALL Agent is configured for proximity detection but no shares are configured to support such detection, or when proximity detection is disabled but all of the assigned shares use proximity detection, the Master Agent issues a warning indicating that it is going to contact the deployment share, because this is considered an error condition. But the Master Agent did not actually contact the deployment share, so under these circumstances, no simple means was available to get the correct configuration information to the workstation. This behavior has been corrected; under these circumstances the Master Agent now actually attempts to attach to the deployment share. (8.70.03).

Agent Deployment

Running the WIDeploy utility locally, with a Secure Manual Deployment (SMD) file, on machines with an agent installed would attempt to install the agent again.  WIDeploy is often used through Active Directory startup scripts to deploy agents automatically, which would result in delays for users while this installation was unnecessarily attempted.  WIDeploy now checks to see if the agents are installed when doing a local deployment, and if so, it simply issues a warning and does not attempt to install the agents. (8.70.04).

Agent Status

  • WinINSTALL now provides granular control over the frequency and operation of the agent status update in the machine list. For details, see the section entitled Viewing WinINSTALL Agent Status in The WinINSTALL Agent chapter of the Administrators Guide. (8.70.03).

  • The Agent Activity dialog now provides additional information on error messages generated by the Start/Stop Agent commands. In addition to more detailed reporting, additional information is also available in tool tips, which display when the cursor is hovered over the error message on the Agent Activity dialog. (8.70.0201).

CD Wizard

No longer is only one list file available for inclusion on the CD (usually WinApps.lst ) when the CD Wizard is invoked from the toolbar. (8.70.02).

You may now select any list file as a base list from which to stage your CDs, whether you invoke the CD Wizard from the toolbar or by right-clicking on any list file and choosing the context menu item Stage CD . (8.70.02).

Console

  • The loading of large numbers of machines into the Machine List has been greatly improved. (8.70.04).

  • A new option is now available from the Machines ->Options dialog to update only those machines visible in the Machine List control.  This option is used in conjunction with the automatic and manual refresh options.  When this option is checked, the only machines that will have status updates are those that are immediately visible in the list control.  The machines processed by the status thread are updated when the user scrolls, pages, or executes a search. The benefit of this change is that at any point in time, the status thread will be processing a relatively small number of machines (e.g., 30) and those will be the ones the user is viewing.  The user won't have to wait for large numbers of machines to be processed before he sees the one he is interested in. (8.70.04).

  • The user is now able to copy information from the Description field of the console log. (8.70.03).

  • WinINSTALL Agent Status in the console now indicates when a machine name does not match the machine ID shown in the database for that machine, or when two machines have the same name. (8.70.03).

  • The All Machines view in the console now displays a count of machines with running WinINSTALL agents. (8.70.03).

  • The console log now creates entries when a Secure Manual Deployment (SMD) file is created. (8.70.03).

  • When you add a workstation or server through the Add Machines Wizard and check the WinINSTALL Agent is already deployed box, the last page of the wizard no longer allows you to check the box to indicate the agent should be deployed. (8.70.03).

  • The machines list has moved the Select All button from the bottom, below the list, to the right side, under the column of other buttons. In addition, support for the Ctrl-A key sequence has been added to the list, and a Select All command now appears in the Edit menu. (8.70.03).

  • When you double-click a machine in the machines list, go the Log tab, and then select one of the log sub-pages, the commands in the Edit menu (e.g., Copy) and in the context menu (e.g., Details) now work as expected. (8.70.03).

  • The Agent Activity dialog now monitors the service status during processing of start/stop commands. If the status is not returned, the Agent Activity dialog and Console Log will eventually time out and display a warning message indicating that fact, and that the status is unknown. (8.70.03).

  • The agent status display in the console is now much more detailed than in previous versions, including diagnostic information, where available. (8.70.03).

  • When a database is upgraded from 8.6 or earlier to 8.7, the upgrade script adds the NEAREST_SERVER column to the WIAI_MASETTINGS database table, and sets its value to the default value of NULL, which is interpreted as equal to 1 (ENABLED). However, if machine settings are later changed, earlier console versions would incorrectly interpret the NULL as 0 and write this incorrect value to the database, effectively disabling share proximity detection on the machine and possibly preventing it from connecting to any WinINSTALL share. This problem has been resolved. (8.70.03).

  • When adding a service to a package, if the Import NT Service button was used but the Add Service dialog was canceled, the console would terminate. This problem has been resolved. (8.70.03).

  • In earlier versions, the Republish command would not publish settings for the targeted workstations. Instead, it would republish the settings for the servers to which the selected machines were assigned. This behavior has been corrected. (8.70.03).

  • This version resolves several potential problems in merging third-party (e.g. Microsoft) merge modules into Discover-created MSI packages. Symptoms could have included missing Directory table entries after merging-in a merge module during conversion to MSI, or even a console crash. (8.70.03).

  • WinINSTALL now provides the ability to copy all or selected list items to the clipboard or to export them to a tab-delimited text file. This capability has been added to the Assets and Licenses tabs, the Agent Activity dialog, the machine list, and the Console Log pages. (8.70.03).

  • The Console title bar now displays the path of the current WinINSTALL share. (8.70.0201).

  • The stability of the Custom Action Wizard has been improved. (8.70.01).

  • Creating Merge or Publish tasks in the console no longer causes database errors when an Oracle database is connected. (8.70.01).

  • The AppSearch CompLocator dialog now displays GUIDs instead of component IDs. (8.70.01).

  • MSI packages containing an AppSearch CompLocator entry now install properly. (8.70.01).

Discover

When Discovering an ODBC DSN, the machine-specific MAC address is also captured. Distributing the resulting package to multiple machines results in all connections to the data source appearing to come from the same machine. Discover's default registry exclusions have been modified to prevent this information from being included. (8.70.03).

Help and Documentation

The product help and documentation include a number of corrections and improvements to both correct inaccuracies and improve clarity.  To reduce the number of supplied documentation files, the contents of the Release Notes document have been moved into the ReadMe file (this file), and the information from the WinINSTALL Reference Guide has been incorporated into the WinINSTALL Administrators Guide. (8.70.04).

Installers

In earlier versions, when several packages were separately scheduled to be installed on a machine, if one package failed to install due to package conditions, the rest of the queued packages would also fail to install. This problem has been resolved. (8.70.03).

Publisher

To address a performance problem with the Publisher sub-agent in networks with large numbers of WinINSTALL workstations, the Publisher sub-agent defaults to verifiying that MAC address and Dynamic List files are up to date only on agent startup and every 15 publishing cycles thereafter. In earlier versions this verification was performed at every publishing cycle, but the verification process can be quite time-consuming, so a larger count is desirable. The default count is 15, meaning that, for example, if the publishing interval is two minutes, dynamic LST file processing will occur every 30 minutes.. The 15-cycle interval is determined by a setting in the WinINSTALL database and is configurable through execution of a stored procedure in the WinINSTALL database. For details on that procedure and how to execute it, see the section entitled Procedure to Set the Dynamic List Publishing Interval in the Special WinINSTALL Utilities section of the Miscellaneous chapter of the WinINSTALL Administrators Guide. (8.70.0201).

Client Reset

Installation of  Windows XP with Service Pack 2 integrated could fail with the message, "Partition is too full to contain Windows XP" when the drive actually did contain enough space for the installation.  This problem has been resolved.  WinINSTALL will now create the initial partition using FAT32.  This partition will use all of the available space on the drive.  If NTFS is selected as the file system in the template, the OS installation will convert to NTFS normally.  (8.70.04).

PXE Client Reset

  • Installing Japanese, Korean, Traditional Chinese, or Simplified Chinese versions of Windows 2000 Professional, Server, or Advanced Server could result in a failure to copy the files c8514fix.fon, c8514oem.fon, and c8514sys.fon, requiring user interaction on the client machine to circumvent the problem. This issue has been resolved, and the failure to copy errors will not occur.  (8.70.03).

  • A number of issues involved with resetting machines to Spanish, Brazilian Portugese, and Japanese versions of Windows operating systems have now been resolved. (8.70.03).

Personality Transfer

After performing a Backup of a machine that has a specific user profile, the job could not be Restored to a different machine if that same user profile was not already present.  WinINSTALL now allows source users to be remapped to the destination machine.  But the administrator must explicitly specify the destination target users if the source and destination machines are different. (8.70.04).

Replication

  • When replicating packages with the Preserve Folder option enabled, packages were not being replicated to sub-folders correctly; instead, packages were replicated to the root Packages folder.  This problem has been corrected. (8.70.04).

  • In earlier releases, an error would occur when attempting replication from a server which owns no shares, even if that server has shares assigned. Replication from such a server will now automatically proceed from the first assigned share. (8.70.03).

  • Zero byte files with the Hidden and/or System attributes set will now replicate properly. (8.70.01).

  • Client Reset Templates with hidden partitions enabled will now replicate properly. (8.70.01).

  • The Replication Wizard will no longer run at startup if the Run Share Replication Wizard on startup checkbox is unchecked on the Console Options dialog. (8.70.01).

Reporting

The following reports have been added (8.70.03):

  • Last logged on user (Inventory category)

  • Last inventory date and time by machine group (Inventory category)

  • Last inventory date and time in chronological order (Inventory category)

  • List of all licensed applications, number of licenses and the total number of installs (Console category)

Several reports which did not work with an Oracle database in earlier versions have been fixed and now work properly with either SQL Server/MSDE or Oracle. (8.70.03).

Scheduling

  • Editing scheduled Run Once jobs could cause unwanted changes in the job scheduling configuration under certain circumstances. For example, the job could be configured to run once, but the recurrence pattern could be set to cause the job to run, say, only on a Saturday in the 3rd week of the month. If the user later edited the job or switched back to view the Schedule page, the recurrence pattern would be lost. Now the user can select the Run Recurrently option with an occurrence count of 1 and it will be interpreted as a Run Once job when editing or switching pages back to the Schedule page. Specified recurrence patterns are now retained in this situation. (8.70.03).

  • Opening and viewing a "Run recurrently" schedule in the console no longer resets its recurrence to "Run Once." (8.70.03).

Share Proximity Determination

  • WinINSTALL had a problem using ping to determine which share to connect to. This share proximity determination method will now work correctly. (8.70.03).

  • Maximum ping packet size has been increased to 65,500 bytes. (8.70.0201).

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:

v8.7 Licensed Product (Upgrade Permitted):

LE

MSI

SDS

DMS

DAS

LE 8.7 Eval

YES

NO

NO

NO

NO

MSI 8.7 Eval

NO

YES

NO

NO

NO

SDS 8.7 Eval

NO

NO

YES

YES*

YES*

WinINSTALL 8.60 Eval

NO

NO

NO

YES

YES

WinINSTALL 8.60.01 Eval

NO

NO

NO

YES

YES

DMS 8.7 Eval

NO

NO

NO

YES

YES

DAS 8.60 Eval

NO

NO

NO

YES

YES

DAS 8.60.01 Eval

NO

NO

NO

YES

YES

DAS 8.7 Eval

NO

NO

NO

YES

YES

SDS 8.7

NO

NO

N/A

YES*

YES*

WinINSTALL 8.60

NO

NO

NO

YES

YES

WinINSTALL 8.60.01

NO

NO

NO

YES

YES

DMS 8.7

NO

NO

NO

N/A

YES

DAS 8.60

NO

NO

NO

NO

YES

DAS 8.60.01

NO

NO

NO

YES

YES

* Upgrading the Software Distribution Suite to the Desktop Management Suite or the Desktop Availability Suite requires following a special procedure to accommodate the changes in database configuration between SDS and the other products. 

NOTE: Upgrading to 8.70.04 from 8.70.0000, 8.70.0100, 8.70.0200, 8.70.0201, or 8.70.03 is accomplished by executing the appropriate product-specific patch. If you want to move from an evaluation version of 8.70.0000, 8.70.0100, 8.70.0200, 8.70.0201, or 8.70.03 to a licensed version of 8.70.04, you must perform two operations: license the product and upgrade the version. These two operations can be performed in any order.

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.

If you have an earlier version of WinINSTALL 8.x installed, when you first start the console after applying the upgrade patch, you will be prompted to allow WinINSTALL to automatically update the database schema. If you would prefer to update the schema manually, please see the release notes to the patch for instructions on how to run the script to update the database schema to 8.70.04.

WinINSTALL Agent

  • Installing the WinINSTALL Agent on Windows 95, Windows 98, and Windows NT 4 machines 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.

  • 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.

Secure Manual Deployment

The Secure Manual Deployment UI, available from the Machines List context menu and from the Machines menu, currently provides no positive feedback that the SMD file was created successfully.

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.

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 fill in the missing share information.

  6. Select each server's (or all the servers') Settings page(s) and fill in the missing database connection information (it will have been lost), along with any other missing information.

  7. 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.

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.

Inventory/View Application File Relations

During installation of certain OEM MSI files, the install file paths are resolved using custom actions, rather than through the accepted practice of entering target paths in the MSI file's Directory Table. Therefore, in such cases, the Directory Table in the MSI file shows a different path from the one where the file ultimately gets installed. As a result, when executing a View/App File Relations operation on a workstation inventory containing such an application, some of the files may incorrectly show as missing.

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.

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

  • If the @WinstallDir variable was used to create packages in v7.5 and earlier versions of the product, these packages won't work correctly when copied to the packages directory of 8.xx Shares. The reason is that @WinstallDir resolves to the folder where the WinINSTALL installer executable resides. In earlier versions, this directory was typically the \Winstall folder on the WinINSTALL server. In version 8.xx, the WinINSTALL installer executables reside in \WinINSTALL\Bin . In previous versions of the product, users often stored packages in the \Winstall folder. Now we recommend storing them in the \WinINSTALL\Packages directory. In most cases (as described above), simply replacing @WinstallDir with @PackageDir will solve the problem with these legacy packages. Some editing and/or package configuration may be needed.

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.

Scheduled Job Start and End Times

Due to an anomaly in the current release, when a job is scheduled with a start date of today and a time window which has passed for the day, it will never execute. The end date may be many days away, but if the time window has already expired for today (and the start date is today), then the job will not be executed.

A temporary workaround is to schedule the start date for tomorrow, rather than today, if the desired time window has already passed for the current day. This change will assure that the job is executed tomorrow.

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.

  • The following switches are no longer valid - / SuppressNetworkerrors , /SuppressNetWareErrors and /SuppressMSNetErrors .

  • 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.

NoNetNoGo

NoNetNoGo does not work using the NoNetNoGo.ini file. The workaround is as follows:

Create an item in the HKEY_CURRENT_USER\SOFTWARE\OnDemand\WinINSTALL\NoNetNoGo key named Command (a string item), which NoNetNoGo.exe will execute if it can (or silently fail if it cannot). Using the HKEY_CURRENT_USER hive allows system administrators to have only one version of this executable on the file system, yet allow multiple users to have discrete command lines, unique to them. This currently replaces the legacy way of handling this, which involved multiple copies of the NoNetNoGo.exe and different INI files.

PXE Client Reset

Windows 95/98 Limitations

In the current release, neither scheduled reset nor immediate reset work for machines with Windows 95 or Windows 98 installed. But you can effect a scheduled reset or an immediate reset by setting these machines to reset on the next reboot, and then scheduling or distributing a WinINSTALL package that reboots the target machine.

However, if such machines are not running but are in a state from which they can be booted by Wake on LAN, then immediate reset will work.

NLS (Non-English) Operating Systems

While WinINSTALL PXE Client Reset can install most non-English operating systems as simply and easily as it can English operating systems, we have identified technical challenges posed by the following language/operating system combinations.

Windows 2003 Standard/Enterprise Server French

Installing French versions of Windows 2003 Server (either Standard or Enterprise) may result in a failure to copy the file channels.scf . There are two workarounds if you encounter this problem:

  1. You can choose to skip this file; setup will then continue uninterrupted.

    NOTE:
    This workaround will require user intervention at the target machine during the reset process.

  2. On the WinINSTALL share, edit the appropriate file, as specified in the following table:

    Operating System

    File to Modify

    Windows 2003 Enterprise Server Volume License

    ClientReset\1036\Win2K3eV\i386\txtsetup.sif

    Windows 2003 Enterprise Server

    ClientReset\1036\Win2K3e\i386\txtsetup.sif

    Windows 2003 Standard Server Volume License

    ClientReset\1036\Win2K3sV\i386\txtsetup.sif

    Windows 2003 Standard Server

    ClientReset\1036\Win2K3s\i386\txtsetup.sif

  1. Locate the [Strings] section in the txtsetup.sif file.

  2. Find the key entry ViewChannelsSCF.

  3. Replace the single character in the value entry as specified below:

Before:

[Strings]

 

ViewChannelsSCF = Cha?nes.scf

Note: ? is hexadecimal 0x3F.

After:

[Strings]

 

ViewChannelsSCF = Cha?nes.scf

Note: ? is hexadecimal 0x8C.

Client Reset

  • If a Client Reset Template contains a Reset Partition, after the image is installed and the workstation is rebooted, the workstation will be reset a second time. (This occurs because the new Reset Partition becomes the active boot partition.) At this point, the workstation will be ready and the disk will be imaged correctly.

  • On NT Server, Windows 2000 Server or Windows 2000 Advanced Server, if you select the option to resize to the maximum space available (rather than to a specific size), the partition size will not be expanded beyond 2GB.

  • When the Reset Workstation application ( Start | Programs | OnDemand | WinINSTALL | Reset Workstation ) is used to reset a Windows 98 workstation, the user may experience an error such as the following:

Error #8325

Error: No partition found with volume label WinINSTALL
Press any key...

The workaround is to hit any key, which causes the Client Reset to continue on as usual.

  • When adding service packs to a Client Reset Template, service pack filenames must meet MS-DOS 8.3 naming standard. According to Microsoft, CmdLines.txt supports only MS-DOS 8.3 filenames. ( CmdLines.txt executes the service pack during OS install.)

Replication

  • In the WinINSTALL Desktop Availability Suite, you can replicate Backup and Policy Personality repositories but not Migration repositories (this is by design).

  • You can replicate Packages, Patches, and Personalities (WinINSTALL Desktop Availability Suite only) to/from any WinINSTALL Share, whether or not a WinINSTALL agent is installed on the same machine as the share. Client Reset Templates may be replicated only to a machine which has installed both a WinINSTALL Share and a WinINSTALL server agent.

Personality Transfer (Desktop Availability Suite only)

The Personality Transfer feature can extract user data and settings from any of the following platforms: Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, and Windows 2003. Regardless of the platform from which the data was extracted, that extracted data can then be injected into any of these platforms--except Windows 95 and Windows 98. Injection is not supported on Windows 95 and Windows 98. Therefore, you cannot migrate TO Windows 95 or Windows 98, nor can you restore data or distribute Personality Transfer policies to either of these platforms.

Personality Repository Security

When you extract data and settings from a machine, whether for the purpose of backup, migration, or policy distribution, WinINSTALL can encrypt the extracted data before storing it in its repository on the server. To enable encryption, you simply specify an enterprise-wide encryption key on the Personality Transfer Options page.

It is extremely important to note that this enterprise-wide key is used for all extraction and injection operations throughout your WinINSTALL installation. Therefore, if you change this key, any existing repositories will become inaccessible for injection.

For example, if the encryption key is not specified prior to the first extraction, WinINSTALL does not encrypt the data. If you later specify a non-blank encryption key, data from all pervious extractions (those created prior to the specification of an encryption key) will be inaccessible because WinINSTALL will attempt to use the specified key to inject unencrypted data.

Similarly, if you specify a key and later change it, you will render all previously extracted data inaccessible for the same reason: WinINSTALL will attempt to use the new key to inject data that was extracted with the old key.

Personality Transfer Character Limitations

Personality Transfer jobs will fail if any of the HTML reserved characters, > < & ` " (less than, greater than, ampersand, single quote, double quote), appear in any of the following places:

  • Personality Transfer Template name

  • Personality Transfer Task name

  • Personality Repository Encryption key

  • WinINSTALL share path

This limitation will be addressed in a later release.

User Account Handling During Migration

The WinINSTALL Desktop Availability Suite affords some flexibility in handling user accounts during Migration (this flexibility is not needed in the cases of backup/restore or policy distribution). The default behavior of Migration is to migrate all users on a machine to the new machine. This may not be the desired behavior for several reasons:

  • You may not want to carry over all users from the old machine. For example, the new machine may already have an administrative account with settings appropriate to the new machine.

  • You may want to move users to a new domain as part of the migration.

  • You may want to implement some form of mapping of users from unmanaged machines (e.g. Win9x) to managed machines.

If need be, you can create an XML file in the Migration\Templates folder in the WinINSTALL share: UserMap.xml. This XML file can contain one or more rules used to map the extracted users to the injected users (or to drop users from the injection). Note that this file must be Migration\Templates\UserMap.xml in the WinINSTALL share.

Additional details, including syntax for the rules and the full format of the file, are contained in the Personality Transfer chapter of the WinINSTALL Administrator Guide .

Policy Distribution

You can specify a target user or users for a policy distribution injection, but this specification is handled differently from injections for other Personality Transfer operations (i.e., restores and migrations).

In the case of restores or migrations, if you specify a target user who has never logged onto the target machine, WinINSTALL will create the user profile on the target machine as part of the injection process. But WinINSTALL will not do so for policy distribution operations. In a policy distribution operation, if you specify a target user, that user must have previously logged onto the machine or no injection will occur on that machine.

The reason for this difference in behavior is that a policy distribution operation, unlike restore and migration operations, is typically carried out on multiple target machines. A single user is not likely to need profiles on all the target machines, so in this situation, WinINSTALL will perform the injection only on those machines where the specified user already has a profile present (i.e., has already logged in at least once before).

Migration Can fail when attempting to migrate to Windows XP

Under certain circumstances, migration jobs can fail with error code 7. This problem occurs only when a machine was originally created outside a domain and later promoted into the domain. Furthermore, it only occurs on machines where XP was instructed to keep profiles private during setup, so that when the machine is added to the domain, it deletes part of the original Administrator profile. Ordinarily, the operating system will re-create the profile the next time the local Administrator account logs on. But if no one logs on to the local Administrator account before the migration, the profile is not fully present and the migration engine is unable to load the profile during the extraction. Although it doesn't report an extraction error, the resulting extraction will cause the injection to fail.

Workarounds include any of the following:

  1. Logon as the local Administrator at least once after the machine is added to the domain.

  2. Delete the local Administrator profile (not account) from the machine.

  3. Exclude the local Administrator from the extraction.

  4. Exclude the local Administrator from the injection.

Personality Transfer Restore jobs may not follow file overwrite setting specified when creating the job.  

Under certain circumstances, files are restored regardless of this setting, overwriting newer files in some cases.  The reason for this behavior is that the "replace only if newer" (or "...never") options are part of the file rules.  Content-related files, like .doc, are not backed-up or restored using the file rules, so the replacement rules don't apply.  

File backups specified using the file rules, work as expected.  Therefore, to avoid undesired overwriting of files, you can manually create File Rules for the files you want to protect, instead of using the Content interface.

Windows Vista™

Some preliminary testing has been done with WinINSTALL on Windows Vista, specifically on the most recent February 2006 Community Technology Preview (CTP) release. One defect was addressed that resulted in a crash in the Master Agent if the Share Proximity "Traffic analysis" option was used. There are, however, some other issues that have been observed relative to Vista that may or may not result in changes to WinINSTALL in future releases:

  • 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.

  • After agents are deployed to a Vista machine, you may see one or two warnings in the event log from the Configuration agent - COM error 0x80004023 (CO_E_MSI_ERROR). The Master Agent should be stopped, and the following DLLs re-registered with regsvr32.exe at the command prompt: WIPingUtils.dll and WISENSEvents.dll (both in the C:\Program Files\OnDemand\WinINSTALL\Bin folder). Restart the Master Agent and the warnings should go away.

  • In previous builds of Vista (e.g. the December 2005 CTP release), the new Windows Defender feature may pop-up when agent deployment installs the Master Agent service. This did not occur on the February 2006 CTP release in our testing.

As Vista progresses towards 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.