RogueSpear

I'm not sure how you could expect one iota of help with the complete lack of useful information that you provided.

What I generally do is wait for the text mode setup to complete before firing off another install. It only takes a couple of minutes at the most anyway. As for scripts, I've been putting together post setup scripts for a years now. If you hit the link in my signature, you can check them out.

If you want to use RyanVM's Update Pack on your RIS image, my AutoImage utility will properly do that. You can even integrate it using either the RVM Integrator or nLite.

Now I'm noticing that. I'm doubtful that they would discontinue the program and I haven't seen anything in the news about some kind of court injunction. Perhaps it only gets installed if the WGA validation check fails?

Just for the record, I'm using 2W to go 2 miles. Also I was not the person who installed the hardware, a communications specialist who didn't mind climbing up a 200 foot Sprint tower did that A lot of it really just has to do with properly focusing and aiming the signal.

I have a building to building connection over 802.11b that goes a distance of over two miles using a couple of yagi antennae. The connection speed is a solid 2mb, but drops down a bit during heavy snow. Going 1500 feet, even with some foilage obstruction shouldn't be a problem.

The problem has nothing to do with nLite. The problem is that you're running the script from svcpack or cmdlines and I specifically state that it should be run from RunOnceEx. The script relies on WMI which is unavailable from svcpack or cmdlines without the use of hacks.

This is a perfect example of why I hate advertised shortcuts The idea behind them is fine, but some software publishers power and control issues. They wan't their shortcuts on your Start Menu only as they define them.

Well I'm not about to argue with "if it ain't broke don't fix it" It was just that when I read the entire thread from start to finish, I never saw mention as whether or not anybody had tried it. Something that came to mind was that since DetachedProgram is defined within WINNT.SIF, I thought that perhaps it would have the potential to make things easier on those that use multiboot discs. I don't use multiboot discs myself, but it's to my understanding that you would have a seperate WINNT.SIF for each of the various installs on that disc.

While I have updated my installer for DT, it's no longer in the old thread here. Click the link in my signature and you'll find all of my installers over at my forums.

Just wondering if there would be an advantage to running this from DetachedProgram rather than svcpack or cmdlines. With some things in Windows setup, the earlier the better.

If your biggest concern is actually the security of your servers, you can configure IPsec in group policy. But as far as actual DHCP security goes, nitroshift's suggestion is the best I would come up with as well. In fact I've done just that in very small environments. Everything gets a DHCP reservation and the reservations make up the entire pool. This way you can at least push down network config changes (DNS server assignments for example) if need be. DHCP by nature uses broadcasts, so if you wanted to completely eliminate any communication with unauthorized hosts you would need to configure the DHCP server to only accept packets from a white list of MAC addresses. But that's starting to get into the realm of micromanaging.

Yes .NET 2.0 is rather large for a "runtime" and it does take a considerable amount of time to install, but the whole idea here is to have an "unattended" install isn't it? Anyway if you think 2.0 is bad, just wait for .NET 3.0.

I would try it on a VM first if I was you.. because like I said, svcpack is where it should be installed from. This error message is generated when you attempt to use a .NET 2.0 installer that is specifically made for svcpack after svcpack. You need to use it from within svcpack only. If you'd like a .NET 2.0 installer that will run from RunOnceEx, then you need an installer that simply makes the msiexec call and nothing else.

Any of my installers that have .NET 2.0 in them are svcpack only. I don't believe any of the RunOnceEx installers are still lurking about.

In this type of environment, that is a workgroup environment, when you attempt to use the shared resources of another computer, either a file share or shared printer, you must supply the credentials of a user on the other computer. Also, make sure that the share permissions and if applicable, the NTFS permissions, allow that user access to the resource from a remote computer. One other gotcha to look out for is that the credentials you connect with must have a password. I don't know if this a security feature that Microsoft intentionally put in the OS to prevent unsafe resource sharing or not, but you must have some kind of password even if it's only a single character.

This error message is generated when you attempt to use a .NET 2.0 installer that is specifically made for svcpack after svcpack. You need to use it from within svcpack only. If you'd like a .NET 2.0 installer that will run from RunOnceEx, then you need an installer that simply makes the msiexec call and nothing else.

I just disabled it from downloading today.

If you are able to enumerate HKLM\SYSTEM\Setup\SystemSetupInProgress then perhaps you could prevent a reboot even if it is configured as such in the .ini file. During the GUI portion of setup, that reg key should be set to 1.

AutoRIS is discontinued and replaced by AutoImage. I removed the download for AutoRIS because I was receiving far too many requests for support even though it is clearly stated the AutoRIS will NOT work with the current generation of DriverPacks. Further, during the development of AutoImage I discovered issues in AutoRIS that will prevent it from working at all with Windows Server 2003 RIS servers. To prevent people from possibly harming their systems and to cut back on requests for support, I decided to remove the download entirely.

In reference to %SystemRoot%\Installer, I always apply NTFS compression to it (and some other directories as well) with a script during RunOnceEx. I know you stated that you keep the partition as FAT32 so NTFS compression doesn't apply. But I just thought I would throw it in there.

Everything has been removed. See post #1.

I had a computer boot into safe mode unintentionally and it still ran my RunOnceEx scripts (which failed due to the unavailability of WMI). I wonder why it would work for some and not others? Also, just in case it would be of use to anybody here, I've used a freeware utility for booting into safe mode that works pretty nice: BootSafe

I'd be curious to know if there are any helpful event log entries on both the laptop and your DC(s).

He's always a douchebag.. and in this case he's also about three months behind on the information.