Invested Development » Tools

Enabling BitLocker in Windows 7

stuartthompson — Fri, 06 May 2011 21:25:54 +0000

BitLocker provides full disk encryption. With mounting concerns around identity theft and corporate data security it is more important than ever that everyone take steps to ensure the data stored on their personal computers is kept secure.

The following step by step instructions can be used to enable BitLocker drive encryption on a machine running Windows 7.

Disclaimer: These instructions are provided AS IS without implied warranty of any kind. USE AT YOUR OWN RISK. I will not provide support and by reading this post or using these instructions you agree that I am in no way responsible for loss of data or any other losses that result from your usage of the information contained in this post.

Step 1 – Configure Local Group Policy
BitLocker uses local group policy settings to configure its behavior. These settings must be initialized prior to running BitLocker.

Step 1.1 – Open the Local Group Policy Snapin
Click Start and in the run box type gpedit.msc

Step 1.2 – Navigate to the correct node in the group policy editor
Navigate to:
Local Group Policy –> Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives

There are four settings groups that need to be configured here. Open each window in turn as specified in the following four steps. To open a settings group double-click the setting in the list.

Step 1.3 – Require additional authentication at startup
Configure BitLocker to require a startup PIN with TPM (Trusted Platform Module). This setting means that BitLocker will require the user to enter a PIN when the computer is first powered on.

Click Apply and OK to close the settings window.

Step 1.4 – Allow enhanced PINs for startup
Enhanced PINs allow for the use of a more diverse set of characters. Select "Enabled"

Click Apply and OK to close the settings window.

Step 1.5 – Configure minimum PIN length for startup
The next settings group provides a minimum PIN length to be specified.

Click Apply and OK to close the settings window.

Step 1.6 – Chose how BitLocker-protected operating system drives can be recovered
Specify the mechanisms through which a BitLocker protected drive can be recovered.

Click Apply and OK to close the settings window.

Step 1.7 – Verify that all four settings groups are shown as Enabled
THIS IS IMPORTANT! Ensure that the settings groups are enabled correctly. Once the BitLocker process begins these settings will be used without further confirmation.

Close the Local Group Policy Editor window

Step 2 – Enable BitLocker Drive Encryption
Now that the local group policy has been configured the system is ready for BitLocker drive encryption.

This set of steps proceeds through a series of dialogs, each of which are explained below.

Step 2.1 – Turn on BitLocker
Turn on BitLocker by right-clicking your operating system drive and select Turn on Bitlocker…

Step 2.2 – BitLocker initializes the drive
Wait until the initialization is complete.

Step 2.3 – Prepare your drive for BitLocker

Click the Next button to prepare your drive.

Step 2.4 – Continue preparing your drive

Click the Next button again to continue

Step 2.5 – Encrypt the drive

Click Next to initiate the drive encryption process.

Step 2.6 – Require a PIN at every startup

Click on the Require a PIN at every startup option.

Step 2.7 – Enter a startup PIN
Choose a PIN that will be required at every startup. It is recommended that this is a mixture of characters and numbers that is easy to remember and is different from your username and domain password. This PIN should not be a number of phrase that is printed on the case of the computer. Service tags are not appropriate PINs.

Click the Set PIN button to proceed.

Step 2.8 – Insert a USB thumb-drive into your laptop
This will be used to store your recovery key.

Step 2.9 – Save the recovery key to a USB flash drive

Click the Save the recovery key to a USB flash drive option.

Step 2.10 – Save the recovery key to the thumb drive
A dialog is shown listing the USB devices connected to the system. The thumb drive inserted in step 2.8 should be listed and selected.

Click the Save button to save the recovery key.

Step 2.11 – Proceed to next step
Click the Next button to proceed.

Step 2.12 – Run BitLocker system check
Ensure that the Run BitLocker system check box is checked.

Click the Continue button to proceed.

Step 2.13 – Restart computer
BitLocker will now perform a system check prior to encrypting drive contents.

Part of this check involves restarting the computer to ensure that the user enters their PIN correctly and that the TPM key can be unsealed using that PIN.

Click the Restart now button to proceed.

Step 2.14 – Enter PIN
Enter the PIN used for this computer.

Step 2.15 – Encryption in progress
After the machine is booted up, note that drive encryption is in progress.

Step 2.16 – Wait for Drive Encryption to Complete

Click Close to finish.

