WinINSTALL SDS 9.0 Hotfix 3



Base WinINSTALL Version:          9.00.0000, 9.00.0001 or 9.00.0002 (English)

Hotfix WinINSTALL Version:         9.00.0003 (English)


Product affected by this hotfix:



Product version information:


            WinINSTALL hotfixes are cumulative, and include all fixes for issues corrected in all previous hotfixes.  However, depending on which files are updated in this hotfix or in previous hotfixes, certain areas of the product will report a product version corresponding to the previous hotfixes or the base product release.  Following correct application of this hotfix, the following versions should be observed in Add/Remove Programs (ARP) or in Help / About:



ARP Version

About/Agent Version








Files included in this hotfix:



Old Version(s)

New Version





Hotfix description and installation instructions (this file)




Hotfix installation trigger file




Upgrade checker utility (see below)




Upgrade checker help




Updated agent MSI file




Updated console MSI file


Updated Discover program

Dated 2/7/2007

Dated 8/20/2007

Updated MSI/MSM template cabinet file


Updated console module for the machine list


Updated console module for packaging


Updated console module for patch management


Updated console resource file


Updated agent module providing utility functions


Updated agent module for handling scheduling


Updated agent module for handling patch management


Updated agent module for software distribution


Updated agent module for publishing configuration


Updated agent module for replication


Updated agent module for replication resources


Updated configuration/transaction file module


Updated client communications module


Issues addressed in this hotfix:


Issue: DTR 297096 (18205) – Incorrect agent version is reported after upgrading.


Description: When initially deploying agents from an upgraded WinINSTALL share, the agent version reported in the console will show as the base or previous upgrade version, and not the version actually installed.


Resolution: The pre-configuration default for the UPDATE_ONSTART value was changed to force an upgrade check at startup to get the correct version registered.


Issue: DTR 297125 (18256) – Some distribution jobs remain in the running state indefinitely.


Description: In some cases, despite the fact that distribution jobs have completed, the console will show the jobs perpetually in the “Running” state.


Resolution: Additional information, such as the time the job ran, is now used to clarify the order of the status information in cases where there are multiple instances of a job execution.


Issue: DTR 297175 (18313) – Transforms created by Discover report error during installation.


Description: Transforms created by Discover cause MSI installations to fail with error code 1624.


Resolution: A number of problems were found and corrected when creating the “After” MSI file used to generate the transform, including incorrect paths used, and File/Media table consistency issues.


Issue: DTR 297161 (18302) – Discover is unable to produce MSI transforms correctly from an MSI package.


Description: Discover does not correctly produce an MSI transform (MST file) when asked to do so via the Advanced wizard selection.


Resolution: Several changes were made to Discover to correct transform generation issues, including a new file with schema information for MSI 1.0 (pre-release for some Office releases), and changes to use the correct logic for determining whether or not to generate a transform.


Issue: DTR 300155 – Agents fail to upgrade if the deployment share is unavailable.


Description: If the original share used to deploy agents is retired or is otherwise unavailable to the machines when upgrading, the upgrade will appear to succeed but the agents won’t actually be upgraded.


Resolution: The upgrade process now changes the agent package source to point to the current share when upgrading.


Issue: DTR 300161 – Agent upgrade process needs to be more resilient.


Description: Frequently, agent upgrades will fail to install, but will appear to have been installed correctly according to the agent version reported in the console.


Resolution: The upgrade process is now more intelligent about detecting upgrade problems and retrying the upgrade process if necessary.


Issue: DTR 300503 – If download of alt scan source fails, user is not prompted to download again.


Description: When creating a scan and the user chooses to use the alternate scan source, we check if the alternate scan source package is already on the share, and if it is not on the share we prompt for download. This download can fail in the middle of the download and the resulting alternate source file is in a bad state and we don’t delete this bad file but then attempt to use it.


Resolution: If the download fails, we now delete the bad alternate source file and the checkbox to use the alternate scan source is deselected. If the use reselects the checkbox, another attempt to download the alternate scan source will occur.  If it fails again, there may be a connection problem to diagnose.


Issue: DTR 300576 – Transform created by Discover can't find needed files.


