RogueSpear

And there you have it. Three valid ways to do the same thing I'm sure there's more too and that you'll find something that suits your tastes.

I realize I'm preaching to the choir here, so don't be offended by this question, but have all of you nForce mobo users been doing updates to the BIOS? I'm just curious if nVidia has been making an effort to solve some of these problems via firmware updates.

You may want to check out this link before you get too far involved in a project making a driver: http://msdn.microsoft.com/library/default....eviceDriver.asp

Networking is not available during device enumeration (T-39). What I do is use Bashrat the Sneaky's Method 2 with RIS. I detail it in my RIS guide.

Here's a small script that I wrote that does just what you're looking for. The only difference is that it copies i386 to the %SystemRoot% directory instead of %SystemDrive%. Also, it makes the appropriate registry entries so that the workstation will look to that directory for the i386 source. Dim ws, fs, windir, colDrives, objDrive, strCD Set ws = WScript.CreateObject("WScript.Shell") Set fs = CreateObject("Scripting.FileSystemObject") windir = ws.ExpandEnvironmentStrings ("%SYSTEMROOT%") Set colDrives = fs.Drives For Each objDrive in colDrives If fs.FileExists(objDrive.DriveLetter & ":\WIN51") Then strCD = objDrive.DriveLetter & ":" Next Sub CopySource Dim strKeyPath strKeyPath = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\" fs.CopyFolder (strCD & "\i386"), (windir & "\i386"),True If fs.FolderExists(windir & "\i386\svcpack") Then fs.DeleteFolder(windir & "\i386\svcpack"),True ws.RegWrite strKeyPath & "SourcePath", "%systemroot%\\i386\\", "REG_SZ" ws.RegWrite strKeyPath & "ServicePackSourcePath", "%systemroot%\\i386\\", "REG_SZ" End Sub CopySource CopySource.7z

I really can't give any authoritative answers regarding ICS. I've used it so little and it was quite some time ago.

No you can't forward the same port to more than one computer. At least not with a consumer grade router. You would have to change port numbers for each.

RunOnceEx runs after Windows has finished installing and rebooted, so it sounds like something went wrong way before then. You may want to try a search for "RunOnceEx" in the Unattended forum (this one). Use the search box at the bottom of the thread listing as opposed to the Google search box at the top.

I hate to say it, but if you want to be able to put together an unattended CD/DVD with the programs you want in there, you'll need to learn a thing or two. I don't mean to sound flip about it, but that's why there's all these forums here with thousands of threads and posts. If it was all cut and dry someone could just make a nice and neat guide that covered everything in one place and you wouldn't need the forums. First there's the method of integration. You mentioned RunOnceEx in your post. That's one of the methods and even at that there's a few options of how you get them there. There's also cmdlines.txt and svcpack.inf. I know, it's an awful lot of stuff to digest in the beginning, and honestly.. after a few years I'm still learning new stuff everyday. For starters, you should check out the excellent Unattended Guide here at MSFN. There's a lot of good stuff there. But you'll still have to go beyond that and just poke around and read a little.

Are serious? That actually beats out all of the brainless stupid ham fisted things I've ever seen RealTek do. Is it programmable? I mean what the hell good is it? I'm growing less and less confident with nVidia as the months go by. First we BSODs because some their own drivers conflict with each other, their mass storage is all but impossible support in a hands off fashion, and now this. They're getting perilously close to making my blacklist of "never purchase from" vendors.

It's been a while now since I've had to patch Office 2003 with SP2, but I seem to remember that SHORTFILENAMES=True is not necessary. In fact I don't think it was with SP1 either. I think that was only for Office XP and 2000. If you look inside of the Files directory in your AIP, you'll notice the subdirectory "Program Files" instead of the old Office XP "PFILES". And here's a tip for you. Put your .msp file inside of the directory where your AIP is and run your msiexec from there. That way you don't have to worry about typing out all those paths

