RogueSpear

I finally managed to integrate the 7.0.1 and 7.0.2 updates into the source. Looking back on it, it's not all that hard.. but **** did I spend way too much time in VMware screwing around. The integration isn't "perfect", meaning that the updates still show up as being not installed in the Adobe Update program. The splash screen, about screen, file versions, etc. are all up to date however. Before posting a guide, I'm trying to see if activation can be made unattended. And I hate to say this, but I'm thinking not. I've isolated the file and the two registry entries made as a result of activation, but the thing is super sensitive. Upon install it always tells me that the configuration has changed and you must reactivate. This may just be unavoidable using legit methods.

My uA DVD is pretty much complete at this point. Just for my own added convenience though I decided to throw in the install files for some other applications that I use from time to time, but I don't necessarily want them to be installed. I had already been doing this in fact and everything was working great with the DVD at a comfortable size of 3.5GB. No when I toss in some more stuff and the size swells to 4.2GB it doesn't want to work. Specifically, when the disc first boots, before I even see the blue text mode portion of setup, I get an error message that says that my txtsetup.sif file is corrupted or damaged. No matter what way, sequence or method I use to create this ISO file or burn the DVD, I get that error message. Some time ago I was receiving that same error and after a long long time found out it was because I was checking "Optimize" in UltraISO in order to save a couple meg here and there. Once I stopped doing that the problem went away. I am guessing that doing the file optimization somehow or another messes around with the txtsetup.sif file. Or am I totally wrong altogether? Is there some limitation I'm not aware of in Joliet? Any help would be appreciated as I had grand dreams of making a DVD-9 install disc sometime in the near future.

@kanesama, I know that BTS is aware of the site problems and plans to migrate to another hosting provider. This may take a couple of weeks however. I don't know of anybody mirroring his project right now. If you do have an older version of the DPs you may want to try and see if you can get the SATA controller working using an unattended CD first. If you get that part working then at least you know it will work under RIS as well. Regarding the NIC. I'm not familiar with Via's line of products. Due to some fairly bad experiences in the past, I always shy away from anything they make. What you may want to do though is check their web site and see if there is any documentation about RIS. In the past, Intel's NICs used to require a special .inf file in order to properly boot. Also doublecheck to make sure the NIC claims PXE compliance.

@Brainstane, integrating RyanVM's Update Pack is probably the best way to integrate Microsoft's hotfixes, but you can use the /integrate switch with current hotfixes. Regarding the groveler; this is a pretty interesting service. The idea behind it is that it searches out duplicate files and essentially takes the duplicates and turns them into pointers to a "single instance" of that file. This way if you have half a dozen images (think RIPrep here), most of the files are all the same so you will save huge on disk space. I've actually heard of outfits making a RIPrep image for every single workstation in the enterprise so that if one goes down, the end user can just boot to the network and dump his workstation back. Not quite my cup of tea, but if you have say 400 images where 98% of the files are identical, this is obviously quite a savings. It would actually be nice if you could run the groveler on any partition. Think about the savings and the lack of fragmentation on a partition that stores a couple thousand roaming profiles. @Kreabea, I think you may have to doublecheck your various files to make sure the paths are correct.

I have to say that I had difficulties using the inf file method, so I came up with a reg file that works just fine from cmdlines.txt. Windows Registry Editor Version 5.00 ; Maxthon [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ftp\shell] @="Maxthon" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ftp\shell\Maxthon\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ftp\shell\open\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htmlfile\shell] @="Maxthon" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htmlfile\shell\Maxthon\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htmlfile\shell\open\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\HTTP\shell] @="Maxthon" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\HTTP\shell\Maxthon\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\HTTP\shell\open\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell] @="Maxthon" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\Maxthon\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\open\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\InternetShortcut\shell] @="Maxthon" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\InternetShortcut\shell\Maxthon\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\InternetShortcut\shell\open\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mhtmlfile\shell] @="Maxthon" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mhtmlfile\shell\Maxthon\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mhtmlfile\shell\open\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet] @="Maxthon.exe" [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Maxthon.exe] "LocalizedString"="Maxthon Web Browser" [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Maxthon.exe\shell] [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Maxthon.exe\shell\open\command] @="\"C:\\Program Files\\Maxthon\\Maxthon.exe\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform] "Maxthon"="??" [HKEY_CURRENT_USER\Software\Maxthon] "InstallCount"=dword:00000002 [HKEY_CURRENT_USER\Software\Maxthon\Dync] "Running"="0" [HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\MUICache] "@explorer.exe,-7004"="Opens your Internet browser." "@shell32.dll,-12704"="Internet P&roperties" "@shell32.dll,-12705"="&Browse the Internet" "C:\\Program Files\\Maxthon\\Maxthon.exe"="Maxthon Web Browser"

