Monthly Archives: April 2009

BCDEDIT – Boot Configuration Data Store Editor – Step by Step Instructions

So you’ve gotten into a Dual boot Scenario in Windows Vista, Server 2008, Windows 7 or Server 2008R2.

And you just discovered that there seems to be no easy way to edit the entries.   You can change some of your defaults with MSCONFIG and Delete entries.  If you’re fluent in WMI you can do a lot in that aspect.  Especially if you like Powershell which can navigate WMI as easily as it can navigate directories.

But just HOW do you edit those silly names?

In a Dual boot (or triple if you’re getting REALLY fancy on us) it gets more than a little confusing with all the entries called “Windows 7”

But it’s not difficult.  And it’s not a nightmare.  It’s actually on some levels VERY easy.  

You just need to be introduced to the utility.  Run from Command line.  Very powerful.   Incredibly effective. 

And your friend.

World.   Let me introduce you to BCDEDIT.  BCDEDIT say hello to the world.

Step one.  Start the Utility.

If you’re going to work with BCDEDIT, you need to run it with Administrative Privileges.  In a command prompt of course.  


BCDEDIT is actually a little daunting at first when you run the BCDEDIT /? to see what it can do.   It’s powerful.   Here is the output and what’s in store for you.


BCDEDIT – Boot Configuration Data Store Editor

The Bcdedit.exe command-line tool modifies the boot configuration data store.
The boot configuration data store contains boot configuration parameters and
controls how the operating system is booted. These parameters were previously
in the Boot.ini file (in BIOS-based operating systems) or in the nonvolatile
RAM entries (in Extensible Firmware Interface-based operating systems). You can
use Bcdedit.exe to add, delete, edit, and append entries in the boot
configuration data store.

For detailed command and option information, type bcdedit.exe /? <command>. For
example, to display detailed information about the /createstore command, type:

     bcdedit.exe /? /createstore

For an alphabetical list of topics in this help file, run "bcdedit /? TOPICS".

Commands that operate on a store
/createstore    Creates a new and empty boot configuration data store.
/export         Exports the contents of the system store to a file. This file
                can be used later to restore the state of the system store.
/import         Restores the state of the system store using a backup file
                created with the /export command.
/sysstore       Sets the system store device (only affects EFI systems, does
                not persist across reboots, and is only used in cases where
                the system store device is ambiguous).

Commands that operate on entries in a store
/copy           Makes copies of entries in the store.
/create         Creates new entries in the store.
/delete         Deletes entries from the store.
/mirror         Creates mirror of entries in the store.

Run bcdedit /? ID for information about identifiers used by these commands.

Commands that operate on entry options
/deletevalue    Deletes entry options from the store.
/set            Sets entry option values in the store.

Run bcdedit /? TYPES for a list of datatypes used by these commands.
Run bcdedit /? FORMATS for a list of valid data formats.

Commands that control output
/enum           Lists entries in the store.
/v              Command-line option that displays entry identifiers in full,
                rather than using names for well-known identifiers.
                Use /v by itself as a command to display entry identifiers
                in full for the ACTIVE type.

Running "bcdedit" by itself is equivalent to running "bcdedit /enum ACTIVE".

Commands that control the boot manager
/bootsequence   Sets the one-time boot sequence for the boot manager.
/default        Sets the default entry that the boot manager will use.
/displayorder   Sets the order in which the boot manager displays the
                multiboot menu.
/timeout        Sets the boot manager time-out value.
/toolsdisplayorder  Sets the order in which the boot manager displays
                    the tools menu.

Commands that control Emergency Management Services for a boot application
/bootems        Enables or disables Emergency Management Services
                for a boot application.
/ems            Enables or disables Emergency Management Services for an
                operating system entry.
/emssettings    Sets the global Emergency Management Services parameters.

Command that control debugging
/bootdebug      Enables or disables boot debugging for a boot application.
/dbgsettings    Sets the global debugger parameters.
/debug          Enables or disables kernel debugging for an operating system
/hypervisorsettings  Sets the hypervisor parameters.


“Oh my!” you eyes pop open as you wonder how you’ll ever put a leash on this beast.   But it’s not so scary.

Really there’s only a few options I’ve had to learn to work with to get the control I need.

Really.  That’s it.

BCDEDIT /COPY (To make copy of an entry to work it)

BCDEDIT /DELETE (To delete an Entry)

BCDEDIT /SET (To set information within an entry)

So how do we use them?  I’ll try and keep this as simple as can be.

First you run in that Command Prompt a BCDEDIT /V to see what entries you do have.


What you’re seeing is the equivalent to the old “BOOT.INI”  The top half marked “Windows Boot Manager” is similar to the old [boot loader] section

[boot loader]

The next section marked “Windows Boot Loader” is the equivalent to the individual lines you used to have under the [operating systems] entry in “BOOT.INI” like below

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect


So the basics. 

First off, we’re going to make a copy of an existing entry and work with that copy.

