RogueSpear

I've used a similar method in the past but using vbscript. What I had been doing was using WMI to read BIOS information and based on what is enumerated, the script goes ahead and installs various drivers or helper apps specific to that model. To explain a little bit clearer: I have several Compaq/HP laptops, models A, B, C (just to be easy). Anyone familiar with these brand of laptops knows that some of the driver and helper apps (one-touch buttons for example) don't generally install silently using an integrated driver method. And I also have experienced a problem with the Synaptics Touchpad drivers installing on desktop computers when they shouldn't using an integrated driver approach. So I enumerate the BIOS and branch off from there. This sounds fairly similar.

In my experience I have found that easiest way to disable some sounds is to alter the HIVEDEF.INF file. They are defined right at the beginning of the file. As an example, to make the System Exit event have no defined sound find the two following lines: and remove the pointer to the sound file, but leave the quotes. So the lines will look like this: I also disable System Start and Navigating.

I'm not sure what the best thread for this is since it applies to all three driver packs and deals with Pyron's method for driver integration. So if someone feels this is an inappropriate place for this post, please feel free to move it. I've had some difficulties with Method 2 for the driver packs. My svcpack.inf and cmdlines.txt are not running at all. I've spent a large amount of time researching why this is, but still come up with nothing. The final straw is that at the end of the GUI portion of setup, my install hangs, requiring a push of the reset button. So from all of the posts I've seen around here I decided to try a hybrid of Methods 1 and 2 together. What I did was create a big WinRAR SFX of my drivers and use Pyron's method to extract it to my hard drive as per Method 2. Then instead of leaving presetup.cmd running, it simply hands over control to the real setup.exe and terminates. This requires you to fill in the WINNT.SIF file with all of the paths as required by Method 1. So far I think this is all working as expected but I'm going to test it out on a couple of different machines at work. The reason I wanted to try out this method is that I was not having luck with using the DetachedProgram entry in WINNT.SIF.

I found the easiest thing to do is to edit the msi file directly or make a corresponding mst file. This way all you have to do is use a /qn switch. If anything, this also lets you examine what components have been made mandatory by the publisher and then make them optional (direct msi edit method only). It also gives a pretty good idea as to which switches are available and their options.

@Nilfred When you setup an AIP for some reason the process does not copy over some files. Look for alerules.exe and INSTOPTS.DAT from the original source and copy them to the root of your AIP.

This is semi-topic related, but could almost use a thread of it's own. I was looking through the file layout.inf and noticed there are entries in there that refer to WMP9. And I was wondering, would it be beneficial to eliminate for instance wmp.inf from this listing and replace it with wmp10.inf? I also noticed that nLite does not seem to remove anything from this file. Heck, I'm not even 100% sure what the file is for. It looks like it's telling setup which subdirectories all the various files should be copied to, but I don't know if it does more than that. So, I'm really curious if our unattended installs would go any faster or be more reliable perhaps, if we were to groom the layout.inf file to more accurately reflect our modifications. EDIT: I forgot to mention that this guide worked out great for me the first time through. Very well put together and thank you for all the time it will save me!

http://www.symantec.com/techsupp/enterpris..._ts_online.html When you get to the page, there is a drop down list to chose which forum. When you go to a forum you will notice a search box towards the top. I found the page file issue by searching for "pagefile." Give 'em hell.. EDIT: http://servicenews.symantec.com/cgi-bin/di...client_security Here is the post I referenced earlier.

I find it odd that the 9.01 is still the latest download on Symantec's site. I'm really not sure of the origins of my copy to be honest. But with the amount of scratch I lay out for a Gold Support Contract, which as far as I can tell is only useful for free upgrades, I don't feel very guilty about having it. If I can locate the source I'll definately post it here. I simply have not had the time to test this, but I plan on it within 24 hours. By the way, I would not count on this problem being fixed. I was browsing through Symantec's message boards where someone (you?) asked about this very problem with all builds of version 9 and the tech support wrote back that this problem was first surfaced with the version 8 series but was resolved with version 9 and that the guy should upgrade. It seems that their reading comprehension sucks since this guy clearly stated he was using version 9. And the other thing that bothers me to no end is that as far as I am concerned this is HUGE freakin bug that demonstrates some pretty Mickey Mouse software development. Now depending on how large your enterprise is, you could be spending from $1,000 to $50,000 easy to upgrade to V9. I am QUICKLY losing faith in Symantec (are you people reading this?!?).

Name your policy file CPOLICY.XML and place it in the root of your installation source. Put your GRC.DAT file in the same location to restore AV settings on install. That's all there is to it.

I didn't see any mention here that to even use this thing, you need to have UPnP running along with File and Printer Sharing for Microsoft Networks. I home environments, which I think would be the main target for this application, I always shut off File and Printer Sharing by default. And I NEVER EVER have UPnP / SSDP enabled. So this POS isn't going to be making it into my unattended installations any time soon.

@Famer that's why I said it was the "best" way. I don't think that there is anything technically wrong with using an SP1 source, but after integrating SP2 you will have about an extra 15MB or so of junk laying around. I am pretty luck in that I convinced my main employer to go to XP as soon as it came out (I really wanted the Remote Desktop feature). I'm not a lawyer and I have not tried to decipher all of Microsoft's various EULAs, BUT it would seem to me that if you are fully licensed to be running XP in the first place, there shouldn't be a problem obtaining a copy of the Gold version. Just so long as you can use your own key code and properly activate each workstation. Just a side comment. I'm actually in the unusual situation of having about 10 extra seats on my select license through workstation attrition. And nobody wants to sell me any computers without an XP Pro license or if they do, they charge the same amount anyway.

