u/Shadow_Knight-

Hi everyone,

I’m running into a strange BitLocker issue after reimaging a Windows 11 laptop and would appreciate some advice on the proper process.

The laptop previously had BitLocker enabled.
During the reimage process, I went to the Windows partition screen, deleted the primary Windows partition, and then proceeded with the reimage.

Everything went smoothly until I reached the Windows desktop.

After reaching the desktop, I started BitLocker encryption. I was prompted to create/enter a PIN and run the system check, which restarted the laptop.

After the restart, BitLocker prompted for the PIN/key. I entered the same PIN that I had configured during the BitLocker setup, but it reported that the PIN was incorrect.

This is confusing because the same PIN had been working on the device before the reimage.

If I press Esc, I can bypass the BitLocker screen and get back into Windows. Once in Windows, I get an error saying that BitLocker could not be set up due to a TPM-related communication issue (I unfortunately don’t have the exact wording of the error).

I then tried clearing the TPM keys from BIOS and restarting.

After attempting to set up BitLocker again, I get a different error saying something along the lines of:
BitLocker could not start. Try restarting BitLocker.
At this point I’m basically stuck in a loop.

One additional detail
For our reimaging process, we currently have to disable Secure Boot before reimaging and then enable it again after Windows has been reimaged.

So I’m wondering if this could be related to the TPM/Secure Boot state.

My questions
For a device that previously had BitLocker enabled, what is the recommended process before reimaging?
Should I:
Suspend/disable BitLocker before reimaging?
Clear the TPM before reimaging?
Clear TPM/Secure Boot keys before reimaging?
Disable Secure Boot, reimage, then enable it again?
Or should TPM/Secure Boot be handled differently?
And more importantly, what would be the correct way to recover this particular device from the BitLocker/TPM loop?

I’m trying to understand whether I’m creating a mismatch between the TPM, Secure Boot measurements and the new Windows installation by clearing/re-enabling things in the wrong order.

Any advice on the proper reimage + TPM + Secure Boot + BitLocker process would be greatly appreciated.

Hi everyone,

I’m having an issue deploying Whalebone through Microsoft Intune and wanted to see if anyone else is experiencing something similar.

We use Intune/Autopilot to provision laptops for new users. We also regularly reuse returned laptops.
Our process is:

Receive returned laptop.
Perform an Intune Wipe without retaining user data.
Reprovision the device through Autopilot.
Whalebone is deployed as a required application through Intune/ESP.
Recently, Whalebone has started constantly failing during installation.
The error shown in Intune is:
Failed during installation (0x80070643)

This wasn’t happening previously. The deployment was working fine before, but we’ve started seeing this issue recently.

One thing I’ve noticed is that sometimes the application doesn’t seem to start installing immediately after ESP. It can sit for quite a while before Intune/IME starts downloading it, and then the installation eventually fails with 0x80070643.

What’s confusing is that if we wipe the same device again and reprovision it, the installation can sometimes work normally.

Has anyone else experienced Whalebone + Intune installation failures with error 0x80070643 recently?

I’m trying to determine whether this is more likely to be:
An issue with the Whalebone installer/package
A recent Whalebone update/change
Intune Management Extension timing/sync
A previous/partial installation left behind after the device was wiped
A dependency or Windows component issue
Another application/security product interfering with the installation

If anyone has encountered 0x80070643 specifically with Whalebone through Intune, I’d appreciate any troubleshooting tips or logs you recommend checking.

Hi everyone,

I’m having an intermittent issue deploying the SentinelOne Windows agent through Intune during Autopilot/ESP, and I’m hoping someone has experienced something similar.

We regularly reuse laptops that are returned by users. When we receive a device, we perform an Intune Wipe without retaining user data and then reprovision it for the next user.

For the past 2–3 weeks, we’ve started seeing issues with SentinelOne that we weren’t experiencing previously.
Here are some of the different behaviors we’re seeing:
Intune reports that SentinelOne failed during installation.
Sometimes the installation appears to succeed, but SentinelOne doesn’t appear under Installed Apps.
Sometimes the agent is installed, but it isn’t actually running.

In services.msc, both SentinelOne Agent and SentinelOne Helper services can be disabled/not running.

If I manually set the services to Automatic and start them, the SentinelOne Helper service starts, but the SentinelOne Agent service does not.

In some cases, SentinelOne eventually works after another Intune sync/retry.

