RogueSpear

DenyBud doesn't crash the system, it actually removed you from someone else's list. But I don't know if it works with the new version 7 or not.

Ok, the script looks for all four tag files on an XP SP2 CD which are "WIN51", "WIN51IP", "WIN51IP.SP1", and "WIN51IP.SP2". Are all of these files on your CD? I can say that I've never had this problem before and I certainly had a few in the development of Virgin 1.0. EDIT: Looks like I was posting as you were editing. And from your edit it appears the two of the tag files are missing from your distro CD.

Yes, if the executable for the RVM integrator is not found, AutoRIS will just skip over that section completely. The same with nLite. I do have a mandatory pause for BTS at the moment because I'm still not sure how that integration will take place.

I've personally never had luck with RIPrep and after fighting with it for so long, just went ahead and made my normal RIS images so automated and tweaked that the end result is the same. Actually probably superior since it's clean install. I've never considered RIPrep installs to be "clean". My first hunch is to say that there's a difference in the mass storage controller from one machine to another. With all of these new SATA controllers, RAID controllers coming out these days, I could imagine this happening.

The error seems to be indicating that you do not have a Windows XP SP2 CD in your CD-ROM (or an .ISO file of such mounted with something like Daemon Tools). AutoRIS attempts to copy the tag files over to the RISTEMP directory since RVM (and maybe nLite) need them in order to function properly. In the next version I'll throw in some code to check and see if those files are already there and if they are not there and there is no XP SP2 source available the script will allow you to put a CD in and continue. For now though, just make sure you have a CD in the drive.

I was going through the run_me.cmd batch today trying to get a better feel for what's going on in the background there and I noticed something. The check for KB888111 looks for the presence of one of the dll files from that particular hotfix. The problem is that if you use RyanVM's update pack, I don't think you're going to see that file in i386 because of the way the hotfix is integrated using the RVM pack. I don't know if this would create any problems or not, but it does result in duplicate entries being made in txtsetup.sif and dosnet.inf. Perhaps an additional check could be done for the presence of RVM having been integrated already could solve the issue.

Yea and I'll have to get BTS integration put in You're a bigger man than me for tackling that one as smooth as you did.

10/11/2005 nLite V1.0 RC1 tested and works. Now there is a tool to go along with the guide. AutoRIS will automatically do most of the chores outlined in post #1 of this guide. In other words, not the scripts.

