Horizon View 5.3 Part 14 – Windows Server Desktops

March 10, 2014March 9, 2014 / seanpmassey / 1 Comment

Technology isn’t the most complicated part of any VDI deployment. That honor belongs to Microsoft’s VDA licensing – a complex labyrinth of restrictions on how the Windows Desktop OS can be used in a VDI environment. The VDA program either requires software assurance on Windows devices or a subscription for devices that aren’t covered under SA such as zero clients or employee-owned devices.

The VDA program is a management nightmare, and it has spawned a small movement in the community called #FixVDA to try and get Microsoft to fix the problems with this program.

The licensing for virtualizing Windows Server is much less complicated, and a licensing model for remote desktop access that isn’t dependent upon software assurance already exists.

Note: I am not an expert on Microsoft licensing. Microsoft does update VDA and other licensing options, so check with your Microsoft Licensing representative before purchasing. If you want more details about Microsoft’s licensing for 2008 R2 Remote Desktop Services, you can view the licensing brief here.

In previous versions of Horizon View, it was possible, although difficult to configure and unsupported, to use Windows Server 2008 R2 as a desktop OS. Horizon View 5.3 has added official support for using Windows Server 2008 R2 as a desktop OS. This opens up desktop virtualization for enterprises and service providers.

Batteries Not Included

Windows Server-based desktops are missing a number of features in View that other versions of Windows are able to take advantage of. These features are:

Virtual Printing (AKA ThinkPrint)
Multimedia Redirection
Persona Management
vCOPs for View functionality
Local-Mode Support
Smart Card SSO
UC/Lync APIs and support

ThinPrint can be worked around – either by using Group Policy Preferences for users inside the firewall or buying the full product from Cortado. Personal Management can also be worked around by using Roaming Profiles and folder redirection.

If you need smart cards, Lync 2013 support, Local-Mode, or vCOPs for View support, you will still need to pony up for a VDA subscription.

I suspect that more of these features will be working in the next version of View as they are fully tested and validated by VMware.

What’s Included Today

It seems like there are a lot of features in View 5.3 that aren’t supported or available with Windows Server 2008 R2 desktops. So what is included?

PCoIP Access
VMware Blast HTML5 Access – Installed separately with the Remote Experience Pack
USB and Audio Redirection

That doesn’t sound like much, but it may be worth the tradeoff if it saves on licensing.

Enabling Windows Server Desktop Support

Windows Server Desktop support is not enabled by default in Horizon View 5.3, but it isn’t too hard to enable. There is one step that needs to be performed inside the View LDAP database to enable support, and the agent needs to be installed from the command line.

To configure View to support Server 2008 R2 desktops, you need to take the following steps:

Connect to the View ADAM (LDAP) Database
Expand dc=vdi, dc=vmware, dc=int
Expand OU=Properties
Expand OU=Global
Right click on CN=Common and select Properties.
Scroll to the attribute named “pae-EnableServerinDesktopMode”
Click the Edit Button
Change the value to 1 and click OK.
Click OK
Close ADSI Edit

After the View environment has been configured to support Windows Server as a desktop source, the desktop gold image can be configured. Although the process is mostly the same as Part 11 – Building Your Desktop Golden Images, there are a few key differences.

These differences are:

The VMXNET3 network card should be used over the E1000 network card.
The Desktop Experience Feature needs to be installed before the View Agent. This feature is important if you plan to use VMware Blast.
The VMware View Agent needs to be installed from the command line in order to force the agent to install in Desktop Mode. The command test is “VMware-viewagent-x86_64-5.3.0-xxxxx.exe /v”VDM_FORCE_DESKTOP_AGENT=1″”

Aside from these differences, a Server 2008 R2 desktop source can be configured the same as a Windows 7 desktop source.

The next post in this series will be on securing the View environment with SSL certificates.

VMware’s New Certification Policy

March 9, 2014March 9, 2014 / seanpmassey / 1 Comment

Over the weekend, VMware quietly announced a new certification policy – existing holders of the VMware Certified Professional and higher certifications would need to recertify within two years of their most recent certification or lose them. This announcement has caused a bit of an outcry on social media channels as the news spread.

