RogueSpear

@durex Yes, you can throw it into RunOnceEx. In fact my RunOnceEx is nothing but a series of VBscripts, about 10 of them I believe.

@durex If you notice the script looks for the network connection that is named "Local Area Connection". It should change only that one network connection, not all of them. I've run this script on literally dozens of different computers now (if not hundreds) and it has worked every time. Check and see if you changed something. As an example, I have one computer at work that has one NIC, one 802.11g adapter, VMware, Cisco VPN Client (which makes a virtual NIC), and firewire; it worked as expected and only turned on the one 10/100 NIC labeled "Local Area Connection". Off topic - I never received an email notification that anybody responded to this thread which is odd. I just happened to search for it so I could reference it in another thread. Anyone else experience this kind of thing?

I posted a script a while ago that does this and additionally, it renames the "Local Area Connection" to whatever you want, and disables NetBIOS from all interfaces, including from firewire. Something you need to keep in mind is that WMI is not available yet when cmdlines.txt runs. So you need to run it later. http://www.msfn.org/board/index.php?showto...hl=network+tray

One nice freeware program that I implemented once is eDexter. This program is meant to take the place of an ad blocking HOSTS file. It's basically a small proxy. The configuration can be a little tricky at first, but this program is really fantastic for a freebie. It's configuration file works similiarly to a hosts file but you can use wildcards in the entries, explicitly allow or deny, etc. There are no registry entries with it, just it's own config files. And there isn't the overhead and slowdown that you experience with some of the 20,000 plus entry hosts files that are available. Highly recommended for those not using a software based firewall and adblocker.

I suppose I forgot to mention one of the more important things while on this topic. One of the reg keys that Spywareblaster populates is actually a list of web sites to be put into IE's "Restricted Zone." Unfortunately, even in SP2, the default configuration for the restricted zone leaves a couple of holes open. What I do is go in there and make sure "Disable" or "High Security" is selected for everything. This can also be accomplished via importing a reg file. EDIT: To those using IE-SPYAD.. I gave up on this product a long time ago. As comprehensive as it is, it simply broke too many web sites. This includes Yahoo and MSN, and that is unacceptable to most of my clients. Further, in reviewing the list of sites supplied by Spywareblaster, I was perfectly satisfied with that list.

1.) Like it or not, Internet Explorer is indeed rather interwoven into Windows 2K/XP. So it would definately be in the best interest of everyone using Windows 2K/XP to take advantage of these registry entries. If you want to use Spywareblaster and Spybot S&D, all the better. 2.) Has anyone here tried to deploy and manage Firefox in an enterprise environment? And felt it was worth the effort? Didn't think so. 3.) The license agreements to both Spybot and Spywareblaster leave me wondering if you can deploy them en mass. So the next best thing is to take the registry entries and import them. I've even implemented within a machine startup script written in VBscript, a routine that checks for updates by way of a seed file and updates the registry as necessary. So all I have to do make a new registry file once a month and put on the server. The next time all of the computers reboot (think patch tuesday), they get the updates. 4.) In the last year, using nothing but Internet Explorer, Spybot and Adaware have found nothing. It's all in the configuration, using Symantec Client Security V2, Spybot S&D, Adaware, and a little common sense. I think too many people are lulled into a false sense of security because they use Firefox or Opera.

For quite some time now I have been combining the reg entries made by Spywareblaster and Spybot S&D into one large reg file and I import it in during the cmdlines.txt phase of the install. If you really wanted it integrated in you could use Nuhi's RegHive application and put all of the entries into an inf file (like nLite.inf). Basically you want to grab the following registry keys: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\P3P\History] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Ranges] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains] This will get you all of the protection from both apps (the innoculating part anyway). EDIT: I would love to see Nuhi put this into nLite or RyanVM put it into his Update Pack. I'd even volunteer to do the monthly updates of it.

While the definitions are indeed updated daily, Symantec recommends that you use the "release" updates that are put out weekly or bi-weekly (I forget now). The daily updates can have virus definitions that are so new that they have not undergone the appropriate testing. So they're more or less considered for the advanced user.

You need to have a Platinum support contract to get it.

We got some anger issues here?

@BTS I have a location with LOTS of Matrox G400 and G450 cards. There isn't a control panel applet that I'm aware of. One of the things that I have always liked about the cards is the drivers. I've never had any issues integrating them into my RIS installs and their dual screen support is flawless. An excellent card for business use.

I haven't gotten around to fiddling with this yet (actually I'll be using SCS V2.03.1000). Can anyone tell me if this build fixes the pagefile.sys bug?

Just a tip here.. for months I was doing my searches by using the Google search at the top of the web pages. I found that I get MUCH better results using the search box that is at the bottom of the pages that contain the list of threads. I don't know why it took me so long to figure this out, but then again I don't know why that search function isn't placed near the top also instead of at the bottom of the page.

