Below is my import drivers to MDT PowerShell script, also uploaded to the script repository here.
My last post focused on creating a driverstore structure. Now it’s time to import your hard work into MDT. This script will import all your device drivers into MDT detecting and replicating the tree structure. It will also generate the device driver selection profiles for each OS and architecture. Respect to Johan Arwidmark and Chris Nackers who both did somthing similar a while back.
<#
.SYNOPSIS
Imports Windows Drivers into Microsoft Deployment Toolkit.
.DESCRIPTION
The Import-MDTDrivers.ps1 script will duplicate a folder tree structure in Microsoft Deployment Toolkit and import the Drivers.
.PARAMETER $DriverPath
The fully qualified path to the folder that contains the device drivers you want to import. example: "C:\Downloads\Drivers". The default is the current folder in the shell.
.PARAMETER PSDriveName
(Optional) MDT Persistent drive name example: "DS002". The default is the Persistent drive of the first Deployment Share.
.PARAMETER DeploymentShare
(Optional) MDT Persistent drive path example: "D:\Depshare". The default is the first Deployment Share.
.EXAMPLE
Import-MDTDrivers.ps1
This will import drivers from the current location to the driverstore of the first detected deploymentshare replicating the tree structure.
.EXAMPLE
Import-MDTDrivers.ps1 -DriverPath C:\Downloads\Drivers -PSDriveName DS001 -DeploymentShare D:\DeploymentShare
This will import the device drivers into MDT from the source folder C:\Downloads\Drivers to the deployment share DS001 located at D:\DeploymentShare
.NOTES
Author: Andrew Barnes
Date: 4 June 2012
Last Modified: 23 July 2012
.LINK
http://scriptimus.wordpress.com/2012/06/18/mdt-powershell-importing-drivers/
#>
Param (
[String]$DriverPath = $PWD, # Device drivers path example: "C:\Downloads\Drivers"
[String]$PSDriveName, # MDT Persistent drive name example: "DS002"
[String]$DeploymentShare # MDT Persistent drive path example: "D:\Depshare"
)
# \\ Import MDT Module
Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"
# \\ Detect First MDT PSDrive
IF (!$PSDriveName) {$PSDriveName = (Get-MDTPersistentDrive)[0].name}
# \\ Detect First MDT Deployment Share
IF (!$DeploymentShare) {$DeploymentShare = (Get-MDTPersistentDrive)[0].path}
$DSDriverPath = $PSDriveName+':\Out-of-Box Drivers'
$DSSelectionProfilePath = $PSDriveName+':\Selection Profiles'
# \\ Connect to Deployment Share
If (!(Get-PSDrive -Name $PSDriveName -ErrorAction SilentlyContinue)) {
New-PSDrive -Name $PSDriveName -PSProvider MDTProvider -Root $DeploymentShare
}
# \\ Loop through folders and import Drivers
Get-ChildItem $DriverPath | foreach {
$OS = $_
if (!(Test-Path $DSDriverPath\$OS)) {
new-item -path $DSDriverPath -enable "True" -Name $OS -ItemType "folder" -Verbose
}
if (!(Test-Path $DSSelectionProfilePath"\Drivers - "$OS)) {
new-item -path $DSSelectionProfilePath -enable "True" -Name "Drivers - $OS" -Definition "<SelectionProfile><Include path=`"Out-of-Box Drivers\$OS`" /></SelectionProfile>" -ReadOnly "False" -Verbose
}
Get-ChildItem $_.FullName | foreach {
$Make = $_
if (!(Test-Path $DSDriverPath\$OS\$Make)) {
new-item -path $DSDriverPath\$OS -enable "True" -Name $Make -ItemType "folder" -Verbose
}
Get-ChildItem $_.FullName | foreach {
$Model = $_
if (!(Test-Path $DSDriverPath\$OS\$Make\$Model)) {
new-item -path $DSDriverPath\$OS\$Make -enable "True" -Name $Model -ItemType "folder" -Verbose
import-mdtdriver -path $DSDriverPath\$OS\$Make\$Model -SourcePath $_.FullName -Verbose
}
}
}
}
The device drivers in the DriverStore need to be expanded to their *.inf files or MDT wont detect them. For example, MDT will not extract a driver from an exe archive. However, if you’ve downloaded your drivers from Microsoft Update Catalog their *.cab files can be used unexploded.
The deployment workbench will now have the exact same tree structure as your local (or server) driver store.
By default the script will import the drivers from the current (working) folder into the first deployment share in the deployment workbench so of the script is run from the location of the drivers then no parameters are needed. Below is a typical example if you only have 1 deployment share on your computer.
.\Import-MDTDrivers.ps1 -DriverPath C:\Downloads\Drivers
If you have multiple deployment shares, the script can be run from the console with the $PSDriveName and $DeploymentShare variables. parameters, like in this example:
.\Import-MDTDrivers.ps1 -DriverPath C:\Downloads\Drivers -PSDriveName DS001 -DeploymentShare D:\DeploymentShare
Here’s how the script works. The script will browse the device driver directory specified in the $DriverPath variable. It will then create the Operating System folders in MDT if they do not already exist and generate matching Selection Profiles so you can use them later in your task sequences.
At the ‘Make’ level it will create the Manufacturer folder if it does not exist.
At the ‘Model’ folder, if it does not already exist in MDT, it will create the folder and then import the drivers. This means if the script is run a second time it will not create folders if they already exist in MDT. The benefit with this approach is that you can delete any folder(s) and then re-run the script to re-create any element.
If you update the drivers for a particular model you should delete that model in the deployment workbench then run the script again. This will re-create just that model folder and cleanly re-import the drivers again.



I love this, definitely useful for maintaining a driver store. It makes keeping the console organized so much easier, which makes doing targeted rollbacks and/or updates quite a bit easier.
Maybe I’ll experiment combining this with the script to remove duplicate (older/unsigned) drivers.
Thanks for sharing!
I figured out how to do the folder setup, but when i try to run this script i get a lot of errors, when i type .\Import-MDTDrivers.ps1 -DriverPath C:\Downloads\Drivers i get red errors is there something i can do to get this errors from showing up?
What exactly are the errors? Probably the execution policy.