Third-Party Downgrades of FlexNet Inventory Agent on Microsoft Windows Leave the Agent Non-Functiona...

Report Inappropriate Content · ‎Nov 08, 2018

Summary

Special attention is required for downgrades of FlexNet inventory agent driven by third-party tools like Microsoft SCCM.

Synopsis

On Microsoft Windows devices, using a third-party tool such as Microsoft SCCM or Altiris to trigger a downgrade of FlexNet inventory agent damages the installation, leaving the FlexNet inventory agent non-functional so that the inventory device is orphaned. This is in the list of Known Issues for FlexNet Manager Suite 2018 R2 under master issue number IOJ-1809619. Special arrangements discussed below can prevent this issue.

Exceptions: This issue does not affect the following scenarios:

Using the ?self-upgrade? mechanism within FlexNet Manager Suite, and authorizing an earlier version of FlexNet inventory agent, triggers downgrades of installed, later versions of the agent to match the new policy. These internally-driven downgrades are not subject to the behavior described here, and downgrade successfully.
UNIX-like platforms are unaffected by this issue. Both upgrades and downgrades work as expected on these platforms.
Very early editions of FlexNet inventory agent running on legacy Windows platforms are not affected by this scenario, since they refuse the upgrade request (modern upgrade methods cannot run on these legacy Windows platforms). This applies to any releases earlier than:
- Windows 2000 SP4
- Windows XP Gold
- Windows Server 2003 Gold.

Discussion

This issue is typically a result of having multiple processes attempting to control installations of FlexNet inventory agent. For example, consider this scenario:

You have configured Microsoft SCCM to install (say) version 12 of FlexNet inventory agent.
A changed policy distributed through FlexNet Manager Suite authorizes upgrades to version 13, and various installations of FlexNet inventory agent automatically self-upgrade as a result.
Microsoft SCCM revisits un upgraded device, finds that it is no longer running version 12, and attempts an ?upgrade? (in reality, a downgrade) to match its specification for version 12. Notice that no change is required in SCCM settings to cause this issue. This downgrade fails, leaving the installation of FlexNet inventory agent corrupted and inoperative.

The issue is caused when the default settings for Microsoft SCCM allow the attempted ?upgrade?, but when certain files are recognized as more recent than the currently specified version, they are not replaced, even though they have already been removed in the upgrade process.

Note: You may need to check the functionality of the deployment package for FlexNet inventory agent with the person who created the package. Some implementations may use additional scripts that control re-installation (such as .vbs scripts with SCCM). You can also check the installation.log file for evidence of unpacking cabinet files and copying the resulting files across directories. The msiexec installation log (visible in Event Viewer) also shows when the installer has been executing in the installation directory for FlexNet inventory agent.

Downgrade of the agent by FlexNet Manager Suite is not affected, because this method uses a stronger command line with options that force a complete replacement regardless of versions (see below).

Workaround

For recovery, see the next section.

To avoid damaging existing installations of FlexNet inventory agent, you may use any of the following alternatives:

Allow the upgrade: If the policy for FlexNet Manager Suite is set to authorize upgrades to a specific version (such as 13.1.1), you may modify the settings for your third-party tool (such as SCCM) to deploy the same version of FlexNet inventory agent. If both channels for managing upgrades are specifying the same target version, there is no conflict and no attempted downgrade.
Reverse the upgrade policy: Where there is sufficient time between the FlexNet Manager Suite policy change and scheduled upgrades using your third-party tool (or you can defer operation of that tool), you may revert your FlexNet policy settings to specify the earlier version of FlexNet inventory agent, matching settings in your third-party tool. (Customers using cloud implementations at this time must request that the downgrade is specified for them, since this currently involves database manipulation.) Specifying the earlier version in FlexNet Manager Suite before the third-party tool attempts the downgrade triggers a successful downgrade, after which you can resume operation of your third-party tool, since there is no longer any contention.

Additional Information

This section discusses recovery methods. See the previous section for avoiding the issue in the first place.

Where the attempted downgrade has already occurred, and the installation of FlexNet inventory agent is damaged so that the inventory device is ?orphaned? (unable to communicate with the central application server for FlexNet Manager Suite), the damaged installation must either be repaired, or removed and replaced. You may use approaches like the following:

Repair: This is the recommended approach. Use your third-party tool (such as SCCM) to repair the installation to your preferred version. You may use the absence of the ndtrack.exe file in the broken installation as a detection rule to initiate the repair. With SCCM, you can use command lines like either of the following alternatives to trigger a repair:
```
msiexec /f "FlexNet Inventory Agent.msi" /L*V "test.log" 
msiexec /i "FlexNet Inventory Agent.msi" /L*V "test.log" REINSTALL=ALL
```
Your package deployment team are likely already experienced in triggering repairs.
Replace: Use your third-party tool to trigger the uninstallation (removal) of the old and damaged FlexNet inventory agent. Thereafter, use your preferred method (either your third-party tool, or ?adoption? through FlexNet Manager Suite) to install your preferred version of FlexNet inventory agent as a ?first time? installation (rather than an upgrade).
Reinstall: Modify the behavior of your third-party party tool to force a completely new installation of FlexNet inventory agent. (Do NOT use this method where FlexNet inventory agent and FlexNet Beacon are installed on the same device, which should never be the case.) For example, in the Microsoft SCCM console, you can modify the existing deployment command with
```
REINSTALLMODE = amus
```
to force replacement of the existing installed files. See the Microsoft documentation for more information on these a, m, u, and s options. This ?forced versioning? approach may be considered heavy-handed, since it escapes the versioning rules used by Windows Installer. It is acceptable for the FlexNet inventory agent package only because, by design, the FlexNet inventory agent is self-contained and does not have external dependencies (such as shared resources or custom actions).
Manual action: Where the number of affected devices is sufficiently small, you can log into each device and double-click the MSI file for the FlexNet inventory agent. This runs a complete replacement on that inventory device.