MDT Powershell: Creating a Driverstore folder structure

I was thinking about my drivers folder and helping people to organise their drivers and I remembered Chris Nackers and Johan Arwidmark had posted scripts to help import drivers into MDT.

I’ve created a script that can be used to generate a driver repository folder structure on a hard drive or network share. The structure is in a format useful to MDT and SCCM.

This screenshot shows a recommended tree structure for organising your drivers.

The structure allows you to separate architecture, OS and models in order to organise drivers and better leverage Selection Profiles within MDT. Another tip is to use the exact make and model descriptions from WMI so you can use variables to target your driver selection.

Thanks to Andy Sibthorp for spotting an obvious flaw in the original code. Here’s my script:

Param(
    $Folder="C:\Downloads\Drivers",
    $archs = "x86","x64",
    $OSs = "Windows PE","Windows XP","Windows 7","Windows 8",
$Makes = "Dell Inc.","Hewlett-Packard","Microsoft Corporation","VMware, Inc"
)

foreach ($arch in $archs) {
    foreach ($OS in $OSs) {
        foreach ($make in $Makes) {
            New-Item -path "$Folder\$OS $arch" -Name "$Make" -Type directory
            }
        }
    }

There are 4 Variables that can be edited to include/exclude OS or Models etc.

The full code is below and in the script repository here.

<#
.SYNOPSIS
Create a Driver Repository for SCCM and MDT drivers.

.DESCRIPTION
The Create-DriverStore.ps1 script will create a folder then populate it with empty subfolders suitable for driver storage.

.PARAMETER Folder
Specifies the path where the folder structure will be created.

.PARAMETER archs
List the architecture(s) that you will be deploying to

.PARAMETER OSs
List the Operating Systems that you will be deploying within your Enterprise

.PARAMETER Makes
List all the Manufacturers of Computers within your organisation

.EXAMPLE
Create-DriverStore.ps1
This will create a New Driver repository in the default recomended location

.EXAMPLE
Create-DriverStore.ps1 -Folder C:\DriverStore
This will create a New Driver repository in C:\DriverStore

.EXAMPLE
Create-DriverStore.ps1 -Folder C:\Downloads\Drivers -archs x86 -OSs "Windows PE","Windows 8" -Makes "Dell Inc.", "VMWare"
This will create a New Driver repository in C:\Downloads\Drivers for x86 Architecture for Windows PE and Windows 8 for models Dell and VMware

.NOTES
Author: Andrew Barnes
Date: 4 June 2012

Version Control:
16 November 2012 - Fixed parameter block

.LINK
Online version: https://scriptimus.wordpress.com
#>

Param (
[String[]]$Folder=("C:\Downloads\Drivers"),
[String[]]$archs = ("x86","x64"),
[String[]]$OSs = ("Windows PE","Windows XP","Windows 7"),
[String[]]$Makes = ("Dell Inc.","Hewlett-Packard","Microsoft Corporation","VMware, Inc")
)

Begin{}
Process{
foreach ($arch in $archs) {
foreach ($OS in $OSs) {
foreach ($make in $Makes) {
New-Item -path "$Folder\$OS $arch" -Name "$Make" -Type directory
}
}
}
}
End{}

My next post will contain my script for importing drivers from this store into MDT. Enjoy.

 

The script is self documenting, open a Powershell Console and type:


Get-Help .\Create-DriverStore.ps1 -Examples

This will show the usage examples like below.

————————– EXAMPLE 1 ————————–

C:\PS>Create-DriverStore.ps1

This will create a New Driver repository in the default recomended location

————————– EXAMPLE 2 ————————–

C:\PS>Create-DriverStore.ps1 -Folder C:\DriverStore

This will create a New Driver repository in C:\DriverStore

————————– EXAMPLE 3 ————————–

C:\PS>Create-DriverStore.ps1 -Folder C:\Downloads\Drivers -archs x86 -OSs “Windows PE”,”Windows 8″ -Makes “Dell Inc.”, “VMWare”

