Apply a Service Pack to MDT Deployment Shares by Using PowerShell
Summary: Microsoft PowerShell MVP, Sean Kearney, shows how to use Windows PowerShell to update MDT Deployment Shares to the latest service pack. Microsoft Scripting Guy, Ed Wilson, is here. It is time for Part 4 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 organize MDT application and driver folders. Today Sean will show us how to update MDT Deployment Shares to the latest service pack by using Windows PowerShell. One of the coolest things about having MDT to control your deployment setup is the ease of changing the environment. Another cool feature comes when it is time to update the deployed software. If you look at your Deployment Share, it’s just a well-organized structure of folders. These folders are organized right down to operating systems and applications. Although we tell MDT the version of the operating system and the applications, it really has no clue what’s in there. To MDT, it’s just a folder with some stuff in it. Knowing this means that updating components to, for example, newer service packs is actually quite easy. Therefore, to update Windows 7 to Windows Service Pack 1, we could delete the contents of the folder that contains Windows 7 and replace it with the contents of new media with Service Pack 1 through the GUI. We could do that…we could do that if we were living in a world of sadness where Windows PowerShell did not exist. But because such a tragic thing never happened thanks to our great creative friends on the Windows PowerShell team, we absolutely can use Windows PowerShell for this task. So our first task in MDT is to determine the assigned Name for your MDT Deployment Share. To do this, use the Add-PSSnapin to add in the appropriate snap-in. Next, use the Get-MDTPersistentDrive cmdlet to retrieve drive information. These two commands are shown here.
Add-PSsnapin Microsoft.BDD.PSsnapin
GET-MDTPersistentDrive On the screen, you’ll see a list of Deployment Points that are accessible from MDT. In a new scenario, you’ll have one drive that is typically named DS001, but it could be any name. Let’s assume we’re going to work with the first one in the list. To do this, we can index directly into the first drive. This command is shown here.
(GET-MDTPersistentDrive)[0] Now let’s look at that Cmdlet that assigns the DSName as a connection point. The command to assign the DSName uses the New-PSDrive cmdlet. The exact syntax appears here.
New-PSDrive –Name ‘DS001’ -PSProvider MDTProvider –Root ‘C:DeploymentShare’ You’ll see that there are three available Properties that we are interested in. If we look at the display, it seems obvious that the one we want is Name for the DSName and Path for the root of the particular structure in MDT. To recreate this from the variables that we have just pulled, we can use the commands that follow.
$PersistentDrive=(GET-MDTPersistentDrive)[0]
$DSName=$PersistentDrive.Name
$PhysicalLocation=$PersistentDrive.Path
New-PSDrive –Name $DSName –PSProvider MDTProvider –Root $PhysicalLocation So after having done this, we’ll actually have a new drive mount point named DSxxx: for MDT. Like any other Windows PowerShell provider, you can test it by using the Test-Path cmdlet, or simply use the Set-Location cmdlet to change the working location to the newly created drive. The following command changes the working location.
SET-LOCATION “$DSName:” You can update the operating system in MDT in one of two ways. The most obvious way is to add it as a service pack in MDT. Unfortunately, this is the slower of the two processes because it actually has to run the service pack installation upon deployment of a new operating system. The other option is to obtain newer media with the service pack preinstalled. The media, of course, must be the same version as what you had before (for example, Enterprise, OEM, or Retail). To update the operating system, we need to know (at least) the folder where it was installed. If you use the Get-ChildItem cmdlet, you can see the folder names on the Deployment Share. The following command assumes your DSNAME is DS001.
GET-CHILDITEM “$DSNAME:Operating Systems” If you are curious about which revisions of Windows exist (assuming a folder of Windows 7), you can execute the following command.
GET-CHILDITEM ‘$DSNAME:Operating SystemsWindows 7” –recurse Knowing the location, how could you update this? The process is easier than you think. It literally is removing the contents and replacing them. MDT has no real idea about the difference between a Service Pack 1 and an RTM release. It just holds a folder of full of information and a catalog. As long as you are replacing the same exact media with a newer service pack version, we can step to the “real world” and remove the folder contents. We don’t need to use the MDT for that. Remember that we obtained the PhysicalPath property earlier to tell us where the data is. First we want to delete the old content. To do this, use the Get-ChildItem cmdlet, and pipe the objects to the Remove-Item cmdlet. This command is shown here.
GET-CHILDITEM “$PhysicalLocationOperating SystemsWindows 7” –recurse | REMOVE-ITEM –recurse –force Then we update the structure with the new contents from the DVD media (or an ISO file). Let’s presume that the location of the replacement media with Service Pack 1 is on Drive E. We literally copy the data back to the new location. Here is the command to accomplish this task.
COPY-ITEM E:* –Destination “$PhysicalLocationOperating SystemsWindows 7” –recurse –force TaDa! Your operating system in MDT has now been updated to the most current service pack from the provided media. The cool part is that you don’t need to do anything other than rebuild your media. All of your task sequences and other configuration details are identical to what they were before. To update your media, we’ll need to know what name you gave it. To find out the names within Windows PowerShell, use the Get-ChildItem cmdlet in a command similar to the one shown here.
GET-CHILDITEM “$DSName:Media” To update the Media for “WallaWalla”, I use the Update-MDTMedia cmdlet. This command is shown here.
UPDATE-MDTMedia “WallaWalla” Pulling all of these different commands into a single script would look like this.
Add-PSsnapin Microsoft.BDD.PSsnapin
# GET Available MDT points
GET-MDTPersistentDrive
# Work on the First Deployment Share
$PersistentDrive=(GET-MDTPersistentDrive)[0]
# Get the DSname and Physical Location
$DSName=$PersistentDrive.Name
$PhysicalLocation=$PersistentDrive.Path
# Connect up the MDT PersistentDrive
New-PSDrive –Name $DSName –PSProvider MDTProvider –Root $PhysicalLocation
# Remove the contents of an old Windows 7 Folder
GET-CHILDITEM “$PhysicalLocationOperating SystemsWindows 7” –recurse | REMOVE-ITEM –recurse –force
# Replace the contents with fresh DVD Media
COPY-ITEM E:* –Destination “$PhysicalLocationOperating SystemsWindows 7” –recurse –force
# Update the ISO and content folder for ‘WallaWalla’
UPDATE-MDTMedia “WallaWalla” Sure, it took a little time to prepare. But knowing the steps involved, you could update multiple deployment points easily. The other option you have if you’re good with IMAGEX, is to apply a service pack to an operating system and then recapture it to a new .wim file. You can simply replace the INSTALL.WIM that is within your Windows 7 folder structure with your new Gold one (make sure to rename it INSTALL.WIM). Tomorrow we’ll show you how to build a script to automatically build a basic deployment from scratch. You’ll of course have to tweak it, but getting it automatically built…well isn’t that what automation and scripting are all about? ~Sean Sean! Dude, you rock! Thank you so much for this way cool blog post. I invite everyone to join us tomorrow for the exciting conclusion to Sean’s series about using Windows PowerShell and the MDT. 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