Quick and Dirty Image Factory with MDT and PowerShell

I haven’t written a blog in a while, been busy with the new job at Tanium, but I did write this script recently, and thought I would share, in case anyone else found it interesting. Share it forwards.

Problem

Been working on solutions to upgrade Windows 7 to Windows 10 using Tanium as the delivery platform (it’s pretty awesome if I do say so my self). But as with all solutions, I need to test the system with some end to end tests.

As with most of my OS Deployment work, the Code was easy, the testing is HARD!

So I needed to create some Windows 7 Images with the latest Updates. MDT to the rescue! I created A MDT Deployment Share (thanks Ashish ;^), then created a Media Share to contain each Task Sequence. With some fancy CustomSettings.ini work and some PowerShell glue logic, I can now re-create the latest Windows 7 SP1 patched VHD and/or WIM file at moment’s notice.

Solution

First of all, you need a MDT Deployment Share, with a standard Build and Capture Task Sequence. A Build and Capture Task Sequence is just the standard Client.xml task sequence but we’ll override it to capture the image at the end.

In my case, I decided NOT to use MDT to capture the image into a WIM file at the end of the Task Sequence. Instead, I just have MDT perform the Sysprep and shut down. Then I can use PowerShell on the Host to perform the conversion from VHDX to WIM.

And when I say Host, I mean that all of my reference Images are built using Hyper-V, that way I don’t have any excess OEM driver junk, and I can spin up the process at any time.

In order to fully automate the process, for each MDT “Media” entry. I add the following line into the BootStrap.ini file:

    SkipBDDWelcome=YES

and the following lines into my CustomSettings.ini file:

    SKIPWIZARD=YES            ; Skip Starting Wizards
    SKIPFINALSUMMARY=YES      ; Skip Closing Wizards 
    ComputerName=*            ; Auto-Generate a random Computer Name
    DoCapture=SYSPREP         ; Run SysPrep, but don't capture the WIM.
    FINISHACTION=SHUTDOWN     ; Just Shutdown
    AdminPassword=P@ssw0rd    ; Any Password
    TASKSEQUENCEID=ICS001     ; The ID for your TaskSequence (Upper Case)

Now it’s just a matter of building the LitetouchMedia.iso image, mounting to a Hyper-V Virtual Machine, and capturing the results.

Orchestrator

What I present here is the Powershell script used to orchestrate the creation of a VHDX file from a MDT Litetouch Media Build.

  • The script will prompt for the location of your MDT Deployment Share. Or you can pass in as a command line argument.
  • The script will open up the Deployment Share and enumerate through all Media Entries, Prompting you to select which one to use.
  • For each Media Entry selected, the script will
    • Force MDT to update the Media build (just to be sure)
    • Create a New Virtual Machine (and blow away the old one)
    • Create a New VHD file, and Mount into the Virtual Machine
    • Mount the LitetouchMedia.iso file into the Virtual Machine
    • Start the VM
  • The script will wait for MDT to auto generate the build.
  • Once Done, for each Media Entry Selected, the script will
    • Dismount the VHDx
    • Create a WIM file (Compression Type none)
    • Auto Generate a cleaned VHDx file

Code

The code shows how to use Powershell to:

  • Connect to an existing MDT Deployment Share
  • Extract out Media information, and rebuild Media
  • How to create a Virtual Machine and assign resources
  • How to monitor a Virtual Machine
  • How to capture and apply WIM images to VHDx virtual Disks


