Missing BitLocker Recovery Tab ADUC in Windows 7

I spent hours looking for a solution.  I was missing the BitLocker Recovery Tab in Active Directory Users and Computers (ADUC) on Windows 7.  Honestly, there are a lot of posts about this…but almost all of them detail how to do things in Windows Server 2008 and Windows 7 is nowhere to be found.  Of course, I tried to use them for Windows 7…but nothing worked.

The problem:  I was missing the BitLocker tab that displays the BitLocker recovery key for Active Directory Users and Computers.  No amount of DLL re-registering or Remote Server Administration Toolkit (RSAT) installing (those 2 are solutions in Server 2008) helped me display that tab.

When I finally did solve this problem, I found I was very close the entire time…and it was simple.  As the saying goes, that only counts in horseshoes and hand grenades.  I found the simple solution by my non-Sherlock Holmes power of deduction….I knew BitLocker was a part of RSAT from Microsoft and so I figured that viewing the tab might be a feature add-on…and my suspicion was absolutely right.  Screenshots of everything for a visual representation of this solution below.

Note:  You must install Remote Server Administration Tools (RSAT) for Windows 7 before the feature we need to enable will become available.  Install that first, then come back here and perform the following steps:

Windows-R to get run dialogue, type ‘appwiz.cpl’ and click ‘OK’
Click on “Turn Windows features on or off”
Find Remote Server Administration Tools and expand it
Expand ‘Feature Administration Tools’ and check the box on ‘BitLocker Password Recovery Viewer’

That’s it.  Now when you go inside ADUC, you’ll have a recovery key tab available on PC’s you’ve encrypted using BitLocker.  All that fuss and hunting for a solution that takes about 3 minutes to fix.  Simple right?  I sure hope that in publishing this, I make it more readily available and searchable for those looking for the solution in the future…because it sure took me a long time to find it!  Thanks for reading!

Dear Microsoft, Public Folders

Dear Microsoft,

Public Folders are way to hard to manage in Exchange 2007/2010.  Adding/Removing folders is a pain the neck; even if I’ve got the right permissions, I still don’t have the right permissions.  Please fix this immediately.

Yours Truly,


PS:  Do something about getting Local Continuous Replication (LCR) in 2010 too?  Thanks!

Security Group Membership without Powershell

I’m getting pretty used to powershell in my day to day workings with Exchange.  Today however, I was helping a user out on a PC in a different department and I needed to find all of the members of a specific security group.  Sure, I could remote back into my work PC and launch ADUC but I’d rather be able to query it with a single query…all from right there using her computer with the limited user account.

Thanks to powershell, I now think in pipes…while I’ve always done this with Linux, I’ve never had to do so with Windows.  It’s almost like wearing two caps at the same time.  Nonetheless, I was able to figure out how to do this after 3 or 4 attempts and then output it to a file so I could see members of the security group and I did so without the power of powershell (ba-dum-ching!)

I used dsquery and piped the command using dsget to grab the information I needed and then output that into a text file onto the desktop.  Important to note that you should open the command window using ‘run as’.  So in XP, browse to Start >> Programs >> Accessories and then right click ‘command prompt’ and ‘run as’ with elevated privileges.  You’ll need to be able to view the group you’re querying.  I used my own user since I’m a domain admin…you get the idea.  Once you have the command prompt, cd to Desktop so the text file will be easy to find.  Then initiate the following command:

dsquery group -name GroupName |dsget group -members |dsget user -display >memberlist.txt

Substitute for GroupName and put in the group you’re looking for.  Hopefully this helps out.

Microsoft Please, Smarter Not Harder

My grandfather always says to work “smarter and not harder” which is 1930’s speak for be more efficient.

Why couldn’t Microsoft have listened to him (and all the other grandpa’s of the world who say the same aphorism)?

I had a user come in the other day with a Windows Mobile HTC Touch Pro 2.  They wanted to hook up to EAS and have all the whiz bang features that my Palm Pre and all the whiz bang features that iPhones are able to have…synchronizing calendar, contacts, and email.  This user is by no means very technical.  They need a way to plug in their email address and server name and have it just work…much in the way that it does for the Palm Pre and iPhone.

The user dropped off the phone to me to handle this for them of course so I entered in all the information and went to connect it.  Promptly, I received the following message:

“your exchange server requires a personal certificate for authorization”

I anticipate this for some phones…on some phones you have to copy across a root certificate in order to have them connect to a SSL enabled CAS from the internet.  This would be my first phone that I’ve run across that didn’t automatically import the certificate.  Now, let me begin by saying this is probably one of the dumbest things I’ve ever heard of before (not automatically importing the certificate) because if you’re connecting to the exchange server and authenticating…you should trust whatever certificate is setup by your administrator automatically.  Locally here on our PC’s in the enterprise, we’ve automatically trusted the certificate from servers we can authenticate with passwords to.

