RogueSpear

The encrypted password, as I understand it, if for joining the computer to the domain.

If the drivers are signed, you'll end up breaking the driver signing for all of them.

In the support file, 3Com drivers are listed as being under \3C when in fact they are under \3. There is listed support for Lite-On WN5401A under \LIT, but no such directory exists. Not sure if the drivers exists elsewhere.

I think what he's referring to is RIPrep. Basically it allows RIS to deploy a canned image kind of like sysprep does with CD/DVD media. I don't like procedure at all, but it does seem to have quite a following.

I haven't tried that hotfix as it appears to not apply to Windows 2000 Server RIS servers. I have to say though, once you know what to do with the .inf file, it takes about 20 seconds to do it. And modifying the .inf file has no bearing on the PnP enumeration of the NIC during setup. The drivers for PnP are located elsewhere in the install source. EDIT: Guess I didn't scroll down far enough. It does seem to apply to 2000 SP4.

Extra NIC drivers for RIS The link above is my collection the most recent NIC drivers, with the .inf files modified for RIS. Credit here goes to Fencer128. I got the Broadcom 440x driver from him. Until then I had no idea there was even a seperate driver.

If you have a dual head card, it often reports two cards. Same with a laptop that can use the external VGA port as a second display.

Sounds like you could have a corrupted ISO image. I had some settings all wrong in UltraISO way back when and had similar errors.

It's not so much a missing driver as a missing HWID. I made an install CD for the girl and she ran it on her own, which is why I was unable to get the HWID from the unit. One big pain in the butt thing I noticed from talking her through it all on the phone is that you cannot disable the sound adapter from the BIOS. I ended up FedExing a new CD the next day with the RealTek sound drivers removed.