This will create a New Driver repository in C:\Downloads\Drivers for x86 Architecture for Windows PE and Windows 8 for models Dell and VMware

 

Posted in Deployment, MDT 2010, MDT 2012, PowerShell, SCCM | Tagged , , , | 10 Comments

MDT PowerShell: Creating a New Deployment Share

When you perform Actions in MDT you can use the View Script function to replicate the PowerShell commands that you run. This is so you can store them in a custom script to build up your own automation task(s).

Clicking View Script will open notepad and show the code that was ran to perform the task. In this example, to create a new Deployment Share.

This all works great with the exception of the first script you try to automate. The NewDP.Ps1 script only attaches the drive in MDT and populates it with folders and scripts. The remaining stuff is not done in PowerShell. MDT does some sneaky stuff behind the scenes like erm. . . creating a folder and sharing it!!! Meaning you have to script it yourself.

This omission is probably due to the fact that there isn’t a share creation cmdlet built into PowerShell 2.0. Can’t really defend them on creating the folder though. To this end I’ve created my own script to tackle this issue. It’s paramaterized and uses the NET tool built into the Windows command shell. (Yes, I know there are new share scripts and modules on codeplex, don’t email me them please. I want to use the built in software here.)

# \\ Declare Variables
Param (
 [String]$Path="C:\DeploymentShare",
 [String]$PSDriveName="DS001",
 [String]$Description="MDT Deployment Share",
 [String]$ShareName="DeploymentShare$"
 )

# \\ Import MDT Module
Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"

# \\ Create a new Folder
If (!(Test-Path $Path)) {
 New-Item -Path $Path -Type directory -Verbose
 }

# \\ Create a new Deployment Share
New-PSDrive -Name $PSDriveName -PSProvider "MDTProvider" -Root $Path -Description $Description -NetworkPath \\$env:COMPUTERNAME\$ShareName | add-MDTPersistentDrive

# \\ Share Folder
Net Share $ShareName=$Path "/Grant:Everyone,Full" "/Remark:$Description"

Breaking it down, it’s a very straightforward script but the syntax can trip you up if you’re not careful.

These are the Parameters. They have defaults that will create a folder called DeploymentShare in the root of the C: drive, A PS Drive called DS001 , a description and  a hidden  share called DeploymentShare$. You can use -switches on the command line and pass your own values eg -Path D:\DepShare -Description “Scriptimus Share”

# \\ Declare Variables
Param (
 [String]$Path="C:\DeploymentShare",
 [String]$PSDriveName="DS001",
 [String]$Description="MDT Deployment Share",
 [String]$ShareName="DeploymentShare$"
)

This section Imports the new MDT module so we can use the MDT cmdlets later.

# \\ Import MDT Module
Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"

This section, missing from the original MDT script, will create the folder if it does not exist.

# \\ Create a new Folder
If (!(Test-Path $Path)) {
 New-Item -Path $Path -Type directory -Verbose
 }

This line will create the MDT Deployment Share by filling it with the MDT Scripts and default folders so it can be opened in the deployment workbench.

# \\ Create a new Deployment Share
New-PSDrive -Name $PSDriveName -PSProvider "MDTProvider" -Root $Path -Description $Description -NetworkPath \\$env:COMPUTERNAME\$ShareName | add-MDTPersistentDrive

This line, missing from the original MDT script, will share the folder with full control. Full control is needed so you can save your captured images to your Deployment Share and store log files etc.

# \\ Share Folder
Net Share $ShareName=$Path "/Grant:Everyone,Full" "/Remark:$Description"

It has default values and is parameterized so it can be used to create custom deployment shares.

The full script below is self documenting so you can type get-help .\New-DeploymentShare.ps1 to get full usage information.


<#
.SYNOPSIS
Create a new Microsoft Deployment Toolkit Deployment Share.

