RogueSpear

I imagine you could make a script to download (ftp) the updates at whatever schedule you like.

I have yet to learn AutoIt because so far I've been able to accomplish everything I need to do through VBscript and repackaging/direct .msi editing. But this one has me stumped: I have repacked SpywareBlaster into an msi file and it has the latest updates that were available at the time I made the custom package, but obviously it would be nice to automate an update at the time of OS installation. I don't want to schedule auto updates to run regularly because I get the feeling this would violate the EULA. Just a one time update so that when my OS install is complete.. it's complete. SpywareBlaster uses a non-standard interface. I believe it is mandatory that you use a pointing device in order to use this application. I have been unable to find any way to navigate via the keyboard. One can only assume this was done on purpose so that they can sell subscriptions to the auto update service. So can AutoIt manipulate this kind of application? I have nothing against AutoIt, but I don't want to spend a day or two checking it out only to find it can't do this one task - which is all I would ever really need it for. So I'm just wondering if anyone knows the answer off the top of their head. Thanks.

For years now I have been using RIS in favor of sysprep (or even riprep for that matter). For the last year and a half I have been using all of the tricks and techniques you would normally use for CD/DVD based installs and implementing them into RIS. The major differences with my RIS deployments are using GPOs to deploy applications instead of switchless silent installers and using GPOs for the majority of registry settings. If you take the time to do it right RIS can't be beat. You will have to put your share of research and experimentation however.

Ya learn something new everyday.. one of the things I love about this place. To the mods: I didn't mean to hijack this thread away from it's intended purpose - installing SAV unattended and preconfigured. Just needed to vent some steam. So with that said I'll keep any further comments on topic.

Just about every major AV vendor supports these fuctions to my satisfaction. I will concede that I feel Symantec is the best in terms of definition turn around time and the quality of those definitions. But I'm satisfied enough with the detection capabilities of all the other competing products. If you have your network, operating system, and mail client properly configured, the odds of getting infected are not so great. Spyware is the one form of malware that Symantec really lags behind in so I'll continue to rely upon standalone products, freeware and commercial, for that. The main problem I have with Symantec is managing their products in the enterprise. Plain and simple.. it sucks. Their documentation is sometimes worse than having none at all as it's often incorrect and misleading, nevermind being incomplete. They also keep on trying to load in new and more features without fixing the existing ones. Manageability is what I'm really looking for at this point in a corporate AV / firewall product.

Caution: Rant ahead. Skip this if you don't want to read something of a non-technical nature. I've been using both Symantec AntiVirus and Symantec Client Security for several years now. I feel as though I keep on using and recommnding it mostly because I'm familiar with it and quite honestly, because so many of my clients are invested in it and aren't likely to jump ship now. But I have just about had it with Symantec's Mickey Mouse operation. Everything seems to be a major hassle with this software. Sure it seems to work ok, but I've invested nearly as much time tinkering with Symantec's products as I have Windows itself. Just to make matters worse, I always seem to be educating Tech Support about the very products they are supposed to be supporting. Why in the world can't anything be easy with them? Since version 1 of Symantec Client Security I have been lodging complaints with Tech Support that you are unable to terminal service into an SCS client without the ccapp.exe thread pegging the CPU at 100%. The only "official" answer that I have received to date is "we aren't sure why that happens, but the programmers have been working on the problem for quite a while now." This was followed by an explanation of how the firewall portion of the client is not supported on Windows Server operating systems because of terminal services and that RDP with Windows XP is such a "new" feature that it would take a little while for it to be officially supported (this discussion was post SP2). If anyone reading this is a Symantec employee, I urge you to forward this to someone who makes a decision or two over there. At this point I am starting to actively research alternative solutions. I just can't recommend this product any longer. If it helps I'll use some fancy industry speak. The Total Cost of Ownership (TCO) is skyhigh for this product.

I think the entire project is at the mercy of the hardware vendors in terms of stability. There are those vendors who release bad hardware, bad drivers, and bad hardware with bad drivers. The latter seeming to be the most frequent. Analog Devices comes to mind first and foremost for me since they have spread their infection of substandard sound devices far and wide. But motherboard and mass storage makers seem to have an especially difficult time coming up with a stable solution. Part of the problem seems to be that they all are trying to make things as fast as possible with stability taking a back seat speed and features. I don't work for Intel, own shares in Intel stock, hell I don't even know anyone who does - but I never recommend anything to a client other than an Intel mobo/CPU combination. It's always been rock solid if not the speediest thing on the block. But then again my clients and businesses and government agencies. They aren't interested in playing video games. And I'm just about ready to make the drive to Canada to beg and plead with Matrox to bring back the G400/G450 dual head video cards. Easily the most reliable and stable video platform I've ever used. nVidia and ATI are laughable in this regard (I will admit to using an nVidia card at home for those video games though ).

