Windows 10 In-Place Upgrade machine have duplicate entries console in console

We are currently upgrading Windows 10 machine using, Autopilot, BigFix and Windows update.
We are updating to version 2004 from 1803,1809,1903 and 1909.
For some reason the client ID is getting reset on some machine. Not all and it is not dependent on the method of upgrade.
The BigFix client version is 9.5.16.
Has anybody else come across as similar issue when the client is reset for some reason.
It must be removing the;
“HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BigFix\EnterpriseClient\GlobalOptions” registry keys and specifically the values:

RegCount
ComputerId
ReportSequenceNumber

entries for some reason.
As I say it is complete random.
Looking in the logs there is no evidence of the client reset. The log simply show that it carried on reporting.
The only evidence is the existence of duplicate entries;
One with the old OS version, which stops reporting
Second one with the new OS and a recent report time.

Regards

Matt Gilder

1 Like

@matt10b25, what error messages (if any) do you see in the applicable BES OSD logs?

HI CMCannday
We are not using OSD to do this.

We are simply sending the ISO via Bigfix and then kicking of the Install. We also upgrading machine via Autopilot and WUFB.

Matt

If you’re not leveraging OSD for your Win10 in-place upgrades, then you’ll need to open a support case with Microsoft. Alternatively, if you are entitled to Lifecycle, the OSD module is very compelling.

Depending on which feature updates you’re moving from/to, we’ve found that some machines reregister themselves during the process. We’ve been prefetching the ISO, then running setup.exe with select parameters.

What would OSD add to this process?

From the OS Deployment User’s Guide, it provides a consolidated, comprehensive solution to quickly deploy new workstations and servers throughout a network from a single, centralized location. This solution saves time and money, enforces a standardized and approved image, and reduces risks associated with non-compliant or insecure configurations.

Please note that I do not have any experience with the process that you defined in your prior post, so I can’t provide you with a compare/contrast. However, we might be able to get @bradsexton81 to provide feedback regarding this topic.

As an experiment, you might try setting _BESClient_Resource_StartupSleepSeconds to 300 seconds.

setting "_BESClient_Resource_StartupSleepSeconds"="300" on "{now}" for client

There’s a description in the thread below. What I would speculate could be happening is that during the Windows Setup phase, while the system is still in the “temporary” Windows installation and finalizing Setup, the BES Client service could start up and send a report. Then when Setup replaces the permanent registry with the upgraded registry, that could roll back a client report sequence number and force the client to reset itself. It’s been a few years since I’ve seen that as a problem, but it might be worth a try.

edit: smart quotes

1 Like

the builtin fixlets part of lifecycle offer some very compelling cases.

  1. Use the same Microsoft ISO files you uploaded to the image library in BigFix.
  2. Break out the in-place upgrade into two steps such as check for issues ahead of time such as app or driver conflict while store the media needed for the upgrade waiting for the next step. This will allow you to be more transparent with the user on when the upgrade will begin because you are now not waiting on a download and you know the upgrade will be successful with the checks - https://www.linkedin.com/pulse/windows-in-place-upgrades-brad-sexton/
  3. Run actions after the upgrade such as upgrade software or settings - https://www.linkedin.com/pulse/bigfix-add-custom-actions-after-in-place-upgrades-brad-sexton/?trackingId=PwUMIjgITUW513wWTLj5jg%3D%3D
1 Like

Thank you all for your advice,