Getting the msdeploy.exe install path using powershell


I’ve been playing around with msdeploy and powershell lately, and one of the things I needed to find out is where the msdeploy.exe was located. After building a web deploy package, the associated batch file created by msdeploy uses a registry key to get the executables location.

Accessing the registry in powershell is super easy, so we may as well do the same thing. The key in question is: "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy" which we can access using a standard Get-ChildItem or gci for short.


I have both MSDeploy v1 and v2 installed, and it’s the latter one I want to get at so we can use a Select –Last 1 to choose it. We also want just the InstallPath property which is accessible via GetValue on the RegistryKey object.


Great! We can easily put this into a function and load it into our path using:

function Get-MSWebDeployInstallPath(){
     return (get-childitem "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy" | Select -last 1).GetValue("InstallPath")

function Load-Configuration
    $webDeploy = Get-MSWebDeployInstallPath
    $env:Path += (";" + $webDeploy)

You should be able to access msdeploy from your powershell script now…

Fully automated VHD install of Windows 8 Developer Preview using PowerShell


After reading Scotts excellent post:

…and subsequently noticing a smart chap saying something about an easier way in the comments:


I decided to go ahead and make this even easier since PowerShell is my new hammer I’m going to take advantage of it. The Creating a Bootable VHD guide does specify that there is a Microsoft PowerShell script which makes this easier, so there is method to my madness.

The relevant code has already been pushed to Github:

A direct download of the zip is:


You need to download and mount the ISO yourself. You can get it from here and I recommend Virtual Clone Drive as a free and lightweight mounting tool.

The script has three parameters:

  1. Full path and name of the VHD you would like to create.
  2. The maximum size of the image.
  3. The drive letter to assign the VDH to (must not be in use).

An example of using it is:

cd C:\projects\CreateWindows8VHD
C:\projects\CreateWindows8VHD> Import-Module .\Create-Windows8VHD.ps1
C:\projects\CreateWindows8VHD> Create-Windows8VHD "C:\vhd\windows8preview.vhd" "30000" "X"

Here’s an example of my output:


Following this to set up a dual boot record you can do (where driveletter is what you choose above).

C:\Windows\sysnative\bcdboot.exe driveletter:\Windows

You should now be able to restart into the Windows 8 Preview!

Feel free to submit pull requests and make suggestions.

Accessing BCDBoot.exe from PowerShell


This one was driving me crazy for a little while…

The term 'bcdboot' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or
if a path was included, verify that the path is correct and try again.
At line:1 char:8
+ bcdboot <<<<
    + CategoryInfo          : ObjectNotFound: (bcdboot:String) [], CommandNotFoundException

I wondered whether it was the case with all System32 binaries and security, so some Googling turned up:

So if you would like to access bcdboot from PowerShell, and for my current script I definitely do, then you can use:



Irritating, but a relief to find its possible. Happy hacking.

Scrum basics: Sprint planning meetings


When a developer starts work on a new piece of code or application for a hobby project, they generally have a rough idea of the design and how long its going to take. Scrum has taken a pragmatic approach and designed the sprint planning meeting to fit exactly that; a dialog of essentially the what's and the how's.


The time within a sprint is fixed based on the iteration length, however people’s time per iteration can change based on holiday and having resources allocated elsewhere. In order to scope out what PBIs we will put into the sprint, we need to calculate how much time we have to work with.

Assuming you have:

  • 5 days in your iteration.
  • 8 hours per day per team member.
  • 3 team members.
  • 1 team member is on holiday.

Then you have 80 hours of potential time this sprint to burn down tasks. A general rule on previous projects is that people are not machines and are not productive for 8 hours a day. Cutting this value down to 5 productive hours a day means you have 50 hours of potential time, it may look bad on your spread sheet but your project is more likely to succeed because of it.


Before a sprint can begin, a team needs to know what is going to be worked on. At the beginning of the meeting the product owner should bring in the prioritised backlog of work and work with the team to bring items into the sprint. This dialog needs to happen for two reasons:

  1. So the product owner communicates the priority of the tasks and what order they should be completed in.
  2. So the team can negotiate re-ordering tasks to tackle tasks more efficiently, usually because of technical reasons.

Exploring the latter point further, a common scenario is:

  • A solution comprises of multiple systems, a frontend and a backend.
  • The business priority puts the frontend system first.
  • Data can only be displayed on the frontend by using the backend.
  • They both need to be completed for go live.

The options are:

  • Create a throw away tool to push data to the frontend.
  • Implement a small slice of the backend.

So even though the business priority puts the frontend first, its more economical from a technical perspective to reorder some of the tasks. This is what the initial part of the sprint planning meeting is about, optimising the way the team will work over the sprint and providing the best value possible to the business.


The last part of sprint planning is the estimation, which involves:

  • Picking a PBI from the top of the prioritised list.
  • Breaking it down into tasks.
  • Assigning hours (estimated) to those tasks.

What you will find during this is a vast about of discussion which will encompass business logic, lots of conceptual design, some logical design and snippets of physical design. This entire dialog drives and shapes what will happen in your sprint, so its important to strike a good balance between allowing the team to communicate and time boxing the session so the team doesn’t burn out.

After the team is satisfied about what the task involves, an estimate of the effort involved in hours should be assigned. All team members should pick a number, either on cards or their fingers and come to a consensus after a little more discussion. A good rule of thumb for the size of the tasks is that they should be small enough to be completed within a day; smaller tasks drive better more accurate estimates.

It’s important that the product owner is available during this in case the team has questions about solutions they believe need approval from the business. They can also assist as an expert in the domain of the project along with business analysts during discussions around business rules and logic.

Begin your sprint

Once you have estimated enough tasks such that your availability figure is exceeded you are ready to begin your sprint.

Newer Posts Older Posts