RogueSpear

There's more to it than just sniffing packets. If you're performing DNS resolution on that server you mentioned, then the DNS records on that server will give up a bit of information on sites you've gone to. If your network sits behind any sort of router, firewall, proxy, etc. there is the possibility that a syslog daemon is running recording all of that information too.

Well my love affair with Hamachi has ground to a screeching halt. I've been trying to connect to the network now for a couple of hours. It keeps telling me that the volume is too heavy or something like that. This blows.

I tried this out on a few .iso files that were around 700MB. One was a CBT title full of .avi files, the other was of many smaller mixed file types. In both cases the resulting archive file was significantly larger than what 7-Zip produced and it took in the neighborhood of 20 to 30 times as long to do it. No thanks..

I don't remember for certain, but I believe that's the default behavior in an AD environment. There is a group policy setting for this which you should apply at the domain level. I'm going to assume you're referring to .SIF file in \Templates. Find the file deploy.cab in the support directory on your Windows XP CD. Decompress the .cab file and you'll find a couple of .chm help files that detail everything you can put in there. Alternatively, I'm sure this information is readily available on Microsoft's web site. Unless you have SMS or something similar, then yes, you'll probably want to deploy any software packaged as an .msi file through group policy at the OU level. If you look at the final script, I wipe out all of the autologon stuff from the registry. This can be done in group policy.If you need a crash course on administering and maintaining a Microsoft based network, and I think you might, I would suggest buying and reading in it's entirety Mastering Windows Server 2003 by Mark Minasi. You will not find a book on this topic that is easier to read and understand than this. I cut my teeth with Windows Servers by reading his Mastering Windows 2000 Server book. I read the whole thing, over 1500 pages, in about a month and it pretty much changed my life. http://www.bookpool.com/sm/0782141307

If you don't want to run a certain script, just leave the script out of your install and everything will still run just fine. If you don't have VPC or VMware installed, AutoRIS will simply not run them. It does a check to see if they're there. You can place ntregopt.exe in $OEM$\$$ or $OEM$\$$\System32. Or alternatively you could put it in the 000_SRoot.7z file and it will be decompressed by presetup.cmd. I'll be refreshing AutoRIS shortly with updates to some of the scripts that should aleiviate any of the problems with autologon and passwords.

Two things: first, you would probably be better off running the Java installer from svcpack.inf. Second, there is a bug in there relating to the custom actions at the 200 level. I'll be releasing a refresh shortly that addresses that issue and a couple of others as well. Just trying to tie up some loose ends and test everything properly. Ok I lied, there's three things - here's the third.. if you do decide to run the installer by making an entry in the 500_Settings.ini file, you will need to place the installer in $OEM$\$1.

It almost sounds as though something is wrong with the switch, I mean other than a config issue. I don't know my way around Dell switches either, but maybe you could poke around and view the switch's ARP table, etc to see if there is anything else that doesn't make sense.