As an example, if Microsoft treated their Domain Controllers in an AD Forest the same way…we’d be getting pop-ups anytime I regenerated a certificate on a DC.  We don’t get those because if a computer is authenticated and the server changes, we don’t want our users getting popups they can’t explain or understand.  We used group policy to silently negotiate the certificate exchange in the background.  We did the same for OWA when it is accessed internally.

But a smart phone running Windows Mobile?  Heck NO!  You have to manually copy the certificate over and import it manually…you’re not given the opportunity to authenticate and import automatically.  Nothing takes place in the background…even if you are ON THE DOMAIN.  The behavior gives you no other alternative.

I thought this would be fine…but it’s not.  There isn’t a way for me to get access to the filesystem of the phone.  I plug it in via USB.  It can’t install it because it can’t find drivers.  I use the software included with the phone and it wants to synchronize locally with Outlook…but the user that is using this phone DOESN’T HAVE OUTLOOK nor do they have their own PC, so why would they want to install software just to be able to get files onto their phone?  Why would I?

In this instance, this phone is locked down…which is fine in a corporate environment.  But this is a personal phone and there is no corporate Windows Mobile plan we have here.  I need it to be as easy as an iPhone.  I need it to be as easy as my Palm Pre.  I need to type in the information and have it connect and start working immediately.  It doesn’t.  Microsoft needs to work smarter and not harder on this.

I wasted 2 hours yesterday trying to get a certificate copied over to the device and I still can’t do it.  I pretty much gave up in frustration and figured I’d file an issue and see what someone can tell me…there comes a point though where security and usability collide in an awesome display of stupidity…and I think this is the case here.

I’m sure everyone is saying “You’re a dummy then!  It’s easy, you just perform action X and they Y and it works!”  and to that I ask that you leave a comment on how you get it working…remember, I can’t copy files to this device…it won’t let me.  So tell me how to get it done without copying files to the device or how to hack the device so I can copy files to it and I’ll agree with you by saying “yes, I am a dummy”.  Documentation on this problem and solution are non-existent…google and live were not my friends on this topic.  So please tell me how wrong I am…I want to be proved wrong and fix this.

In the meantime, please Microsoft, work smarter and NOT harder.  Making things this difficult to do simple things is dumb.  My boss doesn’t care about all the technical details.  She just knows that she took her iPhone in and I had it up and running in about 10 minutes.  And now she knows that one of her directors asked for the same functionality in a Windows Mobile phone and 2 hours later I told him I couldn’t get it to work.  Here it is 2 days later and I still can’t get it to work.  Making it so competitors systems work better on your own product is comparable to shooting yourself in the foot with a canon.

Moving Mailboxes from Exchange 2003 to Exchange 2007

During a migration from Exchange 2003 to Exchange 2007 many find that having 4 maximum thread transactions happening simultaneously is a bottleneck. Using powershell, one can increase the maximum number above 4 and save time and effort in the process.

During a migration from Exchange 2003 to Exchange 2007 many find that having 4 maximum thread transactions (default in using the Exchange Management Console) happening simultaneously is a bottleneck.  Using powershell, one can increase the maximum number above 4 and save time and effort in the process.

Some things to keep in mind during the migration:

  1. Tons of transaction logs will be generated and won’t be wiped until a backup happens…make sure you have space on your transaction log disks.
  2. Make sure your Mailbox Server has plenty of physical resources available to use during the move…RAM is a specific concern.  Always overshoot your estimates on how much RAM you need.
  3. Error reporting in the shell isn’t as intuitive as you’ll get using the EMC (Exchange Management Console)

My specific environment was moving from a single backend 2003 server to a single 2007 mailbox server.  The cmdlet that is posted can be used to move a mailbox database/storagegroup from one physical server to a another database/storagegroup on a different physical server.  I’ll go through what each section of the cmdlet means.

Get-Mailbox –Database “2003ServerName\StorageGroupName\DatabaseName” | Move-Mailbox –TargetDatabase “2007ServerName\StorageGroup\Database” –MaxThreads 10

The command above should be executed in powershell on your 2007 Mailbox Database Server.  The Get-Mailbox -Database command will tell Exchange where the mailboxes you are moving are coming from.   You then Move-Mailbox to a target database on the 2007 Mailbox Server.  The last portion of the command tells the command to increase the max threads of the command from 4 to 10.  Please make sure that you substitute in the server names, storage group names, and database names appropriately.

Remember that this will only move one database at a time…if you are like me, you like to take small steps in the process and verify that things look good after each small step.  Hopefully, this helps your migration take a little less time.

Creative Commons License
Except where otherwise noted, the content on this site is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.