Saturday, December 20, 2014

Quicker parsing of Apply Driver steps

Was talking to someone at the local user group and he (Thanks for the Jamba Juice John!) was curious how I was handling driver detection in the TS so quickly so I thought it would be something to share with everyone else as well.

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.




Monday, December 8, 2014

Managing SCCM Console installs


As I move to implement CU3 in our 2012 R2 environment, one of the tasks done is to update all your consoles. With my firms size we have consoles all over the place. They are on Site Servers, Workstations, Abacus', even hosted on Citrix. I wanted an easy way to deal with them, so why not treat it like any other software you manage via ConfigMgr?


While we are on CU1 currently, I learned that there are actually several console installs that are still on R2 and should be on CU1, even a non R2 out there. When we move to CU3 those will get cleaned up.

First things first, setup the Collections. We set them up not only for 2012, but also for each CU revision as shown above. This was to manage and keep track as we migrate from CU1 to CU3 and beyond. As with any other software Collection, we looked at Add/Remove for the Console Software which was called 'System Center 2012 R2 Configuration Manager Console'. We then split it out for versions. Luckily we turned to this TechNET blog post that had the version info to query on. This link is also useful for other tasks like ConfigMgr agent version.

To save time, you can cheat and just copy the query language below:

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileVersion = "5.0.7958.1401" and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "System Center 2012 R2 Configuration Manager Console"  

Just change the version '5.0.7958.1401' to the one you care about, or remove it.

For the pre R2 systems we had to use a different Add/remove name of 'Microsoft System Center 2012 Configuration Manager Console'. BTW, you can use this query if you don't want versions. Here is that query:

 select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "Microsoft System Center 2012 Configuration Manager Console"  

Update:
Looks like I wasn't the only one with this idea.


-Kevin