GTOOOOOH

I have nothing in the autoexec.bat and the only lines in config.sys are the following: DEVICE=GRUB.EXE INSTALL=GRUB.EXE SHELL=GRUB.EXE I even tried a blank config.sys and then running GRUB from the a:\ prompt... same error, but, if I switch to an XP MS-DOS boot disk and rub GRUB from A: it's fine. I'm using the latest version.

I'm trying to use a Win98SE Bootdisk to kick-off Grub4DOS, doesn't seem possible though I keep getting an error: Failure restore ROM INT 0x11 vector. Unsupposed DOS, device driver or TSR. If I use an XP bootdisk it's fine, but I'm forced to use Win98SE bootdisk for this old PXE server we have and I cannot upgrade the PXE... so, can GRUB4DOS be activated from a 98SE bootdisk?

This is more of an exploratory question... here's my problem.. I currently use a scripted version of Robocopy to sync up some usb keys with a server share, however, when we go across time zones, it's an issue, and when we change times, like Daylight Savings, and Daylight Spending in the U.S. we get out of sync because the operating system see's it's files as 1 hour ahead or behind what's on the key(s). I know there are programs out there to compensate for this, however, I'm looking for a FREE solution, and I use AIT constantly, for everything, but this one is eluding me. Does anyone know of a free utility to compensate for time zone issues? XXCopy requires you purchase the Pro version to get that functionality, and I'm not aware of any others?

I think the easiest way is to search on here how to dual-boot with PE in the Windows Boot Menu?