Mhh, this sif file has to be linked to the installation in the RIS server if I am not mistaken, right ? Are you sure the location of this sif file does not matter ? I said that the name of the file does not matter. Only the file extension, and then to place the file inside the \i386\templates directory. It's all in the quote of my original post. A perfect example for explanation here is the Intel Pro 100 NIC. The original release of this NIC and some versions thereafter are supported out of the box by RIS. Some newer versions however are not. When you try to do a RIS boot you get a blue screen message stating that a driver supporting your NIC could not be found. So we need to go through this procedure of adding NIC drivers. It's somewhat analogous to adding mass storage drivers, just not exactly the same. I believe so long as the NIC is PXE V2.0 or greater compliant, it should work. The utility RBFG.exe, which makes a boot floppy for RIS, I think is allowing you to use a non-PXE NIC with RIS. That's why it's support is so limited. Yes it is possible to do this with other NICs. I haven't run into a situation yet where this was necessary however. RealTek and Kingston branded NICs will both use the built in Intel Pro 100 NIC drivers for instance. At some point, BTS could probably make his DP LAN "RIS aware" and have the option integrate the NIC drivers for this purpose as an option, much like the option to KtD (Keep the Drivers).

Here's an example that you may be able to adapt for your purposes. It's not pretty, but it works and I left it at that. Set ws = WScript.CreateObject("WScript.Shell") Set fs = CreateObject("Scripting.FileSystemObject") sysdrv = ws.ExpandEnvironmentStrings ("%SYSTEMDRIVE%") progdir = ws.ExpandEnvironmentStrings ("%PROGRAMFILES%") windir = ws.ExpandEnvironmentStrings ("%SYSTEMROOT%") defuser = sysdrv & "\Documents and Settings\Default User" Set colDrives = fs.Drives For Each objDrive in colDrives If fs.FileExists(objDrive.DriveLetter & ":\WIN51") Then strCD = objDrive.DriveLetter & ":\" Next strOEM = strCD & "OEM\" str7Zcmd = windir & "\system32\7za.exe x -y -aoa " & strOEM If fs.FileExists(strOEM & "\000_ProgFiles.7z") Then ws.Run(str7Zcmd & "\000_ProgFiles.7z -o" & """" & progdir & """"),0,True If fs.FileExists(strOEM & "\000_DefaultUser.7z") Then ws.Run(str7Zcmd & "\000_DefaultUser.7z -o" & """" & defuser & """"),0,True The last two lines should be of particular interest and unfortunately they also wrap around since they are so long. I'm sure someone here could come up with another way to accomplish this and it would look a lot better, but I needed this to work ASAP. Sometimes down and dirty is good enough

I posted the RIS guide here. Let the questions and comments begin..