For anyone out there using Desktop Sidebar, this visual style goes great with the Royal Black Knight Compact skin for DS. Makes for one classy looking desktop.

I posted some registry tweaks in the sticky Registry Tweaks Pt.2 for Perfect Disk. Presets some of the options and enters your license for you.

The easiest way to disable during an unattended install is via the WINNT.SIF file. If you'd like to disable it on all interfaces, I wrote a VBscript to do that which you can find here. Look towards the bottom of the thread.

Regarding the use of nLite with Ryan's pack.. I think that is paramount that people understand that his update pack should go first in the list of hotfixes and that you should only use nLite w/ his pack on a virgin i386 source. IMHO the best way is to take an XP source with no SP at all, integrate SP2 yourself, then use nLite. Also, I never re-nLite something that's already been through the process once before.

At this point I would have to think that MS did a pretty good job of nuking the code for concurrent sessions from termsrv or someone would have hacked the most recent version by now. And on the same topic. I cannot seem to get this hack to work. I'm starting to feel like a real chucklehead on this one. I've tried every which way but Tuesday to do it too. Used the reg entry, tried modifying the hive file so its integrated in the registry during setup. Nothing. Now I remember reading in other threads that FastUserSwitching service needed to be running and that the hack won't work in a domain environment. Have these claims been substantiated? This hack would completely change my life in the some of the enterprises I deal with.

You don't need to add a user from a domain at all. If what you're looking for is to autologon a domain user (ex: to run RunOnceEx), then just add the default domain in the registry where all the other autologon entries are. And this does work with VMware. I do it regularly. Just make sure that your unattended (in my case at work RIS) joins the domain (per WINNT.SIF) and that you have VMware configured for bridged networking.

In addition to renaming Administrator/Guest and disabling the Administrator account (SID 500), I also strip away the descriptions for them and nuke the ASPNET user that .NET creates.

Well today I finally found the time to do something I've been meaning do for a while (still got like 999 things like that to go). I finally decompressed the latest version of the full pack, decompressed various files inside of it, and took a gander. The experience leads me to say a couple of things: 1. If you want to get some of the "how and why" regarding Ryan's pack, by all means take a peek inside. I always knew this thing must have been a bit of work putting together, but after checking it all out, I have a newfound respect for the amount of research, time, debugging, and trial/error that really went into this. 2. You have probably been around for a while and think that you have thought of everything there is in the world. Wrong! Even those with 20 years in IT have a thing or two to learn. You never know when you'll stumble upon something and the little light bulb appears over your head. So I say this: If you are using this pack regularly and you have not done so yet: 1.) Read this entire thread 2.) Read Ryan's upgrade pack web site 3.) Decompress the pack and inspect it's contents. I am convinced that there would be a crapload less of the redundant questions and sloppy mistakes and we could actually have some intelligent discussion regarding the topic. My apologies in advance if this sounds a little too high and mighty for some, but nothing drives me crazy more than people who refuse to read instructions or do their own homework in the hopes of a quick answer from someone else.

Boilerplate Disclaimer: Yes I searched but didn't find anything about this exactly. Is is possible / beneficial to put drivers in the drivers.cab file? Especially if some sort of script procedure could be made to the different infs and sifs. My unattended project has been growing so complex lately that when something doesn't work I often just resort to using nLite on a virgin install source and plop all my files back in again. It's getting to be a little much, all of the hacks, mods, and scripts we engross ourselves with for the sake of making the "perfect" unattended source. Sorry for the rant.

Slightly off topic question here. Does anyone know what Microsoft's rationele was for not including the latest RDC in XP SP2 (or XML for that matter)? Obviously XP SP2 is much newer than 2K3 Server. It just seems a little odd. Which leads me to wonder what has changed with the newer client.

Try changing FileSystem to FileSystem=LeaveAlone

Actually I got it from a co-worker who also has several licensed clients for this product. I was browsing through the documentation and it does appear legit. I asked about a corresponding version 2.02 for SCS but no luck there.

There are quite a few resources for this problem, and a pretty decent knowledge base article over at MS too. Essentially what you need to do is go to Intel's site and download the latest and greatest drivers from them. You should also notice a download available that is described something like ".INF file for RIS". Or something to that effect. Download that too. Decompress your drivers to a temp directory. You can combine the driver files for the 100 and the 1000 based NICs into one directory, overwriting any duplicates. Now copy all of those files to your i386 directory (of your RIS image). Then copy over the .inf file I talked about above to the i386 directory. Next, set up your .SIF file for the RIS image to look for OEM PnP drivers and copy the driver files there too (this whole process has been documented here and elsewhere adinfinitum). DO NOT copy the special RIS .inf file to this directory however. Also in your $OEM$ make a directory called $$, then inside $$ make a directory called inf. Copy the driver .inf files there. Again, do not copy the special RIS .inf file here. Finally, stop and then start again the BINL service. Now the first time you try to RIS one of your clients it may fail, so if it does, try again. When you do RIS a client, your RIS server will create the necessary .PNF files in the i386 directory in your RIS image. Notes: The special RIS .inf file is simply meant to get the NIC up and going for the installation. The regular .inf files that come with the drivers will actually install the NIC properly during the PnP enumeration part of setup.

It appears that SAV 9.02 is out. More testing..