It's going to cost you big time!!!! NOTE! - All code is written in AutoIT - !NOTE Alright, so first thing, since I use DP's I have the typical OEM directory on the root of my install source. I also have an OEM2 that's for MY DP's, and in the sources directory where the boot.wim resides I keep my .ini files. That being said, onto the code... MODELS.INI - This is the file it checks after reading the BIOS to see if the models/models section matches what it found in the BIOS, if so it reads the model specific section/filename entry for what custom DP files it needs to use rather then the OEM\DP files which are only used if it doesn't find the specific model entry in this file. Get it? Another thing I need to mention, since some of these DP's are actually program installs, I've also packaged them to be unattended as well, so, something like the HP DriveGuard software you'll see below is a scripted app installation. You'll see below from the T61 section that's where I really got granular with packaging the drivers individually as well as apps. From this point forward, that's the way I do all the drivers/apps, singular. [models] models=2510p,6710b,8710w,dc7800p,t61 [2510p] Filename=dpricoh4in1R5C83x84x.7z,dpricoh4in1R5C83x84x.ini,dphplaptops.7z,dphpdriveguard.7z,dphpdrive guard.ini,dphpfingerprintreader.7z,dphpfingerprintreader.ini,dphpprotecttools.7z,dphpprotecttools.in i ,dphpquicklaunch.7z,dphpquicklaunch.ini [6710b] Filename=dphplaptops.7z,dphpdriveguard.7z,dphpdriveguard.ini,dphpfingerprintreader.7z,dphpfingerprin treader.ini,dphpprotecttools.7z,dphpprotecttools.ini,dphpquicklaunch.7z,dphpquicklaunch.ini,dpricoh4 i n1R5C83x84x.7z,dpricoh4in1R5C83x84x.ini [8710w] Filename=dphplaptops.7z,dphpdriveguard.7z,dphpdriveguard.ini,dphpfingerprintreader.7z,dphpfingerprin treader.ini,dphpprotecttools.7z,dphpprotecttools.ini,dphpquicklaunch.7z,dphpquicklaunch.ini,dpricoh4 i n1R5C83x84x.7z,dpricoh4in1R5C83x84x.ini [dc7800p] Filename=dphpdesktops.7z,dphplightscribe.7z,dphplightscribe.ini,dphpprotecttools.7z,dphpprotecttools .ini [t61] Filename=dpibmatmeltpm.7z,dpibmACPIPowerManagement.7z,dpibmACPIPowerManagement.ini,dpibmActiveProtec tionSystem.7z,dpibmActiveProtectionSystem.ini,dpibmFingerPrintReader.7z,dpibmFingerPrintReader.ini,d p ibmaccessconnections.7z,dpibmaccessconnections.ini,dpibmmodem.7z,dpibmPowerManager.7z,dpibmPowerMana g er.ini,dpibmTX61SoundMaxAudio.7z,dpibmTX61SoundMaxAudio.ini,dpibmBlueTooth.7z,dpibmBlueTooth.ini,dpI n telGM965chipset.7z,dpIntelGM965chipset.ini,dpIntelPro1000a.7z,dpricoh4in1R5C83x84x.7z,dpricoh4in1R5C 8 3x84x.ini,dpSecureDigital6040501.7z,dpibmSmartCard.7z,dpNvidia614115666.7z,dpIntelVideo1.7z,dpIntelP r oWiFi1.7z,dpUltraNav751725.7z,dpUltraNav751725.ini,dpibmUltraNavUtility.7z,dpibmUltraNavUtility.ini, d pDisableTurboMemory.7z,dpIntelVideo2.7z NEXT!!!!! I'll show you the BIOS capture coding that reads the BIOS, then does everything I mentioned above, parsing the INI copying the necessary files, and then building a customized manifest.ini for that model based on what was read from the first ini file. It does this for any INI files MENTIONED in the model specific section, I do that because in those INI files I put the command-line switches for the applications specific packages, since most of them are InstallShield packages it's setup.exe /S /v/qn. Func Model() $wbemFlagReturnImmediately = 0x10 $wbemFlagForwardOnly = 0x20 $colItems = "" $objWMIService = ObjGet("winmgmts:\\localhost\root\CIMV2") $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystemProduct", "WQL", _ $wbemFlagReturnImmediately + $wbemFlagForwardOnly) For $objItem In $colItems $biosinfo[0] = $objItem.Vendor; =====================================================MANUFACTURER, ALWAYS AVAILABLE=================================================================== $biosinfo[1] = $objItem.Name $biosinfo[2]= $objItem.Version Next If $biosinfo[0] <> "Lenovo" And $biosinfo[0] <> "IBM" Then $biosinfo[2] = $biosinfo[1] For $m = 1 To $allmodels[0] $model = StringInStr($biosinfo[2], $allmodels[$m]) If $model <> 0 Then $foundit = "1" ExitLoop EndIf Next If $foundit = "1" Then $filename = IniRead($path & "\sources\models.ini", $allmodels[$m], "Filename","") RunWait(@COMSPEC & " /c x:\windows\system32\robocopy y:\oem\bin c:\temp\oem\bin /e /z", "x:\windows\system32") FileCopy("y:\oem\ATICCC.ins", "c:\temp\oem\ATICCC.ins", 9) FileCopy("y:\oem\DPM711.7z", "c:\temp\oem\DPM711.7z", 9) $filename = StringSplit($filename, ",") $inicounter = 1 For $filecount = 1 To $filename[0] FileCopy("y:\oem2\" & $filename[$filecount], "c:\temp\oem\" & $filename[$filecount], 9) $inifile = StringInStr($filename[$filecount], ".ini") If $inifile <> 0 Then IniWrite("c:\temp\manifest.ini", "inis", $inicounter, $filename[$filecount]) $inicounter = $inicounter+1 EndIf Next Else; ======================================================================GENERAL DRIVER PACK USED, MODEL NOT SPECIFIC======================================================================================== RunWait(@COMSPEC & " /c x:\windows\system32\robocopy y:\oem c:\temp\oem /e /z", "x:\windows\system32") EndIf ;WriteMif() Return EndFunc This last piece of code is run on XP's first boot where it automatically logs in as the Administrator account, and after the DP cleanup runs. This checks for the manifest.ini, and if it exists, it knows that packaged apps have to be installed. If FileExists("c:\temp\manifest.ini") Then $CountLines = _FileCountLines("c:\temp\manifest.ini") $CountLines = $CountLines-1 For $iniloop = 1 To $CountLines $inis = INIRead("c:\temp\manifest.ini", "inis", $iniloop,"") $ininame = StringTrimRight($inis, 4) $CountLines2 = _FileCountLines("c:\temp\oem\" & $inis) $CountLines2 = $CountLines2-1 For $installloop = 1 To $CountLines2 $installfile = INIRead("c:\temp\oem\" & $inis, "installs", $installloop,"") $msifile = StringInStr($installfile, ".msi") If $msifile <> 0 Then RunWait(@ComSpec & " /c C:\WINDOWS\system32\msiexec /i c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop & "\" & $installfile, "c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop, @SW_HIDE) Else RunWait(@ComSpec & " /c c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop & "\" & $installfile, "c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop, @SW_HIDE) EndIf Next Next EndIf That's it, looking at the system it's simple as all hell, but as you know, getting simple is the hardest thing to do.

