Monthly Archives: July 2014

Virtual Desktop Optimisation – Enforcing Windows Visual Effects

Optimisation Type [explain] : user experience (↓↑) / resource optimisation (↑) / functionality (-) / administration (-)

Most people may not realise, but the Windows Visual Effects settings can have a direct impact to the user experience. Ok, that sounds a little too obvious, but it’s more than just turn on and off “eye candies” and making Windows look less appealing. Especially in resource constraint systems, changing these settings can improve on the user experience. The reason is simple, the “nicer” Windows look, the more resources it tends to consume.


Windows_Visual_EffectsNow, user experience in this post can mean 2 aspects; 1. experience in how nice Windows look and feel, and 2. experience in terms of how responsive and smooth the movements and animations are. This post talks about optimising for Virtual desktops, which by default means reducing (1), and increasing (2). The main reason we want to optimise this is for (2) and to reduce resource consumption due to these Visual Effects.

Virtual desktop performance has one more dimension which is never really an issue for physical machines, that is network. By reducing the amount of animation, and screen redraws, there will be less pixel changes to be sent across the network. Thereby reducing the network bandwidth requirements. Regardless of display protocol, this should stand true.

If you have ever used Webex, you might have notice a screen flicker when you first share your desktop to the web audiences. Did you realise that Windows might have looked a bit different after that? or if you try dragging a window, you only see grey border that is being dragged. You no longer see window contents while dragging. This was done to reduce the amount of changed pixels that have to be sent from your computer to all the audiences.

By default, Windows will try to choose what’s best for your computer. It determine this by various means, such as hardware capabilities, and by executing the Windows Experience Index. On a typical home PC, these are done automatically and the individual settings can change without you noticing.

Now, in virtual desktop world, we would not leave this to chance, and would want to ensure that the display protocol is loaded as little as possible. This leaves a big opportunity for us to tune the visual effects.

In a Windows 7 optimisation guide published by Microsoft, one of the options recommended is to tune the Visual Effects settings.

So, what are the settings I would recommend for a VMware View virtual desktop deployment? I have 2 answers.

  1. If users are keen to go all out for the most optimised Windows desktop; I would choose Adjust for best performance. This essentially turns off everything, which also reverts Windows 7 to look a bit like Windows XP (as some would put it).
  2. I have some users (including myself) who would really like to optimise everything, but still maintain at least a Windows 7 look to the desktop. In this case, we have to opt for a Custom selection where everything but Use visual styles on windows and buttons, has to be disabled.

Now, if the choice is #2, there is one more thing to watch out for. Part of  the VMware Windows Optimisation guide actually recommends disabling the Windows Themes service. We have to keep the service running in order for Windows 7 desktop to keep its look.



Now, we know what we want to achieve, question now is how it can be done?

This is a tricky one as it is a user based configuration, and not quite something that you can update via changes to a parent desktop image. Well, yes we can update the default user profile in Windows 7, but these settings will only be made default for users who are getting their profile created for the first time on log on. So, for users who already have existing profiles, such a change will not impact them. Additionally, even if new users are being created with an altered default settings, they can probably still have the ability to change it.

Group_Policy_PreferencesSo as with all things to be “forced upon” the users, the most effective way is to apply this via a GPP (Group Policy Preferences). This can only be done from Group Policy Management on a Windows 2008 server, and is not found on the local group policy editor (gpedit.msc). Create a new or update an existing GPO as normal, and edit it.

In the Group Policy Management Editor, navigate the nodes User Configuration > Preferences > Windows Settings > Registry. Yes, there is no nice GUI drop-down-click-click way to configure this. It has to be done by means of changing registry keys.

Next, is to slowly provide the registry keys and the values to be changed. There are many blog posts out there which you can get a comprehensive list of settings and values you can set. I’ll leave you to google that out. Instead I’ll give you the exact settings I’ve configured to achieve #2.

If you need more guidance to create the registry entries, this is a pretty good guide I found.

Now, I have read in many places that these settings can be changed in registry, but may not take effect in Windows. This is partially true. When I first tried to do this, I simply tried importing a .reg file but nothing changed. This method of applying via Group Policy works, and I have tested it.

(REG_DWORD) VisualFXSetting = 3

(REG_SZ) TaskbarAnimations = 0
(REG_SZ) ListviewAlphaSelect = 0
(REG_SZ) ListviewShadow = 0

[HKEY_CURRENT_USER\Control Panel\Desktop]
(REG_BINARY) UserPreferencesMask = 9012038010000000
(REG_SZ) DragFullWindows = 0
(REG_SZ) FontSmoothing = 0

[HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics]
(REG_BINARY) MinAnimate = 0

(REG_SZ) ThemeActive = 1
(REG_EXPAND_SZ) DllName = %SystemRoot%\resources\themes\Aero\Aero.msstyles


I hope this post is able to help you out in some way. If you find it useful, please do share it and let me know.

[Update 20141130] corrected typo for “VisualFXSetting” – it had an extra “s” at the end.
[Update 20150410] If you are looking for settings for Windows 8.1, they are found here.
[Update 20150425] corrected typo for “WindowMetrics”

Horizon 6 with View – Unofficial Configuration Maximums

I have to start with a disclaimer that this post (and this blog) is not an official guidance from VMware. As my personal practice, I will always try to substantiate what I say & write with official documentation, KB and my experience.

Horizon View has gone through lots of improvements over the years and there is always some changes with each release. I will attempt to list down these maximums for Horizon View 6 in this post. These are numbers that I will use in my engagements and you should do your own due diligence and not take mine for granted.

Do remember that View operates on top of vSphere and so some configuration maximums actually depends on vSphere.

For the purpose of this post, we are looking at Horizon View 6.0 and vSphere 5.5.
The vSphere Configuration Maximum document is found here.
The Horizon 6 Documentations are found here.

Architecture Component : View Pod

Item Maximum Remarks
View Connection Servers 7 support info
View Security Servers As Needed related post
Pod Concurrent Sessions 10,000 combined desktops & hosted apps
vCenter Servers As Needed related post
View Composer Servers One per vCenter Server
View Desktop Blocks As Needed related post
RDS Hosts ?? coming soon…

Architecture Component : View Connection Server, View Security Server

Item Maximum Remarks
Direct Connection (PCoIP,RDP) 2000 Connection Server only; support info
Tunneled Connection (PCoIP,RDP) 2000 Both Servers; Hard Limit
Tunneled Connection (Blast) 800 Both Servers

Architecture Component : Cloud Pod Architecture

Item Maximum Remarks
Number of Sites 2 Tested Soft Limit
Number of Pods 4 Tested Soft Limit
Concurrent Sessions 20,000 Tested Soft Limit

Architecture Component : Storage

Item Maximum Remarks
Unique Parent VM Snapshot to Replica per Datastore 1 Based on Experience; related post
Powered on VMs per VMFS Datastore 2048 vSphere Maximum
VMs per VMFS Datastore (no VAAI) 64 Based on Experience; I haven't challenged this limit
VMs per NFS Datastore varied advised by storage vendor
Maximum Linked Clones per Desktop Pool 2000; common deployment is 1000 Depends on View Composer Server Capacity; see here; related post"

Notice that I have not mentioned the maximum number of linked clones per datastore. As my understanding this is actually dependent on vSphere, and so the vSphere configuration maximum is the appropriate one to follow.

Mirage Windows Migration – where are the files?

This is an interesting experience which I thought I share with the rest of the world.

I’ve been involved in some projects to migrate computers from Windows XP to Windows 7 using VMware Mirage. The greatest benefit of which is that the actual migration is expected to be fairly easy and straight forward. However, there can be road bumps along the way, one of which I will write about in this post.

This environment is in the healthcare sector and has a classic combination of Windows XP with Symantec Endpoint Protection. I am already aware that there are known protections which SEP puts in place which can interfere with USMT operations. Read more about that here. With that, we have well prepared in advance to make sure that VMware Mirage processes are appropriately configured to be “safe listed” in SEP, so that Tamperproof Protection ignores the actions of Mirage processes.

Interestingly enough, our test migrations failed to migrate the user profiles. We can see that in C:\Users\ all the user profiles have been created, but they are all blank. We expect everything to show up.

Further tests showed that if we were to stop SEP prior to migration, the profile migration will be successful, except that Microsoft Outlook profile goes missing.

Mirage and USMT logs will show that USMT exited with errorcode 71.

SEP logs did not show any errors related to Tamperproof Protection.

Eventually, thanks to the missing Outlook profile, it prompted me to go back and check if the USMT hotfix was correctly applied. (That’s the main reason to apply the patch in the first place) It turned out to be the real issue! The USMT hotfix was only applied to the x64 folder of USMT, but not the i386. The tests we have been doing are on 32bit desktops. We applied the patch and proceeded to test migrate.

True enough, all migrations thereafter were successful, even without the need to disable SEP. The culprit all along was a bad USMT upload.

