RogueSpear

It's going to take me a little while to look over all that code and put it what you're looking for, but FWIW there's some pretty kick a** stuff in that script. It'll certainly teach me a thing or two while trying to solve your problem.

Considering that I don't know what it is I'm reading, I "think" it worked for me without any errors. I'm going to see if maybe I can make a Camtasia movie so you can see for yourself. EDIT: Ok, here it is. You may need to download the TechSmith Screen Capture Codec from here to view this. Keep in mind I use Maxthon, but it is based on Internet Explorer so it should crash in the same fashion as IE if something goes wrong. I'm not crashing and there's no Java error log on the desktop as is customary with a JavaVM problem. Maybe this will tell you something. http://www.earlymorninghours.net/Stuff/Untitled.avi

I would give you a direct link to it, but as you know it's a secure server that requires a login and acknowledging about half a dozen disclaimers. Once, you get the file if you have any further questions about how to make the installer, just give me a shout.

For Windows, they almost always list two downloads for any given version. One obviously is InstallShield, and the other they usually subtitle as "Windows Installer".

What I did was download the .msi version of the installer and make a switchless silent installer out of it. Check out Keytotime's 7-Zip installer tutorial for how to make one. It's a pretty straightforward install.

Sweet! Many thanks

These are decompressed from 100_Cleanup.vbs as described here: It was pointed out to me that the way Microsoft registers the source location, you should point to the location containing the i386 directory instead of pointing to the i386 directory itself. This script will compress, using NTFS compression, certain directories in %SystemRoot% and %ProgramFiles%. The script will run depending on the size of your hard disk. You can set the size of the hard drive at which the script will be triggered in the .ini file.

This would probably be better placed in another thread, but as long we're on the topic.. Do you know how to tap into WMI or ADSI from AutoIt?

Option Explicit Dim ws, fs, strComputer, objWMIService, colSoftware, objSoftware Set ws = WScript.CreateObject("WScript.Shell") Set fs = CreateObject("Scripting.FileSystemObject") strComputer = "." Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colSoftware = objWMIService.ExecQuery("Select * from Win32_Product") For Each objSoftware in colSoftware If Left(objSoftware.Name, 12) = "Adobe Reader" Then WScript.Echo objSoftware.Name & " is installed." WScript.Echo "The installed version is: " & objSoftware.Version End If Next

You could always create a block rule in Windows Firewall (or most any other firewall product) to block the .exe file itself. If you're in an Active Directory environment, you may be able to use Group Policy to disable it. I know it works for Windows Messenger, so it may work for WLM as well. Microsoft seems to tie the two programs together for certain things and this may be one of them.

You could also set DefragRegistry=No

When adding support for non-native NICs in RIS, you need to have the driver in two different places. First the .inf file and the .sys file(s) must be placed in i386. Then the full driver set needs to be available elsewhere (depends on what method your using). What I have noticed is that very rarely do you ever have to modify anything at all for the latter stage - where Windows XP Setup performs a PnP enumeration. Some people refer to this as T-39. It's the first part, getting the computer to boot to RIS that seems to present the most confusion and problems. If you need to modify the .inf different for one group of computer from another group of computers, but they both will use the same .sys files, that's fine. Just put both .inf files, named differently, along with the necessary .sys driver files in the i386 directory. You don't need to concern yourself with breaking driver signing or anything for the first part. The only thing you need to do is jump start the thing into booting. Once that's done, the full driver set should be detected and installed during T-39.

If you change the directory names of the DriverPacks, I don't think the control panel applets will install for any video and sound devices that have them.

That's one of the nice things about it being open source. If there was anything nefarious in there, someone would have blown the whistle by now. I've found that software developers in the security sector have some of the keenest eyes for detail of any. I hate to put blind faith in anything, but realistically speaking, who has the time to sort through the code of everything? I do have a reliance on the skills and honesty of others, but I like to think that I place my reliance and faith wisely. BTW, if you needed any tips or pointers on Tor, Mrs. Peel knows quite a bit about it. She has an account here, but spends more time over at RyanVM's forums.

