MDT

PowerShell is King – HP Scripting Tools for Windows PowerShell v1.1 is released

The Deployment Bunny - Mon, 04/21/2014 - 08:02

The 1.1 version supports PowerShell v3 and v4 and that means you can install it on Windows 8.1 and Windows Server 2012 R2. There is also some added CMDlets plus some minor changes.

Download it from http://www8.hp.com/us/en/products/server-software/product-detail.html?oid=5440657#!tab=features

Release notes is here (read them) http://h20564.www2.hp.com/portal/site/hpsc/public/kb/docDisplay/?docId=c04141539

/mike


Categories: MDT

Listing all the IP Addresses used by VMs

Virtual PC Guy's WebLog - Fri, 04/18/2014 - 12:14

Here is a neat little snippet of PowerShell:

Get-VM | ?{$_.State -eq "Running"} |  Get-VMNetworkAdapter | Select VMName, IPAddresses

If you run this on a Hyper-V Server it will give you a listing of all the IP addresses that are assigned to running virtual machines:

This works whether you are using DHCP or Static IP addresses – and can really help when you are trying to track down a rogue virtual machine.

Cheers,
Ben

Categories: MDT

Exporting a Virtual Machine Checkpoint

Virtual PC Guy's WebLog - Thu, 04/17/2014 - 12:56

Something neat that you can do in Windows Server 2012 / Windows 8 or later is to export a virtual machine checkpoint.  You can do this by either:

  1. Selecting the checkpoint in the UI and selecting Export from the action pane
  2. Using the Export-VMSnapshot cmdlet

When you do this, we will actually create an exported virtual machine that represents just the checkpoint you selected.  This means that we will merge all the changes from the checkpoint into a single set of virtual hard disks – so that you can create a new virtual machine from that point in time without having to include other checkpoints.

Cheers,
Ben

Categories: MDT

Hyper-V Networking–NIC Teaming

Virtual PC Guy's WebLog - Wed, 04/16/2014 - 19:46

If you look at the advanced features of a network adapter in Hyper-V, you may have noticed the NIC Teaming option below:

And wondered what this was about.

In most deployments you will enabled network adapter teaming in the host operating system, and connect a virtual switch to the team.  If you do this you will never need to enable this option.

But there are situations where you will not want to use network adapter teaming in the host operating system, and instead you will want to connect two virtual network adapters to the virtual machine and configure teaming inside the guest operating system.  One situation where you would want to do this is if you were using SR-IOV enabled network adapters.

The effect of enabling this option is that if there is a connection failure on the physical network adapter that is being used by the virtual switch, we also disconnect the virtual network adapter.  This is required to ensure that network teaming functions correctly inside the guest operating system – but will cause problems if network teaming is not configured inside the guest operating system.

Cheers,
Ben

Categories: MDT

PowerShell is King–Use PowerShell to find out the file information in a file repository

The Deployment Bunny - Wed, 04/16/2014 - 06:45

This morning I was scheduled to install some software, one part of HP Service Pack was not installed, so I made the decision to just install that component, rather then re-running that Service Pack Setup (HPSUM). The quarion is, what file contains what I need? All files has just the CPXXXXXXX.exe? If I select properties from a file in explorer, I can see that it contains this:

Hmm, how could  I get that using PowerShell? Could it be “"Get-ChildItem”?

Running Get-ChildItem -Path \\cloud\dfs\Software\Applications\HP\swpackages -Filter *.exe gives me this:

and that does not help, but if adding | Select * will give me this:

So, the info is there, right, now how could I get rid of the junk…

Hmm, there is something called VersionInfo, lets try that…

Get-ChildItem -Path \\cloud\dfs\Software\Applications\HP\swpackages -Filter *.exe | Select-Object Name,VersionInfo | Out-GridView

Getting closer, bet still to much junk…

Maybe, this would work?

Get-ChildItem -Path \\cloud\dfs\Software\Applications\HP\swpackages -Filter *.exe | Select-Object -ExpandProperty VersionInfo | Select-Object -Property ProductName, ProductVersion, Filename | Out-GridView

Lets try that:

Yes, that seems to give the the result I like.

/mike


Categories: MDT

Nice to Know–Management Pack for Windows Server 2012 R2 Hyper-V has an Issue

The Deployment Bunny - Wed, 04/16/2014 - 04:52
The Issue:

ID: 26001 – Microsoft.SystemCenter.VirtualMachineManager.2012.Report.VPortUsageCollection

Got null results from Select Connection from Msvm_SyntheticEthernetPortSettingData where InstanceId=

The “Solution”:

To be honest, there is no real solution so far, the reason is that the MP is looking for the WMI data in the “old” V1 place, and in R2 that is gone, that information is in the new namespace V2. There should be a new MP, but so far I have not seen one. So the only solution is to turn this collector of and that solves only one issue. The event log looks “nice”. In my world that’s is not a solution…

Read more:

http://support.microsoft.com/kb/2924512


Categories: MDT

TechEd–New Session: Bare Metal OS Deployment in Microsoft System Center 2012 R2 Virtual Machine Manager: This is How it is Done!

The Deployment Bunny - Tue, 04/15/2014 - 20:46

A very nice surprise.

At TechEd they have added more sessions to the DataCenter track and that means I’ve got a new session!