You’ll notice in each entry displayed by BCDEDIT is a line marked “identifier”.  Since we’re editing entries for bootable operating system, we’re going to copy a “Windows Boot Loader” entry.

The process is dead simple.   Execute a

BCDEDIT /COPY {SID} /D “Name of New Entry”

where the {SID} is the unique number to the right of the identifier line in the “Windows Boot Loader” entry you wish to copy and “Name of New Entry” is the description you wish to give that Entry.

Here’s an example


The line highlighted in WHITE is the {SID} for the Windows Boot Loader entry.

So to make a copy of that entry execute the following command

BCDEDIT /COPY {cc5ea394-dec9-11dd-9550-00166f474543} /D “MY NEW WINDOWS 7 ENTRY”

You’ll get the following result.  Yes I wasn’t very creative with my naming was I? :)


The new entry will be identified by the line highlighted in White above.   The end results can be viewed with a BCDEDIT /V command


The new entry is highlighted in White (Sorry, my command prompt may not be the prettiest environment in colours.  But it is incredibly powerful) ;)

Setting or edit changes, now that you understand where the {SID} is, is quite easy.

To change a value in this entry use the

BCDEDIT /SET {ID} <datatype> <value>

We’re going to change the “description” from “MY NEW WINDOWS 7 ENTRY” to something more useful like “WINDOWS 7 TEST”

BCEDIT /SET {cc5ea39d-dec9-11dd-9550-00166f474543} description “WINDOWS 7 TEST”

You will find the entry is now changed.  As can be seen below


IF you wish delete this entire “Windows Boot Loader” entry just execute a


Like so…

BCDEDIT /DELETE {cc5ea39d-dec9-11dd-9550-00166f474543}

and if you run a BCDEDIT /V you’ll find the list is now missing the new entry since we have deleted it.


And now all your work is gone. (or done depending on how you view it)   Personally I prefer to use MSCONFIG to delete the entry.  Somehow feels a little safer.

But I’m hoping this takes a LITTLE mystery out of the BCDEDIT command.  There’s a LOT more you can do with this.   Next blog post I’ll show you how to make a change to Add in a bootable VHD file.  Or at least to tell that one is there :)

The Energized Tech


Installing Windows 7 or Server 2008R2 off of a VHD

My challenge handed to me was to learn how to get the new Windows 7 to boot from a VHD.

My head spun about on all the hows and whys and wherefores.

There were theory’s on using Virtual PC’s to create the drive.

In some ways it was quite vague.

But after digging all over online, I found the best resource was from a site I like to follow called “The Lazy Admin”

This excellent article written by Rodney Buike broke it right down to the what did and didn’t work.  Which helped me understand the process where I was missing pieces.

Let’s break down what the VHD boot isn’t.

It is NOT a Virtual PC or a Virtual O/S.   Although a Hyper-V VHD might work in this scenario, it is the Virtual File system part of the VHD that is more important.  This is a hardware dependant install of Windows 7 or Server 2008R2 installed within a Virtual Hard Drive. 

Although in THEORY a Sysprep might strip out the hardware components to bring that VHD onto a new machine.  But that’s a different blog post for a different time.

What is the difference between this and a Virtual PC?

The Drivers.

This install uses the ACTUAL drivers from the board.  There is no abstraction between the hardware and operating system.   No Emulation.  No Hypervisor required.

this Means it will perform so close to being on the regular file system you won’t care.

This means when I installed Windows 7 into my VHD I actually had to get my Video driver from Nvidia, the Sound card driver from SoundMax working.

The advantage to using THIS as a Dual Boot scenario I could immediately see.

No repartitioning.  No stretching or resizing of drivers.   No wasted space because you allocated an extra 20 gig to play with just in case.

After all, being a VHD you can make it a 20 gig Dynamic VHD, and unless it uses that space it can be as small as you like.

So what is the process?

Pretty simple.

Whether you are using Server 2008R2 or Windows 7.


You boot up from the install Media. 


Select the Repair Your Computer option.  

Choose the Command Prompt from the Repair Console.


using the DISKPART.EXE in the console create a blank Virtual Hard Drive and Attach IT

in the following example, a twenty gigabyte Virtual Hard Drive called Win7.VHD has been created and stored in a folder called C:\VIRTUAL in this example.

Picture1 After finishing this process the Command Prompt and Repair Console are closed down by closing “X” on each one.

Install Is chosen and the normal installation process continues.   you now simply choose the newly attached unprepared 20 gigabyte hard Drive and install as normal.

Once the install completes you will have a NEW CLEAN Windows7 (or Server 2008R2, depending on what media you used) inside the VHD file.  Windows 7 upon bootup will give you two choices, both will be named Windows 7 (as the O/S uses that as a default).   You will need to install the necessary drivers.

Next time we’ll explain how to use BCDEDIT to add/copy, set and delete boot entries to name the entries to something a little more correct or remove them when we’re done.


The Energized Tech


Microsoft Techdays Canada 2009!

