Freigeben über

MDT 2012 Update 1: Deploy to VHD

  • Artikel

I was working on a separate blog posting (to be posted soon) that referenced the “Deploy to VHD” support that was present in MDT 2012 and improved in MDT 2012 Update 1 and wanted to include a link to that previous blog.  Except there was no previous blog – I guess I never did one…

So let’s start with what was added in MDT 2012.  Present in this version are two task sequence templates:

  • Deploy to VHD Client Task Sequence.  This is the equivalent of the “Standard Client Task Sequence” template, modified to deploy a client OS (Windows 7 or above) into a VHD file.
  • Deploy to VHD Server Task Sequence.  This is the equivalent of the “Standard Server Task Sequence” template, modified to deploy a server OS (Windows Server 2008 R2 or above) into a VHD file.

Just to be clear, these task sequences have nothing to do with the creation of virtual machines (although you could use them in virtual machines – there’s nothing preventing a VM from using boot from VHD).  Instead, these are designed to do the following, in the case of a new computer deployment:

  • Format and partition the physical disk.
  • Create a new, empty VHD file.
  • Format and partition the VHD file.
  • Apply the specified operating system WIM image to a volume created in the VHD file.
  • Set up a BCD entry to boot from the OS volume contained in the VHD file.

Of course all the other standard task sequence components are present too (injecting drivers, installing apps, applying patches, etc.).  Also, in MDT 2012 Update 1, the first step to format and partition the physical disk can be skipped, causing the new OS to be created on the existing disk, not disturbing the existing OS that might be on that disk.  As a result, you could then have a dual-boot computer, choosing the appropriate OS from the boot menu as there would be multiple BCD entries.

MDT 2012 Update 1 also will work with other scenarios, e.g. refreshes, but I’m not exactly sure why would want to do that.  Imagine what happens:  The user state is captured from current OS on the disk, a new VHD is created with the new OS, and then the user state is restored into that new OS in the VHD.  But now the user state is in both places, in the old OS and in the new OS.  (MDT 2012 RTW wouldn’t preserve the existing BCD, so you would always end up with only one BCD entry.  That behavior was fixed in MDT 2012 Update 1.)

If you want to try refreshing from a system already booting from a VHD file into a new OS running from a VHD file (same or different one), don’t.  It won’t work.  The challenge is that MDT really isn’t aware that the existing OS volume is in a VHD, so it might run into a variety of issues (e.g. staging the boot WIM in the VHD, or any operation that requires accessing the old OS files from within Windows PE).

So why is this referred to as “Deploy to VHD”?  It’s called that because MDT is not moving around VHD files (which would be highly inefficient, as these files aren’t compressed in any way).  Instead, it creates a new empty VHD file and deploys the operating system WIM file into it.  This is actually fairly fast and efficient, and surprisingly doesn’t complicate the deployment process very much at all.

Why might you want to do this?  This is primarily useful as a mechanism for setting up an additional OS on an existing computer.  Personally, I prefer using virtual machines for most things, but there could be some valid cases where using an OS running on the physical hardware (which after all is what you are doing, even when booting from a VHD file) is advantageous.

There are a few gotchas in the process though.  Because of some technical issues that could occur when using dynamically expanding VHDs, any time you perform a “boot from VHD” the VHD file will automatically expand to its full size (to make sure that Windows never needs to do this while the OS in the VHD is actively running).  So even if you have a 10GB operating system WIM (expanded from a 3GB WIM), you’ll end up with a much larger VHD file.  By default, MDT will create a VHD file whose maximum size is 80% of the available disk space on the OS volume.  So if you do a bare metal deployment to a computer with a 128GB physical drive, you’ll end up with a 102GB VHD file and about 26GB of free disk space.  You can customize this by editing the task sequence if you don’t want it to be that large:

image

Another gotcha has to do with the use of differencing disks, which you can see in the above screen shot.  What happens if you configure that?  Well, it will happily create a new empty VHD and then create a differencing disk on that empty VHD.  So then when the operating system image gets deployed, it ends up writing the whole thing into the differencing disk, while the parent VHD stays empty.  That’s not terribly useful.  But there are some additional properties in the underlying MDT ZTIVHDCreate.wsf script that could be leveraged instead to have MDT start by making a copy of an existing VHD file, instead of starting with an empty VHD.  But that’s a more advanced scenario, left for the creative types.

