RogueSpear

I'll be danged.. it is showing on US VLK. Wonder if this is something that can be directly integrated. It looks as though this does not cover Office (though Office is indeed updated through Microsoft Update). Also, it doesn't show up on W2K servers, how about 2003 Server?

Interesting.. I haven't seen this yet, but the only workstation I've had my hands on the last few days are VLK. I'm wondering if this is going to be limited to Pro and Home. Also curious if it will show up on the SUS and WUS products.

There is just NO WAY that V10.0 went through even a modicum of quality assurance before it hit the shelf. If I didn't know any better I'd swear this was a government operation. Just today I was discussing the situation with a fellow that I do some consulting with. He deployed V10.0 at a rather large law firm and ended up taking down several hundred workstations for the day. Another Symantec customer lost. They may not be around as long as you think.

In my testing on a wide variety of machines, Method 3 is no longer working due to the speed of the driverpack decompression. Simply put - device detection begins prior to all of the DPs being decompressed. This fact alone means we cannot use SetDevicePath.exe since the registry entry MUST be set prior to device detection. OemPnPDriversPath character limitation has been exhausted, at least in my case. I'm using a custom DP in addition to the BTS DPs. And what this means is that SetDevicePath.exe will need to be used for Method 1 too.

SAV used to be Symantec's last shining star. Sadly it seems they have managed F that up as well. I fear the horror of what they will do to the Veritas line of products now.

If you're using RIS have you considered simply prestaging the workstations? One benefit is that you can avoid a lot of this scripting when it isn't really necessary and you can also put the workstation in the appropriate OU, again without scripting. Don't get me wrong, I'm a VBscript freak of the highest order. It just doesn't seem appropriate here. If anyone is interested, here is a script I wrote to change the name of the computer to PCYYMMDDHHMM. The italics denoting year, month, day, etc of when the operating system was installed. I tend to use this strictly in NON domain environments. Sub RenameComp Dim strName, strComputer, objWMIService, colComputers, objComputer, Err strName = "PC" & Year(Date) & Month(Date) & Day(Date) & Hour(Time) & Minute(Time) strComputer = "." Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colComputers = objWMIService.ExecQuery("Select * from Win32_ComputerSystem") For Each objComputer in colComputers Err = ObjComputer.Rename(strName) Next End Sub

I've all but completely lost faith in Microsoft AntiSpyware after the recent sillyness involving Claria (Gator). It was bad enough that MS downgraded the threat level of this slime, but then their reaction to the whole thing when they were called to the carpet on it showed their true colors. Also I have seen so many conflicting reports on whether or not MS AntiSpyware will remain free or become commercial after it leaves beta that I don't know if I really want to become dependant on it now.

One little tidbit I discovered in a home environment (non domain) is that you must have passwords set for all the users. If you try to authenticate using a credential that has no password it won't work. In an environment where security truly does not matter at all I always use the word "password" as the password. It's almost impossible to forget that one.

It sounds as though you have other clients logging into the domain without any problems? If so, consider the following: - Are the successful computers in the same OU and using the same GPOs? - Are they all hitting the same DHCP server and getting the same settings? Same DHCP scope? - Are you using the latest Intel NIC drivers? Some of the newer Pro100/1000 NICs really seem to benefit and sometimes require the latest drivers. - Check the domain controller's event log to see if there are any events describing a failed login attempt.

I have officially given up I created a firewall policy completely free of all pRules. In fact in the general rules, I created one master rule that allows all TCP/UDP traffic over all ports to and from any computer. The only thing I left in there were the ICMP rules since they seem to be "special" in the eyes of Symantec. It's funny how a computer is actually more secure running in this fashion than with a policy that contains far more restrictions. I've searched high and low, put Google through a pretty good work out, but all I've been able to find online is help for running the SCS3 client in an unmanaged fashion. Anybody have any opinions on an alternative product to this POS? I'm all ears..

I've had this happen a few different times to me and it almost always boils down to a failure to authenticate to the domain which will make something wait for a timeout. The one that gave me the most grief ever involved laptops using a RealTek NIC. The short story is that drivers from RealTek for their NICs do not initialize in time for the machine to authenticate itself to the domain. So in my case the delay was the computer trying to find and run a machine startup script as defined in a GPO. Actually the entire process of attempting to process the GPO is riddled with timeouts. If your machine properly gets a DHCP lease and is otherwise on the network, just not authenticating, it will have to go through all of these different timeouts because the OS sees that it's network connected. If you pull the CAT5 cable, it knows that it's offline and will behave as such. BTW if you are having difficulties with a RealTek NIC like I described, the solution is to use the MS supplied drivers. Never could understand that one... good luck.

Something I tried recently on a smaller network was to take a really old good for nothing computer and just set it up as sacrificial lamb in the DMZ. Mind you it's running XP SP2 with all of the patches and updates so that it won't get taken down immediately. But it gives the kiddies something to mess with, generally drawing attention away from what matters. There's all sorts of other things you can do as well but that would involve a rather lengthy reply, not to mention an endless debate on what's better.

I was soooooooo tempted to vote for the failure only list. I guess I'm hoping that a success list will lead some to actually check it. Can the Wiki list support both a success and a failure listing?

Glad I could be of assistance