After taking some time to think about it, the policy makes sense. VMware releases a new version of vSphere every year, and while the new versions are usually marketed as point releases, they contain a lot of changes and additions to the way that the underlying system operations. There are enough changes that vSphere 5.5 is a different beast than vSphere 5.0.

The policy, which you can read in full here, is that you have to recertify within two years of your most recently passed exam. If you passed a VCP on January 1st, 2013, you would have until January 1st, 2015 to pass the same VCP, a VCP in another category, or a VCAP exam for your certification to remain valid.

VMware isn’t the first vendor to propose, or implement this sort of policy. This has been Cisco’s policy for years, although Cisco allows the certification to remain valid for three years instead of two.

VMware’s motivations, as outlined in the announcement, are to ensure that VCP holders are keeping their skills up to date. Some members of the VMware Certification team have also made comments in #vBrownbag podcasts about wanting to increase the number of people who hold VCAP-level certifications, and the requirement to recertify is one method to encourage that.

My Thoughts

There are other vendors, and entirely other fields, that require certification/license holders to retest, relicense or recertify on a regular basis. And while someone in IT doesn’t have as much on the line as a medical professional, teacher or a licensed/bonded engineer in the mechanical/structural/electrical/aerospace/etc. disciplines, VMware does have a vested interest in making sure that it’s certification program retains it’s value as their products change.

However, this change is far from perfect. The biggest issue that I have with it is that certifications are only valid for two years. I think that certifications should be valid for three years, or VMware should at least provide a 1 year grace period where someone with a lapsed VCP could take a new exam without having to retake the class.

I also think that there needs to be more of an incentive to go take the VCAP-level exams. These exams, especially the administration ones, require a lab set up to practice the items on the exam blueprint. In order to encourage this, I think that VMware should provide anyone who registers for a VCAP-level exam with NFR license keys for the products covered in the exam.

One thing that I think VMware did right, though, is that they granted a one year grace period and removed classroom prerequisites for anyone who holds an older VCP. This will allow a number of VCP holders to get current without having to sit through classroom training.

Hands-On: The Dell Wyse Cloud Connect

March 7, 2014March 9, 2014 / seanpmassey / 2 Comments

Sometime in the last couple of weeks, $work picked up a Dell Wyse Cloud Connect. The Cloud Connect is essentially a thin client as a stick – it looks like an oversized thumb drive with an HDMI connection where the USB connection would be.

The old saying goes “Big things come in little packages.” The package is little, but the only big thing that comes with it is potential. The idea behind Cloud Connect is very sound, but the execution is lacking. It is a first generation product, so there is plenty of room for improvement.

Hardware Overview

Cloud Connect packs a good bit of hardware into a very small package. The system is built around an ARM Cortex-A9 system on a chip with Wireless-N and Bluetooth. Other features on the device include a Bluetooth connection button for pairing devices, a mini-USB port for power, a Micro-USB port for connecting a peripheral device such as a keyboard or mouse, and a microSD port for expanded storage. It can hook up to any display with an HDMI port and provide 1080P graphics with some 3D support.

Operating System

Cloud Connect runs Android 4.1 Jelly Bean. The interface of the device I used was the standard Android interface, and it wasn’t optimized for keyboard and mouse usage. It was difficult to navigate through the menus when hooked up to a 1080P TV, and I had trouble finding various menus because the icons were too small. While I love Android, the combination of an older version of the Android OS and an interface that was optimized for touch usage means that there is a lot of room for improvement in this category.

Apps

Cloud Connect comes with a few standard apps that are mainly there to allow users to connect to various virtual desktop environments. Those apps are:

Pocket Cloud Standard Edition
Citrix Receiver
VMware Horizon View Client

The version of the View Client that was installed on the device was version 2.1. This client was a few releases behind, and I was not able to connect to the Horizon View 5.3 environment in my home lab. I was unable to update the client to the most recent as the Google Play store claimed that the app was not supported on my device.

Another disappointment of this device is that it does not come with the Professional Edition of Wyse PocketCloud. The standard edition has a reduced feature base – it is limited to one saved connection and can only connect via RDP or VNC. PocketCloud Professional can utilize the PCoIP protocol for connecting to remote desktops and allows multiple saved connections.

Impression

I’m going to turn to the wise sage and critic extraordinaire Jay Sherman to sum up my thoughts on the Wyse Cloud Connect:

Frankly, it just didn’t work. I wasn’t able to connect to virtual desktops in my environment. I couldn’t update the old versions of the software to fix those issues, and the interface was painful to navigate because it was the standard Android interface with no skinning or overlay to improve the experience for keyboard and mouse use.

That’s not to say that this device doesn’t have potential or some great use cases. I can see this being a good option for school computer labs, business travelers who do not want to carry a laptop, or even as a remote access terminal for teleworkers. It’s just that the negatives for this current version outweigh the potential that this device has.

Recommendations for Improvement

So how can Dell fix some of these shortcomings? The area that needs the biggest improvement is the user interface. The standard Android interface works great for touch devices, but it’s not user friendly when the input device is something besides a finger or stylus. Dell needs to build their own skin so they can optimize the experience for TVs, monitors, and projectors. That means bigger icons, adding keyboard shortcuts, and making the system menus more accessible.

Addressing the user interface issues would go a long way towards improving this product. It won’t fix all the issues, though, such as the View Client being listed as incompatible with this device in the Google Play Store.

My Experience With PernixData in the Lab

March 3, 2014March 3, 2014 / seanpmassey / 1 Comment

As solid state drives continue to come down in price, it’s easier to justify putting them in your data center as they provide a significant boost to storage performance. All solid state drive SANs exist, but unless your SAN is up for replacement or you’re starting a new project that requires new storage, you’re probably not going to get the capital to rip and replace.

So how can you take advantage of the insanely high performance that solid state drives provide without having to invest in an entirely new storage infrastructure? A couple of companies have set out to answer that question and put solid state drives in your servers to accelerate your storage without having to buy a new SAN.

One of those companies is PernixData. PernixData has built a product that uses solid state drives on the server to accelerate fibre channel, iSCSI, and/or FCoE block storage.

Disclosure: This post was written using a beta version of PernixData FVP 1.5. I am not affiliated with PernixData in any way.

What is PernixData?

PernixData officially labels the FVP product as a “Flash Hypervisor.” What it does, at a base level, is act as a storage caching layer on the host for block storage that can accelerate reads and writes. It can share flash amongst hosts in a cluster and is fully compatible with vMotion, HA, and other vSphere features.

Installation

PernixData FVP has two main components – a management application that runs on a Windows server and some new multipathing plugins that support that PernixData features that need to be installed on the hosts. A SQL Server database is required, and it can be run on a SQL Server Express instance, and a vCenter account with administrator privileges is also needed.

PernixData’s multipathing protocols are enabled once they are installed on the host, so the only additional configuration that is needed is to configure the flash clusters and the virtual machines or datastores that will take advantage of PernixData.

Overall, the installation and configuration is very easy. The documentation is very thorough and does a great job of walking users through the installation.

Use

When I was running PernixData in my lab, it was pretty much a maintenance-free product. Once it was put in, it just worked.

So how do you know that PernixData is working and actually accelerating storage? How do you know if your VMs are reading and writing to the local flash drives?

PernixData includes a vCenter plugin that provides great visualization of storage use. Graphs can show information on local flash, network flash, and datastore usage for a virtual machine or a host. These graphs are a much better way to visualize IOPS and latency than the graphs on the vCenter server performance tab.

Unlike a lot of reviews, you won’t see any performance graphs for how it improved storage under load. I didn’t run any of those types of tests. If you are interested in performance results that pushed the envelope, check out Luca Dell’oco’s performance testing results.

Other Notes

My home lab is mostly dedicated to running VMware View, and I run a lot of linked clone desktops. PernixData is compatible with linked clone desktops. I was initially confused about how PernixData worked with linked clones, and I wasn’t sure if PernixData was caching the same data multiple times. The explanation I received from Andy Daniel, one of the PernixData SEs, was that if the data was being referenced from the linked clone base disk, it was only being cached once.

System Requirements

As long as there is room on your servers for at least one solid state disk, PernixData can be added into the environment. It doesn’t require any special hardware and supports SATA, SAS, and PCiE solid state disks. It is supported on ESXi 5.0, 5.1, and with the latest version, 5.5.

PernixData is storage agnostic. It will work with any block storage SANs or storage devices that may be in your environment. I used it with 4GB Fibre Channel and a server running OmniOS and saw no issues during my trial.

