Adding a Data Recovery Agent to Group Policy in Windows

Barry (aka Fishbreakfast) came to me with an issue last week when I exclaimed:

I’m bored!

First off, don’t say you’re bored in the vicinity of the people who either a) are your boss or b) have more stuff to do than you do because you invariably come away with more stuff on your plate.

Anyway, the issue he had was that he had used Windows’ built-in Encrypting File System function to encrypt a few sensitive files. He got a new laptop, but didn’t either decrypt the files before transferring to the new laptop.

I can’t really blame him for that, though. Our assumption was that a Data Recovery Agent (RA) was enabled on our domain. Upon further investigation, we discovered that an RA, in fact, was *not* setup on the domain.

So, because I was bored, and because it is an interesting issue to look up, I hacked away at the problem until I could say definitively that Barry’s files could be decrypted.  Or the files were toast.

We have an Enterprise Certificate Authority installed into our Domain, so EFS/Recovery certificates are very easy to come by. What isn’t quite so obvious is how to include the RA certificate into the Group Policy that applies to particular domain computers. (You can read more about the whole process here.)

Okay, so the Group Policy setting that effects EFS Data Recovery can be found here: Computer Configuration -> Windows Settings -> Public Key Policies -> Encrypting File System. Right-click on that “folder” and choose Create Data Recovery Agent. This uses the automatic enrollment methods to request an EFS Recovery Certificate, and then apply it to the Personal Certificate store on the local computer, as well as upload it into the definition of the Group Policy Object.

Easy peasy, eh? A couple of caveats.

The only place the private key is stored (the private key being the part of the PKI cert that is required to actually recover any data) is on the computer where you requested the certificate. So be sure to export the newly created EFS Recovery certificate (including the private key) to a safe and secure backup location so that you can perform data recovery from somewhere else.

Also, the RA certificate is useful only if the group policy is applied *before* you encrypt any files. It’s worth noting, too that this only applies to Active Directory member computers. The process for setting up an RA is quite different for standalone machines.

So, back to Barry’s files? Given the above, they are definitely toast. Unless he’s got an army of PlayStation 3 consoles he could use to brute-force decrypt the files.

We now return you to your regularly-scheduled, non-geeky programming.

Shrink a Windows System Partition using VMWare Converter

As part of our license for VMWare’s Virtual Center Management Server, we get a copy of the VMWare Converter, Enterprise Edition, which allows trivial migration of any Windows physical host to virtual hardware. Additionally, the Converter can…well…convert from other virtual machine formats, including other VMWare products.

An interesting side-effect of this is that you can re-size your VMDKs (virtual disk image “files”). SAN space is expensive, so when we were looking to deploy some new VMs in our test environment, and noting that they only took up maybe 15% of the allocated disk space for them, it occurred to me that we could “clone” them by using the Converter, and simultaneously shrink them.

Normally this is something that you could do with ESX’s vmkfstools command-line utility, which allows you to shrink or grow these virtual disks. Unfortunately, Windows will sometimes complain when you try to resize the system/boot partition.

Here’s what it looks like:

Notice the “New Disk Space” drop-down; a 20GB VMDK, after conversion, will now be only 10GB! By choosing the same Virtual Center installation as the source and destination, you can effectively and conveniently resize your system partition. Don’t forget to remove the “old” VM (the source in this case), otherwise you’re not really saving any disk space!

Welcome to Sparta…may I take your cloak?

Boyfriend and I saw the “300″ today. Just in case you’re living under a bridge or pretending to be homeless, it’s a movie based on Frank Miller’s graphic novel about the Battle of Thermopylae, where King Leonidas and 300 warriors fight to the death to defend Greece from the Persion army.

The movie was quite satisfying, I’d have to admit, with only one part that seemed over-long. But I won’t go into more details. If you are at all interested in grisly graphic novel adaptations of legendary events, this movie is a must-see!

One thing that struck me was that this legend/story/myth is nearly three thousand years old, and we are still telling/watching it! It’s truly humbling and amazing to me.

What stories, do you think, people three thousand years from now will be telling?

Nike + Autobots = GEEK ALERT!

I know of one person who would be so geeked out over this he would probably blog about it incessantly and then try to sell one to all of his friends and co-workers.

Kurt! I’m talking about you! Oh wait…you haven’t blogged about anything since the Stone Age (also known as Fall 2006).

Hello? I want to read about this on your blog (via Kotaku)!

Clone your Active Directory in 12 minutes using VMWare

Anyone out there who runs a successful Microsoft Windows Active Directory, knows that it is pre-eminently useful to have a test environment that very nearly represents your production environment…to do…you know…testing!

I went to a VMWare Disaster Recovery seminar and one of the presenters described how easy it was for them to use and create a test environment by simply taking one of their existing, virtualized Domain Controllers, cloning it, attaching it to a private network, and off you go.

I thought I would give that a try, and here’s what I came up with.

1. Shutdown and clone a Virtual Domain Controller with a 20GB disk drive, 4.5 minutes.
2. Power-on and attach the virtual DC to a totally private network, visible only to other virtual machines on the same box, 15 seconds.
3. Install DNS on the Domain Controller to allow for dynamic updates within the private network, 3 minutes.
4. Seizing FSMO roles from Domain Controllers that aren’t in this private network, 3 minutes.
5. Sit back in wonder, 45 seconds.

These simple steps aren’t completely error free. Because the DC I chose was a replication partner with a bunch of other DCs and Active Directory Sites, it was necessary to do some tweaking to remove the “defunct” Domain Controller properties from the Active Directory. That process is documented well, here: Remove old Domain Controller Settings from FRS and the Domain.

Also, step 4 isn’t immediately obvious since most Domain Administrators would be familiar with the GUI-mode way of transferring FSMO ownership. That transfer, though, requires that the current FSMO owner be online to accede the role. Which brings us to this article: How to forcibly transfer (or seize) FSMO Roles from one DC to another from Daniel Petri (a really great resource for Windows administrators, IMO).

There you have it, folks. How to clone your Microsoft Active Directory Domain Services using VMWare in less than 12 minutes!