Windows 2008 R2 + ESX4 + vCenter Client Console = FREEZE

[joergriether]

Hello,

i reproduced this several times now and also found a coressponding thread in the microsoft newsgroups, ( http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/bc0f3c12-eda7-440... ) so here you go:

Install a fresh W2008 R2 to an ESX4 machine, do this all with vCenter Client Console, not with reomte RDP. Add the role

Remote-Desktop-Services to the newly created W2008 R2 machine, reboot, after reboot when the machine tries to finish

the changes (after logon) it totally freezes.

Now the interesting part on that:

If you log on via RDP after the reboot (oh yeah, you urgently need to turn rdp on before reboot!!!), then

the installer of the role WILL FINISH!!!

Now how strange is that?

Any ideas?

best,

Joerg

[TiloVM]

btw, Also happen with VMware server 2.0.2

[-_DK_-]

Hello and thank you for your email. I am out of the office until July 7. I will not be checking email or voicemail during my absence. You can always get immediate assistance during business hours by contacting the Helpdesk: Phone: 408-369-7585 and select the option for Helpdesk. Email: support@justworks.net Thank you, Dan

[TransennaTCF]

Jeg tillader mig at holde lidt ferie og er derfor ikke på kontoret frem til man. d. 19/7-10.

NB: Vigtige meddelelser bedes rettet til telefon 8819 9990 eller hotline@transenna.dk<mailto:hotline@transenna.dk>

Med venlig hilsen

Thomas C. Fossing

CTO, Partner

VCP, MCITP, MCSE, MCTS

[kfkernel]

Hi,

we had the same problem on Windows 2008 R2 servers running on ESX 4.1, build 258902. We followed instructions posted previously in this thread:

"" I take back what I wrote earlier. I have been able to

install the WDDM driver and so far neither of my Windows 2008 R2 VMs

have locked up! Here was my problem:

1. I did not have the latest VMware Tools installed. Even though

vCenter said that the tools status was OK, I brought up the tools inside

of the VM and they were an older build than ESXi 4.0.0 build 219382. I

upgraded the VMware Tools and now the build numbers match.

2. Per

you must manually browse to "C:\Program Files\Common

Files\VMware\Drivers\wddm_video" folder to install the WDDM driver. If

you only browse to the "C:\Program Files\Common Files\VMware\Drivers"

folder, as suggested in the KB article, when Windows searches for a

driver it will find the incorrect VMware SVGA II driverin the

"C:\Program Files\Common Files\VMware\Drivers\video" folder and install

it. My guess is because v comes before w alphabetically and it installs

the first driver that it finds.

Again, you must manually browse to "C:\Program Files\Common Files\VMware\Drivers\wddm_video" to install the WDDM driver in Windows 2008 R2.

So far I have not experienced the lockedp issue after performing both of the steps above ""

Just wanted to let you know that the problem is still around. Anyone knows about how to inform VMware about this? Because this is clearly a driver issue?

Best regards,

Frej Eriksson

[axmentor]

Thank you for your email. I am unfortunately not able to respond before the end of this week.

Best regards,

Henrik Enk

[jaspain]

I haven't tried ESX 4.1 yet, but with 4.0U2, a default installation of VMware Tools on a new Windows Server 2008 R2 virtual machine leaves the Microsoft Standard VGA Graphics Adapter video driver in place and does not install any video driver from VMware. The tools installation does copy the VMware SVGA driver files to C:\Program Files\Common Files\VMware\Drivers\video and the WDDM driver files to C:\Program Files\Common Files\VMware\Drivers\wddm_video. This is the expected behavior described in KB 1016770. For me the Microsoft video driver performs well enough and never freezes. My sense is that VMware considers this issue resolved or at least adequately mitigated based on KB 1016770. Nothing about this has really changed in about a year.

[jefmes]

Agreed, but as we've all come to agree over the past year+ on this, it's not really "fixed" in any of our opinions, correct?

I personally expect the console of a Server 2008 R2 VM to perform just as well as a Server 2008, Server 2003, or Server 2000 console. Do any of you think that's unreasonable? As much as I'd love to not have to log into the console session, some vendors still don't understand the concept of "Services" and "Please don't make your app run requiring local console admin rights!"