Version 1.01 - 04/09/2006 cmdlines.vbs - There was a typo involving the RunOnceEx registry entries for custom script entries at the 140 level. Fixed. 110_CopySource.vbs - The source path was being registered as %systemroot%\i386 instead of %systemroot%. To work properly the entry needs to read up to but not including the i386 folder. Also, there were two registry entries for the source path that I was not populating. Both problems fixed. Thank you to Moonlight Sonata for pointing out both errors and providing working fixes. Talk about service Each script will contain a change log at the very bottom, after all code. This will hopefully make for better tracking of changes. @nowinscenario, something you could consider doing is making a 7-Zip archive named 101_AllUsers.7z with your Start Menu shortcuts in there. The script 100_Cleanup.vbs will look for this file and if found, will decompress it to %ALLUSERSPROFILE%. I actually do this at one location where they have some proprietary applications that don't have any install routine, but for some reason they must be in the root of the system drive. The applications are actually in 000_SystemDrive.7z which gets decompressed from presetup.cmd, then later like I described above, the shortcuts get decompressed. As far as modifying cab addons goes.. I don't think you'll have a whole lot of luck modifying those unless you basically decompress them, perform your modifications, then make the installer all over again. Essentially it would be just as easy to make your own from scratch.

@Yurek3, I'll try my best here as I can't read the error messages in some of your screenshots. Screenshot 1 - Is that the first boot after GUI setup? Did you appropriately set your autologon info in the .ini file? Screenshot 2 - You appear to have the BTS finish batch file scheduled twice and have reordered the execution of some of my scripts. I can't guarantee what will happen if you reorder the scripts. Leaving out scripts is perfectly fine, as I designed all of this around being able to pick and choose. Also, it doesn't appear that there's an error message on the screen. Is there an error I should see? Screenshot 3 - Umm.. looks good. Screenshot 4 - It would appear that you have the option for an offline defrag turned on, but you don't have SysInternal's PageDefrag located within the system path. Screenshot 5 - Similar to screenshot 4. You have the option to perform a registry defrag turned on, but you don't have NTRegOpt located with the system path.

I really forsee some problems with that method. I'm not really expert enough on the procedure that setupcopyoeminf.exe goes through. The procedure that my script goes through definately works, as I have tested it extensively. Also it's very easy to update a computer to a newer set of drivers if you ever wanted to and very easy to select exactly which drivers you want to keep. Lastly, while it may take a little more hard drive space, it's a relatively simple method that has not failed me yet, the integration is extremely fast from a Method 1 source and acceptable from a Method 2 source. One of the problems I have with setupcopyoeminf.exe is recovering from it. It doesn't seem so easily reversed.

True indeed. Part of what I'm doing with my script pack is to keep the source open. The other problem with compiling an AutoIt script is allowing other people to use the script. I wouldn't want to expect people to have to compile a script everytime they make up a source. What I may do is devise a very very simple encryption scheme. Something that would merely thwart the casual observer. This way if someone stumbled upon your CD/DVD, they would have to figure out that there's some kind of encryption to begin with and then go through the hassle of cracking it. It would be analogous to locking your car door in that you're keeping honest people honest. To get much more involved would defeat the simplicity of the scripts and probably discourage people from encrypting anything.

That's actually something I'm working into my script now. Essentially you would put all of the information into an .ini file for up to five (5) different wireless networks. The script would loop through for every entry it finds. The one thing that's bothering me is the (in)security of having that information in a plain text file for all to see. I also started to make an hta application similar to my user name / computer name hta, but then it dawned on me how lame that is when you could just initiate the wizard itself and get something a bit more polished.

That'll rename it just fine, but you'll still need a reboot to have it take effect. I've been doing way too much research into this today. So far everything I run into indicates that a name change or a change in domain membership on a computer that already has the OS installed will require a reboot.

Excellent post I'm sure that I will need to reference this again not too far down the road.

Thanks to all for the comments. I was wondering if I was all alone here @MadBoy, I have done some work in AutoIt and I think it's fantastic. I really wish some of the functionality and ease of use would be adopted by Microsoft in WSH. I just don't think that it will allow me to go far enough with some of the ideas I have in my head. I finally broke down and started to take up VB.NET and C#. I thought just familiarize myself with the languages, I would take some of my current VBscripts and duplicate their functionality. I'm espcially looking forward to converting my HTA application and AutoRIS over.

I've never tried to prestage a computer account outside of the scope of RIS. I would imagine that it should work the same however. You would need to enter in the UUID of the computer, or in the absence of a UUID, create one using the MAC address padded with zeros. If you take a look at my script pack, I have an HTA application in there that among other things, names the computer. I had always intended it for use in workgroup environments, but I think I could modify it to join a domain of the user's choice.

I would agree with that. I certainly have more "trust" in open source software since it is open to the scrutiny of everybody. I've never been a fan of secrets.

I don't think you can join a domain and have it take effect until a reboot. Same would go for renaming a computer. As far as new installs go, I always prestage the account for RIS, and the domain join happens during the GUI portion of setup. For pre-existing installs, going from workgroup mode to joining a domain has always given me a prompt to reboot. I'd be interested in knowing how you join a domain without needing to reboot though. Manual or otherwise.