Bare Metal OS Deployment in Microsoft System Center 2012 R2 Virtual Machine Manager: This is How it is Done!

System Center Virtual Machine Manager 2012 R2 has bare metal OSD deployment built-in. This session is all about that. You will learn how to do discover, how to deal with drivers, networking and you will learn how to troubleshoot the process and most of all you will learn how to NOT troubleshoot, since you will learn how to do it correctly. You will also see how to deal with hardware configuration, firmware and such, expect lots of demos and PowerShell.

As you can see the session will be focusing on bare metal deployment, something I have been doing for many years now. Besides the actual deployment I will also show you how to do the network and storage related configuration to get VMQ to work correctly and some other stuff. This is going to be fun!

Note: If you are going to TechEd and you do join the session, please, step up to the podium and say hi.

/mike


Categories: MDT

Understanding Maximum Dynamic Memory from inside a VM

Virtual PC Guy's WebLog - Tue, 04/15/2014 - 12:49

Dynamic memory is a great feature that allows Hyper-V administrators to get better utilization of their physical memory.  But it can be hard to tell what is going on from inside of a virtual machine.  There are, however, some things that you can do from inside a virtual machine.

The first thing you can do is see how much memory is currently available to your virtual machine.  This is just the free memory as is displayed in Task Manager inside the guest operating system:

Beyond this, if you are running Windows 8 or later, you can also see what the maximum memory is set at for your virtual machine.  In the screenshot above you can see that the Maximum memory of this virtual machine is set to 4GB.

You can also access the information about the maximum memory configured inside of a virtual machine by looking at the Maximum Memory, Mbytes performance counter off of the Hyper-V Dynamic Memory Integration Service using Performance Monitor.

Finally, you can access this information using PowerShell:

Running the following command inside of a virtual machine:

(get-counter "\Hyper-v Dynamic Memory Integration Service\Maximum Memory, Mbytes").CounterSamples.CookedValue

Will tell you what the maximum memory for that virtual machine is configured to.

Cheers,
Ben

Categories: MDT

USMT: Architecture-Independent Rules for Migrating 32-bit Applications

The Deployment Guys - Mon, 04/14/2014 - 12:12

