mmarable

Don't bother with prestaging your machines in AD, it's far easier to do a custom setup. Do go with flat images as opposed to RIPrep images, it's far easier. Go into the properties of your RIS server in AD, and enable custom setup. While you're there, change the target AD container if you wish. Now, when you start a RIS session, after you authenticate you'll have the options to do either an automatic or custom setup. If you choose automatic, you will select the image to deploy and everything is (you guessed it) automatic. If you choose to do a custom, you select the image, and then you get a screen where you can set the computer name, and even specify a specific container for the computer account to go.

I ran across something about setting the size of the initial partion in WinNT.sif. That (if it works) would get you your first partition. From there you'd have to script DiskPart to run and create the others and reassign drive letters. Other than that, you will have to go with PE.

How are these RunOnceEx# files triggered? It sounds like #1 runs, then it executes #2, and so on. If that's the case, then what sounds like is happening is that RunOnceEx1 starts RunOnceEx2, and it will not move on to the next line (your EXIT command) until RunOnceEx2 completes and returns control. This continues on through RunOnceEx6. When that completes, control is returned to #5, which then exits and returns control to #4, which exits and returns control to #3, and so on. I'm only going by how you have described it. If you post your code everyone will have an easier time troubleshooting it.

What is the syntax of the commands you're using to populate RunOnceEx? The syntax for the REG command differes in Win2000 and WinXP/2003.

I have never found a way to boot the USB drive exactly as a CD would. You're best bet would be an WinPE bootable USB drive that kicks off the install. You can then use PE to run any system prep scripts you might want, like partitioning, etc. For example, you can run a script that determines what model machine you're installing to and it only copies over the drivers needed for that model.

Sure, it can easily be done. You can go with WinPE and you can script all of this. Since you only know the set size that you want your D drive to be you won't be able to use trickery in the SIF file to create your partitions. In a nutshell, you'll boot into WinPE and have a diskpart script partition up your drive. Or, since you're planning on using Ghost you can get real slick and use GDISK32 to create a hidden partiiton and use that for your Ghosting. You'll then have WinPE kick off an unattended install of WinXP, install Ghost and even Ghost the drive to an image. The problem you're going to be running in to is when it comes time to recover. The user will have to boot from something other than their Windows drive. So, they'll have to boot from a CD with Ghost or you can do like we do and have a hidden partition at the end of the drive that will boot WinPE and allow them to Ghost the C drive.

It's a networking issue. Can you ping the other box successfully? Check your firewall settings. If file/printer sharing (someting like that) is not an exception, then you won't be able to connect as the other computer will block the incoming conneciton. By default, XP's firewall does not have this exception enabled.

The folders can be named anything you like. For example, on my disk I have the following: $OEM$\$1\Drivers Easy enough so far. From there I break it down by my different hardware. The drivers for my ATI cards are here: $OEM$\$1\Drivers\ATI\x700 I use the same NIC in all my machines: $OEM$\$1\Drivers\Broadcom Next is my Dell laptop: $OEM$\$1\Drivers\Dell\D600\Audio $OEM$\$1\Drivers\Dell\D600\Video $OEM$\$1\Drivers\Dell\D600\Wireless Now my desktop: $OEM$\$1\Drivers\Abit\VT7\SATA $OEM$\$1\Drivers\Abit\VT7\Audio Then my kid's computer: $OEM$\$1\Drivers\Asus\P4S800\Audio $OEM$\$1\Drivers\Asus\P4S800\Video So on and so on until I have all my drivers on the disk. My WinNT.sif just lists them all out. I boot any of my machines from this disk and I can fully install all the hardware without problems. The names of the folders don't matter, as you see you can call them anything you want just as long as it makes sense to you. I break mine down based on the hardware, you can do anything you want, even lump them all together into a single folder if you want. Windows won't care, all it wants to know is where to find the drivers. The folder structure and names are only there to make sense to us.

Personally, you're making all this far more complicated than it really needs. You should forget about all these driver packs and do it by hand. Just follow the tutorial http://unattended.msfn.org/unattended.xp/view/web/33/ and add in the drivers you need for your machines. You'll learn far more doing it that way than you are now. But, that's just my opinion.

Here is a simple solution to what you want to accomplish. Off the root of your CD, create a folder called "Type1" and another called "Type2". Download all the hotfixes. Sort them into either the Type 1 or Type 2 folders. Use a batch file to cycle through each folder, installing them with the needed silent switches, executed by the Autorun.inf Run QChain at the end of your batch file and you're done. That will get you a CD that will install all the patches when you drop it into a system. As new patches come in, you just drop them into the appropriate folder. You can expand it as needed, put in an automatic reboot, and if you're willing to do a little work you can have it check for each patch before it installs and skip it if the box already has it.

