I’ve had a few remote people ask how to fix this on their own.

Login to your computer and abort the reboot by doing:

start/run , in that box type in “cmd” (no quotes)

This should bring up a black command box window

In that window type “shutdown /a” this means abort the shutdown.

Once that is done,   Go to this website.

http://www.mcafee.com/apps/downloads/security_updates/superdat.asp?region=us&segment=enterprise

Download the sdat5957.exe to a known location, such as c:\ (root of your c drive)

in the black command window you opened earlier type in “c:\sdat5957.exe /F “  this will run the patch with a “Force downgrade” to the old version of McAfee Dat.

The bad version is 5958, so once 5959 is released, that will probably be a better option that installing 5957, but again it isn’t released yet.

If you can’t go to that website on your PC due to network issues, use a second computer to download the update to a USB key or burn to a blank CD and then use that on your effected PC to repair it.

Good Luck,

I hope they publish the SuperDat for 5959 soon.

It’s really nice that windows has a 20 character username limit, but when you create one longer it doesn’t warn you, it just happily accepts the username that will never work.  Yes there is a registry hack to allow windows to allow longer names, but cmon..put some intelligence into ADUC..

No matter what Intel tells you, it doesn't work with jumbo frames.

Since you can’t modify unattend.xml or really do anything else to keep it enabled through sysprep (which auto disables it)

Do this:

Create %WINDIR%\Setup\Scripts\

Create SetupComplete.cmd (make sure no hidden extensions like SetupComplete.cmd.txt)

Edit that file, put this in there:

net user administrator /active:yes

(optional change password)

net user administrator new_password

After Windows is installed, but before the logon screen appears, Windows Setup searches for the SetupComplete.cmd file in the %WINDIR%\Setup\Scripts\ directory.  If a SetupComplete.cmd file is found, the file is executed. Otherwise, installation continues normally. Windows Setup logs the action in the Setupact.log file.

That should do it, now that Template should keep local admin enabled even after sysprep.

So when the Lab Manager documentation people say don’t modify the unattend.xml, they mean it.  No matter how much you modify it, the changes never make it into sysprep.

After Creating Templates for XP 64 SP1(base) and SP2 in our lab manager install, some percentage of the time after you deploy these templates you can not long into these VM’s, you type in your password, and you are re-prompted for the password.  If you type the wrong password it tells you, but the right password just causes a re-prompt.  After much troubleshooting I found we were not following the best practice of having machines ready to be sysprepped with the Administrator password blank.  After making that change everything works again.  To get the standard password back into the VM, we modified the “c:\Program Files\VMware\VMware vCenter Lab Manager\Tools\CustomizeGuest\Windows\Sysprep\WinXP_64\sysprep.inf” (that your never supposed to modify according to VMware, but i’m a rebel) from: AdminPassword="*” (* means bank) to:AdminPassword="password”

The Server is a fully patched 2003 Server. P2V should be working, everything is full 1GB, all drives are NTFS, nothing funny. I'm doing this all hot by the way, no cold booting, its a production server with no downtime allowed. Each P2V attempt died near the end, it takes several hours, so I was never watching exactly when it died. Checking the logs on the client at C:\Documents and Settings\All Users\Application Data\VMware\VMware Converter Enterprise\Logs\vmware-converter-agent-2.log . Shows me the error :

"Image processing task has failed with PlatformError fault: (1117) The request could not be performed because of an I/O device error.".

Obviously this indicates an I/O error. After some searching I found an interesting fact, if you maintain the size of the original drive the P2V or "import machine" will do a block level copy, and if there are bad blocks, then you can get this error. So if you change the destination drive size, it does a file level copy instead. There is a chance that this server's hard drive has bad blocks, but honestly I don't know. It's an old server, that's why i'm P2Ving it. After making a change to the destination partition size, this fixed my issue and the P2V was finally sucessful.

FYI, this was all done with the latest software, ESX 4.0U1, VC 4U1, etc...

Finally...

From Microsoft

“The connection cannot be completed because the remote computer that was reached is not the one you specified.  This could be caused by and outdated entry in the DNS cache.  Try using the IP address of the computer instead of the name”

I saw this error connecting from Windows 7 Desktops to a specific 2008 Server in the same domain.  The problem was that the clock on the server was wrong.  Once I updated it, it all works again.