.DESCRIPTION
The New-DeploymentShare.ps1 script will import the MDT module, Create a folder then create a new Deployment Share based on the parameters supplied in the variables section or passed to the command line.

.PARAMETER Path
Specifies the path to the Deployment Share.

.PARAMETER PSDriveName
Specifies the label for the the PSSDrive created eg. DS001

.PARAMETER Description
A friendly description for the Deployment Share. Useful in a production environment with multiple DeploymentShares.

.PARAMETER ShareName
A new Deployment Share needs to have a network share for remote access. eg: \\Servername\DeploymentShare$

.EXAMPLE
New-DeploymentShare.ps1
This will create a New Deployment Share in the root of C:\ with the default settings

.EXAMPLE
New-DeploymentShare.ps1 -Path C:\MyShare -PSDriveName DS001 -Description "Deployment Share on Scriptimus01" -ShareName DeployShare$
This will create a New Deployment Share with the custom parameters provided

.NOTES
Author: Andrew Barnes
Date: 4 June 2012

.LINK
Online version: https://scriptimus.wordpress.com

#>

# \\ Declare Variables
Param (
 [String]$Path="C:\DeploymentShare",
 [String]$PSDriveName="DS001",
 [String]$Description="MDT Deployment Share",
 [String]$ShareName="DeploymentShare$"
 )

# \\ Import MDT Module
Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"

# \\ Create a new Folder
If (!(Test-Path $Path)) {
 New-Item -Path $Path -Type directory -Verbose
 }

# \\ Create a new Deployment Share
New-PSDrive -Name $PSDriveName -PSProvider "MDTProvider" -Root $Path -Description $Description -NetworkPath \\$env:COMPUTERNAME\$ShareName | add-MDTPersistentDrive

# \\ Share Folder
Net Share $ShareName=$Path "/Grant:Everyone,Full" "/Remark:$Description"

When you  save the file, call it New-DeploymentShare.ps1

Posted in MDT 2012, PowerShell, Scripting | Tagged , , | Leave a comment

MDT PowerShell: New Module in MDT 2012

MDT-PowerShell-2012

Microsoft Deployment Toolkit 2012 now comes with a PowerShell module in addition to the PSSnapIn used in previous versions. In earlier versions of PowerShell in order to start using the PowerShell cmdlets for MDT you would have to add the snap-in by running this command:

Add-PSSnapIn Microsoft.BDD.PSSnapIn

Your scripts will still work with this method and it hasn’t been removed. But now the scripts are called by using a Module with this command:

Import-Module “C:\Program Files\Microsoft Deployment Toolkit\Bin\MicrosoftDeploymentToolkit.psd1”

Using Get-Command –Module you can see that there are cmdlets for the new monitoring service.

image

I’m not sure that this module adds any value as the module would have worked better if deployed to the usual location of  C:\Windows\System32\WindowsPowerShell\v1.0\Modules so you wouldn’t need to type the entire path when calling it. You would also be able to discover it like in this example.

image

I guess I should have spoke up more during the beta testing but I was busy with my new baby. Sorry.

Posted in MDT 2012, PowerShell, Scripting | Tagged , , | 1 Comment

Microsoft Deployment Toolkit (MDT) 2012 RTM now available

Solution Accelerators

Today, Microsoft have released Microsoft Deployment Toolkit (MDT) 2012. I hosts a world of new features and improvements. My favourites are the ability to hide the GUI during deployments and the Validation check fix when deploying to Virtual Machines.

You can download it from the Microsoft Download Centre here.

