cluberti

No - the actual underlying Windows structure has no support built in for 16bit code. There are specific Installshield and Acme installers that will work (they're upgraded to 32bit installers on the fly, thus allowing them to run in WOW64), but otherwise no. The NTVDM relies on certain system .dll's and .sys files to work, and those files either no longer exist, or have no support for 16bit calls in their 64bit iterations. You'd have to copy the whole 16bit subsystem of Windows XP over, and there's no guarantee that it would work then, either.

Are you certain of the following? 1. All domain controllers have the same time, and are set in their proper time zones. 2. You have NO public DNS information on any of your servers or clients - they all have only internal DNS servers in their DNS configuration (or gathered from DHCP). 3. This has worked before (those error messages are not necessarily uncommon in a non-domain environment, as these are Kerberos errors). There is one thing you can try, as these errors can occur if other services start before the DNS service. What you may wish to try is making the NETLOGON service depend on DNS. This can be done in the registry: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon Value: DependOnService Data: DNS (add under any other values listed here)

It appears as though your DNS server is having trouble binding to an IP address on port 53 - have you considered manually configuring your DNS server to use a specific IP address? Also, are these multihomed machines, and do you use any NIC teaming software?

Yes, it should.

SAV10, Avast, and eTrust are all good 64bit native A/V applications. NOD32 is still a 32bit app that can run on the 64bit platform - it's not bad, but it's definitely not the best way to do it.

I would strongly suggest anyone seeing this issue contact Microsoft with the problem, otherwise it will likely not get addressed publicly. It takes either a volume of support requests for a particular issue, or a serious bug or security issue for a KB article to be created. If no one tells Microsoft this is an issue for them, Microsoft isn't going to necessarily know.

I'd first try doing an sfc /scannow, and failing that, a repair installation before doing a complete reinstallation.

Does it behave the same in Safe Mode with Networking?

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "ShowLogonOptions"=dword:00000001 If you're not using the classic Windows logon ("ctrl-alt-del box"), this setting will have no effect. If you've got the fast-user switching disabled and are ussing the classic logon, this should give you the full expanded options box. If your box isn't a member of a domain, though, you get no more information than if it isn't expanded.

These sorts of things can also be very easily done via a script using the netsh command: http://www.microsoft.com/technet/prodtechn...d045f8de79.mspx

Your opinion. Personally I think Microsoft products are just fine, but use the best tool for the task at hand - if Linux or Unix are better tools for you, I suggest you use those tools. Again, best of luck to you.

If you buy an OEM copy of Windows (or get Windows with your PC), you don't get free support from Microsoft. You either support it yourself, call the vendor who sold you the PC, or you pay $245 and talk to Microsoft. Or, you buy a full retail product and get a certain number of free incident support requests. That's one of the myriad reasons OEM versions of Windows are cheaper.

The next time you are able, open up task manager (taskmgr) and sort by CPU - which process is listed as using 100% CPU, or which processes are using the most CPU time constantly?

Ok, so it seems fairly obvious that the problem isn't with your .sif file, but with file(s) on the disc itself. Roll back to using a default, non-modified XP x64 source, and if it installs, add the NFM updates and try again. If that works, recab one file at a time until it all works, or it fails. Whenever it does fail, you'll know where the problem lies.

Yes, you can run 64bit guests on a 32bit host, as long as the processor checks out. Also, to clear things up with supported processors, you can use this tool to check your processor to see if it will work properly with VMWare: http://www.vmware.com/download/ws/ You can find the link down the page a bit.

np.

Why do you ask?

Yes - unless your video drivers are installed (via the OemPnpDriversPath and $OEM$ method) during the Windows installation, or your video card's drivers are included in the Windows drivers, you will get a 640x480 screen no matter what resolution you set. It has nothing to do with VMWare (start installing the VMWare tools, then copy the drivers off of the virtual CD it creates to put these into your own CD - I do this with great success).

Wow - good catch. I'd wager that's what's causing it right there - improper spelling .

I'd say remove the applications that those drivers belong to, and reinstall.

Use the AD Sites and Services to create new sites, and associate network subnets to the proper site. Move the DC's into the proper site containers, and within the next few replications clients should be using the closest DC for authentication purposes (except password changes - those always go through the PDCE first).

No, it will give an error - note that it's the C-G core, and it needs to be C-H or higher (which no Athlon's have, only Sempron Palmino and Mobile Athlon 64's).

All x64 versions of Windows (XP and 2003) have SP1 built-in. If you've got an x64 version of Windows, you've got the SP1 bits. As to the error, have you tried your Winnt.sif file without any of the program files options? Does setup work properly then?

It'll cost you $245 a request because you'd talk to people like me, who are real support technicians, not just a sales/routing desk. B)

Make sure you've configured your DNS server to allow all updates, not just secure updates. Since you do not have a domain, the "secure updates" setting will not work (and you'll see those errors).