TPM 鎖定的原因
我們部署了多台 Surface Pro 3 設備，並在 TPM + PIN 模式下啟用了 BitLocker。這些設備具有 TPM 2.0 晶片並執行 Windows 8.1 Pro。
我們遇到的問題是，使用者在輸入正確的 PIN 碼時偶爾會收到“錯誤的 PIN 碼嘗試次數過多”錯誤。然後，他們必須輸入恢復密鑰才能繼續啟動過程。然後，他們每次啟動設備時都需要輸入恢復密鑰，直到我們使用 tpm.msc 手動重置 TPM 鎖定，這顯然不方便。
出於某種原因，TPM 正在進入鎖定狀態，但這似乎不是因為重複錯誤的 PIN 嘗試。如果您讓設備執行，鎖定最終不會超時這一事實也表明它是出於其他原因，而不是達到最大錯誤身份驗證嘗試次數。我了解 TPM 2.0 規範聲明應該是這種情況，與將確切行為留給供應商的 TPM 1.2 規範不同。
執行
Get-Tpm表明 TPM 肯定處於鎖定狀態，但不提供有關原因的任何資訊。有誰知道我是否可以做任何事情來嘗試確定鎖定的根本原因？
最後，我設法在解決這個問題上取得了相當大的進展。我會盡力記住細節，但已經有一段時間了……
不幸的是，有問題的機器是 Windows 8 機器，因此
Get-Tpmcmdlet 不會返回有關鎖定計數器的資訊。我最終設法編寫了一個自定義腳本來直接從 TPM 讀取這些計數器，果然，鎖定計數器已達到鎖定門檻值。即使我們沒有錯誤地輸入 PIN，情況也是如此。經過大量探勘，我最終偶然發現了 TPM 2.0 規範中的一個部分，該部分描述了一種幾乎可以肯定導致問題的機制。在我詳細介紹之前，有一點背景知識會很有用… 在作業系統可以使用 TPM 之前，它必須呼叫 TPM 的啟動常式。這似乎發生在顯示 BitLocker PIN 螢幕之前。相反，一旦作業系統完成使用 TPM，它應該呼叫 TPM 的關閉常式。Windows 似乎在作業系統關閉序列期間執行此操作。
當系統關閉而作業系統沒有完全關閉時，問題就出現了。在這種情況下，TPM 的關閉程序在晶片斷電之前沒有被呼叫。TPM 2.0 規範規定，如果在沒有先前呼叫 TPM 的關閉常式的情況下呼叫 TPM 的啟動常式，它應該將鎖定計數器加一。此功能的存在是為了防止針對 TPM 的特定類型的攻擊。因此，當設備再次開機時，即使使用者輸入了正確的 BitLocker PIN，鎖定計數器也會加一。
在我的特殊情況下，有問題的設備都是 Microsoft Surface Pro 3 平板電腦。我的預感是使用者按住電源按鈕以關閉機器而不是乾淨地關閉它。通常，這不是一個大問題，因為鎖定計數器最終會在兩小時後再次遞減。但是，如果他們經常這樣做，鎖定計數器就沒有時間遞減。如果機器重新通電，用於跟踪何時減少的計時器會重置，這意味著它必須在減少之前連續保持兩個小時，從而使問題更加複雜。一些使用者只在短時間內將他們的機器拿出來。
Surface Pro 3 支持微軟稱之為“Connected Standby”或“InstantGo”的東西。這是一項使設備在電源管理方面表現得更像移動設備的功能。點擊電源按鈕會使設備進入低功耗模式，而不是傳統的待機或睡眠模式。但是，我們已將電源計劃切換到“高性能”，這具有禁用連接待機模式的效果，使設備的行為類似於傳統 PC。我認為這可能是問題的一個因素。
我讀過的解釋是 TPM 無權寫入任何類型的日誌或導致鎖定它拒絕訪問的驅動器。明智的。給出一個理由也可能存在安全漏洞。
我能找到的唯一資訊是輸入的錯誤密碼的數量。打開提升的 powershell 提示符並輸入：
獲取-tpm
與普通的命令外殼不同，您將擁有 LockoutCount 和 LockoutMax 的條目。這將為您提供輸入了多少錯誤密碼的計數。我確信使用者確信他們總是輸入正確的密碼，但我發現通常存在溝通錯誤。
話雖如此，還有許多其他鎖定原因。 https://technet.microsoft.com/en-us/library/dn383583(v=ws.11).aspx 特別是“什麼導致 Bitlocker 恢復？” 從插入 CD 到讓設備的電池完全放電，任何事情都可能導致鎖定。這是我試圖通過混合使用者教育、幫助台教育和評估要更改的組/本地策略設置來解決的問題。 https://technet.microsoft.com/en-us/library/jj679890(v=ws.11).aspx