What’s New in This Release?

  • Integration with Security Compliance Manager Templates
  • Run Windows PowerShell Scripts in Task Sequences
  • Automated Participation in CEIP and WER
  • Improved Guidance for Using SQL Server 2008 R2 with SP1
  • Support for Windows 8 Consumer Preview and Windows Server 8 Beta
  • Support for the Windows Assessment and Deployment Kit (Windows ADK).
  • Monitoring of LTI deployment process.
  • Deployment of Windows Recovery Environment (Windows RE).
  • Deployment of Microsoft Diagnostics and Recovery Toolkit (DaRT).
  • Deployment to computers that use the Unified Extensible Firmware Interface (UEFI).
  • Deployment to computers that require GUID Partition Table (GPT) format.
  • Deployment to virtual hard disks (VHDs) for native boot
  • Support for Windows Thin PC.
  • Support for Windows Embedded POSReady 7
  • Add local administrator accounts wizard step.
  • Deployment Wizard user experience improvements.
  • Support for System Center 2012 Configuration Manager.

What’s Been Removed from This Release?

  • Support for prerelease versions of Configuration Manager 2012
  • Support for installation of MDT on Windows Server 2003
  • Support for installation of MDT on Windows Vista
  • Support for installation of MDT on Windows XP
  • Support for Windows Deployment Services running on Windows Server 2003
  • Original equipment manufacturer task sequence templates from ZTI (Instead, use the prestaged media capabilities in Configuration Manager 2012 and Configuration Manager 2007 R3.)
Posted in Deployment, MDT 2012 | Tagged , , , | 3 Comments

MDT Scripting: Using VBScript Expressions in customsettings.ini file

I received an email from one of my readers:

I’m trying to deploy to a mixed physical / VM environment using the serial number for the OSDComputername. However, on my VMs (VM Ware) the VM serial number is full of spaces.  is there a way to stripe out the spaces on the fly?

Hi there, the answer is yes, there’s a number of ways to tackle this issue so I’ll walk through how I dealt with it.

To begin with, boot into WinPE and take a look at the problem itself, the serial number.

serialnumber

As you can see, it’s a messy one about 40 characters in length, it has leading text, spaces, 2 hyphen and although you can’t see it trailing spaces. VBScript has a number of ways to reformat strings.

If you’ve read any of my scripting articles you will know that you can get a copy of the MDT scripting template and add the following line to output an MDT variable to the console:

wscript.echo oEnvironment.Item("SerialNumber")

Your full code should look like this example:


<job id="Z-Sample">
<script language="VBScript" src="ZTIUtility.vbs"/>
<script language="VBScript">

' //***************************************************************************
' // ***** Script Header *****
' //
' // Solution: Solution Accelerator for Microsoft Deployment
' // File: ZTIComputername.wsf
' //
' // Purpose: Testing MDT Variable Output
' //
' // Usage: cscript ZTIComputername.wsf [/debug:true]
' //
' // Script Version: 1.0.0
' // History:
' //
' // ***** End Header *****
' //***************************************************************************

'//----------------------------------------------------------------------------
'//
'// Global constant and variable declarations
'//
'//----------------------------------------------------------------------------

Option Explicit

Dim iRetVal

'//----------------------------------------------------------------------------
'// End declarations
'//----------------------------------------------------------------------------

'//----------------------------------------------------------------------------
'// Main routine
'//----------------------------------------------------------------------------

On Error Resume Next
iRetVal = ZTIProcess
ProcessResults iRetVal
On Error Goto 0

'//---------------------------------------------------------------------------
'//
'// Function: ZTIProcess()
'//
'// Input: None
'//
'// Return: Success - 0
'// Failure - non-zero
'//
'// Purpose: Perform main ZTI processing
'//
'//---------------------------------------------------------------------------
Function ZTIProcess()

iRetVal = Success

ZTIProcess = iRetval

     wscript.echo oEnvironment.Item("SerialNumber")

End Function

</script>
</job>

Save your script to the DeploymentShare\scripts folder and name it ZTIComputername.wsf. Next, boot your machine from your Lite-Touch media. Then in WinPE navigate to Z:\scripts and type:

cscript ZTIComputername.wsf

This is now the environment that we’ll use to customise the variable and test the results.

Echo serialnumber

