Lab Manager Enable Local Admin Account Vista

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.

sysprep unattend.xml and Lab Manager

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.

XP 64 sysprep issues in Lab Manager 4

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”

Problems with P2V of a physical server

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...

XP mode for Windows 7 no longer requires processor VT

Finally...

From Microsoft

Remote Desktop Error

“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.