Issue regarding Thin Installer and driver packages

Question

Hello everybody,
I have recently started to work for a new company and have been tasked with creating a new Windows deployment solution.
My company are using Lenovo desktop and laptop and my installation image use Thin Installer to deploy drivers to our workstations during Windows deployment.
I have been having some difficulties getting everything to work and I want to write about it here to hopefully help someone in the same situation as me and call out for better quality control at Lenovo.
Here are the command line I call to start Thin Installer from the local computer:
START /WAIT thininstaller.exe /CM -search A -action INSTALL -repository \\wds\lenovo -noicon -showprogress -IncludeRebootPackages 1,3,4  -noreboot
Hers the issues I have expirienced:
1. Sometimes packages downloaded with Update Retriever will be set to "Reboot type: Forces a reboot" as default. This causes the Thin Installer to reboot reguardless of the -noreboot switch.
Its possible to change reboot type "Requires a reboot" in Update Retriever and than the updates installs fine.
This causes problem with scripted installs where you cannot have the system reboot "out of order".
Updates should never be default "forces a reboot".
2. On my Thinkcenter e93z (10B8) the Intel Displaydriver (v 9.18.10.3220) wont install because the PnPID is not listed in the XML file. (my PnPID is VEN_8086&DEV_041E&SUBSYS_309C17AA (309D17AA is listed tho)). Manualy editing the XML files to include my PnPID solves the problem.
Lenovo should really have better qualitycontrol here.
3. On a t440s machine i have the Synaptics UltraNav Driver (v. 17.0.12.60) wont install automatically with Thin Installer.
This is because the machine i installed failed the "BIOS test" in the XML file of the update package. I manually edited the XML file and replaced the "BIOS TEST" with one from another update that worked on that system and now everything installs automatically and works fine.
Its possible that Lenovo has detected some kind of problem with my BIOS version and the Synaptics driver but everything seems to work fine for me.
I hope this post will help someone in the future
EDIT: Other people have called out some problems with the information provied in this post. You should read the whole thread before making any changes to your systems.
Kind Regards,
2bi

Answer 1

2bi,
Thanks for posting your findings.  I will investigate and escalate the missing PnP id issue for the Display Driver issue.  We absolutely need to avoid these kinds of escapes.
For you ThinInstaller command line I would recommend not using the -showprogress parameter if you are using in a scripted deployment scenario with something like MDT and/or SCCM.  These solutions typically will not allow TI to interact with the desktop during deployment which is what -showprogress will cause.
Also, you are telling TI to include packages that will automatically reboot your system (type 1), requires a reboot which can be delayed (type 3), will shutdown the machine automatically (type 4).  We have very few type 4 packages anymore; however we definitely have type 1 and type 3.  As sclexman mentioned, the -noreboot will only apply to the type 3 packages which leave the execution of the reboot up to TI.  So -noreboot tells TI that even if it installs updates of type 3, it should not reboot when finished.
Changing the Reboot Type value in Update Retriever only changes how TI sees the package and does not alter how the package itself executes.  So if a package is designed to always automatically reboot, changing it to type 3 in UR will have no affect.  We have recently had a display driver released by Intel that will automatically reboot if the driver installer detects that it is upgrading an older version of the driver.  In a clean deployment scenario, the automatic reboot will not happen so in this case it is safe to change the type to type 3.
This leads to another point.  All of our content that is available through Update Retriever is also intended for consumption by System Update which is the utility aimed at individual consumers to help them keep their drivers up to date.  Therefore this becomes our lowest common denominator that we have to support.  This leads to situations that may not be ideal for the deployment scenario.  If we had an army of resources we might be able to manage all of our content for both consumers and enterprise deployments; in effect doubling our efforts.  Unfortunately this is not the case and we are trying to do the best we can.
Regarding the UltraNav update for T440s, I see that the XML has a _BIOS section under the Dependencies.  However it is defined such that any BIOS level will work because the first level listed is a wildcard asterisk (*).  This BIOS section is actually included for a completely different solution which also uses the XML.  It is not intended to control the targeting of the update for System Update or Thin Installer.  Perhaps there was a mistake made initially and the XML was released without the * and has since been fixed.
(from the current UltraNav driver package:  )
<_Bios>
<Level>*</Level>
<Level>GGET*</Level>
<Level>GFET*</Level>
<Level>GHET*</Level>
<Level>GIET*</Level>
<Level>GJET*</Level>
<Level>GLET*</Level>
<Level>GMET*</Level>
<Level>GNET*</Level>
<Level>GRET*</Level>
</_Bios>