RogueSpear

No thank you. I can't even explain how much time and energy these DPs have helped me. Just wanted to give back a little is all.

Apart from the inherent 4096 character limitation of OemPnPDriversPath, there's no problem with this method. With only one exception, and I'll get to that, I've never had device detection begin prior to the 7z files being extracted to the hard drive. So since they're extracted prior to device detection, we don't need to run SetDevicePath.exe. The OemPnPDriversPath is set as always and will find the drivers since we are extracting them to the proper location. Now for that one exception. It was a hyperthreaded P4-3.6 system. I don't know if the hyperthreading had anything to do with it or not. I would think not since before device detection, the system shouldn't even be recognized as a multi-CPU ACPI computer - or would it? Is the HAL something detected and loaded up during the text portion of setup? Anyway to get around the issue, I put all of the DP's in $OEM$\$1 and modified drivers.cmd appropriately. This allowed the archived to be decompressed a bit faster and thus they were done before device detection began. I speculate also that since the hard drive was being kept so busy, it slowed down the rest of the setup process, preventing it from going ahead of the 7z decompression. I also have tried this on a HP laptop that had a P4-3.0 HT CPU and didn't have this issue come up. Now this could have been due to a slower CPU, slower HD subsystem, slower interface to system RAM, etc. For the control panels batch file. I made my own custom DP and simply put it in there so that when it decompresses it will end up in %SYSTEMDRIVE%\D. A possible solution here since not everyone has their own custom DP is to include the control panel batch file in both graphics and sound DPs. Just let it overwrite upon decompression. Having it in all four DPs would waste space, but we're really talking about such a negligable amount of space here, that I don't think it would make or break anybody's project.

First, I've never used a directory as my tag file in determining the source CD letter. I don't know if this is causing a problem or not but I would suggest setting the tag file to the file WIN51. Second, while I am not totally versed in everything Method 2 I think you could and probably shoud keep the WatchDriverSigningPolicy.exe in your presetup.cmd file. I think the way this works is that it will stay resident and running when executed from presetup.cmd, but I'm not so sure it will do that if executed from DetachedProgram. Third, I don't know if this will make a difference for sure, but I think the BTS DPs are designed so that the various batch files expect to find the DPs as %SYSYEMDRIVE%\D. You've nested D inside another directory. Again, I don't know for sure if this will make a difference or not, but you may as well eliminate any potential problems right off the bat. Ok and in looking carefully here you are putting driver.cmd in %SYSTEMDRIVE%\D but the DPs themselves decompress to "%SystemRoot%\BtS_DriverPacks. Suggestion: decompress all DPs to %SYSTEMDRIVE% and put your drivers.cmd file inside $OEM$\$1 in your install media. Make the appropriate changes to your presetup.cmd and drivers.cmd files.

@Yzöwl, the 7za.exe file was not updated since V4.16 so even after you install V4.18 the file's version properties are the same.

The problem is that Windows setup hasn't run AT ALL at this point yet, so there is no directory structure to be found on the hard drive. Try running SetupCopyOEMInf.exe from DetachedProgram and I bet it works for you. EDIT: You may want to make a simple batch that you call from DetachedProgram to run SetupCopyOEMInf.exe otherwise you'll have to play around with the Arguments entry in the WINNT.SIF.

