In MDT Lite Touch, there are two types of drivers to worry about when deploying Windows. There are drivers for Windows PE (the boot image) and there are drivers for the Windows Operating System that you deploy.
Driver management for the boot image is pretty straight , but driver management for the Operating Systems that you deploy is more complex. The real answer is it depends. To simplify I have broken down drivers for the Windows Operating system in to three core scenarios (see later in this post). But first, let's start with the boot image drivers.
Drivers for Windows PE (the boot image)
The boot image you use for deployment is based on Windows PE (a subset of the Windows 10 operating system). For the boot image you need at Nic and Storage drivers at minimum, but sometimes you need to add other drivers as well (such as mouse drivers for remote cards like ILO etc.)
The good thing about Windows PE is that it supports the same hardware as Windows 10, so if you are lucky you don't need to add any drivers at all to it. But in this article you find guidance if you need to add any driver. You also need to set the scratchspace in Windows PE to increase the temporary storage that is used when the Windows setup engine is injecting drivers.
To be successful with boot image drivers in MDT Lite Touch I recommend that you do the following
- Create two folders in Out-Of-Box drivers, name the folders WinPE 5.0 x86 and WinPE 5.0 x64.
- Import any needed x86 drivers into the WinPE 5.0 x86 folder, and any needed x64 drivers into the WinPE 5.0 x64 folder. Note: You should only use Windows 8.1 drivers for the boot images, even if you plan to deploy Windows 7 SP1 with MDT 2013 Lite Touch.

