I’m currently doing some intense SCCM 2012 training so I’ve not been posting or in the forums recently. I’ve still been responding to emails though.

I received an email from a reader earlier this week. He wanted to add the current computer to an AD security group during his deployment.

It turns out that I wrote such a script a few weeks earlier. It’s in the repository here.

The script will add the current computer to an AD Group that is set in the customsettings.ini

The script is then run in a task sequence with the command line:

cscript.exe “%SCRIPTROOT%\ZTIAddMember.wsf

The code below is a sample of the customsettings.ini changes.

[Settings]
Priority=Default
Properties=CustomProperty, ADGroup 

[Default]
OSInstall=Y
ADGroup = LDAP://CN=IT Computers,OU=Groups,DC=corp,DC=continuum,DC=com

The code is “As is”. No refunds!

Big news in deployment right now. Microsoft has release a hotfix rollup is for Windows 7 SP1 and Windows Server 2008 R2 SP1. So it’s kinda like Service Pack 1 and a half. There are 4 flavours 2008R2 Itanium/x64 and Windows 7 x86/x64.

You can get it from Microsoft Update Catalog by clicking the link here.

You can then add the updates to your basket and download them.

There’s a Microsoft KB article here. Article KB2775511

The updates are in a format suitable for importing into the Packages folder of your MDT deployment share.

Deployment.
The process of applying operating system images to a computer(sometimes called build). This may also include it’s associated framework inc. drivers, patches, service packs, applications etc. The term is a general phrase that describes the process as a whole.

Windows Image Deployment (WIM Imaging).
This term describes any of the methods used to apply images based on the Windows Imaging file format.  

Operating System Deployment(OSD).
This term can be used literally but usually refers to the deployment of images using the OSD feature of System Center Configuration Manager.

Lite-Touch Deployment (LTI).
This describes the use of Microsoft Deployment Toolkit to apply images. This includes any such  methods including PXE boot with Windows Deployment Services

Zero-Touch Deployment (ZTI).
This describes applying images with System Center Configuration Manager with Microsoft Deployment Toolkit integrated.

User-Driven Installation (UDI).
This is Zero-Touch deployment that is initiatedby a user using the User Driven Installation feature of MDT. It could also refer to any other method of deployment where the user user initiates the build.

Imaging.
The term ‘imaging’ when appending a noun can refer to where the image is being deployed from but it’s not totally accurate terminology. eg WDS Imaging, File Share Imaging, 

Below are a few useful links to various articles on this topic.

Operating System Deployment Terminology This is a glossary of most of the popular imaging process technical terms.

Choosing a Deployment Strategy This post will demystify the terms High Touch, Lite-Touch and Zero-Touch.

Deployment Dilemmas This post will explain the following terms - In-Place Upgrade, New Installation, Refresh and Replace.

No DHCP? No Problem

In this scenario, you have a computer with static IP Address assignments that you wish to maintain during a REFRESH.

There’s a Task Sequence step called Capture Network Settings. This runs the script ZTINICConfig.wsf that can capture network settings and store them in the Variables.dat file.

There are 2 switches of use here in the ZTINICConfig.wsf script. (From the manual)

/ForceCapture -  If there are any local networking adapters with static IP addresses saved, this script captures those settings and saves them to the local environment—for example, C:\MININT\SMSOSD\OSDLogs\Variables.dat. This script can be useful in capturing static IP settings for a large number of computers for automation.

/RestoreWithinWinPE – When specified, applies any saved static IP network settings to the local computer, when appropriate; used for internal processing only.

Use both switches to capture adapter settings in a refresh.

No DHCP? No Problem

In this scenario, the requirement is to boot a lite touch boot image with a static IP address, where is no DHCP available. You can use a custom answer file (unattend.xml) to configure your static IP settings at boot. Below are 2 methods

Method 1 – Netshell

Use the answer file in your extra files folder to run a command line like netsh  during boot. I’ve previously explained how to use the extra files for BGInfo and the process is pretty much the same.

