Windows 10 BitLocker

I normally focus on troubleshooting with my blog posts, but this one is an exception. I wrote up a section for course manual on BitLocker in Windows 10 that includes a couple of short activities enabling BitLocker. However, I'm concerned that that activities could take an extended period of time. So, this blog post is providing screenshots of what those activities look like.

Before I start with the steps, I was pleasantly surprised that I was easily able to get BitLocker going in a VM without doing anything goofy. Once upon a time, to get BitLocker going, we needed to use a virtual floppy to store the startup key. There is now an option to use a password instead. I haven't looked at this in a while and this is probably not a new option. I'm going to guess that Windows 8.1 at least probably had the same.

There are three nice things about a startup password for BitLocker:

• You don't need a TPM in your computer to make it work. Many computers don't have a TPM so that requirement is a deal breaker for many people.
• You don't need a USB key to startup. Before, the alternative to a TPM was a USB key with the startup key. The idea that I needed to keep a USB key with my laptop seemed inherently fragile.
• The behavior mimics what other drive encryption products do. Many other full drive encryption products require a password to startup the system. Users that are used to this process like to continue using it.

With no further ado, here are the screenshots...

Enabling BitLocker in Windows 10

Turn on Bitlocker

Select an unlock method

Enter the password to unlock the drive

Save the key to a location that is not the drive being encrypted.

In my VM, I printed using the built in PDF printer since the VM only had the C: drive.

I'm not planning to access this drive from anything but Windows 10 build 1511 or later. So, new encryption mode was good.

Click Continue to make it so.

After a reboot, enter the password to startup

Check encryption status with manage-bde.exe

Testing BitLocker Recovery with a Recovery Key

On the BitLocker startup screen press Esc to access BitLocker recovery

Enter the recovery key from the PDF (you printed that before you got to this point right?)

Once you're in you can change the password or turn off BitLocker

Missing "How will this person sign in?"

Normally when you create a user account in Windows 10, the first thing asked is How will this person sign in?" This identifies whether  the account is a local account or a Microsoft account. Today as I was developing some course material for user accounts in Windows 10, this screen was missing from my laptop. Instead, it went directly in to asking for account information for a local user account.

After much searching around, I finally figured out that my laptop had no network connectivity. I had just installed a Windows Insider build and the new build killed WiFi on my laptop. Once the WiFi connectivity was restored the new account wizard behaved as expected.

I expect you would see the same behaviour in Windows 8.1 when disconnected from the network.

No Quotes Required for Paths with Spaces

I got a comment back from a technical editor today that I didn't need quotes around the path in a CD command at the command prompt. I was surprised because the path included spaces. However, after testing, it's true!

In the past I would have done:

cd "folder1\foldername with spaces"

However, this version (without quotes) works just as well:

cd folder1\foldername with spaces

Since it worked in Windows 10, I tried out Windows 8.1. It works in Windows 8.1 too. It's funny the little things you learn sometimes.

More on Secure Time for Windows 10

After doing some experimenting, I have determined the following about secure time in Windows 10:

• Secure time is updated when the computer goes to sleep or is shut down. This makes sense and I believe it is used to ensure that Windows has a reasonable time change and protect against irrational time sources. So, you want to compare time on startup against when it was last shut down.
• The registry keys use UTC time. When I read the time in SecureTimeEstimated and apply the correct time zone, then it matches the time the computer was put to sleep or shut down.
• SecureTimeEstimated seems to be the time of shutdown or going to sleep.
• SecureTimeHigh is one hour later than SecureTimeEstimated.
• SecureTimeLow is one hour earlier than SecureTimeEstimated.

To view these values yourself you can use the following PowerShell code:

[datetime]$(Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits).SecureTimeEstimated
[datetime]$(Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits).SecureTimeHigh
[datetime]$(Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits).SecureTimeLow

Please note that the times returned are 1600 years before the current date. So, even through the year may appear to be 0416, add 1600 to get the current year of 2016.

Previous info about secure time and the problems it can cause for imaging are here:

• http://byronwright.blogspot.ca/2016/03/windows-10-time-synchronization-and.html

Windows 10 - Time Synchronization and Imaging

Windows 10 has a new feature for time synchronization called secure time. The problem is that I haven't been able to find any documentation on it. What secure time seems to do is prevent significant time changes that are considered unreasonable. I believe it's new because there is no documentation at this time and because the registry keys for it don't exist in Windows 8.1, but do in Windows 10.

Here is the problem I ran into with secure time.....

As part of course development, we have a base image of Windows 10 with Office 2016 installed. We use this base as a starting point for differencing drives in course VMs, but this would also apply to an image you deploy to new workstations. This issue occurred even with just the base drive deployed.

