Reimage Windows 10 Over the Internet

[jriv]

I have a need to reimage over some PCs while they are at home with their respective users. There are mixed versions of Windows 10 and it would be ideal (but not required) to upgrade them all to the same (latest) version. I followed the guide here https://help.hcltechsw.com/bigfix/9.2/lifecycle/Lifecycle_Man/OSD_Users_Guide/c_imaging_windows.html but only had limited success - I was able to erase and reinstall a VM on the same network as our servers. I spun up a new VM that’s outside of the network but the reimage baseline I created isn’t showing as applicable to this new VM.

Anyone have a better guide or troubleshooting steps that I can follow? Or any hints as to making sure the baseline is applicable to all devices?

Thanks!

[michele.t]

Hi,
you should check in the last VM what are the relevances that are not applicable to it. You can exploit fixlet debugger utility (if I remember correctly) to manually run the relevances’ evaluation on it.

I hope this helps,
regards

[jriv]

Thanks, @michele.t.

All the actions in the baseline have the same relevance and they all came back “True” using the fixlet debugger.
(NOT exists key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\ImageInfo" whose (exists value "MDTCompleted" of it) of x32 registry)

Any idea on why some devices have "ImageInfo" in the registry and some don’t?

[michele.t]

Hi @jriv,
do you mean that relevance issue in reimage is solved?
About relevance against “MDTCompleted” value in registry, I am not sure if it refers to a value that bigfix client writes in the registry at the end of the reimage process. Sorry, but I can not check in the code to give you this answer.

I hope this helps,
regards

[sergio_tarchi]

Hello. The ones that already have the key ImageInfo have probably already run a reimage task.
Is it possible that the one that are not applicable for the reimage baseline have a newer version of OS than the image to be installed? Thanks.

[jriv]

Hi @michele.t and @sergio_tarchi

I figured out why the baseline was not applicable even though the relevance checked out. It was a rookie mistake on my part. It turns out, I placed the baseline in a site where some of my devices were not subscribed. After subscribing them to the site, they became applicable.

I was able to remotely reimage a test machine. However, came across a different issue. Once the OS is installed and booted, it fails to get the next action because it’s not joined to wifi. I expected this. However, once joined to wifi, it still is unable to move on to the next step. I’m seeing an error "Failed to register to the Authenticating Relay with provided password." Looking at the registry, I still see _BESClient_SecureRegistration key and there is an obfuscated string. After manually replacing it with the password in clear text, the BES client successfully starts up.

The password is definitely not something we can provide to the end user. Also, while apps, users and other data were erased (expected), the BES Client directory in C:\Program Files (x86)\BigFix Enterprise was preserved - I see logs from the past week. It would actually be preferable if the BES Client can be reinstalled during this process. I want to clear all existing computer settings from these devices and I think I can use the reinstall to set the secure registration password. Do you or anyone else know how this can be done with the reimage baseline?

[michele.t]

Hi Jriv,
reimage process, by design, preserves BES client identity. This is a goal of the reimage process. You will have at the end a new OS, but with the same bigfix client. If you want to have a new fresh installation with a new client ID, you should exploit bare metal deployment, but in your scenario (computers at home), I don’t see it as feasible. Network configuration can be a show stopper.

Regards

[sergio_tarchi]

Hello Jriv,
your scenario is not clear to me but if I correctly understand and you want the client to run an action that auto-reset itself, the only possibility that I see is to send an action that writes and runs a script that does the job, this because, once stopped, the client will not be able anymore to receive commands but the script (a batch or vbs for example) can continue its execution up to completion. By the way this is unrelated to the OS deployment that must be completed with the same client identity that started it, and preserved during the installation, or the action will not be marked as complete.
Thanks.

[jriv]

Hi @sergio_tarchi,

Sounds like I should do a capture of the OS (I’ve been deploying the Windows installer ISO) after I’ve reset the client. I’ve done something similar when creating an image for systems in AWS Workspaces: BigFix Client in AWS Workspace Image. Thanks for the idea!

I’m testing the capture image process and running into an issue where it completes the actions, but there is no .wim file generated. I assume it would be saved in the smb share that I specified in the capture image wizard? During the capture, I see a bunch of directories get created in C:\Deploy. Once the action group completes, all (except for Tools directory) disappear). Was I just being impatient?

[sergio_tarchi]

Hi Jriv.
Exactly with the same mechanism, the capture action is marked as completed when the LiteTouch part is launched because the bigfix client loses its identity when the computer is un-configured (because it’s Windows itself to be “generalized” with sysprep). By the way the capture continues its job to create the wim file but, if some failure occurs, it cannot be reported back to the console by the client.
When the failure occurs in the preparation in the OS (before restarting to WinPE for the actual image creation), you can find the logs in the folder C:\Windows\Temp\DeploymentLogs. You can read at BDD.log as starting point. If you are capturing Windows 10, please check the section “Capture of a Windows 10 image might fail” at this link for possible causes and solutions -> https://help.hcltechsw.com/bigfix/10.0/lifecycle/Lifecycle/OSD_Users_Guide/c_capture_images.html
Thanks.

[jriv]

According to HCL support, I’ve hit a bug that is preventing the client from registering to an Authenticating Relay after a remote OS reinstall. They have provided me with a new version of the Image Library wizard that contains the fix for testing and the issue seems to be resolved. According to support, a new version of OSD site will come out soon with the fix.