NFS is not a supported protocol, and there are other products that will provide similar features.

When to Use It

There are a couple of areas where I see PernixData being a good option. These include:

VDI deployments
Resolving storage performance issues

This is a very attractive option if capital or space is not available to upgrade backend storage. Based on the most recent pricing I could find, the cost per host is $7500 for the Enterprise license with no limits on VMs or Flash devices.

I’m used to working in smaller environments, and the finance people I’ve worked with would have an easier time justifying $20,000 in server-side flash than an entirely new array or a tray of solid state drives for an existing array. There is also an SMB bundle that allows for four hosts and 100 VMs.

Final Thoughts

There are a lot of use cases for PernixData, and if you need storage performance without having to add disks or spend significant amounts of capital, it is worth putting the trial in to see if it resolves your issues.

Horizon View 5.3 Part 13 – VMware Blast

February 25, 2014February 24, 2014 / seanpmassey / 6 Comments

One of the new features that was introduced in Horizon View 5.2 was VMware Blast. VMware Blast gives Horizon View administrators another option for allowing users to access virtual desktops – any HTML5 compatible web browser.

Yes. You read that right. The newest option for accessing virtual desktops is your web browser. There are a couple of good use cases for this – employee remote access, employee BYOD, and Internet or guest-use kiosks are the first three that come to mind.

But there are also some drawbacks. A number of features, such as multimedia redirection, virtual printing (ThinPrint), and USB device access, are not available through Blast. View Blast is not as scalable as PCoIP – a single connection server can only support 350 users when using Blast compared to 2000 users when using PCoIP.

Despite those drawbacks, this is one of my favorite features. I love the ability to log into a desktop without having to load the View Client onto a machine.

Unfortunately, this feature isn’t included in the default installation, and additional components need to be installed on connection servers and virtual desktops in order to enable it.

Enabling VMware Blast

There are two components that need to be installed to allow HTML desktop access in a Horizon View environment. One component, the Horizon View HTML Access component, needs to be installed on connection servers, and Horizon View Remote Experience Agent needs to be installed on the View desktop with the HTML component enabled. No additional components need to be installed on Security Servers, but a service will need to be enabled to allow the Security Server to manage HTML5 connections to desktops.

Connection Server

The steps for installing the HTML Access component on a Connection Server are:

1. Run the HTML Access Installer

2. Click Next

3. Accept the license agreement and click Next

4. Select the installation directory and click Next

5. Click Install to begin the installation

6. Once the installation has finished, click Finish to exit the installer.

After you have installed the HTML access component, you will want to ensure that the VMware Blast firewall rules are enabled, and you can do that in the Firewall Management Console.

Caption: Make sure the two highlighted rules are enabled.

Security Server

The VMware View Blast Secure Gateway Service is the Blast component that runs on View Security Servers. This components is part of the default security server installation, but the service is disabled.

If you are using a security server and plan to allow HTML access to external users, you will need to make sure the VMware View Blast Secure Gateway Service is set to Automatic and started. You will also need to enable the VMware Blast firewall rules.

View Desktop Agents

A component will need to be installed on each desktop that you want to enable HTML access to. This component is part of the Horizon View Remote Experience Agent.

The steps for installing the agent are:

1. Run the Horizon View 5.3 Remote Experience Agent installer.

2. Accept the license agreement.

3. The HTML Access option is enabled by default. Click next to continue.

4. Click Install.

All the components that are required for HTML Access will be installed after this installation is complete. If you are planning to use this feature with Linked Clones, you will need to take a snapshot and recompose the desktop pools where you want to use this feature.

Configuring VMware Blast URLs

The URLs that will be used to access desktops through VMware Blast need to be configured before users can log in. These URLs are configured in View Administrator, and they can be configured on both Connection Servers and Security Servers.

The procedure for configuring the URLs are the same for Connection Servers and Security Servers. These steps are:

Log into View Administrator
Click on View Configuration
Click on Servers
Click on the Connection Servers or Security Servers tab.
Select the server that you want to configure and click Edit.
Enter the URL that users will use for accessing desktops via HTTPS under Blast Secure Gateway. The default port for Blast is 8443.

Enabling HTML Access for Desktop Pools