Comments

  • Anonymous
    June 06, 2013
    I would like to know, if you have the info where can I modify the VHD settings  for this tasks like Description, because when I boot I have 2 Win7 entries and I would liek to know where on MDT scripts or variables I could modify the VHD entry on bcdedit part. thanks

  • Anonymous
    June 24, 2013
    Have you ever tried a full deployment of a duel boot machine. So that the task sequence would deploy the primary os to disk and then a secondaly os to VHD in one sequence?

  • Anonymous
    October 28, 2015
    Hi
    Here's my scenario.
    Install Windows 7 SP1 64bit using standard Client.xml template.
    Install Windows 8.1 64bit using VHDClient.xml template.
    In the Windows 8.1 task sequence I disabled "Format and Partition Disk" step.

    Windows 8.1 installed fine but MDT removed previously BCD entries for Windows 7.

    Looking in the LTIApply.wsf and function I see the if statement.
    If ucase(oEnvironment.Item("IsUEFI")) = "TRUE" then
    ...
    ...
    oLogging.CreateEntry "Removing existing BCD so it can be recreated using BCDBOOT.", LogTypeInfo
    Else
    ...
    If oEnvironment.Item("VHDDisks") <> "" then
    oLogging.CreateEntry "Skip Removal of BCD files in VHD Scenarios.", LogTypeInfo
    ...

    So when IsUEFI = true then it always remove BCD entries.

    I added another If statement to the IsUEFI=True section. So that when VHDDisks have some data it won't clear the BCD entries.

    Here's the full If statement.

    If ucase(oEnvironment.Item("IsUEFI")) = "TRUE" then

    ' Remove old BCD, as it might get in the way
    On Error Resume Next
    If oEnvironment.Item("VHDDisks") <> "" then
    oLogging.CreateEntry "IsUEFI sectiom. Skip Removal of BCD files in VHD Scenarios.", LogTypeInfo
    Else
    'If oFSO.FileExists(Left(oBootDrive.Drive,2) & "efimicrosoftbootbcd") then
    oLogging.CreateEntry "Removing existing BCD so it can be recreated using BCDBOOT.", LogTypeInfo
    oFSO.DeleteFile Left(oBootDrive.Drive,2) & "efimicrosoftbootbcd", true
    End if

    ' When using Windows ADK, specify that we want to update the UEFI BCD (in firmware).
    ' When using Windows AIK, don't specify a store as it should figure it out.

    If Left(oEnvironment.Item("OSCurrentVersion"), 3) >= "6.2" then
    TestAndFail RunBCDBootEx( sDestinationDrive & "windows", " /s " & left(oBootDrive.Drive,2) & " /f UEFI"), 5616, "Verify BCDBootEx"
    Else
    TestAndFail RunBCDBootEx( sDestinationDrive & "windows", " "), 5616,"Verify BCDBootEx"
    End if


    ' Make sure the boot menu timeout is 0

    RunBCDEdit "/timeout 0"

    Else

    ' Remove old BCD, as it might get in the way

    On Error Resume Next
    If oEnvironment.Item("VHDDisks") <> "" then
    oLogging.CreateEntry "Skip Removal of BCD files in VHD Scenarios.", LogTypeInfo
    ElseIf oFSO.FileExists(Left(oBootDrive.Drive,2) & "bootbcd") then
    oLogging.CreateEntry "Removing existing BCD so it can be recreated using BCDBOOT.", LogTypeInfo
    oFSO.DeleteFile Left(oBootDrive.Drive,2) & "bootbcd", true
    End if
    On Error Goto 0


    ' Create a new boot entry

    TestAndFail RunBCDBootEx( sDestinationDrive & "windows", " /s " & left(oBootDrive.Drive,2)),5616,"Verify BCDBootEx"


    ' Make sure the boot menu timeout is 0

    RunBCDEditEx "/timeout 0", Left(oBootDrive.Drive,2) & "bootbcd", null

    End if

  • Anonymous
    October 28, 2015
    The comment has been removed

  • Anonymous
    January 05, 2016
    Useful Thank You Sayings in general, for providing the requested information.http://goo.gl/w7evPl