cluberti

gpedit.msc Computer Configuration Windows Settings Security Settings Local Policies Security Options Devices: Prevent users from installing printer drivers - Disabled User Configuration Administrative Templates Control Panel Printers Point and Print Restrictions - Disabled Prevent addition of printers - Disabled Prevent deletion of printers - Disabled Edit - wrapped in code, the only way I can keep formatting

Is the disk controller the same on the machine the W2K image came from and the new VMWare machine? If they aren't, you'll get this error. This isn't a boot.ini issue, it's likely a driver issue. Can you boot into safe mode?

If you can, boot to a recovery console and do a chkdsk /f /r on the boot volume. This can also be caused by corruption in the system hive, which can be repaired as well via chkreg.exe if chkdsk doesn't find any problems.

You can do this with some WMI magic in a vb script: Option Explicit Dim objWMI, objItem, colItems Dim strComputer, VerOS, VerBig, Ver9x, Version9x, OS, OSystem strComputer = "COMPUTERNAMEHERE" Set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set colItems = objWMI.ExecQuery("Select * from Win32_OperatingSystem",,48) For Each objItem in colItems VerBig = Left(objItem.Version,3) Next Select Case VerBig Case "5.0" OSystem = "W2K" Case "5.1" OSystem = "XP" Case "5.2" OSystem = "Windows 2003" Case "4.0" OSystem = "NT 4.0" Case Else OSystem = "Unknown (Win9x perhaps?)" End Select Wscript.Echo "Version No : " & VerBig & vbCr _ & "OS System : " & OSystem WScript.Quit

1. Click Start, click Control Panel, click Performance and Maintenance, and then click Administrative Tools. 2. Double-click Local Security Policy. 3. Expand Security Settings, then expand Local Policies, and then click Security Options. 4. In the right pane, double-click the Shutdown: Allow system to be shut down without having to log on policy, click the Disabled radio button, and then click OK.

Note that the boot.ini option only works on 32bit - it will do nothing on x64 Windows.

Can you check in your registry for the following: Key: HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318} Value: UpperFilters Type: REG_MULTI_SZ Data: PartMgr Do you have this value?

http://support.microsoft.com/kb/912923/en-us

Are you certain you have the latest drivers for your video hardware, and that you're using a recent version of DirectX?

DirectX on Windows 2003 SP1 is listed as 9.0c, but if you look closely at the files they're different minor version numbers than XP SP2 with 9.0c. It's like a mixture of 9.0b and 9.0c (I'm not in the DX dev group, so don't quote me on it), and it requires using something like happy uninstall to remove and reinstall the proper DirectX 9.0c. Otherwise, it'll report quite a few different versions to programs - which is odd, and I don't know the reasons behind the crippling, but it is indeed not the same after SP1.

It depends - does your NIC support doing IPSec in hardware, or would this be done on the CPU? If it's the latter, yes, you will see slower speeds when IPSec is enabled. If it's the former, speed differences are likely to be negligible.

From the Microsoft site: As to Windows setup time being slow, yes, Vista is a slow, slow setup. Windows XP setup rarely takes me longer than 30 minutes though, on midrange hardware. You have to remember that Windows setup is registering a lot of system components, not just copying files over to the disk.

http://support.microsoft.com/?kbid=823303

I also have to state that building an x64 version of a 32bit application shouldn't be hard for most vendors - assuming they aren't using direct access to functions and are using the default exposed Win32 APIs, a relatively simple code review and recompile using an x64 compiler should be all that is needed. Now if a vendor uses filter drivers, direct access to functions, built-in application memory management outside the NT memory manager, or any other such type function then yes, building an x64 version of that application will require some work.

That's not something that you can fix without doing a repair installation.

You should consider posting this in the dedicated Unattended RIS forum - or better yet, search there first. You would've found the answer right away, as this is a (very) common question. Unattended RIS Installations forum: http://www.msfn.org/board/index.php?showforum=127

...especially the "Good luck" part

Use the User State Migration Tool to back up documents / settings to a USB key or network location, and then use the same tool to restore after a clean install. http://www.windowsitpro.com/Windows/Articl...1668/41668.html

As for performance monitoring, consider using Perfwiz to configure perfmon for you - it gets everything you need: http://www.microsoft.com/downloads/details...&displaylang=en

A print driver, processor, or monitor is always the culprit. Are you using 3rd party print drivers, or the inbox ones from Microsoft? I strongly suggest using printmig to back up your configuration, running cleanspl.exe to clear the print spooler of all non-Microsoft items, then running printmig again to restore the back up and get your printer working again. If you have any version 2 print drivers, UPGRADE THEM NOW. Those are kernel-mode drivers from the NT4 days, and they can and will crash or hang a Windows 200x server. Upgrade to version 3 drivers ASAP to avoid issues like this. Printmig.exe: http://www.microsoft.com/WindowsServer2003...igrator3.1.mspx Cleanspl.exe: http://www.microsoft.com/downloads/details...&displaylang=en I do also second the question - why are you running print queues on a DC? The print spooler requires a lot of resources when printing, and this can affect how the DC runs due to the fact that the lsass process on a DC also requires a lot of resources, but all of the time. You can get race conditions and server hangs on a busy DC that is also a print server. Consider moving your print operations to a different machine - if you can't dedicate a server to printing, at least don't use a DC . Edit: I can't spell.

Run regmon (www.sysinternals.com) and then install vmware. When it fails, stop the regmon capture (CTRL+E in the regmon window) and look for the installer's access to that key. Is it Access Denied or Not Found? That will tell you whether it's a permissions issue or if the key specified actually doesn't exist...

Bug Check 0x7A: KERNEL_DATA_INPAGE_ERROR Frequently, the cause of this error can be determined from the error status (parameter 2). C000000E literally means "a device which does not exist was specified". This could be a driver issue, a filesystem issue, or even failing disk hardware. I would suggest running chkdsk /f /r on all disks on the system, as well as making sure that you are using the latest WHQL drivers for your disk controller at the very least. I would also suggest, after doing chkdsk on all disks and updating drivers as necessary, running "sfc /scannow" to make sure that you don't have any corrupt system files on the system. Good luck.

If you uninstall your video driver, and just use the standard VGA driver, does the problem go away?

So the problem is every other system restart, or did this just happen once?

Is this machine XP Professional?