Stoic Joker

There is nothing on the market, that will protect you from everything, all of the time. Here's a "Golden Rule" for you, The first 10,000 - 50,000 people to encounter a new virus, will generally be infected by it. This is (why we have daily updates...) called response time. You are your own (best) first line of defence ... beyond that whatever you use is probable just fine. For those that just can't resist opening strange attachments there is (frankly no hope...) always the term Web Cattle I've grown rather fond of. I use Symantec Corp on XP, but it a bit flakey on Vista so I'm doing a bit of shopping for new options. I'm currently trying to decide between either Panda or MS's Antigen

Huh?!? How & Where is this "Network" printer connected (a true network printer should be direct IP), it sounds like you have the printer physically connected to the host machine (and shared) & the VPC is connecting to the share ... Yes? If that's the case, think DOS to find your answer. Capture the port on the Host Machine! net use LPT1 \\Machine\Share /persistent:yes Then let the VPC have access to the host's LPT1 No share access = no permissions needed = who cares how often the password changes ... All that is required is that the host machine has permission to access itself.

The site is down at the moment, but www.Windows-Now.com did bit on it that was full of links to information about it. There's also a piece there about PhotoSynth (Another new MS Technology)

Nice, but what about THIS Looks like they're up to 6 exploites now, 4 DoS and 2 remote code execution.

ALL Machines should (must) point only to the DC's DNS server. = Correct. The DC's DNS server should (must) have forwarders enabled to resolve (internet) DNS lookups for the rest of the network. The sticking point here is in Windows2000 you need to delete the Dot '.' Zone before the forwarders tab will be displayed, so you can enable DNS (lookup) forwarding for external (internet) domains.

Well... At least I'm not the only one that calls it a Thumb Drive.

While not exactly what you're asking for, I've been using X-Find by Xteq (www.xteq.com) to drill through large piles of log files. It doesn't give you thumbnails, but it will search all files in a given directory for a string of text, and then give you a list of files the string was found in. Clicking any of the files in the list will display the files contents on a viewer panel with your search text highlighted. It's a small, lightning fast, single file (no install required) utility that might be worth a shot.

Sounds like a typical corrupt Outlook profile issue to me. Back up their mail etc., then delete the Outlook profile in control panel then recreate it from scratch. Now sure how or why this happens but it seems to every now and then when you setup Outlook for the first time ... It just decides to Bork the profile.

Not exactly, but not the way you're thinking either. An AD domain has basically two states of operation, DNS is working fine, and all hell just broke lose. Hence the only DNS server the client machines are to use is the internal one running on your DC (192.168.0.135). Do Not configure a secondary DNS server on the client machined unless you happen to enjoy random connectivity and logon issues. Also do not configure a secondary DNS server on your DC as it will only cause the machine to loop through the DNS timeouts twice before failing anyway (if using the machine's IP), or worse fail to identify itself and refuse to authenticate anything including itself (if using an external DNS Server). Your DC will also use only itself for internal DNS lookups, and the forward lookups for external domains (e.g. the internet) to the DNS servers listed in the DNS forwarders list. Also Make sure if the DCPROMO wizzard configures your DNS server that you are not forwarding to yourself (at 192.168.0.135) if you use the loopback ip address (127.0.0.1) for the primary DNS server on your DC. <- This one drove me nuts for a week once trying to figure out why webrowsing was lagged badly on a T1) *Sigh* By default if DNS forwarding is enabled, the DNS server will forward all external domain lookups to the internet root (backbone) DNS servers (Which is the configuration I usually use), or you can add your ISP DNS servers to the forwarders list ... that's personal choice.

Those updates all deal with permissions issues, but are installed after MSVS. I've installed VS2k5 several times on both x86 & x64 Vista both before and after RTM. While I don't recall having any issues during the install it may be worth trying XPSP2 compatability mode and/or toggling UAC on/off. I was using an MSDN DVD copy of MSVS2k5 for all the installs, and think UAC was off during all of them. I don't recall using compatibility mode but it's worth a shot.

Nope. But I know him from another forum. His english is (2nd language) terrible when he gets excited, but he knows what he's doing.

Because it simpler then explaining what types of applications can/might/will conflict with the installer for any given application. Can you juggle 9 rabbid badgers at the same time? Probably. But should you...?