When I had a VM using the base drive, it would run fine for about half an hour and then the time would reset back to December 3rd. This is approximately when the base drive was created. Time in the VM would then bounce back and forth between the proper time it obtained from the PDC and December 3rd. If you reboot, it would use proper time again for about half an hour and then the same issue would recur.

If you're reading this post because you have VM time synchronization problems in general, you should also check out this posting for some detailed information about how time synchronization works with Hyper-V:

• https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/11/19/time-synchronization-in-hyper-v/

Also, see here for how to enable debug logging for time synchronization:

• http://blogs.msdn.com/b/w32time/archive/2008/02/28/configuring-the-time-service-enabling-the-debug-log.aspx

I tried several things described in these articles:

• Manually configured time synchronization type to domhier.
• Manually configured the PDC as time source.
• Disabled the Hyper-V time synchronization in the guest OS of the VM.
• Configured the PDC to use BIOS clock as a time source instead of time.windows.com (which was unreachable in a isolated environment).

All the time I was doing these things I had debug logging enabled and watched the log. Time synchronization would be done in 1024 second intervals (about 17 minutes). After two synchronization intervals time would reset to December 3rd. Finally, I really paid attention to the message in the debug log:

Setting the system time because it is outside the secure time limits.
Current system time: 18:0:45.622 3/1/2016
Target system time: 19:4:54.231 12/3/2015

The key here is the reference to secure time which I didn't realize existed. However, as I browsed the registry keys for time synchronization at HKLM:\System\CurrentControlSet\Services\W32Time (I'd been reviewing these over and over), it clicked and I noticed the registry key SecureTimeLimits. In SecureTimeLimits were the following:

• SecureTimeConfidence
• SecureTimeEstimated
• SecureTimeHigh
• SecureTimeLow
• SecureTimeTickCount

The values for SecureTimeEstimated, SecureTimeHigh, and SecureTimeLow are all hex values. However, you can convert them to a date format. In my case, I used Windows Calculator to convert 0x1d12dfd7e79669e to decimal 130936430942316190. Then I used PowerShell to covert to a date:

[datetime]$STestimated=130936430942316190
$STestimated

This gave a date of December 3, 0415 7:04:54 PM. When time conversions are done, you need add 1600 to the year. So, this gave us December 3, 2015 7:04:54 PM. Exactly when the time was being reset to. Next question, how do we make it stop?

The key SecureTimeConfidence looks like a likely solution. The current value was 0x6. A quick Google search turned up only a single reference to this value:

• https://social.technet.microsoft.com/Forums/windows/en-US/891bc6c6-eaf6-49da-b4dc-c588c8944fe1/windows-10-conflicting-time-issue?forum=win10itprogeneral&prof=required

Two other people in this thread indicated that setting this value to zero resolved the same issue for them. Unfortunately I've not seen any documentation on this registry value at all and I've been unable to find any. Another installation of Windows 10 Eval that I'm using as a demo has a value of 0x7. My laptop which is upgraded from Windows 7 has a value of 0x8.

However, the important point, is that I can confirm that setting SecureTimeConfidence to a value of 0 resolved the issue in the VM. I believe this will be a required part of preparing Windows 10 images in the future.

UPDATE: There is now a KB article related to this as provided by an anonymous comment below: https://support.microsoft.com/en-us/kb/3160312

ANOTHER UPDATE (Sept 2016): There is another article describing "Secure Time Seeding". This article also indicates that the problem described above in this posting has been fixed in Windows 10 Anniversary Edition. Check it out for more details: https://blogs.msdn.microsoft.com/w32time/2016/09/28/secure-time-seeding-improving-time-keeping-in-windows/

Sysprep Error with Windows 10

I'm doing some experimentation with Windows 10 deployment and attempted to run Sysprep. When I ran it, I got the following error:

Sysprep was not able to validate your Windows installation. Review the log file at %WINDIR%\System32\Sysprep\Panther\setupact.log for details. After resolving the issue, use Sysprep to validate your installation again.

When I read the log file, I found this:

Package 9E2F88E3.Twitter_4.3.3.0_x86__wgeqdkkx372wm was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.

So, apparently the Twitter app that is included by default is causing my issue. I did some research and found references to other packages causing the same issue if Windows 10 communicates with the Internet. The VM I'm using does have Internet connectivity.

To remove the app, I ran the following command. Note that you can use wildcards in PackageName for Get-AppxPackage, such as *twitter*.

Get-AppxPackage PackageName | Remove-AppxPackage

When I ran Sysprep again, I got the same error, except this time it was Candy Crush instead of twitter. After removing Candy Crush in the same way, Sysprep ran fine.

I should note, that I never ran or started either of those applications. So, it seems that it may be a best practice for Windows 10 to prevent your base images from communicating on the Internet. After performing one Sysprep, I was able to run Sysprep additional times.

I think this may have to do with live tiles in the Start menu. Both Candy Crush and Twitter are listed in the Start menu.