1. Create a folder called ‘ExtraFiles’ (or Extrafiles64) in your deployment share.
2. Next, create a folder called Windows with a subfolder called System32 beneath it.
3. In the Deployment Workbench, Right-Click on the Deployment Share and select properties. Then click on the Windows PE x86 Settings (or Windows PE x86 Settings )Tab
4. In the Windows PE Customizations section browse to the ExtraFiles (or Extrafiles64) folder

Unattend.XML

1. Open Windows System Image Manager and select a DeploymentShare
2. Then select a Windows Image
3. Then create a New AnswerFile
4. Add the following settings to the Answer File in the WindowsPE configuration Pass

Microsoft-Windows-Setup | RunSynchronous | RunSynchronousCommand

5. Add the following settings:

Description=Set Static IP Address
Order=1
Path=netsh interface ip set address Ethernet static 10.0.0.9 255.255.255.0 127.0.0.1

Description=Set Background
Order=2
Path=Bginfo.exe Win_PE.bgi /silent /timer:0 /NOLICPROMPT

Description=Lite Touch PE
Order=3
Path=wscript.exe X:\Deploy\Scripts\LiteTouch.wsf

In this example I am placing the command before BGInfo and Lite Touch PE. Ommit the BGInfo section if you’ve not configured it.

6.  Save the file in your deployment share as \ExtraFiles\Unattend.XML then update the deployment share to recreate the LiteTouchPE_x86.wim (or ISO or x64)

Method 2 – Set a Unicast IP Address

In this method, we use the native settings of the WindowsPE answer file configuration pass.

1. Navigate to Microsoft-Windows-TCPIP | Interfaces | Interface | Ipv4Settings and select Add Setting to Pass 1 windowsPE.

2. Add the following settings:

Ipv4Settings
    DhcpEnabled=false
Metric=10
RouterDiscoveryEnabled=false

3. Under Microsoft-Windows-TCPIP | Interfaces | Interface | UnicastIpAddresses

and select Add Setting to Pass 1 windowsPE.

4. Add an IP Address with the following settings:

Key=1
Value=10.0.0.9/24

5. Navigate to Microsoft-Windows-TCPIP | Interfaces | Interface

and change the Identifier to “Ethernet”.

6. Again, save the file in your deployment share as \ExtraFiles\Unattend.XML then update the deployment share to recreate the LiteTouchPE_x86.wim (or ISO or x64)

Be aware that this method only has very basic IP settings.

No DHCP? No Problem.

Part 1.

I’ve been working on the various methods of setting Static IP addresses during Lite Touch deployments and decided to space the articles out over the week. Today we’ll cover the easy ones.

If you boot into WinPE and find you don’t have an IP Address there are 2 quick ways to configure one. The first is to use the Welcome wizard pane. If you don’t see this pane then remove the line SkipBDDWelcome=YES from your bootstrap.ini file.

Simply click the Configure with Static IP Address button then a new pane will appear where you can enter the IP details.

You can also use netsh to set a static IP via a command prompt.

In this scenario, WINPE uses “Ethernet” as the adapter name. The command is

netsh interface ip set address Ethernet static 10.0.0.9 255.0.0.0 127.0.0.1

In the next post, I'll explain how to automate a Static IP Address during a bare metal boot.

One of the best reasons implementing MDT 2012 is the way it manages your drivers. I had a customer who was using WDS only for deploying their Windows 7 images. They told me that the deployment would halt for around 30 minutes when applying drivers. The problem there was that every driver was being to applied to every machine during deployment. I explained to them a few ways in which MDT could help.

Small Scale

When you create a new Operating System deployment Task Sequence, the default behaviour is to Install only matching drivers from the selection profile. This will save an immense amount of time without you having to do anything.

For small deployments with up to 10 models and only 1 version of Windows these defaults will suffice and I would continue to use them.

Medium Scale

If you have multiple Operating Systems I suggest using the driver selection profiles to isolate each Operating System and Architecture(x86,AMD64).

