cluberti

You have to be aware that updating IE does update some files that other applications reference, both in the shell interface and otherwise. If you roll your system back to IE6, does the issue go away?

I'm a bit confused - you need a private hotfix from Microsoft, which requires you to contact Microsoft support to receive it. Unfortunately, you purchased an OEM version of Windows, the tradeoff of which was that you received the software at a lesser cost during the transaction in return for not being able to receive free support for said software from Microsoft support (email or phone) in the future. So your choices are simple, but unfortunately painful in this case - you can purchase a retail version and get free support incidents, or purchase OEM software at a reduced cost and either pay for support when needed, or wait for the next Windows service pack. I empathize with your situation, but unfortunately you have OEM software - that's the deal you make when you purchase OEM software. You would like to have your cake (cheaper software) and eat it too (free support), but unfortunately it doesn't work that way when it comes to Microsoft support for OEM software.

Files and folders don't move on their own, but you could have an application or user moving them. You could always use filemon (from www.sysinternals.com) to watch the filesystem and see what is happening.

Here are some things you should check: 1. Check permissions on the WINDOWS\Registration folder - Administrators, System, and Users should all be listed - Administrators and System should have full control, Users should have at least read access. 2. Check the impersonate a client after authentication policy setting in gpedit.msc under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. You should at least have Administrators and SERVICE in there. 3. Check the bypass traverse checking right in gpedit.msc under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. You should have Administrators, Backup Operators, Everyone, Power Users, and Users in there at the least. 4. Export the HKLM\Software\Microsoft\Ole key, and then delete the defaultpermissions subkey and reboot. 5. If you still can't open MMC's, delete the entire Ole key and import one from a working machine and reboot.

That's the tradeoff for the OEM version of the software - it'll probably get rolled into the next service pack, if you're willing to wait.

Is the driver you are uisng 64 bit, and is it WHQL certified or "signed"? If not, you're playing with fire...

Make sure you aren't using your ISP's DNS servers in your IP configuration - only your own. This may not be the case, but it's the very first thing to check. Most AD problems are DNS-related, and even if you do have your internal DNS server(s) listed in your IP configuration, having even one external DNS server in your IP configuration can really wreak havoc on AD communications.

I honestly do not know - I doubt it'll be around in the Longhorn timeframe, though. It's more of a pipe dream at this point, but one I truly hope we go for sooner rather than later - I'm not sure how it can be implemented in the current architecture of Windows, but again, one can hope . As to clusters, there are some good and bad situations to use clusters (personal opinion), but if 5 9's are a requirement, cluster is almost the only option that can meet these requirements (as is using 2003 Enterprise or Datacenter editions).

They're not technically integrated, but IE uses shell components at times (like shdocvw.dll and shell32.dll), and Explorer uses IE components at times (like wininet.dll and urlmon.dll). I doubt this is going to change any time soon, including the Vista timeframe (otherwise IE7 would likely not be able to run on XP).

Risk vs. reward - either install updates to make sure you have the most recent security patches, or leave the box running for long periods of time and attempt to mitigate security issues via workarounds and security measures. Once hot-patching becomes standard in the OS, these issues should be mitigated due to patches no longer requiring restarts.

Nope, just the client.

I would consider installing netcap (from the support folder on the XP CD) on the XP machine, then get a network trace via netcap of the issue occurring. The trace should show you what is actually happening in the SMB communications between boxes, but you'll need to install a program such as Netmon or Ethereal to open the resulting .cap file.

IE6 and explorer cannot be separated, as IE6 actually uses shell components (not the other way around). There are guides on the 'net on how to remove IE6 completely from an installation, but I wouldn't suggest it.

Contact Microsoft to provide you with the Italian version of the hotfix. That's a private hotfix, so it's not available to download. I can tell you that an Italian version does exist, but you'll need to contact Microsoft to get it.

IE7 has the same files separated from shell components as Windows Explorer. It's just that the IE7-specific files are newer than IE6, otherwise they'll use the same shell components on Windows XP.

Are you extracting these files to an NTFS-formatted volume?

If you're talking about Exchange, this can be done with some 3rd party utilities. My favorite is GFI MailEssentials, but there are others (you could even do this with a sendmail box in front of Exchange, if you are so willing).

Have you checked the appmgmt.log file to see what happened on the client when the logon occurred?

If the time (or date) on the systems are off by more than 5 minutes, this is what will happen. Log onto one of the clients, and verify both the TIME and DATE against what the server has - if they're different, you'll see this behavior.

I'm a little confused by the question - do you want IE6 not to use shell components, or the old-style Windows Explorer?

Google is your friend. http://support.microsoft.com/default.aspx?...kb;en-us;290398

That's a common CLSID - it's listed as "netman" in DCOM Config. That's where the error lies.

Open outlook from a command prompt with the /rpcdiag switch to make sure RPC communications between Outlook and the Exchange server are working. If not, it's likely that a device along the way (usually firewall or VPN server) is blocking port 135 at the least, with causes RPC to fail. You can always configure Outlook 2003 and Exchange 2003 to do RPC over HTTP as well.