cluberti

A (very) good msconfig replacement is autoruns from sysinternals (www.sysinternals.com).

Technically yes, but I would not choose 192.169.0.0/24 as none of the class C ranges in the 192.169 IP range are set aside as private. You have to choose from one of the following ranges: 192.168.0.x/24 - 192.168.255.x/24 - Class C Private ranges (192.168.0.1 - 192.168.255.254) 172.16.x.x/16 - 172.31.x.x/16 - Class B Private ranges (172.16.0.1 - 172.31.255.254) 10.0.0.x/8 - 10.255.255.x/8 - Class A Private ranges (10.0.0.1 - 10.255.255.254) I'd suggest using 192.168.1.0/24 as the range for your external network, just to make it easier for you. That way, your router and Windows 2000 machine can use 192.168.1.x addresses, and the ICS will give out 192.168.0.x addresses - this will work just fine .

Either reinstall SP1, or install SP2 to get the function. Otherwise, it won't work.

If you've got your Windows CD, simply run "sfc /scannow" from a command prompt to try to restore/repair the file. If that doesn't work, boot with the CD and go into the setup routine - select the "Repair" option when you're given the chance.

I do not have such registry keys on workstations in my domain, but if you do, it would go without saying that your users would need special access to most keys in HKLM for things like this to work.

You'll need to compare it to a non-slow workstation to be sure there aren't excessive retransmits, or auth failures, etc. My guess is going to be authentication failures or excessive retransmits when the users are logged into the domain, but it's just a guess. Are there any events in the eventviewer, and is there a proxy in use on this network? Are login times to the domain controllers slow? Are any of the user's folders redirected? Do the users use Internet Explorer / Outlook Express exclusively? Are the documents being downloaded and opened from a server on your network, or on a server outside the network? Do you use DHCP on your network, and if so, what DNS servers are you pushing out via DHCP?

Use the GPO to change permissions on the %windir%\fonts folder to give the needed user or user groups change permissions on that folder, and that user or group will be able to install fonts.

Note that the vulnerability doesn't affect Windows 2000, XP, or 2003, just NT 4.0 Workstation. It's not a bad idea to whack the file though .

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

Where's the netmon traces showing the slowness? Netmon a box that is slow, and netmon a box that isn't, and you should see the reasons in black and white .

No, you need to change your router to not use the 192.168.0.xxx range AT ALL. You CAN'T use that IP range on your external network and still use ICS unless you have Windows Server 2003. Period.

There is the "Load and unload device drivers" under user rights assignment in the computer config of a GPO. By default, users do not have this right, but granting it should allow installation and use of PNP devices (like USB keys).

Is your cluster operation mode unicast or multicast, and is the IP address you chose for the virtual IP address configured as an IP on your network, with the correct subnet mask? If these servers all have only one network adapter, you MUST be using multicast (and thus, your network must be able to handle multicast traffic).

That I can't speak to. I can honestly say that I haven't seen any support requests recently for this hotfix, so either people aren't aware of the heat issue, or it just isn't affecting many SMP users and is only triggered in specific situations with specific hardware types.