Now we need to work on it.

OK, first customise your script with this code below. This is a basic script that outputs both the old and new serial number. I’ve shown the whole function this time to demonstrate where to insert the code in the template.

I’m using the VBScript replace function to remove all the spaces.

Function ZTIProcess()
     iRetVal = Success
     ZTIProcess = iRetval

	wscript.echo vbCRLF & vbCRLF
	wscript.echo "Original SerialNumber: " & oEnvironment.Item("SerialNumber")
	wscript.echo vbCRLF & vbCRLF
	wscript.echo Replace(oEnvironment.Item("SerialNumber")," ","")
	wscript.echo vbCRLF & vbCRLF

End Function

Run the script again and this time the output looks like this (No Spaces):

Replace Spaces

For the next step. Let’s get rid of the hyphens by using the same method. You can simply wrap the existing code in the same method.

	wscript.echo Replace(Replace(oEnvironment.Item("SerialNumber")," ",""),"-","")

Replace Hyphens

Looking good, now let’s strip away the word ‘VMware’ from the start (First 6 charactars, plus 1) then select only 15 characters, the maximum allowed length for a computername.

  	wscript.echo Mid(Replace(Replace(oEnvironment.Item("SerialNumber")," ",""),"-",""),7,15)

Mid Text

Perfect. Now, the question is does that mean you have to write a vbscript to create the computername? No, you can use the expression you created above in the customsettings.ini enclosed in hashes. Here’s the finished solution(it’s a whopper).

OSDComputerName=#Mid(Replace(Replace(oEnvironment.Item("SerialNumber")," ",""),"-",""),7,15)#

Now in the deployment wizard, this is what you’ll see:

Results

There are many other ways of manipulating text in VB. There’s an MSDN manual here. You should be able to use these methods with other variables to tackle further issues.

Posted in MDT 2010, MDT 2012, Scripting | Tagged , , , | 12 Comments

TestLab: Network Design

When creating a test environment, one needs to spend some time pondering the design in order to avoid potential problems.

One past networking issue I had was getting the internet into my labs without bleeding DHCP from my servers into my home network. I solved it in the past by installing the Microsoft Loopback adapter on my guests but this was not ideal. This was especially so when I moved over to VMware workstation and also wanted to use my test laptops in my SCCM testing. Remember, even if your lab is only designed to test server computing, you will still need to learn and configure the basics of networking. My new design will take care of past issues for me. This is how it looks:

Home LAN

You’ll see from previous posts that I’ve purchased a HP Microserver and installed VMware ESXi 5. I’ve also installed an extra NIC. The plan is to have NIC 0 as a management network so I can manage ESXi from my laptop using PowerCLI and the VMware vSphere Client.

In order to achieve the above configuration, within VMware ESX 5 I’ve configured the networking like so:

Network

vSwitch0 is connected to my broadband router and home network. This will serve as a management network so I can WOL the host etc.

vSwitch1 is for guests and test machines only. It will talk to the internal LAN called collective.local and externally to the 2nd network card NIC 1. This will allow physical machines on my test network to receive DHCP and join the domain etc.

There will be 1 internal guest server (COL-Proxy01) that will have 2 network cards installed. Having 1 NIC in each network will allow it to act as a proxy server (Forefront TMG or Squid Virtual Appliance), bringing internet into the labs through vSwitch0 and serving it through vSwitch1. In future experiments I may later need to place COL-Proxy01 in the DMZ.

The end result now is that my test lab is completely isolated from my home network and I can manage and control my guest VM’s from the comfort of my laptop. I have the best of both worlds.

Posted in Testlab | Tagged , , , | Leave a comment

MDT 2010: Imaging to similar hardware

After a Sysprep operation, Hardware is detected and devices reinstall all their drivers. This behaviour is to by design and to be expected.