Because it's what the client has invested in and is using. Now I'll be honest and admit that I got one client stuck with this product. I had always like SAV quite a bit and they were already SAV subscribers. Well they decided that they also wanted the firewall component so they got SCS. For the most part I really do still like SAV over the competition, but the incredibly, unbelievably poor tech support and responses that I have received from Symantec, have really shook my confidence in them as a whole. I have pointed out issues to them only to be rebuffed as supposedly not knowing what I am doing. And when I present what amounts to a thesis on the issue, documenting the problem and possible solutions, I'm told either nothing at all or a curt "we'll look at it." I finally stopped calling them altogether as the Mickey Mouse development shop they got going on was too aggravating to bear.

I've been using SCS for a few years now with several clients. After wrestling with the firewall policies and SCFA for what must be months on end, I've finally given up and I just created a policy that is balls out wide open. I figure that for now at least the clients are getting the benefit of IDS and ad blocking until I figure this thing out better. If you've ever used this product then you know that the supplied documentation and online help are all but worthless. So my question is... Does anybody know of a decent online resource or support group for this product? I've done some looking around but all I find are people having the same issues that I have (with no answers). Specifically I am having huge problems with pRules. I've essentially given up on using required digests as file versions change. So I wanted to start using file properties, even though it's less secure. Well this works with some files and not others. There's just no rhyme or reason with half the crap this program does. And it only seems to get worse with each new version.

Not trying to be a smartass here, but what's the problem? If I better understand, perhaps I could help.

For the KtD option I had an idea I thought I'd run by you. Perhaps users could have the option of either keeping ALL the drivers or just those that are commonly removeable devices - USB, Firewire, PCMCIA. For the latter option I was thinking perhaps a tag file could be stored in the directories of those drivers to keep. A 0 byte file named KtD.tag for instance. This would also make it pretty easy for users to tag whatever additional drivers they see fit just by copying (or creating) that tag file in the directory of other drivers. I think that checking for the presence of a tag file would be easier than maintaining a text file list that would need to be read in by a script. Probably would be more reliable as well.

In my first post I said that the DriverPacks in general are at the mercy of hardware vendors. And I stand by that statement. But I would like to add another; the DriverPacks are also at the mercy of the very members of this forum. There is no way that BTS could ever own every single mobo, mass storage controller, video adapter, etc. And there is no VMware type product to "emulate" all of these various hardware devices. So he relies largely on us to report errors and anomolies. And I have noticed that some are better than others at this process. I don't want to paint everyone with the same brush here. Those of you who know what your doing.. you know who you are. But for those not as experienced in the troubleshooting field, I'd like to offer a few tips that you may or may not have seen posted in other threads here. If you are having difficulties of any kind with the DriverPacks try the following: - Implement only the BTS DPs. Leave out nLite, XPize, Xplode, RVM, etc. The makers of all these fine works do have a certain amount communication with one another, but none of them want to go bug chasing not knowing whose project is to blame. - Having a problem with the Mass Storage DP? Then leave out all of the other DPs. Try to isolate the problem by eliminating the other DPs as a possible cause. Got your Mass Storage DP issue fixed? Ok, now add the others back in one at a time to determine if there is a conflict somewhere. - Always always always make sure you are using the latest versions and have read the release notes. Check out the documentation for the hardware that is giving you fits. Perhaps there is a setting in the BIOS you flipped on by mistake. Just remember that this is something we contribute to in our spare (rare) time. Nobody wants to make this all work more than BTS. And chances are he doesn't even have the stinkin hardware your using! And in my final remark of this insanely longwinded diatribe.. I have made some purchasing decisions based on what I read here. When I see two dozen people all having serious grief with [insert brand here] motherboard and mass storage combination, that's not what I'm buying. Vote with your wallet. It's about the only influence we can have with these hardware vendors.

@BTS I have to admit that this slice of the unattended world is not my specialty, so half of what you mention is foreign to me. I'm going to try to configure my adapter first as ATA, run your proggy, and then as RAID, and run the proggy.. see what I come up with. EDIT: Sorry this took so long. Real life got in the way. hwids.txt

So are the hardware IDs going to be the same no matter which version of the driver? I know that they will be different depending on ATA or RAID.. I'm at work now so I can't check the IDs at the moment, but I'll report what I find tonight.

Here is the link for Gigabyte's Promise drivers. I'm not posting the IDs directly because the download has multiple drivers. It appears that some are WHQL, while others are not. I don't know if you'd like to look at them in case one is completely the same as what you're using already with the only difference being the IDs. I can do some legwork if you like, I just need a little direction... http://www.giga-byte.com/Motherboard/Suppo...ver_Promise.htm

I got my jump on RIS using Mark Minasi's excellent reference Mastering Windows 2000 Server. I imagine that the follow up Mastering Windows 2003 Server also covers RIS. I've recommended this title in some other threads before and don't want to sound like a salesman or anything, but it really should be required reading for all Windows network admins. After getting the RIS basics down, this web site will definately be your best reference automating RIS as much as possible. I would say 90% of what you want to do with RIS is the same as if you were using optical media. The main difference being that you can leverage Group Policy for a lot of things.

Ok you've inspired me Now my wife is really gonna kill me. One more thing to take up my time

hmmm.. sounds like it would be dependant upon the screen resolution maybe? Like the coordinates would be different on an 800x600 than on a 1024x768 screen. Or is it coordinates based on the open window itself? If that's the case then maybe I will break down and figure this thing out.