cluberti

As long as you have Windows 2000 SP4 and URP1 installed, you should be fine.

Not necessarily - you can have active/active file clusters, active/active print clusters, active/active Exchange clusters... Why anyone would have an active/active cluster is a bit beyond me, because you remove the redundancy portion of it, but I guess sometimes performance is more needed than failover.

Post that minidump here, if you would, and I can at least tell you what happened - since minidumps are usually devoid of good information (they're only good for determining what happened, but not where and why), also do the following: Configure your machine (in system properties) to do a complete memory dump, make sure your page file is on C: and the minimum size is at least as large as the amount of RAM in your machine +50MB, and if the problem happens again you'll get a complete memory dump (which will be easier to tshoot).

Try the following: 329708: Windows Cannot Determine the User or Computer Name http://support.microsoft.com/default.aspx?...kb;EN-US;329708 819411: Event IDs 5788 and 5789 are logged when you join a Windows 2000-based client to a Windows 2000 domain http://support.microsoft.com/default.aspx?...kb;EN-US;819411 257734: Event ID 5788 and Event ID 5789 Appear in the System Event Log http://support.microsoft.com/default.aspx?...kb;EN-US;257734 You may also want to delete the following registry values: HKLM\SOFTWARE\Policies\Microsoft\System\DNSclient\PrimaryDnsSuffix HKLM\SOFTWARE\Policies\Microsoft\System\DNSclient\\NV PrimaryDnsSuffix

If it's restarting and going through the whole shutdown process, it's possibly an infection of some sort. However, if it's just rebooting (without the whole shutdown process happening, saving your settings, closing network connections, etc) then you either have a hardware problem or the machine is indeed bugchecking. Make sure your system is configured to do a complete memory dump, notify the administrator, and NOT automatically reboot. If you're getting a bluescreen, you should see it after making these changes in the system properties. However, if the machine still reboots (and again, isn't going through the whole shutdown process) it's almost always a hardware problem and obvious hardware testing should ensue. And pressing F8 after the BIOS POST, but before the Windows XP splash screen comes up, is how you get into safe mode.

Actually, Server 2003 x64 is based on the Server 2003 SP1 codebase, as is Windows XP x64. I was mentioning that they're the same codebase, not where they came from (which is indeed the same place, Server 2003 SP1). I'm not sure there's any correction needed there.

chilifrei64 is right - these permissions should be configured by default, but if you modify them, things will break.

So the problem happens with both ftp.exe in XP, and FTP programs as well?

Development of Service Pack 2 for XP really put a dent in the Vista development timetable, but I think we can all agree that no XP user should be without SP2 at this point. As to XP x64, remember that real, production x64 hardware has only been available en masse for the last 2.5 years or so, and there are two different implementations of that architecture (Intel's EM64T and AMD's x64). Windows XP x64 is actually the same codebase as Server 2003 x64, with some memory and cache tweaks to make it more "workstation-like". All (and I mean ALL) Windows Server 2003 binaries had to be recompiled and tested on x64 hardware, as well as making sure that the WoW64 architecture ran most 32bit applications on a 64bit OS. Vista will also ship in 32 and 64bit versions, as will Longhorn server, making these likely the last OS products Microsoft will ship in 32bit variants. I know we can all pound on Vista for being late and having a shorter feature-set than it originally was slated to have, but x64 has nothing to do with this. Vista is a new OS, XP and Server 2003 x64 is a recompile of an existing codebase, not new code.

What exactly were you doing in FTP when it hung?

You will probably get different results in different sites, as AD is configured to go to the local DC GC in each site before trying others. This is normal behavior, because you are using multiple sites.

You need to also change the SourcePath value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\, and you may need to modify the ServicePackSourcePath value in HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\ if the i386 folder is slipstreamed with the currently installed service pack level.

Run "msiexec /regserver" from a command line, otherwise run sfc /scannow and then "msiexec /regserver". The MSI engine actually has two processes - one runs as a service, and the other runs under the user account. It's possible that one (or both) of these are no longer loading properly, or .dll's have become corrupt, or registry settings for the service are invalid, etc.

Open up a command prompt, and type: msiexec /regserver Reboot, and see if the Microsoft Installer engine works. If not, you should probably run sfc /scannow, then run the above command, to see if that works. Otherwise, you should consider doing a repair installation (as a last resort).

That's odd - you sure that box is clean from viruses, spyware, rootkits, etc? Winlogon initiating a machine restart, without any reason, is pretty fishy.

You need to run forestprep once from one DC in the root domain of a forest, and domainprep once from one DC in every child domain (including the root domain of the forest). If you only have one domain root and no child domains, you only need to run forestprep and domainprep (in that order) on one, and only one, DC. You should wait 15-30 minutes between running forestprep and running domainprep, but otherwise there are no caveats.

What does the server in question do, or what will it be expected to do?

Your syntax is incorrect. Windows Registry Editor Version 5.00 [HKEY_USERS\.DEFAULT\Control Panel\Desktop] "Wallpaper"="C:\\WINDOWS\\Web\\Wallpaper\\MyWallpaper.bmp"

You've posted this before . Download perfwiz from the MS download site and run it in "high CPU" mode from another machine - note not to choose either the Exchange or Terminal Server option. You'll need to configure the performance logs and alerts service on the remote machine to log on with a domain admin account, or a local admin account on the server with the issue. Once you've started perfwiz on the remote machine, give it 5 minutes, then stop the log, open it in perfmon, and check the following: Memory: - Pages/sec - Page Faults/sec - Page Reads/sec - Page Writes/sec - Pages Input/sec - Pages Output/sec Process ***For each process in the right-hand pane (NOT total!), select the following counters*** - Handle Count - IO Read Bytes/sec - IO Read Operations/sec - IO Write Bytes/sec - IO Write Operations/sec - Page Faults/sec - Private Bytes - Thread Count - Virtual Bytes - Working Set Also, run filemon (http://www.sysinternals.com) to see if you have any spikes to a particular file or set of files in this 10-second interval that can be seen.

Is the XP firewall enabled?

I don't see any lines pertaining to "lpDefaultPath =" there - meaning it never looked for \\ntserver\netlogon\default user. You SURE the network is up _and_ the user has at least NTFS and share read access to the netlogon share? Because it's not showing up in your userenv logs...

What happens if you ping 141.149.134.194? And tracert to the same?

When you sysprep'ed the machines, did you have a video driver installed, or did you install (and use) the Standard VGA driver? If you installed video drivers before sysprep'ing, it can cause certain issues, and it is recommended to use all standard Microsoft drivers for any component where possible when creating the initial sysprep image.

If the drives are NTFS, a 98boot disk will do you no good (it can't read NTFS without 3rd party software). You would run the following command to run chkdsk in "fix" mode (the /f): chkdsk C: /F /R You should only do one drive at a time (and you should do it after a reboot, do not forcibly dismount any drives if prompted to do so!), and you should run this command for each hard disk volume on your system (obviously substituting the proper drive letter for C:, when appropriate).

I hate to say this, but this dump still shows a hardware error with a different stop code from before (it's now a stop 77, 0x77_c000009d: I'm sorry, and I can't tell you why quicktime is doing it (other than it's owned by csrss.exe, and appears to be bringing csrss.exe down when it crashes, which is also VERY odd), but the system says there's a hardware error here, and I'm inclined to agree. It may be as simple as running chkdsk /f against all drives on the box, or it could be a bad cable connected to a CD or hard disk - but it's just not something I see going on in any stack in the entire dump. The only stacks I can see with issues are ones with a kernel trap or kernel lock, and these are all csrss.exe processes, which would make sense because if csrss.exe crashes, the whole box will come down. This error can only be caused by a bad block in the page file, or it is indeed a disk controller/subsystem error. My guess is that it's a bad block in your paging file (perhaps move it to a different drive and reboot?), but it could still be the actual controller on your motherboard (or PCI IDE controller) has a problem (drivers or bad hardware). If it's a bad block in the paging file, you should consider your filesystem suspect and should chkdsk /f the drive right away. If it's a controller error, you should consider replacing the drive, the controller, or both. Wish I had a better explanation, but I don't - the issue is the filesystem (specifically in the page file location) or the actual controller/cables/hard disk subsystem. Sorry to be the bearer of bad news, but dumps don't lie .