First off, I hope that I'm allowed to post a poll here and that nobody is offended that I did so. Hopefully the 30 Euro donation I just made this week will afford me some leeway here What I am going to describe here has been outlined within these forums previously, including by me. But for the purposes of the poll and for those who are unfamiliar, please read on. For many months now I have been using what I've been calling a "modified Method 1" of utilizing the BTS DPs. I run the Method 1 slipstreamer through all of it's steps so that the appropriate mass storage drivers are copied over to the i386 directory and the various setup files are properly modified (txtsetup.inf, etc). I then get rid of the D directory completely and instead of using that copy all of the DP 7z archives to a directory on the CD called OEM. I then call a batch file from DetachedProgram in WINNT.SIF that decompresses all of the drivers to D on the hard drive. I have a custom DP that I use and within that 7z archive I have placed the control panels batch file for extraction along with the drivers. I've been doing this now for quite some time with no problems at all. It's been tested on everything from a Pentium MMX-233 (holy crap is that slow) to a P4-3.4Ghz (holy crap is that fast). Personally I am not comfortable using Method 2. It's just too Rube Goldberg for my tastes with all of the hacks involved. The method I use has the advantage of saving a temendous amount of room on your installation media and it would save a tremendous amount of time during the slipstreaming process as all the driver files do not need compressing. Now for those interested in the new "Keep the Drivers" option, the existing script that takes care of those chores could be run from either cmdlines.txt or from GuiRunOnce/RunOnceEx. Indeed this would add some time to the installation process, but we are all here for the purpose of making an "unattended" installation in the first place right? From what I have read and gathered here, keeping the drivers is a very desireable feature to many members, but so is keeping the size of the DPs as small as possible on the install media. I'd be very interested in hearing everyone's opinion on this issue and I would like to apologize in advance if I appear to be stepping on toes here. That's not my intention at all. I just want to help forward to usefullness and utility of these fine works that have saved me countless hours of time. For the sake of being complete I am including the contents of Drivers.cmd, which I place inside $OEM$\$1 on my install media and call from DetachedProgram. @ECHO OFF set tagfile=\WIN51 for %%i in (c d e f g h i j k l m n o p q r s t u v w x y z) do if exist "%%i:%tagfile%" set CDDRIVE=%%i: %SystemDrive% cd \ copy %CDDRIVE%\OEM\7za.exe %SYSTEMROOT%\system32\7za.exe /V /Y Start /WAIT 7za.exe x -y -aoa %CDDRIVE%\OEM\DriverPack_*.7z -o"%SYSTEMDRIVE%" Start /WAIT 7za.exe x -y -aoa %CDDRIVE%\OEM\000_AllUsers.7z -o"%ALLUSERSPROFILE%" Start /WAIT 7za.exe x -y -aoa %CDDRIVE%\OEM\000_ProgFiles.7z -o"%PROGRAMFILES%" Start /WAIT 7za.exe x -y -aoa %CDDRIVE%\OEM\000_WinDir.7z -o"%SYSTEMROOT%"

Well I wasn't aware it had been done before and honestly, I never would have even though to look it up or ask. Sometimes a little repitition about an obscure topic isn't that bad. Thanks for the tip...

This is definately possible, and may not even be that hard either. I simply don't have the time at the moment to develop it. Perhaps in a couple of weeks. I will say though my mind has kind of taken off with the possibilities this has. For now I'll post a vbscript I run from RunOnceEx that does a lot of account housekeeping chores. If any scripting people out there want to take my code and run with it, have a ball.. Option Explicit On Error Resume Next Dim ws, fs, wn, objReg, sysdrv, strComputer, strPath, objComp, Drives, Drive, strCD, strOEM Set ws = WScript.CreateObject("WScript.Shell") Set fs = CreateObject("Scripting.FileSystemObject") Set wn=WScript.CreateObject("WScript.Network") Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & "." & "\root\default:StdRegProv") sysdrv = ws.ExpandEnvironmentStrings ("%SYSTEMDRIVE%") strComputer=wn.ComputerName strPath=("WinNT://" & strComputer) Set objComp=GetObject(strPath) Drives = Array("C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", _ "T", "U", "V", "W", "X", "Y", "Z") For Each Drive In Drives If fs.FileExists(Drive & ":\WIN51") Then strCD = Drive & ":\" Next strOEM = strCD & "OEM\" '********************************************************************** '** Subroutine; Process the built-in Administrator account ** '********************************************************************** Sub ProcessAdmin Dim objUser1, objUser2, objGroup1, objGroup2, flag Set objUser1=objComp.GetObject("user","Administrator") Set objGroup1=objComp.GetObject("group","Debugger Users") Set objGroup2=objComp.GetObject("group","Guests") objGroup1.Remove objUser1.AdsPath objGroup2.Add objUser1.AdsPath objUser1.SetPassword "password1" Set objUser2=objComp.MoveHere(objUser1.ADsPath,"Jerry") objUser2.Description="" objUser2.SetInfo If objUser2.AccountDisabled="False" Then flag=objUser2.Get("UserFlags")+2 objUser2.Put "UserFlags", flag objUser2.SetInfo End Sub '********************************************************************** '** Subroutine; Process the built-in Guest account ** '********************************************************************** Sub ProcessGuest Dim objUser1, objUser2 Set objUser1=objComp.GetObject("user","Guest") objUser1.SetPassword "password2" Set objUser2=objComp.MoveHere(objUser1.AdsPath,"Kramer") objUser2.Description="" objUser2.SetInfo End Sub '********************************************************************** '** Subroutine; Create and configure a new Administrator account ** '********************************************************************** Sub NewAdmin Dim objUser, objGroup Set objUser=objComp.Create("user", "Dave") Set objGroup=objComp.GetObject("group","Administrators") objUser.SetPassword "password" objUser.FullName="David J. Doe" objUser.SetInfo objGroup.Add objUser.AdsPath End Sub '********************************************************************** '** Subroutine; Create and configure a fake Administrator account ** '********************************************************************** Sub FakeAdmin Dim objUser, objGroup, flag Set objUser=objComp.Create("user", "Administrator") Set objGroup=objComp.GetObject("group","Guests") objUser.SetPassword "password4" objUser.Description="Built-in account for administering the computer/domain" objUser.FullName="" objUser.SetInfo objGroup.Add objUser.AdsPath If objUser.AccountDisabled="False" Then flag=objUser.Get("UserFlags")+2 objUser.Put "UserFlags", flag objUser.SetInfo End Sub '********************************************************************** '** Run Tasks ** '********************************************************************** ProcessAdmin ProcessGuest NewAdmin FakeAdmin ws.Run "REGEDIT /S " & strOEM & "\001_Registry.reg",0,True fs.CopyFile (sysdrv & "\Documents and Settings\Administrator\ntuser.dat"), (sysdrv & "\Documents and Settings\Default User\ntuser.dat"),True If fs.FolderExists(sysdrv & "\Documents and Settings\Administrator") Then fs.DeleteFolder(sysdrv & "\Documents and Settings\Administrator"), True objComp.Delete "user", "Administrator" objComp.Delete "user", "ASPNET" objComp.Delete "user", "HelpAssistant" objComp.Delete "user", "SUPPORT_388945a0" EDIT: I don't know what the problem is exactly but for some reason whenever I post VBscript using code tags it screws up my comment lines putting in an ampersand, a space and then pound 39 or something. It's just a commented line is all.