One challenge with capturing the settings for a 32-bit applications with USMT is that some file and Registry paths will be different on 32-bit operating systems and 64-bit operating systems.  On a 32-bit operating system 32-bit programs get installed to C:\Program Files and local machine Registry entries are written to HKLM\Software.  However, on a 64-bit operating system , 32-bit programs get installed to C:\Program Files (x86) and local machine Registry entries are redirected to HKLM\SOFTWARE\Wow6432Node.  (See this section of the Programming Guide for 64-bit Windows for more details: http://msdn.microsoft.com/en-us/library/aa384249(v=vs.85).aspx.)

Because of this, you might think you would need to different components to migrate 32-bit application settings depending on the source and destination operating system architecture.  For example, I had a customer that was using three different XML files with components for 32-bit applications.  I’ll illustrate this using a fictitious 32-bit application called MyApp.  This application is installed by default to C:\Program Files\MyApp and creates machine-based settings in HKLM\Software\MyApp on a 32-bit OS.  For the sake of simplicity for this example, lets say that the desired way to migrate this app is to capture all the files in the C:\Program Files\MyApp\Config folder and to capture all of HKLM\Software\MyApp (or the equivalent locations on a 64-bit OS).

The customer had three different migration scenarios:

  • Windows XP 32-bit to Windows XP 32-bit (break/fix rebuilds, etc.)
  • Windows XP 32-bit to Windows 7 64-bit (OS migration)
  • Windows 7 64-bit to Windows 7 64-bit (break/fix rebuilds, etc.)

For Windows XP 32-bit to Windows XP 32-bit migrations they had a component like this for MyApp.

<component type="Application" context="System">
    <displayName>Migrate MyApp - XP to XP</displayName>
    <role role="Settings">
        <rules>
            <include>
                <objectSet>
                    <pattern type="File">%CSIDL_PROGRAM_FILES%\MyApp\Config\* [*]</pattern>
                    <pattern type="Registry">HKLM\Software\MyApp\* [*]</pattern>
                </objectSet>
            </include>
        </rules>
    </role>
</component>

For Windows XP 32-bit to Windows 7 64-bit migrations they had a component like this for MyApp.  This has locationModify rules to move the migrated items to the redirected locations for 32-bit apps on 64-bit Windows.

<component type="Application" context="System">
    <displayName>Migrate MyApp - XP to Win7</displayName>
    <role role="Settings">
        <rules>
            <include>
                <objectSet>
                    <pattern type="File">%CSIDL_PROGRAM_FILES%\MyApp\Config\* [*]</pattern>
                    <pattern type="Registry">HKLM\Software\MyApp\* [*]</pattern>
                </objectSet>
            </include>
            <locationModify script="MigXmlHelper.Move('%CSIDL_PROGRAM_FILESX86%\MyApp\Config')">
                <objectSet>
                    <pattern type="File">%CSIDL_PROGRAM_FILES%\MyApp\Config\* [*]</pattern>
                </objectSet>
            </locationModify>
            <locationModify script="MigXmlHelper.Move('HKLM\SOFTWARE\Wow6432Node\MyApp')">
                <objectSet>
                    <pattern type="Registry">HKLM\Software\MyApp\* [*]</pattern>
                </objectSet>
            </locationModify>
        </rules>
    </role>
</component>

For Windows 7 64-bit to Windows 7 64-bit migrations they had a component like this for MyApp which directly captured/restored the redirected locations for the 32-bit app on 64-bit Windows.

<component type="Application" context="System">
    <displayName>Migrate MyApp - Win7 to Win7</displayName>
    <role role="Settings">
        <rules>
            <include>
                <objectSet>
                    <pattern type="File">%CSIDL_PROGRAM_FILESX86%\MyApp\Config\* [*]</pattern>
                    <pattern type="Registry">HKLM\SOFTWARE\Wow6432Node\MyApp\* [*]</pattern>
                </objectSet>
            </include>
        </rules>
    </role>
</component>

Of course, this makes it complicated to call USMT with the correct XML file depending on what source and destination operating systems were involved.  Fortunately, there is a way to avoid this.  It involves using a technique I lifted directly from MigApp.xml.  MigApp.xml contains a namedElements node that defines a bunch of global items.  Some of these items define single variables representing the file and local machine Registry locations for 32-bit applications independent of the operating system architecture.  You can copy this into your own custom XML files and use those variables in the same way.  Copy the XML content below into your custom XML files (just after the migration node at the top)

<library prefix="MigSysHelper">MigSys.dll</library>

<_locDefinition>
    <_locDefault _loc="locNone"/>
    <_locTag _loc="locData">displayName</_locTag>
</_locDefinition>

<namedElements>
    <!-- Global -->
    <environment name="GlobalEnvX64">
        <conditions>
            <condition>MigXmlHelper.IsNative64Bit()</condition>
        </conditions>
        <variable name="HklmWowSoftware">
            <text>HKLM\SOFTWARE\Wow6432Node</text>
        </variable>
        <variable name="ProgramFiles32bit">
            <text>%ProgramFiles(x86)%</text>
        </variable>
        <variable name="CommonProgramFiles32bit">
            <text>%CommonProgramFiles(x86)%</text>
        </variable>
    </environment>
    <environment name="GlobalEnv">
        <conditions>
            <condition negation="Yes">MigXmlHelper.IsNative64Bit()</condition>
        </conditions>
        <variable name="HklmWowSoftware">
            <text>HKLM\Software</text>
        </variable>
        <variable name="ProgramFiles32bit">
            <text>%ProgramFiles%</text>
        </variable>
        <variable name="CommonProgramFiles32bit">
            <text>%CommonProgramFiles%</text>
        </variable>
    </environment>

    <!-- Global USER -->
    <environment context="USER" name="GlobalEnvX64User">
        <conditions>
            <condition>MigXmlHelper.IsNative64Bit()</condition>
        </conditions>
        <variable name="VirtualStore_ProgramFiles32bit">
            <text>%CSIDL_VIRTUALSTORE_PROGRAMFILES(X86)%</text>
        </variable>
        <variable name="VirtualStore_CommonProgramFiles32bit">
            <text>%CSIDL_VIRTUALSTORE_COMMONPROGRAMFILES(X86)%</text>
        </variable>
    </environment>
    <environment context="USER" name="GlobalEnvUser">
        <conditions>
            <condition negation="Yes">MigXmlHelper.IsNative64Bit()</condition>
        </conditions>
        <variable name="VirtualStore_ProgramFiles32bit">
            <text>%CSIDL_VIRTUALSTORE_PROGRAMFILES%</text>
        </variable>
        <variable name="VirtualStore_CommonProgramFiles32bit">
            <text>%CSIDL_VIRTUALSTORE_COMMONPROGRAMFILES%</text>
        </variable>
    </environment>
</namedElements>

Once you add this, you can now define one component to migrate MyApp that will work in all three scenarios:

<component type="Application" context="System">
    <displayName>Migrate MyApp</displayName>
    <environment name="GlobalEnv"/>
    <environment name="GlobalEnvX64"/>
    <environment name="GlobalEnvUser"/>
    <environment name="GlobalEnvX64User"/>
    <role role="Settings">
        <rules>
            <include>
                <objectSet>
                    <pattern type="File">%ProgramFiles32bit%\MyApp\Config\* [*]</pattern>
                    <pattern type="Registry">%HklmWowSoftware%\MyApp\* [*]</pattern>
                </objectSet>
            </include>
        </rules>
    </role>
</component>

The variable %ProgramFiles32bit% will resolve correctly to C:\Program Files on a 32-bit OS and C:\Program Files (x86) on a 64-bit OS.  The variable %HklmWowSoftware% will resolve correctly to HKLM\Software on a 32-bit OS and HKLM\SOFTWARE\Wow6432Node on a 64-bit OS.

One thing to note, you need to add four environment nodes shown in the above example into your components that will use these variables.  This is essentially adding a “reference” to the namedElements items that define the variables.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region

Categories: MDT

Importing a VM with VHDs in Different Paths

Virtual PC Guy's WebLog - Mon, 04/14/2014 - 12:09

I was recently given an interesting challenge.  I was asked to show how you could use PowerShell to import a virtual machine; where the virtual hard disks were stored in multiple different locations.  Now, if the virtual hard disks were all in a single location, you could just use the “VHDSourcePath” parameter on Import-VM to let Hyper-V know where to look.  But this does not work if the virtual hard disks are in multiple different locations.

To handle this situation – you need to use Compare-VM (as I discussed here).

The process I followed to do this is:

  1. Use Compare-VM to create a virtual machine compatibility report.  Like this:

    $vmReport = compare-vm "C:\Users\benja_000\Desktop\Exported VM\Import Test VM\Virtual Machines\CCAE6F7E-B9FD-474B-9D08-A7011940C217.XML" -Copy –GenerateNewId

  2. List the incompatibilities and see that there are two virtual hard disks that have not been found.
  3. Look at .Source.Path on each incompatibility to determine which virtual hard disk is missing
  4. Use Set-VMHardDiskDrive to correct the location for the first virtual hard disk:

    Set-VMHardDiskDrive $vmReport.Incompatibilities[0].Source -Path "C:\Users\benja_000\Desktop\Exported VM\Import Test VM\Virtual Hard Disks\a\Import Test VM.vhdx"

  5. Use Set-VMHardDiskDrive to correct the location for the second virtual hard disk:

    Set-VMHardDiskDrive $vmReport.Incompatibilities[1].Source -Path "C:\Users\benja_000\Desktop\Exported VM\Import Test VM\Virtual Hard Disks\b\Another VHDX.VHDX"

  6. Finally use Import-VM with the corrected virtual machine compatibility report

Now the virtual machine is imported and ready to go.

Cheers,
Ben

Categories: MDT

Experimenting with WIMBoot using MDT 2013

With the release of the Windows 8.1 Update, there is a new mechanism available for running Windows called Windows Image Boot, or WIMBoot for short.  For details about what this is and how it works, see the Springboard blog.

Although MDT 2013 doesn’t include any specific support for WIMBoot (maybe something that could be considered for a future release), there’s nothing preventing anyone from following the instructions available in the ADK to create a task sequence that does it.  So I decided to try it.  Let’s walk through the process at a high level.

Step #1:  Create an image with Windows 8.1 Update

Because WIMBoot is a new feature with the Windows 8.1 Update, it makes sense that you first need to have a Windows 8.1 image that contains the Windows 8.1 Update.  The easiest way to do this is to download a pre-patched ISO from the Volume License Service Center on April 14th, but you can also inject the Windows 8.1 Update fixes into an existing Windows image.

Step #2: Get MDT 2013 to create a Windows PE 5.1 boot image

In order to deploy WIMBoot, you need to use a version of Windows PE that supports it.  That would be Windows PE 5.1.  But that’s not a version that you just download and use.  Instead, it’s a version that you (or ideally MDT) need to create.  The first step in that is to update the ADK to the latest version.  Download the new ADKSETUP.EXE and run it to install all the patches. 

After you’ve done that, the process for creating a Windows PE 5.1 image involves injecting the Windows 8.1 Update into Windows PE.  That’s not something MDT knows anything about, but since MDT includes the ability to run a script during the boot image generation process, it can be “taught.”  That means dropping in an updated UpdateExit.vbs script that injects the six Windows 8.1 Update fixes to the boot image.  And of course it needs to have those updates available to it, so you need to download those from the Download Center and place them where the script can find them.

After that’s done, update the deployment share, completely regenerating the boot image.  This will take quite a while, as the Windows PE generation process itself isn’t very fast to start with, but when you add in the patch installation process the time will easily double.  Maybe you want to try this in a lab :-)