- Create two selection profiles, one named WinPE 5.0 x86 (where you select the WinPE 5.0 x86 folder in Out-Of-Box drivers), and one named WinPE 5.0 x64 (where you select the WinPE 5.0 x64 folder in Out-Of-Box drivers.
- Then configure the deployment share properties to use the correct selection profile. In the Windows PE x86 Components tab, in the Driver Injection area, select the WinPE x86 selection profile. Do the same for Windows PE x64 Components tab, but select the WinPE x64 selection profile.
- Also in the deployment share properties, in the Windows PE x86 Settings tab, in the Lite Touch Boot Image Settings area, set the Scratch space size to 128, do the same in the Windows PE x64 Settings tab.

Drivers for Windows Operating systems
To simplify things I recommend starting with one of three core scenarios when configuring drivers for MDT 2013 Lite Touch. The three scenarios are based on the size of the company, the number of operating systems being deployed, the level of control desired, and the number of hardware models.
Scenario #1 – Total Chaos
This scenario has the following assumptions. This is for a small company, they are only deploying one operating system, say Windows 8.1 x64, and they have a few hardware models from the same vendor. The key things here are that they are deploying just one family of operating systems and that the hardware is from the same vendor. The reason is that the larger vendors do test compatibility among their own models per operating system family, so it's quite rare that a driver from one model will interfere with another driver.
Solution
For this scenario I recommend that you stick with the default simple PnP ID detection based method for drivers. Shorthand story is, just download and extract the drivers for each model to a folder, and import that folder into the Deployment Workbench.

Scenario #2 – Added Predictability
This scenario has the following assumptions. This is a small or midsize company, they are deploying multiple operating systems, say Windows 7 SP1 x64 and Windows 8.1 x64, and they have a few more hardware models but still from the same vendor. The major difference from the first scenario is that are deploying multiple operating systems. Since the default method is using PnP ID detection among all imported drivers we need to have a way of filtering the drivers so that only Windows 7 drivers are considered for Windows 7 SP1 deployments, and that only Windows 8.1 drivers are considered for Windows 8.1 deployments. The feature in MDT 2013 that we can use for this filtering is called Selection Profiles.
Solution
For this scenario I recommend that you use the default PnP ID detection based method with the addition of using selection profiles as a filter for the drivers. The configuration in MDT is that you first create two folders inside Out-of-box drivers, named Windows 7 x64 and Windows 8.1 x64. Then you import the drivers the correct folder in the Deployment Workbench.
After importing the drivers, you create a selection profile created for each operating system driver folder, and then configure the Inject Drivers action in the Task Sequence to use the correct selection profile.


Scenario #3 – Total Control
This scenario has the following assumptions. This is a small, medium or larger company, they are deploying multiple operating systems, say Windows 7 SP1 and Windows 8.1, they have many hardware models, and from multiple vendors. The major difference from the second scenario is that they are using hardware from multiple vendors, and the fact that they want more granular control of their drivers.
Note: This method is my personal favorite, because even if it takes some extra time to setup, I get complete control of the driver injection process.
Anyway, since there are multiple vendors involved, the testing and compatibility matrix between each model cannot be guaranteed if you base detection on PnP only. You need to be able to filter not only on operating system but also on a per model basis. Even though you technically could use selection profiles for this as well, this is not what they were designed for. There is another feature called DriverGroup that will help you do some more advanced filtering.
Solution
For this scenario I recommend that you don't use the default PnP ID detection based method, but instead use DriverGroup as a filter for the drivers. The configuration in MDT 2013 is that you first create two folders inside Out-of-box drivers, for example named Windows 7 x64 and Windows 8.1 x64. Then you create subfolders for each model you have. Then you download and extract the drivers for each model, and per operating system. Then import each per operating system folder and per model into the correct folder in the Deployment Workbench.
Please note that selection profiles and driver groups work together meaning if I have a selection profile including driver A, and a driver group including driver B, both drivers will be added. Most times you only want one or the other but they can be combined. When using drivers per model I recommend you to use the selection profile named Nothing for the Inject Drivers action. The real trick for this scenario is to name the driver folders according to the name of the model, then you can set the DriverGroup001 variable to %Model% in either the Task Sequence or in the rules.
Also, to avoid having issues with drivers not detected by plug and play within the folder (DriverGroup), I recommend forcing driver injection by changing the Inject Drivers action property to "Install all drivers from the selection profile". The property is a bit misleading, because it's also valid for driver groups, but the label does not really say that 🙂



Happy Deployment
/ Johan
Hi Johan, thanks for all the useful tips and tricks. I have setup an MDT share but i am using model alias in my custom ini file to try and keep the character limitations in check (although i suspect this is not actually needed). Any how at the moment I have all of my model alias subfolders just below the Out-of-Box Drivers level and for my DriverGroup001 variable I have just used %ModelAlias% is there a way i can make it less strict with regards to model name? and with regards to the folder structure in MDT, from what i… Read more »
There is still a 260 character total path length limit, and if you want to have MDT be less strict you would have to modify the script injecting drivers (not recommended), or write custom script (better)
Hi Johan! I have been using the Total Control Method for a while now and it has been working great. We deploy Windows 11 23H2 currently with it and have found a couple of models that drivers do not seem to be injecting properly for. Dell Precision 3590, the latest driverpack from Dell's download site or the Dell Command site, the drivers do not install. After rebooting into Windows where appllication installation takes place, I check the device manager and there are tons of drivers that have not been installed. I can see there are drivers being injected in the… Read more »
Nothing I've seen I'm afraid. The setupact.log might yield some clues.
Hi. Thanks for share this post. Its really helpful – even its now 2024 🙂 Have one additional scenario for Total Control – in my environment have some Desktops and Notebooks (Laptops) they are basically from the same vendor – Lenovo – and have similar Hardware, except BIG driver for NVidia Video Cards. There are also just few OEM Desktops with other Hardware and also Nvidia Video Cards.. (Additionaly: Now Nvidia usually share they drivers with 3 options for VideoCards: Quadro Desktop and Notebook NVIDIA Studio Driver GeForce Game Ready Driver But point 2&3 are almost the same one. )… Read more »
I haven't tried multiple drivergroup variables in a loooong time, so I don't know. But it's easy to verify. If the drivers you expect are downloaded to \Drivers on the OS Volume during the WinPE phase, then it worked.
So I understand you download all the system drivers into the windows folder…but what I’m confused about, is there anything that you actually need to put in the WinPE 5.0 x64 and x86 folders? Also I’m deploying windows 11 which doesn’t actually support x86 anyways so is that folder even needed when deploying windows 11 systems?
You only import drivers for WinPE into the WinPE folder, and no, if you support x64 operating systems you don't need the WinPE x86 folder.
What do you mean exactly, “Only add import”? I’m not sure I understand…
Typo, I meant to say you only import (add) drivers for WinPE to the WinPE folder
One downside is that with HP models, lots of their driver packs are for multiple models. So unless there's a way to put a wildcard in the model name folder, you'll have to duplicate driver packs in MDT. For example, you'd need one folder for ProBook 430 G7, and another for ProBook 440 G7, each containing the exact same set of drivers.
HP offers per-model packages for all their business models. I recommend using those packages instead of the family packages. Otherwise, through a custom script you can map family packages to model names. Usually referred to as using a model alias variable.
ModelAlias variable with HP models will have an issue due to length limitation of 256 characters when adding drivers or create offline media iso
For example : HP EliteBook 630 13 inch G9 Notebook PC
You may workaround that by using shorter folder names or put in model exceptions for models with really long names. Other options are changing the script to use the SKU (only four characters) instead of the full model name.
Hi Johan
I really don't know how to put in model exceptions for models with really long names as u say or use SKU for HP models only. Can u share me the way how to do that please ?
Thinking more about it, the HP model name length should actually not be an issue. MDT breaks down the drivers to its own internal structure inside the Out-of-Box Drivers folder. It must be something else… Can you send me a screen dump of the error you are getting? (you can send me a message on LinkedIn with the screenshot)
I'm interested in knowing more about how MDT internally recognizes "DriverGroup001". Is this a special, built-in variable name? How well does %Make% work? Do you have any posts with regard to what core Features should be selected under a Deployment Share's Windows PE tab? Is 128 still a recommended setting for scratch space size? Does this article flow in nicely with your Modern Driver Management article?
I just want to mention that this is the single best source I have seen online with regard to MDT. You have explained everything 1000% better than Microsoft ever has. THANK YOU!
Yes, DriverGroup001 is one of the default arrays that MDT supports, and the %Make% and %Model% are values that MDT populates via WMI during deployment. The driver script are using those to match the make/model with a folder name. You typically don't have to worry about scratchspace settings anymore. Since WinPE 5.0 (2013-2014), the scratch space size is set dynamically depending on memory in the machine. Here is a post that explains the behavior: https://www.deploymentresearch.com/winpe-5-0-scratch-space-in-mdt-2013-and-configmgr-2012-r2/
I ran into this same exact issue when HP decided to lengthen their model names. My solution was to remove the "Make" from the equation. In the Out of box drivers i only list the Models in each of their own folder (no HP parent folder). In the task sequence for DriverGroup001 I only have it look for %model% to match the model and inject the drivers. This removed enough characters to be less than 256.
I also shortened the deployment share name to "DS". Not sure if this made a difference but all the above combined worked for me.
Thanks for the info
Johan, thank you so much for all the great information you provide on deployments have been very helpful for me. I have been having trouble getting total control to work. I thought it was working but lately I have been getting new models and getting the error (picture attached) once the OS installs and boot into windows the first time. When I check the device manager I see know know network drivers installed. A lot of other drivers missing as well. If I check the bdd.log I find that "<![LOG[Filtered.Count: 0]LOG]!><time="10:19:24.000+000" date="01-16-2024" component="ZTIDrivers" context="" type="1" thread="" file="ZTIDrivers">" I had thought… Read more »
The error appears to be related to the build account used. Open a command prompt via F8, and see if you have an IP address and that you can do a net use to the deployment share manually using that account.
As long as the folder name in the workbench is correct, drivers are found by just setting the drivergroup001 variable. No selection profile should be used for the task sequence.
Johan it connected fine in PE environment, it's when the system restarts and logs into Windows 10 the first time. no ethernet drive was loaded. seems it was that the that set drive group was after inject driver group. thank you for the info on the drivergroup001 as well. I was also using your guidance on how to troubleshoot the driver installs using the smts.log and ZTIdrivers.log Is anywhere you find what all different steps, commands etc.do and what they mean? Also, you reference that all the drivers are stored in C:\drivers but i can't seem to find that file… Read more »
Hi Matthew, if you send me a link to the log files from your deployment i can take a quick look. Send me a message on LinkedIn.
Hi Johan, thank you very much for your great blog first.
"I have a question, can I change the variable 'Task Sequence Variable: DriverGroup001' in MDT to a custom name, such as changing DriverGroup001 to ProductDrivers, etc.?"
Thanks a lot.
Nope, the scripts are looking for that variable specifically
HI Johan, thank you for this post. I use the total control method, but i get an message "inaccessible boot device" after first reboot. i have an latitude 5440. i see that the drivers get injected, but after short time – first reboot, the sequence stops. you've further information for me?
Make sure the device is configured for AHCI instead of RAID.
Thank you, Johan. Useful blog.
We try to install the OS on Raid ON mode in Dell Latitude 7440, but getting error attached. With ACHI mode OS installation is fine, no issue. Required Intel Rapid Storage Technology Driver and Application included in the MDT. With older models 7430, 7390 able to install the OS with Raid ON.
Using AHCI is your better option than messing around with the RST drivers. If you absolutely must use RAID please be aware that offline driver injection order matters in WinPE, and you have to use a exit script in MDT to control that order.
Read more here: https://www.deploymentresearch.com/back-to-basics-driver-installation-order-in-winpe-matters/
Great guide!
Do you have a guide like this for the Task Sequences too?
I found bits and pieces out there on Microsoft TechNet forums, but none explained as well as this that I could find.
Thanks!
This guide covers the required MDT Lite Touch Task Sequence configuration, or are you asking about ConfigMgr Task Sequences?
This is an incredibly useful blog. Thanks for your time.
Do I need to recreate the make/model structure for WinPE drivers like I do for the "total control" method? Or can I just import all of the models into my \Out-of-Box Drivers\WinPEx64 folder?
For WinPE Drivers, a single folder works fine. As long as you also create a selection profile for that folder and configure your deployment share to use it.
Hi, Have you ever had the issue when you are building aimage from the task sequence and it just like pauses? We have this issue and the only way have been able to get it to carry on is plug a randomw usb drive in and it all wakes up. Any idea what could be causing the deployment to pause? This is on a Dell3571 Thanks Matt
Can't say I have… Only thing that comes to mind is making sure the power plan is set to high performance, or disable any BIOS settings for power savings…
Any luck imaging Microsoft Surface Laptops?I receive this error. I am not sure what to do.
Either missing network drivers, or indeed invalid credentials to the deployment share, or you haven't relaxed the default permissions for new deployment shares. Try doing a net use command to the deployment share, using the same UNC path, and user account as you have in X:\Deploy\Scripts\Bootstrap.ini, and then try to list the content.
This is a great doc and has been working for me great! It looks like Dell XPS 13 9315 doesn't appear in the list, I believe this is because it's only showing the windows 11 driver link in.Dell Command | Deploy Driver Packs for Enterprise Client OS Deployment | Dell US.
I've added Windows 11 to line 81
where-object { $_.SupportedOperatingSystems.OperatingSystem.osCode -match "(Windows7|Windows8.1|windows10|windows11)"}
This did bring in windows 11 drivers but not XPS 13 9315
How do you inject the drivers if there is no "model" listed. I encountered this on my Asus motherboard, but for some reason MSI motherboard had it listed. Any work around? We're trying to deploy our systems preloaded with the drivers but I can't find a way to work around this "OEM" models. Thank you!
I've been using modelalias scripts to detect strange OEM hardware (ASUS), and set a custom variable in MDT for them. This post explains the use of it: https://www.deploymentresearch.com/using-modelalias-for-configmgr-driver-management/ You just need to add this to MDT instead of ConfigMgr.
Hello, First I apologize for my broken English… This question has been asked several times but I'm stuck on one point. I created a folder for each model we use and I set up a DriverGroup001 variable. What I'm having trouble with is for computers that have never been deployed. I put another task to download all the drivers but now it installs the drivers related to the computer and all the drivers there… I saw this post and I don't know how to know if the folder exists : https://social.technet.microsoft.com/Forums/en-US/e062e2b7-af69-4206-a2c7-f50824554673/mdt-driver-manager-profile-if?forum=mdt I tried several things in the "if statement" but… Read more »
I put together a solution you can use to have MDT fallback to a different driver folder if a model is not found: https://www.deploymentresearch.com/add-driver-fallback-to-mdt-lite-touch/
Hello,
Thanks for making a doc! I copied the script and everything works as I want now, thank you very much.
Cordially,
S. Hepperle
Hello,
Thank you for this very useful documentation.
I have a question regarding new computers. Sometimes I get a blue screen because the drivers haven't been exported yet and the folder isn't created in Out-of-box Drivers.
I saw this post but I can't detect if the folder exists. It installs computer drivers and all drivers.
Thank you in advance for your help.
(sorry for my poor English)
Cordially,
S. Hepperle
Hi Stefan,
Earlier today I put together a solution that allows for a driver fallback setup, in the event a model is missing. That might help this scenario.
I appreciate this is an old post but do you know why I do not have an option to select the Selection Profile under driver injection on the windows PE tab. It is not showing any other drivers to choose from. Should this replicate what is under my Out-Of-Box-Drivers?
You need to create the WinPE x64 selection profile first under Advanced Configuration / Selection Profiles. Then it will show up in the drop down
/ Johan
Hello Johan,
i have problem in Task Sequence Preinstall-New Computer only- Format and Partition disk UEFI.
## Disk(0) was not found. Unable to continue.]LOG]!><time="09:52:32.000+000" date="03-02-2022" component="ZTIDiskpart" context="" type="3" thread="" file="ZTIDiskpart">
<![LOG[## Possible Cause: Missing Storage Driver.]LOG]!><time="09:52:32.000+000" date="03-02-2022" component="ZTIDiskpart" context="" type="3" thread="" file="ZTIDiskpart">
But Inject Drivers is in next steps.
All models is OK. Only Acer TravelMate P215-41 have this problem.
When i check from DISkpart i dont see any disk.
I have add all drivers from acer support for this model to Out-of-Box Drivers
Where should I look for a mistake?
Hi Boris,
Try switching the drives in BIOS to AHCI instead of RAID.
Hi Johan, glad to see you are still responding to this 7-years old thread. Anyway, we are having same issue with Dell 5430 and 5470 models. Although I have downloaded those drivers and added them into Out Of The Box, updated deployment share, etc but somehow we can only image with AHCI but not with RAID ON. We have multiple hardware models but only one or two OS editions to deploy so we are doing Scenario #1 and #2 above. Is there something else that still need to be done such as modify Task Sequence, adding selection profile…? How do… Read more »
Yeah, RAID mode is very picky about the drivers used, sometimes you need to script in older/specific drivers for certain models. Easier to just use AHCI. RAID doesn't add any benefits with a single disk. I recommend the total control method in regard to any driver management.
Hi Johan,
Can i ask about "Set Task Sequence Variable"
Where are you get "Task Sequence Variable : DriverGroup001"
Thank,
PhuocNguyen.
Hi Phuoc,
That's just an action that you add to the task sequence.
Hi Johan, can you help me with some advice? Since after deploying win10, the FileRepository folder weighs 47GB, I realized that I had not configured it along the path of total control, now I did everything according to the instructions of total control.
But nothing has changed, I don’t understand what I’m missing.
Driver folders named, x64\make\model as example x64\HP\HP Z2 Tower G4 Workstation, DriverGroup001 set like – x64\% Make%\% Model%
In Inject Drivers chose selection profile – Nothing
I have no idea.
Hi Andrey,
Kind of hard to know with the information given, but if this is still an issue, please drop me a message on LinkedIn, and I'll try to help.
Do we not also have to do this for the 2nd "Inject Driver" node under post install?
No need, the second driver action just runs the ZTIDrivers.wsf script. / Johan
You may want to add a note that the 'Set DriverGroup' task has to be BEFORE 'inject drivers' in the task sequence for this to work. It wasn't working for me and I heard someone mentioned this in a YouTube video. Sure enough; once I moved it above it worked perfectly. Thanks for the article; very useful.
Hello Johan, this still works great! Thank you so much!
One question though, using the Total Control method; imagine we deploy a new device model and there aren't any model specific drivers for that model in MDT OoBD. Would it be possible to point that device to use, for example, a fallback selection profile with just basic drivers? Or any other way to handle drivers for devices that doesn't have any model specific drivers in MDT?
A few different ways for that, but the easiest is probably having a PowerShell script that looks up tested/certified modules from a list, and sets a variable depending on known and unknown. Then use that variable as a condition on the drivergroup001 action.
Hi Johan, we use the total control process. But we have a lot of devices, especially from Lenovo. For each model we import new drivers and now our "driver-database" is aprox. 50 GB big. But the modelname from Lenovo devices only change at the last 6 letters and the 4 at the beginning specify the "real" device. The last 6 characters are only defining if there is another soundchip, harddisk etc. Is there any chance that we can only import one driverpack for a model (ie 20N20009MB vs 20N2005UMB ) an let this use by MDT? In this case we… Read more »
I use a modelalias script in MDT to normalize the model names for Lenovos. That way I only need to import the right model type, not each variant of it.
Hi Johan, thanks for your answer. Where can we find this script? Can you please share it?
You can find the ModelAliasExit.vbs script here: https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/ModelAliasExit.vbs And here is a post with more details: https://deploymentresearch.com/using-modelalias-for-configmgr-driver-management/
why are we applying the drivergroup and inject drivers pre-install for "OS drivers, and not post install?
MDT copies down the drivers locally, and then using offline serving via dism after the OS image has been applied. Technically, that copying could have been done after applying the OS image as well.
/ Johan
I've tonight come across a good reason for that – when Windows doesn't have the drivers it needs to continue MDT post-install (for me, it was the NIC – Lenovo ThinkCentre M90q on 21H1)
I have a similar issue. W10 1909. I am using the total control process. Have the folders for each model we are using. However, only the HP 705 G5 SFF and Mini are failing with driver related issues. Regardless if I use the ONLINE or OFFline MDT. The issue is that the system reports back a inaccessible boot device blue screen at the point right after the drive is imaged. Saw the sad face. But when running the online, the no device found error happens. Downloaded what was supposed to be the newer hard drive files from HP site. NO… Read more »
Finding the right drivers can be tricky indeed, however for older models to work with newer versions of Windows 10, sometimes not adding a driver at all makes it work. Windows 10 usually takes over driver support when vendors stop.
Hi, so I downloaded your ModelAlias script. What do I set for the DriverGroup001 variable? The link shows to set the customsettings.ini as:
[Settings]
Priority=HardwareInfo, Default
Properties=MakeAlias, ModelAlias, MyCustomProperty
[HardwareInfo]
UserExit=ModelAliasExit.vbs
MakeAlias=#SetMakeAlias()#
ModelAlias=#SetModelAlias()#
When using ModelAlias, you set DriverGroup001 to for example: Windows 10 x64\%ModelAlias%
Assuming your top level folder in Out-Of-Box Drivers is named Windows 10 x64
Hi Johan
Can you kindly tell me how to inject multiple drivers for different models using a single Task Sequence.
I will really appreciate.
Sam
From UK
Scenario #3 is perfect for that. As long as you name the driver folders in the Deployment Workbench to what the model actually is. The DriverGroup001 variable will do the matching.
Do i need to update custom settings.ini file with DriverGroup001, DrivetGroup002
Please let me know
Sam
I usually recommend setting them in the Task Sequence, because it's depending on the OS Family. But if you are only deploying Windows 10, it's fine setting them in the CustomSettings.ini file.
Do i need to create DriverGroup001,002 for each make n model OR one DriverGroup001 is ok for all models.
Let me know pls.
Sam
DriverGroup001 is ok for all models
Hello,
I followed this tutorial :
https://developers.hp.com/hp-client-management/blog/automating-mdt-drivers-hp-client-management-script-library
Injection of the drivers is not working …
On this article the author use the value "Win10\%Product%" for the variable "DriverGroup001".
On your article you use "%Model%", I don't understand the difference …
Could you, please, explain it ?
Thanks and sorry for my poor English.
For HP specifically, the Win32_ComputerSystemProduct class can be used instead of win32_ComputerSystem, but win32_ComputerSystem is more generic across multiple hardware vendors.
That being said, these days I often use a custom variable, ModelAlias, which is set via a userexit script that calls the "best" method depending on vendor.
HI Johan,
Given that I know for example that Lenovo's use a totally different WMI location for the human model name, I am wondering if you would be willing to share that userexit script??? Or at least perhaps give a heads up on which vendors beyond Lenovo that we should be proactively working to ensure that we can get the best possible model name value…
Thanks!!
– Allyn
Sure, here it is: https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/ModelAliasExit.vbs
This is kind of interesting as Im trying to get my MDT 8456 to actually use %product% but it doesnt work. Too long path/names?
The MDT logic is not very good at detecting the product variable. You are better of using a modelaliasexit script for that where you can control which query to run for which vendor/model.
Funny part, it started working shortly after. I bet my customsettings.ini was messed up. I decided to go with a new *.ini and now its working
Thanks for your reply btw:) Can I also ask you and the others a question regarding MDT & joining domain? Somehow MDT has [default] prioritized before [MACAdress]. I have a VM which is suppose to join my domain, i can see that it defaults to join "JoinWorkGroup=<Workgroupname>" instead but why? Joining the domain works just fine by selecting that option instead but I want it automatically based on MAC. Or should I use TSID? In TaskSequence it has JoinWorkGroup ticked instead of JoinDomain Also when is it suppose to apply network settings from cs.ini? It reads the last section of… Read more »
If you want do to per task sequence related settings for workgroup or domain join settings, they have to be re-evaluated by the task sequence. Often its easier to just prompt for workgroup vs. domain in the wizard, but with some clever script you can provide different settings. The trick is to never have workgroup or domain variables both being set.
/ Johan
Thanks for your reply. This is more VM-related, I want every TS to join the domain for that specific VM. Its not a huge thing but I guess I can set TS variables in State Restore for each domain-variable needed? (Domainjoin, Domainadmin,password etc)
Sure, you can always hard code a variable in the task sequence, or via script.
/ Johan
We are using the "Total Control" scenario to inject drivers for different models.
How can we combine this with selection profiles to inject common drivers e.g. for docking stations for all laptops?
I have created a selection profile that matches the name of the Make and Model and selected the model drivers as well as the Displaylink drivers.
Is this the correct way to do this?
Create a folder named "Docking Stations", add the docking station drivers, and use a DriverGroup variable for those. Might have to call the inject drivers step again, it's been a while since I tested using multiple DriverGroup variables.
Hi Johan, I own all your books and I used the "Total Control" scenario since MDT 2010.
However we are in the process of migration to Windows 10. So I bought your book DF vol. 6, that continue to present the "Total Control" as a feasible way to manage the driver, but it simply doesn't work with MDT version 6.3.8456.1000. Are you aware of any bug on this topic? Thanks! 🙂
I posted a topic here https://social.technet.microsoft.com/Forums/en-US/abfbb359-a216-4ea7-92db-c34b39f981e2/using-mdt-version-6384431000-drivers-not-injecting?forum=mdt&prof=required
Thanks for the support 🙂 Now, as far as you question goes. I'm not aware of any bugs. Setting DriverGroup001 works fine in MDT 8456, at least when done in the task sequence. There were no code changes from MDT 8450 in that regard. I posted a more detailed reply in the TechNet forum. If you still can't get it to work, ping me on LinkedIn (https://www.linkedin.com/in/jarwidmark) and I'll see what I can do to help. / Johan
Thanks Johan, luckly I don't have a lot of different computer models and all of them are from HP, so for now I'm using the scenario "Added Predictability" that fits just fine 🙂
Your help is very appreciated, I can forward you a BDD.log for check, maybe the solution is just under my nose…
Follow-up, worked with Gianluigi offline, and it turned out be an incorrect path in CustomSettings.ini / Johan
You just add a "Set Task Sequence Variable" action from the "Add" menu, when editing the task sequence.
/ Johan
Hi,
Great tutorial! How do you get the "Set Drivergroup" step in your task sequence? I don't have it in mine. I just have "Inject Drivers."
Thanks
Absolutely right.. needed the Kernel Mode Driver Framework update in the reference image. Working great again, thanks Johan
You can check the setupact.log and setupapi.dev.log files, but most likely it's either missing kernel mode driver framework update in the reference image, or wrong drivers staged into the driver store.
/ Johan
Dell OptiPlex 7020.. Anyone deploying windows 7 x64 to this?
I tried deploying my current image to it, and as I thought, it booted and errored out because no network drivers, etc. I created an OptiPlex 7020 folder in Out-of-Box DriversWindows 7 x64 in MDT and imported the drivers from dell driver pack. Re-deployed the image to a desktop, now it errors out during "Setup is preparing your computer for first use" and just keeps rebooting after pressing OK. How do I determine what is failing?
Hi Johan,i used scenario #3 deployment solution. My OOBE is structured like your screenshot. I created 3 TS (Windows 7 x32, Windows 7 x64 and Windows 8.1 x64). In each TS i added Task Sequence Variable DriverGroup001 with value "Windows 7 x32%Model%" in the preinstall section just before Inject Driver. My understanding is : 1 – Do i need to add someting in my CS.ini to call my variable DriverGroup001 ?2 – Do i need to modify some script to call my variable DriverGroup001 ?3 – If i choose "Nothing" and "Install all drivers from the selection profiles" in PreinstallInject… Read more »
Nope, you cannot nest task sequences. However, if you have them open side-by-side, you can easily just copy and past actions between them.
/ Johan
Johan,
Thanks for the video.
Another question: do you know if there's a way to call/execute a task sequence from another task sequence? I have a 'template' task sequence that has about 25 driver packages with their corresponding WMI queries, and I'd like my OSD users to leverage that template task sequence from their OSD task sequence. The alternative would be that they would have to update their OSD task sequence with the contents of my template task sequence every time I add a new driver package.
Johan, I'm in the progress of building and testing a new MDT environment at my school. I've built the share, and started testing deployment to the different models we have. So far I have 6 machines tested, 5 Dells and one HP laptop model. The issue I'm having is with the HP laptop. The drivers were imported into the MDT environment in folder OSPlatformModel. Deploying to a Dell Vostro 260s works using this structure (The only other system that needed OOB drivers) – I've set my CS.ini file to start like:[Settings]Priority=Model, DefaultProperties=MyCustomProperty [Vostro 260s]DriverGroup001=Windows 7×86%model%DriverSelectionProfile=nothing [HP ProBook 6455b]DriverGroup002=Windows 7×86%model%DriverSelectionProfile=nothing The… Read more »
RickB,
Check this video: Most is still valid…
Inside Panther: Troubleshooting the Windows Setup Engine
channel9.msdn.com/events/TechEd/NorthAmerica/2011/WCL401
/ Johan
Pitchdown, try configure the inject drivers action to stage all drivers in the selection profile, and not the default pnp-id detection behaviour. Otherwise check dism.log and setupapi.dev.log.
/ Johan
Johan,
Thanks for the video, it's very informative and educational. Another question for you: do you know of any documentation available that shows a process diagram of the imaging process with the respective components (ie drivers, WinPE), and all the different log files and their location depending on where you are in the imaging process?
Added:
the missing drivers are :
ven_8086@dev_0F31@SUBSYS_06031028
ACPINTCF1A1
ACPIDLAC30023&36B2D927&0
ACPIINT33FB1
These are added to the MDT-selection profile, but not installed on the dell venue pro 5130 after installation with mdt2013.
Anybody who knows a solution for this issue?
Hello,
i also try to install the dell venue pro 5130 with MDT.
This is working well, except for 4 drivers (camera-drivers, and sensor-driver).
These drivers are added to MDT, but the hardware is not recognized after the installation.
When pointing to the driver-location manually , the hardware is installed right away.
Any idea why these camera and sensor-devices are not installed with the imported drivers?
Thx
For ConfigMgr you don't use the DriverGroup variable, you use conditions on each driver package that you add to the task sequence.
Check this video recording for details:
A Drivers Saga: Mastering Windows Deployment
channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WCA-B301
/ Johan
Johan,
Thanks for the prompt reply. Can you tell me how the variable should be configured for driver packages instead of drivergroup when using SCCM? Thanks much. Maybe post an explicit article on MDT 2013 Zero Touch Driver Management with screenshots?
In ConfigMgr 2012 you use driver packages (instead of drivegroup), but yes, each package can (and should) have a condition to apply for a specific model.
/ Johan