#Requires -RunAsAdministrator
<#
.Synopsis
Auto create a VM from your MDT Deployment Media
.DESCRIPTION
Given an MDT Litetouch Deployment Share, this script will enumerate
through all "Offline Media" shares, allow you to select one or more,
and then auto-update and auto-create the Virtual Machine.
Ideal to create base reference images (like Windows7).
.NOTES
IN Addition to the default settings for your CustomSettings.ini file,
you should also have the following defined for each MEdia Share:
SKIPWIZARD=YES ; Skip Starting Wizards
SKIPFINALSUMMARY=YES ; Skip Closing Wizards
ComputerName=* ; AUto-Generate a random computername
DoCapture=SYSPREP ; Run SysPrep, but don't capture the WIM.
FINISHACTION=SHUTDOWN ; Just Shutdown
AdminPassword=P@ssw0rd ; Any Password
TASKSEQUENCEID=ICS001 ; The ID for your TaskSequence (allCaps)
Also requires https://github.com/keithga/DeploySharedLibrary powershell library
#>
[cmdletbinding()]
param(
[Parameter(Mandatory=$true)]
[string] $DeploymentShare = 'G:\Projects\DeploymentShares\DeploymentShare.Win7SP1',
[int] $VMGeneration = 1,
[int64] $MemoryStartupBytes = 4GB,
[int64] $NewVHDSizeBytes = 120GB,
[version]$VMVersion = '5.0.0.0',
[int] $ProcessorCount = 4,
[string] $ImageName = 'Windows 7 SP1',
$VMSwitch,
[switch] $SkipMediaRebuild
)
Start-Transcript
#region Initialize
if ( -not ( get-command 'Convert-WIMtoVHD' ) ) { throw 'Missing https://github.com/keithga/DeploySharedLibrary&#39; }
# On most of my machines, at least one switch will be external to the internet.
if ( -not $VMSwitch ) { $VMSwitch = get-vmswitch -SwitchType External | ? Name -NotLike 'Hyd-CorpNet' | Select-object -first 1 -ExpandProperty Name }
if ( -not $VMSwitch ) { throw "missing Virtual Switch" }
write-verbose $VHDPath
write-verbose $VMSwitch
#endregion
#region Open MDT Deployment Share
$MDTInstall = get-itemproperty 'HKLM:\SOFTWARE\Microsoft\Deployment 4' | % Install_dir
if ( -not ( test-path "$MDTInstall\Bin\microsoftDeploymentToolkit.psd1" ) ) { throw "Missing MDT" }
import-module -force "C:\Program Files\Microsoft Deployment Toolkit\Bin\microsoftDeploymentToolkit.psd1" -ErrorAction SilentlyContinue -Verbose:$false
new-PSDrive -Name "DS001" -PSProvider "MDTProvider" -Root $DeploymentShare -Description "MDT Deployment Share" -Verbose -Scope script | out-string | write-verbose
$OfflineMedias = dir DS001:\Media | select-object -Property * | Out-GridView -OutputMode Multiple
$OfflineMedias | out-string | Write-Verbose
#endregion
#region Create a VM for each Offline Media Entry and Start
foreach ( $Media in $OfflineMedias ) {
$Media | out-string | write-verbose
$VMName = split-path $Media.Root -Leaf
get-vm $VMName -ErrorAction SilentlyContinue | stop-vm -TurnOff -Force -ErrorAction SilentlyContinue
get-vm $VMName -ErrorAction SilentlyContinue | Remove-VM -Force
$VHDPath = join-path ((get-vmhost).VirtualHardDiskPath) "$($VMName).vhdx"
remove-item $VHDPath -ErrorAction SilentlyContinue -Force | out-null
$ISOPath = "$($media.root)\$($Media.ISOName)"
if (-not $SkipMediaRebuild) {
write-verbose "Update Media $ISOPath"
Update-MDTMedia $Media.PSPath.Substring($Media.PSProvider.ToString().length+2)
}
$NewVMHash = @{
Name = $VMName
MemoryStartupBytes = $MemoryStartupBytes
SwitchName = $VMSwitch
Generation = $VMGeneration
Version = $VMVersion
NewVHDSizeBytes = $NewVHDSizeBytes
NewVHDPath = $VHDPath
}
New-VM @NewVMHash -Force
Add-VMDvdDrive -VMName $VMName -Path $ISOpath
set-vm -Name $VMName -ProcessorCount $ProcessorCount
start-vm -Name $VMName
}
#endregion
#region Wait for process to finish, and extract VHDX
foreach ( $Media in $OfflineMedias ) {
$VMName = split-path $Media.Root -Leaf
[datetime]::Now | write-verbose
get-vm -vm $VMName <# -ComputerName $CaptureMachine #> | out-string | write-verbose
while ( $x = get-vm -vm $VMName | where state -ne off ) { write-progress "$($x.Name) – Uptime: $($X.Uptime)" ; start-sleep 1 }
$x | out-string | write-verbose
[datetime]::Now | write-verbose
start-sleep -Seconds 10
$VHDPath = join-path ((get-vmhost).VirtualHardDiskPath) "$($VMName).vhdx"
dismount-vhd -path $VHDPath -ErrorAction SilentlyContinue
$WIMPath = join-path ((get-vmhost).VirtualHardDiskPath) "$($VMName).WIM"
write-verbose "Convert-VHDToWIM -ImagePath '$WIMPath' -VHDFile '$VHDPath' -Name '$ImageName' -CompressionType None -Turbo -Force"
Convert-VHDtoWIM -ImagePath $WIMPath -VHDFile $VHDPath -Name $ImageName -CompressionType None -Turbo -Force
write-verbose "Convert-WIMtoVHD -ImagePath $WIMPath -VHDFile '$($VHDPath).Compressed.vhdx' -Name $ImageName -Generation $VMGeneration -SizeBytes $NewVHDSizeBytes -Turbo -Force"
Convert-WIMtoVHD -ImagePath $WIMPath -VHDFile "$($VHDPath).Compressed.vhdx" -Name $ImageName -Generation $VMGeneration -SizeBytes $NewVHDSizeBytes -Turbo -Force
}
#endregion

Notes

I’ve been struggling with how to create a MDT VHDx file with the smallest possible size. I tried tools like Optimize-Drive and sDelete.exe to clear out as much space as possible, but I’ve been disappointed with the results. So here I’m using a technique to Capture the VHDx file as a Volume to a WIM file (uncompressed for speed), and the apply the Capture back to a new VHDx file. That should ensure that no deleted files are transferred. Overall results are good:

Before:   19.5 GB VHDx file --> 7.4 GB compressed zip
After:    13.5 GB VHDx file --> 5.6 GB compressed zip

Links

Gist: https://gist.github.com/keithga/21007d2aeb310a57f58392dfa0bdfcc2

https://wordpress.com/read/feeds/26139167/posts/2120718261

https://community.tanium.com/s/article/How-to-execute-a-Windows-10-upgrade-with-Tanium-Deploy-Setup

https://community.tanium.com/s/article/How-to-execute-a-Windows-10-upgrade-with-Tanium-Deploy-The-Sensors

https://community.tanium.com/s/article/How-to-execute-a-Windows-10-upgrade-with-Tanium-Deploy-Setup

 

Bypass OEM Setup and install your own image.

AutoPilot

Really Windows Autopilot is the future. As soon as the OEM’s get their act together, and offer machines without the bloatware and adware. Yea, I’m talking about you Anti-Virus Trial! Go away, shoo! Shoo! Give me Signature Images, or I’ll do it myself.

Unfortunately, I’m currently working for a client that is “Cloud Adverse”, and very… particular about Security. “have our machines go through the internet, and download our apps from a cloud, oh heavens no!!”.

So all machines come from the OEM’s and into a centralized distribution center, where they run a hodge-podge of OS Imaging tools to get the machines ready to ship out to each user.

And, No they don’t use any MDT… at least not yet…

Really it’s the Anti AutoPilot…

Where to start.

Well, when the machines arrive from the OEM, they are unboxed and placed on a configuration rack. If they are Desktop Machines, they are also connected to a KVM switch (Imagine several 8-port switches daisy chained together). Then they are plugged into power, network, and turned on.

Here’s our first challenge: How do we stop the PC from booting into the OEM’s OOBE process into OUR process? Well right now the technicians need to press the magic function key press at just the right time during boot up.

You know the drill, Press F12 for Dell, or perhaps press F9 for HP, or Press enter for Lenovo. Perhaps you have a Surface Device, and need to hold down the Volume button while starting the machine. Yuck, but better than nothing…

Well, the feedback we got from the technicians is that sometimes they miss pressing the button… at “just” the right time. This is really a problem for a Desktop PC’s connected to that KVM switch. If the Monitor doesn’t sync to the new PC quickly enough, you might easily miss pressing the boot override switch.

This sounded like a good challenge to start with.

Audit Mode

Really, IT departments don’t use Audit Mode. Audit Mode is a way to make customizations *during* Windows Setup and then re-seal the OS, so the end-user gets the nice shiny Windows Setup process (Specialize and OOBE) that they expect in a new PC.

Deployments in IT are all about bypassing the shiny Windows OOBE experience. No we don’t care about all the fancy new features in Cortana, We have already signed the SA agreement with Microsoft, we already know the domain to connect to, and our company has only one locale and keyboard type. IT departments would much rather skip all that, and get the user to their machine. So the thought of re-sealing a machine and going *back* to OOBE when we just finished joining to the domain and installing apps is silly.

But there are some Possibilities here. Turns out, that when Windows Setup is running, it will look for an Unattend.xml file and try to use it.

Methods for running Windows Setup

MDT uses an Unattend.xml file on the local machine it we can skip over the settings we know about, and re-launch MDT LiteTouch when finished. What about this process? If we place the Unattend.xml file on the root of a removable USB drive, the Windows version on the hard disk will look there and use these settings. The Lab Techs appeared to have a lot of USB sticks laying around, so using them shouldn’t be a problem.

We can’t use a MDT unattend.xml file as-is, but we can use AuditMode to get to a command prompt and install our own MDT LitetouchPE_x64.wim file.

  1. Boot into Audit Mode.
  2. While in Audit Mode, auto login using the Administrator Account.
  3. Find our PowerShell script and run it!


<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
<Reseal>
<Mode>Audit</Mode>
</Reseal>
</component>
</settings>
<settings pass="auditSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="wow64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
<AutoLogon>
<Enabled>true</Enabled>
<LogonCount>5</LogonCount>
<Username>administrator</Username>
</AutoLogon>
</component>
</settings>
<settings pass="auditUser">
<component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
<RunSynchronous>
<RunSynchronousCommand wcm:action="add">
<Description>Run script</Description>
<Order>1</Order>
<!– Enumerate through all drives looking for the MYIT_OEMBypass.ps1 script, if found, run it. Leave the command prompt open. –>
<Path>cmd /c "(FOR %i IN (C D E F G H I J K L N M) DO IF EXIST %i:\MYIT_OEMBypass.ps1 Powershell -executionpolicy ByPass %i:\MYIT_OEMBypass.ps1) & pause"</Path>
<WillReboot>OnRequest</WillReboot>
</RunSynchronousCommand>
</RunSynchronous>
</component>
</settings>
</unattend>

view raw

unattend.xml

hosted with ❤ by GitHub

PowerShell script

Once we are in PowerShell, we now have full access to the system, and can modify it in any we choose. In this case, I have copied a LiteTouchPE_x64.wim file to the USB Stick, and we can force the Hard Drive to boot from that instead, continuing our process in MDT LiteTouch. Yea!


<#
Bypass file for OEM OOBE Setup.
Called from within Audit Mode.
#>
param(
[int] $TargetDisk = 0,
[string] $NewBootWim = "$PSScriptRoot\Generic_x64.wim",
[string] $UserName = 'MDTServer\MDTNonInteractive',
[string] $Password = 'UnSecurePassword1234',
[string] $BootType = 'x64',
[string] $Target = 'h:'
)
$ErrorActionPreference = 'stop'
#region Find the largest on-disk partition
###############################################################################
$TargetDrive = get-disk -Number $TargetDisk |
Get-partition |
Sort -Descending -Property Size |
Select-Object -First 1 |
Get-Volume |
foreach-object { $_.DriveLetter + ':' }
# get a drive letter for the system partition
get-disk -Number $TargetDisk |
get-partition |
where-object { -not $_.DriveLetter } |
Where-Object Type -eq System |
Add-PartitionAccessPath -AccessPath $Target
#endregion
#region Connect to a network share if Source is over the network…
###############################################################################
if ( -not ( test-path $NewBootWim ) ) {
if ( $newBootWim.StartsWith('\\') -and $UserName -and $Password ) {
# COnnect to the network share.
net use "$(split-path $NewBootWim)" /user:$UserName "$Password"
}
}
#endregion
#region Copy the Boot WIM
###############################################################################
new-item -ItemType directory -path $TargetDrive\Sources -Force -ErrorAction SilentlyContinue | Out-Null
copy-item $NewBootWim $TargetDrive\Sources\Boot.wim
robocopy /e $PSScriptRoot\x64 $Target\ /xf bcd bcd.log
#endregion
#region Create a BCD entry
###############################################################################
Bcdedit /create "{ramdiskoptions}" /d "Ramdisk options"
Bcdedit /set "{ramdiskoptions}" ramdisksdidevice boot
Bcdedit /set "{ramdiskoptions}" ramdisksdipath \boot\boot.sdi
$Output = bcdedit -create /d "MYIT_OEMHack" /application OSLOADER
$GUID = $output | %{ $_.split(' ')[2] }
bcdedit /set $Guid device "ramdisk=[$TargetDrive]\sources\boot.wim,{ramdiskoptions}"
bcdedit /set $Guid osdevice "ramdisk=[$TargetDrive]\sources\boot.wim,{ramdiskoptions}"
bcdedit /set $Guid path \windows\system32\boot\winload.efi
bcdedit /set $Guid systemroot \windows
bcdedit /set $Guid detecthal yes
bcdedit /set $Guid winpe yes
bcdedit /set $Guid ems no
bcdedit /set $Guid isolatedcontext yes
Bcdedit /displayorder $Guid -addfirst
Bcdedit /default $Guid
Bcdedit /timeout 10
#endregion
#region Reboot
###############################################################################
write-host "DONE"
shutdown -r -f -t 0
#endregion

Now we have a bridge between the OEM system and our LiteTouch, or any other automated WinPE disk.

Yea! Now for the *REAL* automation to begin… 🙂

-k

 

Windows 1709 In Place Upgrade Bug

Thanks to Johan Arwidmark and Dan Vega for pointing me out to this bug. It took me a while to set up a scenario where it could reproduce, but it’s a good bug. Windows 10 In-Place Upgrade is an important new feature of Windows 10, and it’s good to have MDT support it.

The Bug

When upgrading to Windows 10 Version 1709 using the built-in MDT “Standard Client Upgrade Task Sequence”, you will get an error during OS upgrade within a MDT Wizard page that shows something like:

A VBScript Runtime Error has occurred:
Error: 500 = Variable is undefined

VBScript Code:
-------------------
IsThereAtLeastOneApplicationPresent

At this point, the OS *has* been upgraded, but the Task Sequence can no longer continue.

The Background

During OS upgrades, MDT needs a way to hook into the OS Installation process when done and continue installation tasks in the New OS.

Before In-Place upgrades, MDT would perform this by adding in a custom step into the unattend.xml file. Perhaps you have seen this segment of code before:

<FirstLogonCommands>
 <SynchronousCommand wcm:action="add">
  <CommandLine>wscript.exe %SystemDrive%\LTIBootstrap.vbs</CommandLine>
  <Description>Lite Touch new OS</Description>
  <Order>1</Order>
 </SynchronousCommand>
</FirstLogonCommands>

Windows would run the LTIBootStrap.vbs script, which would call the LiteTouch.wsf script, which would find the existing Task Sequence environment and kick of the remaining steps within the “State Restore” of the Task Sequence.

For the Windows 10 In-Place upgrade process, instead of processing the unattend.xml file, they have their own method of calling back into our LiteTouch environment using a SetupComplete.cmd file. This SetupComplete.cmd is responsible for finding our LiteTouch script and calling it.

The Analysis

It took me a while to setup a repro scenario (my test lab is configured for new-computer scenarios with the Windows 10 Eval bits, which can’t be used in an In-Place upgrade scenario). But I was able to reproduce the issue, and I got the bug, and was able to get the bdd.log file for analysis.

The challenge here is that during In-Place upgrade, I can’t open a Cmd.exe window for debugging using F8 or Shift-F10. Instead I hard coded a “start cmd.exe” line into the SetupComplete.cmd file.

What I observed is that the Window being displayed was the ZTIGather.wsf progress screen. LiteTouch.wsf will kick off the ZTIGather.wsf script early in the process, and will show a customized version of the LiteTouch wizard as a progress dialog. Well clearly the wizard isn’t working properly. But after closer analysis, ZTIGather.wsf shouldn’t be running AT ALL. For some reason, LiteTouch.wsf didn’t recall that it was in the MIDDLE of a task sequence, and that it should just directly go back to the TS in progress.

MDT has two methods for storing variables. When within the SMS Stand Alone Task Sequencing Engine, MDT LiteTouch scripts will read the SMS variables through the Microsoft.SMS.TSEnvironment COM object. But if ZTIUtility.vbs can’t open the variable store, it will store variables locally in the Variables.dat file.

Finally, after getting a powershell.exe window, creating the Microsoft.SMS.TSEnvironment, and making a couple of test calls to verify the contents of the variable store, a surprise. All variables returned empty *Successfully* (which is bad) but writes caused an Exception (which is correct). Since we were not running the SMS Stand Alone Task Sequencing Engine, all calls should have caused an exception.

Why is the Microsoft.SMS.TSEnvironment COM object registered, but not working? Well, that’s still under investigation, but now we can work on a fix/work around for MDT!!!

The Fix

The fix (Not written by me), is to force the Microsoft.SMS.TSEnvironment COM object to unregister before calling LiteTouch.wsf. This can be done by a simple call at the start of the SetupComplete.cmd script:

:: Workaround for incorrectly-registered TS environment
reg delete HKCR\Microsoft.SMS.TSEnvironment /f

The issue has been acknoleged by Microsoft, and this fix is currently targeted for the next release of MDT.

<Code Removed>

Thanks!

k

ZTISelectBootDisk.wsf new with BusType

Several years ago I wrote a script to help select which disk to deploy Windows to during your MDT LiteTouch or ZeroTouch task sequence.

https://keithga.wordpress.com/2013/09/18/ztiselectbootdisk-wsf/

Well, based on a request from my latest client, I have created a similar script that support BusType.

BackGround

My client is trying to install Windows Server 2016 on a Server with a SAN. When the machine boots to WinPE, one of the SAN drives appears *first* as Disk 0 (Zero). By default MDT Task Sequences will deploy to Disk Zero! My ZTISelectBootDisk.wsf already shows how to override. All we need to do is to find a way to tell MDT which disk to choose based on the correct WMI query.

Turns out it was harder than I thought.

What we wanted was the BusType that appears in the “Type” field when you type “Select Disk X” and then “detail disk” in Diskpart.exe.  When we ran “Detail Disk” in DIskpart.exe we could see the bus type: Fibre as compared to regular disks like SCSI or SAS.

The challenge was that the regular Win32_diskDrive WMI query wasn’t returning the BusType value, and we couldn’t figure out how to get that data through other queries.

I tried running some PowerShell queries like ‘Get-Disk’ and noticed that the output type was MSFT_Disk, from a weird WMI Namespace: root\microsoft\windows\storage. But adding that query to the script works! Yea!!!

BusType

What kind of BusTypes are there?

Name Value Meaning
Unknown 0 The bus type is unknown.
SCSI 1 SCSI
ATAPI 2 ATAPI
ATA 3 ATA
1394 4 IEEE 1394
SSA 5 SSA
Fibre Channel 6 Fibre Channel
USB 7 USB
RAID 8 RAID
iSCSI 9 iSCSI
SAS 10 Serial Attached SCSI (SAS)
SATA 11 Serial ATA (SATA)
SD 12 Secure Digital (SD)
MMC 13 Multimedia Card (MMC)
Virtual 14 This value is reserved for system use.
File Backed Virtual  15 File-Backed Virtual
Storage Spaces  16 Storage spaces
NVMe 17 NVMe

For this script we are *excluding* the following devices:

Name Value Meaning
Fibre Channel 6 Fibre Channel
iSCSI 9 iSCSI
Storage Spaces  16 Storage spaces
NVMe 17 NVMe

Meaning that the *FIRST* fixed device not in this list will become the new *Target* OS Disk. Run this query on your machine to see what disk will become the target:

gwmi -namespace root\microsoft\windows\storage -query 'select Number,Size,BusType,Model from MSFT_Disk where BusType <> 6 and BusTy
pe <> 9 and BusType <> 16 and BusType <> 17' | Select -first 1

Requirements

Reminder that this script requires MDT (latest), and the script should be placed in the %DeploymentShare%\Scripts folder. Additionally you should install all the Storage packages for WinPE, sorry I don’t recall *which* packages I selected when I did testing.

Script


<job id="ZTISelectBootDisk">
<script language="VBScript" src="ZTIUtility.vbs"/>
<script language="VBScript" src="ZTIDiskUtility.vbs"/>
<script language="VBScript">
' // ***************************************************************************
' //
' // Copyright (c) Microsoft Corporation. All rights reserved.
' //
' // Microsoft Deployment Toolkit Solution Accelerator
' //
' // File: ZTISelectBootDisk.wsf
' //
' // Version: <VERSION>
' //
' // Purpose: Given a collection of Storage Devices on a machine,
' // this program will assist in finding the correct
' // device to be processed by "ZTIDiskPart.wsf"
' //
' // Currently hard coded to select the *FIRST* drive that is
' // Not iSCSI, Fibre Channel, Storage Spaces, nor NVMe.
' //
' // REQUIRES that you install the correct WinPE Storage Components!
' //
' //
' // WARNING: If there are any *other* disks that need to be Cleaned
' // and formatted, they should be processed first.
' // And this the global Variable OSDDiskIndex should be
' // set to <blank> when done being processed by ZTIDiskPart.wsf.
' //
' // Variables:
' // OSDDiskIndex [ Output ] – Disk Index
' //
' // Usage:
' // cscript.exe [//nologo] ZTISelectBootDisk.wsf [/debug:true]
' // cscript.exe [//nologo] ZTIDiskPart.wsf [/debug:true]
' // cscript.exe [//nologo] ZTISetVariable.wsf [/debug:true] /OSDDiskIndex:""
' //
' // ***************************************************************************
Option Explicit
RunNewInstance
'//—————————————————————————-
'// Main Class
'//—————————————————————————-
Class ZTISelectBootDisk
'//—————————————————————————-
'// Main routine
'//—————————————————————————-
Function Main
Dim oWMIDisk
Dim bFound
Dim oDiskPartBoot
Dim oContext, oLocator, objQuery, objStorageWMI, objStorage
oLogging.CreateEntry "—————- Initialization —————-", LogTypeInfo
IF oEnvironment.Item("DEPLOYMENTTYPE") <> "NEWCOMPUTER" Then
oLogging.ReportFailure "Not a new computer scenario, exiting Select Boot Disk.", 7700
End If
bFound = FAILURE
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'
' 1st Pass – Find any disk that matches the Query "Select * From Win32_diskPartition %OSBootDiskOverrideWQL%"
'
Set oContext = CreateObject("WbemScripting.SWbemNamedValueSet")
oContext.Add "__ProviderArchitecture", 64
Set oLocator = CreateObject("Wbemscripting.SWbemLocator")
set objStorageWMI = oLocator.ConnectServer("","root\Microsoft\Windows\Storage","","",,,,oContext)
set objQuery = objStorageWMI.ExecQuery("select Number,Size,BusType,Model from MSFT_Disk where BusType <> 6 and BusType <> 9 and BusType <> 16 and BusType <> 17")
If objQuery.Count = 0 then
oLogging.CreateEntry "No Disk Drives Found!?!?! Dude, did you install the right storage drivers into WinPE 0x7b.",LogTypeError
exit function
End if
For each objStorage in objQuery
oLogging.CreateEntry "Found Device: N:" & ObjStorage.Number & " S:" & ObjStorage.Size & " M:" & ObjStorage.Model & " T:" & ObjStorage.BusType & " " , LogTypeInfo
oEnvironment.Item("OSDDiskIndex") = ObjStorage.Number
bFound = SUCCESS
exit for
Next
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'
' 2nd pass – Use the 1st Partition larger than 15GB on the first disk with a bootable partition.
'
If bFound = FAILURE then
oLogging.CreateEntry "No drive was found using search parameters, Use the 1st \Windows Partition found.", LogTypeInfo
set oDiskPartBoot = GetBootDriveEx( false, oEnvironment.Item("ImageBuild"), false )
If not oDiskPartBoot is nothing then
oEnvironment.Item("OSDDiskIndex") = oDiskPartBoot.Disk
bFound = SUCCESS
End if
End if
TestAndLog bFound = SUCCESS, "Verify OSDDiskIndex was found and set: " & oEnvironment.Item("OSDDiskIndex")
Main = bFound
End Function
End class
</script>
</job>

-k

 

 

Update CustomSettings.ini file remotely!

Got on a discussion this week with someone how to use PowerShell to update an MDT CustomSettings.ini file over the network. Well a *lot* of CS.ini files.. 🙂

My manager is the Global Ops Manager and now he is asking me to find a way to run [update of customsettings.ini] on about 50 servers worldwide so the other MDT admins don’t have to log onto each server just to add one line.

The example given was to update the AdminPassword in CS.ini. I hope this company is following best practices, and disabling the local Administrator account and/or changing the Password once joined to the domain or connected to SCCM.

Anywho, INI files are a tad bit difficult to modify in Powershell because there are no native PowerShell or .NET functions to perform the action. So instead we need to do some ugly Pinvoke calls to the appropriate Win32 API.

-k


<#
.SYNOPSIS
Update CustomSettings.ini file.
.DESCRIPTION
Updates one or more CUstomSettings.ini files with a common value.
Calling powershell.exe instance must have read/write privelages to the share.
.PARAMETER DeployShares
The full path to the share. Can be input from the pipeline
Example:
c:\DeploymentShare
\\localhost\DeploymentShare$
.PARAMETER Section
The section name to update.
.PARAMETER Name
THe name to update
.PARAMETER Value
The value to write
.EXAMPLE
C:\PS> .\Update-INIFiles -DeployShares c:\DeploymentShare -Section Default -Name AdminPassword -value 'P@ssw0rd'
set a new password in an MDT deployment share
.EXAMPLE
C:\PS> "\\localhost\DeploymentShare$" | .\Update-INIFiles -Section Default -Name AdminPassword -value 'P@ssw0rd'
set a new password in an MDT deployment share, get the file from the pipeline.
C:\PS> type .\MyMDTServerList.txt | .\Update-INIFiles -Section Default -Name AdminPassword -value 'P@ssw0rd'
set a new password in an MDT deployment share, get the list of files from a list of servers passed in through the cmdline.
.EXAMPLE
C:\PS> [Reflection.Assembly]::LoadWithPartialName("System.Web") | out-null
C:\PS> $NewPassword = [System.Web.Security.Membership]::GeneratePassword(10,2)
C:\PS> "The new password will be: $NewPassword"
The new password will be: F{nK:*[L}H
C:\PS> type .\MyMDTServerList.txt | .\Update-INIFiles -Section Default -Name AdminPassword -value $NewPassword
Generate a new random password with powershell, then update all Cs.ini files from a list of servers passed in through the command line.
.LINK
https://foxdeploy.com/2014/09/04/adding-whatif-support-to-your-scripts-the-right-way-and-how-you-shouldnt-do-it/
#>
[cmdletbinding(SupportsShouldProcess=$true)]
param(
[parameter(Mandatory=$true, ValueFromPipeline=$true)]
$DeployShares,
[parameter(Mandatory=$true)]
[string] $Section,
[parameter(Mandatory=$true)]
[string] $Name,
[parameter(Mandatory=$true)]
[string] $Value
)
begin {
## The signature of the Windows API that retrieves INI settings
$signature = @'
[DllImport("kernel32.dll", CharSet=CharSet.Unicode, SetLastError=true)]
public static extern bool WritePrivateProfileString(
string lpAppName,
string lpKeyName,
string lpString,
string lpFileName);
[DllImport("Kernel32.dll")]
public static extern uint GetLastError();
'@
## Create a new type that lets us access the Windows API function
$type = Add-Type -MemberDefinition $signature -Name API -Namespace Win32 -PassThru
}
process {
foreach ( $DPShare in $DeployShares ) {
if ($pscmdlet.ShouldProcess("$DPShare", "CustomSettings.ini write")){
$result = [Win32.API]::WritePrivateProfileString($Section, $Name, $Value, "$DPShare\control\customsettings.ini")
if ( -not $result ) {
$err = [Win32.API]::GetLastError()
throw ( New-Object ComponentModel.Win32Exception ($err -as [int]) )
}
}
}
}

New script – Import Machine Objects from Hyper-V into ConfigMgr

Quick Post, been doing a lot of ConfigMgr OSD Deployments lately, with a lot of Hyper-V test hosts.

For my test hosts, I’ve been creating Machine Objects in ConfigMgr by manually entering them in one at a time (yuck). So I was wondering what the process is for entering in Machine Objects via PowerShell.

Additionally, I was curious how to inject variables into the Machine Object that could be used later on in the deployment Process, in this case a Role.

Up next, how to extract this information from VMWare <meh>.


<#
.SYNOPSIS
Generate a computer list from Hyper-V ready to import into Configuration Manager
.DESCRIPTION
Given a Hyper-V server and a set of Hyper-V Virtual Machines, this script will
extract out the necessary information required to create the associated Machine Object in
Configuration Manager.
.PARAMETER Path
Name of the CSV file to be created
.PARAMETER SourceComputer
Optional parameter used to pre-populate the SourceComputer Field in the CSV output.
.PARAMETER Role
Optional Paramater used to pre-populate the
.NOTES
If you modify this file in Excel, you should save the file in "CSV (MS-DOS) *.csv" format to ensure there are no extra double-quotes present.
.EXAMPLE
.\Get-VMListFOrCM.ps1 | ft
Get all virtual machines and display in a table.
.EXAMPLE
.\Get-VMListFOrCM.ps1 | convertto-csv -NoTypeInformation | % { $_.replace('"','') }
Find all Virtual Machines and convert to a CSV format without any doublequotes.
.EXAMPLE
.\Get-VMListFOrCM.ps1 -Verbose -name hyd-cli* -Role ROLE_Test1 -path .\test.csv
Find all Virtual Machines that start with the name HYD-CLI, and export to .\test.csv
.LINK
https://technet.microsoft.com/en-us/library/bb633291.aspx
#>
[cmdletbinding()]
param (
[string[]] $Name,
[string] $computerName,
[pscredential] $Credential,
[string] $path,
[string] $SourceComputer = '',
[string] $Role = ''
)
$GetVMProp = @{}
if ( $computerName ) { $GetVMProp.add( 'ComputerName',$computerName ) }
if ( $Credential ) { $GetVMProp.add( 'Credential',$Credential ) }
$VitSetData = get-wmiobject -Namespace "Root\virtualization\v2" -class Msvm_VirtualSystemSettingData @GetVMProp
if ( $Name ) { $GetVMProp.add( 'Name',$Name ) }
write-verbose "Extract data from Hyper-V"
$Results = Get-VM @GetVMProp |
ForEach-Object {
[PSCustomObject] @{
ComputerName = $_.Name
'SMBIOS GUID' = $VitSetData |
Where-Object ConfigurationID -eq $_.VMId.Guid |
ForEach-Object { $_.BIOSGUID.Trim('{}') }
'MAC Address' = $_ | Get-VMNetworkAdapter | select-object -first 1 | ForEach-Object { $_.MacAddress -replace '..(?!$)', '$&:' }
'Source Computer' = $SourceComputer
'Role001' = $Role
}
}
$Results | out-string -Width 200 | Write-Verbose
write-verbose "write out to CSV file"
if ( $path ) {
$Results |
ConvertTo-Csv -NoTypeInformation |
ForEach-Object { $_.replace('"','') } |
Out-File -FilePath $path -Encoding ascii
write-verbose @"
You can now import this list into CM:
#############################################
# Sample Script to import into Config Manager
import-module 'C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1'
get-psdrive | Where-Object { $_.Provider.name -eq 'CMSite' } | Select-object -first 1 | ForEach-Object { set-location `"`$(`$_.name)“:`" }
Import-CMComputerInformation -CollectionName "All Systems" -FileName "$Path" -VariableName Role001
#############################################
"@
}
else {
$Results
}

New Sample for MDT (Custom Actions)

MDTLTIPSSampleAction

MDT Litetouch Action Property Page Sample

Fancy Example

Background

MDT has several pre-defined pages for common task sequence editing tasks. You’ve seen them in the MDT Litetouch Task Sequence Editor, under General, Disks, Images, Settings, and Roles.

They help abstract the ugly command line and scripting code behind the scenes for the user.

Recently I had an idea for a super-wiz-bang property page type for MDT Litetouch, and asked “are there any MDT LTI samples out there?”. I knew Config Mgr had a SDK Sample and I’ve been using it for a while now to create SCCM Task Sequence Actions pages.

The answer came back “There was an MDT Litetouch SDK, but not anymore.” (Long story for another day)

“Someone should create a sample!” I said!

“Cool Keith, when you figure it out, can you share the results? :)” For those of you who wonder, how does one become a Microsoft MVP? This, so here we go.

The Basics

C#

MDT Task Sequence Action Pages are simply C# Windows Form Control Library, with some standard API interfaces so it can be called from the Litetouch Wizard Host. The MDT team designed the API to closely resemble the System Center Configuration Manager Action Page API.

  • There are entry points for when the control is initialized.
    • Use this opportunity to load the UI elements with the saved data from the PropertyManager (aka TS.xml)
  • There are entry points for when the “OK” and “Apply” buttons are pressed.
    • Use this opportunity to save the UI elements with to the PropertyManager

There are several dependent classes required by the sample, they are contained in the ‘c:\program files\Microsoft Deployment Toolkit\bin\Microsoft.BDD.Workbench.dll’ assembly, so you will need add this reference to your project.

Anything else you want to add in the control, can be done if you know the correct C# code to get the job done.

Registration

Once you have created the DLL Library, we will need to add it so MDT Litetouch console knows about it.

First off, copy the DLL to the ‘c:\program files\Microsoft Deployment Toolkit\bin’ folder.

Secondly, we’ll need to add an element to the actions.xml file.

<action>
	<Category>General</Category>
	<Name>Install PowerShellGet Action</Name>
	<Type>BDD_MDTLTIPSSampleControl</Type>
	<Assembly>MDTLTIPSSampleAction</Assembly>
	<Class>MDTLTIPSSampleAction.MDTLTIPSSampleControl</Class>
	<Action>powershell.exe -Command  Install-Package -Force -ForceBootStrap -Name (New-Object -COMObject Microsoft.SMS.TSEnvironment).Value('Package')</Action>
	<Property type="string" name="Package" />
</action>

For this sample, I included a PowerShell libary module with two functions, one to register the new control, the other to remove the control. Easy!

The Sample

The sample in this case is pretty small.

https://github.com/keithga/MDTLTIPSSampleAction

There is one TextBox (as shown above), that prompts the user for the name of a PowerShell Package.

The package name get’s added to the TS.XML, along with the command, in this case it calls PowerShell.exe with the cmdlet Install-Package. We use COM to connect to the SMS environment space to get the package name and go.

You can use the build.ps1 script to compile the sample, and create PowerShell library to install the control within MDT Litetouch.

Future

Well I created this sample, because I have some ideas for some MDT LiteTouch (and SCCM) Action controls.

  • Fancy UI for installation of applications through Chocolatey
  • Run scripts and modules from PowerShellGallery.com
  • Other ideas, let me know (comments or e-mail)

Keith

Formatting a removable USB drive with 2 partitions

TL;DR – Starting with Windows 10 Insider Preview Build 14965, you can format any “Removable” USB Flash Drive with more than one partition. Perfect for installation of large (over 4GB) WIM files on UEFI machines!

 

Hey all, back from a week at the Microsoft MVP summit, a Week in the UK, and a week in Arizona.

A few weeks ago at the Microsoft MVP summit, an engineering manager with the Windows Product group made an offhand comment about formatting a removable USB drive with two partitions. This took several of us by surprise, because historically, this hasn’t been supported widely without converting to a Fixed disk or something.

Mike Terrill (and Mike Niehaus) already beat me to the punch with some posts, but I wanted to share my results. :^)

The Background

Why is this important? Well as I mentioned in another blog post, as more and more people are booting to UEFI, on USB flash drives formatted with Fat32, with WIM images over 4GB in size, that causes a problem because Fat32 can’t hold files over 4GB in size.

Another solution would be to use the Rufus tool to split a USB drive into multiple partitions with a hidden fat32 partition. However, the problem here is that the hidden partition uses a special UEFI app that is not signed, so it won’t work on UEFI machines with Secure Boot enabled.

This has become even more interesting since Windows Server 2016 came out, with a base WIM image for standard Server SKU that is over 4GB in size. Hum…

The Hardware

20161126_200856.jpg

I tested on several different USB makes using my Windows 10 (version 1607) laptop. Some would allow me to create a 2nd partition on a removable Flash Drive, others would not giving me an error:

DISKPART> create part pri

No usable free extent could be found. It may be that there is insufficient 
free space to create a partition at the specified size and offset. Specify
different size and offset values or don't specify either to create the maximum 
sized partition. It may be that the disk is partitioned using the MBR disk
partitioning format and the disk contains either 4 primary partitions, (no
more partitions may be created), or 3 primary partitions and one extended
partition, (only logical drives may be created).

Mostly the older and/or cheaper drives didn’t work, but most of the newer and/or name brand drives did work.

Finally I narrowed it down to two different models, both my favorites:

Then I tested against three Operating Systems: Windows 10 Version 1607, Windows 10 Preview, and Windwos 7.0 SP1. All using Diskpart to create multiple partitions.

The script

Diskpart.exe –>

sel disk 1
clean
create part pri size=450
format quick fs=fat32
assign
create part pri
format quick fs=ntfs
assign
exit

The Results:

                                 SanDisk           Transcend
Windows 7 SP1 Build 7601           Pass               Fail
Windows 10  Version 1607           Pass               Fail
Windows 10 Preview 14965           Pass               Pass   

I was able to format my SanDisk into multiple partitions using Windows 7 and beyond.

But I was not able to format the Transcend drive into multiple partitions using Windows 7 or Windows 10 Version 1607, but I was able to partition into multiple partitions on the new Windows 10 Insider Preview 14965.

That’s new!

I haven’t done enough testing using the removable flash drives on older machines, to see if the partitions are still visible, but the results look promising for a start.

Update #1 – 11/28/16:

Found out today that the reason that my SanDisk Extreme disk worked on Windows 7 and Windows 10 1607 may be because the removable Flash disk is reported as “Fixed” rather than “Removable” to the OS. Link.

Update #2 – 11/28/16:

I noticed that when taking the “removable” disk formatted with 2 partitions from Windows 10 Preview 14965 over to Windows 10 Version 1607, only the first partition was visible. As a work around I tried moving the main NTFS partition first and the Fat32 partition second.

sel disk 1
clean
create part pri
shrink desired=450
format quick fs=ntfs
assign
create part pri
format quick fs=fat32
assign
exit

Fix for Windows 1511 ADK bug

First off, yes, I have a new job working for 1e! I’m super excited, and I should have posted something about it, but I’ve been super busy. My first day on the job was at a customer site in Dallas, and I’ve been on the go ever since, working on this and that (stay tuned :^).

As many of you may have known, there has been a pretty big bug in the Windows 10 Version 1511 ADK, it’s caused all kinds of interop problems with Configuration Manager. Well Microsoft released a fix today! KB3143760. Yea!

Well I opened up KB3143760, and yikes! The instructions are a bit dry. Mount this, patch that, watch out for the data streams!

I needed to patch my local Windows 1511 ADK installation because I’m working on a SCCM+MDT Refresh scenario, and I don’t want to uninstall the 1511 ADK. Perfect timing, if only there was a way to automate this..

Repair-1511ADK.ps1

Here is a link to a PowerShell script I wrote to auto-magically patch your WinPE files!

https://onedrive.live.com/redir?resid=5407B03614346A99!158500&authkey=!AHWArN5C7FyRPIY&ithint=file%2cps1

This script will:

  • Download the patch (no need to go through the E-Mail process)
  • Take care of all the stream issues (really I don’t use IE/Edge, so no security streams)
  • Auto extract the patch contents
  • Mount the wim file
  • Patch the appropriate dat files
  • Fix the permissions
  • Dismounts the WIM
  • Cleans up all left over files

So, for example, if you wanted to patch all of the WinPE Wim files in the ADK directory (before importing them into SCCM), you can run the following command:

get-childitem 'C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\*.wim' -recurse | .\Repair-1511ADK.ps1 -verbose

Lately, when programming in PowerShell, I have taken the “write-host considered harmful” rule to heart, so by default, there is *NO* std console output. Instead, I redirect most information output to “verbose”, so if you want to see what is happening in the background, use the -verbose switch.

-k

Hopefully, moving forwards, this will be the *last* time I place a new script up on OneDrive, really I should be moving towards something more… modern… like GitHub.

MDT package now on Chocolatey.org ready for Windows 10!

Been a while since I posted, I’ve been busy with Surface, Windows 10, and other Kits. But my chocolatey package just got approved, so I thought I would share.

I’ve been following the progress of PowerShell’s OneGet, and http://Chocolatey.org for a while now, and thought it was time to stick my toes in and create a package for public use. MDT seemed like a great start.

As you may already know OneGet is a new feature of PowerShell, included in Windows 10 and available through WMF 5.0 that allows for the installation of packages over the internet. Chocolatey is one of the back-end providers, with a great collection of apps ready for installation.

With the recent release of MDT 2013 Update 2, it seemed like a great opportunity to practice my packaging skills. Eventually I created a PowerShell script to auto generate the chocolatey package (not shown here), it would download the MSI files, and extract out the MSI Product Code and Checksum values. You can see the code generated on the Chocolatey MDT page.

Now to install MDT on Windows 10 (or Windows Server 2016), we can run the commands:

set-executionpolicy RemoteSigned; 
Install-Package -Name MDT -ProviderName Chocolatey `
-ForceBootstrap -Force -Verbose

How it works

First step we need to do on clean machine is to set the execution policy:

set-executionpolicy RemoteSigned

Chocolatey has some PowerShell scripts that run in the background, so we need to allow PowerShell to run these commands with the Set-ExecutionPolicy command. Most Powershell users run this command anyways, so it’s not that uncommon.

Then we install the package using the PowerShell 5.0 “Install-Package” cmdlet built into Windows 10:

Install-Package -Name MDT -ProviderName Chocolatey

We must specify the “-ProviderName Chocolatey” parameter the fist time we call Install-Package so the chocolatey Provider is installed, MDT is only known to Chocolatey at this time.

Install-Package will prompt us to confirm installation of the chocolatey provider, we can skip this with the -ForceBootStrap parameter. Additionally, Install-Package will also ask for confirmation before installing MDT, and we can sip the confirmation with the -Force Paramater.

I like to see what is going on the background, so I add the -verbose parameter, and my screen fills with yellow:

Capture

We can see Install-Package downloading MicrosoftDeploymentToolkit2013_x64.msi from the Microsoft web servers.

ADK

The Windows 10 ADK package has also been uploaded to Chocolatey, but hasn’t been officially approved yet, so when you try to run the “windows-ADK” package it will install the older Windows 8.1 version. We can force the Windows 10 ADK to install with a version parameter. Additionally, the default version of the “Windows-ADK” package does not install USMT, so to install everything we will need the “windows-adk-all” package (which is a lot of stuff, sorry).

install-package -ProviderName Chocolatey -Name Windows-ADK-All `
-force -Verbose -MinimumVersion 10.1.10586.0

More information:

https://chocolatey.org/packages/MDT

-k