Step #3: Teach MDT how to deploy using WIMBoot

The steps necessary to apply a WIM using WIMBoot are not surprisingly different than what MDT typically does, so the existing LTIApply.wsf script won’t do it.  So we need a new script.  Fortunately, because we can focus exclusively on this one scenario, the scripting needed to this, which follows the ADK steps documented at http://technet.microsoft.com/en-us/library/dn605112.aspx, isn’t too hard.  To add more flexibility and to solve some challenges, I added a few features:

  • The script will dynamically determine the size of the “Images” volume needed to hold the WIM file, then shrink the OS partition by that size.  That way, you don’t need to modify the “Format and Partition Disk” step to specify an explicit size, which is nearly impossible to do anyway because you want a fixed-size partition after the OS partition, where the OS partition says “100% of the remaining free space”, an impossible combination in the UI.
  • The script will export an existing WIM to make it ready for WIMBoot.  This export process, done using DISM.EXE /Export-Image /WIMBoot, ends up adding a lot of time to the deployment process though, because it ends up decompressing and recompressing the contents of the WIM in the process of exporting it.  As an alternative, you can do this once ahead of time (manually) and tell the script that you’ve done this.
  • If for some reason you want to explicitly specify the size of the images partition, you can through a command line parameter.
  • Ideally the machine would be set up properly so that the system recovery options (Reset My PC/Refresh My PC) work.  To do this, you need a Windows RE boot image that has been updated with the Windows 8.1 Update fixes, using the same basic steps documented at http://technet.microsoft.com/en-us/library/dn613859.aspx.  That part must be done manually, but the script will look for the WinRE.wim file in the same folder as the OS WIM and copy it to the same “Images” volume and register it as a recovery image.