Click on the link in my sig for AutoRIS and then download it (it's under 1MB). Whether you use the program or not, you will find Broadcom drivers with a modified .inf file that works with RIS. I modified the .inf file myself and tested it as working. I was presented (not my purchase decision) with a bunch of laptops with Broadcom NICs built in, so I sort of had to get it working.

Perhaps it will force some of these sloppy companies to get their act together. Then again look what happens everytime we try to make politicians honest here in the states.

lol, then on the other side of the driver hell spectrum is Analog Devices. They think a HWID is like a MAC address

This is actually pretty much what I do with RealTek NIC drivers with RIS. I use the new drivers for the bootup and then let the NIC detect as a Corega for the PnP enumeration. NIC and mass storage drivers are pretty similar in that sense. You need the .inf and .sys files in i386 for the text mode portion, then the entire driver set for the PnP part. Little footnote: I just discovered today actually that the new RealTek drivers in the latest DP LAN may actually be functioning properly in Windows. I'm not saying for sure until tommorow though, but it looks like someone at RealTek may have poked a hole in their bellybutton and is seeing the rest of the world now. As far as any kind of major scripting at T-39 (or even prior), I don't know if that's going to be feasable or not. I can't even get cscript to run at that point and I know that WMI isn't available even at T-12. If the proper batch could be made it may need the assistance of a command line utility capable of reading firmware information from the BIOS and/or the mass storage controller. Hey! Post 1,000

As far as Remote Desktop goes, yes port forwarding through a router will work. As far as through Internet Connection Sharing, that's a toughy. While not exactly the solution you're looking for, I think you can initiate Remote Assistance through Internet Connection Sharing via Windows Messenger so long as UPnP is enabled.

@cluberti, First of all excellent find second, I've noticed that they're calling up 4D36E972-E325-11CE-BFC1-08002BE10318 in the script that you linked to. I don't know if you've seen the VBscript that I posted for enabling the tray status icon, but I think I could rather easily adapt the info provided to my script and accomplish both tasks at once. I always adjust my NICs to 100/Full. For some reason I actually must do it in order for a custom Oracle application to properly maintain it's connection with a database over a dedicated T1 connection. I imagine losing all of the autosense garbage must help out somehow.

If only it were that easy. I had a heck of a time getting a DVD to boot once it got over like 3GB in size (I don't remember the exact size). It would boot just fine when it was say 2.2GB, but once I got over 3GB it was no go. I ended up turning off an option in UltraISO that said something like "Add Joliet Volume as Needed". That did the trick, but I really don't have a complete understanding of this since the UltraISO help is less than verbose. Perhaps CDIMAGE is doing something automatically that UltraISO is not, I don't know, but I can tell you first hand that not all .iso images are the same.

Wow, those are excellent articles. I'm going to get a ton of use out of those

I've been using UltraISO for my .iso file work and Nero to burn the DVD. I've been making bootable dual layer DVD's now for a little while and they work out great. I will say that the CD/DVD file system stuff, like Joliet and all of it's options are a pain in the rear. Has anyone ever found a definitive resource on all of this stuff? I can only find bits and pieces from differing web sites and it would be great to find all of the info in one spot.

First of all I have to tell you that performing an unattended install from a network installation point has always been the hardest type for me to get working properly. If it's possible for you to try getting the hang of things either using CD-RW media or even better, using VMware Workstation and an .ISO file, I would suggest that. There is indeed a lot to learn, but really most of it is not too terribly difficult to pick up. It's mostly a lot of reading and a lot trial and error. I guess the point I'm trying to make is that if you can get down some of the essentials and build up your confidence in this topic area, then you could later try to tackle the network method. Most of the fundamentals carry over, but there are some differences. Now, if you're in a networked environment and need to install XP to some workstations, I would suggest doing one of two things. If you're running an Active Directory domain, consider using RIS. I've found it to be so much easier than network installation points. If you only have say a dozen workstations in a workgroup, then consider using CD/DVD for your installs. If there's more than what will fit on a CD, perhaps you could either use DVDs or you could script drive mappings during RunOnceEx and go from there. Also, definately take a look at the Unattended Install Guide here at MSFN. It has changed an awful lot since I first found it a couple of years ago, but there is really a lot of great information in there. You'll certainly learn a ton if you go through it. You made no mention of the contents of your WINNT.SIF file, but there are some essentials entries that need to be in place there in order for your additional drivers to take hold and install.

Indeed, cmdlines.txt should be placed inside of the $OEM$ subdirectory. If you plan on calling any executable files or importing any .reg files, they too should be placed inside of the $OEM$ subdirectory alongside cmdlines.txt. So for instance, if you wanted to import registry entries from a file called registry.reg, you would have both cmdlines.txt and registry.reg inside of $OEM$. You would then need to make sure your cmdlines.txt reads follows: [Commands] "regedit /s registry.reg" Note that the quotations are required for each line under [Commands].

I need to download them and reconcile them to what I have now. I should be able to get them up and ready within a week. This week is pretty jam packed for me.

I like this little utility, though you will need to read a little bit and experiment to get the blocking just how you want it. This essentially works just like host file blocking with the following differences: - It works as a proxy, so it will only affect those applications that use IE's connection settings. Host file blocking will block all TCP/IP communications that use DNS. - It uses wildcards instead of a flat list. This is why it's so much faster, uses less resources, and will block some things that may not make it on to a static list. With that said, it still wouldn't hurt to use something like Google Toolbar, MSN Toolbar, etc for additional pop up blocking. If you are using something like Norton Internet Security, McAffee, etc. Some kind of retail software firewall package, it should have some pretty ad and popup blocking all it's own and you probably would not need something like eDexter.

This reg file was never intended to be a popup or adblocking mechanism to begin with. It's meant to add domains to Internet Explorer's restricted sites zone. What this does is prevent execution of ActiveX, Java, unsafe scripts, etc from those listed domains. And there are so many better ways to block ads and popups than using a host file to do it.