Here's a script I wrote that takes care of all the account chores. It renames both the Administrator and Guest accounts, strips out their descriptions, creates a fake Administrator account that has the description and belongs to the guests group, creates what you want your real admin account to be, and finally, deletes the extra user names that are created by default. One note: The "Debugger Users" group will only exist if you are joining a domain. Option Explicit On Error Resume Next Dim wn, objReg, sysdrv, strComputer, strPath, objComp Set wn=WScript.CreateObject("WScript.Network") Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & "." & "\root\default:StdRegProv") strComputer=wn.ComputerName strPath=("WinNT://" & strComputer) Set objComp=GetObject(strPath) '********************************************************************** '** Subroutine; Process the built-in Administrator account ** '********************************************************************** Sub ProcessAdmin Dim objUser1, objUser2, objGroup1, objGroup2, flag Set objUser1=objComp.GetObject("user","Administrator") Set objGroup1=objComp.GetObject("group","Debugger Users") Set objGroup2=objComp.GetObject("group","Guests") objGroup1.Remove objUser1.AdsPath objGroup2.Add objUser1.AdsPath objUser1.SetPassword "password1" Set objUser2=objComp.MoveHere(objUser1.ADsPath,"Jerry") objUser2.Description="" objUser2.SetInfo If objUser2.AccountDisabled="False" Then flag=objUser2.Get("UserFlags")+2 objUser2.Put "UserFlags", flag objUser2.SetInfo End Sub '********************************************************************** '** Subroutine; Process the built-in Guest account ** '********************************************************************** Sub ProcessGuest Dim objUser1, objUser2 Set objUser1=objComp.GetObject("user","Guest") objUser1.SetPassword "password2" Set objUser2=objComp.MoveHere(objUser1.AdsPath,"Kramer") objUser2.Description="" objUser2.SetInfo End Sub '********************************************************************** '** Subroutine; Create and configure a new Administrator account ** '********************************************************************** Sub NewAdmin Dim objUser, objGroup Set objUser=objComp.Create("user", "Dave") Set objGroup=objComp.GetObject("group","Administrators") objUser.SetPassword "password3" objUser.FullName="David J. Doe" objUser.SetInfo objGroup.Add objUser.AdsPath End Sub '********************************************************************** '** Subroutine; Create and configure a fake Administrator account ** '********************************************************************** Sub FakeAdmin Dim objUser, objGroup, flag Set objUser=objComp.Create("user", "Administrator") Set objGroup=objComp.GetObject("group","Guests") objUser.SetPassword "password4" objUser.Description="Built-in account for administering the computer/domain" objUser.FullName="" objUser.SetInfo objGroup.Add objUser.AdsPath If objUser.AccountDisabled="False" Then flag=objUser.Get("UserFlags")+2 objUser.Put "UserFlags", flag objUser.SetInfo End Sub '********************************************************************** '** Run Tasks ** '********************************************************************** ProcessAdmin ProcessGuest NewAdmin FakeAdmin objComp.Delete "user", "ASPNET" objComp.Delete "user", "HelpAssistant" objComp.Delete "user", "SUPPORT_388945a0"

I've always used RunOnceEx to run programs from the CD/DVD. I use VBscipt instead of batch, but it's essentially the same process. Determine the drive letter and away you go. What I do is actually put a VBscript in the ROE entry and that script installs software from the media. Option Explicit Dim fs, objService, objSoftware, Drives, Drive, strFiles, errReturn Set fs = CreateObject("Scripting.FileSystemObject") Set objService = GetObject("winmgmts:") Set objSoftware = objService.Get("Win32_Product") Drives = Array("C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", _ "R", "S", "T", "U", "V", "W", "X", "Y", "Z") For Each Drive In Drives If fs.FileExists(Drive & ":\WIN51") Then strFiles = Drive & ":\EXTRAS\" Next '********************************************************************** '** Run Tasks ** '********************************************************************** errReturn = objSoftware.Install(strFiles & "\Adobe Reader 7.0.msi", , True) errReturn = objSoftware.Install(strFiles & "\Camtasia Studio.msi", , True) errReturn = objSoftware.Install(strFiles & "\FFDShow.msi", , True) errReturn = objSoftware.Install(strFiles & "\J2RE5.0_1.msi", , True)