The next piece is a task sequence.  Since WIMBoot is really only useful for bare metal deployments, I took the standard client task sequence template and chopped it down to the bare minimum needed to perform a bare metal WIMBoot deployment, while still supporting things like driver injection, app installation, Windows Update installation, etc.  The original “Install Operating System” is left in but disabled, since that’s the step that provides a simple way to associate an OS with the task sequence.  Instead of running this step, a new step was added to run “LTIApplyWIMBoot.wsf”, the new script discussed above.  The net result is something that looks like this:

Step #4:  Deploy

Find a machine that meets the requirements and you’re ready to do a bare metal deployment:

  • 16GB or 32GB SSD or eMMC solid-state storage.
  • UEFI 2.3.1 system (Windows 8 logo-certified).

Ideally these would be machines that come already configured for WIMBoot (since you know it meets the requirements and has been tested by the OEM to ensure good performance).  But if you just want to test it out, you can try it on Windows Server 2012 R2 Hyper-V or Windows 8.1 Hyper-V, since both support “type 2” virtual machines that use UEFI. 

What do you have to do?

Just complete the previous four steps.  OK, but those steps leave out the details, so let’s use a checklist instead.

  1. Create a Windows 8.1 Update operating system image by injecting the Windows 8.1 Updates into an existing Windows 8.1 image, or download a new Windows 8.1 Update ISO already containing the updates from VLSC (available on April 14th).  Import the operating system into your MDT deployment share.
  2. Download the updated ADKSETUP.EXE for the ADK for Windows 8.1 and use it to install the updated ADK components released with Windows 8.1 Update.
  3. Download the Windows 8.1 Update prerequisite (a servicing stack update) for both x86 and x64 from http://support.microsoft.com/kb/2919442, and place them into the “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder.  (Note that both x86 and x64 versions are needed because they will be used to update x86 and x64 boot images.)
  4. Download the individual x86 and x64 Windows 8.1 Updates from the download center and place them into the “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder.  (Note that both x86 and x64 versions are needed because they will be used to update x86 and x64 boot images.)  With the downloads from step #3 and these, you should have a total of 12 different MSU files in the folder.
  5. Place the updated “UpdateExit.vbs” file in the attached zip file into the same “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder, replacing the version that is already there.  (If you’ve made any other changes to this, you’ll need to merge your changes into the attached version.)  This script will be called during the deployment share update process to inject the Windows 8.1 Update into the boot images, which is what is needed to make Windows PE 5.1 boot images.
  6. Update your deployment share by right-clicking on it and choosing the “Update deployment share” option.  Make sure you check the “Completely regenerate the boot images” option, as this is needed the first time to get Windows PE updated.
  7. Check the results of the “update” process to make sure all the MSU files were injected successfully by making sure all the steps have good return codes.  Here’s an example:

    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2919442-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2919355-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2932046-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2937592-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2938439-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2934018-x86.msu"
    Return code from command = 0
    About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Cleanup-Image /StartComponentCleanup /ResetBase
    Return code from command = 0

  8. Place the new “WIMBoot.xml” task sequence template from the attached zip file into the “C:\Program Files\Microsoft Deployment Toolkit\Templates” folder.
  9. Place the new “LTIApplyWIMBoot.wsf” script into the deployment share’s “Scripts” folder.
  10. Create a new task sequence, selecting the “WIMBoot Task Sequence” template and the operating system image that you imported.
  11. Perform a bare metal deployment using the updated boot images (update WDS if using PXE, generate new boot CDs, etc.), selecting your new task sequence.

In this scenario, you’ll notice during the task sequence execution that the operating image is exported to make it ready for WIMBoot.  This export process takes a long time, because it changes the compression method used for the WIM.  It's the easiest option since it requires no additional steps on your part, but it’s not the quickest.  If you want to make the process faster, you can follow these steps:

  1. Export the existing WIM image using this DISM command:
    DISM.EXE /Export-Image /WIMBoot /SourceImageFile:<original WIM> /SourceIndex:1 /DestinationImageFile:<new WIM to create>
  2. Import the new WIM into your deployment share.
  3. Update your existing WIMBoot task sequence to use the new image.
  4. Modify the task sequence step “Apply WIM Boot Image“ to add a “/Optimized:TRUE” switch to the LTIApplyWIMBoot step to indicate that no export is required.

Note that this WIM image can still be used for non-WIMBoot deployments – it’s ready for WIMBoot, but not optimized for WIMBoot.  If you want to take it a step further, you can optimize that exported image (following the above three steps first) using these steps:

  1. Mount the WIMBoot-ready image using DISM:
    DISM.EXE /Mount-Image /ImageFile:<WIM file> /Index:1 /MountDir:C:\Mount
  2. Optimize the image for WIMBoot using DISM:
    DISM.EXE /Image:C:\Mount /Optimize-Image /WIMBoot
  3. Commit the changes to the WIM file:
    DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
  4. Import the modified image into your deployment share.
  5. Update your existing WIMBoot task sequence to use the new image.
  6. Modify the task sequence step “Apply WIM Boot Image“ to add a “/Optimized:TRUE” switch to the LTIApplyWIMBoot step to indicate that no export is required.

