Windows 11 upgrade baseline failing retroactively after restart

I have a baseline that upgrades from Windows 10 > 11 with a restart component in it.

Below are my execution parameters:

  • It will run between 1:00:00 AM and 3:00:00 PM client local time, on any day of the week.
  • If the action becomes relevant after it has successfully executed, the action will not be reapplied.
  • The action’s downloads will be started before action constraints are satisfied.
  • If the action fails, it will be retried up to 1 times, waiting 1 hour between attempts.
  • The action’s downloads will be staggered over 5 minutes to reduce network load.
  • If a member action fails, the action group will abort.

My baseline has a single relevance:
(name of it = "Win10") of operating system and true

Below is an example of an action info of a computer that exhibits the issue:

Completed    - Remove CyberArk Broken Reg Key 
Failed       - Win10 to Win11 24H2 ISO Upgrade 
Completed    - Restart Computer - 8 Hours 
Not Relevant - Verify Windows 11 Upgrade 
Not Relevant - KMS Windows Activation 
Not Relevant - ImageRight 7.1.112.2375 Desktop Install 
Not Relevant - Remove Appx Bloat

The issue is that the Win10 to Win11 24H2 ISO Upgrade component is succeeding on the client machine, I have verified this by checking the BES logs of the computer. After taking the restart component, Windows will successfully upgrade but BigFix reports failure for the upgrade component and then all subsequent components become not relevant. Also of note: the restart component reports completed before the upgrade component reports failed.

Since the baseline relevance is looking for Windows 10 machines, after the restart is should start reporting as Windows 11 so could this cause the issue?

Below is a log snippet just prior to the restart component:

Summary

At 12:59:07 -0400 - actionsite (http://abcdefg/cgi-bin/bfgather.exe/actionsite)
Not paused pause while False (group:213853,action:213855)
Command succeeded parameter “LogFile” = “C:\Win11Upgrade\Panther\setuperr.log” (group:213853,action:213855)
Command succeeded (evaluated true) continue if {not exists file (parameter “LogFile”) whose (exists line whose (it as lowercase contains “abort” or it as lowercase contains “abandoning”) of it)} (group:213853,action:213855)
At 12:59:14 -0400 -
ActionLogMessage: (group:213853,action213855) ending sub action
At 12:59:14 -0400 - actionsite (http://abcdefg/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Win10 to Win11 24H2 ISO Upgrade (fixlet:213855)
At 12:59:16 -0400 -
ActionLogMessage: (action:213853) Action signature verified for Execution
ActionLogMessage: (action:213853) starting sub action
At 12:59:16 -0400 - actionsite (http://abcdefg/cgi-bin/bfgather.exe/actionsite)
Command succeeded action requires restart (group:213853,action:213856)
At 12:59:16 -0400 -
ActionLogMessage: (group:213853,action213856) ending sub action
At 12:59:16 -0400 - actionsite (http://abcdefg/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Restart Computer - 8 Hours (fixlet:213856)
At 12:59:17 -0400 -
ActionLogMessage: (group:213853,action213856) Cannot empty _Download directory
At 12:59:23 -0400 - actionsite (http://abcdefg/cgi-bin/bfgather.exe/actionsite)
Relevant - Nightly Reboot (12:30AM - 5:30AM) [DO NOT STOP] (fixlet:160014)
At 12:59:29 -0400 -
Report aborted with restart command pending
At 12:59:32 -0400 -
Report posted successfully
BigFix Restart from ActionID 213853
At 12:59:36 -0400 - BES Support (http://sync.bigfix.com/cgi-bin/bfgather/bessupport)
Relevant - Restart Needed (fixlet:177)
Relevant - Administrative Login Needed (fixlet:240)
Relevant - Restart Needed - Triggered by a BES Action (fixlet:390)
At 12:59:42 -0400 - CustomSite_NCFB_Custom_Content (http://abcdefg/cgi-bin/bfgather.exe/CustomSite_NCFB_Custom_Content)
Fixed - Idle 19 jp (fixlet:205668)
Fixed - Idle1 - jp (fixlet:205667)
At 12:59:49 -0400 -
Client shutdown (Service manager shutdown request)

And a log snippet after the restart:

Summary

At 13:05:54 -0400 - actionsite (http://abcdefg/cgi-bin/bfgather.exe/actionsite)
Not Relevant - (fixlet:213853)
Not Relevant - Verify Windows 11 Upgrade (fixlet:213857)
Not Relevant - KMS Windows Activation (fixlet:213858)
Not Relevant - Remove Appx Bloat (fixlet:213860)

Are you monitoring the upgrade process as it runs? These results seem to indicate that the upgrade was rolled back before the agent runs again. There are logs that may help diagnose the issue:

  1. C:$Windows.~BT\Sources\Panther: File named Setupact.log records actions in the downlevel and SafeOS phase. As the log can be very large, the setup also creates a file named “Setuperr.log” that only has information about the errors encountered by the Setup to narrow the source of the problem.
  2. C:$Windows.~BT\Sources\Rollback: File named Setupact.log records what happened after the update failed and Windows rolled back to Windows 10. The starting portion of the file may explain what happened and why the update failed.
  3. C:$Windows.~BT\Sources\Panther\UnattendGC: In this folder, Setupact.log records what happened during the OOBE phase. Helpful when the extended code is 4XXXX.
  4. Supplementary logs: There are certain supplementary logs that may be incident-specific. These can be found in: C:$Windows.~BT\Sources\Rollback. Examples include setupmem.dmp if the computer Blue-screened or the device install log that logs driver migrations during the upgrade.

See: Troubleshoot Windows 11 upgrade and Installation errors - Microsoft Community

1 Like

The computers are upgrading to Windows 11 successfully.

  1. The computers are reporting back to BigFix as Windows 11.
  2. I can remote into the computers to verify they are on Windows 11.
  3. My action script parses the setuperr.log file for errors already. If I check the BES log, the entire Windows upgrade action script I have has succeeded on the client.

What is the success criteria on your task that it’s failing on? It could be running successfully but perhaps something in the success criteria is making it come back as failed?

I think what you might be seeing is because your baseline is setup with relevance to look for Windows 10 but prior to the upgrade you’re upgrading it to Windows 11 as part of the task, so after the reboot the baseline re-evaluates and is no longer relevant to run any of the components because your main criteria on the baseline is no longer relevant. Maybe what I would suggest is creating a flag file (text file or something) that says ((name of it = “Win10”) of operating system or exists file “c:\windows\Windows11upgrade.dat”) and have that file get created at the beginning of the task so that the baseline is still relevance throughout the baseline running then on the last task of the baseline have the dat file removed.

I would also highly recommend editing your original post and remove the references to your server name from your log files unless those aren’t the actual server names.

1 Like

The success criteria for every component is “action script runs to completion”. If I view the action info where it reports as failed, every line of the action script comes back as Completed.

I’m assuming this is a relevance issue. What I’m going to try is removing the Windows 10 relevance from the baseline, add it to the Windows 11 Upgrade component, and have that component applicable to machines where the component is relevant. I’ll report back with results.

Made a couple changes that seem to have fixed the issue.

  • Removed the Win10 relevance from the baseline and added it to the upgrade component, made the baseline applicable to machines that meet the component relevance.
  • Made the baseline continue to run even during failure. I had to adjust other components to compensate for this.
  • Removed the restart component and added it directly into the upgrade component. I think this was the main culprit.
1 Like