cluberti

Try disabling the NIC's autosense, force the network connection's speed and duplex settings manually, and see if that helps any across a reboot.

A Stop 8E error maps to "Setup_Failure" as it's error code, and the resulting memory dump should tell us a bit as to what is causing the error the next time this occurs - if you can even get that far. First, I'd strongly suggest running a repair installation to see if it is a Windows system file that has gone corrupt or has been replaced with a less-than-stable version by a driver or application. Second, if the repair install didn't work, I'd install Windows 2003 again, but this time without installing any drivers - assuming the installation is stable, start installing drivers one at a time and rebooting until the problem recurs.

Actually that hardware should be just fine for 2 or 3 VM's running concurrently. I've run VS2K5 on lesser hardware with little issue . PM me if you need some help.

It can be done, but why would you want to?

You say you've got a 40GB disk 95% full? My guess is going to be a disk cache issue, especially if you've got the pagefile on the 40GB drive. Anytime you have less than 15% free space on a drive, you'll start running into issues such as these with heavy disk access or updates.

Did the Windows installation on the machine in question come from a vendor's OEM CD? If so, are you using that CD to do the reinstallation, or are you using another retail or OEM CD?

Have you modified the NTFS file permissions on the folder the Riprep image is stored in?

You will need to make the registry change, and then use the /usepmtimer option in the boot.ini file. Yes, this does fix a halt issue that can cause excessive processor heat under W2K SP4 with URP1 installed (this also works on Athlon 64 x2 processors).

You are entitled to your opinion, and I would always suggest people use products that work best for them in their environment. However, just saying a product sucks without pointing out specific reasons isn't very good advice.

I'm not sure there's any other way to do it, short of using a different deployment method such as RIS (or riprep). Have you tried replacing those .dll files until you get no errors during installation, or does the installation always complain about missing files no matter what you replace?

Windows XP x64 is very picky about driver support - if the drivers you are using are not WHQL and vendor certified to run in a 64bit environment, you WILL have problems. I hate to say this, but stick to drivers from the computer manufacturer or component vendor as necessary, and you'll have fewer driver issues in Windows XP x64. If you're using someone's tweaked driver set, you may run into problems occasionally.

First of all, Virtual Server 2005 R2 isn't slow unless you're running it on slow hardware - it's a server product, and it needs a server-class machine to run on (if you wouldn't run SQL on it, you shouldn't run VS 2005 on it!). VS 2005 works very well when it's run on good hardware, and each VM does not need the memory footprint that a VMWare VM needs to run at similar speeds once booted. You can use the following articles to help you cluster 2 machines in VS 2005 (although you can only cluster 2 virtually, due to limitations in the virtual SCSI adapter used in VS): http://www.microsoft.com/technet/prodtechn...VM_cluster.mspx http://www.microsoft.com/technet/prodtechn...oy/cvs2005.mspx It's quite easy to do using the instructions in the articles above.

Yes, you only need to "purchase" a piece of hardware to purchase an OEM copy of Windows legally - you don't necessarily have to "use" it afterwards. It's a loophole in the EULA, but it's not illegal.

Very true.

Try using a runonceex string of commands to join the domain, and use the following vbscript before you run your .cmd that joins the domain to determine network access is available before running the .cmd: Dim sTestPath Dim intCount Set objFSO = CreateObject("Scripting.FileSystemObject") Set objShell = CreateObject("WScript.Shell") Set objVolatileEnv = objShell.Environment("VOLATILE") ' An UNC path here that will be available when network connection is in place sTestPath = "\\server\share" intCount = 1 ' test on volatile environment variable to avoid running script If Not objVolatileEnv("LogonScript") = "Done" Then Do Until objFSO.FolderExists(sTestPath) ' sleep 5 seconds WScript.Sleep 5000 intCount = intCount + 1 If intCount = 240 Then MsgBox "Unable to connect to network share for 20 minutes. Please notify your network administrator." Exit Do End If Loop ' share/folder available on server now, so continue End If Once the vbscript detects that it can access "\\server\share", it exits and the next command in your RunOnceEx key gets executed. Very simple script, but yet very powerful (especially for RIS or network installations).

Windows 2000, XP, and 2003 all have this functionality as described by rjz. It is not specific to any of these versions; it was introduced in Windows 2000.

You'd be wise to back up your data and reinstall Server 2003 - since both Windows XP and Server 2003 use the \WINDOWS folder on the system drive to store most of their information, you've now got a hodge-podge of files from both 2003 and XP in the same WINDOWS directory. This is likely why you have boot issues with one of the installations as well, as having mismatched file versions (especially from different Windows versions, let alone service pack and hotfix levels) causes these kinds of issues all of the time. Good luck to you, you may need it .