Great. It took me forever to get V9 and all the subsequent patches stabilized for deployment through GPO. Now it looks like I get to start all over again. Well I hope they at least fixed some of the glaring omissions and bugs in this new version.

X-savior, actually I'm wondering the same thing. I made a cab today of all the DPs plus my own DP and it came out to 222MB if I remember correctly. Sure it's a big file, but it's one file instead of thousands. I started thinking about how all of this could or should be implemented. There's going to be a lot of compromise one way or the other. I'll explain: Using 7-Zip, all the drivers come in at under 150MB. The cab file as I explained above is much larger. Yes I do have a DVD burner and yes I do make a version of my project on DVD. But there are still PLENTY of circumstances where a CD is mandatory. Therefore every last byte counts. So what I'm thinking is that the process could go something like what I do currently, but with a few additions at the end. Currently I use a modified Method 1. I run the M1 slipstream batch and let it go through all of it's steps modifying the various inf and sif files. Once it's all done, I get rid of the D directory and put the original 7z files in a directory called OEM. From DetachedProgram I call a simple batch file that decompresses the archives to the HD. In a VBscript executed via RunOnceEx, I run the control panels batch and then delete the D directory. Ok so that's what I do now. What I'd like to do is put in a routine to run from RunOnceEx (or possibly cmdlines.txt) that makes this monster cab file from the contents of D, delete D, and make the necessary changes to the registry and anywhere else so that a future PnP enumeration will look in the custom cab in addition to the stock cab. I hope this is making sense to some of you out there. I don't always have a flair for explaining things very clear. From what I can tell, we have all of the pieces in place. It's just a matter of implementation. So in conclusion, this would save space on our distribution media since we're still using 7z archives, get the drivers onto the hard drive in time for the initial device install portion of setup, and finally make a nice, neat cab file for future device installations. The only negative I can find so far is that we will still be bound to the 4096 character limitation in the winnt.sif file. Thoughts? Comments? Oh yea.. OT but interesting: I discovered today that Viewsonic makes available a single file for download that contains the drivers for dozens of their monitors. Wouldn't it be nice if all monitor manufacturers did this?

It should work from DetachedProgram.

A shot in the dark here, but here it goes: I used to keep my i386 directory on the hard drive as "i386 - Active" and I always had grief with DP Base running into issues. I since gave in and just decided to call it "UAWXPCD" and have had no difficulties since. I did this several versions back. So I don't know if have spaces within your path is throwing something off when Base is executed.