And one more thing:  You need to perform some additional steps if you want Windows RE to work for recovering a WIMBoot system.  This is needed to ensure the refresh/reset my PC options work from PC Settings, that the machine can self-repair if something happens during the boot process, that BitLocker recovery can work properly, etc.  So it’s highly recommend that you do this.  To do this, follow these steps:

  1. Mount your Windows image using DISM:
    DISM.EXE /Mount-Image /ImageFile:<WIM file> /Index:1 /MountDir:C:\Mount
  2. Move the WinRE.WIM out of the image (since recovery can’t boot a WIM within a WIM):
    move C:\mount\Windows\Windows\System32\Recovery\winre.wim C:\winre.wim
  3. Commit the changes to the WIM file:
    DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
  4. Mount the WinRE.WIM file:
    DISM.EXE /Mount-Image /ImageFile:C:\winre.wim /Index:1 /MountDir:C:\Mount
  5. Inject the downloaded Windows 8.1 updates into the WIM image:
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2919442-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2919355-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2932046-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2937592-x86.msu
    DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2934018-x86.msu
  6. Cleanup the image as described in the ADK documentation:
    DISM.EXE /Image:C:\Mount /Cleanup-Image /StartComponentCleanup /ResetBase
  7. Commit the changes to the WIM file:
    DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
  8. Export the contents of the WIM into a new WIM to reduce the size of the image:
    DISM.EXE /Export-Image /SourceImageFile:C:\winre.wim /SourceIndex:1 /DestinationImageFile:C:\winre-new.wim
  9. Copy the resulting file into the same folder as the operating system WIM on the deployment share, e.g. “C:\DeploymentShare\Operating Systems\WIMBoot”.  Make sure the file is named “winre.wim” so that the LTIApplyWIMBoot.wsf script can find it; the script will take care of the remaining steps.

And that’s all there is to it. 

Well, almost.  I need to point out a few more things:

  • I am providing these scripts and the task sequence template as-is.  It’s not supported by Microsoft, so don’t call support about it.  Feel free to e-mail me at mniehaus@microsoft.com, but I can’t guarantee a quick response – might take weeks or months before I get to the e-mail :-)
  • When you use a non-WIMBoot image (one not exported using the steps above), the recompression process that happens when the image is exported causes the new image to be larger than the original one.  The LTIApplyWIMBoot script attempts to guess at how big, assuming it will be about one-third bigger, but that might not be accurate.  If you run into issues where the OS image and winre.wim won’t fit, you can either go through the export steps above (so no guessing needs to be done), or you can explicitly specify how big you want to make the images partition by adding an “ImagesSize” switch to the LTIApplyWIMBoot command line.  See the script comments for more information.
  • If you choose to optimize the operating system image using the steps above, you might also want to export the image into a new WIM file to make it as small as possible.  It won’t be a huge difference, but on a 16GB system, every little bit helps.
  • Remember, WIMBoot is intended for new hardware that has smaller (16GB or 32GB) SSD or eMMC disks, and requires Windows 8 certified UEFI systems.  I would only recommend using it on systems that originally shipped from the manufacturer configured for WIMBoot.  For example, let’s say you purchased a new 16GB tablet that was configured with WIMBoot and the Windows 8.1 “core” SKU, and you wanted to deploy Windows 8.1 Enterprise to it.  You could use the provided task sequence to completely wipe the device (no data migration) and reload it.
  • If you want to try this in a VM, feel free – but remember it needs to be a UEFI virtual machine (e.g. Hyper-V on Windows 8.1 or Windows Server 2012 R2).  But this isn’t intended for virtual machines, VDI, or other scenarios.
  • If you’ve set everything up correctly, you should be able to see in the Disk Management tool that the C: drive is using WIMBoot.  And more importantly, the refresh and reset recovery options should work.  Try them out at least once to make sure.
  • I included steps in the task sequence template to restore user state (useful for a “replace” scenario), to inject drivers, to inject updates, and to install apps.  But there is nothing to capture state.  That’s because this is a bare metal-only scenario.
  • Make sure you have a lot of free disk space, as the Windows PE generation process will likely require at least 3GB of available space to inject the Windows 8.1 Update files (before the cleanup process shrinks it back down again).
  • You won’t see any progress reported while the updates are being injected into Windows PE, as the UpdateExit.vbs script doesn’t have the ability to provide any real-time status information back to Workbench.  Just be patient – you can see via Task Manager that the DISM commands are still running.

Please try this out when you have some spare time, and post some comments indicating if it worked or not.  Most of the validation of the steps in this blog was done in hotel rooms, airports, and airplanes…

Categories: MDT

Dealing with Jailbroken/Roted devices in ConfigMgr 2012 R2 & Intune

Coretech Blog » Kent Agerlund - Thu, 04/10/2014 - 04:18
As you enroll a mobile device into Intune/ConfigMgr 2012 R2, inventory data will automatically be uploaded to the ConfigMgr database. One of the data being collected is the Jailbroken/rooted condition. In the below example the device is being detected as a jailbroken device. One of the many benefits of using Intune as the MDM solution […]
Categories: MDT

Event – CA Accelerate IT PRO Camp, Stockholm 10,22,23 of April 2014 – Windows Client deployment and then some…

The Deployment Bunny - Mon, 04/07/2014 - 16:31

(in Swedish)

LabCenter kommer tillsammans med Microsoft att genomföra en dags workshops kring Windows 8 och Windows 8.1 klienten med fokus på administration och utrullning I föreatags miljöer. Cirka halva dagaen är förläsningar och demonstrationer och den andra halvan är hands-on. av dom 3 event vi kör så är 2 fullbokade, men det finns ett tillfälle med cirka 10 platser kavr och det är där du kommer in!

