Random Windows Deactivation

Question

System OS: Windows 10 IoT Enterprise 2019 (With Extended Support)

System Hardware: Onyx Zeus 227S / 228 All-In-One PC

Activation Method: Multiple Activation Key (MAK)

Description: We activated multiple systems with MAK and confirmed all system activated successfully. In subsequent use and maintenance, we noticed a few instances where the system would become deactivated after replacement of the PC backup battery and CMOS battery. Based on the event logs (see screenshots below), the software licensing service failed to evaluate the license or not able to find the license. We were able to reactivate the system with phone activation method but we are concerned about the random deactivation and potential impact on the system functionalities.

Event Log Screenshots: Before Deactivation Deactivation:

Questions:

1. Does the MAK activation rely on hardware characteristics from backup battery or CMOS battery? 2. Does the deactivation of Windows IoT Enterprise affect Windows feature availability (e.g. Shell Launcher)? 3. Are there configuration / mitigation that we can implement to prevent the deactivation? Or we should accept it as part of the norms?

Thanks,

Answer 1

Hello,

1. this should not affect activation unless the hardware detection happens after the CMOS battery is changed. Probably something else
2. The only effect deactivation would be with the limitations put on the desktop display along with the notice on the desktop. No other features would be affected.
3. It's not clear why it's being deactivated, the logs are not indicative of a deactivation issue. You could run the licensingdiag,exe tool and post cab file with teh results to see if there is something that points in ithe correct direction.

Darrell

Answer 2

Dear Team,

1. Does MAK activation rely on the backup or CMOS battery?

No, the activation process does not directly check the battery itself. However, a failing or replaced CMOS battery can cause system instability that leads to deactivation.

Windows activation creates a hardware hash, a unique identifier based on key components like the motherboard, processor, BIOS, and hard drive. When you replace the CMOS battery, the system's BIOS/UEFI settings, including the system clock, can be reset to their defaults. This sudden and significant change in system configuration, especially if it affects how the hardware is reported to the operating system upon boot, can alter the hardware hash enough for Windows to believe it's on a different machine. The event log error, where the licensing service fails to evaluate or find the license, is consistent with this scenario.

---

2. Does deactivation affect Windows IoT Enterprise features like Shell Launcher?

For a period, most features, including Shell Launcher, will likely continue to function. However, you should not rely on this. An unactivated state is not supported for production environments.

While Windows might enter a "notification" period where core functionality remains, continued deactivation will lead to:

Persistent notifications and a watermark on the desktop, which can interfere with custom shell environments.

Loss of personalization settings.

Crucially, the system will stop receiving critical security and feature updates. For an IoT device, this poses a significant security risk.

Eventually, Windows may enter a Reduced Functionality Mode (RFM), which could disable advanced features, although this is less common in modern versions of Windows 10. The primary impact is the loss of updates and the intrusive notifications.

---

3. Can this deactivation be prevented, or is it normal?

This is not normal behavior that should be accepted, but it is a known issue when significant hardware or configuration changes occur. You can take steps to mitigate it.

Preventative & Mitigation Steps:

Standardize BIOS/UEFI Settings: Before replacing a battery, document the exact BIOS/UEFI settings of a properly activated machine. After the replacement, immediately enter the BIOS/UEFI setup and restore these settings before booting into Windows. This consistency can prevent the hardware hash from changing significantly.

Network Connection: Ensure the device has a stable internet connection when it's first booted after the hardware change. This allows it to contact Microsoft's activation servers. If the system was activated via a MAK Proxy, ensure it can reach the proxy server.

Re-Arm the License: For planned maintenance, you can use the Software License Manager (slmgr.vbs) command-line tool to "re-arm" the license before the hardware change. This command resets the licensing timers, providing a grace period before requiring activation. You can use the command slmgr /rearm in an elevated command prompt. This can be done a limited number of times.

Accepting random deactivation is not a viable long-term strategy due to the security and potential functionality risks. Proactively managing the hardware replacement process is the recommended approach.

1. Does MAK activation rely on the backup or CMOS battery?

No, the activation process does not directly check the battery itself. However, a failing or replaced CMOS battery can cause system instability that leads to deactivation.

Windows activation creates a hardware hash, a unique identifier based on key components like the motherboard, processor, BIOS, and hard drive. When you replace the CMOS battery, the system's BIOS/UEFI settings, including the system clock, can be reset to their defaults. This sudden and significant change in system configuration, especially if it affects how the hardware is reported to the operating system upon boot, can alter the hardware hash enough for Windows to believe it's on a different machine. The event log error, where the licensing service fails to evaluate or find the license, is consistent with this scenario.

---

2. Does deactivation affect Windows IoT Enterprise features like Shell Launcher?

For a period, most features, including Shell Launcher, will likely continue to function. However, you should not rely on this. An unactivated state is not supported for production environments.

While Windows might enter a "notification" period where core functionality remains, continued deactivation will lead to:

Persistent notifications and a watermark on the desktop, which can interfere with custom shell environments.

Loss of personalization settings.

Crucially, the system will stop receiving critical security and feature updates. For an IoT device, this poses a significant security risk.

Eventually, Windows may enter a Reduced Functionality Mode (RFM), which could disable advanced features, although this is less common in modern versions of Windows 10. The primary impact is the loss of updates and the intrusive notifications.

---

3. Can this deactivation be prevented, or is it normal?

This is not normal behavior that should be accepted, but it is a known issue when significant hardware or configuration changes occur. You can take steps to mitigate it.

Preventative & Mitigation Steps:

Standardize BIOS/UEFI Settings: Before replacing a battery, document the exact BIOS/UEFI settings of a properly activated machine. After the replacement, immediately enter the BIOS/UEFI setup and restore these settings before booting into Windows. This consistency can prevent the hardware hash from changing significantly.

Network Connection: Ensure the device has a stable internet connection when it's first booted after the hardware change. This allows it to contact Microsoft's activation servers. If the system was activated via a MAK Proxy, ensure it can reach the proxy server.

Re-Arm the License: For planned maintenance, you can use the Software License Manager (slmgr.vbs) command-line tool to "re-arm" the license before the hardware change. This command resets the licensing timers, providing a grace period before requiring activation. You can use the command slmgr /rearm in an elevated command prompt. This can be done a limited number of times.

Accepting random deactivation is not a viable long-term strategy due to the security and potential functionality risks. Proactively managing the hardware replacement process is the recommended approach.