See one of the things that is important to me is being able to either A.) keep the drivers on the HD after the install or B.) have the drivers on the install CD and let the wizard find them there. Just something so that when someone plugs in a new device it will be enumerated and install properly. Even if it's not the latest up to date driver, whatever the person had at the time of install would likely be better the MS supplied driver if there is one or the always bloated with crap install CD that vendor seem to be supplying these days (think Dell AIO devices).

Ok, so I've been trying to put together everything from this thread and the other thread "Having Windows keep the drivers." Is the end goal here to have a cab file full of drivers, the necessary inf files in place, and entries made in drvindex or txtsetup or whatever is appropriate? I've read these threads over and over again and I'm not new to all this, but I'm having some difficulty wrapping my brain around it. I'd definately like to help out where possible, though I am admittedly not very proficient in batch. If anything needs to be done in VBscript, lemme know though. OT - just started a divorce and my head isn't quite all there lately. Just be patient with me and I'll get it eventually

With all the DPs and even my own custom DP, it came out to around 3600 charachters. So there's still a little room left.

What I do is rename the directory DP to D and then do a replace function in notepad. Shortens it up a little bit.

Yes, I populate my RunOnceEx with a series of individual VBscripts (hey I like it what can I say). But you could point at an executable file just as easily.

I'm curious.. can the control panel batch be executed from cmdlines.txt?

Way way back when, before the DPs were so well automated, the Drivers directory was just that - Drivers. I used to do a replace function in notepad to change "Drivers\" to "D\". It may be time to consider that again, especially since I have my own driverpack with lots of monitor, modem, and hid drivers.

I'm curious, is this the next evolutionary step here? It would certainly save some space, but more importantly I think this may be a necessary step in the true slipstreaming of drivers as discussed in the thread "Having Windows Keep the Drivers." Thus far it seems that testing has been done on devices that have no drivers available by default in XP. But what about something like a Matrox G400 video adapter? Or a 3Com NIC? XP already includes drivers for these devices. This brings me to a more serious issue as it's not really a matter technical feasibility, but preference. I always remove the entry for RealTek NICs from the OemPnPDriversPath in my WINNT.SIF file so that they don't install. I have found that in a domain environment every single driver straight from RealTek prevents the machine from properly authenticating to the domain. The default drivers that MS has supplied with XP do not suffer from this issue however. So should a "true slipstream" method be developed enough for prime time, how does the author(s) of such a project decide what to keep and what to kill? This is all going under the assumption that a batch method could be developed to remove drivers from Drivers.cab in the first place. Just a little something for you all to mull over this weekend. Oh, one last thing. Does anyone see any benefit or have any desire to see any of the scripts in the DPs converted over to VBscript? I have entertained the thought of converting the control panels batch file over to see what real benefits may result. I'm open for comments and suggestions.