AutoRIS V2.10 2006-04-07 David Stein aka RogueSpear AutoRIS V2.10 - 2.76MB MD5: 62F36324F011B8B9D61128068C309514 NOTICE - 08/08/2006 I will leave this final version of AutoRIS available for download until 12/31/2006 for those that are interested for one reason or another. Understand however that the DriverPacks functionality will not work at all with the new generation of that project. Furthermore, I will no longer be updating AutoRIS since it has been succeeded by my new utility AutoImage. The source code for AutoRIS is free for use and / or modification by anybody with a few conditions: You do not purport any modified code to be completely of your own making. My name or handle should still be referenced in the source code. You will NOT sell the source code or any modified version of it. You will NOT include the source code or any modified version of it as a part of some other commercial software. You absolutely CAN include the source code or any modified version of it as a part of an open source software project. YOU will provide support for and take responsibility for any technical issues the arrise from using the source code or a modified version of it. If you have seen my guide to unattended RIS then you will have an idea of what this utility will do. What is in the guide has been automated now, but I would recommend it for reading if you are involved with RIS deployments and plan on using AutoRIS. It's always a good idea to know what's going on in the background. Please make sure that you have read this entire post and the documentation inside of the AutoRIS.ini file prior to asking for help. Features Prepare your RIS image for compatibility and processing with RyanVM's Windows XP Post-SP2 Update Pack, nLite, XPize (as an nLite hotfix), and Bashrat the Sneaky's Driver Packs. Perform the integration of RyanVM's Update Pack. Automatically launch nLite and resume upon completion. Automatic Method 2 integration of the BTS Driver Packs. Includes added support for new model Broadcom, Intel, Marvel, and RealTek NIC adapters. Add your own new NIC drivers that are not natively supported by RIS. Add custom user .SIF files to the \Templates directory. Will automatically restart the BINL service on your RIS server. Will upload the image back to the RIS server, including the $OEM$ directory. Recompress the .INF and .PNF files directly on the server. Easily configurable by modification of an .ini file. Integration of the Microsoft .NET Framework V1.1 SP1 and V2.0. Integration of the Microsoft Visual J# Redistributables V1.1 and V2.0 Ready made cmdlines.txt with accompanying cmdlines.vbs script and ready made VBscripts for RunOnceEx. No script modification is necessary. All script settings are now stored in an .ini file. This makes for a total end to end RIS solution. Please visit this thread for documentation regarding the scripts. INSTRUCTIONS Decompress the AutoRIS.7z archive directly to the root of a hard drive. The hard disk should have enough free space on it for a fresh RIS image in addition to enough space to perform RVM and nLite operations. After decompressing the archive you will have a directory called AutoRIS. This directory is where everything will take place. Copy the RVM Integrator and whatever update packs you use to the AutoRIS directory. The Windows XP SP2 ident files are included with AutoRIS and they should not be deleted. Filecase.exe is required and must be within your system path for AutoRIS to function properly. It is included with AutoRIS, but you can just drop in %SystemRoot% or somewhere else within your path. If you already have filecase.exe, feel free to delete the copy inside the AutoRIS directory. Open AutoRIS.ini in any text editor and edit the entries to suit your environment. Many of the default settings will be fine for most users, but some of the paths that are specific to YOUR network must be set before running AutoRIS. An example custom .SIF file, SP2.SIF, is included. You may edit this file to suit your environment. You can put as many of your own custom .SIF files in the AutoRIS directory as you like. They will all be integrated into your RIS image. Before running AutoRIS, you should generate an integrator.ini file for the RVM Integrator to use. A sample integrator.ini is included so that all you need to do is modify it to your needs. NOTE: AutoRIS requires at a minimum V1.05 of the RVM Integrator. nLite V1.0 RC7 has been tested. Included is RIS.ini, the settings file from nLite that I personally use with RIS deployments. You are welcome to inspect it, modify it, and use it as you see fit. Please note that it removes all languages except US English. Adjust the settings in AutoRIS.ini for BTS DriverPack integration. Make sure to read the documentation contained in AutoRIS.ini for how to do this properly. On your RIS server, after creating a fresh image, you should have a directory named "i386". The first time AutoRIS is executed, it will check for this directory, and rename it to "i386-Original". AutoRIS will then copy down it's source files from there. You should leave this directory in place for future use. When a new version of RVM, nLite, or BTS comes out, you can then just run AutoRIS and it will grab the default image from i386-Original. Once you have everything edited and your files in place, just double click on AutoRIS.vbs. This should go without saying, but the script obviously won't work if you have disabled WSH. Please note the following: This tool was designed around and tested on a RIS image created with Windows Server 2000, but I have received multiple reports of full compatibility with Windows Server 2003, including SBS. AutoRIS must be executed using a domain account that has administrative rights to your target RIS server. This must include the right to stop and start the BINL service. Change Log V2.10 - 04/07/2006 - As it turns out, I didn't inroduce a bug with the WMI method of BINL service restarting. It does seem that PsService is the more reliable method. I really don't know what method PsService is using to do it's thing, but it must not be WMI. - All NIC drivers have been updated. - Experimental support for nVidia nForce NICs has been added. Since I don't have any such hardware, I can't do any testing of this myself. As always, your feedback is welcome. - The cmdlines and RunOnceEx script have continued to undergo extensive updating. For a complete description and documentation of the scripts please visit this thread. V2.00 - 03/26/2006 - Finally I broke down and put the code in to do a Method 2 BTS DriverPack integration. Method 2 is the only one supported and will be the only one supported until the next gen BTS Slipstreamer is released. In order for the integration to work you must use the Method 2 Helper Addon that I include with either the RyanVM Integrator or nLite. In order to get the DriverPack Sound packs to function properly with HD sound adapters, you must integrate RyanVM's Post SP2 Update Pack with either the RVM Integrator or nLite. - I completely reworked all of the scripts. These will be better documented shortly in another thread which I will link to. This new set of scripts is completely modular. They will work with either a RIS or CD/DVD based install. There are two basic requirements - you must use my cmdlines.vbs script and the file 999_settings.ini must be located in $OEM$\$1 (for RIS) or %CDROM$\OEM (for CD/DVD). If there is a script that you don't want to use in RunOnceEx, just leave it out - everything is autodetected now. Some initial documentation is located in the 999_settings.ini file. - There is now a choice between using either WMI or SysInternal's PsService to restart the BINL service. This will hopefully eliminate the issues with Windows Server 2003 throwing up a permissions error. The selection is a setting in AutoRIS.ini. Due to licensing restrictions I am unable to include PsService with the AutoRIS distribution. You can download it from SysInternals directly here. V1.52 - 02/10/2006 - The supplemental NIC drivers have been updated. There is still a conflict between the latest revisions of RealTek's NICs and their older integrated NICs. If you need to support only the older versions, you should remove the updated RealTek drivers from the NIC_Drivers folder. - Automation for a full BTS DriverPack slipstream has been removed. In place is the old style "pause and wait" where you must perform the slipstream/integration on your own. - The nLite sample .ini file has been updated to reflect nLite V1.0 RC6. - Added Restricted Sites Zone protection to the cmdlines.reg registry tweak file. V1.51 - 01/12/2006 - Corrected a fairly serious bug in which not all compressable files were being compressed. - The location of additional NIC drivers to be integrated is no longer user definable in AutoRIS.ini. - All VBscripts have been updated and there is one less reboot required during the setup now. - There is no more Full and Lite versions. The AutoRIS download now includes all of the VBscripts. - Links are provided for the additional addons and installers. V1.50 - 12/31/2005 - AutoRIS settings are now retrieved from an .ini file, AutoRIS.ini. - More and better error checking and handling. - Deleting the default .SIF file, RISTNDRD.SIF, is now an option (set in AutoRIS.ini). - Updated existing NIC drivers, and added support for Broadcom NICs. - Integrating additional NIC drivers is now an option (set in AutoRIS.ini). - VMware or VirtualPC, if present will be launched automatically after the BINL service is restarted on the RIS server. - nLite is now automatically launched. - Final compression of .INF and .PNF file is now optional. - AutoRIS now indicated that it is terminating both at the completion of processing and when it encounters path errors. - A "Full" version of AutoRIS is now available for download. This version includes support for cmdlines.txt, RunOnceEx, automatic integration of .NET runtimes, and more. V1.03 - 10/30/2005 - Add custom user .SIF files to the \Templates directory. I have included a sample .SIF file which will be copied by AutoRIS. Users can either edit this file to suit their needs or replace it entirely with one or more of their own .SIF files. The default .SIF file, RISTNDRD.SIF, is deleted by default. - Drivers for Intel Pro, Marvel Yukon, and RealTek are now included with AutoRIS. The .SYS files are not compressed in the distribution in order to achieve greater compression of the AutoRIS download file. The .SYS files are compressed during execution of AutoRIS. V1.02 - 10/13/2005 - More error trapping, couple of minor modifications, and a lot of testing. - Changed the defaults to drive letter C:\ as this seems to be much more popular than D:\. V1.01 - 10/12/2005 - Tag files for Windows XP SP2 and filecase.exe are now included in the AutoRIS download. Tag file detection has been removed completely. Removal of the tagfiles from the AutoRIS temp directory could prevent RVM and nLite from properly functioning.

