Posts tagged view
VCP5-DT Exam Experience
Dec 8th
In July of 2011, I took and passed the VCA-DT exam based on View 4.x; however, I figured it was time to go ahead and update to the VCP-DT on View 5.x. I found a 25% off exam coupon on Twitter around Thanksgiving time, so I went ahead and scheduled it using that (I’ve seen these floating around frequently and it usually states for the VCP specifically but also applies to VCP-Desktop and VCP-Cloud, from my experience).
Due to Holidays and travel plans, my study time was a little cramped but was able to put together some notes based on the blue print and study some great resources that others in the community have put together. The following are the resources I used:
- VMware Community Member jkpk’s VCP5-DT Notes – Security Guide, Administration Guide, Installation Guide, and Architecture Planning Guide
- SpeakVirtual’s VCP5-DT Blueprint Study Guide
- My personal VCP5-DT Exam Notes
- Official VMware View 5.1 Architecture Planning Guide
- Official VMware View 5.1 Installation Guide
- Official VMware View 5.1 Administration Guide
- Official VMware View 5.1 Security Guide
As far as my experience, I arrived at the testing center early, but myself and others (who were taking things like TSA exams, Microsoft exams, and Cosmetology exams) weren’t able to begin until an hour or so later due to the proctor arriving late. I thought the test was challenging but passed with a pretty good score so in the end it all worked out. I was able to finish with about 45 minutes left of the total 90 minutes allowed. I hope the aforementioned documents prove helpful, and I wish the best of luck to all others in their efforts to obtain this certification!
Working with Error’d Desktops
Mar 23rd
This tip is a pretty simple one, but can be confusing to some. For example, when a delete fails, it’s natural to want to just click delete again. To that point, in the past, I have seen virtual desktops go into the ‘Error’ state when deletions or recomposures fail. For example, a recompose failed because it couldn’t join the domain due to the DHCP range running out of addresses, and I know what went wrong and just want to do the operation again.
Trying the same operation again won’t do anything. Getting back to a good state, assuming the root cause has hopefully been resolved, is accomplished via a simple refresh:
We can, assuming deletion was our goal, then re-delete the desktop and it should do so cleanly:
VMware View iPad App Updated to v1.2
Oct 24th
The latest version of the VMware View app has been released for both the iPad and Android. Several new documented changes in this version, as well as some other slight undocumented modifications. Here is the documented list:
- Optimized for VMware View 5 with improved performance
- Support for iOS 5 including AirPlay
- Presentation Mode for use with external display and AirPlay
- Embedded RSA soft token simplifies login to desktop
- Background tasking to move between Windows and iOS apps
- Updated look and feel
- Integrated online help
- Buffered text input for multibyte text entry
- Now in French, German, Japanese, Korean, Simplified Chinese
- Bug fixes
The three bolded are my top choices for best new features. It was a complete pain having to reconnect when switching between apps, and made me almost not want to even use it. I’m very happy to see that is now fixed.
The included online help is also a blessing as it gives novice users (which should be a large portion of the userbase of this app, if VDI is successful) a way to figure out how to maneuver and operate the application.
Lastly, Presentation Mode will be very handy for a lot of users.
Two of the undocumented features that I have noticed are:
- Passwords are no longer savable. You must authenticate every time you log in. Previously you could save the password to the iPad, but this was removed for security reasons.
- The screenshot of desktops used as icons for the specific Virtual Desktops is now blurred, which is likely for security reasons as well.
Introducing the EVGA PD02
May 28th
Earlier this year, EVGA released a new VMware-Certified Zero Client dubbed the PD02. It uses the same chipset as the products it competes with, notably the Wyse P20, Dell FX100, and others; this means it is functionally the exact same.
The form factor is different as it comes in a small cube as opposed to the traditional blocky design. However, the biggest difference is the pricing: $299. The other units are at least 25% more expensive with the Wyse P20 listing on CDW for as much as $419.99. When purchasing hundreds of these units, that amount can really add up. For a 600 seat deployment, that’s a whopping $72,000 saved.
The unit has an aluminum casing on the sides which acts as a heat sink. While this may do a great job at accomplishing its goal of cooling the unit, it also does a great job at making it uncomfortable to touch. A non-scientific heat gun reading listed the unit as around 110 degrees (F). It’s not unbearable, but it is certainly unpleasant to hold after it has been on for awhile.
The unit can be managed via the Teradici PCoIP Management Console just as all other units that use the Teradici chipset. It can also use the firmware directly from Teradici like the others. It does not come with a keyboard or mouse similarly to the FX100; it is worth noting the Wyse P20 comes with PS/2 versions of both.
It will be interesting to see how other manufacturers respond to this unit, but hopefully this will drive down the pricing for zero clients. I am a huge proponent of zero clients over thin clients or re-purposed desktops as the experience among the three is night-and-day with the zero client coming out far ahead of the others. Lowering the cost of these units will increase their deployment numbers and be better for View-based VDI deployments.
User Resetting Desktop Breaks Recompose
May 16th
We ran into an interesting incident today where we were attempting to refresh/recompose a user’s desktop to try to resolve an issue. When the recompose was initiated, it seemed like there were a lot of virtual machine resets involved in the process; definitely more than the usual, but Composer does initiate these so it isn’t all that out of the ordinary. vCenter was upgraded to 4.0u3 mere hours before, so it was thought that maybe something changed in the process.
After a little troubleshooting, other desktops seemed to recompose fine and new desktops recomposed fine as well. The desktop in question would just keep reseting in an infinite loop, though. In the View Admin portal, the desktop would stick at ‘Customizing’. It wasn’t until we stopped all the tasks and let it sit for a few minutes and it still happened until it became obvious what the issue was:
It turns out that a very proactive user was resetting their desktop every minute or so trying to expedite the fix we were trying to put in place. As soon as we had them stop resetting the desktop, the recompose finished flawlessly. Be sure to utilize maintenance mode for the desktop to avoid this.
Comprehensive List of VMware View Firewall Rules
May 14th
Getting firewall rules correct for View can be one of the more tedious tasks to do right. If things aren’t done right, you can run into lots of odd issues. It seems like the majority of installation problems arise due to firewall rules not being exactly as needed. The following is a list of all of the firewall rules that need to be created which was gathered from various sources by VMware Employee/Author of That’s My View (http://www.thatsmyview.net); all credit for the below should go to his original article.
Also, be sure to follow the great Setting up PCoIP Remote Access with View 4.6 guide if you run into further PCoIP issues after ensuring the firewall rules are configured as below.
Perimeter Firewall Rules
| Source IP | Source Port | Direction | Destination IP | Transport Protocol | Dest. Port | Application Protocol | Comment | Type |
| <EXTERNALCLIENT> | <CLIENTPORT> | Inbound | <SECURITYSERVER> | TCP | 80 | HTTP | Used if SSL/HTTPS is not used on the Security Server | Optional |
| <EXTERNALCLIENT> | <CLIENTPORT> | Inbound | <SECURITYSERVER> | TCP | 443 | HTTPS | Communication between View Client and View Security Server. Authentication etc. | Mandatory |
| <EXTERNALCLIENT> | <CLIENTPORT> | Inbound | <SECURITYSERVER> | TCP | 4172 | PCoIP | PCoIP Connection Establishment | Mandatory |
| <EXTERNALCLIENT> | <CLIENTPORT> | Both | <SECURITYSERVER> | UDP | 4172 | PCoIP | PCoIP Data Transmission | Mandatory |
DMZ Firewall Rules
| Source IP | Source Port | Direction | Destination IP | Transport Protocol | Dest. Port | Application Protocol | Comment | Type |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 8009 | AJP13 | AJP-Data Traffic | Mandatory |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 4001 | JMS | Java Messanging | Mandatory |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 80 | HTTP | Used if SSL/HTTPS is not used on the Transfer Server | HTTPS prefered |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 443 | HTTPS | Communication with Transfer Server for the Offline Usage of VDIs | |
| <SECURITYSERVER> | <CLIENTPORT> | Both | <VIEWAGENT> | UDP | 4172 | PCoIP | PCoIP Data Transmission | Mandatory |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 3389 | RDP | Remote Desktop Protocol | Optional |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 4172 | PCoIP | PCoIP Connection Establishment | Mandatory |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 32111 | USB-Redirection | Optional | |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 9427 | Multi Media Redirection, RDP-Connections only | Optional |
Connection Server Rules
| Source IP | Source Port | Direction | Destination IP | Transport Protocol | Dest. Port | Application Protocol | Comment | Type |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <ACTIVEDIRECTORYSERVER> | TCP | 389 | LDAP | Active Directory Authentication | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <ACTIVEDIRECTORYSERVER> | UDP | 389 | LDAP | Active Directory Authentication | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <CONNECTIONSERVER> | TCP | 4100 | JMSIR | Inter-Server Communication | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <CONNECTIONSERVER> | TCP | 389 | LDAP | ADAM | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <CONNECTIONSERVER> | TCP | 636 | LDAPS | AD LDS | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <CONNECTIONSERVER> | TCP | 1515 | Microsoft Endpoint Mapper | Mandatory | |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <CONNECTIONSERVER> | TCP | 4001 | JMS | Java Messanging | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <CONNECTIONSERVER> | TCP | 8009 | AJP13 | AJP-Data Traffic | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <TRANSFERSERVER> | TCP | 8009 | AJP13 | AJP-Data Traffic | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <TRANSFERSERVER> | TCP | 80 | HTTP | Used if SSL/HTTPS is not used on the Transfer Server | HTTPS prefered |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <TRANSFERSERVER> | TCP | 443 | HTTPS | Communication with Transfer Server for the Offline Usage of VDIs | |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <TRANSFERSERVER> | TCP | 4001 | JMS | Java Messanging | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <TRANSFERSERVER> | TCP | 4100 | JMSIR | Inter-Server Communication | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <TRANSFERSERVER> | TCP | 8009 | AJP13 | AJP-Data Traffic | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <VCENTERSERVER> | TCP | 18443 | SOAP | View Composer Communication | Mandatory |
| <CONNECTIONSERVER> | lt;CLIENTPORT> | Outbound | <VCENTERSERVER> | TCP | 443 | HTTPS | vCenter Communication | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Both | <VIEWAGENT> | TCP | 4001 | JMS | Java Messanging | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Outbound | <RSASERVER> | UDP | 5500 | RSA Secure ID Authentication | Optional | |
| <INTERNALCLIENT> | <CLIENTPORT> | Outbound | <CONNECTIONSERVER> | TCP | 80 | HTTP | Used if SSL/HTTPS is not used on the Connection Server | HTTPS prefered |
| <INTERNALCLIENT> | <CLIENTPORT> | Outbound | <CONNECTIONSERVER> | TCP | 443 | SSL | Communication between View Client and View Connection Server. Authentication etc. | |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 8009 | AJP13 | AJP-Data Traffic | Mandatory |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 4001 | JMS | Java Messanging | Mandatory |
Transfer Server Rules
| Source IP | Source Port | Direction
|
Destination IP | Transport Protocol | Dest. Port | Application Protocol | Comment | Type |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 80 | HTTP | Used if SSL/HTTPS is not used on the Transfer Server | HTTPS prefered |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 443 | HTTPS | Communication with Transfer Server for the Offline Usage of VDIs | |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 80 | HTTP | Used if SSL/HTTPS is not used on the Transfer Server | HTTPS prefered |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 443 | HTTPS | Communication with Transfer Server for the Offline Usage of VDIs | |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 8009 | AJP13 | AJP-Data Traffic | Mandatory |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 4100 | JMSIR | Inter-Server Communication | Mandatory |
| <SECURITYSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 4001 | JMS | Java Messanging | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 4001 | JMS | Java Messanging | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 4100 | JMSIR | Inter-Server Communication | Mandatory |
| <CONNECTIONSERVER> | <CLIENTPORT> | Inbound | <TRANSFERSERVER> | TCP | 8009 | AJP13 | AJP-Data Traffic | Mandatory |
| <TRANSFERSERVER> | <CLIENTPORT> | Outbound | <VSPHEREHOST> | TCP | 902 | Used if SSL/HTTPS is not used on the Connection Server | Mandatory |
View Agent Rules
| Source IP | Source Port | Direction | Destination IP | Transport Protocol | Dest. Port | Application Protocol | Comment | Type |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 3389 | RDP | Remote Desktop Protocol | Optional |
| <INTERNALCLIENT> | <CLIENTPORT> | Both | <VIEWAGENT> | UDP | 4172 | PCoIP | PCoIP Data Transmission | Mandatory |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 4172 | PCoIP | PCoIP Connection Establishment | Mandatory |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 9472 | Multi Media Redirection, RDP-Connections only | Optional | |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 32111 | USB-Redirection | Optional | |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 42966 | HP RGS | HP Remote Graphics Server | Optional |
| <VIEWAGENT> | <CLIENTPORT> | Outbound | <CONNECTIONSERVER> | TCP | 4001 | JMS | Java Messanging | Mandatory |
View Client Rules (internal / without using Security Server)
| Source IP |
Source Port | Direction | Destination IP | Transport Protocol | Dest. Port | Application Protocol | Comment | Type |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 3389 | RDP | Remote Desktop Protocol | Optional |
| <INTERNALCLIENT> | <CLIENTPORT> | Both | <VIEWAGENT> | UDP | 4172 | PCoIP | PCoIP Data Transmission | Mandatory |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 4172 | PCoIP | PCoIP Connection Establishment | Mandatory |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 9472 | Multi Media Redirection, RDP-Connections only | Optional | |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 32111 | USB-Redirection | Optional | |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <VIEWAGENT> | TCP | 42966 | HP RGS | HP Remote Graphics Server | Optional |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 80 | HTTP | HTTPS Prefred | |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 443 | HTTPS |
View Client Rules (external / using Security Server)
| Source IP | Source Port | Direction | Destination IP | Transport Protocol | Dest. Port | Application Protocol | Comment | Type |
| <EXTERNALCLIENT> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 80 | HTTP | HTTPS Prefred | |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 443 | HTTPS | ||
| <INTERNALCLIENT> | <CLIENTPORT> | Both | <CONNECTIONSERVER> | UDP | 4172 | PCoIP | PCoIP Data Transmission | Mandatory |
| <INTERNALCLIENT> | <CLIENTPORT> | Inbound | <CONNECTIONSERVER> | TCP | 4172 | PCoIP | PCoIP Connection Establishment | Mandatory |
PCoIP Gateway Self-Signed SSL Cert
Apr 28th
As part of our periodical PCI Compliance scans, our corporate vulnerability scanner recently picked up the View 4.6 PCoIP Gateway as having a few issues. These issues were as follows:
- SSL Server Supports Weak Encryption Vulnerability (port 4172/tcp over SSL)
- SSL Certificate – Subject Common Name Does Not Match Server FQDN
- SSL Certificate – Signature Verification Failed Vulnerability
We found this odd since we had an SSL certificate installed on the Security Server, and going to the site externally showed it using a proper cert. We opened a ticket with VMware who explained that this was due to port 4172 not using the SSL certificate that is used for HTTPS, and subsequently opened a ticket with Teradici.
To try to either get this fixed, we reached out to our local VMware reps for assistance. They were incredible helpful and went out of their way with conference calls, performing research on our behalf, and even writing up the following explanation on why the aforementioned results are actually false positives. It’s also an interesting read, regardless:
One of the roles of the View Security Server is to ensure that only traffic on behalf of authenticated users is allowed to reach the internal network and only to those desktops that the user is authorized to access. Authentication and authorisation is performed over an HTTPS (TCP 443) connection to View Security Server.
When a PCoIP virtual desktop is selected by the user at the View Client, View Connection Server (via Security Server) returns an IP address, a port number and a one-time token to the client to enable the PCoIP connection to the Security Server. This channel is protected using an SSL server certificate that can be replaced by a CA signed certificate. The client will connect to the supplied IP address/port number and will proceed only if the far end is a PCoIP server or View Security Server. The TCP 4172 listener on View Security Server 4.6, in its turn, will negotiate only with a PCoIP client executing in the context of an authenticated and authorized user. Once an SSL channel is established, the client provides the one-time token to the Security Server, which then associates the client with the authenticated user through the token. Over this assured channel, an IPSec security association is performed in a process analogous to an IKE Phase 2 negotiation.
All PCoIP traffic between the View Client and View Desktop, through View Security Server, is then AES-128 encrypted with GCM authentication. UDP packets arriving at the View Security Server (or the View Desktop) with an invalid IPSec SPI or that cannot be authenticated with the key associated with the SPI will be discarded. The client similarly discards traffic that is not from the server.
The PCoIP (4172) channel can not be used to gateway PCoIP traffic without the user first authenticating and having entitlements to access virtual desktops. We are aware that some security scanners will report a PCI violation relating to the use of self-signed certificates on this PCoIP channel because they cannot know that this channel can’t be used without the initial authentication.
Some vulnerability scanners have not been updated to compensate for View using multiple ports and authentication mechanisms in tunnel creation and as such report false positives against the View Security Server.
The previous information has been critical in getting approval to re-enable our PCoIP Gateway, which is a lot more pleasant to use than RDP… especially on the iPad.
ThinApp Recipe: Telestream FlipFactory Console
Apr 8th
- Install Java 1.5.0_12.
- Install Quicktime 7.4.5.
- Create a shortcut on the desktop.
- In the Target put: “C:\Program Files\Java\jre1.5.0_12\bin\javaws.exe” “http://<FlipFactoryConsoleIP>:9001/FlipFactory/console.jnlp”.
- In the name put: “FlipFactory Console (<FlipFactoryConsoleIP>)”.
- Copy the icon from an existing install (FlipFactory.ico) and set the Shortcut to use this icon.
- Open Control Panel->Classic View->Java.
- Within the Java Control Panel, go to Advanced->Shortcut Creation and set it to ‘Never allow’.
- Open the shortcut and ensure it works.
- Postscan and create the package normally.
VMware View ADAM Database Replication
Mar 20th
When using multiple Connection Servers in View, things can get wonky if replication of the ADAM database stops occurring. The ADAM database stores the majority of the configuration for View, and as such is very important. When replication stops occurring, if users log in to connection servers that have stopped getting replication information then they could receive improper pool listings. Also, obviously, configuration changes will not be pushed out. We ran into this recently with our main connection server not wanting to replicate to our replica server, and we saw both of the issues above (as well as some other oddities).
To see the status of replication on each of your connection servers, you can console them and bring up a command line and run:
C:\WINDOWS\adam\repadmin.exe /showrepl localhost:389 DC=vdi,DC=vmware,DC=int
This should show results similar to the following if you’re having replication failures:
From this you can see that your connection server is unable to replicate to the specific replica (in this case, VIEWCS). In this particular case, this was caused by the replica server being turned off but not removed. Many other errors can show up, and this is great information to use when troubleshooting what is causing the failure. Some other issues that can cause replication failures (this is not an exhaustive list, but just a few of many):
- Firewall blocking connectivity between the two servers
- Ambiguous DNS (pointing to multiple IPs)
- Kerberos issues
When trying to resolve these issues, you can manually force replication both-ways by executing the following:
C:\WINDOWS\adam\repadmin.exe /replicate local-host.fqdn.com:389 remote-host.fqdn.com:389 dc=vdi,dc=vmware,dc=int
C:\WINDOWS\adam\repadmin.exe /replicate remote-host.fqdn.com:389 local-host.fqdn.com:389 dc=vdi,dc=vmware,dc=int
If all goes well, you should see the following:
It seems when things really go wrong in View, administrators can end up needing to get their hands dirty with the ADAM database. Some other VMware KB articles requiring ADAM tinkering:
- Manually deleting linked clones or stale virtual desktop entries from VMware View Manager
- ThinApps in View Administrator show an assignment but the Assignments tab is empty
- Changing Disposable and User Data Disk drive mappings in VMware View 4.5
- The View Connection broker event log reports the error: Missing VM was not in the original query: vm-xxxx causing pools to wait for agent
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.