It’s not tomorrow.  It’s note even in a few weeks.

But it’s happening.

The planning has ALREADY begun.

Microsoft Techdays 2009 is in the works.

Keep your eyes on

Also watch, and various other sites run by user groups and enthusiasts across Canada for further details.

What is it?  I can’t tell you what it isn’t.

It isn’t a waste of time.

It’s a cost effective chance for people to get training they normally can’t.   A large 2 days smorgasbord of topics for IT professionals, Managers and Developers.

It’s for everybody.

Check out for details regarding last year, and forums and online posts regarding other’s experiences for Techdays.

I can tell you that I personally, out of pocket, paid for Techdays 2008.  I couldn’t afford it.

But I also couldn’t afford NOT to.

And there wasn’t ONE session I walked out that didn’t give me at LEAST a nugget of knowledge I wasn’t able to use in the last six months.

So drop that thought in your hat.  Keep it there.  When there is more information available to the public that I hear about Techdays I will echo it to you.   Dates are projected as early as September 2009 in Toronto.

Come let it all hang out.
A day for you and me wrapped in Technology

It’s early but watch for it happening

Microsoft Techdays 2009

The best bang for the buck in Canada of intense training.



Today I was out the door early today.  5:15am out the door to get to Microsoft Mississauga.   For an “Install Fest”.

Initially I was signed up as a participant.

But this turned out to be far more interesting.   I got to help.

And I found this was far more energizing than anything I had ever encountered.  I was one of a team of “Proctors”, people there to help Microsoft help others installing Windows 7 Beta on their computers.

I don’t know the official count but I saw people of all walks of life enter in with PC’s and laptops just to get a chance to tryout a Beta copy of the new Windows 7!

Running about left right, handing out media, answer questions, helping troubleshoot, working and helping to keep the flow smooth.

I loved it!

I’m not surprised that I loved it but this was better than Energize IT 2008 on so many levels.  And to imagine this was echoed across Canada.   In different areas.    Microsoft and the Community hand in hand.

And for it to be a chance to touch base with other IT Professional and Developers again.  Friends, colleagues, peers.

To see an idea offered up by Microsoft to the crowd and see SO MANY react positively to it.

The room with so many Beta fish not fighting :)

Windows 7 is the successor to Windows Vista.   It’s in Beta.

It’s going to be an exciting day when it’s released!


Switching a Windows Deployment Server to a New Domain

Well folks.  Here’s a "What If"
"What if" you had a perfectly running Windows Deployment Server under Server 2008 and let’s just say, oh I don’t know, it lost it’s Domain.  It’s connection.  The original Domain was dead, not reachable, kaput.
Or in MY case you had to switch a Windows Deployment Server onto a new domain but had no "nice way" to do it.
In both cases you have a small problem.   For Windows Deployment Services to actually "work" it NEEDS a Domain.  There is an object it creates in Active Directory and it uses Active Directory, you know for silly little things like RESTRICTING who can mess with it.   Funny thing about a Deployment Server, is that it just DEPLOYS things like complete OPERATING SYSTEMS and SERVERS which are really good at wiping out things like, OTHER operating systems and Servers.
So for this reason, you need some security around it.
But in our case, we need to switch it to a new Domain.  The original one is gone for whatever reason.  You have admin rights on the box.   So what do you do?
Suprisingly it’s VERY easy to fix.
Step one.  Switch to Workgroup.
Step two.  Switch to New Domain.
"I KNOW I KNOW!!!" you may pipe up excitedly "STEP THREE!  START IT UP! YEAH!"
Bzzzzzt.  Wrong.  CLOSE but wrong.  So wrong.
You see if you TRY that, our Windows Deployment SERVICE will stubbornly keep shutting down.  You’ll also get an error in the EventViewer to the effect of
"An error occurred while trying to tstart the Windows Deployment Services server."
Error Information 0x13
Oh THAT’s just helpful and cryptic isn’t it?
But there’s a good and simple reason for that.
Did I mention that Object in "Active Directory".  Just where do you think it came from, the Tooth Fairy?
You need to put that information back into Active Directory.   But that’s actually quite easy.
You can reference this link from Microsoft regarding our helpful little error code poking it’s head out of EventViewer Will give you EXACTLY the answer you need
First off, if you know where the "Remote install folder was" it’s quite easy.  Usually it’s a folder at the root of C: called "RemoteInstall".   If you can’t find it look for a folder with a similiar structure to this

So if they WERE under C:\RemoteInstall Here’s your commands to run in that wonderful command prompt.

Start up a Command Prompt with Administrative rights and execute the following
wdsutil /uninitialize-server
wdsutil /initialize-server /reminst:C:\RemoteInstall
Then of course there is one other piece of minor nastiness.  If you had the workstations going to a Default OU you’ll have to (Under the Windows Deployment Server properties for "Directory Services" pick a new location)
When you’re done you can start up the Windows Deployment Service and you should be back in business.
How about that. 
That wasn’t so bad?  Was it?
The Energized Tech