What you have tattooed is important as you may not think it's that cool when you're 80 (but it'll still be there) Where you have it tattooed is even more important, keeping them covered at work may be a job requirement. (Not everybody is that open minded...) I'm a network admin (and an old school biker), and have about 20 tats ... It does complicate things at times.

Yes, the printhead alignment data is stored in the printer an is therefore considered portable.

I've long been a fan of GetDataBack, but now will reconsider this. Thank You.

According to www.SecurityFocus.com this is a SQL injection attack specific to RunawaySoft Haber Portal 1.0 ... Not a Windows issue. But thanks for letting folks know about it.

Vista uses a completely different boot loader than XP, have you tried running fixmbr from the XP recovery console?

The sodium in any soft drink will simply (dehydrate you) make you more thirsty which is why it's in there in the first place, to make you drink (and buy...) more of it. If you really are worried about your health then stick to drinking water, it's been hydrating people just fine for millions of years, and will also help to flush some of your other "sins" out of your system.

Being that you're working on a Sunday and can shut all the machines in the building down, I'm assuming the place is closed. So I'd try a slightly more low-tech approach. If the network is fine with all machines off start there, and then turn the machines on one at a time. Keep an eye on the switch to see which machine makes it light up like a christmas tree. A quik burst of activity is normal as it anonuces itself on the wire, but if it continues then you've got either a chatty NIC, or a tweaker that has borked their workstation. Just a Thought Stoic Joker

This might help How to view and transfer FSMO roles in Windows Server 2003 (Some of those tests can be a bear so...) Good luck on your studies!

WinImage is a commercial application that also uses the FileDisk code, they have some documentation for it on their site and provide a downloadable demo that may give you some insight into which API they used for the dismount/eject. It's been awhile since I went to their site but the encouraged folks to use the FileDisk code and used to provide downloadable source for it's usage. Just a Thought Stoic Joker

Frankly I have better things to do with my time then argue symantics, but I'll try explaining this one more time. Actually...no, I wasn't. I was simply pointing out that he already stated he wasn't using NetBIOS. Ignoring it and then asking the question did the job quite well. The point is the While he thinks NetBIOS is (completely) disabled ... it isn't, which is why DFS is functioning and not throwing errors every time sombody attempts to access a share. My objective was to get him to confirm just how throughly NetBIOS had been "disabled" and where. Not to mention (being that there is only one subnet/broadcast zone) that no mention of how addressing is being handled leaves the door open to a DHCP server letting the old WINS server mask the issue. (e.g. does it provide a Node Type and if so which one) DHCP servers don't care what domain you belong to trusted or not...If you're "On the Wire" you're OK. TCP/IP does not require NetBIOS to operate and NetBIOS does not require TCP/IP to operate. NetBIOS will work over IPX/SPX, or even NetBEUI. So NetBIOS will work over the NetBIOS Enhanced User Interface Eh? *Sigh* The guy that started the thread made the TCP/IP -vs- NetBIOS connection Not Me which is exactly why I ignored the statement (thanks for pointing out that you noticed its absurdity). The issue is DNS -vs- NetBIOS and does he need to add a registry key that will also require him to rebuild the DFS root from scratch. The object here is to Help the Guy that started this thread not side track it by branishing yourself. so if you have something relevent to the issue feel free to join in, otherwise leave the space open to those of us who are actually trying to help the poor fellow

Gee, Let me guess ... You're trying to make me look like an id*** by pointing out a statement that I appear to have missed? I didn't miss it, I simply ignored it because it didn't make any sense. (e.g. TCP/IP and NetBIOS are not mutually exclusive) The point is (obviously) that one of two things has happened. 1. Using FQDNs for the share mappings is acting as a "Work-Around" for the name resolution issue. (That's a stretch, or...) 2. NetBIOS isn't actually as disabled as he thinks it is... Frankly my money is on option 2, as just setting NetBIOS to disabled in Local Area Connection properties doesn't actually (Completely) disable it. Feel free to spend a bit of quality time with a packet sniffer watching broadcast traffic to confirm this (I have). Also it's currently working without throwing errors, and it's working with roaming profiles which are extreemly touchy and love to fail if everything isn't perfect. There are several registry hacks that are required to truly (and completely) disable NetBIOS, hence my assumption (based on and confirmed by the above) that NetBIOS is still (kinda) working. Frankly due to the prevalence of legacy applications (and/or current applications that use legacy code) that require NetBOIS in some manner to function properly (or at all) it is really not recommended to try to run a DNS only domain...But I was trying to not have to go into that part.

Well... Unless you've made a point of disabling NetBIOS, then you're using it. And if you're using it with a single subnet/broadcast zone (which you are) then it is fine as it is.

I think the key point here is if you're not using either WINS or NetBIOS, then (and only then) do you have to configure DFS to use DNS only. Assuming that all your machines are in the same broadcast zone then NetBIOS can/will work for DFS name resolution. If you had multiple subnets, sites connected by VPN, or a segmented switch (things that require routers) then you would need a WINS server for the standard UNC fileshare names to work, and likewise for DFS to work.