แก้ BitLocker Recovery Key Windows 11 2026

เอาจริง ๆ นะ เดือนเมษายน 2026 นี่ทีม IT Helpdesk หลายแห่งทั่วโลกแทบไม่ได้พักเลย หลังจากที่ผู้ใช้ Windows 11 24H2 และ 25H2 ถูกเด้งหน้าจอน้ำเงินเรียก BitLocker Recovery Key กันเป็นแถบ ๆ หลังติดตั้ง Cumulative Update KB5083769 หรือ KB5082052 และที่เลวร้ายกว่านั้นคือบางเครื่องเข้าสู่ Boot Loop แบบรับ Recovery Key เสร็จแล้วก็เด้งกลับมาถามใหม่ วน ๆ อยู่อย่างนั้น

บทความนี้ผมรวมแนวทางวินิจฉัยและแก้ปัญหา BitLocker Recovery Key สำหรับทีม IT Helpdesk แบบ End-to-End ตั้งแต่การดึง Recovery Key จาก Microsoft Entra ID และ Intune, การใช้ manage-bde ใน Recovery Environment, การตั้งค่า Group Policy ที่ถูกต้อง ไปจนถึงการป้องกันปัญหาไม่ให้เกิดขึ้นอีกในอนาคต — อิงตามคำแนะนำล่าสุดจาก Microsoft (อัปเดตเมษายน 2026)

เหตุการณ์ KB5083769/KB5082052 เมษายน 2026: เกิดอะไรขึ้นกันแน่

เมื่อวันที่ 14 เมษายน 2026 Microsoft แอบเพิ่มหัวข้อ Known Issue ใน Release Note ของอัปเดตทั้งสองตัวว่า "อุปกรณ์ที่มี BitLocker Group Policy ที่ไม่แนะนำอาจถูกบังคับให้กรอก Recovery Key หลังติดตั้งอัปเดต" ซึ่ง... พูดตรง ๆ ก็คือยอมรับว่าเป็นบั๊กนั่นแหละ แค่ไม่อยากเรียกตรง ๆ

อาการที่ผู้ใช้เจอ

เครื่องบูตขึ้นมาแล้วเจอหน้า BitLocker Recovery สีน้ำเงินทันทีหลังรีบูตจากการติดตั้งอัปเดต
กรอก 48-digit Recovery Key ถูกต้อง แต่เครื่องรีบูตและกลับมาถามใหม่ (Endless Loop ของจริง)
บางเครื่องพบ Pixelated BSOD ตามด้วย CRITICAL_PROCESS_DIED หรือ UNEXPECTED_KERNEL_MODE_TRAP
ส่วนใหญ่พบในเครื่อง HP และ Dell ที่ใช้ Windows 11 24H2 หรือ 25H2 และมี Group Policy เกี่ยวกับ TPM Platform Validation Profile เปิดใช้งาน

Root Cause: PCR7 และ TPM Platform Validation Profile

ปัญหาหลักมาจาก Group Policy ตัวนี้:

Computer Configuration
  > Administrative Templates
    > Windows Components
      > BitLocker Drive Encryption
        > Operating System Drives
          > Configure TPM platform validation profile for native UEFI firmware configurations

เมื่อ Policy นี้ถูกตั้งค่าให้ตรวจสอบ PCR (Platform Configuration Register) ที่ไม่จำเป็น เช่น PCR0, PCR2, PCR4 พร้อมกัน ทันทีที่ Windows Update เปลี่ยน Boot Component บางตัว ค่า PCR ที่บันทึกไว้ใน TPM ก็จะไม่ตรงกับค่าหลังบูต BitLocker เลยตัดสินใจ "Seal Failed" และเรียก Recovery Key ขึ้นมาเลย

Microsoft แนะนำชัดว่าให้ใช้ PCR7-Based Validation สำหรับเครื่องที่รองรับ Secure Boot ซึ่งเป็นค่าเริ่มต้นของ Windows อยู่แล้ว — ไม่ควร Override ผ่าน GPO เว้นแต่จำเป็นจริง ๆ (และถ้าคุณกำลังคิดว่า "จำเป็นจริง ๆ" ของคุณคืออะไร ลองคิดอีกรอบก่อนเถอะ)

ขั้นตอนแรกของ Helpdesk: ยืนยันสภาพเครื่องและดึง Recovery Key

1. ระบุประเภทการ Join ของเครื่อง

