Albuquerque

Regarding HAL issues on Sysprepped machines -- something new we're doing with the PE CD here in my office is using a standard ACPI HAL'd Sysprep image, and then dropping the appropriate HAL onto the machine after Ghost finishes but before we reboot. This gives us the ability to use a single sysprep image on essentially every machine in our environment... So long as we have the proper mass storage drivers to make it boot of course

Installing it now on my Inspiron... Heard a rumor online that MS's Windows Validation Servers were plugged up for a day or so because of all the activations FOr some reason, I don't recall seeing BETA 2 on the little desktop version stamp until 5381... Oh well.

Curious how much different this is from 5381.1 that was also labeled as Beta 2 (whether it really was or not)

Nope, I'm using the exact same software you are: Server 2003 SP1 July 2005 Windows Preinstallation Environment OPK (WinPE 1.6) I do a MKIMG /PNP /WMI I do a BUILDOPTIONALCOMPONENTS (for WSH and HTA support) I do the DRVINST and point it to a huge pile of drivers (Network, Video, Mass Storage, etc) I copy in my scripts, move it to an SDI file, create an ISO, burn it and boot it without any problems.

You've essentially got the right idea; anything you see in the SCSI section will indeed be accessible. And yes, you can simply copy in the appropriate INF and SYS files to gain additional access to other mass storage drivers in most cases... I had to make some changes to the TXTSETUP.SIF file to get my Promise 20276 RAID controller to work correctly, but I didn't have to make any changes like that for the Intel ICH5R / ICH6R / AHCI devices I've run into. Not sure what the exact differences are...

Hmmm, well I'm using Intel 10.3 drivers too without any problems. I'd suggest you try completely rebuilding your Windows PE image from scratch (MKIMG, then DRVINST) and checking again. There must be something wrong with your PE build somehow.

Your BSOD is almost assuredly "Inaccessible Boot Device"; this happens when Windows tries to make the switch from real mode into protected mode but does not have a 32 bit driver interface for your boot device. In this case, when you pressed skip to NVATABUS.SYS, you told it to not copy the system driver file responsible for accessing your (IDE = ATA) hard drive. So, as soon as the kernel enters protected mode, it can no longer access the local drive and it bombs out. You need to identify why it cannot find that NVATABUS file. Either it's not there, or not in the proper folder structure, or something else. But that's your problem

Al, would this also be true for integration in any pre-install/unattended setup? I had a problem with this just recently, although "human error" (mine) could have been at work. In other words, even if you are going to do a post install, will the INF look for the prounstl.exe? When I did a post install, I don't remember the update driver process going into executable mode. If I remember it correctly, I think it just picked up the driver via INF. Thanks You certainly pose a valid question; unfortunately I cannot answer. My educated guess is that it will look for and attempt to install that PROUNSTL.EXE file, as we also include it in both of our sysprepped XP and 2K OS ghost image files. However, I can't say for certain that it's actually needed... Being the kind of guy I am, I'd try it without first. And if it doesn't work, then throw it back in MTalan: Where did you obtain your Pro 100/1000 driver? And what version is it? I'm using the entire gammut of Intel 100mbit -> 10gbit network drivers without issue (e100b325, e1000325, ixgb325) and as such I know they do function normally within Windows PE 1.6. Are you perhaps booting this over PXE rather than from CD?

Both of you are speaking as if this is some sort of final release... Are you sure you know what you're looking at? We're not even at BETA 2 yet; the earliest release date for this software is still almost six months out. Yes, it uses XP sounds. I prefer they spend time fixing bugs versus making up new noises. Yes, the UI still isn't 100% yet, during install and otherwise. I prefer they get the functions working and, once it all actually WORKS, they can spend time making it prettier. Yes, things are slow and it soaks up ram. Might this conceivably be linked somehow to the whole "beta" stage it's in? I'm not here to be a Microsoft "apologist", there are some core-level issues with this OS that aren't yet fixed that are quite glaring; issues with static IP addressing is certainly one that's high on my list. But six months away from their earliest speculated release date isn't a fair time to gripe at them about missing video codecs, or GUI quirks in the start menu, or missing installation time stamp. That start menu has changed at least three times in the last six months. The install screen has changed almost every time I've installed it. And hell, at least video works at some fundamental level in the recent builds; I couldn't even get this far in many of the previous releases.

Oops... Sorry I had deleted it, thinking that the Uninstaller utility certainly wouldn't be needed; I was proven wrong. Bleh. Have you used any tools to "shrink" your PE image size?

The Intel PRO drivers require executable "prounstl.exe" to exist in I386\System32 folder. This is causing your error.

I'm not very sure that a guide would help; most of this stuff isn't something you can just "snap in" and go. The massive quantity of scripting I've generated has simply evolved to this point from many previous years of combined DOS and recently WinPE bootable CD work. And in fact, I'd rather give a person the big picture and let their brain figure out the best way to do it in their environment. Some of the complexity I have built into my scripting is simply because of the complexity of my environment. Someone who doesn't need the entire scope of my scripting functionality would have way too much to look at; someone who needs even more would probably get a headache looking at my code Our environment is up for a pretty large change in how we build workstations; we're still utterly dependant on Ghost images and we've got some ugly machine dependancies going on. It's time to move to dynamically created unattend.txt files generated from XML pages, WMI queries and voodoo magic

First: For anyone who wants to see what I do to knock my PE size down, visit my reply to another thread. Legally, Microsoft doesn't allow distribution of 1.x PE images as you likely already know. Even outside of that, the PE image I develop also contains licensed and copyrighted software, and several components of the scripting contain sensitive corporate data such as service account passwords and information about our network topology. While the information is "encoded" to keep the general user populace out, it wouldn't be hard to disassemble As such, I'm sure you understand, I cannot host a file for your perusal. However, I can give you the general gist of what I do: I first use ISOLinux for the underlying structure of the CD. This of course allows me to put all the BIOS flash utilities, OEM standalone diagnostic software, WinPE and other items into a simple boot menu. I like ISOLinux because it's VERY straight forward and works on nearly everything I need. Within PE, I've developed two "tiers" of scripting -- one part on the CD, one part that resides on multiple servers in our environment. The CD portion does the following: Boot to Ramdisk from SDI, Enumerate PnP, start networking If the CD is still in the drive, it's ejected so the tech doesn't forget Query for available NIC cards, then query for link, then query for IP address and connection speed If a NIC is not available, it flips to "CD Only" mode (see further below) It correlates the local IP against an INF file that identifies "parent" servers for scripting (supports definition of class A, B or C subnets, references a domain to authenticate against, parent server name, upload directory for imaging, download directory for script files, among a few other items It performs a version check -- all my SDI images are named with a unique ID that correlates to that CD release. If that unique ID is not "allowed" on that parent server (outdated, only for testing use, whatever) then it disconnects the network, stops the workstation service and deletes from ramdisk some fundamental files needed for network functionality. Long story, but this became a requirement a few years ago and has worked well Once the CD version checks out, it copies the network script files to a temp directory in the ramdrive and then starts the primary network script from that temp location (I do not run them directly from the server; this gives me the ability to perform network script updates without "killing" a CD that may be currently using said scripts) The "CD-only" scripting provides an easy interface for three levels of physical disk wipe + make DOS bootable, ghost physical disk to/from CD/DVD, offline checkdisk of a HDD volume, offline checkdisk of a HDD volume, and a few other items such as dropping to a command prompt. The "network" code does some further items, such as the following: Detect hardware type. This allows me to spawn seperate core menus for working with servers versus workstations. Also allows other scripting branches later for devices that may need it (VMWare machines for enabling acceleration, tablet PC's, IBM Thinkpads that need our special "bios fix", et al) Ghost options (upload to parent server if available, download standard 2K or XP image, download a previously uploaded image, join a multicast session) It also allows access to the "CD Only" menu, and access to a few other little utilities such as hosting a GhostCast server, ghost explorer, regedit, notepad, et al. That gives you the REALLY high level version of what my CD does. Since I'm using the legitemate Microsoft PE tool, I don't have the luxury of "snapping in" a bunch of cool tools that are already provided. However, with only a small bit of work, you can "convert" essentially any BartPE snapin to work with the real PE. And why not, since they're the same damned OS anyway?

It's still a bit of a memory hog, still a bit slow to boot, and hibernate/suspend don't always work perfectly. But even with the quirks, I'm having quite a bit of good luck with it this round. It found every piece of hardware on my laptop without issue, and over the last two days of relatively consistent abuse, I've only had a single app crash on me (it was some background process that was unrelated to the applications I was working in) Hardware specs on the Dell: T2300 Core Duo (1.66ghz x 2) 1GB Dual Channel DDR2 80gb SATA HDD 8x DL-DVDRW ATI x1300 64mb + 192mb "hypermemory" Conexant Hi-Def Audio + 56k SoftModem Ricoh multi-card reader Broadcom 440x nic + Intel 3945 A/B/G Wireless I noticed in the event log that *something* attached to the PCI bus isn't working 100%, but whatever it is, it has yet to seemingly affect me. Overall, the stability, general performance and hardware interaction has been quite good in this release. Of course, now that I've said this, it will probably throw itself into the bit-bucket and die

The best people to ask about this would be the developer(s) of your application. It sounds like something is going wrong with the app itself, which likely few (if any) people on this forum could help you with.

Hmmm, mine was available directly on the MS Connect site. Maybe it's logon-based as to who sees it and who doesn't; I didn't think of that.

Microsoft released the 5308 WAIK probably 30-45 days ago on their Connect website. If you've got all the licensing you say you do, just go out to the MS Connect site and download it.

Some of the earlier "pro vivo" cards were rebadged XTPE's and came with 1.6ns memory -- but also had core chips that failed speed bin testing at XTPE speeds. Those usually had a lot of room for memory overclock but barely any for GPU overclock. Most of the later "pro" cards have better cores now, but come with 2.0ns memory. As such, they do quite well at the GPU level but bite it on memory overclocks -- it sounds like you may have run into a similar situation. My voltmodded watercooled X800 Pro Vivo (unlocked to 16 pipes) has been merrily poking along at 600/585 for the last 18 months or so. It's been a great card and I'm still able to play nearly any of my games at reasonable quality levels on my HDTV (1280x720) with some amount of AA and AF.

By the quality of your "review", I'd bet a dollar that it was a warezed copy anyway. Good riddance to you and your (likely illegal) copy of Vista.

For a *very* long time I used an old HP Vectra XA5 to do exactly what you were asking. It was: HP 85W power supply 32x CDROM 2gb 4200RPM harddrive 192mb EDO ram Pentium original 166 underclocked to 90mhz Onboard AMD 10/100nic and additional 3Com 3C905b 10/100nic Matrox Millenium 2064W 2mb PCI video card No monitor, no keyboard, no mouse. Set the BIOS to not error out and continue booting w/o Keyboard Used it as a software firewall, router, DHCP server, DNS cache, fileserver (for holding all my MP3's via external USB 250gb drive), terminal server and telnet server. Enjoyed uptimes in excess of 200 days...

I mentioned UPX in a WindowsPE thread. Essentially, any file you compress with UPX will "automatically uncompress" itself when run. You do not need to take any other actions... When talking about the individual application, memory utilization doesn't really increase by a noteable amount. However, notice how I bolded individual? UPX-compressed files cannot be "instanced" within RAM; a great example is SHELL32.DLL. If you compress SHELL32.DLL, your system will suddenly start hogging 40+ MB more memory... Why? It's not because the individual app is taking more, but because Windows by default loads the module once and then references that once-loaded module multiple times for all its needs. When you compress it with UPX, Windows can no longer use it that way and must load it again and again every time an instance is required. The result is, SHELL32.DLL gets loaded into ram dozens of times, and as such takes up seriously more ram. The lesson to be learned is -- while most files can be compressed, you should perform testing to ensure they should be compressed.

I do it slightly differently than Chris... All of our workstations use a Ghost image of some sort, depending on model (sysprep for most, a few tablet-specific images.) I use a combination of WSH script, WMI queries and DISKPART to identify if this machine has a current BIOS (use an "answer file" on a centralized server location), and if so: I query for the size of the destination disk, calculate the smallest partition that can be created on that disk (typically ~7mb), create a primary partition that is the entire size of the disk minus that minimum determined size, and then create a second primary partition that is the remainder. I ghost the workstation OS image into the big primary partition, and I then ghost down a FAT16 "bios fix" image into that remaining tiny portion at the end. I set that second utility partition active and force a reboot. Upon reboot, that utility image does several things: Loads all datasets into a ramdrive Points COMMAND.COM into ramdrive as well Identifies the hardware. * Flash the BIOS accordingly Completely removes the second partition from the disk Re-sets the first primary partition to be active (bootable) Reboots into the normal Windows OS Now, about the asterisk... To keep my job simple, I wanted this one DOS utility partition to work on every piece of hardware in my organization. And as such, I need to identify (within DOS) which piece of hardware I'm on before I can flash the BIOS. I built an answer using the DOS utility PCISCAN by creating what I call "fingerprint files". Without going into uber detail, you can determine what piece of hardware you're on by what devices (and in what layout or configuration) are in a PCISCAN dump. Once I figure that out, I know what BIOS flash I need to use. There is obviously a big chunk I've left out, but anyone here should be smart enough to figure out the interim pieces. And if not, then I'm going to say you need to spend the time to figure it out anyway Oh, and why do I figure the "smallest partiiton size possible?" Because when you delete a 7mb partition from a >20GB drive, the remaining "emtpy" space is so small that Windows doesn't show it in Disk Management. Thus, our end users don't b***h about somehow not using their entire disk

My colleague had this problem on his laptop..Can it be fix on a laptop? Thx Sure, disable the CPU's ability to change speeds. Basically all mobile chipsets have a function that allows you to "lock" the CPU speed to either the lowest or highest setting. Just set it that way and all should be well.

Interesting note on the Dells, my office uses Optiplex 260/270/280 machines. I might have a look into their offerings to see if it's something I want to integrate into my scripting support... On another note, is it possible that the BIOS tool is erroring out because it's unable to write a temporary file to disk somewhere? It might gripe about lacking permissions because it cannot write to disk from your PE image. I'm just guessing of course...

Best thing about the Ghost option is that FAT / FAT32 images can be directly manipulated (files dropped in, files deleted, et al) unlike NTFS images that are read-only. THus, you can maintain one "standard" ghost image on a network somewhere and always pull it down, and make updates to it whenever you need.