My organization is running AD DS on Server 2008 R2 schema. Already a bad start, I know, but let's pretend that's impossible to change. In our default domain policy, we have the following setting enabled to require AD backup of TPM owner authorization value hashes:

Computer Settings\Policies\Administrative Templates\System\Trusted Platform Module Services\Turn on TPM backup to Active Directory Domain Services

As a result, when I try to encrypt an AD-bound Windows 8 Enterprise machine with BitLocker, it fails because Windows 8 tries to store the TPM authorization hash as a child object (with type ms-TPM-OwnershipInformation) of the computer object, while the Server 2008 R2 schema requires storing this information as an attribute (specifically, msTPM-OwnerInformation) of the computer object. This is perfectly fine and dandy - in fact, it's clearly documented in a TechNet article (http://technet.microsoft.com/en-us/library/jj131725.aspx#BKMK_AuthValue) that this behavior is intentional, and the solution is to update to Server 2012 schema. Cool.

The bit that concerns me is that when I try to encrypt an AD-bound Windows 8.1 Enterprise machine, it succeeds under these same circumstances. However, despite the policy setting requiring the TPM backup, it simply doesn't occur - it is neither stored in the computer attribute, nor is it created as a child object to the computer.

I have not been able to find any documentation that would indicate that Windows 8.1 behaves differently from Windows 8 on this matter. As the mainstream support end date for Server 2008 R2 is not until 01/13/14, I wouldn't expect that Microsoft has intentionally implemented what I have described. Might this then be an unintended behavior?

you will need to use a more recent SKU of Windows server to be able to do that

for secure boot, you need server 2012 r2 

I appreciate the feedback; however, I'm not sure we're talking about the same thing. I am not referring to or implementing Secure Boot in any fashion; I am concerned about a discrepancy between the documented behavior of TPM owner authorization backup in Windows 8 versus the actual behavior in Windows 8.1, when in a Server 2008 R2 environment...

Hi,

According to the Screenshot below, you could find that, Windows 8, 8.1, Windows Server 2012 R2 doesn't support configure the level of TPM owner authorization information:

You can refer to the link below for more details about this information:

http://technet.microsoft.com/en-us/library/jj679889.aspx#BKMK_tpmgp_oauthos

Hi,

According to the Screenshot below, you could find that, At least Windows 8, Windows RT support configure the level of TPM owner authorization information:

You can refer to the link below for more details about this information:

http://technet.microsoft.com/en-us/library/jj679889.aspx#BKMK_tpmgp_oauth

the TPM is more useful for a mobile machine, servers are now mostly seen in datacenters

virtual machines are another angle to consider

Roger,

Thanks for the feedback; however, as indicated in my post, I am using the Turn on TPM backup to Active Directory Domain Services policy, which, as per your screenshot and link, is supported in Windows 8, Windows 8.1, and Windows Server 2008 R2. Again, if I can reiterate my concern, it is that the behavior I am describing with Windows 8.1 is that it does not comply with this policy setting when using Server 2008 R2 schema, which I feel is inappropriate and rather concerning.

Vegan Fanatic,

I agree, the TPM is very useful for mobile machines - which is exactly my concern: my organization has thousands of laptops and tablets that are used in a highly mobile fashion, and we suffer loss and theft of these devices on a regular basis. Since our users' current needs demand more and more of a push towards Windows 8 and 8.1, it would be nice to know that the security features we rely on are working as expected as we move towards those operating systems.

The TPM and the secure boot along with AD for Bitlocker will make sure any lost mobile machine is safe.

Any such machine could be refurbished, but the data would be secure.

Hi,

I made an amount of research about this problem. Untill now, I doubt this is maybe Windows 8 problem not Windows 8.1.

Firstly, you can try to turn off the policy you mentioned, then encrypt Windows 8 system for test.

If problem persists, it would be better to provide the detailed error message of this problem. A screenshot would be better.

Hi,

I made a deep research about this problem today. Here is some new updates below:

According to the library: http://technet.microsoft.com/en-us/library/dd875529(v=ws.10).aspx

You should also configure AD DS before configuring BitLocker on client computers. If BitLocker is enabled first, recovery information for those computers will not be automatically added to AD DS.  If necessary, recovery information can be backed up to AD DS after BitLocker has been enabled by using either the Manage-bde command-line tool or the BitLocker Windows Management Instrumentation (WMI) provider.

That's to say, If you never initialize the TPM of Windows 8 before, but Windows 8.1 machine did. When you use TPM first time in Domain Environment, the Windows 8 machine may encounter the problem like initialization failed, but Windows 8.1 would works properly.

To verify our inference, you can try to run the command like manage-bde -protectors -adbackup c: -id {xxxx,xxxx,xxxx,xxxxx} at Windows 8.1 to backup Recovery information to AD to check if it works fine.

Here is another blog which further talking about how to backup recovery information in AD after BitLocker is turned ON in Windows 7. I guess this article would be helpful with your problem:

http://blogs.technet.com/b/askcore/archive/2010/04/06/how-to-backup-recovery-information-in-ad-after-bitlocker-is-turned-on-in-windows-7.aspx

In addition, We need to know that TPM recovery information is backed up when you:
1. Set the TPM owner password during TPM initialization.

2. Change the TPM owner password.

Therefore, please check your situation if it similar with the pheonmenon above, if not, please feel free let us know.