Jump to content

cluberti

Patron
  • Posts

    11,045
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    country-ZZ

Posts posted by cluberti

  1. 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 :).

  2. 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.

  3. 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?

  4. 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).

  5. 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 :).

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

×
×
  • Create New...