M100873: Repacking packages containing settings for Windows Server 2003 may cause reinstalls

Symptoms

A managed device may re-install a package that has already been installed if:

1. The managed device is running ManageSoft for managed devices 7.9 SP1 or earlier
2. The device previously installed a version of the package that was packed using an administration server running a release earlier than Deployment Manager 7.9
3. The package contains settings for the Microsoft Windows Server 2003 environment
4. Deployment Manager 7.9 or 7.95 is used to repack and distribute the same package again.

Installation agent logging (typically in <Temporary Directory> \ManageSoft\installation.log) will show details similar to the following in this scenario, indicating that the package version has not changed but that the package MD5 checksum has changed:

Installing "My Package[Common](1,0,0,0)" Compare version 1,0,0,0 (My Package) to 1,0,0,0 (My Package) 

Versions are the SAME

 Compare MD5 checksum 281bca41ca662ea6b73b0a4f7756942b (My Package) against 496804c785bd019c9252b1cecf4ce718 (My Package) 

MD5 checksums are DIFFERENT

 User selected to install the package 

The package "My Package" will be upgraded

Cause

This behavior is the result of a change introduced in the Deployment Manager 7.9 release in the details of how the Microsoft Windows Server 2003 package environment is specified. These changes were implemented so the installation agent is able to distinguish between the Windows Server 2003 platform and the Windows XP 64-bit platform which was supported for the first time in the 7.9 release.

Repacking any package using Deployment Manager 7.9 or 7.95 that includes the Microsoft Windows Server 2003 environment will result in a different package catalog (.ndc) file being generated from what was generated by earlier releases. The changed catalog reflects the changed environment details. The different catalog subsequently triggers the package to be re-installed on devices running ManageSoft for managed devices 7.9 SP1 or earlier.

A package will be repacked automatically when the package is distributed if the distribution functionality determines that the C:\ManageSoft\Staging\Common\Packages folder does not contain an up-to-date version of the package, or if the package contains a package dependency. A repack of a package can also be forced by opening its project under the Packaging node in the administration console and selecting the Pack... option on the right-click context menu for the project.

Mitigation and Workarounds

Re-installs are not problematic for many packages for example, non-MSI external installer packages, security patch packages, or simple packages deploying files will all typically re-install with minimal side effects. However re-installs of other packages can cause significant problems a common scenario to watch out for is re-installs causing user configuration and settings to be reset to default values. In this case, some mitigation or workaround for this problem may be required.

Unfortunately there are no straightforward workarounds to this problem that don't have some drawbacks. The following sections describe some options that are available.

Restore packages that were packed with Deployment Manager&ampnbsppre-7.9

In order to immediately respond to a situation where reinstalls are occurring on production devices, it may be useful to consider manually restoring packages on distribution servers to the same state that they were prior to their repack and distribution using Deployment Manager&ampnbsp7.9 or 7.95. In an emergency situation, the quickest way to do this (if possible) is&ampnbsplikely to be to manually copy versions of the packages from a distribution server that has not been updated. Packages downloaded by managed devices are stored by default in the C:\ManageSoft\LocalDeployment\Packages folder on distribution servers that have a &quotnon-linked&quot distribution location, or in C:\ManageSoft\Staging\Common\Packages if the distribution location is &quotlinked&quot to the staging area.

You may also want to consider disabling the ManageSoftDL HTTP share and ManageSoftDL$ file share on affected servers to avoid further downloads of the affected packages until the si