7 Replies Latest reply on Jun 27, 2009 4:17 AM by jan.buelens

    Inconsistencies with HII and Dell Dimension Models


      I have been using revision 9 of the "Hardware Independent Imaging (HII) And LANDesk® Management Suite" by Mike Ybarra and Jan Buelens.  It work beautifully on the Dimension 3000 boxes that we have, but is almost inoperable on the Dimension 2400.  I thought (and still suspect) that the problems may be at least partially rooted in the divers, but am at my wits end trying to figure out what is failing.


      The Dimension 3000s load beautifully, sysprep works properly, the LANDesk agent installs right.  All automated aspects perform perfectly.  Yet when I run the exact same script against the Dell Dimension 2400, it fails when loading the drivers (I've verified the copydriver.ini file is correct, but the drivers are not being copied).  It also fails to join the domain or install te LANDesk Agent.


      I've posted the primary scripts, and would really be tahnkful for any help you can offer.


      Bunch HII WinXPPro Deployment.ini


      ScriptName=Bunch HII WinXPPro Deployment
      ScriptDescription=Bunch HII WinXPPro Deployment
      ImageToolCmd=h:\osd\imaging\2.0\imagew.exe /r /o /d:0 /f:"i:\Dell\DIMENS~1\WINXP_~1\D3644.TBI" /rb:0
      ImageToolCmdsFile=\\LANDESK\LDMAIN\LANDESK\FILES\Bunch HII WinXPPro Deployment.txt
      SysPrepFile=\\LANDESK\LDMAIN\LANDESK\FILES\Bunch HII WinXPPro Deployment.inf
      DESCRIPTION=Bunch HII WinXPPro Deployment
      NAME=Bunch HII WinXPPro Deployment
      REMEXEC0=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/bootfile.exe"
      REMEXEC1=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tlibr16.dll"
      REMEXEC2=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tlibr32.dll"
      REMEXEC3=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/lddefrag.exe"
      REMEXEC4=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/cicfgmgr.vxd"
      REMEXEC5=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/cindis.vxd"
      REMEXEC6=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/copyfile.exe"
      REMEXEC7=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/winbom.ini"
      REMEXEC8=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/ldvpe0.img"
      REMEXEC9=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /dest="C:\ldvpe1.img" /p="http://%CUSTJOBHOSTIP%/landesk/vboot/ldvpe1.img"
      REMEXEC10=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tokreplw.exe"
      REMEXEC11=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /dest="%LDMS_CLIENT_DIR%\diskinfo.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/diskinfo.exe"
      REMEXEC12=<qt/>%LDMS_CLIENT_DIR%\diskinfo.exe<qt/> update_winnt_sif <qt/>%LDMS_CLIENT_DIR%\winnt.sif.new<qt/>
      REMEXEC13=<qt/>%LDMS_CLIENT_DIR%\copyfile.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\ldvpe0.img<qt/> <qt/>%LDMS_CLIENT_DIR%\winnt.sif.new<qt/> \winnt.sif
      REMEXEC14=<qt/>%LDMS_CLIENT_DIR%\lddefrag.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\ldvpe0.img<qt/>, STATUS
      REMEXEC15=<qt/>%LDMS_CLIENT_DIR%\bootfile.exe<qt/> %LDMS_CLIENT_DIR%\ldvpe0.img /keep /bootunsafe, ASYNC
      REMEXEC17=diskpart /s X:\LDClient\rmvol.txt
      REMEXEC18=drvmap.exe bunch\landesk 108C3D2CDFA1DCD8FB60E3D7B0B I: <qt/>\\landesk.bunch.local\images<qt/>, STATUS FACILITY=3513
      REMEXEC19=drvmap.exe bunch\landesk 108C3D2CDFA1DCD8FB60E3D7B0B H: <qt/>\\landesk.bunch.local\ldmain<qt/>, STATUS FACILITY=3513
      REMEXEC20=diskpart /s X:\LDClient\wipeDisk0.txt
      REMEXEC21=cmd /c format /Y /FS:NTFS /Q /V:C-DRIVE c:
      REMEXEC22=h:\osd\imaging\2.0\imagew.exe /r /o /d:0 /f:"i:\Dell\DIMENS~1\WINXP_~1\D3644.TBI" /rb:0
      REMEXEC23=sdclient /f /o /dest="X:\LDClient\diskinfo.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/diskinfo.exe", STATUS
      REMEXEC24=sdclient /f /o /dest="X:\LDClient\assvol.txt" /p="http://%CUSTJOBHOSTIP%/landesk/files/assvol.txt", STATUS
      REMEXEC25=tokreplw X:\LDClient\assvol.txt partition=1
      REMEXEC26=diskpart /s X:\LDClient\assvol.txt
      REMEXEC27=sdclient /f /o /dest="C:\sysprep\sysprep.inf" /p="http://%CUSTJOBHOSTIP%/landesk/files/Bunch%20HII%20WinXPPro%20Deployment.inf", STATUS
      REMEXEC28=sdclient /f /o /dest="C:\ldsleep.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/ldsleep.exe", STATUS
      REMEXEC29=tokreplw C:\sysprep\sysprep.inf COMPUTERNAME=%Computer - Device Name%
      REMEXEC30=cmd /c copy /y X:\LDClient\guid.pds C:\LDISCAN.CFG
      REMEXEC31=tokreplw C:\LDISCAN.CFG DEVICEID=%Computer - Device ID%
      REMEXEC32=tokreplw C:\LDISCAN.CFG IMAGEPATH=\\landesk.bunch.local\images\Dell\Dimension\WinXP_sysprep\D3644.TBI
      REMEXEC33=sdclient.exe<qt/> /f /o /dest="x:\ldclient\fixvista.bat" /p="http://%CUSTJOBHOSTIP%/landesk/files/FixVista.bat"
      REMEXEC34=sdclient.exe<qt/> /f /o /dest="x:\ldclient\fixntfs.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/fixntfs.exe"
      REMEXEC35=sdclient.exe<qt/> /f /o /dest="x:\ldclient\bcdedit.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/bcdedit.exe"
      REMEXEC36=RunBatch -1 X:\LDCLient x:\ldclient\FixVista.bat
      REMEXEC37=diskinfo extend_last_partition
      ; REMEXEC371=i:\tools\halconfig.exe
      REMEXEC372=i:\tools\copydrivers.exe /c
      REMEXEC373=reg load HKLM\Software1 C:\Windows\system32\config\software
      REMEXEC374=i:\tools\ldprep /c /reg=Software1 /path=c:\drivers\pnp
      REMEXEC38=reboot, timeout=2

      Bunch HII WinXPPro Deployment.inf


      FullName=Bunch User
      OrgName=Bunch & Associates, Inc.
      Command0="c:\ldsleep.exe 30"
      Command1="net use \\landesk\ldlogon Yensid12 /u:bunch\landesk"
      Command2="cmd /q /c \\landesk\ldlogon\wscfg32.exe /F /NOUI /REBOOT /DONTSTARTSVCS"
      Command3="net use \\landesk\ldlogon /d /y"
      Command4="cmd /q /c del /q c:\ldsleep.exe"
      Command5="cmd /q /c del /q c:\ldiscan.cfg"



      VMware Virtual Platform=VMware Virtual Platform
      Latitude E6400=Latitude E6400
      Dimension 2400=Dimension 2400
      Dimension 3000=Dimension 3000
      OptiPlex 755=OptiPlex 755
      Latitude D630=Latitude D630

        • 1. Re: Inconsistencies with HII and Dell Dimension Models

          "it fails when loading the drivers (I've verified the copydriver.ini file is correct, but the drivers are not being copied)"


          How did you verify that that copydrivers.ini is correct? Looking at your copydrivers.ini, I suppose you have verified that folder "\\ landesk\images\drivers\Dimension 2400" exists. Have you also verified that "Dimension 2400" is indeed the model name as reported by WMI?


          What does the log tell you? If copydrivers "didn't work", there should be an exit code in the log that says what went wrong.


          And here's another troubleshooting hint: insert a dummy command like notepad in your script, just before the copydrivers line. Then, when the notepad window pops up, do some manual troubleshooting. Open a console window and try the copydrivers command manually, with a /v. If copydrivers isn't finding what it's looking for, you will see what it is. It will also show you the WMI model name.

          1 of 1 people found this helpful
          • 2. Re: Inconsistencies with HII and Dell Dimension Models

            Thank you for the pointers - they were exactly what I needed to identify the problem, though I fear it has only muddied the waters a little more.


            It turns out that when I used the /v switch, the copydrivers application verified the path and WMI type in a popup dialog box, then displayed the error "Unable to locate \\landesk\drivers\Dimension2400".  The problem is that the path is correct.  I reran the copydrivers command using the /s and /d switches, once again using the UNC, but encountered the same issue.  I finally ran the command with the mapped drive letter instead, "copydrivers /s i:\drivers /d c:\drivers\pnp /v"


            So this seems to suggest a work around exists, but the solution still escapes me.  Even though the UNC path was 1) Valid, an 2) Entered into the configuration file by the unswitched copydrivers command, it would not run.


            In the end, the use of the drive letter did allow the drivers to get copied, but did not resolved the final issue, which was windows prompting for a couple of video-associated files during the hardware discovery phase.  The confusing part is that the files it prompts for are both located in the one of the directories copied over by the copydrivers command.  The first one is right in "c:\drivers\pnp\video" and the second is in "c:\drivers\pnp\video\Win2000".  Any idea why it might be prompting for these files?

            • 3. Re: Inconsistencies with HII and Dell Dimension Models

              Regarding the UNC path, glad to see you found the workaround. Note that the UNC path may have been valid, but was it also accessible? Did you try some other command to make sure there wasn't something with access rights that stopped you - and copydrivers - from accessing the unc path? Anyway, if there had been, my recommendation would have been exactly what you have already done.


              Regarding mini-setup prompting you for files, 2 thoughts:


              1. Perhaps you used some tool like DriverMagician to harvest the drivers? I know several of these tools and they work great, but every single one that I tried had this problem: they "flattened" the driver, i.e. they put all the driver files in one folder even though the inf file says that some of the files should be in a subfolder.


              2. Read this article.

              • 4. Re: Inconsistencies with HII and Dell Dimension Models

                jan.buelens wrote:


                <snip> Note that the UNC path may have been valid, but was it also accessible? <snip>


                Indeed, it is.  Using the notepad command you recommended above, I was able to "pause" the process and able use the console window to browse to the network directory, list its't contents, etc.


                from jan.buelen's blog:


                <snip> Solution: make sure your image has an sp3.cab (or sp2.cab in the case of sp2) in c:\windows\driver cache\i386. If it's not there, you can copy it from an expanded copy of SP3 and inject it during the post-imaging phase of your OSD script / provisioning template.  <snip>


                The only injection I've done before this is Mass Stoarge Drivers. What method do you recommend I use to inject this file?  I assume I can add it to the "Bunch HII WinXPPro Deployment.ini file"?


                • 5. Re: Inconsistencies with HII and Dell Dimension Models

                  The term "inject" seems to have confused you. You can just copy the file. Any copy command will do, such as


                  REMEXECnn=cmd /c copy i:\someplace\sp3.cab "c:\windows\driver cache\i386"

                  • 6. Re: Inconsistencies with HII and Dell Dimension Models

                    Thank you very much for the clarification.  I thought it looked very promising, the blog was clear and made perfect sense.


                    Unfortunately, it didn't work in this case.


                    About half-way through the driver load, the progress bar seems to hang for a little bit, then a dialogue pops up:


                    Files Needed

                    The file 'ialmnt5.sys' on Intel(R) Graphics Media Exelerator is needed.

                    Type the path wherre the file is located, then hit OK.

                    Copy files from:


                    e:\r87365 - intel(r) graphics media accelerator driver\win2000"


                    Interestingly, if I leave that select screen up for too long, the PS2 keyboard and mouse both lock up, forcing me to reboot the computer.  Assuming I get to the prompt in a reasonable amount of time, I can then browse to where the file is already included: c:\drivers\pnp\Intel(R) 82845G GL GE PE GV Graphics Controller.  The default location (e:\r87365...) is completely unknown to me - I have no idea where it is getting the location from.

                    • 7. Re: Inconsistencies with HII and Dell Dimension Models

                      Looks like the problem is something to do with the driver already being present in the image. The story is similar to the one in this article, with this important twist that what's being reinstalled is an already installed "oem driver", not a microsoft supplied driver that came with the OS.


                      Let's just picture the process and try to understand what's going on. So here we have mini-setup chasing inf files. Let's follow it along on its journey. For the purpose of our story we need to assume that the correct display driver is already installed. Your source machine had a similar display adapter so the already installed driver is also the correct driver for the target machine. Except, although the display adapters are "similar" (same driver), they are not identical (different hardware IDs). Therefore, mini-setup wants to reinstall the driver. If we assume that the already installed driver is the same version as the driver that you supply in a subfolder of c:\drivers\pnp, then we have 2 identical copies of the inf file: the already installed one (in c:\windows\inf) and your "new" one. Which one is mini-setup going to use? I don't know if there are any rules about which inf file to take if multiple equivalent inf files are found, but let's assume it always takes the first one. Because c:\windows\inf normally comes first in the DevicePath key (the list in the registry of paths to scan for inf files), the first one is the one already in c:\windows\inf.


                      So the picture we get to is this: mini-setup is trying to install the driver based on an inf file already present in c:\windows\inf - not the one in your subfolder of c:\drivers\pnp. It starts to look for some of the driver files, such as ialmnt5.sys. By the normal rules of the game, it looks for them in the same place as the inf. When it can't find them there, it prompts you for the driver installation disk. The last time in the history of your image it did that, the path it was given was e:\r87365 (isn't that some dell patch number or so?), so it kindly suggests that this time as well, that's a good place to start.


                      I can see several loose ends to my story and I don't fully understand all the whys and wherefores and ifs and buts, but I'm sure what's happening is at least something along these lines.


                      Now where to go from here?


                      First, remember this recommendation: you want your master image to be as generic as possible. If at all possible, install only the drivers that come with the OS.


                      Second, you could delete c:\windows\inf\ialmnt5.inf (the file is probably no longer called that, it may have been renamed OEMnn.INF).


                      Third, attached is a new version of ldprep that I believe will avoid the problem. It introduces a new command line parameter (/pre), which causes the inf paths to be pre-pended rather than appended to the DevicePath registry key. With this command line parameter, your copy of the driver (i.e. the one in path specified by the /path parameter) will take precedence over an existing copy already present in the image.