Wild, I just built something similar, but I used the DriverPacks program/method, heavily customized/rewritten. Mine reads the BIOS, determines the machine type, based on that, it walks an INI, if it finds a match it ROBOCOPY's the filenames listed in the INI to the typical DriverPacks location I use. The files listed are 7Zip packages I build, and are simply 1 file per driver. So, 1 file is for a modem for that specific model, 1 for audio, 1 for the chipset, etc... then I just let DriverPacks take over and do the rest, works perfectly everytime. The other cool thing, no duplicate drivers, I keep a manifest of what drivers I've already packaged, and if a different model computer uses the same hardware, I just copy/paste that package info from 1 spot in the INI to the corresponding spot. Works wonders!!

You know you could just slipstream all your hotfixes right?

Forget it, I got it... and in case anyone is interested, adding WMI adds about 50mb.

So, I'm tinkering with a WIM file I have, it's stripped down big time. 79mb, it runs, but when I try to add the WMI package to it, it says it's been prep'd already, true. Now what? I thought I could mount the WIM, and export it to a new WIM, then add packages to it, however that's not the case. Am I doing something wrong here, or have I misunderstood the /export option?

Jazkal peimg.exe /prep /f C:\winpe_2x86\Mount\Windows While attempting to shrink my image some I used the PREP line in BOLD above and got the error: PEIMG failed to complete the operation with status code 0x80004005.

So, this is kind of like a BartPE, but a build it yourself way?

I did post that because of the high security environment I manage and compliancy with several regulatory groups we must maintain certain standards. My point is that I used to use images and because of the new standards we traded time for compliancy, and now that my new method is set, I have some time to explore some hybrid of images/uai. Best of both worlds ya know, speed AND compliancy. Also, my next step in speed improvement is building individual driver packs for each model computer we have rather then relying on the bloat of the current driverpacks system. I've already done this for several of our models and it's a great time saver to have my scripts in PE read the BIOS through a WMI AutoIT script, then push the specific DP for the machine as well as any manufacturer related items. It's working great and cut out 10-15min from the install.

I know and it's so frustrating, I keep thinking about Vista, and whatever platform MS comes out with next. The fact that you can deploy without HAL issues or having to try and overcome HAL issues is a big time saver in a largely mixed environment, and yet I still won't be able to take advantage of it. I actually had a question about HAL scripts and such. When I look in the registry of a machine that I've booted with WinPE2, you know that key that tells you the HardwareID for the HAL? Every multiprocessor machine I look at, just says acpiapic... so, isn't that wrong? Because in Windows the same machine is listed as an MP_ACPI or something like that?

Ok, so my problem is time versus consistency. Some people on here use images for OS deployment and they get around HAL issues with XP in various ways. So, let's say I want to go that route and I tackle the HAL issue. Ok... the next real issue for me is image consistency. How can you, or CAN YOU at all keep an image up to date with MS patches, virus dat's, new tweaks/settings, application installations, etc, etc with as little work as slipstreaming? Ideally I would love to dump an XP WIM on any machine, and have it have the same patch levels virus dat's, etc, etc as a bare metal would have that has been slipstreamed and has post installation tasks attached? I realize I can attach post installation tasks to an image, but what about MS patches, OS tweaks, virus DAT levels INSIDE the image? Any thoughts? Best practices?

I wish I only had 22 models and that right there is the reason why imaging with sysprep and re-sysprepping would be so prohibitive on time for me, by the time I'm "done" we'd have new models to test. Currently at the last count we had over 6 manufacturers and 53 models, now for the most part as long as the HAL is the same, you can cut that number in half, however staying on top of virus dat's and critical KB's from MS because we run Safe Access to lock down all our machines requires I stay up to date by no less then 4 days, otherwise a machine in our domain is quarantined and the user unable to get a production IP. This also forces us to use local media rather then a network install because PXE can't hand out addresses in our production environment because Safe Access blocks machines not in our domain. Your way of doing things is really pie-in-the-sky for me, one day maybe, but with so much legacy equipment, SOX restrictions, and red-tape... 1 hour is the best we got at this point.