After getting tired of juggling different scripts and files for different installs, I've started to make all of my scripts, batches, etc. flexible and modular. So here's the PRESETUP.CMD file that I came up with: SET TAG=\WIN51IP.SP2 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:%TAG%" SET CDDRIVE=%%i: SET OEM=%CDDRIVE%\OEM IF EXIST %OEM%\7za.exe Copy %OEM%\7za.exe %SYSTEMROOT%\system32\7za.exe IF EXIST %OEM%\D*.7z 7za.exe x -y -aoa %OEM%\D*.7z -o%SYSTEMDRIVE% IF EXIST %SYSTEMDRIVE%\D*.7z 7za.exe x -y -aoa %SYSTEMDRIVE%\D*.7z -o%SYSTEMDRIVE% IF EXIST %SYSTEMDRIVE%\D*.7z DEL %SYSTEMDRIVE%\D*.7z IF EXIST %OEM%\000_SR*.7z 7za.exe x -y -aoa %OEM%\000_SR*.7z -o%SYSTEMROOT% IF EXIST %SYSTEMDRIVE%\000_SR*.7z 7za.exe x -y -aoa %SYSTEMDRIVE%\000_SR*.7z -o%SYSTEMROOT% IF EXIST %SYSTEMDRIVE%\000_SR*.7z DEL %SYSTEMDRIVE%\000_SR*.7z IF EXIST %OEM%\000_SD*.7z 7za.exe x -y -aoa %OEM%\000_SD*.7z -o%SYSTEMDRIVE% IF EXIST %SYSTEMDRIVE%\000_SD*.7z 7za.exe x -y -aoa %SYSTEMDRIVE%\000_SD*.7z -o%SYSTEMDRIVE% IF EXIST %SYSTEMDRIVE%\000_SD*.7z DEL %SYSTEMDRIVE%\000_SD*.7z IF EXIST %OEM%\SetDevicePath.exe SET SDP=%OEM%\SetDevicePath.exe IF EXIST %SYSTEMDRIVE%\SetDevicePath.exe SET SDP=%SYSTEMDRIVE%\SetDevicePath.exe IF EXIST %OEM%\DevPath.exe SET SDP=%OEM%\DevPath.exe IF EXIST %SYSTEMDRIVE%\DevPath.exe SET SDP=%SYSTEMDRIVE%\DevPath.exe IF EXIST %OEM%\WatchDriverSigningPolicy.exe SET WDSP=%OEM%\WatchDriverSigningPolicy.exe IF EXIST %SYSTEMDRIVE%\WatchDriverSigningPolicy.exe SET WDSP=%SYSTEMDRIVE%\WatchDriverSigningPolicy.exe IF EXIST %OEM%\WatchDSP.exe SET WDSP=%OEM%\WatchDSP.exe IF EXIST %SYSTEMDRIVE%\WatchDSP.exe SET WDSP=%SYSTEMDRIVE%\WatchDSP.exe IF EXIST %CDDRIVE%\D SET DP=%CDDRIVE%\D IF EXIST %SYSTEMDRIVE%\D SET DP=%SYSTEMDRIVE%\D %SDP% %DP% START %WDSP% You can execute your installs in the following ways: Method 2 install where you decompress the DriverPack .7z files to the %SystemDrive%. The DriverPack .7z files can be located either in the \OEM directory of your CD/DVD or in the root of your %SystemDrive% in the case of a RIS install. Perform the first half of a Method 1 slipstream and then put the \D directory right on your DVD. Put SetDevicePath.exe and WatchDriverSigningPolicy.exe in either location as well. It doesn't matter which location they're in, it will work. I also put in functionality to decompress 7-Zip archives to %SystemDrive% and to %SystemRoot% from the presetup.cmd file. If they are located on the %SystemDrive%, they will be deleted after decompressing. If the DriverPack .7z archive files are located in %SystemDrive% they will be deleted after decompressing. Update 03312006 If the DriverPack .7z archive files are located in %SystemDrive% they will be deleted after decompressing. Update 04112006 Now supports wildcard for decompressing archives to %SystemDrive% and %SystemRoot%. I found this made it easier for me with all of the different setups I have to maintain. As an example, you could have 000_WinDir.7z that you use in all installations, but then also have 000_WinDir-Work.7z and 000_WinDir-Home.7z for differing installs. With support for wildcards you can now just pick and choose as many or few as you want to include in your source. Update 04212006 It appears that there has been movement in making everything 8.3 compliant for those wanting to execute their unattended installs from winnt.exe. So I made a few changes to try and further that trend of compatibility. For the extra 7z archives, I changed the names replacing the previous long names with SR (SystemRoot) and SD (SystemDrive). PRESETUP.7z

There's certainly something going on. If you take a look at the Symantec AntiVirus Corp V10 distribution, any of the 32-bit application installs (SAV, SSC, etc.) contain the two Windows Installer runtime files, but the SAV x64 client does not. Yet the 64-bit install is an .msi installer. I don't know if this is because XP x64 comes with a more up to date version of Windows Installer where as the 32-bit applications are supposed to be compatible all the way down to NT4. I have a feeling all of this 64-bit stuff is going to require a lot of relearning and workarounds.

Yes.

I had the exact same problem with the exact same model of laptop. Unfortunately the owner of the laptop lives out of state and so I never got a chance to grab the HWIDs off of it. Glad someone else ran across this model and got them

Just so you guys know, WMI is a bit faster and uses less resources when installing something from an .msi installer. I always try to minimize the amount of times the command interpreter is invoked. It generally makes for faster running less resource hogging scripts.