Large Scale

For larger organisations where you have many makes and models (25+) and multiple OS versions I suggest isolating your Drivers by Operating System/Architecture and Make/Model then dynamically applying the drivers. This will isolate and ensure that only the exact drivers are downloaded in injected during your deployments.

Here’s how it’s done. Organise your drivers by using the driver management methods in my previous posts:

• MDT Powershell: Creating a Driverstore folder structure
• MDT Powershell: Importing device drivers from organised folders

Your drivers will now be organised in a tree hierarchy like in this screenshot.

This time we wont be using the selection profiles so change the selection profile to nothing.

Next, create a new Task Sequence Variable for DriverGroup001 and enter a value for the Operating System root folder then make and model variables.

Now during your deployments, MDT will only apply a small subset of drivers to each model.

You could also do this in the customsettings.ini by adding the DriverGroup property to a specific path. This example demonstrates such a method but assumes you have only 1 Operating System.

[Settings]
Priority=Model, Default
Properties=CustomProperty

[Default]
OSInstall=Y

[OptiPlex 755]
  OSDComputername=PC%SerialNumber%
  DriverGroup001="Windows 7 x86\Dell Inc\OptiPlex 755"

[HP ProBook 6560b]
  OSDComputername=PC01
  DriverGroup001="Windows 7 x86\Hewlett-Packard\HP ProBook 6560b"

This is an updated version of the skipping deployment wizard pages table. This is one of the most popular articles on Scriptimus Ex Machina as it covers most of what is required to automate Lite Touch deployments. Readers use it as a jumping off point to find other articles written here.

If you’re interested in automating your deployments then this table should help. You can also use the value SkipWizard property to completely hide all wizard panes. If you do this however, remember to supply all the required values or your deployments may fail.

There’s a feature in MDT that displays a dropdown list of Domain OU’s in the Lite Touch deployment wizard. There are 2 ways to set it up.

First, you can create a list of OU’s in the customsettings.ini by using the DOMAINOUS variable list. This first example demonstrates this:

This example shows the other method where you create a file in your scripts folder called DomainOUList.xml and list each OU in a separate element:

The result is you now get a dropdown list button next to the Organizational Unit in the deployment wizard.

The list displays the OU’s you entered earlier making it easier to select and reduce errors during deployments.

There’s also an old post by Keith Garner here that shows how to display friendly names.

I was contacted last week by a former colleague who is just getting into MDT. He was missing drivers on one model and received this common error page during his boot sequence. Naturally, I had loads of resources to share but sadly the final part was missing from my blog. The error is:

A connection to the deployment share (\\Server\DeploymentShare$)
could not be made.
The following networking device did not have a driver installed.
PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01

Here’s how to resolve this issue.

This error is very helpful in that it shows the hardware ID of the missing network driver. A quick Google search or visit to Microsoft Update Catalog should find the missing drivers.

Create a Driver Store

After you locate and download the correct driver, create an organised driver store on a local or network drive. I posted a script to do this a few months back. MDT Powershell: Creating a Driverstore folder structure

Import Drivers

Next, import the drivers into the desired Windows PE folder and run the script to import the drivers into the deployment workbench. Again, I created another script to do this a few months back. MDT Powershell: Importing device drivers from organised folders My script will not only creates the driver folders but the selection profiles also.

Check the hardware ID of the imported driver and ensure that it matches the error from earlier.

Apply Selection Profiles

We now need to use selection profiles to ensure that only the Windows PE network drivers get copied to the boot disk, otherwise the boot image can take longer to load.

To do this, right-click the deployment share and select properties. Select the correct platform then the WinPE selection profile.

Recreate the Boot Image

Finally, recreate the boot image by updating the deployment share.

Update your boot media with the newly updated LiteTouchPE_x64.wim file and reboot your client.

I recommend implementing selection profiles like this to isolate your boot drivers and ensure that the boot process runs as fast as possible.