I don't have the reference in front of me, but I remember seeing some info on doing this in Mark Minasi's Mastering Windows 2000 Server. I'm going to make an assumption that this would also be covered in the more recent release Mastering Windows 2003 Server. As I recall it wasn't a too in depth look at the topic but enough to get you going on it.

Just a suggestion.. if you have any RealTek hardware in your system and you're getting blue screens, eliminate those drivers first in your testing. Once things are going smooth, then reintroduce them into your install. In my experience RealTek sound adapters and NICs have always caused a ton of grief for me. So much so that I permanently wipe out the RealTek NIC drivers from DP LAN and let the install use the MS supplied drivers.

I should never have doubted you Sensei lol.. Method 3 was working for me quite well when everything fit within the limits of 4096, but that seems like an ever more impossible limitation to meet.

Something I would love to see, and no I don't have the know how to do it, is to have a KtD routine the picks out the drivers for only those devices which are USB/FireWire/PCMCIA based. Is there anything identifing within an inf file that specifies if a device is USB based, for example? That would make it so you could have all the logic within a script instead of having to maintaining a list of devices that qualify manually.

Well I've finally gone over to the dark side. I'm using Method 2 now. I had never liked the idea of using a hacked setup.exe, but after tooling around with it more, I'm much more comfortable in the process. It seems to have matured considerably since it's Pyron first posted this method. On the other hand... I'm beginning to seriously think that Method 3 may need to be retired after it's brief appearance. I've done extensive testing on a number of machines as this was always my personal favorite method. There's two main problems at this point, the first of which also effects Method 1. The dreaded 4096 limit in winnt.sif. I have my own custom DP that consists of the smaller 3rd party DPs released recently and some of my own drivers as well. I combined directories as much as possible to cut down on the additions to the OemPnPDriversPath, but no love. I just can't get it under the 4096 limit. So I turned to the old Method 2 SetDevicePath.exe. So here's where the Method 3 problems come up. With the size and amount of drivers currently in the sum total of all the current DPs, plus the addition of a few more, the drivers do not finish decompressing in time since SetDevicePath.exe must must before any device detection begins. The benefit to OemPnPDriversPath was that decompression of the 7z archives was done in alphabetical order. So with the device path already defined in the winnt.sif file, you just had to make sure the chipset and mass storage drivers were among the first to be decompressed. Because the sound and video would surely be decompressed by the time the PnP enumeration got around to detecting them. Well unfortunately the two choices we have for getting things done via Method 3 are quickly reaching the end of the useful lives. In fact I would have to argue that Method 1's days are becoming numbered as we speak. There's simply too many drivers and too many vendors that put out one specialized set of drivers for each of their 9 dozen products instead of a set of unified drivers. Method 1, I believe, is going to have to adopt using SetDevicePath.exe from DetachedProgram (yes it works, I tried). But if you want maximum space savings on your distribution media, bow to the Method 2 Gods

I looked into this a little bit as I am contemplating purhasing the new Logitech Notebook Pro webcam (or whatever they're calling it, it's around $100 USD). I downloaded Logitech QuickShare V8.4.6 build 1016A from their web site. This is a selfextracting exe file. Inside you'll find a few directories of drivers. The files all seem similarly named and it looks as though they may be uniqie to the various models Logitech sells. Either include all of them, or find the drivers appropriate for your friend's webcam and integrate the drivers using a method of your choice. They are all described at infinitum through this forum. If you are already using the BTS DPs, check out the sticky thread on making your own driver pack. If she's planning on using the Logitech Quickshare software, you will have to generate a .iss file as the install routine appears to be an Installshield. Again, this is described thoroughly in these forums. Best place to look would be the Applications Install forum. OT: Are these Logitech webcams any good? Any other suggestions before I blow a C note?

Nope, it mattes. At least in my experience it does. For the most part I use a VLK source and if I try to use a WINNT.SIF with a TabletPC key code it fails. I can't find the web site to save my life at this point, but I remember seeing an explanation as to how the whole key code / version thing works. The file SETUPP.INI, located in the i386 directory, has almost everything to do with it. For the time being I'm just maintaining seperate install media. I've tried all the tricks with optimizing the ISO file, etc.. and it's just more trouble than it's worth. Especially if you want a client to be able to restore one of their machines on their own.