You cannot run the script from cmdlines.txt because it relies on WMI and WMI is not yet available at the cmdlines stage of setup. Note also that what I posted is simply a subroutine. In order for it to run all you should have to do is add one line to the bottom of the script (make it the last line): ConfigPageFile In fact I'm going to edit the post to reflect that.

Here is a VBscript subroutine I wrote for resizing the page file to twice the amount of RAM in a system. Been using it for years without problems. Sub ConfigPageFile Dim strComputer, objWMIService, objSWbemServices, colPageFile, colSWbemObject Dim colSWbemObjectSet, objSWbemObject, objPageFile, SystemRAM strComputer = "." Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set objSWbemServices = GetObject("winmgmts:\\" & strComputer) Set colPageFile = objWMIService.ExecQuery ("SELECT * FROM Win32_PageFileSetting") Set colSWbemObjectSet = objSWbemServices.InstancesOf("Win32_LogicalMemoryConfiguration") For Each objSWbemObject In colSWbemObjectSet SystemRAM = objSWbemObject.TotalPhysicalMemory / 1024 Next For Each objPageFile In colPageFile objPageFile.InitialSize = 2 * SystemRAM objPageFile.MaximumSize = 2 * SystemRAM objPageFile.Put_ Next End Sub ConfigPageFile

Someone had inquired about IPSEC above. I have only experimented with this in a lab situation. My impressions are that it's about as rock solid of a secure network implementation as you're going to get for your client/server and server/server communications. There are some caveats however. The setup is a total bear. I mean seriously, this is not for the neophyte network admin. In fact I would say that unless you're one of these people who dream in binary and hex, that you should only attempt it on a large scale if there is more than one person involved in the planning and implementation. There's a lot to consider which means there's a lot to forget somewhere along the way. Now I have one to throw out there. I've been using Symantec Client Security for several years now. This is primarily due to the AV portion of the client. I've always been very impressed with the performance of that product and my history of having no major outbreaks or infections really speaks for itself. On the other hand, the firewall portion of this client is plain crap. I'm actually struggling at this point to not bang out 10 pages of venom detailing all of the reasons I hate the product and why it has totally destroyed any and all of my confidence in Symantec as a whole. So what I am asking is this: what managed firewall based product would get your recommendation based on actual experience with that product. I have had so many issues with the Symantec product that I actually don't install the firewall at all. You can only take so many episodes of someone screaming on the other end of the phone at you. So I would actually say that the ease of management and the reliability of the product is what's most important to me. If it's the greatest most secure firewall on earth, but it's such a chore to manage and riddled with bugs that commonly prevent legitimate communications to go through, then it's actually more unsecure because, like in my case, you'll never actually use it.