Whenever it's feasable, I push apps out via GPO. One of the main reasons for this too is that you can rather quickly uninstall a particular app or patch it for that matter, enterprise wide. There are those apps where a GPO isn't possible or practical, and for that I use the machine start up script. Then I ran into a doozy a couple months back. I needed to push out a very custom VPN-type of application. I say type because it's not truly a VPN connection, but it's using token/smartcard authentication for web site access. Anyway, try as I might, I could not package this thing into an MSI package (the first time out of literally dozens of apps). So seeing that it was an InstallShield routine, I made up a silent response file and implemented the whole thing into a startup script. Don't you know it wouldn't run at all. Having tunnel vision at this point, it took me a little while to realize that this was a 16-bit InstallShield routine. Well the 16-bit subsystem isn't intitialized in time for the installer to run from the machine startup script. Ooookay, so now in desperation, I plop it into the user logon script and sure enough the users don't have the rights to install the app. So I did a little bit of searching and found CPAU (Create Process As User) which allowed me to run the install as a user with admin rights. The utility supports encoding of passwords too, so you don't have to worry about someone opening the script file and seeing the password in plain text. This is completely off topic - I found it interesting that this application used a 16-bit install routine. My guess is that this was to facilitate compatibility with Win9x operating systems. Now anybody who uses this application has to be fingerprinted, complete and pass a background check and polygraph, be bonded, etc. (including me since I administer it at one location). So I find it curious that this application is allowed to run on such a fundamentally insecure OS. There's always something that makes me wonder.. everyday..

What I usually do in situations like this is open up a small IE window and format the text appropriately. You can even throw in an animated GIF if you like. I'm on the road at the moment but will post some code in the morning if you are interested. Oh yea, the last thing the script does is close out the IE window.

Try using NirCmd. I've yet to have it fail me with changing resolution. There's another utility here somewhere that does nothing but change resolution and I have not had good experience with it.

I believe he is going to be putting them in the next release. As a side note, I was able to integrate them without any problems. I'm mobile at the moment so I can't look up the thread, but there is a guide for doing exactly what you want to do. Try a search.

Take a look at BTS's driver pack discusion thread. In there I descibe how I 7-zip all of my drivers and use DetachedProgram to decompress them at T-39. I also use this method with RIS. This way I'm moving 1 file that's close to 100MB instead of thousands of files totaling more than 340MB. It works too, been using this method for about 6 weeks now.

That may be true and I know it's what M$ and all of the installer companies tell you, but there are times when you simply cannot accomplish what you need to do without doing a direct edit. And to be honest, sometimes it's just a lot easier to do a down and dirty msi edit intead of generating a transform. Just keep and original of that msi for backup.

@BTS I didn't know that issue with the infs and driver signing. I'd say that sort of puts the kabash on the whole thing. I don't know all of the ins and outs of inf files so if this seems like a question of ultimate stupidity please forgive me. Can you have one inf file call another inf file? I sort of have a half baked idea of having a master inf file for the driver packs so that a PnP detection would first "see" the device in the master inf which would then call on the *real* inf file. If this were possible, could you then have all of the drivers stuffed into a cab file? Would this then maintain the driver signing since you're not modifying the original inf? I know this is pie in the sky sounding, but as I said I really don't know everything that is possible with inf files.

No offense, but I've always thought that Method 2 is pretty whacko Still, for me, the ultimate solution would be having a BTS.cab file with the associated information in the driver index file. This would pretty much make all the trickery of shimming the drivers in moot. But the best part would be having the drivers remain available after the install and in a compressed format. For those of you who have ever watched Monster Garage - "it must appear to be stock" is the phrase I am thinking of. I am not familiar with how nLite integrates drivers since I do use it for this purpose, but am I correct that they are put into the drivers.cab? It makes me wonder if some sort of collaboration could be done, much like Ryan did with his Update Pack.

I forgot to mention in my previous post something that could throw you off a little. Before BTS changed the driver directory from "Drivers" to "DP", I was using a search and replace to change my WINNT.SIF so that "Drivers" became "D". So the following line: Start /WAIT %CDDRIVE%\OEM\7za.exe x -y -aoa %CDDRIVE%\OEM\Drivers.7z -o"%SYSTEMDRIVE%\D" should be: Start /WAIT %CDDRIVE%\OEM\7za.exe x -y -aoa %CDDRIVE%\OEM\Drivers.7z -o"%SYSTEMDRIVE%\DP" Since it's only one letter difference now, I'm going to stick with DP.

This was something I mentioned in one of the (former) stickies a while back. In fact I think it's still the final post in that thread. When I investigated this myself, it does seem rather simple at first glance, but I have a feeling that there just has to be more to it. One example I can think of off the top of my head are the RealTek NIC drivers. The drivers that come from RealTek, from two years ago until the present, are simply atrocious. They don't initialize in time to properly authenticate a domain computer to a domain controller. And no amount of reordering service startup sequences seems to fix it. The solution? Use Microsoft's provided drivers. They actually do work. So the moral of this longwinded story is; how do you determine when to keep MS's supplied driver or use the new vendor supplied driver?