Helpful WMI Queries (OSD)

, ,

WMI Queries

Earlier in the 2017 year I was at a customers site where they had 60+ task sequences. This customer had a specific TS for each model they supported, and for each scenario. This was eventually reduced down to 3 task sequence primarily by the use of WMI Queries.

For Tier 1 Support

 

“WMIC CSPRODUCT GET NAME”

 

This will return the system model information so I can take a look at what potential problems exist.

 

“WMIC BIOS GET SMBIOSBIOSVERSION”

 

This will return the current bios version running on the system. For my current customer we noticed the 840 G1 touchscreen laptops would exit the TS and have display issues unless we flashed the bios to at least 1.39 while being imaged connected to an ultra slim docking station

 

For Task Sequence
We started to combine the task sequences into 1 by use of WMI queries. There would be individual driver installation steps based on each mode.

select * from win32_computersystem where Model like “%HP EliteBook 840 G1%”

 

We can see when we query status messages that only the step to install 840 G1 drivers was ran due to the WMI query.

 

For Bios Flash
I like to create an If statement to include model information combined with specific bios version. This will allow me to target only systems that are not up to the approved baseline. Running with the configuration below we get a return of 5 – 8 minutes per system by being able to avoid this step.

less than version example:

select * from win32_computersystem where Model like “%HP EliteBook 840 G2%”

 

select * from WIN32_BIOS where SMBIOSBIOSVersion < “N71 Ver. 01.21”

 





FOR VPN
useful for deciding to ignore


Select * from Win32_IP4RouteTable where Name like '192.0.99.%' or Name like '192.0.98.%'










ProTip
make sure you always test query. I have seen in a previous customers environment while reviewing status messages that several model machines were failing domain joins b/c the driver packs were not being installed due to bad wmi queries. This was a problem the customer faced against 40% percent of their supported models.

Slow WinPE Boot Speed

, , , ,

Default out-of-the-box booting on WinPE with SCCM 2012/2016 is very slow. In some environments I’ve seen this take 3 hours to download the Boot.Wim. This is because System Center Configuration Manager 2012/2016 uses small TFTP block sizes of 512 bytes.

This behavior is set because it’s compatible with all network configurations; but the result is that the PXE boot speed can be very slow using Operating System Deployment with SCCM.

To increase the PXE boot speed, we need to modify TFTP Block Size.
In the registry editor:
Path : HKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSDP
Name : RamDiskTFTPBlockSize
Type : REG_DWORD
Value : 16384 (decimal)

16384 is the maximum supported value.
If it is bigger, you can have corrupted data.
However I recommend to do some test with values :
– 4096,
– 8192,
– 16384.
I typically run 16384 and 8182 in my environments. These will be DP that are on server 2008R2 and later.

Restart the Windows Deployment Services Service. (WDS)

On this particular PXE-DP the time to download the boot.wim increased by roughly 80%

To my knowledge this feature has been built into CB1606 but I have not moved there yet to test myself.

ALSO SEE : Rebuild site servers without redistributing content over the WAN