Empower Microsoft Deployment Toolkit with PowerShell

PowerShell is king when it comes to Windows scripting nowadays. But Microsoft Deployment Toolkit (MDT), the free collection of tools, processes, and guidance from Microsoft for automating desktop and server deployments, is still mostly architected using VBScript. This will probably soon change, however, as you may have read in my recent interview with Michael Niehaus, the director of product marketing for the Windows Commercial team at Microsoft and the chief brains behind the creation and continuing development of MDT. But until MDT is completely rebuilt from the ground up using PowerShell, administrators who deploy Microsoft Windows don’t need to feel they can’t make use of the tremendous power of Windows PowerShell. It’s possible today to use PowerShell in various ways when you use MDT to deploy Windows images to your target machines. This article points you to some resources that can help you get going with this, and also points out a few tricks and gotchas to be aware of.

Using PowerShell as a wrapper with Microsoft Deployment Toolkit

Johan Arwidmark, chief technology officer for TrueSec, is probably one of the best-known Microsoft Deployment Toolkit experts around. Any IT pro who has made the pilgrimage to Microsoft events like MMS, TechEd, or Ignite over the years has probably encountered Johan at least once if they have any interest at all in learning how to deploy Windows properly and efficiently. As a consultant, author and all-around geek specializing in Systems Management and Enterprise Windows Deployment Solutions, Johan likes sharing his knowledge and expertise with other IT pros, and one of the ways he has been doing this is through his website called Deployment Research, which is a site he maintains that is dedicated to sharing information and guidance around System Center, OS deployment, migration and more.

Your first stop when looking for ways to “empower” Microsoft Deployment Toolkit with PowerShell is Johan’s site, and one of the goodies on his site is this example of how you can use PowerShell to run a command during execution of an Microsoft Deployment Toolkit task sequence to create new sites and subnets in Active Directory by tapping into some MDT variables in order to read the log path that MDT is using. What Johan’s example really illustrates is that you can wrap almost any Windows command in a PowerShell script and then either run it as an application or as a command line task in an MDT task sequence. More examples of using PowerShell with MDT can easily be found by searching Johan’s site.

Building a reference image factory

Microsoft Deployment Toolkit
deploymentbunny.com

A truly beautiful use of PowerShell with MDT is the reference image factory that Michael Nystrom built using PowerShell and which is hosted on GitHub for all to use. This image factory creates reference images using MDT running on a Hyper-V host. The result is that for each task sequence you specify, one virtual machine is created and booted, has Windows installed and the resulting image captured, and then has the virtual machine stopped and removed. Michael also works at TrueSec (the same company where Johan works) and is a senior executive consultant as well as a longtime Microsoft Most Valuable Professional (MVP), so he is likewise also committed to sharing his expertise and experience with the worldwide IT community the way that Microsoft MVPs are known to do. His website and blog is affectionately called The Deployment Bunny for reasons that I’m not privy to and hesitate to try to imagine, and although he sometimes posts there in his native Swedish, he also frequently writes posts in English as well. Like Johan, Michael sees tremendous value in utilizing PowerShell scripting together with MDT automation capabilities, and you can find lots of examples of how to do this by searching for his posts tagged as “PowerShell.”

Scriptimus Prime

Another great resource for deployment experts who want to learn more about using PowerShell is the site Scriptimus Ex Machina by Andrew Barnes, who goes by the alternate moniker of Scriptimus Prime. Andrew is a deployment specialist from Manchester, England, and he wrote a terrific guest editorial for our WServerNews newsletter a couple of years ago on the topic of building test labs for when you’re going to be a new system, developing code, undertaking career training, or just evaluating a new software product. Andrew also has numerous examples of using PowerShell with MDT on his blog and they’re well worth spending some time examining in detail as you can learn a lot from some of them.

Script won’t run

A frequent use of PowerShell with Microsoft Deployment Toolkit is having your task sequence call a PowerShell script to perform some action. A common issue that some people experience is that the script they specified in their task sequence doesn’t seem to run as expected, and many have purple marks on their foreheads from banging their heads against the wall for hours on this one.

The key to resolving this frustration (and saving your head) is usually to make sure you set the execution policy properly so the script you specify can run. The execution policy is a PowerShell security construct that determines whether the user can load configuration files, including the user’s PowerShell profile, and run PowerShell scripts on the computer. The execution policy also determines which scripts, if any, have to be digitally signed before they are allowed to run on the computer. The default execution policy for Windows is “Restricted,” which means that configuration files cannot load and scripts cannot be run. Other available options for execution policy include “Bypass,” which is where nothing is blocked and no warnings or prompts are generated; “Unrestricted,” which is where configuration files are loaded and scripts are run but unsigned scripts prompt for permission before they can be run; “RemoteSigned,” which is where configuration files and scripts must be signed by a trusted publisher unless they were written on the local machine; and “All Signed,” which is where configuration files and scripts must always be signed by a trusted publisher even if they were written on the local machine. One trick that is often used when trying to run PowerShell scripts from MDT task sequences is to wrap your script in the following PowerShell command:

powershell.exe -ExecutionPolicy Bypass -File %DEPLOYROOT%\Applications\MyPath\MyScript.ps1

This will temporarily set the execution policy to “Bypass” so your script can run when it’s called as an application from your task sequence. There’s another way, however, that you can get your script to run properly from a task sequence: Make use of the Scripts folder in your deployment share if you’re running MDT 2013. What you do is put your PowerShell script in the Scripts folder and then add a new step called “Run PowerShell Script” to your task sequence. If you do this, then Microsoft Deployment Toolkit automatically knows you need to run your PowerShell script and it will handle this by doing the same as if you had explicitly set the execution policy to “Bypass” as in the example above.

If you have the bandwidth

Finally, for all you deployment freaks out there, if you have about 30GB of bandwidth to spare on your Internet connection you may want to download the Windows 10 Deployment and Management Lab Kit from the Windows IT Center. This free kit provides you with a complete pre-configured virtual lab environment for trying out the new in-place upgrade option for Windows 10 as well as traditional deployment methods. It includes evaluation versions of Windows 10 Creators Update and associated deployment tools like MDT version 8443 and System Center Configuration Manager (SCCM) version 1702 and various other supporting goodies. The Lab Kit also includes a whole bunch of step-by-step illustrated lab guides that take you through various deployment and management scenarios, and, of course, PowerShell figures prominently in some of these labs. Just don’t download it unless you also have several hundred free hours to spare, too!

Photo credit: Freerange Stock

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top