Congratulations! Your drive is now encrypted with BitLocker using a TPM and PIN.

Changing Visual Studio Registration Information

stuartthompson — Wed, 17 Mar 2010 20:58:53 +0000

This morning as I started Visual Studio it bugged me that the splash screen reported my registration information as “User” at “Microsoft”. My name isn’t “User” and I don’t work for “Microsoft”, at least not directly. This is something that has bothered me in the past but I’ve never dug into it far enough to figure out how to fix it.

This afternoon after a little research I was able to piece together the steps necessary to update the information. I found this question on Stack Overflow that had some useful information but not a complete solution. I also came across this post on John Robbins’ blog and between the two of them I was able to close the gap.

Updating Company Name and User for Windows
The first step is to open the registry editor and navigate to:

32 bit: HKLM\Software\Microsoft\Windows NT\CurrentVersion
64 bit: HKLM\Software\Wow6432Node\Microsoft\WindowsNT\CurrentVersion

Here you can edit the RegisteredOrganization and RegisteredOwner values.

Updating Visual Studio User Registry Key
The next step is to update the user name for your Visual Studio registration. This is also a key in the registry at:

32 bit: HKLM\Software\Microsoft\VisualStudio\9.0\Registration
64 bit: HKLM\Software\Wow6432Node\Microsoft\VisualStudio\9.0\Registration

Getting Visual Studio to Use the New Information
Modifying the keys is the first step. However, it turns out that Visual Studio actually stores the information to be displayed in a SplashInfo key. The info is stored in binary data. Fortunately we do not need to modify the binary value in the registry. Instead simply run devenv /setup and the information will be updated automatically.

Verifying the Information
To verify that the information was updated correctly you can either view the SplashInfo key in the registry or simply run Visual Studio. I’m now “Stuart Thompson” at “SoftSource Consulting”. Much better!

Disclaimer
This process worked for me. Your mileage may vary. This information is provided as is without any implied warranty of fitness for any purpose. I am not responsible for corrupted Visual Studio installations or registry hives nor for any other problems that may arise as a result of using these steps. USE AT YOUR OWN RISK.

NDoc Shadow Cache – UnauthorizedAccessException

stuartthompson — Tue, 05 Jun 2007 16:20:01 +0000

I ran into an interesting issue yesterday while adding log4net to a project that was using NDoc as part of its build process. The project is using Team System for both source control and builds, and is using NDoc 2 Alpha 3 to generate code documentation files as part of the build. A common tools folder exists as part of the source control tree that is copied to the build server during the build process and used as a reference point for common libraries throughout the solution. This approach has been successful for me in the past because it means that the hint paths for references can point to a common known location and avoid common path issues to referenced libraries. However, shortly after checking in the log4net library to the tools folder and referencing it from several projects, I received the following build failure notification:

It appeared that the log4net library was locked and was causing NDoc to fail. After a little investigation, I found that the log4net dll was marked as read-only (because it had been added to source control) and experimented to see if that was part of the problem. Sure enough, on my local machine, if I changed the file to not be read-only then NDoc would build the documentation successfully. However, this didn’t solve the problem for the build process as the files on the build server are purged and freshly checked out prior to each build. The read-only log4net.dll would be copied down to the build server upon each build with the read-only flag set and the build would fail. The first, and more distasteful solution, was to add a build step prior to generating documentation to modify the attributes of the file to ensure that it was not read-only. However, more investigation led me to learn about the NDoc shadow cache. I found the information on Kiwidude’s blog here.

It turns out that NDoc is copying the referenced libraries to a separate shadow cache before interrogating them to build the documentation. This is to avoid, of all things, access permission problems that might arise from NDoc attempting to read a locked file. However, when NDoc goes to delete this shadow cache, it fails to note that some of the copied files might be read-only; the case with our log4net.dll. The System.UnauthorizedAccessException is being generated when NDoc tries to delete the read-only file from the shadow cache. Thanks to Kiwidude’s blog, I was now aware of an option to disable the shadow cache and force NDoc to simply read the files in place. Opening up the NDoc GUI, I loaded our .ndoc project and immediately saw the UseAssemblyShadowCache option:

This actually manifests itself in the project file as the following:

After changing this option, NDoc was able to compile the documentation without error and checking in the change fixed the build. I am presuming that the beta version of NDoc 2.0 will check the attributes on files that were copied to the shadow-cache to avoid this kind of problem, but for now this fixes it.