It's quite easy. I'll post one of my scripts that has those elements in it for you to look at. This is the VBscript I run from cmdlines.txt: Option Explicit Dim ws, fs, sysdrv, windir, progdir, Drives, Drive, strCD, strOEM Set ws = WScript.CreateObject("WScript.Shell") Set fs = CreateObject("Scripting.FileSystemObject") sysdrv = ws.ExpandEnvironmentStrings ("%SYSTEMDRIVE%") windir = ws.ExpandEnvironmentStrings ("%SYSTEMROOT%") progdir = ws.ExpandEnvironmentStrings ("%PROGRAMFILES%") Drives = Array("C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", _ "T", "U", "V", "W", "X", "Y", "Z") For Each Drive In Drives If fs.FileExists(Drive & ":\WIN51") Then strCD = Drive & ":\" Next strOEM = strCD & "OEM\" '********************************************************************** '** Subroutine; Set the RunOnceEx key with values ** '********************************************************************** Sub SetROE Dim strKeyPath strKeyPath = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\" ws.RegWrite strKeyPath & "TITLE", "Installing Software", "REG_SZ" ws.RegWrite strKeyPath & "001\", "Cleaning up" , "REG_SZ" ws.RegWrite strKeyPath & "001\1", strOEM & "001_Start.vbs", "REG_SZ" If fs.FileExists(strOEM & "Streets.7z") Then ws.RegWrite strKeyPath & "005\", "Microsoft Streets and Trips 2005", "REG_SZ" ws.RegWrite strKeyPath & "005\1", strOEM & "005_Streets.vbs", "REG_SZ" End If If fs.FileExists(strOEM & "Microsoft Office 2003 SP1\PRO11.MSI") Then ws.RegWrite strKeyPath & "010\", "Microsoft Office 2003 SP1", "REG_SZ" ws.RegWrite strKeyPath & "010\1", strOEM & "010_Office.vbs", "REG_SZ" End If ws.RegWrite strKeyPath & "015\", "Administrative Tools and Advanced Applications", "REG_SZ" ws.RegWrite strKeyPath & "015\1", strOEM & "015_Admin.vbs", "REG_SZ" ws.RegWrite strKeyPath & "020\", "Accessories and Multimedia Applications", "REG_SZ" ws.RegWrite strKeyPath & "020\1", strOEM & "020_Accessories.vbs", "REG_SZ" ws.RegWrite strKeyPath & "025\", "Utilities and CD-R Tools", "REG_SZ" ws.RegWrite strKeyPath & "025\1", strOEM & "025_Utilities.vbs", "REG_SZ" ws.RegWrite strKeyPath & "030\", "Security and Malware Applications", "REG_SZ" ws.RegWrite strKeyPath & "030\1", strOEM & "030_Security.vbs", "REG_SZ" ws.RegWrite strKeyPath & "050\", "Compress Select Directories", "REG_SZ" ws.RegWrite strKeyPath & "050\1", strOEM & "050_Compress.vbs", "REG_SZ" 'ws.RegWrite strKeyPath & "055\", "Initial Hard Disk Defragmentation", "REG_SZ" 'ws.RegWrite strKeyPath & "055\1", strOEM & "055_1stDefrag.vbs", "REG_SZ" ws.RegWrite strKeyPath & "060\", "Configure the Page File", "REG_SZ" ws.RegWrite strKeyPath & "060\1", strOEM & "060_PageFile.vbs", "REG_SZ" ws.RegWrite strKeyPath & "065\", "Defragment the Registry", "REG_SZ" ws.RegWrite strKeyPath & "065\1", strOEM & "065_RegDefrag.vbs", "REG_SZ" End Sub '********************************************************************** '** Run Tasks ** '********************************************************************** If fs.FileExists(sysdrv & "\Drivers.cmd") Then fs.DeleteFile(sysdrv & "\Drivers.cmd"), True ws.Run "REGEDIT /S cmdlines.reg",0,True SetROE EDIT: Well for some reason the comment lines got garbled. Also if you copy/paste this into notepad on a 1024x768 screen it should be much more readable.

@X-Savior It's a registry trick I picked up from either Gosh or GreenMachine, I don't remember which at the moment. Now that I'm thinking about it driver.cab is copied to the HD by default so this is all probably irrelevent. I think the purpose of copying i386 and changing the reg is so that you can do an Add/Remove Windows components operation or in case a driver needs files from the XP source, you won't need the Windows XP media. A handy trick for those installs where the computer owner loses their media or gets confused easily. But back to topic, it probably won't help out this situation.

strKeyPath = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\" fs.CopyFolder (strCD & "i386"), (windir & "\i386"),True If fs.FolderExists(windir & "\i386\svcpack") Then fs.DeleteFolder(windir & "\i386\svcpack"),True ws.RegWrite strKeyPath & "SourcePath", "%systemroot%\\i386\\", "REG_SZ" ws.RegWrite strKeyPath & "ServicePackSourcePath", "%systemroot%\\i386\\", "REG_SZ" This is a mere piece of a much larger VBscript that I run from RunOnceEx. It should give you the basic idea though.

You may want to try running compname as a part of Runonceex instead of during cmdlines. If you're using %MACHINENAME% and %MACHINEDOMAIN% in your sif file then you shouldn't even have to use netdom. It should join on it's own based on the info in the sif file. I've been using RIS for years and I think I have it down pretty well, pehaps there is something I didn't understand in your question.

I don't want to sound like a downer here, but if you don't really have any scripting experience, then you're going to be spending a long time on this. I spent many years programming when I was younger, then about 3 years ago decided I had to pick up on VBscript for a wide range of purposes. Even with my programming experience and 3 years under my belt with VBscript, this would definately take me a long while to construct and properly test. In a very simplified nutshell, you're going to need to tap into WMI to read some of the system component information. You'll then need to program the various aspects of decision making based on whatever the script finds. If you have a decent number of these desktops to install, my suggestion would be to either use RIS or an unattended CD/DVD. Couple either one with the BTS driverpacks. You'll save yourself a lot of time this way and IMO will end up with better installs. I "gave up the Ghost" long ago (lol) in favor of either of the two options I just mentioned. There's a lot of gotchas using SysPrep in conjuction with Ghost.