Archive for September, 2010
AutoView: Most Underrated View Tool?
Sep 29th
In my journey to find the best method to convert an old workstation into a thin client for our View deployments, I came across many solutions before we came upon AutoView by Justin Emerson at VM Junkie. AutoView is a series of scripts and registry edits that convert an XP machine into a thin client in minutes with only one click.
The general premise of what it does is:
1. Create a user called ‘user’ and temporarily adds this user to the Administrator group so it can make the necessary registry changes.
2. Modify the Winlogon registry settings for the local machine so that ‘user’ logs on automatically, and that upon the next reboot another batch script executes.
3. Reboots the system.
4. After reboot, it sets a VBScript to execute the View client in a loop as ‘users’s logon shell. This makes it so that the user only sees the View client, and not the start menu, etc. It also disables Task Manager, Lock Workstation, and Password Change options from the Ctrl+Alt+Delete menu.
5. It then removes ‘user’ from the Administrators group and reboots the system.
6. The system now boots up, auto-logs into the ‘user’ account, and only shows the View client to the user.
If the View client is exited, it simply re-opens automatically. If you need to get to the Administrator account or to another account, simply Ctrl+Alt+Del and hold down ‘Shift’ while clicking Log off. This will exit you out to the normal Windows logon screen. If shift is not held down, it simply logs back into the user account.
The great thing about this is that you can convert someone’s existing workstation and leave it untouched in case they are unhappy with their virtual desktop. All you have to do is make it so the ‘user’ account doesn’t auto-login which can be done by modifying the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ForceAutoLogon key to 0 then they’re back to their regular desktop.
Overall, this has been the perfect solution for us in our deployments without hardware thin clients. It may not be perfect for everyone, because you’re still using a Windows license on the underlying system, but that is not a problem for our environment.
More information on AutoView from the Author’s blog: Part 1, Part 2.
Other Solutions
I won’t go into detail with these, because we didn’t choose to pursue them after initial testing, but I will give my general impressions.
We use several Wyse thin clients, so we did explore their PC Extender solution. We tested this, and came out generally unimpressed. You could tell it didn’t get a lot of TLC from Wyse, which I suppose makes sense… they would obviously prefer you to buy their hardware thin clients. The setup and implementation wasn’t great, and they would only support a limited number of PC makes/models. It definitely has potentional.
We also considered Devon IT’s VDI Blaster, which was an impressive product. It didn’t have quite the amount of polish I was hoping for, but it was a solid solution. Once issue we ran into is that the hostname of their management suite was hard-coded into the software and required a bit of work to fix.
Lastly, another option is ThinLaunch. This software does literally the exact same thing that AutoView does. There are no features in ThinLaunch that are not provided by AutoView. If you don’t believe me, feel free to watch their video demonstration. The real problem with this? It costs $25 per computer, and AutoView is free and modifiable.
View 4.5 vs. Read-Only Domain Controllers
Sep 13th
When trying to update our Automated Pool after upgrading to View 4.5, we ran into an issue where the virtual desktops being provisioned would fail with an error saying they could not join the domain. If we logged into the virtual desktops through the vSphere client, the machine were actually, in fact, on the domain.
Checking the C:\Windows\Temp\vmware-viewcomposer-ga-new.log file, we could see the following error:
2010-09-10 10:13:08,284 [3636] FATAL CSvmGaService – [svmGaService.cpp, 116] Domain join failedError 1265 (0x4f1): The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
We had full rights to join the domain with the account in question, and we didn’t have any problem using our QuickPrep settings with 4.0.1, so this was quite a mystery. We called VMware Support, and we ran through several troubleshooting routes with no avail. Eventually, through the VMware Communities forum, a VMware employee suggested we try Microsoft KB 944043. The patch provided within this KB is not applied by default with normal updates.
It appears that in 4.5, VMware has modified the QuickPrep process which causes this issue to occur. Luckily, this is an easy fix if you know about it.
View 4.5 First Thoughts
Sep 12th
View was released around 9pm on Thursday, and I had our environment upgraded shortly there-after. We don’t have a ton of users on virtual desktops yet, and VMware is typically very good about not releasing unstable products, so why not? 
Upgrade Process
The upgrade process is very easy, as described in the View 4.5 Upgrade Guide. It’s, more of less, simply a matter of launching the executables on each of your nodes (connection server(s), security server, vCenter server, and desktops). The only part that I wish was a little less cumbersome is upgrading the agents on Individual Desktops. The upgrade guide specifically says:
If you use full-clone desktops or other virtual machines that you added as individual desktops or as part of a manual pool, upgrade View Agent by using whatever third-party tools you usually use for software upgrades.
I think VMware kind of “passed the buck” in this regard. We just upgraded all of our individual desktops manually. It was kind of tedious, but luckily we didn’t have too many. Rolling out the updated agent through recomposing our linked clones was much easier: simply update the master image, create a new snapshot, point to that snapshot, recompose. The agent essentially becomes a core piece of the operating system, it would be nice if they had a more automated-way even if it was similar to how VMware Tools upgrades work.
New View Manager Interface
The interface has been completely revamped with this release, and it is entirely for the better. It now requires Adobe Flash to be installed to view it, however.
One of the best new features if the ability to manipulate User Data Disks much more easily. You can detach them and attach them all now through the Persistent Disks tab under the Inventory section. This is particularly useful if you want to delete a VM, but re-use the UDD on a new VM. It is unfortunate RTO Virtual Profiles did not make it into this release, but this certainly makes dealing with UDDs much less cumbersome.
View Manager Event Logging
When you log into View Manager for the first time after the upgrade, you will notice it wanting you to configure the event database. You will need to point it to a supported Database server type specifically for it to store logs. Information will now be stored to this database, such as users logging in/out of virtual desktops, login audits for View Manager, generic stats like maximum number of users with concurrent desktop sessions, adding pools, composer events, etc. You also have to ability to export the log data to third-party log analysis tools. It’s a very nice addition.
Windows 7 Support
In View 4.0, Windows 7 was listed as experimental. They would still offer support for it, but the quality wasn’t quite there. In 4.5, Windows 7 is now completely supported, both as a client and as a virtual desktop. We didn’t have any problems with 4.0 and Windows 7, but 4.5 does feel snappier. Maybe it’s all psychological, though.
Other features
This is the first release with a Mac version; it only supports RDP, just like the Linux client. One of the non-noted features in View 4.5 is that the Windows View Client now has the ability to Auto-Connect USB devices. The graphics for all of the features now have a more polished professional look, as well.
Some more additions in View 4.5 that I haven’t had a chance to tinker with directly are:
Tiered storage. By placing the Replicas on a separate storage device from Linked Clones, they can be shared by all Linked Clones. You can also use high performance solid-state disks (SSDs) to improve recomposition performance.Local Mode or Type 2 hypervisor. Formerly known as Offline Desktop, Local Mode provides encrypted, encapsulated, and uninterrupted desktop services. IT professionals have full control on data synchronization, replication schedule, or deployment policies including Local Only smart card access, USB access, and more.Smart card and two-factor authentication. By adding your root certificate from a domain certificate authority, you can secure your organization’s workstations with smart cards and smart USB tokens.
Summary
Overall, this is a solid release. Were there tons of new revolutionary features and extensions added? Not really. They did, however, put an immense amount of polish on View 4.0. I believe it is a solid release, and that View is heading in the right direction. It is definitely worth upgrading.
Direct Connections and View Security Server
Sep 8th
When using Wyse thin clients, specifically WTOS and TCX, they require that you enable Direct Connections to the Virtual Desktops for full functionality, as listed in the VMware View and WTOS Best Practices Guide.
Unfortunately, this creates a problem when using the View Security Server. This is because if you’re using direct connections, what is trying to occur is for your client to directly connect over port 3389 to the Virtual Desktop. If you try to connect through the Security Server with this enabled, you will be able to log in to the portal, select your VM, and even select Connect, but that is when it fails. This is because there is no way for your external machine to connect directly to the internal virtual machine via RDP with most firewall/networking practices, and making a rule to allow this is not generally a good idea. (Note: Connections will work if, for some reason, you are trying to connect through the Security Server from inside.)
Fortunately, this is a relatively easy fix, and the best way to fix it is to simply create a Replica Connection Server with Direct Connections not enabled, then link your Security Server to that Replica. This causes your Security Server connections to not pass directly to the VM, but your Wyse devices will still use the main server and get the benefits of direct connections. Setting up a Replica is fairly straightforward, and outlined in the View Manager Administration Guide.
UPDATE: In View 4.5, they have changed the terminology for this. Now you need to disable “Use secure tunneling” for TCX to work properly.