Although the components for HTML Access are installed, the feature isn’t turned on yet. Users will not be able to access their desktops through a web browser until this feature is enabled on a desktop pool.

The steps to enable HTML Access are:

Log into View Administrator
Click on Pools
Select the pool you want to enable HTML Access for
Click Edit
Click the Pool Settings tab
Look for the line called HTML Access in the Remote Display Protocol section. Check the box for Enabled and click OK.

Accessing Desktops over HTML

Once HTML Access is enabled, you can log into your desktop right away. The login URL for VMware Blast is the similar as the URL used for the Blast Secure Gateway. The only difference is the port that users will connect to, the login page is a regular HTTPS site.

For example, if the URL you choose for your Blast Secure Gateway is https://blast.homedomain.com:8443, users should be directed to https://blast.homedomain.com to log in. If they go to the former example, they will receive an error page that “missing route token in request.”

That’s All, Folks!

That covers the basics of setting up HTML access to View Desktops with VMware Blast. Despite missing a number of features that the View Client has, this is a great tool for providing access to virtual desktops without having to install the desktop client.

Top Virtualization Blog Voting For 2014 Now Open

February 22, 2014February 22, 2014 / seanpmassey

Every year, Eric Siebert (Twitter: @ericsiebert) of vsphere-land.com runs a poll of the top VMware and virtualization blogs. The poll to select the top virtualization blogs for 2014 is now open. You can vote here.

Eric’s poll is a great way to recognize the top bloggers in the field.

This will be the first year that this blog will be participating in the poll. Unfortunately, there isn’t a category for top end user computing/virtual desktop blog, but if you enjoy what you’ve seen so far, feel free to vote for me in the general category.

Windows 8.1 Win-X Menu and Roaming Profiles

February 14, 2014February 13, 2014 / seanpmassey

One of the features of the new version of Horizon View 5.3 is support for Windows 8.1, and I used this as my desktop OS of choice as I’ve worked through installing View in my home lab. After all, why not test the latest version of a desktop platform with the latest supported version of Microsoft Windows.

Like all new OSes, it has its share of issues. Although I’m not sure that anyone is looking to do a widespread deployment of 8.1 just yet, there is an issue that could possibly hold up any deployment if roaming profiles are needed.

When Microsoft replaced the Start Menu with Metro in Windows 8, they kept something similar to the old Start menu that could be accessed by pressing Win+X. This menu, shown below, retained a layout that was similar to the start menu and could be used to access various systems management utilities that were hidden by Metro.

The folder for the WinX menu is stored in the local appdata section of the Windows 8.1 user profile, so it isn’t included as part of the roaming profile. Normally this wouldn’t be a big deal, but there seems to be a bug that doesn’t recreate this folder on login for users with roaming profiles.

While this doesn’t “break” Windows, it does make it inconvenient for power users.

This won’t be an issue for persistent VDI environments where the user always gets the same desktop or where roaming profiles aren’t used. However, it could pose some issues to non-persistent VDI environments.

Unfortunately, there aren’t many alternatives to roaming profiles on Windows 8.1. Unlike the old Start Menu, there is no option to use folder redirection on the WinX folder. VMware’s Persona Management doesn’t support this version of Windows yet, and even though the installer allows it as an option, it doesn’t actually install. If Persona Management was supported, this issue could be resolved by turning on the feature to roam the local appdata folder.

The current version of Liquidware Labs’ ProfileUnity product does provide beta support for Windows 8.1, but I haven’t tried it in my lab yet to see how ProfileUnity works with 8.1.

The last option, and the one that many end users would probably appreciate, is to move away from the Metro-style interface entirely with a program like Start8 or Classic Shell. These programs replace the Metro Start Menu with the classic Start Menu from earlier versions of Windows.

I’ve used Classic Shell in my lab. It’s an open source program that is available for free, and it includes ADMX files for managing the application via group policy. It also works with roaming profiles, and it might be a good way to move forward with Windows 8/8.1 without having to retrain users.

Looking for New Home Lab Storage

February 5, 2014 / seanpmassey / 7 Comments

I’ve been a fan of Nexenta for a long time. I’m not sure if it was Sun’s ZFS file system, the easy-to-use web interface, or how Nexenta was able to keep up with my changing needs as my lab grew and acquired more advanced gear. Or it was support for VAAI. Whatever the reason, or combination of reasons, Nexenta was a core component in my lab.