I did have an installer up for both Microsoft AntiSpyware and for Windows Defender, but I made a decision that I'm not going to distribute any installers that require a WGA check in order to download from Microsoft. I just don't need the grief. Besides that I think Microsoft would have frowned upon how I managed to make Windows Defender installable from svcpack.inf (you can't normally). The installers that I have on here now will get updated when I'm able to do so. Any spare time that I have outside of work and clients has been spent lately programming. The other thing is that repacking apps is very mouse and keyboard intense and I've been having a great deal of problems lately with my right arm. Crap Cleaner is definately at the top of my list however.

Sonic posted pretty much exactly what I had in mind. My last post was just before my eyes slammed shut, so I had planned on posting it this morning.

I'll see what I can do with that.. I think all I really have to do is remove the part of the script that disables that account. I'm already renaming it now.

This is something my script pack does. Actually it disables the Administrator account which is preferred. But if you would rather rename it, I could retool the script to do that as well.

Well by default anything in the restricted sites zone cannot run ActiveX code or script. Perhaps my wording was off or could have been misleading, but the end result is that anything in the list from post #1 will show as being a restricted site down in the status bar of IE. If your restricted sites settings are the default, no downloadable code will run.

I was pretty much in the same boat as you and in the end I just said screw it and went ahead anyway. I figure saving $65 a month should make up for the $250 I spent on new phones before too long. The other consideration for me was that my cable modem went down maybe two times in the last seven years, where my phone line went down probably a dozen in the same time. So here's a good laugh - as soon as I disconnect my landline, some small animal ate through my cable line

I ended up going the route of buying a Panasonic base station that can have up to seven satellite phones. The base comes with one handset and I bought one additional. That's plenty really - one for each floor. At the VoiP adapter itself I plugged in a two way splitter, one to the cordless phone base and one to my HP OfficeJet for FAXing. It's all worked out pretty good so far saving me about $65 a month compared to the Verizon landline plan I had previously. I have the Linksys PAP2 plugged into a WRT54. I enabled QoS giving the PAP2 highest priority. Since I did that my wife hasn't complained at all about the quality of a call.

The block list will in fact prevent you from running any ActiveX or script code from the domains contained in the list. That's the whole idea of "Restricted Sites" zone functionality. And since Avant runs the IE core, it will be effected just the same as IE itself. And yes, the list does alter IE Security settings, it just does it in the HKLM meaning the settings won't appear in the control panel applet. But the method is the same. Anybody using this list should actually look at their Restricted Sites settings. All of the misunderstandings would be cleared up rather quickly.

I'm pretty convinced that there is a bug in makecab.exe. I've had similar errors on my laptop, but never on either of my two desktops. I even get the error on my laptop since having reinstalled XP. The only major thing I can think of is that my laptop shares system RAM for the video adapter. It's pretty distant from being related to a command line application like makecab, but I can't really think of anything else that is fundamentally different between all of the systems. I can't remember the exact filename now, but it always happens to me with a certain file in the unofficial DP Broadband. EDIT: Just thought that I would add that I get the same problem when I access MakeCab through COM in a VBscript, but again only on my laptop. So I'm guessing that makecab.exe utilizes the same COM object.

The third party utility usage is described in the script pack thread. I would distribute them with the script pack, probably in the form of an RVM addon, but the EULA for SysInternals just got rather restrictive. In the next Script Pack release and AutoRIS release I'll be setting the 500_Settings.ini file to not use them by default. This way users will have to read the directions and enable them on their own.

I've gotten the same error before during the Method 2 decompression of the DriverPacks. Most problematic for me have been HP-Compaq notebooks with AMD CPUs on VIA chipsets. They even have 384MB RAM in them. I think it's just the lousy VIA chipset.

Judge did a way better job of explaining it than I ever could. And yes, typing with one hand and mousing with the same one hand is slowing me down a bit. Especially since Dragon is virtually useless when you're programming. EDIT: Looking back on it, I can see where my previous post would have made for some major confusion. The DriverPack .7z files should end up in $OEM$\$1 in your RIS image after AutoRIS is run. However, you will need for them to be where Judge described when you run AutoRIS.

Integration of NIC and mass storage drivers for bootup in RIS is completely different than integration for the PnP enumeration stage of setup (during the GUI portion of setup). Now I'm not saying this as a slam or anything like that, but based on your previous posts it seems that you haven't read the AutoRIS instructions too thoroughly and you don't have to clear of an understanding of RIS or integrating device drivers. That's fine, we all have to start at the beginning. It was only about a year ago that I was struggling with this stuff too, but reading the instructions would have saved you a little bit of grief here. Now as best as I can tell you're doing most of this right. There should be a file in your AutoRIS directory named RogueSpearAddonsM2_1.3.cab. This is an addon for use with either the RVM Integrator or nLite. It places the files in i386 needed for a Method 2. It also makes changes to your txtsetup.sif and dosnet.inf files. Needless to say it's an integral part of a Method 2 with AutoRIS. Your DriverPack .7z files should be in $OEM$ and it sounds like you have this part down already. AutoRIS will copy WatchDriverSigningPolicy.exe and SetDevicePath.exe to $OEM$\$1. These are also necessary files as part of a Method 2 integration. If all of this stuff is in place, then your driver integration should work as advertised. Keep in mind that the DriverPacks are a project that will never be finished. There is an endless amount of hardware devices out there. So if something doesn't install here or there, that's to be expected. You may have to manually install the device later. I would highly suggest that you do a lot more reading here and over at Ryan's forums. For the most part this stuff isn't too difficult, but there is a lot to know. If you've gotten this far mostly on your own, figuring stuff out, then you should have no problems at all once you've caught up on reading about these things.

A lot of consumer grade routers support restricting time of use. Nearly every Linksys I've come across does.

This is something I looked into extensively about a year ago and I came up with nothing. I couldn't even find any discussion anywhere about it. This is why I always offer the single .msi file for download in my installers thread.

$OEM$ should be at the same level as i386, not inside it.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "DefaultUserName"="RIS-Autologon" "DefaultPassword"="mySuperDuperPassword" "AltDefaultDomainName"="myDomain" "DefaultDomainName"="myDomain" "ShowLogonOptions"=dword:00000001 "AutoAdminLogon"="1" In my experience adding the entry AltDefaultDomainName clears up autologon issues.

You need to decompress the BTS Base file and put your driver packs in the \DriverPacks directory as normal. Basically you want to have the DriverPacks ready to use as though you were going to use them in the intended fashion. So in your AutoRIS.ini file you should have something similar to this: BTSPATH=C:\BTS_DriverPacks_BASE_V6034 AutoRIS does indeed perform most of the DP integration on it's own, but I made it grab the mass storage integration batch file, modify it on the fly (to future proof it), and then run that silently.