Use PowerShell to Automatically Install and Configure MDT
Summary: Microsoft PowerShell MVP Sean Kearney shows how to use Windows PowerShell to install and to configure MDT automatically. NOTE: Tues Jan 3rd Ed will be speaking at the first meeting of the Madison PowerShell Users Group via live meeting. If you are local to Madison Wis. please join the group in person or remotely through this link. Microsoft Scripting Guy, Ed Wilson, is here. Well, it is time for Part 5 of Windows PowerShell MVP, Sean Kearney’s, most excellent series about using Windows PowerShell with the MDT. Yesterday, we learned about using Windows PowerShell to update Deployment Shares to use the latest operating system service packs. Today Sean will show us how to install and to configure MDT automatically. MDT is truly a synergy of automation. Think about the technologies it leverages. It isn’t only using Windows PowerShell—that’s only one of many pieces it uses. Telling an IT pro to only use Windows PowerShell is foolish. I see jaws dropping all across the internet with that statement…“Sean said WHAT?!” I love Windows PowerShell, that is true. But we have multiple tools available to us for different purposes. In an environment that doesn’t have Windows PowerShell, we still have console apps and VBScript to leverage. MDT provides the perfect example for how we can leverage all of these tools. Most of its environment is based on predefined well-written VBScript scripts. Internally, it uses components from the Windows Automated Installation Kit (Windows AIK) such as DISM.EXE and IMAGEX.EXE to build and capture its images. It uses Windows PowerShell to manage building the environment that manages MDT. I would be a fool to at least not show you the coolest feature in MDT: Automating an installation of MDT and how to automatically build out a basic deployment point of an operating system, applications, and task sequence. Your eyes won’t have to touch VBScript for any of this, but then again, that’s MDT’s job. So we’re going to use some presumptions…just a few.
- We have a DVD rom drive on Drive D with the Windows 7 64-bit edition.
- There is a folder available on USB called F:MDTMedia that has five folders, MDT, WAIK, and Windows Powershell that contain our scripts and .csv files.
- There is a shared folder on the network called \CONTOSO-FILEInstalls that has Office 2010, AdobeReader 9, and a Drivers folder for our data.
This will give us a very basic deployment that you can build on for your own purposes. So we’ll start with the installation of MDT. It will be in a .msi format. To make our life easier, on whatever source you’re placing MDT, you can toss the following line into a setupmdt.cmd batch, then install without prompting by executing.
start /wait msiexec.exe /I C:MDTMediaMDTMicrosoftDeploymentToolkit2010_x64.msi /qb /norestart Note: This is for the 64-bit version. You would change the x64 to x86 if you downloaded the 32-bit media. If you’re feeling adventurous, you can at least automatically start the installation of the Windows AIK. The installer (for whatever reason) is designed as an interactive installation only, and it will not let you do a silent installation. But that doesn’t mean you can’t get it to at least start automatically, as shown here.
start /wait msiexec.exe /I C:MDTMediaWAIKWAITAMD64.msi So now, without lifting a finger (well, maybe one or two), we have at least a wait to get MDT to install without much fuss. But wait! We’re not done! We’re going to leverage the module we built in Part 1 to build that Deployment Share. To make a mini module from the scripts from Part 1 and Part 2, save the content as MyMDTModule.PSM1 file and store it in a folder called, for example, MYMDTMODULE. If you have the MYMDTMODULE folder that contains your PSM1 located in F:MDTMEDIAPowershellMDTSTUFFMYMDTMODULE, you can now import it with the following script.
IMPORT-MODULE F:MDTMEDIAPowershellMDTSTUFFMYMDTMODULE We could now create the new shared folder like this:
NEW-MDTDeploymentShare –Folder ‘C:DeploymentShare’ –Description ‘Deployment Share’ –Share ‘DeploymentShare$’ Now what we need to know for the rest of this, is the DSName and number assigned to our Deployment Share. From this point, we’re going to run MDT cmdlets. Because the new module, MYMDTMODULE, has already loaded in the MDT snap-in, Microsoft.BDD.PSSnapin, we don’t need to load it twice. And like last time, we’ll reconnect our persistent drive as follows:
GET-MDTPersistentDrive
$DSName=(GET-MDTPersistentDrive)[0].Name
$PhysicalPath=(GET-MDTPersistentDrive)[0].Path
$Description=(GET-MDTPersistentDrive)[0].Description
New-PSDrive –Name $DSName -PSProvider MDTProvider –Root $PhysicalPath Remember that I said, “Presume we have Windows 7 on DVD”? We’re going to use a sample script provided by MDT and modify it to import the operating system.
new-item -path “$DSname:Operating Systems” -enable “True” -Name “Windows 7 32bit” -Comments “Windows 7 32bit” -ItemType “folder” -Verbose
import-mdtoperatingsystem -path “$DSName:Operating SystemsWindows 7 32bit” -SourcePath “D:” -DestinationFolder “Windows 7 32bit” –Verbose
We’ll have MDT import some basic applications. I recommend breaking your deployment down as much as possible for easy selection and deselection at the selection profiles level. We’ll use a CSV file like before to import the applications, and we’ll use the same script as last time. Only now we can get a little more creative. Because we’ve already defined the DSName, let’s incorporate that into the script. And let’s eliminate any repetitive data in the CSV file (may as well save on typing and improve consistency wherever possible).
So our CSV file, which is located in F:MDTMEDIAPowershell, will look like this now:
“ApplicationFolder”,”DescriptiveName”,”ShortName”,”Version”,Publisher”,”Language”,”CommandLine”,”WorkingDirectory”,”SourceFolder”,”DestinationFolder”
“Applications”,”Adobe Reader 9″,”Acrobat Reader”,”9″,”Adobe”,”Klingon”,”msiexec.exe /I AcroRead.msi /qb /norestart”,”.ApplicationsAdobe Reader 9″,”\Contoso-FileInstallsAdobeReader”,”Adobe Acrobat Reader 9″
“Applications”,”Office 2010 Standard”,”Microsoft Office”,”2010″,”Microsoft”,”Romulan”,”setup.exe”,”.ApplicationsOffice 2010″,”\Contoso-FileInstallsOffice 2010″,”Office 2010 Standard”
It will now nicely work into this script:
$AppList=IMPORT-CSV C:PowershellMDTCommonApps.csv
Foreach ($App in $Applist) {
import-MDTApplication –path “$DSName:$App.ApplicationFolder” -enable “True” –Name $App.DescriptiveName –ShortName $App.Shortname –Version $App.Version –Publisher $App.Publisher –Language $App.Language –CommandLine $App.CommandLine –WorkingDirectory $App.WorkingDirectory –ApplicationSourcePath $App.SourceFolder –DestinationFolder $App.DestinationFolder –Verbose
} Now that we have an operating system and applications, we should have drivers. Remember that we did that in Part 3? Let’s adapt our CSV file and script in a similar manner so it now references the current DSName. Our FolderName CSV file won’t need to change, only the one for the drivers. The new format will be similar to the one for applications where we no longer reference the DSName in the CSV file. Let’s also improve the script a bit to remove the extra DriverFolders.csv data file. Because “DriverType” is a mimic of the folder name, we’ll let Windows PowerShell use the Test-Path cmdlet to see if it exists, and build it if it does not exist.
“FolderPath”,”DriverType,”Comments”,”Destination Path”,”Model”,”DriverSource”
“Out-of-Box Drivers”,”Network”,”All Network Drivers for the Latitude 6410″,”Out-of-Box Drivers”,”Dell6410″,”\Contoso-fileInstallsDriversDellNetwork”
“Out-of-Box Drivers”,”Video”,”Video Drivers for Latitude 6410″,”Out-of-Box Drivers”,”Dell6410″,”\Contoso-fileInstallsDriversDellVideo”
And now, we add this to our main script to import drivers automatically.
$DriverList=IMPORT-CSV F:MDTMediaPowershellMDTDrivers.csv
Foreach ($Driver in $DriverList) {
IF (!(TEST-PATH “$DSname:Out-of-Box Drivers$Driver.DriverType”)) {
new-item -path “$DSName:Out-of-Box Drivers” -enable “True” –Name $Driver.Drivertype –Comments “” -ItemType “folder” –Verbose
}
new-item -path “$DSName:Out-of-Box Drivers$Driver.Drivertype” -enable “True” –Name $Driver.Model -Comments “All Network Drivers for the Latitude 6410” -ItemType “folder” –Verbose
import-mdtdriver -path “$DSname:Out-of-Box Drivers$Driver.Drivertype$Driver.Model” –SourcePath $Driver.Driversource –Verbose
} The only things you have left to deploy are whatever task sequences you had defined. It’s as easy as importing an application. Create a CSV file with the defined data and then import it. The task sequences I like best are those that perfectly imitate the GUI. Here’s a sample task for a standard client task replace sequence. (This would be a typical scenario in MDT, replacing a workstation). How did I do this? I simply went to MDT, went to create a new task sequence, and took the sample cmdlet at the end! In this particular sequence, we have created a folder based on location in the task sequences, and to keep it organized, we have predefined the Administrator password.
import-mdttasksequence -path “DS002:Task SequencesWallawalla” -Name “Deploy Windows 7” -Template “Client.xml” -Comments “” -ID “Deploy001” -Version “1.0” -OperatingSystemPath “DS002:Operating SystemsWindows 7Windows 7 PROFESSIONAL in Windows 7 install.wim” -FullName “Contoso” -OrgName “Contoso” -HomePage “www.contoso.com” -AdminPassword “Secret123!” -Verbose So again, we grab the details that we need for the CSV file as follows:
“LocationName”,”TaskName”,”Template”,”Comments”,”TaskID”,”Version”,”OSPath”,”FullName”,”OrgName”,”HomePage”,”AdminPW”
”Wallawalla”,”Deploy Windows 7″,”Client.xml”,””,”Deploy001″,”1.0″,”Operating SystemsWindows 7Windows 7 PROFESSIONAL in Windows 7 install.wim” ,”Contoso” ,”Contoso” ,”www.contoso.com”,”Secret123!”
And now, we add a few lines in the script:
$TaskList=IMPORT-CSV F:MDTMEDIAPowershellMDTTasks.csv
Foreach ($Item in $TaskList) {
import-mdttasksequence -path “$DSName:Task Sequences$Item.LocationName” –Name $Item.tasknam –Template $Item.template –Comments $Item.Comments –ID $Item.TaskID –Version $Item.Version -OperatingSystemPath “$DSName:$Item.OSPath” –FullName $Item.Fullname –OrgName $Item.Orgname –HomePage $Item.homepage –AdminPassword $Item.AdminPW -Verbose
} With a little preparation, we have developed the heart of our MDT Deployment Share, an operating system, applications, and drivers. Can we go further? Absolutely! It’s completely possible to build media from scratch, throw in a customsettings.ini file that you would normally use, and even add service packs to the system. You can even build your selection profiles from MDT cmdlets. They turn into an XML file at the end, but you can create them easily with the cmdlets. The beautiful part of MDT is that it is the ultimate example of automation. It uses console tools, VBScript, and Windows PowerShell—all of them used and leveraged in their own unique and special ways. If you’re curious to learn more about MDT, I posted a series on Powershell.ca that ironically doesn’t contain much about Windows Powershell. It’s a fifteen part series called MDT 2010 – From Zero to Deploy. It takes you from the basics to adding that deployment to Windows Deployment Services. By the way, if you ever get to meet Michael Niehaus, thank him for MDT. Just like Windows PowerShell, sometimes the best things in life are free. ~Sean Thank you, Sean, for a great series of blog posts. MDT Week will continue tomorrow when we will have a guest blog written by Microsoft evangelist and author, Matt Hester. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments