Are you running the Critical Database Cleanup after you installed your first machine? If the device is not present in the reference machine, it probably won't get set to "BOOT" hence your issue of order :)
Follow the documented method for adding additional mass storage drivers and trigger the cleanup to deploy after the image gets applied. It will always work then... jlc -----Original Message----- From: Sam Cayze [mailto:[email protected]] Sent: Monday, January 05, 2009 6:37 PM To: NT System Admin Issues Subject: RE: AHCI Sata and sysprep Ben, this is great info, and will get me well on my way! Oddly enough, If sysprep the image on the 6400 first, then deploy, then swap hard drive to a 6500, it works great! (Opposite order of what I tried the first time). But still, I like to know the inner workings of why this works - especially when we want these images rock solid and stable, and your post does just that. Thanks! Sam -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Monday, January 05, 2009 5:15 PM To: NT System Admin Issues Subject: Re: AHCI Sata and sysprep On Mon, Jan 5, 2009 at 5:41 PM, Sam Cayze <[email protected]> wrote: > BUT, I noticed that if I take the hard drive out of a 6500, and put it > in a 6400, it will still BSOD. [...] > Any way around this? Or does AHCI complicated things so much that I > am asking too much... First: NT device drivers are implemented (at least in part) as NT services. At least, some of them are. I'm unclear on what distinguishes between a service that's a driver and a service that's just a service. But anyway, every installed NT service has a start type setting. The start type can be one of several values. You're prolly familiar with AUTOMATIC, DEMAND ("Manual"), and DISABLED. Less well-known are BOOT and SYSTEM. SYSTEM services mostly behave like "regular" services, but for drivers instead. They're loaded after the kernel is running, by the SCM (Service Control Manager). I think their startup might be influenced by what hardware is actually found in the system, but they're generally not all that different. BOOT services are special. They're the only service not loaded by the SCM. They get loaded by the OS loader, before the kernel is started. The OS loader uses BIOS routines (mainly software interrupt 0x13), not NT device drivers. BOOT services exist mainly to give the kernel enough marbles to actually be able to read the disk and decipher the filesystem. This solves the chicken-and-egg problem of how the kernel loads the driver needed to read the disk with the driver. If your disk controller isn't handled by one of your BOOT drivers, the kernel will crash (STOP/BugCheck) almost as soon as it starts, with the INACCESSIBLE_BOOT_DEVICE code. So what you need to do is find out which driver service(s) your various disk controllers need, and enable them in the registry as BOOT drivers. That way the kernel will be able to see them once it's started. That's what all the SYSPREP "MassStorage" shenanigans are supposed to accomplish. It sounds like for you, that's not happening properly. Why, I dunno, but hopefully this gives you enough information to start digging, or at least some Google fodder. Two particular keywords of use for searching: INACCESSIBLE_BOOT_DEVICE SERVICE_BOOT_START. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
