With that said, I have a question for you. How many hardware models does your TS support? When we had XP, its TS supported nearly 80 different models. With W7 its 43 as of today. That will just grow during its life. W8.1 is pretty recent and its already about a dozen.
With that many models I found it was adding unnecessary time to a TS processing due to the constant WMI query on each Apply Driver Package step so I changed how I did it years ago.
The most common method people use is to do a
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE “%Precision T3600%”
On each Apply Driver Package step. Works great for sure but it takes longer then pulling a TS variable, especially inside the PE instance that's not as optimized as the full Windows instance. I'd rather cache the data then do the query over and over.
What I did is basically do a single WMI query within our tech interview HTA and pass that to the TS as the variable ‘OSDComputerModel’. Then during a driver step we just do a condition based on the variable. We can use this variable for other tasks in the TS and TS Variable exports during failures capture the model also via this variable.
For something like the Dell Venue 11 you can add multiple models as a variable, as one driver package could support multiple devices.
The only system that I have found does not work well is the Panasonic FZ-G1 tablet. Their computer name is all over the place so its easier to do the query on the step with % wildcard as it starts with 'FZ-G1' and a bunch of letters (FZ-G1AAHAFLM for example) then the recently released Mark II changed it to 'FZ-G1-2' and a bunch of letters.
Overall, this query is the same output as doing ‘wmic csproduct get name’ via a shell which is an easy way to figure out what it will be populated with, even in PE.
C:\Users\Kevin>WMIC csproduct get name
Name
Precision T3600 We also normalize it by removing spaces and what not so its more friendly to work with then doing a WMI query during a driver step and dealing with LIKE and other operators.
To further streamline the deployment process, we also look at the chassis and spit that out via ‘OSDChassis’ variable. If it’s certain chassis types (8-14), it’s a laptop, if not it’s a desktop. This allowed us to group them together in the TS. This means that if you’re on a laptop, it skips ALL the Desktop steps since the parent Desktops group has a condition for desktops which does not match. As we move more to Windows 8.1 and 10 we will expand the chassis to support tablets however, many laptops and tablets have the same chassis type so it will be a while.
Here is the rough layout of the Apply Drivers Group.
The Apply Hardware vs Virtual Drivers Group is similar. No need to walk the hardware steps if it’s a VM. So the VM folder will apply drivers based on the conditions matching,(ANY) whereas the hardware drivers folder will apply if they are NOT virtual (NONE), shown below. Currently this calls out the main Hyper Visors in use, but we will eventually switch to using a script from MDT that detects virtual and sets a variable.
Download
This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script. Always test, test, test before rolling anything into a production environment.
The HTA is pretty customized, hence why I have not released it. With that said, I did attach one we used for XP that just grabbed the above data and moves on so that should get you going.
Might have to comment/remove lines 20-21 & 52 as that pulls the asset tag and serial from BIOS and not all manufactures use that part of WMI for that. As you see above we are mostly Dell so its centered around that manufacture.
You can get it from here.
No comments:
Post a Comment