Interestingly, if we perform another Intune Wipe and run the Autopilot/ESP provisioning process again, SentinelOne will sometimes install and work correctly.

What makes this particularly strange is that the same laptop can fail during provisioning, then work normally after being wiped and reprovisioned again.

Our general process is:
Returned laptop comes in.
Intune Wipe without retaining user data.
Autopilot provisioning for the new user.
SentinelOne is deployed as a required application during ESP.
Verify required applications/security tools before giving the laptop to the user.

Has anyone seen SentinelOne behave like this recently?

I’m wondering if this could be related to:
Intune/IME timing or sync issues
A partially installed/previous SentinelOne installation remaining after the wipe
SentinelOne services not being configured correctly during installation
A recent SentinelOne agent/installer change
Autopilot ESP installing multiple security applications at the same time
Detection rules reporting success/failure incorrectly

Something left behind on the device after an Intune Wipe
The fact that a second wipe/reprovision can make it work is what has me confused.

This was working reliably for us before the last 2–3 weeks.
If anyone has seen this recently or has suggestions for what logs/settings I should check, I’d really appreciate it.

Hi everyone,

I’m trying to figure out an intermittent issue we’re seeing with Intune app deployments on reused laptops.
We regularly receive returned laptops and re-provision them for new users. Our process is generally:
Perform an Intune/Wipe on the device without retaining user data.

Re-provision the device through Autopilot.
During ESP, required applications such as SentinelOne and Whalebone are supposed to install.
Once everything is installed and verified, we hand the laptop over to the new user.

The issue is that sometimes when we wipe and reprovision a device on the same day, some of the required apps fail to install.
For example, we may see:
“Downloading and installing SentinelOne failed”
“Downloading and installing Whalebone failed”

Another behavior we’ve noticed is that after ESP finishes, SentinelOne may be installed but the other required apps don’t seem to sync/install for quite a while. Eventually Whalebone starts downloading, but then fails during installation.

What’s interesting is that if we wipe the same laptop again a few days later, the exact same apps often install successfully.

This makes me wonder if we’re dealing with some kind of timing/sync issue between Autopilot, Intune, and the Intune Management Extension (IME), rather than an issue with the application packages themselves.

Has anyone experienced something similar when reusing/reprovisioning devices shortly after an Intune wipe?

If so:
Did you find that waiting a certain amount of time after the wipe helped?
Could stale device/Autopilot/Intune state be causing this?
Is there anything specific with IME sync/check-in that we should be checking?
Are there particular IME logs you recommend looking at for these failures?
Could SentinelOne/Whalebone themselves be causing installation conflicts during ESP?

Any troubleshooting suggestions or similar experiences would be really appreciated.

Curious how other organizations handle laptop provisioning with Intune/Autopilot.

Currently, we Autopilot the laptops and use the new hire’s credentials to sign in during provisioning. We then let the ESP complete and verify that everything is set up before shipping the laptop to the user — including:

BitLocker
BIOS settings
Required applications
Other required configurations

This works well, but when we have multiple new hires at the same time, it can become a bit overwhelming since we have to go through each device using the new user’s credentials before shipping.

For those of you doing something similar, how do you handle this?

Do you:
Use the new hire’s credentials to complete ESP and verify everything before shipping?
Have IT sign in with an IT/admin account, complete the configuration, and then use Autopilot Reset to remove the primary user before shipping?
Have a completely different provisioning workflow?

Also, we’ve noticed that sometimes the SentinelOne agent stops running or CyberArk stops running after provisioning. Has anyone experienced this? Could it be related to WMI errors or something happening during Autopilot/BIOS configuration?

Would love to hear how other organizations handle this, especially when provisioning multiple laptops for new hires at once.

I’m working on an Intune deployment to enable virtualization remotely for our employees on Lenovo ThinkPads. We have the BIOS supervisor password and are using Lenovo’s WMI PowerShell methods documented here:
https://download.lenovo.com/pccbbs/mobiles\_pdf/kbl-r\_deploy\_01.pdf

My script is very simple. It detects whether the CPU is Intel or AMD and then applies the appropriate BIOS setting.

Intel ThinkPads
Script runs successfully.
System reboots.
Virtualization is enabled in BIOS.
Task Manager shows “Virtualization: Enabled”.
Get-ComputerInfo / firmware virtualization checks return True.