Just add all the drivers you need to your $OEM$ tree and your SIF file and you're good to go.

You want a second disk with just the updates? That's easy enough to do. Just download them and use autorun to execute a script that installs them all. So, you drop the CD into your newly built computer and it just starts cycling through all the patches. I've done it before. I created a CD that when you dropped it into a machine determined what OS it was running and then cycled through all the patches for that OS I had on the disk. Piece of cake.

I remember seeing somewhere that when doing a CD install, you can use the [RemoteInstall] section (I believe) to partition your drive to be a set size. Something like "Size=40000" to create a 40GB C drive. Then you can run a script that will use DiskPart to create the D drive and then relocate the swap file.

I don't believe editing MSGINA is going to get you what you need. All of these 3rd party authenticators replace the GINA file with a custom of thier own. You won't be able to get the same functionality with MSGINA because the code required to do that just isn't present in the file. It's not a simple hack of the MSGINA to get what you're looking for, it would be a complete recoding of the entire DLL. The GINA file being used to get that logoff dialog is a proprietary DLL written specifically to do what it does. Look at it this way, think of MSGINA as Notepad, while the one you're looking to mimic is Word. You're basically asking about how to link an Excel spreadsheet into a text file. You can't because a text file was never designed to handle embedded objects. The MSGINA was never designed to handle the things you're looking for, hence other vendors have stepped in with GINA files of thier own.

Maybe it's the FAT32? I've silently installed R2 without any problems before, so I know it works.

Can you alter your boot CD to create a partition larger than 2GB to start with? That's what it is ultimatly going to come down to, the 2GB just isn't large enough.

Unfortunatly, "who knows what evil lurks in the hearts of men..." and how exactly Windows decides it's drive letter assignments. It's a hassle and I don't know if it'll work with the card reader or not, but you can use diskpart with a script to assign all the drive letters the way you want them. Or, use a variable like %CDROM% in your runonce lines, but instead of determining the DVD's drive letter when you build the RunOnceEx, determine it when it executes. Your RunOnceEx lines will have "%CDROM%\Apps\....\setup.exe", but the very first thing, before any installs begin, have it run the script that selects the DVD's drive letter and assigns it to %CDROM%. This should work for you. So, even though the drive letters change, the %CDROM% variable isn't pupulated until first logon.

Add this to the very end of your install scripts: net use \\qtx-buildserver\datsoc /delete This will disconnect your connection to the share. When the system reboots it should not attempt to re-establish the connnection again.

Here you go, step by step instructions. http://unattended.msfn.org/unattended.xp/view/web/3/#manual If this doesn't work, or you're getting some kind of error message or messages then there's something else going on. There's no encryption or special security locking the files on the CD.

Use VMWare. VMWare has a built-in screen capture feature. That's what I used to document RIS, disk installs and other things like that.

You can't. I asked the folks over at coolmon.org a few years ago and they said that silent installation wasn't an option. Just extract the contents and copy the files over as part of your $OEM$ tree.

Well, the problem with an image based method is the difficulty in updating it. For example, you want to replace the OfficeXP with Office2003, you have to bring the image down, strip out OfficeXP and install Office2003. Then, upload the image all over again. Or, if you change hardware like a new video card. Again, you have to bring the image down, strip out let's say the ATI Catalyst software, load up the NVidia apps, then reimage the box. Also, you're image is tied to your machine. Granted you could sysprep your system before creating the image and you could install it on other machines. But if you need the flexability to install your setup on multiple machines, an image is more difficult to work with.

It's easy. Just comment out the "JOINDOMAIN" line in the SIF file and replace it with "JOINWORKGROUP=<workgroup name>" I forget the section name, but it's easy to find, usually about halfway down the SIF file you'll find it.

The problem is with the case, not the MicroATX motherboard. As you already know, PCI cards will work just fine in your booard. There are no PCI cards built specifically to fit the small cases used with some MicroATX boards. About all you can do is shop around for a small NIC that will fit in the case.

dijuremo, I'm sorry, you're exactly right. I really should pay more attention to what's going on I suppose. I just saw that the connection worked and didn't even pay attention to the rest. Once I reloaded the menu, everything worked perfectly. Thanks Mike