none
Bitlocker Win 7 - Unable to save TPMOwner Information Error Code 0x80072030 RRS feed

  • Question

  • We have a been using BitLocker for years on a Windows 2008 domain with Windows 7 x86 clients. The Schema is at version 44 and has been extended for Windows 7 BitLocker. We are using Group Policy to set client BitLocker settings and there has not been an issue storing the TPM Owner Information or BitLocker information for the Windows 7 clients until recently.  Now, we cannot store TPM Owner Information into AD and receive the dreaded "There is no such object on the server" with error code 0x80072030.

    If we remove the GP requirement to save the TPM Owner Information to AD we can save the BitLocker Recovery Information to AD.

    We have updated the Group Policy templates in the central policy store for Windows 8.1/Windows Server 2012 R2 but have not updated the schema. 

    Is there an issue with the Group Policy templates that support BitLocker if the schema has not been updated to support Windows 8.1/Windows Server 2012 R2? 

    Could the new templates be causing the Windows 7 issue with the inability to save the TPM Owner Information even though the Windows 7 location is still on the computer object vice a new object under TPM Devices? 

    Has the updated templates changed where Windows 7 saves the TMP Owner Information?

    Thanks

    PS.  There are no W2K12R2 Domain Controllers in the forest.

    
    • Edited by GeorgeKY Wednesday, July 13, 2016 7:56 PM
    Wednesday, July 13, 2016 6:43 PM

Answers

  • I have discovered the resolution but have not discovered the reason. 

    It appears that our Windows 7 clients were failing because instead of storing the TPM Owner Information in the msTPM-OwnerInformation attribute, it was failing because it could not save the TPM Owner Information into the non-existent attribute msTPM-TpmInformationForComputer.

    We have a developmental forest where we try things and we had recently installed W2K12R2 DCs into that forest.  Windows 7 clients were successfully able to save their TPM information into the msTPM-TpmInformationForComputer attribute of the computer object.  We were not yet ready to promote a W2K12R2 DC into our Production forest, but manually extending the schema in our Production forest resolved the issue. 

    I can only assume that a security update has altered the OS in some fashion, changing the attribute that the TPM Owner Information is being saved in AD by Windows 7 clients.  From the documentation that I have read, on Windows 8.1 and newer, the TPM information is being stored in a new container instead of as an attribute of the computer object but if I recall correctly, the attribute name in the new object is msTPM-TpmInformationForComputer.

    Hope this helps someone else.


    George Wilson

    • Marked as answer by GeorgeKY Thursday, July 14, 2016 10:53 PM
    Thursday, July 14, 2016 10:53 PM

All replies

  • I have discovered the resolution but have not discovered the reason. 

    It appears that our Windows 7 clients were failing because instead of storing the TPM Owner Information in the msTPM-OwnerInformation attribute, it was failing because it could not save the TPM Owner Information into the non-existent attribute msTPM-TpmInformationForComputer.

    We have a developmental forest where we try things and we had recently installed W2K12R2 DCs into that forest.  Windows 7 clients were successfully able to save their TPM information into the msTPM-TpmInformationForComputer attribute of the computer object.  We were not yet ready to promote a W2K12R2 DC into our Production forest, but manually extending the schema in our Production forest resolved the issue. 

    I can only assume that a security update has altered the OS in some fashion, changing the attribute that the TPM Owner Information is being saved in AD by Windows 7 clients.  From the documentation that I have read, on Windows 8.1 and newer, the TPM information is being stored in a new container instead of as an attribute of the computer object but if I recall correctly, the attribute name in the new object is msTPM-TpmInformationForComputer.

    Hope this helps someone else.


    George Wilson

    • Marked as answer by GeorgeKY Thursday, July 14, 2016 10:53 PM
    Thursday, July 14, 2016 10:53 PM
  • A valuable case, thank you for sharing:)


    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Sunday, July 17, 2016 8:17 AM
    Moderator
  • I am experiencing this same issue that started sometime in the past month. It is good to have confirmation, but I'd love to know which update actually caused it so I can point my Active Directory Team to it as the culprit.

    The attribute is already set up in our Domain, but now I need them to give the proper permissions to the computer objects so they can save to it. 


    Austin WongCarter Arizona State University

    Tuesday, August 9, 2016 5:45 PM
  • I found removing https://support.microsoft.com/en-us/kb/3133977 allowed the key to be saved to AD
    • Proposed as answer by FoundryGuy Thursday, February 23, 2017 9:58 PM
    Wednesday, August 10, 2016 7:28 AM
  • KB3133977 was superseded - in my testing, it is now KB3133977 &/or KB3125574.


    • Edited by Betsy432 Monday, October 24, 2016 3:16 PM
    Monday, October 24, 2016 3:16 PM
  • Removing the KB3133977 update resolved the 0x80072030 error I was receiving when attempting to pass out BitLocker through SCCM with recovery information being stored in AD.  

    This was an issue affecting only certain computers of various models.  Turns out it was an update compliance issue.  Still looking into it, but my guess is that the computers affected were not in compliance with the KB3125574 update which superceded/resolved the bug regarding BitLocker and escrowing to AD.


    I'm as smart as the next person...God I hope the next person is smart!

    Thursday, February 23, 2017 10:03 PM