Description: Transforms created for certain MSI files can contain references to source file paths that conflict with file paths in the original MSI files, resulting in the install failing when the referenced files cannot be found.


Resolution: Some issues were corrected with conflicting file locations (folders).  In cases where the “Before” and “After” MSI files have collisions in file locations, the files will be relocated according to the “Before” MSI file’s Directory table.


Issue: DTR 300650 – Change replication default to unicast.


Description: Most replication jobs with a transport type of "automatic" will default to use multicast as the transport.  This can cause problems in environments that haven’t yet enabled multicast, and can be less reliable, resulting in more failures.


Resolution: Replication has been changed to default “automatic” to use unicast instead of multicast, which is more reliable and less prone to configuration issues.


Issue: DTR 300671 – Replication agent can cause clients to timeout and disconnect from the server, resulting in failed replications.


Description: When replicating to very large numbers of clients, if one or more client machines become disconnected during the job, it can cause other clients to disconnect as well.


Resolution: Replication has been corrected to prevent other clients from becoming disconnected.


Issue: DTR 300676 – Two-phase distribution jobs retry indefinitely even after a job has been deleted.


Description: With poorly-connected two-phase distribution jobs, if a problem occurs on the server prior to completion of the Replication phase, or there is a problem with the server reaching the workstation during Replication (e.g. the workstation has a firewall up), the job will fail on the server, but will retry continuously every five minutes on the workstation side, even if the job is deleted in the console.


Resolution: The Scheduler was changed to retry job initiation a maximum of five (5) times before terminating the job.  Note that once the job has been initiated successfully, it will continue to retry as needed until the job completes.


Issue: DTR 300742 – Distribution jobs sometimes fail with error code 997 (ERROR_IO_PENDING).


Description: If a distribution job runs, and another job is already active, the new job can fail with error code 997 (“Overlapped I/O operation is in progress”).


Resolution: Distribution was changed to correctly queue multiple requests when jobs are already active.


Issue: DTR 300748 – Scheduled jobs to specific machines do not run.


Description: Jobs that are scheduled to specific machines (vs. all servers/workstations) will not run.  When verbose logging is enabled, the following message will be issued: “Job <name> (<ID>) was not targeted for this machine's role and will be removed.”


Resolution: The console was changed to put the correct machine role in all scheduled jobs.


Issue: DTR 301649 – Cannot create a patch package from a vulnerability.


Description: When downloading an update to create a patch package, the package creation does not finish properly.  It appears to download the update, but then fails to create the package.


Resolution: The Patch Management UI was corrected to properly reflect the status of the download.


Issues addressed in previous hotfixes:


Issue: DTR 297087 (18190) – Failed to update Windows Update Agent errors due to download failures.


Description: Under certain circumstances (due to timing issues) the download of the Windows Update Agent update executables fails on server agents. As a result, agents report "Failed to update Windows Update Agent," and some agents may then fail to perform scans and remediations.


Resolution: The server agent has been modified to prevent two threads from conflicting with each other.


Issue: DTR 297091 (18194) – Existing Schedules disappear after upgrade to 9.0.


Description: After updating the WinINSTALL database to 9.0 from a prior version, scheduled jobs no longer show up in the console.


Resolution: The console has been modified to correctly display pre-existing and new jobs.


Issue: DTR 297017 (18109) – Patch Management Create Package and Add Package to List functions prompt for each vulnerability.


Description: Selecting multiple remediations to download and create packages and/or add packages to list requires the user to click ‘Yes’ to enable the download of each selected remediation.


Resolution: A ‘Yes to All’ option has been added to the dialog.


Issue: DTR 297119 (18247) – Patch Management replication of Alternate Scan Source fails due to share ownership duplication.


Description: In some pathological cases, a WinINSTALL share may appear to be owned by more than one server.  This may cause the wrong server to be used as the server for replication of the Alternate Scan Source.


Resolution: An internal check is now made to ensure that the correct owner is used in these cases.


Issue: DTR 297118 (18246) – Patch Management Alternate Scan Source incorrectly deleted on replication failure.