ก่อนตามหา Recovery Key ทีม Helpdesk ต้องรู้ก่อนว่าเครื่องนั้น Join เข้าสู่ระบบใด ไม่งั้นจะหาผิดที่:

ประเภทการ Join	แหล่งเก็บ Recovery Key
Microsoft Entra Joined	Microsoft Entra Admin Center / Intune Portal
Hybrid Entra Joined	Active Directory + Entra ID (ขึ้นกับ Policy)
AD-Joined อย่างเดียว	Active Directory (ผ่าน BitLocker Recovery Tab)
Workgroup / Personal MSA	aka.ms/aadrecoverykey

2. ดึง Recovery Key จาก Microsoft Entra ID ด้วย Microsoft Graph PowerShell

สำหรับเครื่องที่ Entra Joined หรือ Intune-Managed ผมแนะนำให้ใช้ Microsoft Graph PowerShell — เร็วกว่าการคลิกใน Portal เยอะ โดยเฉพาะตอนที่ทั้งทีมโทรเข้ามาพร้อมกัน:

# Install-Module Microsoft.Graph -Scope CurrentUser -Force
Connect-MgGraph -Scopes "BitlockerKey.Read.All", "Device.Read.All"

function Get-EntraBitLockerKeys {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [string]$DeviceName
    )
    $DeviceId = (Get-MgDevice -Filter "displayName eq '$DeviceName'").DeviceId
    if (-not $DeviceId) {
        Write-Warning "Device '$DeviceName' not found in Entra ID."
        return
    }
    $KeyIds = (Get-MgInformationProtectionBitlockerRecoveryKey `
                  -Filter "deviceId eq '$DeviceId'").Id
    foreach ($Id in $KeyIds) {
        $Key = Get-MgInformationProtectionBitlockerRecoveryKey `
                  -BitlockerRecoveryKeyId $Id -Property "key"
        [PSCustomObject]@{
            Device         = $DeviceName
            KeyId          = $Id
            RecoveryKey    = $Key.Key
            CreatedAt      = $Key.CreatedDateTime
        }
    }
}

Get-EntraBitLockerKeys -DeviceName "DESKTOP-USER01"

3. ดึง Recovery Key จาก Active Directory (On-Prem)

สำหรับองค์กรที่ยังใช้ AD DS อยู่ (มีเยอะกว่าที่คิดนะ) สามารถใช้ Get-ADObject เพื่อค้นหา BitLocker Recovery Information ที่ Escrow ไว้:

Import-Module ActiveDirectory

$ComputerName = "DESKTOP-USER01"
$Computer = Get-ADComputer -Identity $ComputerName

Get-ADObject -Filter { objectClass -eq 'msFVE-RecoveryInformation' } `
             -SearchBase $Computer.DistinguishedName `
             -Properties msFVE-RecoveryPassword, whenCreated |
    Sort-Object whenCreated -Descending |
    Select-Object whenCreated, @{N='RecoveryKey';E={$_.'msFVE-RecoveryPassword'}}

หากองค์กรยังไม่ได้ติดตั้ง BitLocker Recovery Password Viewer ใน RSAT ติดตั้งก่อนนะ:

Add-WindowsCapability -Online -Name "Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0"

แก้ปัญหา Boot Loop หลังกรอก Recovery Key สำเร็จ

นี่คือส่วนที่น่าหงุดหงิดที่สุด คือกรอก Recovery Key แล้วเครื่องก็ดันกลับมาถามอีก ราวกับล้อเล่น ให้ดำเนินการตามลำดับนี้:

ขั้นตอน 1: ปลดล็อกไดรฟ์ใน Recovery Environment ด้วย manage-bde

เมื่อเข้าสู่หน้า BitLocker Recovery ให้กด Esc > Skip this drive > Troubleshoot > Advanced options > Command Prompt จากนั้น:

:: ตรวจสอบสถานะ BitLocker บน OS Drive
manage-bde -status

:: ปลดล็อกไดรฟ์ด้วย Recovery Key (48 digits, มีขีดคั่นทุก 6 ตัว)
manage-bde -unlock C: -RecoveryPassword 123456-234567-345678-456789-567890-678901-789012-890123

:: ระงับการป้องกันชั่วคราว 1 รอบบูต เพื่อให้บูตผ่าน
manage-bde -protectors -disable C: -RebootCount 1

:: ออกจาก Command Prompt และเลือก Continue
exit

ขั้นตอน 2: หลังบูตเข้า Windows ได้แล้ว — Reseal TPM Protector