That changed a few months ago when I started a series of upgrades that culminated in my storage moving to a new server. During those upgrades, I came across a few issues that forced me to change to OmniOS and NAPP-IT as a short-term solution while waiting to see if a new version of Nexenta was released.

Nexenta is no longer viable as a storage platform in my lab because:

Version 3.1.3.5 doesn’t play nicely with the Broadcom NICs in the Dell PowerEdge T310 that I use for storage due to a line being commented out in the driver. Even when I fix this, it’s not quite right.
Version 3.1.5 didn’t work period when I had USB devices plugged in – which makes it hard to use when you have USB hard drives and a USB keyboard.
Version 4 is vaporware.

The OmniOS/Napp-IT combination works, but it doesn’t meet one of my core requirements – VAAI support.

It doesn’t seem like a new version of Nexenta Community Edition will be coming anytime soon. A beta was supposed to be released early in January, but that hasn’t materialized, and it’s time to move onto a new platform.

My requirements are fairly simple. My requirements are:

Spouse Approval Factor – My wife is 7 months pregnant and wants to buy a house. Any solution must be either open-source or extremely cheap. The less I spend, the better.
Support for Fibre Channel – I’ve started putting 4GB Fibre Channel in as my storage network. The solution must have support for using Fibre Channel as I would prefer to keep using it for my storage network.
VMware APIs for Array Integration – My home lab is almost entirely virtualized, so any solution must support VAAI.

ZFS isn’t a requirement for a new system, and I’m not worried about performance right now. A web interface is preferred but not required.

If you have any recommendations, please leave it in the comments.

Horizon View 5.3 Appendix D – Pool Settings

February 3, 2014February 3, 2014 / seanpmassey

In Part 12, I went over how to create an automatic linked clone pool. One area I quickly glossed over was what the options on the Pool Settings page were and what they controlled. When setting up your desktop pools, it is important to understand what these options control.

The settings are grouped into four categories: General, Remote Settings, Remote Display Protocol, and Adobe Flash Settings. General provides options for logins. Remote Settings handles general desktop behavior for the pool. Remote display protocol controls options for the display settings in the pool, and Adobe Flash Settings controls how Adobe Flash is managed.

General Settings

There are two options in the General settings section. These two options are:

State: State controls whether users can log into the pool or not. If the pool is set to enabled, entitled users can log in. If it is disabled, entitled users cannot log in.

Connection Server Restrictions: Horizon View allows Connection Servers to be tagged or grouped. These tags can be used to control which connection servers can be used to access a pool. For instance, if you had connection servers tagged Internal and External, you can use the tags to ensure that a pool used by Accounting cannot be accessed from Internet-facing connection servers.

Remote Settings

Remote Settings is an odd name for this group, and it probably should be renamed Pool Settings or merged with general. This group of settings controls desktop power behavior, logon behavior, and idle session duration.

Remote Desktop Power Policy: This setting controls how the power-state of desktops are managed after the user logs off or the desktop is no longer being used as a spare. The options are:

Take No Power Action: If this option is selected, View will not change the power state after a user logs out or the desktop is no longer needed. Powered on desktops will remain powered on and desktops that are shut down will remain shut down.

Suspend: Desktops that are no longer needed will be suspended by vCenter instead of shut down.

Power Off: The desktop is shut down and powered off after the user logs off or the desktop is no longer needed as a spare.

Ensure Desktops are Always Powered On: The desktop is always powered on, even when it is not needed.

More information on these options can be found here.

Automatically Log Off After Disconnect: This setting determines how long a session will remain in a disconnected or idle state before the user is logged out. The options are:

Never: This is the default option. Users will remain logged in but disconnected indefinitely.

Immediately: The session will be immediately logged out after disconnection.

After X Minutes: The session will remain disconnected for a length of time determined by the administrator before the session is logged out.

Allow Users to Reset Their Desktop: This setting, if enabled and set to Yes, allows users to reset their desktop manually to a known good setting.

Allow Multiple Sessions Per User: This setting controls whether users are allowed to have multiple concurrent sessions in a pool.

Delete or Refresh Desktop on Logoff: This setting controls what happens to the virtual desktop after the user logs off. The options are:

