Enabling bitlocker with Group Policy - startup script requires elevation

This is probably a better question to ask in the Microsoft TechNet forums, since this sounds like a Windows issue, not a Dell hardware issue.  The only thing that comes to mind for me would be verifying that the startup script is in fact running as the SYSTEM account.  To verify that, add a line like this to your PowerShell script:

Whoami | Out-File C:\ScriptUser.txt

thanks for reply the account is : autorite nt\système

Ok, in that case I don't know of any rights that would be denied to the SYSTEM account.  It isn't listed in any of the "Deny" options in Local Security Policy in a default Windows installation.  One option you could investigate would be to replace your WMI query and manage-bde commands with the native BitLocker PowerShell cmdlets as documented here: technet.microsoft.com/.../jj649829(v=wps.620).aspx

UPDATE: Well I ended up taking this project on more fully, initially just for the fun/challenge, and later because I found a client that could use an expanded version of what the OP initially asked about.  I also found out that error messages that mention the TPM are not always actually caused by the TPM.  I got TPM-related errors that turned out to be caused by having a bootable CD/DVD in my system's optical drive, and also when Group Policy wasn't configured properly for what I was trying to do in BitLocker.  See my post below for more on that, but I also found a way to export the "real" error in one of the scripts I've posted here.

The first script (AutoEnable-BitLocker.ps1) automatically enables BitLocker with the TPM protector, and is intended to be run as a startup script; I have successfully tested it on Win10 1709. If it encounters an error while trying to do this, it exports the error message to a text file on C.  The second script (Set-BitLockerPIN.ps1) can be ADDED to an environment that is using the first script.  It is primarily intended to force users to set a startup PIN after BitLocker has been enabled, but it will also pop up a warning to users if the AutoEnable-BitLocker script failed so that the user can do something about it or contact IT.  Note however that setting a startup PIN requires elevated privileges, so if the user isn't a local administrator on their system, they would need someone whose domain account IS a local admin to supply credentials at the elevation prompt.  Therefore the second script may not be desirable to deploy in an environment where users are not local admins.

Both scripts are attached here, and both include full documentation inside the scripts themselves, which I would strongly recommend that you read.  For example, automatically enabling BitLocker is only recommended if you the Group Policy settings in effect that specify backing up Recovery Keys to AD and preventing BitLocker from enabling if that isn't successful.  That's a great feature if you're not already using it, but if you won't be using that, then you should modify this script to export the generated 48-digit Recovery Password somewhere else, otherwise you could end up locking users out of their data.  And the Set-BitLockerPIN script requires loopback processing to be enabled in Group Policy if you want to scope the GPO to computer objects, as you would in most cases.

The extensions on the files below have to be changed from .TXT to .PS1.

[View:/cfs-file/__key/communityserver-discussions-components-files/3518/AutoEnable_2D00_BitLocker.txt:50:50]

[View:/cfs-file/__key/communityserver-discussions-components-files/3518/Set_2D00_BitLockerPIN.txt:50:50]

Ok, I eventually got an error about the TPM to trigger WITHOUT still starting BitLocker afterward, and I finally figured out what was causing it, at least in my case.  By sending the error message output from the Catch block of my script above out to a file, I saw that the REAL error is that BitLocker would not start because it detected that a CD/DVD was inserted.  The first time I started the PC with a CD/DVD inserted, my script threw that error, but I did not see the TPM error until the NEXT reboot.  When I then removed the CD/DVD and restarted, I saw the same TPM error popup again, but this time BitLocker actually started.  When I turned off BitLocker and tried again without having a CD/DVD inserted even at the beginning, BitLocker immediately started without any error messages.  So it looks like the way it works is that if you have a CD/DVD inserted, the TPM error popup will be displayed at the NEXT reboot, but if you've fixed the problem by that time, BitLocker will still enable.  It's very strange, but hopefully this helps you!

See update above.  I ended up building this out even more fully, so I've replaced most of my original longer post with a better script (and an additional script) and included more information.  Hopefully you find this useful!

thank you for spending time finding a solution, I really appreciate

we tested your script and other methods, the error "0×80070522 -> A required privilege is not held by the client" always appears when running with the startup script, but if you run the script manually, everything works fine...

Is that the error that you're seeing in the C:\BitLockerSetupError.txt file that AutoEnable-BitLocker generates?  Or are you seeing that error somewhere else?  Do you have other Group Policy settings active on the PCs you're testing with that might be affecting this?  If you haven't already, put a test system into an OU that has Block Inheritance enabled in Group Policy and then apply ONLY this startup script policy to it in order to see what happens, because as I said, I successfully tested this on Win10 1709, and since the original post I've tested it on multiple systems.

yes the error is only for adding protector key on tpm, we try all the commands:

Add-BitLockerKeyProtector -MountPoint "C:" –TpmProtector

Manage-bde -protectors -add c: -tpm

and also wmi

all point to the same error

believe me we tried everything .

our script works well on other models like the e5530 or e5570 -> tpm 1.2 and  tpm 2.0 for 5570

but does not work on an e5540 and 5580 with same config on bios, under Windows 1511  1703 and 1709

this make me crazy :)

Ah ok, you didn't mention that the exact same software configuration was working on other hardware models.  You just said you had several Dell systems on several versions of Windows 10 that were having a problem.  You did mention that you've had a startup script for a long time that did this, but you didn't provide any details about what system and OS configurations were working.  That would have been helpful information to provide at the beginning. :)

That said, I'm surprised a hardware difference could be causing a privilege error if the OS is otherwise configured identically.  If you're only testing with a corporate image, have you tried starting with a totally clean default Microsoft Win10 installation even before installing any drivers?  You wouldn't need any drivers to enable BitLocker or talk to the TPM, so just take a clean installation and join it to your AD domain so that it sees the startup script.