เปิด PowerShell แบบ Administrator แล้วรันชุดคำสั่งต่อไปนี้ เพื่อบังคับให้ BitLocker สร้าง TPM Protector ใหม่ตามค่า PCR ปัจจุบัน:

# ดู Protector ปัจจุบัน
manage-bde -protectors -get C:

# ลบ TPM Protector เก่า (เก็บ Recovery Password ไว้)
$tpmProtector = (manage-bde -protectors -get C: | Select-String "ID:.*\{.*\}" |
    Where-Object { $_.Line -notmatch "Numerical" }) -replace '.*\{(.*)\}.*','{$1}'
manage-bde -protectors -delete C: -id $tpmProtector

# เพิ่ม TPM Protector ใหม่
manage-bde -protectors -add C: -tpm

# ดูผลลัพธ์
manage-bde -status C:

ขั้นตอน 3: รีเซ็ต Group Policy ที่เป็นต้นเหตุ

หาก Boot Loop เกิดจาก GPO "Configure TPM platform validation profile" ให้ตั้งค่ากลับเป็น Not Configured:

# บนเครื่อง User (ถ้าใช้ Local GPO)
gpedit.msc

# บนเครื่อง Server (Domain GPO)
gpmc.msc

เส้นทาง: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for native UEFI firmware configurations > ตั้งเป็น Not Configured

จากนั้น Force GPO Refresh และ Reseal:

gpupdate /force
manage-bde -protectors -disable C:
manage-bde -protectors -enable C:

วินิจฉัยสาเหตุที่ทำให้ BitLocker เรียก Recovery Key

นอกจาก KB5083769 ที่เป็นข่าวดังในตอนนี้ ปัญหา BitLocker Recovery ในงาน Helpdesk ปกติยังมีสาเหตุที่พบบ่อยอีกหลายอย่าง ดังนี้:

สาเหตุยอดฮิตและวิธีตรวจสอบ

BIOS/UEFI Update ทำให้ค่า PCR เปลี่ยน — ตรวจ Event Viewer: Applications and Services Logs > Microsoft > Windows > BitLocker-API ดู Event ID 24620 หรือ 24621
Secure Boot ถูกปิด — ตรวจด้วย Confirm-SecureBootUEFI ใน PowerShell
TPM ถูก Clear หรือ Firmware ใหม่ — ตรวจด้วย Get-Tpm ดู TpmReady และ OwnerAuth
Boot Order เปลี่ยน — ตั้ง Windows Boot Manager เป็นอันดับแรกใน BIOS
USB-C/Thunderbolt Pre-boot Support เปิดใน BIOS — ปิด Pre-boot for TBT and USB-C/TBT บนเครื่อง Dell/HP บางรุ่น (ตัวนี้ผมเจอกับลูกค้าบ่อยมาก)
Disk Controller Mode (AHCI/RAID) ถูกเปลี่ยน — ห้ามเปลี่ยนหลังเข้ารหัสเด็ดขาด
Hardware ใหม่ที่ติดผ่าน Hot-plug — เช่น Dock, eGPU, External SSD ที่ทำให้ Firmware Boot Order เปลี่ยน

สคริปต์ Helpdesk Diagnostic แบบ One-Shot

ผมชอบใช้สคริปต์นี้รันบนเครื่อง User เพื่อรวมข้อมูลที่จำเป็นทั้งหมดสำหรับวินิจฉัยใน 1 คำสั่ง — ประหยัดเวลาคุยกับ User ได้เยอะ:

# BitLocker-Diag.ps1 — รันแบบ Administrator
$Report = @{
    Hostname        = $env:COMPUTERNAME
    OSBuild         = (Get-ComputerInfo).OsBuildNumber
    UBR             = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
    SecureBoot      = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
    TPM             = (Get-Tpm | Select-Object TpmPresent, TpmReady, ManufacturerVersion)
    BitLocker       = (Get-BitLockerVolume -MountPoint $env:SystemDrive)
    Protectors      = (Get-BitLockerVolume -MountPoint $env:SystemDrive).KeyProtector
    RecentBLEvents  = Get-WinEvent -FilterHashtable @{
                          LogName='Microsoft-Windows-BitLocker/BitLocker Management';
                          StartTime=(Get-Date).AddDays(-7)
                      } -ErrorAction SilentlyContinue |
                      Select-Object TimeCreated, Id, LevelDisplayName, Message
    LastUpdate      = (Get-HotFix | Sort-Object InstalledOn -Descending |
                       Select-Object -First 5 HotFixID, InstalledOn)
}
$Report | ConvertTo-Json -Depth 5 |
    Out-File "$env:TEMP\BitLocker-Diag-$($env:COMPUTERNAME).json"