Description: The WSUSSCN32.CAB and MSOLRSRC.NAI files are deleted after downloading the alternate scan source if the replication job to copy these files to other servers fails or is put into the pending queue, rendering them unavailable to all servers.


Resolution: The Alternate Scan Source files are no longer deleted on a replication failure, and additional logging has been added in this area.


Issue: DTR 295723 (16579) – Recurring scheduled jobs incorrectly excluded from processing.


Description: In some cases, if a recurring scheduled job (e.g. daily, no end date) is in the queue, and another non-recurring job completes, the recurring job may be inadvertently excluded from future processing.


Resolution: The Scheduler agent now correctly handles this case, and recurring jobs will not be incorrectly treated as if they had completed all processing.


Issue: DTR 297123 (18253) – Some jobs stay in the “Running” state forever, even when completed.


Description: Some Two-Phase Distribution, Patch Management or Personality Transfer jobs show as “Running” in the console forever, even when the jobs have completed (failure or success).


Resolution: Transaction file processing now correctly serializes access to a counter used to generate XML file names that was causing the same file to be used for two different requests in some cases, causing some status updates to be lost.


Issue: DTR 291071 (18209) – Global Patch Management scan job support.


Description: Unlike most other types of scheduled jobs, Patch Management jobs couldn’t be scheduled to “All workstations”, “All servers” or “All workstations and servers”, but could only be scheduled to specific lists of workstations or servers, so new workstations wouldn’t automatically pick-up scan jobs when added to the network.


Resolution: The Patch Management user interface has been changed to allow Patch Management jobs to be scheduled to the same types of targets as are allowed for other scheduled jobs.


Install instructions for this hotfix:


  1. The hotfix executable will automatically save copies of all files in a folder on the share named “9000003.BAK”.  The files within are all renamed to include a random extension so they don’t conflict with existing files.
  2. Execute the hotfix executable (SDS_9.00.0003.exe).  You will be prompted to locate the share to be updated, and the hotfix will be applied to the share.
  3. Start the console, which will then automatically upgrade.
  4. From the console, re-start any agents, which will then automatically upgrade the agents:
    1. Select the machine or machines to be upgraded in the machine list.
    2. Right click / Agent Maintenance / Stop Agent / OK.
    3. Right click / Agent Maintenance / Start Agent / OK.
    4. Upon startup, the agents should update.
  5. Verify that SNAPMACH.dll (on console machines) and WIMAUtl.dll (on all machines with WinINSTALL agents installed) has been updated in the local \Program Files\OnDemand\WinINSTALL\Bin folder.
  6. Alternatively, see below for information on WIUpgradeCheck.exe, which can also be used to verify (and correct) proper upgrade application.


Note:    The default for all agents is to check for upgrades on startup.  Please confirm that this option has been set in Agent Settings… / Advanced / Check for upgrade at startup, and set if necessary.


Upgrade checker utility (WIUpgradeCheck.exe):


            This hotfix corrects some common problems encountered during the upgrade process that may prevent all machines from upgrading properly, either when applying this hotfix or earlier hotfixes.  We’ve included a utility in this hotfix, WIUpgradeCheck.exe, which can be run from the WinINSTALL share to check on the upgrade status of your machines without having to do an inventory on each machine.  WIUpgradeCheck.exe also allows an upgrade check to be forced on machines which may not have properly upgraded.  Please see the built-in help (WIUpgradeCheck.chm) for details on the operation of WIUpgradeCheck.exe.  Please note, however, that WIUpgradeCheck.exe has some caveats to consider that may limit its usefulness for some customers.  See the “Requirements and Operation” help topic, but here is one excerpt to consider:


            “Depending on the number of machines in your network, and particularly the number of machines that are unavailable in some way (turned off, firewalled, etc.), WIUpgradeCheck can take a long time to refresh the status on your machines.  To get the status on 1000 machines, for instance, it could take up to five minutes to refresh the entire list if a large proportion of those machines are unavailable.  This is due primarily to how Windows works, in that it has a default 30-second timeout when trying to reach unavailable machines.  WIUpgradeCheck will attempt to contact up to 40 machines in parallel, so hopefully you won't see much effect from unavailable machines.”