In many scenarios however, you may not want this to happen. For example, when you create a Virtual Machine template in VMWare or Hyper-V. In these situations the last thing you will want is to wait while Windows detects and installs all the drivers again each time you deploy the image. After all, you know that the hardware will always be the same.

To prevent this there is a setting you can configure in the Unattend.XML file. IT is called PersistentAllDeviceInstalls and it is found in the Microsoft-Windows-PnPSysprep path. I configure this setting when I create the reference image.

Lauch Windows SIM and locate the Microsoft-Windows-PnPSysprep component then right-click and select Add Setting to Pass 3 generalize.

2_thumb[3]

Next ensure the setting is set to True.

3_thumb[2]

Now when you clone a VM or redeploy an image you don’t have to wait that extra 5 minutes while the drivers are being detected and reinstalled.

Posted in MDT 2010 | Tagged , , , | Leave a comment

MDT 2010: Managing Answer Files

Microsoft Windows installation can be automated by the use of answer files. In previous editions, there was a Unattend.txt. These days the answer files are all xml based so you will need to author an Unattend.xml file.

MDT takes the headache out of this because it generates an answer file each time you create a new task sequence. You can customise this answer file using Windows System Image Manager

Windows System Image Manager (Windows SIM) creates and edits the Setup answer files. Each answer file is configured to a specific WIM image. Windows SIM will generate an index of the image into a catalog file with a .clg file extension. This shows what components exist in the associated wim file so you can configure the image specific settings. (Note: An x64 machine cannot generate an x86 catalog file.)

To make sense of Windows answer files, you will need an understanding of deployment Configuration Passes. Configuration Passes describe each of the phases that Windows takes when performing an installation. Not all passes are performed during a setup some Configuration Passes will only run after a Sysprep operation. You could also create an unattend.xml to configure the WindowsPE environment.

Configuration Passes

To edit an answer file

Right-Click the Task Sequence and select properties.

Start

Select the OS Info tab and click the Edit Unattend.xml button.

1

From there you are in Windows SIM and can edit the Unattend.xml file. Many settings in the file are overwritten by MDT during a deployment by using the propertys in the customsettings.ini. I would check to see if there is a setting first before making a change. I have blogged extensively on this topic here. Another great reference is the Unattended Windows Setup Reference on Technet.

Posted in MDT 2010 | Tagged , , , , , | 6 Comments

MDT 2012: Tip – Getting UUID, SerialNumber

I was working at a customers site last year creating a media based Windows 7 deployment for some laptops. I over heard one of the technical leads saying that he was deploying XP to a machine so he could use system information to collect the exact model from the machine. Naturally I offered him a quicker solution for which he was eternally grateful.

Boot into WinPE and type

     WMIC csproduct list /format

This will display the Make, Model and UUID in a formated list collected from WMI. You can use this tool in XP through to Windows 7 and on server editions also. You can find a list of commands using the WMI Command-line Tool tool here.

Posted in Deployment, MDT 2010, MDT 2012 | Tagged , , , , | 1 Comment

MDT 2012: Targeting Lite-Touch Deployments

There are a number of Operating System Deployment scenarios where you will need to automate specific configurations to individual or certain types of computers. The most common scenarios are:

There a number of ways in which to tackle this. One method is to configure the Deployment Database. This involves installing and configuring Microsoft SQL Server or Express but I will cover that topic another day. Another method is to use the Priority reserved property in the customsettings.ini file.

There are a number of ways to target a specific machine. They all evolve around collecting data that is unique to a single or type of computer. For example, each PC or server in your enterprise will have their own Serial Number and UUID. Each network adapter will have its own MAC Address. In some cases you may have configured an Asset Tag in the BIOS. All of this information is available in WMI. You can determine the various computer types, like a particular Manufacturer or Model. You can also determine if the machine is a Server, Laptop, Desktop or Virtual Machine.

This information is useful a you may find that you need to deploy a particular application or configuration only to a very specific type of computer in your environment.

