I think I found that method.
Run `gpedit.msc`. Navigate to:
Computer Policy > Administrative Templates > Windows Components > Bitlocker Drive Encryption > Operating System Drives
Allow Secure Boot for integrity validation
Use enhanced Boot Configuration Data validation profile
Why wouldn't you just put bitlocker, anti-virus, secure boot, UAC, ...etc under one menu called 'Comp. Security'.
Your suggestion is akin to putting every RHEL/SLED/Ubuntu security setting into one flat configuration file. IPSec, Sudo (and gksudo and friends), anti-virus, cryptfs, apparmor / selinux, ufw / iptables, package signing requirements (including repositories to use), etc.
Something like that would never happen even if Red Hat did control all of the pieces of the puzzle. Now contrast Linux versus Windows here: if you want to configure those things you have to discover the tools or file formats for each security layer configuration manually, versus going into "gpedit.msc" and having categorized settings for the whole OS.
Still makes no sense.
BitLocker, although it can be used to encrypt external/data volumes, is primarily a technology for encrypting the boot volume and then storing the encryption key in the TPM chip. That encryption key can itself be encrypted using some combination of a passphrase, a biometric signature, and a smart card, which must be presented at startup.
In the TPM chip, along with the boot-volume encryption key, there is stored a manifest of SHA signatures for important OS files (specifically, the kernel and drivers required to bring up policy-based security like ACLs and domain authentication.) This manifest is signed by that same encryption key. Thus, the bootstrap loader, having retrieved the credentials necessary to make use of the TPM, can then verify the manifest with the key, and then use the manifest to verify that the OS it's going to boot into can be trusted, and will continue to protect the security of the files stored on the drive when control is passed to it.
This whole setup basically means that there's no way to get data off a BitLocker+Secure Boot computer without it allowing it (or, in limited cases, doing tricks with sticking RAM chips in liquid nitrogen.) If you didn't have BitLocker, you could just read the data "at rest"; if you didn't have Secure Boot, you could just install a rootkit and grab the data "in motion."
 Really, I think the only reason the two technologies (BitLocker and Secure Boot) ended up with different names is that they were supposed to be two subfeatures of one initiative -- Microsoft Palladium or http://en.wikipedia.org/wiki/Next-Generation_Secure_Computin... -- but that initiative was shelved (likely due to the huge public backlash), leaving just these few practical remnants behind. (It's pretty obvious that the BitLocker Settings panel was originally the Palladium Settings panel; it's where you go to reset TPM keys et al.)
MS hides things in GPO or registry settings when it wants to alleviate the concerns of network administrators while still managing to infuriate the end users who have no business touching 'their' operating system.
And that's, of course, absolutely intuitive.
In the most user-hostile move ever, I wanted to disable the "automatic restart in 15 minutes" thing on Windows 8 (Home). It required adding a registry key(!) I hope there's an easier way that I just somehow missed...
Really, really, horrible experience.
During the beta phase, they had mentioned that updates wouldn't do that, that they would auto apply the next time you rebooted.
I really think that all they should do is display a message that says, "New security updates have been installed. To ensure your computer is secure, please reboot your computer."
The problem Microsoft is balancing against is people who never ever reboot their computers no matter what--and thus never update, and become infection vectors. They have to force these people to update against their will to ensure the digital equivalent of herd immunity. And it's really quite hard to tell whether the user trying to "permanently" dismiss the "REBOOT NOW GOSH DARNIT" popup really has something urgent they're doing, or is just a "power user" who thinks they know better than the computer.
Not that I'm apologizing it's behavior - it was a design decision that Windows team made in the past, when it was deemed not important and worth reduction in complexity. Now just it comes and bites them back.
Not exactly. Its up to the application which opens files to control whether the file can be modified externally. It can do this in two ways. (1) Open the file in some FILE_SHARE_* mode and let the OS sort it out. (2) use opportunistic locks that will detect external access and then let the app decide how to react - anti-virus programs use this when they are scanning files.
>That's the cause of most reboots, it will replace them before services or apps that use them start again.
Actually the cause for reboots is much more mundane. Files replaced on disks means new programs using those files get the new version, however, processes which are already running keep using the older version in memory and are thus open to being exploited by bugs that are already patched.
On servers, things are a bit different. To prevent downtime you can 'hotpatch' the update and thus avoid the reboot.
You can perform hot updates to a system but it can be complex and there are a number of restrictions on the types of updates that can be done.
This is really frustrating.