Update: *.nls and *.ocs can be compressed as well.

I use InstallShield's AdminStudio for all of my repacking and modding needs. It's an indisposable tool that I use almost daily, but I am fortunate enough to have an employer that was willing to buy it for me. It's a very expensive tool, but I guess you get what you pay for. Just a little tip too.. I always use the manual 2 step snapshot method for repackaging. Don't be lured by all the automated stuff that they're newer one step feature touts. It's not nearly smart enough and it tends to generate packages with either totally bogus entries or with superflous crap you don't want in there anyway. And ALWAYS carefully inspect the files and registry entries the repacker has made prior to compiling your final .msi file.

My last post was pretty sloppy to say the least. This guide will assume at least a basic understanding of the RIS process and that you will know how to find further documentation about RIS. Let me step-by-step it: 1. Windows XP Gold CD slipstreamed with SP2 to make a good source. 2. Using your new SP2 CD, creat a RIS image on the server. 3. Create directory called RIS on a local hard drive of your desktop computer. 4. Copy the i386 directory from the RIS server to the RIS directory on your local workstation computer (where you have nLite installed). 5. Copy the tag files (WIN51, WIN51IP, WIN51IP.SP1, WIN51IP.SP2) from your SP2 CD to the RIS directory on the desktop computer. 6. I use jcarle's Compression Bin program (a Godsend) to compress all .inf and .pnf files to cut down a little on the network traffic when performing a RIS install and to also eliminate duplicate entries when integrating RVM Update Pack. 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_. Thus you will have two files for the same thing, but RVM's is more current. Here is a list of .inf files (and remember the corresponding .pnf file) that you should NOT compress using Compression Bin: BIOSINFO.INF DMREG.INF DOSNET.INF DRVINDEX.INF HIVECLS.INF HIVEDEF.INF HIVESFT.INF HIVESYS.INF HIVEUSD.INF INTL.INF LAYOUT.INF MSTASK.INF NTPRINT.INF SYSOC.INF WAVEMIX.INF 7. This step I have not finalized yet. Use Compression Bin to compress .sys files. Your RIS image will contain lots of uncompressed sys files. On a standard SP2 CD the following .sys files are NOT compressed and should not be compressed in your RIS image either: KSECDD.SYS NTFS.SYS SPCMDCON.SYS I have tried to compress the remaining .sys files but the text mode portion of setup failed. This was a couple of weeks ago, so I need to revisit the issue and determine what can and cannot be compressed for certain. I will post an update when that is finished. Or for the time being you can just not compress any .sys files. EDIT and UPDATE: I tried this again today and with compressing all .sys files except those listed above, it worked. My previous issue must have related to the BTS DP Mass Storage as it was a going through a bit of a transformation at the time. 8. Perform a manual integration of RVM Update Pack. I did test auto integrate using nLite V0.98 (maybe?) and a version of RVM prior to V1.2.1 and it worked fine. However nLite and in particular, RVM, have changed a bit since then so I don't know if this still works as it did previously. 9. Theoretically speaking, I imagine you could run XPize at this point, though I have not gotten around to using this at all yet, whether we're talking about UA or RIS. Simply have not had the time. 10. nLite the RIS image you copied over to <local drive>:\RIS. nLite patching for SFC and themes works as usual. To answer Nuhi's question, you can select manual install and upgrade files for removal. Removing language files, merging CAB files and higher compression of drivers also works without issue. 11. If you have a .sif file for your image, copy it over to the i386\templates directory. I always delete the default .sif file in \templates so it doesn't even show up as an option when you perform a network boot. In fact if your custom .sif file is the only one in \templates the user performing a RIS install will not even be given a choice of what image to install. This is nice to cut down on folks selecting the wrong image to install. 12. Completely unecessary and totally off topic, but I like it. I take Notepad2 and rename it to notepad.exe, send it through Compression Bin and plop it in the i386 directory to replace Microsoft's standard notepad application. It's freeware and I simply LOVE this program. 13. At this point I integrate the BTS Driver Packs using method 3. You will need to put the BTS DP 7z files in $OEM$\$1 on the RIS server and modify the batch that runs from DetachedProgram to decompress the 7z files from the root of your system drive. Normally in UA mode, BTS Method 3 will decompress the 7z files from the optical media, but this is not an option using RIS. Actually I recommend this method using optical media anyway since with a fast CPU, the archives will decompress faster from the hard disk and tie up the CPU enough so that they will finish decompressing prior to the Device Installation portion of the GUI setup. 14. Delete the i386 directory on your RIS server in the setup directory. Copy over the i386 directory from <local drive>:\RIS to the RIS server. In case it isn't obvious, you do not need to copy the tag files mentioned in step 5. 15. If you have clients using a pretty recent NIC from Intel, or possibly some other vendors, you will need to integrate the drivers in your RIS image. Look here and here for information on how to do it. After doing this, don't forget to restart the BINL service on the RIS server. Now attempt a RIS install for a workstation. It will most likely fail, but the idea here is to get the RIS server to create the .pnf file to go along with the .inf file of the NIC driver. Now you can send the .inf, .pnf, and .sys files through Compression Bin. Some of this may seem a little bit obsessive compulsive when it comes to cutting down on file size, but the way I look at it is that if you're going to be pumping out RIS installs to a few dozen workstations in the course of a day, you should do everything possible to make sure that the file copy portion goes as quick as possible and sends the least number packets as possible. Especially when you consider that after the OS setup is complete you will probably have a lot of applications being deployed via GPO. Now for my own personal problems... as you can see I have been around for a little while and I like to think that I can problem solve with the best of them. But lately I have been stymied by this dang framedyn.dll issue. At first I thought it was me improperly integrating the RVM Pack, then I thought I was removing too much stuff with nLite. Well now I just don't know what the hell is doing it. I never had this problem until very recently either (nLite V1.0 beta and RVM V1.2.2). Has anyone gotten to the bottom of what causes this error? It's killing me and has set me behind by weeks in my work. Any and all help would be GREATLY appreciated. I hope that the guide helps out...