Have you considered using a different NIC to see if the problem occurs there? The onboard nVidia network interface is not a 100% hardware NIC (it's a MAC talking to the chipset itself), so using a different NIC and drivers should tell us if the problem is in the IP stack, or the network interface you're using. Yes, TCP communications in XP are usually slower than their *nix counterparts currently, but there is an overhead built into the Windows IP stack for error checking and QOS. If you've got the QOS agent enabled in your NIC's properties, you can obviously disable that for better throughput. Note that Vista's IP stack is a complete rewrite, and from the betas that I've tested it does seem to network faster than previous versions of Windows. It's at least something to look forward to .

This exact error happens when the CPU in your PC comes across an unrecoverable hardware error. In all x86 CPU's since the Pentium 1, there exists something called the "Machine Check Exception" (called the "Machine Check Architecture" on Pentium Pro processors), which is designed to catch hardware errors that it cannot rectify. These errors are ALWAYS caused by a physical hardware error and are almost always memory errors, although I've seen these with cache or TLB errors on the processor. I've also seen these caused by a system bus signaling error, usually caused by something on the bus (PCI or AGP card, for example). If installing older drivers solves the issue, then you should probably find out which driver was actually causing the problem, because that will direct you to the problem hardware that you should at least consider replacing.

If you do not have at least SP1 installed in WinXP, you'll get this error (the entry point didn't exist in the stock version of Kernel32.dll. If you've got SP1 or SP2 installed, you may need to run sfc /scannow or reinstall the service pack to fix this.

No, there's no mistake. Windows 2000 does not have the capability to understand how hyperthreading works, and thus sees a HT processor as two logical processors. Obviously the HT logical processor is not a real processor, and addressing it as such can cause the processor to run much hotter than it normally would - and thus we usually suggest that one disable hyperthreading on Windows 2000. Also, adding those registry keys or a boot.ini switch to every machine touched by the rollup would actually be detrimental to those people who don't have dual-core or hyperthreaded processors, which is at this point likely 99% of the Windows 2000 user base. This power behavior is likely to occur with dual-core processors at this point now, as Windows 2000 is treating each as a real processor die, and causing temperatures to rise due to the nature of two cores being accessed on only one physical die. Since Windows 2000 is only in critical patch state at this point in it's life, I doubt that something as monumental as a hal.dll rewrite will occur that makes it behave more like Windows XP and Windows 2003 with respect to these processors (they understand hyperthreading, and to a lesser extent dual core). That's why those switches and reg hacks exist - it's an easy fix, and to be honest there aren't many people who would actually need them - most people buy their OS with their PC, and Windows 2000 never shipped (at least by default) on a dual-core or hyperthreaded machine.

To all: Moving C:\Program Files is a bad idea. We have seen Microsoft patches, Microsoft applications, and 3rd party applications fail to install if the Program Files directory is moved to a drive different from C:. Also, there are some functions in the OS that are hard-coded to use C:\Program Files, which may or may not be changed in future versions of Windows. Also, moving the C:\Program Files directory removes your ability to obtain support from Microsoft for Windows or associated Microsoft applications until you move it back. Setting the %ProgramFiles% variable will work for most programs, but not all, and MS patches and programs do sometimes look for only C:\Program Files (MS05-052, for a recent example). Just thought you all should know - this post jogged my memory, and made me check.

Change your router to not use the IP range 192.168.0.x - ICS is hardwired to use 192.168.0.0/24 as it's DHCP range, and having two DHCP servers using that range will cause issues like this. You will NEED to be using an IP range different than 192.168.0.0/24 on your ICS server's network connection, or ICS will not work. This is not true in Windows Server 2003 (you can change the IP range ICS uses in 2003), but it is for XP and earlier.

You must put your virtual machines on a virtual network within VS. However, you can set up the loopback adapter on the real server, and use ICS to share that connection with your virtual network in VS (there are technet articles on how to do this). I find the following article to be much easier to follow, however: http://blogs.msdn.com/virtual_pc_guy/archi.../04/477195.aspx

No, again these are different architectures, and thus, different versions of Windows. No, it will not work.

If you set your users up as regular users, and not power users or administrators, most applications will not install (because they won't have write access to necessary registry keys and folder locations). Also, if you are using Active Directory, things like this can be locked down via Group Policy.

Considering that what you are doing will not be done by 99.5% of the population out there that is using Microsoft Windows, that's not necessarily a "stupid" thing to do to assume that the Program Files directory will be on C:.

Read the following article on enabling MSI logging in Windows XP: http://support.microsoft.com/default.aspx?...kb;en-us;314852 Then try to install your application. The application install will be logged, and the actual errors (not just the generalized dialogue boxes that Windows displays) will be written to the log file. This should tell you what went wrong, or give you an idea of where to start in troubleshooting this issue.