This list really made me realize how many excellent free programs that I use day to day. I wont mention again those that have already been mentioned, but will toss out some I haven't seen mentioned yet. Paint.Net The Proxomitron Tor

I don't think it does it silently, in fact I'm not sure that's possible anymore, but try a search for DenyBud. Does the trick every time.

There's just way too much fooling around that needs to be done when you're not logged in as an admin. Between software installs, script writing.. I've tried and pulled my hair out every time. To tell you the truth, between all the antispyware, antivirus, firewall, special proxies, XP SP2, etc.. it's been quite some time since I've had any issues at all.

I've made my own such CD (actually it's a mini-DVD - 1.4GB). A couple of welcome, freeware additions would be About:Buster, which has saved two different computers for me. Another would be Index.dat Suite. Both can be found either at BetaNews or Softpedia.

This is going to be a slightly off topic reply as, I too, don't quite understand what he wants. But whatever it is, I'm sure that there would be dozens of acceptable suggestions. I have found that particularly in the area of network management, monitoring, analysis, etc., that the prices these products command is just insane. I quite honestly would never even suggest to most of my clients any of these these products for fear of being laughed right out of the office. With all of that being said, I personally, would make every effort to recommend freeware / open source products. Perhaps if more people used such software, some of these software developers would come back down to earth. Some of my favorite examples are Ethereal, Snort, and Nessus. I will admit however to getting my main employer to spring for Solar Winds EE, and I do use that all the time almost everywhere my laptop goes. But there you actually have a good example of a package that isn't too far out of whack in terms of pricing, especially when you look at a package like Sniffer or some of the NetIQ products.