Agenda
Vi visar hur du kan gå från en tidigare version av Windows och Office till en mer modern miljö och kunna dra nytta av de senaste teknologierna kring säkerhet och mobilitet.

Under dagen går vi igenom grunderna i Windows 8/8.1 och Office 365 klientutrullning genom interaktiva presentationer, demos och hands-on laborationer.

  • Introduction to Windows 8.1, Office 365 ProPlus and Office 2013
  • Image Creation, Lite Touch/Zero-Touch Deployment
  • Strategies & Office 2013 Deployment
  • Windows to Go Creation and Deployment
  • Windows 8/8.1 Security
  • Application Delivery with App-V
  • User Personalization with UE-V

Datum att välja på:
Stockholm 10 april 2014 – Fullt!
Stockholm 22 april 2014

Stockholm 23 april 2014 – Fullt!
Plats: LabCenter, Oxtorgsgränd 2, 111 57 Stockholm
Längd: 1 dag (09.00-16.30)
Instruktör: Mikael Nyström
Workshopen är kostnadsfri.

Läsa mer och anmälan – http://www.labcenter.se/sales/CA_Accelerate_IT_PRO_Camp


Categories: MDT

Reduce DNS Client Cache in Windows Server 2012 R2

The Deployment Bunny - Sun, 04/06/2014 - 12:48

A very good friend (and Geek) wrote a post about modifying the cache when using RDP Gateway. A very common issue we have is when we deploy, configure and re-construct the infrastructure is that the gateway is keeping the cache a bit to long.

Get the solution from Markus Lassfolk

/mike


Categories: MDT

TechX–Azure In Sweden next week!–Don’t MISS it!

The Deployment Bunny - Sun, 04/06/2014 - 12:43

(In Swedish)