Never: Nothing happens to the desktop after logoff, and it may go into an ‘Already Used’ state.

Delete Immediately: The desktop is deleted from the environment and recreated from scratch. The VM-ID of the desktop changes with this operation.

Refresh Immediately: The desktop is rolled back to the last good snapshot, but it is not deleted. The VM-ID of the desktop is not changed when this operation occurs.

Remote Display Protocol

The Remote Display Protocol section controls some of the settings that govern remote connections to the pool.

Default Display Protocol: This setting controls the default protocol that is used between the virtual desktop and the client. The two options are PCoIP and Microsoft RDP.

This isn’t the only place that display settings are configured. Fine-grained control over the PCoIP protocol is done via Group Policy through the included ADM files on the Connection Server.

Allow users to choose protocol: If this is set to yes, the user can change the protocol when logging into the pool. If set to no, the user will always use the default protocol.

3D Renderer: If the pool is using a desktop built on Windows 7 or newer, PCoIP is the default protocol, and the user is not allowed to choose the protocol, 3D rendering settings can be configured for the pool. Hardware, software, and automatic are the options that can be selected, and the amount of video memory can be configured as well.

Max Number of Monitors: The maximum number of monitors that users will be able to utilize when logging into their virtual desktop when using PCoIP. The default is 2, but four monitors can be supported as well. This setting, along with Max Resolution, is used to determine video RAM if 3D Rendering is disabled.

Max Resolution of any one monitor: This is the maximum screen resolution supported on any desktop when using PCoIP. This setting, along with Max Resolution, is used to determine video RAM if 3D Rendering is disabled.

HTML Access: If the HTML Access component is installed on your connection brokers and Feature Pack 1 is installed on the desktop, you can enable HTML Access. When this setting is enabled, users can log into the desktop pool using VMware Blast and any HTML5 compatible browser.

Adobe Flash Settings

The final group of settings that can be configured are for managing Adobe Flash. These settings can control the quality of Flash content in order to reduce the amount of bandwidth that a virtual desktop utilizes.

The two settings that can be configured here are:

Adobe Flash Quality: This setting controls the image quality of Flash content.

Adobe Flash Throttling: This setting controls the framerate of the Flash content. The more aggressive the setting, the lower the frame rate.

As I mentioned above, there are settings that can control image quality, bandwidth usage, and other settings inside the virtual desktop that can be set with Group Policy. I’ll go over more details on how to do that in an upcoming appendix.

Horizon View 5.3 Part 12 – Creating An Automatic Linked-Clone Desktop Pool

January 31, 2014January 31, 2014 / seanpmassey / 6 Comments

Every system needs a way to group entities in order to organize them, delegate administration, and control security on them. Horizon VIew uses desktop pools to group desktops, apply Horizon View specific policies, and entitle access to users.

There are a few different types of desktop pools in a Horizon View environment, and the types of desktop pools that you implement will be determined by your use case. I’m partial to Automatic Linked-Clone pools, These are known as Non-Persistent Desktop Pools because the user state is lost after logoff when the desktop is returned to a known good state. In some ways, these pools are similar to Windows XP Steady State desktop setups or a program called Deep Freeze that did something similar.

There are other types of desktop pools in a VMware View environment, and I go into more details on the different pool types in Appendix C.

Since we went through all the effort of setting up View Composer earlier in this series, this article will focus on setting up an Automatic Linked-Clone pool for non-persistent desktops.

1. Log into View Administrator. Under Inventory, select Pools.

2. Click Add to add a new pool.

3. Select the Pool Type that you want to create. For this, we’ll select Automated Pool and click Next.

4. Select whether you want to have Floating or Dedicated Desktops. For this walkthrough, we’ll select Floating and click Next.

Note: The Enable Automatic Assignment option is only available if you select Dedicated. If this option is selected, View automatically assigns a desktop to a use when they log in to dedicated pool for the first time.

5. Choose the type of virtual machines that will be deployed in the environment. For this walkthrough, select View Composer Linked Clones and click Next.

6. Each desktop pool needs an ID and a Display Name. The ID field is the official name of the pool, and it cannot contain any spaces. The Display Name is the “friendly” name that users will see when they select a desktop pool to log into. You can also add a description to the pool.

