First post in a long time. Let’s just say that life keeps me busy… Anyway.
After reading about the Intel/Lenovo-bug with the Thunderbolt firmware, which was damaging the SPI-Rom of the controller over time, I started to look at ways to inventory the NVM-version using CCM. At first it looked quite easy, there was wmi-classes holding the values I wanted and so on. But then I started noticing that there were clients without these classes and that even clients of the model sometimes had or didn’t have the values I was looking for. Dove in deep and found this: https://github.com/mosdeo/N1MTF24W/tree/master/FwUpdateAPI
“Great, that’ll take care of things” Yeah, right. It gave me the info that I needed on my machine, a Dell 7480, but only if it was currently docked. By a chance I noticed a sound when I was updating another computers Thunderbolt-firmware, the kind of sound you get when connecting new hardware to a computer with Windows 10. The Dell Thunderbolt-firmware update tool was also showing the current nvm version on screen. Closed the tool, without updating, took a look at the device manager, the controller was disconnected, in other words, the computer wasn’t docked. Started the tool once again and bam, the controller came online. What kind of black magic is this!? Searching the darkest corners of the web I finally found that there’s a built in command to force a Thunderbolt controller online. “Woohooo, done!” Nope, apparently not… The FwUpdateAPI doesn’t work on computers with a modern (UWP/DCH) driver, or at least I haven’t found a way. Won’t bore you with the details nor the time it took, but I do have a beta of a .dll I made, based on some code I managed to decompile. It has been working 80 to 90% of the times so far, no matter docking status nor the kind of driver :) The modern types of clients we have are mainly Dell's, a couple of HP's but not a single Lenovo computer. That beeing said feel free to try this one out. https://github.com/MattiasC85/Scripts/blob/master/General/Get-ThunderboltInfo.ps1
Example of the output if using CCM's 'Run Script'.
Ah, thought you were wondering if the "driver type output" was static. The output object is a List that's not enumerable, at least not in the dll (c#). That's why I just return the object as it is. Having said that I just finished another version of the dll yesterday. That dll returns an object that is easier to work with. Trying to work around a null reference error that complicates the script. Don't worry about the props though, will keep em in the same order and won't change the names.. If it's not needed ofc :) Let me know how it goes with the inventory! 👍
I got that part..:)
Just wondering about the properties coming out of the script. Never mind, I will create new properties for a custom WMI class for the ConfigMgr. hardware inventory.
First it tries to determine if a TB driver exist and if it does it looks in the registry for a guid that only exists if the driver is a UWP driver. Tried it on my 7480 with both a normal and a UWP driver. So it is dynamic and not per model. :)
One question, I am looking into getting the Thunderbolt 3 info. into Microsoft Endpoint ConfigMgr. as hardware inventory....does the output properties for either the "UWP" or "Normal" thunderbolt type change depending on hardware model or any other factors...?
Great, thanks for the feedback! :)