BigFix 9.5 Patch 12 is now available

The BigFix team is pleased to announce the release of version 9.5 Patch 12 (9.5.12.68) of the BigFix Platform.

The main features in this release are as follows:

  • Security enhancements
  • APAR fixes

This release includes all Platform components.

Please read further details in the 9.5.12 Release Notes document at: 9.5.12 Release Notes

Get more information by reading the full technical changelist.

Useful Links:
BigFix download and release information
Upgrade Fixlets are available in BES Support version 1410 (or later).

9 Likes

Issue BFP-12248 - APAR IJ13194 - HE ACTION TO UPGRADE WINDOWS 10 VERSION MAY FAIL AFTER THE REBOOT

What was the root cause for the Windows 10 upgrade issue?

Are there any other client changes?

The issue with Win 10 upgrade was related to a second reboot triggered by BESClient, after the first restart following the Post-Action condition.

Once the Win 10 setup completes the upgrade and the machine is restarted the first time by the Post-Action restart triggered by BESClient, the OS still has to run some finalization steps to successfully complete the upgrade.
However, while the OS is finalizing the upgrade, BESClient finds registry settings in PendingRenameFileOperations in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] and evaluates them as condition for launching a new reboot.
Unfortunately, the second reboot occurs too early, while the OS is still working to finish the post restart steps,
and it causes the OS rollback to the previous version and the related BigFix action failure.

BESClient 9.5.12.68 addresses the above issue.

The original issue that led to APAR IJ13194 and its resolution is discussed also here: Bigfix Restart Causing Windows 10 1803 Upgrade to Fail.

I’d really like some more detail on how the PendingFileRenameOperations check is altered and whether that is/could be applied to other situations. I.E. is the client making a new check against HKLM\System\Setup for “SetupType” or “SystemSetupInProgess” or something else?

1 Like

Actually, the fix doesn’t change the way BESClient checks the PendingFileRenameOperations settings.
It, instead, modifies the internal logic BESClient uses to detect if the restart has been triggered by an action and to clear the related keys.

In details, when an action creates a pending restart situation, the Windows BESClient creates a global Atom, and the global Atom persists until a machine restart: it allows BESClient to detect if the machine has been restarted since the Atom was created.

Before implementing the fix for APAR IJ13194, BESClient was checking for the global Atom unless the PendingFileRenameOperations test showed no remaining items.
For this reason, it did not clear the existing restart flags in actions.
With the fix, BESClient examines the global Atom even when the PendingFileRenameOperations are present, and used the Atom information to clear the existing restart flags in actions (and preventing any further unexpected reboot).

2 Likes

Thanks for clarifying…and wow, that sounds big. There are lot of other queries in the forum about ‘pending restart’ action statuses not getting cleared, that often trace back to PendingFileRenameOperations getting updated by misbehaving software, and the need to blacklist particular keys. Sounds like this change could help in those situations?

Well, the fix address the scenario where the post action restart setting initiates unwanted reboot, but it doesn’t change the behavior regarding the existence of PendingFileRenameOperations: if items still exist under PendingFileRenameOperations, BESClient won’t restart the machine additional times but the state stays in ‘Pending Restart’ until the items are deleted by the OS/software.

Thanks for the clarification.

This topic was automatically closed after 30 days. New replies are no longer allowed.