RogueSpear

Ok, I had a rather bizarre install experience yesterday. Was performing a CD based install on an older Dell Latitude (don't remember the model) that contains what is labeled a "Mobile Radeon." Well similarly to what was described earlier in this thread, the control panel app started prior to the device install and then it claimed it couldn't find a particular .dll file. I just poked around the other ATI directories until I found a file with the same name and pointed the device install there. Well the device install finished and then the screen went all funny on me. It almost looked like a poorly designed Winamp visual. I decided to just go eat dinner and see if somehow it would correct itself. It did! My RunOnceEx scripts ran their course, the laptop rebooted, started the second string of scripts and was held up by a dialog box that the video card had installed (again). All I needed to do was click on finish. In the end the video adapter works with the drivers, the control panel stuff is all there, but it was strange trip getting there. Makes you wonder though why these hardware companies seemingly go out of their way to make things as difficult as possible.

If there's a BIOS option for "PnP OS", set it to disabled. This is particularly a problem with slightly older computers.

No problems with the file here..

I can confirm this one. Was identical for me.

@dgould393, if you email me the drivers (with your modified .inf file) I'll put them in the next version along with the Marvel drivers that krismark posted. Now I should put in a disclaimer here that I can personally vouch for only the Intel and RealTek drivers since I don't have access to other workstations in a RIS environment. I'll PM you my email addy so you can fire those off. Oh and congrats on your success!

@BTS, are you doing anything with svcpack.inf ? After integrating RVM, nLite, then the Driver Packs, I end up with both svcpack.inf and svcpack.in_. They both appear to be identical in content however.

Going on a guess here.. you want to take two domain user accounts that are simply "users" in the domain and add them to either the Administrators or Power Users group on the local machine. If this is the case you could easily modify the user accounts script I have in my guide to do just that. If you're not too familiar with VBscript and need a hand, just let me know.

@BTS, maybe you should make a Driver Pack NVRAID Personally, after seeing these issues regarding that product, I wouldn't touch it if it were the last RAID product on the market.

Well I'm going to end my participation in this pointless debate on this note: like maxamoto, I too have personally seen the huge difference between systems built around AMD and Intel CPUs, both laptop and desktop. The differences are obvious and clear and you don't have to be Nostradamus to predict that an AMD system will crash and crap out regularly while the Intel system will do what it was designed to do. If you have nothing better to do with your life than play video games all day, then by all means go with an AMD system. If you actually some work to accomplish you'd be well advised to pony up a couple extra bucks for a real computer.

I swear some people have a major reading comprehension problem around here. Look past the end of your nose. Here is a quote from an article I linked to earlier in this thread, it's from Tom's Hardware Gudie:

Integrating the BTS Driver Packs at this point is big pain. Basically you need to let AutoRIS just sit there when the dialog box appears telling you to perform the BTS integration, and then go do it. And yes, you should follow the directions in the RIS guide - to a point. Don't go too far in the guide or you'll overshoot what AutoRIS will attempt to do after you click on OK. You really only need to do a full slipstream of BTS if you want/require integration of the mass storage drivers. In all of my RIS environments, this isn't necessary (yet). If you do need this, then you'll need to run the RUN_ME.BAT file in stage three of BTS integration. Either way, you need to move files around as I describe in the guide in order to successfully execute a Method 2 during setup. I know that this is rather confusing if you're not too familiar with what BTS is doing, but once you see what's going on, it's really all very logical. I am hoping for a much more simplified routine once BTS releases his next gen integrator. Until then we'll have to make due with a slightly clumsy procedure since the driver pack integration never really took RIS into consideration. I've been increadibly preoccupied with some other issues lately, but I'm hoping to put out a new rev of AutoRIS in the next week. I'm going to include some Intel & RealTek drivers in the release to automatically integrate. So here's callout to anyone with extra NIC drivers that you have verified as working with RIS. I know the Intel & RealTek that I have work and I'd like to keep the included drivers in the class of "verified as working."

I'm really not familiar with how nLite creates a .SIF file, so I can't really help you out there, but if you check out my RIS guide in this forum I provided a sample .SIF that you could modify to suit your needs. Also with RIS installations you need to place your .SIF file in \i386\Templates.

It was so early in this thread that I think some have forgotten or never even read what I wrote early on. But it was along sort of related to what you wrote above. I would love build a system with dual CPUs (dual core CPUs I mean). I believe AMD offers the only solution to this right now, and probably at a fair price besides. Indeed, I love this capability, but I'm still in the Intel camp for the most part. Especially since most of what I work with is in the enterprise, not at home.

Yea, obviously..

Well this thing was a bugger, but after three tries I got it. You'll have to reboot after install, but it works. If you install from T-12 you don't even have to worry about the reboot. WinPcap MSI Installer WinPcap Switchless Silent Installer I tested this with the latest Ethereal that just came out today and it works like a charm. Let me know how it works for you.

SiS - I recently took delivery of computers that were speced out to have Intel mobos. Don't you know it, they show up with SiS. So I figure, Ok I'll give it a shot.. can't even boot to a network for a RIS install even though the motherboard box boasts "PXE 2.0 Compliant!" Well that was the end of that. If I can't use RIS it goes back. Better yet, if it clearly doesn't support what it advertises, it goes back. ALi - The absolute worst laptops I have ever had the mispleasure of supporting. Compaq laptops with an ALi chipset and AMD processor. Claiming to be expandable to a whopping 512MB of RAM I convinced my customer to do this. I then went through two months of finding a bug for Compaq. When you go above 384MB of RAM the system routinely crashes. Compaq finally admitted to this flaw, but didn't see fit to do anything other than advise not upgrading the RAM. These laptops then spent the next year shutting down on a regular basis due to overheating. They all eventually went to auction. ALi again - Another round of laptops. This time Intel CPUs, but ALi chipset. The most god awful, slowest hard drive subsystem and memory subsystem I've ever seen. Like putting a two stroke engine in Semi Truck. nVidia - While I don't have any personal experience with an nVidia equipped mobo, MSFN itself it bursting with anecdotal stories of the horror that their ATA/RAID chipsets inflict on their owners. Perhaps they've improved with the latest revisions, but I'm not about to give them a shot until I see some glowing reviews. And yes, research is definately important. I always do my homework and that's what has led me to using Intel solutions for the last several years. But I hold no allegence to Intel. If someone comes up with something better I'm more than willing to purchase that solution, even if it costs more.

@mjc, you should use this program and post the resulting file so that BTS can add the HWID to the Sound Driver Pack. Without the hardware ID present, an Analog Devices SoundMAX will indeed BSOD during PnP enumeration. The only way to eliminate these is if people keep on reporting their hardware IDs.

I think in the end someone needs to make a chipset for AMD CPUs that has the stability, reliability, and ease of driver installation as an Intel mobo has. Intel is almost always the last to release a chipset supporting some new whiz bang feature, whether it's a new memory spec or hard drive subsystem, but when they do release it, it is almost always rock solid from the start. Just take a look at the crap that Via, ALi, SiS, and nVidia have put out over the years. Absolute nightmares.

I'm surprised to see a statement like that. That's the same sort of attitude that would explain why anybody would ever buy a car made by General Motors. Reliability comes in many flavors and what I'm most conerned about is not a computer that's "dead", rather one that crashes continually because the device drivers for the controlling chipset suck a**. When I have someone applying filters in Adobe Photoshop to a 120MB image from a homicide scene, I'd much rather the guy in the photo lab wait an extra 15 minutes for the filter to apply rather than see the spectacular crash about an hour and 45 minutes into it. Yes, I've seen this happen. While this fellow is an unbeatable all star in the field of crime scene analysis, he is also an absolute neophyte with computers. But he "heard" that AMDs were so much faster. How much faster I don't really know since he had to reboot several times a day. If your main concern is video games, then yes AMD would be the way to go. If you're involved with mission critical applications, I don't think too many would argue with me that Intel is the way to go.

@cluberti, you've been a member here for over four years and this was your first post? Well from that first post it seems like you could really offer a lot around here. I'm hoping to test out your solution sometime in the next couple of weeks. Excellent suggestion. Oh and another thing.. keep 'em coming

Speed is fine, but in my book reliability is still King of the hill. I've never seen reliability with an AMD system that satisfied me. As I had stated earlier in this thread, that may be more the fault of the supporting chipset than anything AMD has done. Check out these two articles from Tom's Hardware Guide: http://www.tomshardware.com/cpu/20051010/index.html http://www.tomshardware.com/cpu/20051017/index.html If you buy into half of what is said in these articles, then Intel would seem like a pretty good bet about a year from now. I honestly feel that Intel is the superior company when it comes to engineering, and they certainly have more financial clout to pour into newer and more modern fabrication processes. With that being said, we wouldn't have all of the exponential breakthroughs in CPU performance of the last five years if either Intel or AMD didn't exist. This is a true testament to the benefits of competition. Imagine if there was a real desktop OS competitor to Windows...

I assign software to GPOs at the OU level. I've got some GPOs that deploy over 30 different pieces of software to any computer within. It works out nice. Ok, where you said that you regenerated a .pnf file for the svcpack.inf, that's where your real problems are. What actually happens is pretty hard to explain, but it invalidates all compressed .pnf files when you reboot the BINL service. Not the most intelligent design I know. If you simply decompress the svcpack.in_, delete the compressed .pnf file, modify svcpack.inf and leave it uncompressed, things may work. It's hard to say for certain though. Best to be safe and just follow strict guidelines or start from fresh with a new image.

Actually do a search for Driver Pack Broadband for the Moto SurfBoard.

It's to my understanding that Bart's Network Boot disk will simply provide a DOS environment with network connectivity. I don't believe you could do what's necessary to jump start a RIS install with that boot disk. I think PXE is required. Another thing is that PXE support is required in the computer BIOS in order to do a diskless PXE boot. For your older computers, this is almost certainly impossible. I still have a ton of P2 and P3 class workstations with 3Com 3C905B/C NICs in them and they work great a RBFG generated floppy disk. The only thing you have to remember is to disable the option "PnP OS" in the BIOS, which has no effect at all on the PnP enumeration of your hardware during setup. You shoujld be able to find those NICs for around $20 (US) a piece these days.

With RIS I always install everything possible with Group Policy instead of switchless silent installers. This way you can uninstall things enterprise wide with a couple of mouse clicks. Now regarding your svcpack.inf file. If you run through AutoRIS completely and then decide that you're going to change your svcpack.inf file it can get sticky. Part of what AutoRIS does is optimize your RIS image by compressing all .inf and .pnf files. But this comes with a price. If you screw around with any of the compressed .inf files and then decompress them, it will invalidate the corresponding .pnf file (or the corresponding compressed version of it which is a .pn_). Check out my RIS Guide V2 for a complete explanation of this. A not so elegant, but workable solution to what you want to do is this: After the RVM Integrator has completed, do not click on OK. Instead go into the i386 directory in RISTEMP, uncab svcpack.in_, make your modifications, recab it back again. Now click on OK to continue. This way when AutoRIS does all of the regenerating of .pnf files, the svcpack.pnf will correctly correspond to your svcpack.inf. An alternate solution would be to premodify svcpack.inf prior to running AutoRIS. The above paragraph came out of my brain still thinking that RVM overwrites your svcpack.inf file, but it no longer does this.