09/28/2005 -- This guide is no longer valid. I have discovered several issues that must be addressed and in the process have concluded that a rewrite of the guide is necessary. A new guide is forthcoming. Use of this guide in a production environment IS NOT RECOMMENDED. 10/11/2005 -- The NEW GUIDE is posted along with a new automatic tool, AutoRIS, that will perform most of the guide functions automatically. The intended audience for this guide is an IT professional who already has a basic understanding of RIS and can set RIS up to work in it's "out of the box" form. In order of appearance, this guide currently covers: Windows XP Service Pack 2 jcarle's Compression Bin RyanVM's Windows XP Post-SP2 Update Pack V1.3.1 nLite V1.0 Beta 6 (MSFN Forum) XPize uAE Notepad2 Media Player Classic Bâshrat the Sneaky's Driver Packs V5.08x (MSFN Forum) 08/05/2005 Initial posting 09/09/2005 - Updated compressing of files to include some .dll and .exe files. - Updated RyanVM's Update Pack to cover V1.3.1. - nLite V1.0 Beta 6 tested and works - Longwinded dissertation about about adding NIC drivers and it's quirks. Make An Initial RIS Image First we need to start out with a proper foundation. At the time of this writing, the best source to use for your initial RIS image is a Windows XP Gold CD with SP2 slipstreamed. Your source CD should have nothing else at this point. Only Service Pack 2! 1. Once you have created this base image on the server machine, create a new directory on your local workstation called RIS. We'll be using this as our working directory. 2. Copy the i386 directory from the RIS image to the RIS directory on the local machine. 3. Copy the tag files (WIN51, WIN51IP, WIN51IP.SP1, WIN51IP.SP2) from your SP2 CD to the RIS directory on the local machine. The tag files will be necessary for later use with both nLite and RyanVM's Update Pack (this requirement may not be necessary as future releases of both products are released). 4. Next we are going to compress a lot files. When you create your initial RIS image on the server, files with the extensions .inf, .nls, .ocs, .pnf, and .sys are not compressed. But they can be and I always compress them in the interest of making as efficient of an install source as possible. There's a more important reason however. In their current forms, nLite and RVM are not designed to be "RIS-aware" - again this may change with future releases. Example: Your RIS image will contain a file called SWFLASH.INF and when you integrate RVM you will now have a file called SWFLASH.IN_. Now you will have both SWFLASH.INF and SWFLASH.IN_. This isn't good as the file from RVM is more current. I have found the easiest way to compress all of these files is to use jcarle's Compression Bin program. There are some files that must not be compressed and they are: BIOSINFO.INF, .PNF DMREG.INF, .PNF DOSNET.INF, .PNF DRVINDEX.INF, .PNF HIVECLS.INF, .PNF HIVEDEF.INF, .PNF HIVESFT.INF, .PNF HIVESYS.INF, .PNF HIVEUSD.INF, .PNF INTL.INF, .PNF LAYOUT.INF, .PNF MSTASK.INF, .PNF NTPRINT.INF, .PNF SYSOC.INF, .PNF WAVEMIX.INF (does not seem to have a corresponding .PNF file) KSECDD.SYS NTFS.SYS SPCMDCON.SYS UPDATE 09/09/2005: Fencer128 from RyanVM's forum brought to my attention that some .exe and .dll files are not compressed in a RIS image but they are compressed on an XP CD. This brings about two issues. First and most importantly, it could interfere with the proper integration of the RVM Update Pack if they are not compressed. Second, we can save a little more room, making the initial file transfer a little faster (albeit hardly noticeable). The following files can be compressed in your RIS image: BOOTVID.DLL HAL.DLL HALAACPI.DLL HALAPIC.DLL HALMACPI.DLL HALMPS.DLL HALSP.DLL KD1394.DLL KDCOM.DLL NTKRNLMP.EXE NTOSKRNL.EXE OSCHOICE.EXE OSLOADER.EXE SETUPLDR.EXE 5. At this point you may wish burn a CD with the contents of the RIS directory on your local machine. If you make any mistakes later on or just want to do things a little differently, this will save you a huge amount of time. Trust me on this, I've wasted literally tens of hours remaking everything up to this point in the guide because I never backed it all up. The Extras 6. My personal preference for RyanVM's Update Pack is to perform a manual integration. Version 1.3.0 is due out before too long with a new GUI interface for integration so this section may change in the next few weeks. But for now download V1.2.2 and the V1.2.2b update. Follow the instructions for the manual integration. I don't know why so many have had a hard time with the manual integration, but the instructions are dead on accurate and I haven't had a problem with them. Only my own inattention got me in trouble once. I stress a manual integration because I have never had good luck with letting nLite do the integration for me. So I'm posting what I know works. UPDATE 09/09/2005: Version 1.3.1 has been released. I have tested it using Ryan and Siginet's RVM Integrator and it works great. I have not tested the pack by integrating it via nLite and quite honestly I probably won't. I don't have the time to test out a method I never use. If I get reports of it working, I'll indicate that here in the future. 7. At this point I run XPize. The version for unattended installations. I have used it and can verify that it works just fine on a RIS image. 8. Now is time to use nLite and lighten the load on this pig. You are going to point nLite at the RIS directory on your local machine. I don't remove a huge amount of things using nLite, but I can report that the following can be taken out and your RIS will work: Components Briefcase, Paint (I use Paint.NET), Wordpad (useless) Drivers ATM, Display Adapters (new ones only, use BTS DPs for new adapters), IBM ThinkPad, ISDN, Sony Jog Dial, Toshiba DVD decoder card Languages All Multimedia Music Samples, Old CD Player and Sound Recorder, Windows Media Player Network Client for Netware Networks, Communications Tools, MSN Explorer, NWLink, Windows Messenger (install V5.1 if you need it) Operating System Options Administrator VB scripts, Disk Cleanup, Document Templates, File and Settings Wizard, Framework, Manual Install and Upgrade, Search Assistant, Security Center, Shell Media Handler, Tour, Zip Folders Services Alerter, Application Layer Gateway, Messenger, Telnet Server I always select to patch uxtheme.dll and windows file protection, keep the keyboard layouts, remove the MUIs, and perform higher compression. Keep in mind that if you are performing RIS installs that your target computers are members of a domain (more than likely). So I wouldn't recommend wiping out Internet Explorer, some of the other networking components or anything that makes you think it may be involved with authentication, etc. 9. I always replace notepad with Notepad2 and mplayer2 with Media Player Classic. This is a good time to use throw those in. Rename notepad2.exe to notepad.exe, rename mplayerc.exe to mplayer2.exe, send them through Compression Bin and toss the resulting files in the i386 directory overwriting the existing files. 10. It wouldn't hurt at this point to do a dry run and make sure everything is working as it should. We've done quite a bit of manipulating to the original image and it's pretty easy to make a small mistake somewhere. Delete the i386 directory on the RIS server in the folder that contains your RIS image. Copy over the i386 directory from your local machine to the RIS server. If you have the time and ambition you may even want to do a test install after each major step of the way so that if there's a failure, you will know where that failure happened. The BTS Driver Packs I started a whole new section here because IMHO this is where people are bound to have the most difficulties. It's where you need to do the most hands on work. For integration of the Driver Packs, I use Method 2 exclusively. Method 1 will work, but it takes longer and puts more stress on the network and the RIS server. Also I have not used the Keep the Drivers (KtD) option, so you're on your own with that part. 11. Run the BTS_DPs_Slipstreamer_Vxxx.cmd file and chose Method 2. Follow the remaining instructions. 12. In your BTS working directory you will see a new directory called UWXPCD_ROOT. Copy the contents over to the RIS directory on your local machine. Run the RUN_ME.cmd file as per the instructions. This will integrate the mass storage drivers and patch various .inf and .sif files. When finished our directory structure is going to look as follows: RIS | |-$OEM$ | |-$$ | | |-System32 | |-$1 | | |-D |-i386 |-OEM | |-bin 13. Move the file 7za.exe from \OEM\bin to \$OEM$\$$\System32. 14. Move SetDevicePath.exe and WatchDriverSigningPolicy.exe from \OEM\bin to \$OEM$\$1\D. 15. Move all of the .7z archives from \OEM to \$OEM$\$1. 16. Delete the directory \OEM. 17. Go to the i386 directory and delete both WINNT.SIF and WINNT.old. They are no longer needed. You will need the line command9 = "%SystemDrive%\D\BTS_DPs_Finish.cmd" for later use. 18. We need to edit the TXTSETUP.SIF and DOSNET.INF files if you integrated RyanVM's Update Pack as described earlier. RVM and BTS both make entries for KB888111 in these two files. No sense in having duplicate entries and I'm not sure if duplicates would cause problems but why take the risk? The files with duplicate entries are: hdaprop.dll hdashcut.exe hdaudbus.inf hdaudbus.sys hdaudio.inf hdaudio.sys hdaudres.dll Check the [Files] section of DOSNET.INF and the [sourceDiskFiles] section of TXTSETUP.SIF. You may have to scroll down a little bit. BTS's entries will be at the top followed by entries for the added mass storage driver files, then the RVM entries. 19. We need to edit PRESETUP.CMD so that it reads as follows: 7za.exe x -y -aoa %SYSTEMDRIVE%\DriverPack*.7z -o"%SYSTEMDRIVE%" %SYSTEMDRIVE%\D\SetDevicePath.exe %SYSTEMDRIVE%\D START %SYSTEMDRIVE%\D\WatchDriverSigningPolicy.exe EXIT 20. Now for the SIF file. In the \i386\templates directory should be a lone .SIF file. Delete this one and create your own with setup manager or you can do a little bit of cut and paste with mine: ;SetupMgrTag [Data] AutoPartition=1 DisableAdminAccountOnDomainJoin=1 MsDosInitiated="1" UnattendedInstall="Yes" floppyless="1" OriSrc="\\%SERVERNAME%\RemInst\%INSTALLPATH%" OriTyp="4" LocalSourceOnCD=1 [Components] AccessOpt=Off chat=off deskpaper=off freecell=off hearts=off hyperterm=off IEAccess=off media_clips=off media_utopia=off minesweeper=off msnexplr=off OEAccess=off pinball=off solitaire=off spider=off templates=off WMAccess=off WMPOCM=off zonegames=off [Display] BitsPerPel=32 Xresolution=800 YResolution=600 Vrefresh=75 [SetupData] OsLoadOptions="/noguiboot /fastdetect" SetupSourceDevice="\Device\LanmanRedirector\%SERVERNAME%\RemInst\%INSTALLPATH%" [Unattended] AutoActivate=No DriverSigningPolicy=Ignore NonDriverSigningPolicy=Ignore UnattendMode=FullUnattended OemSkipEula=Yes OemPreinstall=Yes OemPnPDriversPath= TargetPath=\WINDOWS FileSystem=LeaveAlone NtUpgrade=No OverwriteOemFilesOnUpgrade=No CrashDumpSetting=0 Hibernation=No WaitForReboot=No [GuiRunOnce] command9 = "%SystemDrive%\D\BTS_DPs_Finish.cmd" [Shell] CustomDefaultThemeFile="%WINDIR%\Resources\Themes\royale.theme" [GuiUnattended] AdminPassword=encryptedpasswordgoeshere EncryptedAdminPassword=Yes OEMSkipRegional=1 TimeZone=%TIMEZONE% OemSkipWelcome=1 DetachedProgram= [UserData] ProductID=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX FullName="Your CEO's Name" OrgName="Your Company Name" ComputerName=%MACHINENAME% [TapiLocation] CountryCode=1 Dialing=Tone AreaCode=123 LongDistanceAccess="9" [TerminalServices] AllowConnections=1 [Identification] JoinDomain=%MACHINEDOMAIN% DoOldStyleDomainJoin=Yes [RemoteInstall] Repartition=Yes UseWholeDisk=Yes [OSChooser] Description="WinXP SP2 - Custom" Help="This will install Windows XP SP2." LaunchFile="%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com" ImageType=Flat [Networking] InstallDefaultComponents=Yes ProcessPageSections=Yes [WindowsFirewall] Profiles = WindowsFirewall.TurnOffFirewall [WindowsFirewall.TurnOffFirewall] Mode = 0 You can name it pretty much whatever you want. Just put the .SIF extension on it and place in the \i386\templates directory. 21. Now we'll add NIC drivers for newer NICs that aren't natively supported by RIS, like most of the newer Intel Pro NICs. In the past with Intel you had to find and download a special .inf file for RIS purposes. The driver included .inf files would not work. I have found with version 10 however that they have finally resolved that issue. So download the newest Intel NIC drivers and extract them to a temporary directory. There should be seperate directories for Fast Ethernet and for Gigabit Ethernet adapters. From each copy the .sys and .inf files to your \i386 directory. 22. Copy the entire contents of your \RIS directory on your local machine to the folder on the RIS server where your RIS image belongs. On the RIS server stop and then start (or simply restart) the Boot Information Negotiation Layer service. This is necessary in order for the new NIC drivers to work. 23. The first time you go to boot up a machine into RIS it may fail to boot. At least it always does for me. That first time you do it seems to be when the RIS server decides it's going to generate .PNF files for the new NIC drivers. So if it fails the first time, even the second maybe, don't panic. Give it a minute and try again. 24. Once you have this all working (let us pray), you could go to the \i386 directory on the RIS server and look for any .INF, .PNF, and .SYS files that need compressing with Compression Bin. Remember not to compress any of the files listed above in step 4. But you may fine portcls.sys and the newly added NIC drivers could be compressed. Once those .PNF files have been generated by the RIS server it is safe to compress them. UPDATE 09/09/2005: I have discovered some caveats that may be giving users a difficult time. First off, even though we are compressing a lot of files in this procedure and it all works fine, it seems as though RIS wants them to be in their uncompressed form when it comes to NIC drivers and the whole .pnf file generating thing. For instance, VMware emulates an AMD PCnet NIC, which is indeed RIS compliant. But when you go to RIS a VM you'll get a nasty message stating that there are no compatible drivers for your hardware. The solution is to decompress the NETAMD*.IN_ files, delete the NETAMD*.PN_ files, restart the BINL service on your RIS server and have another go at it. This leads me to the second issue. Let's say you integrated your Intel NIC drivers as I outlined above and then compressed the corresponding files. Now you notice this little hangup with VMware so you go through the procedure I just outlined in the previous paragraph. Guess what? Your workstations with the brand spanking new Intel NICs won't boot to RIS anymore. Needless to say this really leads to a pain in the butt situation. What I've done for now, until I can come up with something a little more efficient is this: 1. Make a directory somewhere called NIC Files. 2. Copy over all of the NET*.INF files into it (these are the uncompressed files). 3. Copy the uncompressed .inf files of other NIC drivers (Intel, etc.). 4. For good measure I also copy over an uncompressed copy of the RVM*.INF and NLITE.INF files. May as well let the server create .pnf files for these too. NLHIVE.INF and NLHIVE.PNF MUST remain uncompressed, so don't bother with these. 5. In your RIS image directory delete NET*.IN_ , NET*.PN_ , RVM*.IN_, and NLITE.IN_. 6. Now copy the uncompressed .inf files from the NIC Files directory over to your RIS image i386 directory. 7. Restart the BINL service on the RIS server. 8. Try to RIS a computer. If you try too soon after restarting the BINL service, the DHCP may fail. Don't worry, just try again. When the blue setup screen says "Please Wait..." at the bottom of the screen this is when the RIS server is generating the .pnf files. 9. You should now have a ton of .pnf files to correspond with all of those uncompressed .inf files. At this point you can compress all of them and delete the uncompressed originals. Unfortunately if you later decide to add another third party NIC driver, you're going to have to go through all of this again. Luckily that shouldn't happen too often so you should feel the pain only one time. BTW.. a tip for using Compression Bin. I have noticed that if Compression Bin is not open when you right click on a group of like 100 files, there is a good chance not all of them will get compressed. If you open Compression Bin ahead of time however, you should have much better luck. I did see recently that jcarle said he planned on rewriting Compression Bin from the ground up. So this may be a short term issue. Closing Words I cannot stress enough the importance of getting your RIS server up and running properly before attempting anything at all in this guide. If the basics are not there, you can't reasonably expect anything else to work. I have not and would not attempt to explain RIS itself and all of the little details about it. There are simply too many resources out there that do a fine job at that already. The same goes for all of the other products named here. They have support forums, web sites, etc. You will have to do a certain amount of legwork all on your own for this to work for you. I cut my teeth in RIS with the help of Mark Minasi's excellent book "Mastering Windows 2000 Server." I would not only recommend it to anyone involved with administering a Windows network, but would go so far as to say it should be required reading. I'm sure it has been updated to "Mastering Windows 2003 Server" and should be easily located at BarnesandNoble.com or Amazon.com. If you want it cheap try going over to Bookpool. Remember basic troubleshooting. Start with as little as possible and work your way up, adding things one piece at a time. Yes it's very time consuming, but understanding how and why something works (or doesn't work for that matter) is so much better than just having everything handed to you on a silver platter. This way when a problem crops up down the road, and they will, you will have some idea as to how to fix that problem yourself.

If you are using Method 1, you can use SetDevicePath.exe from Method 2 so long as you execute it from DetachedProgram in your WINNT.SIF. In fact I think this will almost become the mandatory way of using Method 1 before too long because of the 4096 limit imposed on OemPnPDriversPath.

You're starting to get a little bit off topic with the computer name thing. There are a number of ways to RENAME the computer after the setup has completed within post setup scripting (RunOnceEx). I wrote a couple of scripts - one names the computer for you based on the date and time of the install, the other actually prompts the user to input a name. Try a search in the Unattended forum and I'm sure you'll find a few solutions in there.

PerfectDisk has a file in the install called config.ini in which you can set most if not all of the various program options ahead of the install. You then need to add CONFIG=1 to your msiexec command line statement at the time of install. Also, in the online help for PerfectDisk is a rather complete explanation of all of the commandline options for PDcmd.exe.

I always recommend to clients that they purchase Raxco's PerfectDisk. Some can afford it, some can't, some just don't care, etc.. but I always try my best to make my scripts accomodating to all scenarios so that I don't have a dozen versions of the same script floating around. This VBScript checks to see if PerfectDisk is installed. If it is installed then that's what is used and also it will delete the executable and shortcut for Sysinternal's PageDefrag. So I have one script that works in all scenarios for me. Option Explicit Dim ws, fs, progfiles, raxco, sysint Set ws = WScript.CreateObject("WScript.Shell") Set fs = CreateObject("Scripting.FileSystemObject") progfiles = ws.ExpandEnvironmentStrings ("%PROGRAMFILES%") raxco = progfiles & "\Raxco\PerfectDisk" sysint = progfiles & "\Utilities\Sysinternals" '** Subroutine; PerfectDisk Sub PerfectDisk Dim progs, utl progs = ws.SpecialFolders("AllUsersPrograms") utl = progs & "\Utilities" If fs.FileExists(utl & "\Page Defrag.lnk") Then fs.DeleteFile(utl & "\Page Defrag.lnk"), True If fs.FileExists(sysint & "\pagedfrg.exe") Then fs.DeleteFile(sysint & "\pagedfrg.exe"), True If fs.FileExists(sysint & "\pagedfrg.hlp") Then fs.DeleteFile(sysint & "\pagedfrg.hlp"), True If fs.FileExists(raxco & "\PDcmd.exe") Then ws.Run("""%PROGRAMFILES%\Raxco\PerfectDisk\PDcmd.exe"" /SmartPlacement /WAIT /AllDrives"),0,True If fs.FileExists(raxco & "\PDcmd.exe") Then ws.Run("""%PROGRAMFILES%\Raxco\PerfectDisk\PDcmd.exe"" /SCHEDBOOT /All /AllDrives"),0,True End Sub '** Subroutine; Windows Defrag Sub WindowsDefrag ws.Run("defrag %SYSTEMDRIVE% -f"),0,True If fs.FileExists(sysint & "\pagedfrg.exe") Then ws.Run("""%PROGRAMFILES%\Utilities\Sysinternals\pagedfrg.exe"" -o"),0,True End Sub '** Run Tasks If fs.FolderExists(raxco) Then PerfectDisk Else WindowsDefrag End If Please note that there is line wrapping in this post on some of the longer lines.

The fact that you are using Novell clients kind of disqualifies me from helping you too much. But I can give you some tips to start off with. First off, if you are in an Active Directory domain you could always make a little machine shut down script that writes the registry values which make the restricted user log on automatically at the next boot. So no matter who logs off, those registry entries are written. It would add almost no added time to the shutdown sequence. If you're not in an AD domain, I just know that Novell has to support machine shutdown scripts somehow. The key with a machine shutdown script is that they run under the system credentials, so there's no problem with permissions. For the logon as Admin part of your problem, I'd probably tackle this with a little batchfile. You'll need to use a little application called LSRunAs to pass administrative credentials in order to write the appropriate registry entries. LSRunAs supports encryption of the password using a hash so there isn't too much of a security issue there. Here is a little VBScript subroutine I regularly use as a part of my uA installs that sets the AutoLogon information in the registry. You don't have to use it, but it would at least give you the registry keys and values: Sub SetAutoLogin Dim strKeyPath strKeyPath = "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\" ws.RegWrite strKeyPath & "AutoAdminLogon", "1", "REG_SZ" ws.RegWrite strKeyPath & "AutoLogonCount", "1", "REG_SZ" ws.RegWrite strKeyPath & "DefaultPassword", "thisisareallylongpassword", "REG_SZ" ws.RegWrite strKeyPath & "DefaultUserName", "Admin", "REG_SZ" ws.RegDelete strKeyPath & "DefaultDomainName", "MYDOMAIN", "REG_SZ" End Sub

I've been using InstallShield AdminStudio for a couple of years now and I couldn't live without it. I did check out Wise's offering and really couldn't seem to get into it. Eventually I decided to go with AdminStudio and I'm very thankful that I did. Make no mistake, there is a learning curve associated with this app and to be honest I think that no matter what you go with, it's going to take time, experience, and making a lot of mistakes to get really proficient at working with msi files. At least in my case that's how it's been. The work I produce now is so far beyond what I was putting out two years ago. But that is a result of learning the application and carefully researching problems when they arrise. If you do end up going with AdminStudio and you have questions or need help, gimme a shout.

Major oversight on my part here. I've been throwing around "Method 3" and "M3".. when what I've meant is METHOD 2. About a month or so ago, I switched over to Method 2, never to look back again. The RIS Guide is forthcoming. I'll probably post it here first since I'm still trying to figure out all the wiki stuff.

@ravashaak, LOL I've actually pointed out bugs and a solution to the bug, silver platter and all, to these chowderheads and it'll take in the area of 18 months for them to address the issue. At this point I've gone guerilla. I know it's up to me and other end users out there to figure out the quirks and come up with work arounds to the deficiencies. Since you seem to know your way around this product pretty well.. do you know of any command line options for ALEScan.exe so that I could script a program scan towards the end of an uA install? I've searched high and low, but have not been able to find any such thing. I'm about to break down and finally learn AutoIt to try and tack this one. VBScript just doesn't seem cut out for that task.

I didn't think I could ever find this again, but now that I have... http://www.msfn.org/board/index.php?showto...ndpost&p=332860 This is a post I made over at Nuhi's forum. It really is just about the entire guide I was going to be putting together for uAwiki. So for the time being give it a look and let me know if there's any glaring omissions or errors.

Just for the record, I've been using M3 with RIS for about a month now with no problems. The big difference with RIS is that I put the DP 7z files in $OEM$\$1, so they all get copied to the HD ahead of time. This of course means your presetup.cmd will be slightly different. This is what I use in the case of a RIS Method 3: 7za.exe x -y -aoa %SYSTEMDRIVE%\DriverPack*.7z -o"%SYSTEMDRIVE%" 7za.exe x -y -aoa %SYSTEMDRIVE%\000_AllUsers.7z -o"%ALLUSERSPROFILE%" 7za.exe x -y -aoa %SYSTEMDRIVE%\000_WinDir.7z -o"%SYSTEMROOT%" %SYSTEMDRIVE%\SetDevicePath.exe %SYSTEMDRIVE%\D START %SYSTEMDRIVE%\WatchDriverSigningPolicy.exe EXIT Also of possible interest, I'm currently putting together a complete RIS walkthrough for the uAwiki, including BTS, RVM, nLite, XPize for RIS. I've been neck deep in RIS for a few years now so hopefully all of my experience will help others. Stay tuned..

I agree with Nilfred. Plain RIS combined with app deployment via GPO sounds exactly like what you need. I chucked Ghost years ago as it no longer serves a purpose. So as far as RIS itself goes, I don't think you need to be messing around with any HAL files or filters.

Once you do integrate the update, if you value your privacy as I do, you can effectively disable WGA with the following registry entry: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{17492023-C23A-453E-A040-C7C580BBF700}] "oldFlags"=dword:00000000 "Compatibility Flags"=dword:00000400

@ravashaak, I appreciate the ideas and the insight. One thing I have always tried to do is make one master policy that is, for the most part, suitable to several clients. I may give your method a shot and see how comfortable I can become with it. Perhaps an improvement to what you currently do would be to stick in some pRules for those applications you do NOT want to give access to (Kazaa, etc.). Which brings up another idea.. Have you ever messed around with adding host names to the restricted zone? If I understand correctly, anything in the untrusted or restricted zone (talking SCS not IE here) would get literally no access. Meaning no cookies, scripts, ActiveX, etc. A frustrating limitation I have run into is that it does not seem to accept wildcards. For instance *doubleclick* . Being able to implement a blacklist of that type directly into SCS would sure solve a lot of issues right off the bat.

Well I've figured out quite a bit more on how this works, but I'm still not happy. Perhaps this is a bug, I'm not sure, but I cannot get a pRule to match an executable based on file property data. Using a required digest has always worked and is arguably the most secure method to use, but the amount of labor involved to keep all of the digests up to date is just too much. Using the option "Any Version" lets the executable use your defined rules but it is hardly practical when the executable is named setup.exe or some other generic name. In the end, I have this thing working well enough for existing clients who are already invested in the product, but I could hardly recommend it for future considerations. The SAV client seems ok enough. It used to be rock solid but in the last couple of years Symantec just seems to make the product worse and more unreliable than the last version. It's really sad to see a product I've loved for so long turn to complete garbage.

Try doing a manual RVM integration and don't use nLite at all. If that works, nLite it. If that works, then add BTS DPs. It's all one step at a time to find the problem.

This used to happen to me during manual integration of RVM. Triple check that you made no mistakes in your txtsetup.sif and dosnet.inf entries if you did a manual RVM integration.