I spent the weekend ripping apart the lab and rebuilt my lab ESX hosts as 4.1.  I wanted to build some new templates since the old ones were a bit long in the tooth, so the first one I spun up was a Windows Server 2008 R2 VM.  I did the typical - ran through the new VM wizard, attached the ISO, installed Windows and loaded the VM Tools... all normal stuff.  But then I noticed that the mouse performance was really sluggish.  I checked all the old tricks - the Display Properties -> Troubleshooting bar... check.  Mouse shadowing... off.  Tools actually loaded... check.  Hmmm...

A quick Google (or "Bing" for the Microsoft-centric out there) revealed a few others who've seen this also.  I checked the display adapter and sure enough, I was stuck on the Standard Display Adapter...

Initially, I tried updating the driver using the normal search paths, but it kept telling me I had the proper driver - which I knew I didn't.  I manually entered the driver location using the VMware Tools driver path:

C:\Program Files\Common Files\VMware\Drivers

This updated the driver to the VMware SVGA 3D (Microsoft Corporation WDDM) driver, as seen below:

A quick reboot later and I was on my way - problem solved! Apparently this is an issue in Windows 7 and Windows Server 2008 R2 on ESX 4.1.  It was introduced with a virtual hardware update they made in this new release.  Windows Server 2003 and other Windows versions seem fine - just these.

This is a small tidbit of information, but it was quite a nuisance so I hope to help someone out there who's had this.

A Note to VMware: I must say this is pretty disappointing.  In every past version, there's never been an issue where a less than optimal driver is loaded by default.  It's not that easy tracking down why, particularly since it only happens on these two releases of Windows (that I've found this far). I would hope that this is addressed in the near future.

The Hyper-V Best Practices Analyzer (BPA) is the latest in a line of BPA tools from  Microsoft that have been released for various systems since 2007 that scans a the Windows  system and identifies protential areas of configuration or policy that don't align with  Microsoft-recommended best practices.

While it isn't a life-changing tool, it is handy to quickly identify something that you may  have overlooked, particularly once the environment expands.

While perusing the web, I stumbled across a nice "experimental" feature of the VMware VI 2.5 client that allows you to use your logged on Windows credentials to automatically log onto VirtualCenter.  OK, so this may not be big news for everyone and it's not like this is a huge secret, but I find it quite handy.  To try it out, create a shortcut to the VMware Infrastructure Client (or modify the default one) to include the following bold text in the target field:

"C:\Program Files\...\VpxClient.exe" -s VCServerName -passthroughAuth

...where VCServerName is the name or IP address of the VirtualCenter server.

This is a four-part article I wrote for MSTerminalServices.org last year. Parts one and two focus on common server-related licensing issues. Part three covers more obscure server-related issues such as corrupt license server databases and activation issues. Part four looks at licensing-related issues from the client side.

The flow of this article series works best when read as one document, but the publishing guidelines for MSTerminalServices.org place restrictions on the length of a particular article, which is why they end up broken into several segments. The links to all four segments are below:

• Troubleshooting Terminal Server Licensing Issues (Part 1)
• Troubleshooting Terminal Server Licensing Issues (Part 2)
• Troubleshooting Terminal Server Licensing Issues (Part 3)
• Troubleshooting Terminal Server Licensing Issues (Part 4)

This two-part article that I wrote for MSTerminalServices.org discusses providing redundancy and high-availability for your Terminal Server License Servers.  Part one focuses on establishing redundancy for the licensing infrastructure while part two covers ensuring you have easy recovery in the event of a license server failure.  Both segments are available at the following links:

• Terminal Services License Server High-Availability and Recovery (Part 1)
• Terminal Services License Server High-Availability and Recovery (Part 2)
  

This is another article that I wrote for MSTerminalServices.org detailing the license server discovery process.  I have noticed through numerous forum posts that many administrators are still puzzled as to why their license servers are not found by terminal servers in their environment.  Part one describes the available roles for your license server and how the discovery process differs based on the role selected, including detailed flowcharts.  Part two offers advice on better-controlling the process and some troubleshooting tips when things don't go as planned.

• Terminal Services Discovery Process - Part 1
• Terminal Services Discovery Process - Part 2
  

In this two-part article that I wrote for MSTerminalServices.org, I cover the details of how the Terminal Services CAL allocation process functions in both per-device and per-user terminal server modes.  Part one covers the overview of CAL types and server licensing modes, while part two details the step-by-step process for allocating CALs, including in-depth flowcharts.  Check it out over on MSTerminalServices.org.

• Terminal Services CAL Allocation Process - Part 1
• Terminal Services CAL Allocation Process - Part 2
  

As I said before, I have been doing a lot of writing for msterminalservices.org.  I figured it was time for me to do some "cross promoting", or rather just let everyone know that these articles exist, so I will be linking to all of them as I go.

This article delves into using Windows Performance Monitor (or PerfMon) to create a baseline of your terminal servers/Citrix servers to refer back to when performance problems arise.  Too often, performance problems can be difficult to diagnose when issues crop up because no one bothered to examine what the performance stats looked like when things were running normally.  In this two-part article, you'll which counters are important and what they mean.

• Using Windows Performance Monitor to Baseline a Terminal Server (Part 1)
• Using Windows Performance Monitor to Baseline a Terminal Server (Part 2)