AMD ThinkPads
Script runs successfully.
BIOS setting (AMD-V / AMD Virtualization Technology) is enabled.
System reboots and displays a white screen indicating that the system configuration has changed and another restart is required.
After Windows loads, Task Manager still reports “Virtualization: Disabled”.
Firmware virtualization checks also return False.

What’s strange is that when I manually enter BIOS, I can see that AMD-V is already enabled. However, virtualization does not actually become active until I:
Disable AMD-V.
Save and exit BIOS.
Re-enter BIOS.
Re-enable AMD-V.
Save and exit BIOS.

After doing that, Windows immediately reports virtualization as enabled.

Has anyone encountered this behavior on AMD-based ThinkPads when enabling virtualization through Lenovo WMI or scripting?

Is there an additional BIOS setting, reboot sequence, confirmation step, or Lenovo-specific requirement that AMD systems need before the virtualization setting actually takes effect?

Any guidance would be appreciated since I’m trying to deploy this at scale through Intune rather than requiring users to manually enter BIOS.

I’m working on an Intune deployment to enable virtualization remotely for our employees on Lenovo ThinkPads. We have the BIOS supervisor password and are using Lenovo’s WMI PowerShell methods documented here:
https://download.lenovo.com/pccbbs/mobiles\_pdf/kbl-r\_deploy\_01.pdf
My script is very simple. It detects whether the CPU is Intel or AMD and then applies the appropriate BIOS setting.

Intel ThinkPads
Script runs successfully.
System reboots.
Virtualization is enabled in BIOS.
Task Manager shows “Virtualization: Enabled”.
Get-ComputerInfo / firmware virtualization checks return True.

AMD ThinkPads
Script runs successfully.
BIOS setting (AMD-V / AMD Virtualization Technology) is enabled.
System reboots and displays a white screen indicating that the system configuration has changed and another restart is required.
After Windows loads, Task Manager still reports “Virtualization: Disabled”.
Firmware virtualization checks also return False.

What’s strange is that when I manually enter BIOS, I can see that AMD-V is already enabled. However, virtualization does not actually become active until I:
Disable AMD-V.
Save and exit BIOS.
Re-enter BIOS.
Re-enable AMD-V.
Save and exit BIOS.

After doing that, Windows immediately reports virtualization as enabled.

Has anyone encountered this behavior on AMD-based ThinkPads when enabling virtualization through Lenovo WMI or scripting?

Is there an additional BIOS setting, reboot sequence, confirmation step, or Lenovo-specific requirement that AMD systems need before the virtualization setting actually takes effect?

Any guidance would be appreciated since I’m trying to deploy this at scale through Intune rather than requiring users to manually enter BIOS.

I’m working on an Intune deployment to enable virtualization remotely for our employees on Lenovo ThinkPads. We have the BIOS supervisor password and are using Lenovo’s WMI PowerShell methods documented here:
https://download.lenovo.com/pccbbs/mobiles\_pdf/kbl-r\_deploy\_01.pdf

My script is very simple. It detects whether the CPU is Intel or AMD and then applies the appropriate BIOS setting.

Intel ThinkPads
Script runs successfully.
System reboots.
Virtualization is enabled in BIOS.
Task Manager shows “Virtualization: Enabled”.
Get-ComputerInfo / firmware virtualization checks return True.

AMD ThinkPads
Script runs successfully.
BIOS setting (AMD-V / AMD Virtualization Technology) is enabled.
System reboots and displays a white screen indicating that the system configuration has changed and another restart is required.
After Windows loads, Task Manager still reports “Virtualization: Disabled”.
Firmware virtualization checks also return False.

What’s strange is that when I manually enter BIOS, I can see that AMD-V is already enabled. However, virtualization does not actually become active until I:
Disable AMD-V.
Save and exit BIOS.
Re-enter BIOS.
Re-enable AMD-V.
Save and exit BIOS.

After doing that, Windows immediately reports virtualization as enabled.

Has anyone encountered this behavior on AMD-based ThinkPads when enabling virtualization through Lenovo WMI or scripting?

Is there an additional BIOS setting, reboot sequence, confirmation step, or Lenovo-specific requirement that AMD systems need before the virtualization setting actually takes effect?

Any guidance would be appreciated since I’m trying to deploy this at scale through Intune rather than requiring users to manually enter BIOS.