Write-Host "Report saved to $env:TEMP\BitLocker-Diag-$($env:COMPUTERNAME).json"

ป้องกันปัญหาก่อนปล่อย Patch ทั้ง Fleet

Pre-Patching Checklist สำหรับองค์กร

สำรอง Recovery Key ทุกเครื่องก่อนปล่อย Patch — ใช้ BackupToAAD-BitLockerKeyProtector หรือ Group Policy "Choose how BitLocker-protected operating system drives can be recovered" ตั้ง "Save BitLocker recovery information to AD DS for OS drives"
ตรวจสอบเครื่องที่ Recovery Key หายจาก Entra ID ด้วย Graph API ก่อน Patch (ขั้นนี้สำคัญสุด ๆ — เคยเจอองค์กรหนึ่งที่ Key หาย 30% ของ Fleet โดยไม่รู้ตัว)
ทดสอบ Patch บน Pilot Group ที่มี Hardware ใกล้เคียงกับ Fleet (HP, Dell, Lenovo) ที่ Enable BitLocker
เปิด Auto Recovery Password Rotation ผ่าน Intune Configuration Profile (BitLocker / ConfigureRecoveryPasswordRotation = 2)
กำหนด Group Policy ให้ใช้ PCR7-Based Validation เท่านั้น และตั้ง "Configure TPM platform validation profile" เป็น Not Configured

Backup Recovery Key ทั้ง Fleet ด้วย PowerShell

# รันผ่าน Intune Win32 Script หรือ ConfigMgr Compliance Item
$Volume = Get-BitLockerVolume -MountPoint $env:SystemDrive
$KeyProtector = $Volume.KeyProtector |
                Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }
foreach ($kp in $KeyProtector) {
    try {
        BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive `
                                          -KeyProtectorId $kp.KeyProtectorId
        Write-Output "Backed up KeyProtectorId: $($kp.KeyProtectorId)"
    }
    catch {
        Write-Warning "Failed to back up: $_"
    }
}

ขอ Known Issue Rollback (KIR) จาก Microsoft

สำหรับลูกค้า Commercial ที่ติด KB5083769/KB5082052 และไม่สามารถใช้ GPO Workaround ได้ Microsoft เปิดให้ขอ Known Issue Rollback Group Policy โดยติดต่อผ่าน Microsoft Support เพื่อรับ ADMX/ADML สำหรับโรลแบ็ก Configuration ที่เป็นต้นเหตุ — โดยไม่ต้องถอนอัปเดตด้านความปลอดภัยทิ้งทั้งหมด

เคสยาก: Endless Loop ที่ manage-bde -unlock ก็ไม่ผ่าน

ถ้ากรอก Recovery Key ถูก แต่ manage-bde -unlock ใน Recovery Environment ดันตอบกลับว่า The recovery password supplied was incorrect ทั้ง ๆ ที่ Key Id ตรงกัน ลองทำตามนี้:

เปลี่ยนภาษาคีย์บอร์ดใน WinRE เป็น US English ก่อนกรอก (กรณีเครื่องตั้งเป็นไทย/อาหรับ Layout บางตัวจะแมปเลขผิด — ฟังดูเล็กน้อยแต่เจอบ่อยมาก)
ลองด้วย Recovery Key เก่าก่อนหน้า — บางเครื่องมีหลาย Protector หลัง Auto-Rotate
หาก Recovery Key หายจาก Entra ID ให้ตรวจ Sign-in Log ว่าเครื่องเคย Sync เข้า Entra ID ก่อน Encrypt หรือไม่ ถ้าไม่ Key อาจไม่เคยถูก Escrow เลย
ถ้าทุกอย่างไม่ผ่านและไม่มี Backup Recovery Key — ก็ต้องยอมรับความจริงว่าต้อง Reinstall Windows และข้อมูลใน OS Drive จะหายไป (BitLocker ออกแบบมาแบบนี้ — Recover ไม่ได้โดยไม่มี Key คือฟีเจอร์ ไม่ใช่บั๊ก)

คำถามที่พบบ่อย (FAQ)

1. ทำไม BitLocker เรียก Recovery Key หลังอัปเดต Windows ทั้งที่ไม่ได้เปลี่ยน Hardware?

เพราะ Cumulative Update เปลี่ยน Boot Component บางตัว (เช่น Boot Manager, Bootloader) ทำให้ค่า PCR ใน TPM ไม่ตรงกับค่าที่ Seal ไว้ตอน Encrypt ครั้งแรก หากเครื่องตั้งค่า TPM Validation Profile ที่ครอบคลุม PCR หลายตัว (เช่น 0, 2, 4, 11) BitLocker จะมองว่า Boot Environment เปลี่ยน และเรียก Recovery Key อัตโนมัติ KB5083769 (เมษายน 2026) เป็นเคสล่าสุดที่กระทบ Windows 11 24H2/25H2

2. หา BitLocker Recovery Key ของผู้ใช้ที่อยู่นอกออฟฟิศได้อย่างไร?

หากเครื่อง Entra Joined ให้ค้นใน Microsoft Entra Admin Center > Devices > เลือกเครื่อง > แท็บ BitLocker Keys หรือใช้ Microsoft Graph PowerShell (Get-MgInformationProtectionBitlockerRecoveryKey) เพื่อดึงระยะไกล สำหรับเครื่อง Personal ที่ใช้ Microsoft Account ให้ User เปิด account.microsoft.com/devices/recoverykey จากโทรศัพท์เพื่อดู Key ของตนเอง

3. หลังกรอก Recovery Key แล้วต้องทำอะไรเพื่อให้ไม่ถูกถามอีก?

เข้า Windows ให้สำเร็จก่อน จากนั้นเปิด PowerShell แบบ Administrator แล้วรัน manage-bde -protectors -disable C: ตามด้วย manage-bde -protectors -enable C: เพื่อ Reseal TPM Protector ตามค่า PCR ปัจจุบัน หากเกิดจาก GPO ที่ตั้งผิด ให้แก้ TPM Platform Validation Profile กลับเป็น Not Configured ก่อน Reseal

4. ใช้ manage-bde กับ Suspend-BitLocker ต่างกันอย่างไร?

manage-bde -protectors -disable และ Suspend-BitLocker ทำงานคล้ายกันคือระงับ Protector ชั่วคราว แต่ Suspend-BitLocker เป็น PowerShell Cmdlet ที่ใช้ใน Windows ปกติ ส่วน manage-bde เป็น Native Tool ที่ใช้ได้ทั้งใน Windows และ Recovery Environment (WinRE) — ใน WinRE PowerShell Cmdlet ของ BitLocker จะใช้ไม่ได้ ดังนั้นต้องใช้ manage-bde เท่านั้น

5. ป้องกันไม่ให้ BitLocker Recovery Key Loop เกิดขึ้นกับ Fleet ทั้งองค์กรอย่างไร?

1) สำรอง Recovery Key ทุกเครื่องเข้า Entra ID/AD DS ก่อน Patch ผ่าน BackupToAAD-BitLockerKeyProtector 2) ใช้ Pilot Ring ทดสอบ Patch บน Hardware หลากหลายรุ่นก่อนปล่อย 3) ตั้ง GPO "Configure TPM platform validation profile" เป็น Not Configured เพื่อให้ Windows ใช้ PCR7 Default 4) เปิด Recovery Password Rotation ผ่าน Intune 5) ตรวจสอบ Sign-in Log ใน Entra ID ว่า Recovery Key ถูก Escrow ครบทุกเครื่อง

สรุปสำหรับทีม Helpdesk

การจัดการ BitLocker Recovery Key อย่างเป็นระบบเป็นหัวใจของ IT Operations ในยุค Hybrid Work — และพูดตรง ๆ มันเป็นทักษะที่ทีม Helpdesk หลายแห่งยังประเมินค่าต่ำเกินไป ทีมที่เตรียม Recovery Key Inventory ไว้พร้อมก่อน Patch Tuesday จะลดเวลา Resolve เคสจาก 30-60 นาทีเหลือเพียง 5-10 นาที (ผมเคยเห็นทีมหนึ่งลดเวลาได้ถึง 80% หลังทำ Pre-Patching Checklist อย่างจริงจัง)

สำหรับเหตุการณ์ KB5083769 เมษายน 2026 หากองค์กรของคุณมีเครื่องที่ยังกระทบอยู่ ให้เริ่มจาก GPO Workaround ที่ระบุไว้ข้างต้น และวางแผนขอ Known Issue Rollback จาก Microsoft Support เพื่อให้ Fleet กลับสู่สถานะปกติโดยไม่ต้องถอนอัปเดตด้านความปลอดภัยทิ้งไป โชคดีนะครับ