I've been using nLite w/ RIS for several months now. First I make my RIS image from an SP2 source as usual, then I copy over the i386 directory from the RIS server over to my desktop computer. For the sake of completeness, I create a directory on my secondary hard drive (D:) named RIS. I copy i386 from the server to D:\RIS. Then copy over the tag files to D:\RIS. Run nLite. Delete the original i386 directory on the RIS server and replace with your nLited i386. Haven't had any problems thus far.

IMHO this seems more appropriate for inclusion with the DP Chipset. If I'm not mistaken, the ALi infrared controller is in there.

I can lend some VBscript skills if needed. I know there are some talented C++ programmers around here though. And that would probably be the better option if it presents itself. Anyhow, just let me know...

I edited the PhotoStory msi using AdminStudio and then made a 7z switchless silent installer. One curious thing though is that it will not install properly from svcpack.inf, I have to install it from cmdlines.txt. The other oddball that exhibits this behavior is the Windows Journal Viewer. Everthing else goes from svcpack.inf without any difficulties.

While I have used DAP from time to time myself, it has long been on the naughty list of several anti-malware vendors. I don't know what their current business practices are, but I remember that for quite some time they really walked a fine line between legit and spyware spreader. So if their products still raise alarms it really doesn't surprise me, even if they have cleaned up their act.

I just recently started to experience this issue. Using the latest nLite with the latest full RVM Pack. I always integrate RVM manually prior to running nLite. I know it's more work but sometimes I just like to get in there do things myself. All of the file entries (txtsetup, dosnet, etc.) seem to be in order before and after nLite does it's thing. I am wondering if the removal of any certain component with nLite is the cause. I think at this point, after four days of troubleshooting, I'm going to try nLite without removing anything at all. Just going to enable higher compression and merge cabs, which I realize is a little redundant with the RVM Pack process, but what the hell.

There are some freebies out there, though I don't remember at all what the names are. Try taking a peek over at AppDeploy, FileForum, or Softpedia.

That's one of the reasons that I always repack to msi too, but I also find that taking the msi and making AIP and then taking the AIP and making a 7z switchless silent installer yields the smallest file sizes for when you're installing from media. One thing you need to keep in mind when repacking Nero or some other CD burning software is that there will more than likely be registry entries made that specify the CD Burner. In the case of VMware it shows up as a NEC drive. You need to eliminate those reg entries before you compile your msi file. In fact I always thoroughly inspect the registry entries of every application I'm repacking prior to compiling. You'd be surprised what you find in there. Sometimes there are things that definately need to come out, other times there are a lot of completely useless entries having nothing to do with the software at all.