So I've had a working HII script in production for some time. It has worked very well for our environment with just a single .inf file.
Last week I was given some Tablets and asked to add them to the HII process. I managed to get them to work great after some tinkering but I found that I HAVE to use a separate .inf for these because of the need for the TabletXP product key.
No big deal right? I just added a couple lines to that model's driver injection and voila. Worked perfect.
But, after a few days I started noticing some issues with standard models as they were getting deployed. They were running GUIRunOnce commands that were only present in the .inf file for the tablets!
During my troubleshooting for this I actually found 2 bugs.
Here is a condensed version of my HII script btw:
REM Copy Driver and HAL files to the production before the
REM operating system starts.
REM This section is used to locate and use specific drivers based on the
REM model of computer running the job
REM ReplaceTokens .\Sysprep\HIIProd.inf .\Temp\%COMPNAME%.inf
Y:\rdeploy\windows\firm.exe copy Y:\Temp\%COMPNAME%.inf PROD:\Sysprep\sysprep.inf
Y:\rdeploy\windows\firm.exe delete Y:\Temp\%COMPNAME%.inf
echo Your hardware Model number is %#!computer@model_num% and Product ID is %#!computer@prod_name%
if "%#!computer@model_num%"=="D865GLC" goto e4100
if "%#!computer@model_num%"=="D845GRG" goto e4000
if "%#!computer@model_num%"=="0DR845" goto d755
if "%#!computer@model_num%"=="0HX555" goto d755
if "%#!computer@model_num%"=="0UY141" goto d830
if "%#!computer@model_num%"=="0HN341" goto d830
if "%#!computer@model_num%"=="0GM819" goto d755
if "%#!computer@model_num%"=="0TP412" goto t3400
if "%#!computer@prod_name%"=="M685-E" goto m685
if "%#!computer@prod_name%"=="M465-E" goto m465
if "%#!computer@prod_name%"=="Gateway M465" goto m465
if "%#!computer@prod_name%"=="Gateway M460" goto m460
if "%#!computer@prod_name%"=="E-475M" goto e475
if "%#!computer@prod_name%"=="Gateway M680" goto m680
if "%#!computer@prod_name%"=="Latititude XT" goto LatitudeXT
if "%#!computer@prod_name%"=="VMware Virtual Platform" goto VMware
if "%#!computer@prod_name%"=="M285-E" goto m285
REM if no match is found, exit the script
goto Exit
:e4000
Y:\rdeploy\windows\firm.exe -recurse copy Y:\Sysprep\Models\e4000 prod:\
goto Exit
:e4100
Y:\rdeploy\windows\firm.exe -recurse copy Y:\Sysprep\Models\e4100 prod:\
goto Exit
[... content abbreviated .. ]
:VMware
REM ReplaceTokens .\Sysprep\vmwaret.inf .\Temp\%COMPNAME%.inf
Y:\rdeploy\windows\firm.exe copy Y:\Temp\%COMPNAME%.inf PROD:\Sysprep\sysprep.inf
Y:\rdeploy\windows\firm.exe delete Y:\Temp\%COMPNAME%.inf
Y:\rdeploy\windows\firm.exe -recurse copy Y:\Sysprep\Models\e4100 prod:\
goto Exit
:LatitudeXT
REM ReplaceTokens .\Sysprep\Tablet.inf .\Temp\%COMPNAME%.inf
Y:\rdeploy\windows\firm.exe copy Y:\Temp\%COMPNAME%.inf PROD:\Sysprep\sysprep.inf
Y:\rdeploy\windows\firm.exe delete Y:\Temp\%COMPNAME%.inf
Y:\rdeploy\windows\firm.exe -recurse copy Y:\Sysprep\Models\e4100 prod:\
goto Exit
:m285
REM ReplaceTokens .\Sysprep\Tablet.inf .\Temp\%COMPNAME%.inf
Y:\rdeploy\windows\firm.exe copy Y:\Temp\%COMPNAME%.inf PROD:\Sysprep\sysprep.inf
Y:\rdeploy\windows\firm.exe delete Y:\Temp\%COMPNAME%.inf
Y:\rdeploy\windows\firm.exe -recurse copy Y:\Sysprep\Models\e4100 prod:\
goto Exit
:Exit
exit
Basically it does the standard token replacement and .inf injection for all models
Then it injects specific drivers based on a folder structure related to each model
Pretty standard stuff
Then the last few have custom .inf's (I added one for my VMs after I did one for the tablets)
Here's where it gets wierd. I put a pause in at Exit to see what is going on:
Problem 1
The script processes the first REM ReplaceTokens fine and firm copy completes.
it goes down through the 'if then' until it reaches its correct host (in this case VMware)
it skips to VMware
Firm copy the .inf FAILS
- The REM ReplaceTokens does not process, it never creates the temp file.
Firm copies driver folders
it skips to Exit and is done
I tried everything to get that to work. cut and pasted the REM statement that worked from above, tried the exact same .inf, tried several versions of the statement with caps, etc. Nothing. As a second REM statement it simply will not process (Which I don't get because the tablets are obviously getting their proper .inf)
Now if I remove the first REM ReplaceTokens statement, the second one in the VMware branch of the script runs fine! So the code is fine, for some reason DS just can't process two REM ReplaceToken scripts? (Again, how are the Tablets getting theirs?)
Stumped on that one. My solution was to remove the default REM statement and add one to each model branch, something I was going to do anyway to add a little more customization to laptops, etc.
That brought me to
Problem 2
This one is even weirder. So I watched the script run again and it showed everything processing ok. But for some reason my VM was crashing on mini setup...
After further investigating, while the script was paused at the end I used another command window to use
firm type PROD:\sysprep\sysprep.inf to see what was actually on the box.
To my surprise this .inf file exactly matches the Tablet.inf!
???
For whatever reason I have been able to conclude that DS is processing those other REM ReplaceToken statements AND the statements that follow them silently.
They do not get echoed in the script window.
They don't fail like in problem 1
I'm not sure why they don't fail, but what I theorize is happening is that DS still reads through the script line by line and when it sees that REM statement it starts processing it and the subsequent lines. Basically each branch with that REM ReplaceTokens in it gets processed silently.
At least thats what I thought, but if that were true then my VM would have a bunch of extra driver folders. It doesn't...
So somehow the REM ReplaceTokens statement gets process AND it gets firm copied to the sysprep folder but the firm driver copy DOES NOT GET PROCESSED.
???
I'm at a loss right now, I have a phantom in my DS :|
My solution right now is I have removed all branches that need a custom .inf and placed them in their own job condition. I went back to the single default .inf at the top of the script for normal models. Separating these works perfect but its a little harder to maintain and more steps to adding new stuff.
I am currently on DS 6.8 about a week away from moving to 6.9. I will test this on our 6.9 test box as soon as I get a chance.