Nästa vecka är det TechX Azure (http://azure.techx.se/?page_id=867) och då kör jag och Markus Lassfolk hela 6 sessioner, vilket gör att vi kommer att vara där hela dagen och köra!, så vill man så kan man vara I Vision hela dagen och njuta av en tillställning med oss. Vi kommer att bjuda på allt som har med IaaS att göra, Hybrid kopplingar, System Center, Azure AD och mycket mer än så. Här har du agendan:

om du inte har anmält dej så kan det finnas platser kavr (inte säker, men jag tror det) http://azure.techx.se/?page_id=867

/mike


Categories: MDT

Understanding the Windows ADK for Windows 8.1 Update and MDT 2013

Microsoft Deployment Toolkit Team Blog - Thu, 04/03/2014 - 19:30

Author: Aaron Czechowski, Senior Program Manager

This post applies to customers using the Microsoft Deployment Toolkit (MDT) 2013.

A revision to the Windows Assessment and Deployment Kit (ADK) for Windows 8.1 Update is now available. See this post for more information. If you are also using Configuration Manager see this post. (You’ll find it looks very similar to this post, but there are some differences.)

We recommend that all customers of MDT 2013 upgrade to the latest ADK, but this upgrade is not required. You can continue to use an existing version of the Windows 8.1 ADK or the Windows 8.1 Update revision to service and deploy all Windows 8.1 (including Windows 8.1 Update), Windows 8, and Windows 7 images. If you do upgrade, you don’t have to uninstall the previous version first; running the ADK setup will update the existing components of the ADK installation.

After upgrading the ADK to the latest version, here are a few general items of note for MDT:

  • There are some bug fixes to the User State Migration Tool (USMT) in this revision, so if you use USMT be sure to update the deployment share to refresh the USMT content.
  • You do not need to update the deployment share to update boot images. Windows PE 5.0 can be used to deploy Windows 8.1 Update images.
  • We recommend using the latest full installation source (also known as “slipstreamed” or “refresh” media) for Windows 8.1 Update from the Volume Licensing Service Center (VLSC) as the starting point for your OS deployments. This media should be available on or about 14 April 2014.
  • A Windows 8.1 Update OS image (refresh media or offline serviced) can be applied with the deployment tools natively present in Windows PE 5.0.
  • MDT does not support the new WimBoot functionality at this time. We are investigating adding support for WimBoot to a future release.
Windows PE 5.1

The Windows ADK for Windows 8.1 Update still includes Windows PE 5.0 (including the Windows PE 5.0 optional components and language packs), the same as the previous versions of the Windows ADK for Windows 8.1. The Windows PE documentation references Windows PE 5.1 for supporting WimBoot deployments. (Remember, MDT does not yet support WimBoot.) Windows PE version 5.1 is not needed for MDT and can actually be problematic if you try to use it. Windows PE 5.0 can continue to be used to deploy Windows 8.1 Update. There is a documented process to upgrade Windows PE to version 5.1, but this should be considered incompatible with MDT at this time. Keep reading if you want more details about this, otherwise skip to the next section.

Why can’t MDT use Windows PE 5.1? The process to create Windows PE 5.1 requires injecting the Windows 8.1 Update package into the Windows PE image, and if it also includes optional components or language packs these must be done in a specific order. The process then requires using the DISM /Cleanup-Image option with the /ResetBase parameter to cleanup and optimize the image before unmounting the image and committing the changes. MDT doesn’t currently support this sort of process during boot image servicing. Optimizations aside, even though MDT allows for updates to be injected to Windows PE, the order of operation when applying updates is not guaranteed.

Windows 8.1 Update Servicing

As stated above, we recommend using the latest Windows 8.1 Update full media. If you need to service an existing Windows 8.1 image here are some tips:

  • Windows 8.1 Update (KB2919355) requires a servicing stack update (KB2919442) to be installed as a prerequisite. This prerequisite update was released in March.
  • Do not add KB2919355 to the Packages node of a deployment share. MDT’s servicing functionality uses commands in Unattend.xml, which cannot guarantee the order in which updates are applied to an image.
  • These updates can be manually applied to an image using DISM /Add-Package commands, ensuring the correct order is followed.
  • If applying the updates online, for example during a standard client task sequence, they can be created in the deployment share as Applications. This then allows them to be added to the task sequence as explicit steps for proper ordering.
  • Be sure to fully test the outcome of these actions before deploying your serviced image to clients.
  • Did I mention that we recommend using the Windows 8.1 Update refresh media?
Language Packs

If your images and deployments include language packs, be sure to consider the following:

  • As is always the case, per existing documentation, always install language packs before installing updates.
  • Review the Windows 8.1 Update documentation for language packs to learn about additional details regarding any additional processing that must occur when applying language packs.

We’ve been working closely with Windows engineering on streamlining this process as much as possible. I’m always interested in your feedback, or feel free to post your questions below, especially if there are MDT deployment scenarios not covered here.

-- Aaron Czechowski, Sr. Program Manager

 This posting is provided "AS IS" with no warranties and confers no rights.

Categories: MDT

Another Windows 8.1 Update tip

With the Windows 8.1 Update’s release to MSDN yesterday, people are discovering the various improvements in the new release.  Here’s one that I noticed in PC Settings:

See the new “Manage known connections” link?  Click it and now you can remove existing wireless connections (as long as they weren’t pushed out via Group Policy):

Simple enough.

Categories: MDT

Remove WIFI network back in Windows 8.1 Update 1

Coretech Blog » Kent Agerlund - Thu, 04/03/2014 - 05:34
We had in Windows 7, it was removed in Windows 8.1 – and now it’s back, the ability to “forget” known WIFI networks.  Open your Settings Click Change PC Settings from the list of Settings Select Network From the list of know networks, select the Network and click Forget
Categories: MDT

PowerShell is King–Measure disk performance for IOPS and Transfer rate

The Deployment Bunny - Wed, 04/02/2014 - 11:08
The need

Since I build datacenters I need to verify performance and you can do that using SQLIO. But there is a lot of parameters, a lot of typing and to make testing a bit more consistent I was reading Jose Barreto’s blog http://blogs.technet.com/b/josebda/archive/2013/03/28/sqlio-powershell-and-storage-performance-measuring-iops-throughput-and-latency-for-both-local-disks-and-smb-file-shares.aspx and that gave me inspiration to create a PowerShell script that is a bit more complete and here you can see the result of it. We use this to measure performance on local disks, SMB storage, Storage Spaces, SAN storage, iSCSI storage, basically everything, now it is easy to “spot” the issue, since we have seen the numbers so many times.

Output sample in table format.

Output in Grid view.

The Download

You can download the script from here: http://1drv.ms/1pQNr4i

To use it you need to have SQLIO from Microsoft and you need to store the SQLIO.exe file in the same folder as the script, this way it is easy to move around the test tool as a kit, since SQLIO does not really needs to be installed, the download is an MSI file, so you need to install it once or extract it

You can download SQLIO from here: http://www.microsoft.com/en-us/download/details.aspx?id=20163

The script it is rather easy, it is basically a wrapper for SQLIO.exe but it gives you an output as a table or in a grid. There is two options to measure workload, you either measure IOPS or Transfer rate.

The howto

.\Measure-DiskPerformance.ps1 -TestFileName test.dat –TestFileSizeInGB 1 -TestFilepath C:\VMs -TestMode Get-LargeIO -FastMode True -RemoveTestFile True -OutputFormat Out-GridView

Explanation:

-TestFileName test.dat

The name of the file, it will create the file using FSUTIL, but it checks if it exists and if it does it stops, you can override that with the –RemoveTestFile True

–TestFileSizeInGB 1

Size of the file, it has fixed values, use the TAB key to flip through them

-TestFilepath C:\VMs

The folder, can also be an UNC path, it will create the folder so it does not need to exist.

-TestMode Get-LargeIO

There is too test modes Get-LargeIO or Get-SmallIO, you use Get-LargeIO to measure the transfer rate and you use Get-SmallIO to measure IOPS

-FastMode True

Fastmode true runs each test for just 10 seconds, it gives you a hint, if you don’t set it or set it to false it will run for 60 sec (it will take a break for 10 sec between each run)

-RemoveTestFile True

Removes the test file if it exists

-OutputFormat Out-GridView

Choose between Out-Gridview or Format-Table

/mike


Categories: MDT

Nice to Know–MVP for one more year!

The Deployment Bunny - Tue, 04/01/2014 - 15:31

Friends, I’m happy to inform you that I have been awarded the Microsoft MVP title.

/mike


Categories: MDT

Pages