RogueSpear

Well I'm not certain what I am doing different, but today I made a CD-based install with 7-Zip installing from svcpack.inf and it works for me from both admin and restricted users. I may just remove the installer since this is a no-brainer to install silently anyway. EDIT: I just finished up another test and sure enough, it works for me. The only thing I can think of is that towards the end of my RunOnceEx sequence I export HKCU and overwrite the NTUSER.DAT file in the Default User profile.

I've always had good experiences with Linksys routers but in all honesty it probably makes no difference. If you were looking for a router with wireless capabilities, I'd suggest you do a bit of research to find what is most appropriate for your needs. Here's a couple of handy links in case you'd like to read some reviews or technical articles: http://www.practicallynetworked.com http://www.tomsnetworking.com

If you're using the ScriptPack, which it looks like since you're mentioning cmdlines.vbs, then you should follow the instructions for that. If you are not, and only want the functionality of the VMware Tools installation, then there are instructions right in the post where the download is. Furthermore, there are a few posts within this very thread of people having similar issues with responses on how and what to do. I will go on the assumption that you're using the ScriptPack based on the cmdlines.vbs file in your post. Well that file needs to be in your \$OEM$ directory if it's being called within cmdlines.txt. The cmdlines.vbs script will look for the script file named 070_VMwareTools.vbs in your \OEM directory. The 070_VMwareTools.vbs script will run in order to determine if your install is taking place on a VMware virtual computer. If it is, then VMware Tools will install. If it is not, as in your installing XP on a real physical computer, then the VMware Tools will not install. If you need any further information you should be able to find it in this thread or in the support forum for the ScriptPack.

The installer file and the VBscript which determines whether or not the install is taking place on a VM both need to be in the \OEM directory, not the \$OEM$ directory.

Personally, I leave the Display Drivers (old) and remove the new Display Drivers. I think most of the old ones are not supported by the DriverPacks, but almost all or maybe even all of the new ones are. I always remove ISDN, Sound, WLAN, and if it's going to be a disc based install I remove LAN as well. If you are preparing a RIS image, do not remove LAN since they are used for the PXE boot.

Those drivers were almost three years old so I really don't see why they wouldn't work. I have installed computers via RIS that have Intel NICs and are anywhere from 6 years old to bought last month. I'm a little bit at a loss and can only suggest at this point that you take a look for any out of the ordinary BIOS settings. If these clients still have a BIOS with the setting "PnP Operating System", I'd suggest setting it to "No" or "Disabled".

I'll shoot you a PM so you can mail me the drivers. It doesn't make sense that they wouldn't work during setup and then just fine manually. Though I have seen stranger things.

Well what I really meant was to just create a new directory and throw them in there. If you still have that computer "installed".. where it didn't pick up the device during GUI setup, why don't you try to log in and manually install the drivers from the Gigabyte CD to see if even that will work. Ultimately I'd like to confirm that you have a good piece of hardware and / or appropriate drivers from Gigabyte.

What you just said are the exact same thing, unless you mean that you want to create a local user with admin rights to that machine, but will have no rights at all on the domain.

I would then suggest decompressing DP LAN, add a directory and put in the NIC drivers that came on the Gigabyte CD. Recompress with 7-Zip and see if that works. If it does not, I'd try another machine or call your vendor. Seeing that the text mode portion of setup properly performs a PXE boot I wouldn't mess around with those drivers even if it turn out that a newer driver ends up working on the GUI side of things.

I'm not sure if you're using the DriverPacks or not, but Bashrat updated DP LAN like two days ago. Do you have other computers with the exact same motherboard working? If so I'm inclined to say it's defective hardware. Fencer128 documented such a failure a few months back with some Intel mobos, so it's not impossible.

The word that came to my mind was pussyage.

The 7-Zip installer has been working for me since day one.. couple hundred installs and counting. I'm not sure what the problem would be on your end. EDIT: I think I'm understanding the issue, but still it has never not worked for me, even with the set of circumstances you have. Perhaps install from svcpack during windows setup.

Well deploying .msi based software via group policy is a freebie since it's built right in. I've been using that method for about 6 years now and it works rather well. I also have a series of scripts assigned both to the computer and to the user based on OU. In the case of the machine scripts, a script unique to each OU performs it's duties and then calls a common script for those things every computer should perform at boot up. With good planning you can make a very efficient and reliable system this way.

As you're probably already aware, 2000 RIS servers need to be explicitly authorized in the DHCP snap-in (I believe 2003 does this for you). So you need to take into consideration DHCP. Where do these clients obtain their lease from? Are your remote sites part of the same forest? Same domain? At your earliest possible convenience prior to actually setting out to do this, take the time to visit a remote site and do a dry run. Bring along another computer with you if there aren't any appropriate sacrificial lambs at the remote site. A wise man once told me to always remember the seven P's - Proper Prior Planning Prevents p*** Poor Performance. It may sound like a joke, but there's a lot of truth to it. There are so many unforseen things that could go wrong. Better to find out what they are ahead of time.

All of this sort of begs the question as to why group policy, SMS, or something else isn't being utilized for deployment of .msi based installs.

I'm not entirely sure what the command line options are for Adobe Reader's exe file. But if you run it manually you can snag the resulting .msi file (and the accompanting data files). Then you would just use standard msiexec commands: msiexec /i adobereader.msi /qn If you don't mind taking the easy way out, you could always download one of several switchless silent installers for Adobe Reader. I maintain one as well as RyanVM and I'm sure a few others.

Well my wife doesn't mind things being automated so much, but my girlfriend is another story

If you're a systems admin you seriously owe it to yourself to get even just mildly aquainted with VBscript and Windows Script Host. It's really not all that difficult to pick up, there are tons and tons of free resources out there to learn from, and in the end it will make your life much easier. Once you have the basics down it can really become downright addictive having the ability to automate so many things. If you ever need some examples of VBscript that would be applicable to unattended installations, take a peek at my ScriptPack (link in the signature).

Video adapter drivers are very well known to throw up those IRQ less or equal BSODs.

Yea I just noticed that over the weekend myself. I was able to get the .exe file up, but had to wait til today to get my hands on the .msi file. Should all be squared away in the next couple of hours. EDIT: All of the AutoGK links should be operational now.

This is a good idea. I always change the default gateway to use something other than 1. I also disable DHCP and turn on the MAC filtering. Personally, I think if you take enough of the basic precautionary measures that you really don't need to turn on any heavy duty encryption. I've setup enough sites where there are some clients that have old enough wifi adapters that they won't support strong encryption anyway.

If your Internet connection is from a cable modem or dsl, even a 10Mb half duplex interface could easily saturate your connection. As far as networking bandwidth within your home (or business), a single gig interface should easily satisfy even the most demanding application. In fact I'd speculate that a lot of computers would have difficulty in making that connection a bottleneck of any sort.

Well it seems that rootworm would rather send me insulting PMs rather than make a public post. I just love that type. Defending the indefensible, then hiding in the shadows. He would have done quite well in 1940's Germany.

Going to need a lot more information to help you on this one. For instance.. what VPN client? And I'm assuming from your post this is a client to network VPN?