In this example, computers are targeted by their UUID. They share a common Organisation name and Workgroup. The first custom Computer is forced into using the WIN7PRO task sequence and has a mandatory application installed. The second Computer  uses the WIN7ENT  task sequence and has two mandatory applications installed.

[Settings] Priority=UUID, Default
Properties=CustomProperty

[Default]
OSInstall=Y

_SMSTSORGNAME=Scriptimus Ex Machina
JoinWorkgroup=Collective

[6E564D56-15A1-32BD-6049-E5F61008C5A1]
  SkipTaskSequence=YES

   TaskSequenceID=WIN7PRO
   Applications001={0b41ce2c-03a2-49c6-a129-2f6f9e5925ea}

[8F094D56-E366-C6E1-B89B-0FE330393A56]
  SkipTaskSequence=YES
   TaskSequenceID=WIN7ENT

   Applications001={0b41ce2c-03a2-49c6-a129-2f6f9e5925ea}
Applications002={a6e63ac1-0498-406e-8a7c-17876f0a7d49}

The customsettings.ini samples below will demonstrate some other methods and will configure a Computer Name based on a specific criteria.

Automating a Deployment to a Specific Computer


[Settings]
Priority=MACAddress, Default
Properties=CustomProperty

[Default]
OSInstall=Y

[00:37:62:F2:E5:A7]
  OSDComputername=PC01

[09:7A:36:82:98:B4]
  OSDComputername=PC02

Or


[Settings]
Priority=SerialNumber, Default
Properties=CustomProperty

[Default]
OSInstall=Y

[056987]
  OSDComputername=PC01

[053586]
  OSDComputername=PC02

Or


[Settings]
Priority=UUID, Default
Properties=CustomProperty

[Default]
OSInstall=Y

[6E564D56-15A1-32BD-6049-E5F61008C5A1]
  OSDComputername=PC01

[8F094D56-E366-C6E1-B89B-0FE330393A56]
  OSDComputername=PC02

Automating a Deployment to a Specific Make


[Settings]
Priority=MAKE, Default
Properties=CustomProperty

[Default]
OSInstall=Y

[VMWare]
  OSDComputername=VM01

[Dell Inc]
  OSDComputername=PC01

Automating a Deployment to a Specific Model


[Settings]
Priority=Model, Default
Properties=CustomProperty

[Default]
OSInstall=Y

[Latitude D610]
  OSDComputername=PC%SerialNumber%

[HP ProBook 6560b]
  OSDComputername=PC01

Automating a Deployment to a Specific Location


[Settings]
Priority=DefaultGateway, Default
Properties=CustomProperty

[Default]
OSInstall=Y

[DefaultGateway]
  10.0.0.1=Manchester
  172.16.1.1=Birmingham
  172.16.2.1=Birmingham
  172.16.3.1=Birmingham
  10.10.1.1=London
  10.10.2.1=London

[Manchester]
  OSDComputername=MAN%SerialNumber%

[Birmingham]
  OSDComputername=BIR%SerialNumber%

[London]
  OSDComputername=LON%SerialNumber%

Automating a Deployment to a Specific Chassis Type


[Settings]

Priority=...,ByLaptopType,ByDesktopType,ByServerType

[ByLaptopType]

Subsection=Laptop-%IsLaptop%

[ByDesktopType]

Subsection=Desktop-%IsDesktop%

[ByServerType]

Subsection=Server-%IsServer%

[Laptop-True]
  OSDComputername=LAP%SerialNumber%
  Applications001={0b41ce2c-03a2-49c6-a129-2f6f9e5925ea}

[Laptop-False]

[Desktop-True]
  OSDComputername=PC%SerialNumber%

[Desktop-False]

[Server-True]
  OSDComputername=SRV%SerialNumber%

[Server-False]

You can create your own custom deployments based on property information collected in the gather logs.

Posted in Deployment, MDT 2010, MDT 2012 | Tagged , , , , , , | 17 Comments