V2.00 - 03/26/2006 - Finally I broke down and put the code in to do a Method 2 BTS DriverPack integration. Method 2 is the only one supported and will be the only one supported until the next gen BTS Slipstreamer is released. In order for the integration to work you must use the Method 2 Helper Addon that I include with either the RyanVM Integrator or nLite. In order to get the DriverPack Sound packs to function properly with HD sound adapters, you must integrate RyanVM's Post SP2 Update Pack with either the RVM Integrator or nLite. - I completely reworked all of the scripts. These will be better documented shortly in another thread which I will link to. This new set of scripts is completely modular. They will work with either a RIS or CD/DVD based install. There are two basic requirements - you must use my cmdlines.vbs script and the file 999_settings.ini must be located in $OEM$\$1 (for RIS) or %CDROM$\OEM (for CD/DVD). If there is a script that you don't want to use in RunOnceEx, just leave it out - everything is autodetected now. Some initial documentation is located in the 999_settings.ini file. - There is now a choice between using either WMI or SysInternal's PsService to restart the BINL service. This will hopefully eliminate the issues with Windows Server 2003 throwing up a permissions error. The selection is a setting in AutoRIS.ini. Due to licensing restrictions I am unable to include PsService with the AutoRIS distribution. You can download it from SysInternals directly here. I've tested out all of the new features numerous times and it all seems to work great, but there's nothing like putting it out in the wild and getting some real feedback. Now version 1.52 was downloaded over 2,000 times and with the exception of a couple people, I've heard virtually nothing. I'll be particularly interested in hearing whether or not the PsService implementation solves the permission issue for 2003 users. I don't have any computers with a special mass storage controller to test on. In all of my tests the integration completes without error and the OS installs without error. But this is really only half a test since the extra drivers are not being used. If you do have problems that are mass storage related, please refer to the DriverPack Mass Storage forum to see if there are any outstanding issues with your hardware.

Here is a script that should illustrate two things for you. First is the proper way to install .msi based software from within a VBscript. Second, there is a demonstration of constructing and executing a fairly complex 7-Zip command line from within a VBscript. There are times when you need to get a little creative as well. Here is an example where you actually need to use four quotes on either side of a variable: If fs.FileExists(OEM & "\101_AllUsers.7z") Then ws.Run(str7Zcmd & "\101_AllUsers.7z -o" & """" & allusers & """"),0,True the variable allusers is mapped to the environment variable %AllUsersProfile% elsewhere in the script. The thing to keep in mind is that with native WSH commands you often don't need to worry about long file names with spaces in them, but with ws.Run whatever is in there is being passed along to the command interpreter. So you do need to care. Keeping in mind the rule of using double quotes to simulate a quote, I figured (correctly) that using four quotes would simulate a double quote Whenever you need to simulate a double quote however you need to seperate it off from the rest by use of the &. EDIT: Got a little carried away there and forgot to mention that your options need to be outside of the parenthesis. Notice in the code above """"), 0, True. The options are after the closing parenthesis. 130_Streets.7z

I'd make a key under HKLM\Software. Something like HKLM\Software\Hulk. With all of the application repacking that I've done, I can't even believe the way some software publishers cavalierly polute the registry. I think you could put something almost anyplace you like, but the Software branch seems relatively benign.

Depending on your budget (and your friend's), you can do an end to end VPN using a couple of cheap Linksys VPN endpoint adapters. I set this up once for a small business owner and it worked pretty nice. There are some limitations compared to something like a Cisco PIX or VPN Concentrator setup, but it's also way cheaper. Most of the software implementations I've run into either require or work much better when there's a dedicated computer on each end handling the VPN chores.

I always just make a batch file and point config.txt to that. Seems a lot easier than altering code.

If you look at my most recent post in the thread, there's a list of installers that I have removed. Windows Defender is one of those that I removed. I removed most, if not all, Microsoft titles that require a WGA check in order to download.

There's three files on various web sites: icomp.exe, i5comp.exe, and i6comp.exe that will decompress different versions of InstallShield cab files from the command line. Google should yield quick results.

Actually that little bit of trivia was from when I took all of the MCSE 2000 exams. I don't know it holds true with W2K3.

I've never heard of anybody creating a VPN from XP to XP before and quite honestly I didn't even know it was possible. If it is possible however, I'd venture to say that XP Home will not work in this scenario. So you may want to verify the other end before expending too much effort into this.

This is purely speculation.. but perhaps the RIS server is detecting a slow link and rather than give an intelligable error message that makes sense, this is what you're seeing. It's been a long while since I've needed to care about the specifics of AD Sites and throughput speed detection, but that's about the only thing that comes to mind. Remember, you're going to be pumping about 400MB across that WAN link.

Thanks for hammering this out Fencer. All good information to know. And glad to see everything's working again for you