So, if anyone needs this information, it is listed down below.

  • Microsoft USMT 4 Hotfix URL –
  • Make sure you get 2 files – 32bits – 427161_intl_i386_zip.exe & 32bits – 427161_intl_i386_zip.exe
  • Follow the instructions to extract the files and replace the files in the respective USMT folders


VMware Mirage migration with Symantec Endpoint Protection

VMware Mirage is a very powerful tool that does wonders with Windows migration, and should be in the arsenal of every enterprise desktop admin.

In recent projects I’ve worked on, I came across customers with Symantec Endpoint Protection (SEP). Though a great AV product and has nice capabilities, there is something it does that can cause headaches to the migration team. Although the experiences are for Windows XP to Windows 7, I would expect it to be the same with migration from Windows 7 to Windows 8 and above.

The issue that is likely to happen is that after migration, user profiles remain empty. So when users login to their endpoint after migration will not see their files in their “My Documents”, “Desktop”, etc. The files are not gone, but just not properly migrated over from the old “Documents and Settings” location to “Users”.

This happens because of SEP’s tamperproof protection. Details on setting up tamperproof  protection found >

Mirage makes use of Microsoft USMT to execute the migration of user profiles. What gets tricky is that SEP’s Tamperproof Protection will get in the way of USMT, and so prevents USMT from doing it’s job.

VMware has recognized this issue and published a KB article I will let you read up there on the possible workarounds that can be applied. There are also 2 versions of SEP which Mirage will be able to automatically disable during USMT process.

Now, my experience tells me that SEP is not the only reason USMT migration can fail. Watch out for the next post which goes into the other possible reason why USMT can fail.

Linked clones falling off the domain

This is something I’ve seen before and someone just posted the question. I thought I’ll share my answer here in case any one of you out there hits the same issue.

This is something unique to linked clones, and I do not expect it to happen with any other types of View desktops.

The issue is this, a user tries to login to a View Virtual Desktop and is presented with the following message. (Sorry no screenshot here)

“The SAM database on the Windows Server does not have a computer account for this workstation trust relationship”

This basically means, the desktop thinks it is on the domain, but the Active Directory does not agree. As a result, when a user tries to login with a domain account, it fails.

Now why does this happen?

In any standard windows machine (desktop or server, physical or virtual), if that machine joins to an AD domain, a computer account is created. This account has a password that is known to the computer itself, and of course the directory. What happens if the password changes, or the account gets deleted off the domain? The machine at the other end does not know about it, and so keeps trying to login with the credential it knows. But of course, the directory will reject those logins since the credentials do not match.

This is exactly like the situation where an admin changes your password (or deletes your account), but doesn’t tell you.

So, how can this happen if the sys admin from hell wasn’t let loose?

There are many possibilities, but I shall focus on one particular type of event. Time traveling virtual machines! No, I don’t mean time drift, but snapshots!

Every virtual infrastructure admin will love the capability of snapshots (as well as hate them). Yes, it’s a double edge sword.

Think about this scenario.

  • Monday 3pm – a snapshot was taken due to an upcoming change, and the snapshot is for an easy revert [computer password at this point is : just@password]
  • Tuesday 4am – the Windows VM has reached the time to change the password (it has a default 90 days lifetime), and the Computer Account password gets changed [computer password is now : new@password]
  • Over the next few days, things are working just as normal, no issues.
  • Friday 2pm – a critical issue was discovered and a decision was made to revert back to snapshot [computer password before revert is : new@password]
  • After snapshot revert – the error appears, and no one can login to the machine with an AD credential [computer password now is : just@password; but in the AD it is still new@password]

So, that is a situation we don’t want to be in isn’t it? Of course to fix it, one of the easiest way is to re-join the machine back to the directory.

So, how is this relevant to linked clones?

Linked clones all have a refresh point that is created once provisioning is completed. This is where the virtual desktop will always revert to as part of the refresh operation. So in some ways, it’s very much like a snapshot revert. As a result, it will eventually be subjected to the scenario above.

To avoid that, VMware engineers have cleverly added a small 20MB disk to every linked clone. This disk does not get affected by refresh operations and is used to store the computer password for the linked clone. As a result, it is safe to always allow a refresh of a linked clone, and yet not have the computer fall off the domain.

So long introduction to the issue. Question now is why, even with this clever trick, some linked clones can still experience this issue?

I have seen a few cases that it is due to security software that customers want to install in the virtual desktop. Some prevent the disk to be accessible and so the virtual desktop is unable to retrieve the password; and so login fails.

I have also seen admins who have no idea where that disk came from and thought it should be removed. Oops!!

What ever it is, you need to know the importance of that little but non-trivial disk, and have that checked out if you ever encounter this problem.