7. The next screen after setting the pool name is for the pool settings. There are a lot of options here, that control how the pool will behave. Some of the options are:

If the pool is enabled
Default power state of desktops
Display protocols
Adobe Flash settings

8. The next screen will allow you to configure the provisioning settings for the pool. This screen allows you to control provisioning behavior, computer names, and the number of desktops provisioned in the pool.

9. The next screen allows you to set up a special non-persistent disk for disposable files. Disposable files are classified as temporary files and page files. If a disposable disk is used, these files will be redirected to here, and this disk is deleted whenever the VM is shut down.

This screen allows you to determine how the virtual desktop will handle these files.

10. Select the option to store Replicas on a separate datastore if you want to place them on a different storage tier. Andre Leibovici has a good article on the benefits of placing Linked Clone replicas on a different datastore.

11. After you choose whether or not to place the Replica Disks on a separate datastore, you need to configure the pool’s vCenter settings. This covers the Parent VM and the snapshot that the Linked Clones will be based on, the folder that they will be stored in within vCenter, and the cluster and datastores that will be used.

In order to configure each setting, you will need to click the Browse button on the right hand side of the screen. Each step must be configured in order.

11-A. The first item that needs to be configured is the Parent VM that the Linked Clones will be based on. Select the VM that you want to use and click OK.

11-B. The next step is to select the Parent VM snapshot that the Linked Clones will be based on. Select the snapshot that you want to use and click OK.

11-C. After you have selected a Parent VM and a snapshot, you need to configure the vCenter folder in the VMs and Templates view that the VMs will be placed in. Select the folder and click OK.

11-D. The next step is to place the pool on a vSphere cluster. The virtual machines that make up the desktop pool will be run on this cluster, and the remaining choices will be based on this selection. Select the cluster that they should be run on and click OK.

11-E. The next step is to place the desktops into a Resource Pool. In this example, I have not resource pools configured, so the desktops would be placed in the Cluster Root.

11-F. The final two steps of this section are to select the datastores where the Linked Clones and the Replicas will be stored. Linked Clones can be stored on multiple datastores, so you can select multiple datastores in this section. You can also configure View to allow the datastores to be overcommitted by changing the Storage Overcommit option on each datastore.

11-G. Replicas can only be stored on a single datastore. Select the datastore that you want to store them on and click OK.

Note: After you have configured the Replica Datastore, you may receive the following warning about storing Replicas and Linked Clones on local datastores. If you are using a SAN or a NAS and not storing any Replicas or Linked Clones on local datastores, you can ignore this message.

12. The next screen is for configuring the advanced storage options. The three options that can be configured on this screen are the View Storage Accelerator, disk space reclaimation and the option to use native NFS snapshots.

If you use View Storage Accelerator or disk space reclamation, you can configure blackout times where vCenter will not run these tasks.

13. To set the blackout times for the pool, click the Add Button and select the days and times when you do not want these operations to run. You can set multiple schedules.

14. After you have configured the advanced storage options, you need to configure the Guest Customization settings. This screen allows you to select the domain and organizational unit for the desktops and whether Sysprep or Quickprep will be used to prepare the desktops.

15. Review the settings for the pool and verify that everything is correct. Before you click Finish, check the Entitle Users checkbox in the upper right. This will allow you to select the users and/or groups who have permission to log into the desktops.

If you need to make a change to the pool settings, the left-hand column contains links to each page in the wizard.

17. After you click Finish, you will need to grant access to the pool. View allows you to entitle Active Directory users and groups. Click Add to entitle users and groups.

18. Search for the user or group that you want to add to entitle. If you are in a multi-domain environment, you can change domains by selecting the domain from the Domains box. Click on the users or groups that you want to grant access to and click OK.

Note: I recommend that you create Active Directory security groups and entitle those to desktop pools. This makes it easier to manage a user’s pool assignments without having to log into View Administrator whenever you want to make a change.

19. You can check the status of your desktop pool creation in vCenter. If this is a new pool, it will need to clone the VM into a Replica before it can create the Linked Clone desktops.

Once the desktops have finished composing, you will be able to log into them through VMware Blast or the Horizon View client.

I realize that there are a lot of steps in the process of creating a desktop pool. It doesn’t take nearly as long as it seems once you get the hang of it, and you will be able to fly through it pretty quickly.