A couple of things come to mind - if you can afford it, you can really do this nicely. I wouldn't suggest child domains unless you really need the security separation, as simply creating sites and subnets in AD Sites and Services for one domain is much easier to manage long-term. If you really need separate domains, create separate domains for both the 2300 building AND the Ormond building. 1. Create a new domain (for example, mydomain.com), which will be a new domain in a new forest, and migrate your users from your current domain(s) into this one (you'll need a trust to move the users from the old domain(s) into the new, but it's pretty easy once done - the workgroup users will be SOL and will get new accounts ). Remember that if you plan on using ISA 2004 (*wink wink*, strongly suggested in an AD environment) as your firewall of choice to use split DNS - use the same DNS name internally for your AD as you use externally. For example, if you own the "mydomain.com" domain name, your AD domain will be named "mydomain.com" - with the caveat that your internal DNS will be private, non-routable addresses. 2. Decommission all of your other domain controllers and (in essence) you'll "kill" your other domains. 3. For clarity's sake, you would be wise to rebuild these servers once demoted to make sure you don't bring any "old domain" data into your new domain when you dcpromo these boxes. Once you've rebuilt the boxes and established site-to-site VPN links between the remote sites and the home office site, you will be able to continue to step 4. 4. Rejoin your DC's at your home office into the domain via dcpromo. Install DHCP, DNS, and WINS on one DC. 5. Join your DC(s) in the 2300 building into the domain via dcpromo. 6. Join your DC(s) from the Ormond location into the domain. 7. Create the proper sites and subnets in Active Directory Sites and Services on a DC in the home office, and move the proper DC objects into their respective sites. Allow a good few hours for this to be up and fully functional (monitor AD replication via replmon to make sure there are no errors). 8. Create DHCP servers for each site on one of the DC's, matching each DHCP server's scope with the proper IP range for the site. Configure DHCP in each site to give out the DNS and WINS server information from the parent domain, if possible. This makes browsing more controlled and uniform, especially netbios browsing in Network Neighborhood via WINS. Steps 9 and 10 will reduce the load on your links during file and login access, but only follow these if you can get a file server at each site: 9. Create a domain DFS root, and place your file servers in each location into the DFS root. 10. Configure each file server at remote sites to be replicas of the file server at the home office - this will make sure that the data on one file server is present on the others, and DFS will know which server to direct a client to based on it's IP address, subnet, and which site that subnet belongs to. Note that this works much quicker in a Win2K3 AD than a Win2K AD, because Win2K DCs use the DFS object stored in AD to determine the closest replica, and Win2K3 DC's use the site structure in AD (what you see in AD Sites and Services) to determine the closest replica, which is much more reliable and efficient. Again, if you can swing it, steps 9 and 10 make sure that (with few exceptions) all users get similar performance to files, folders, profiles, and logins no matter what site they are located at. You can also use roaming profiles at this point when the profiles are stored in a DFS share, which can make sure that the user's environment also feels the same no matter what site they are logged into as well. Ping me via PM or email on split DNS and site configuration if you have any questions regarding these issues, and I'll be glad to respond. Edit: I can't spell. It's a disease .

Have you run sfc /scannow on the machine, and made sure your drivers are of the latest version (especially input and video drivers)? It sounds like an issue with either explorer.exe or shell32.exe, both of which would be replaced with drivers from the original installation source when you run sfc /scannow from a command prompt.

An original Windows XP retail disc would be at SP0 (it didn't have a service pack when it was released...), but you'll be hard-pressed to find any media that isn't already at SP1 or (more likely) SP2 levels. You may be able to purchase a set online if you specify that you want RTM media that doesn't include a SP, and see what vendors say they have in stock. I've done that before with some success .

As to the slipstreaming issues - that OEM CD you have from Dell has some special files on it that denote it as an OEM CD (and as such, it will only install properly on Dell hardware it recognizes, otherwise it'll require activation right away). Slipstreaming is NOT SUPPORTED on OEM CD's, period, for this reason - those special files are not included in the SP2 distribution that you get from Microsoft, and if it finds these files when you attempt a slipstream, it will refuse to continue. When you buy an OEM computer that comes with an OEM version of Windows (tied to the hardware), you will not be able to slipstream any service packs onto it. This is not Dell's fault, per se, but you will likely have to purchase a new OEM Windows CD if you want one with an updated service pack.1 As far as building your own, there are people out there who (for whatever reason) are unwilling or unable to build a PC on their own. For those people, purchasing a computer from a *respected* third party OEM is their best bet, both for performance and support. Alienware, Falcon, and Velocity Micro are just a few companies that come to mind that I've dealt with that had both good hardware and good support, albeit for price - you do get what you pay for when someone else builds a PC for you .

Well, it's almost definitely a hardware problem - I'd start by contacting the manufacturer to see what they have as far as diagnostic utilities that you can run, or perhaps they can repair it under warranty if they can find the root cause of the shutdown issues. Could be heat due to a non-working fan, could be a bum RAM chip, could be a faulty video chip. It is likely one of these three.

Run a utility called "Process Explorer" from www.sysinternals.com, and take a look inside the explorer.exe process to see what is exactly running within that process. You'll be surprised as to how much runs within explorer.exe, and you may get a good idea as to what might be the problem the next time you shut down. You may also want to try a utility called "Autoruns" (another sysinternals utility) to disable all non-Microsoft items. Reboot, and then try to shut down - if the problem doesn't occur, you will know it's something third-party (usually a virus scanner, but sometimes it's a utility in the systray) causing the issue.

That's not a very good idea - hal.dl_ on the CD is a non-ACPI hal. He should really determine (from the properties of the hal.dll installed on his system) what the internal name of his hal.dll is, and expand THAT .dll file out to the Windows directory as hal.dll. Otherwise, a good idea

Try the hub in a different port on the computer - if it still doesn't work, do the USB devices you mentioned work when attached directly to the computer? It could be the hub or the USB port on the machine, if the devices are working fine elsewhere.