When it comes to msi files, I long ago gave up on best practices. Best practice for who? Certainly not me or anyone who wants to get some work done. For quite a long time I succumed to the "do not modify the msi, make an mst instead" rule. Well a couple of years ago I decided to buck that little piece of Microsoft propaganda. And let me tell you, my custom msi files and switchless silent installers improved dramatically. In some cases (Adobe Audition), I don't think a good, optimized, unattended install would not have been possible. The only msi I have left intact more or less, is MS Office. And that's primarily because of the excellent resource kit utilities. Directly modifying msi files will definately open up a whole new world if you decide to give it shot (and you know at least a little bit about what you're doing).

The Symantec Packager was a short lived product that is no longer supported by Symantec. Honestly, there is no reason to use it anymore. And I don't believe they supply you with the necessary pmi file in order to use it with current products.

It's easier to just do a repack of the whole thing. As a matter of preference I always choose to do the old style snapshop (two stage). You'll run into way less problems this way, especially when you're dealing with an application that installs drivers and/or services. You will however need to edit the registry entries captured prior to compiling the project into an msi file. Especially look out for entries pertaining to the actual CD-RW drive. If you use VMware, it's a NEC VMware or something similar. Nero has always been one of the more time consuming apps for me to repack. It takes time and attention to detail, but it's always worked for me.

One of the things I always do is remove the new video drivers with nLite. Nuhi seperated the "new" from the "old" video drivers. So far it's worked great for nVidia, ATI, Intel, and Matrox chips. Haven't had a problem yet.

I think you have a good workable process down, now it's a matter of implementation. If you run into scripting problems or anything you know where to find me

In Active Directory Users and Computers (dsa.msc), in the properties of a Computer, there is a field for description. This field does not actually correspond to the description field in the properties of My Computer, which is something I could never understand anyway. But, going on the assumption that you are prestaging your computers in their appropriate OUs, the prestaging process is probably fairly labor intense to begin with (if you have ~2000 units). Using ADSI within a VBS, you could script the prestaging of your computers and include the asset tag in this process, putting it in the description field. Then your post setup script, if you even decide you'd need it at this point, would only have to query ADSI for the Active Directory description of the computer and place it in the registry entry that populates the description field from My Computer. This way you'd get the best of both worlds. You would cut down your prestaging labor, and get the asset tag in both description fields.

The NV chipset may be among the most capable and high performing, however trying to get one of these things to properly install using RIS or in a traditional media based unattended fashion is enough to make a grown man cry. One thing I will give AMD... dual CPU options. Right now I can't think of a viable dual CPU option for a home user using an Intel CPU. I'm dying to build a dual CPU machine using Intel dual cores with Hyperthreading

If you want to find some real tech nitty gritty on CPU inner workings I would try these two web sites: AnandTech Tom's Hardware Guide In my personal experience I've had more problems with AMD based systems than I'm willing to put up with. I'm not actually sure if this is due to the AMD processor or the completely substandard mobo chipsets put out by ALi, SiS, and VIA. I've seen way too much complaining on boards regarding nVidia chipsets. So much so that I would never try one out, at least not with my own money. I haven't heard too much about a solution with an AMD chipset however. At this point I only recommend Intel mobos to my clients. They aren't gamers, they're businesses and as such, stability and reliability are paramount. If you're a gamer I'm guessing anything would beat out Intel, just don't expect the same kind of reliability.