Category Archives: Liquidware Labs

What’s the Next Step to Achieving VDI Utopia?

One Master VDI Image

If you’ve been deploying VDI technologies for some time, you’re probably familiar with the VDI Utopian goal of “one master image” and with the technologies available today, is this goal achievable?

Now, going back to the IT stone ages of 2009, when I first started deploying VDI technologies (referring to VMware View and Citrix XenDesktop….I’m not counting XenApp for the purposes of this article), my first two projects, which you can read more about here, were pretty eye opening.

  • Citrix, to their credit, could kinda-sorta provide a single master image with XenDesktop assuming all applications could be published from XenApp servers.  However, this required a Provisioning Server infrastructure that some administrators couldn’t quite understand or get a handle on AND it could require many XenApp servers and multiple XenApp server silos depending upon the required applications.  Though I did get a single master image on the desktop side, I did have to manage multiple XenApp server-based images to support application publishing.  As I wrote in the post referenced above, to support 300 Windows XP desktops and their required applications, 50+ Citrix servers were required.  So, does this really count in achieving the goal of one master image?
  • VMware, at this time as best I can can recall, didn’t make any, “Use VMware View and you’ll only need one master image!” promises.  Again, if I can recall 2009 correctly, VMware did claim that VMware View was “simpler” than XenDesktop in terms of deployment and configuration.  I found the claim to be true in that I only needed a single connection server to support 125 virtual desktops.  However, to support the 125 virtual desktops and their different functions within the organization, I needed 11 master images.

Simplified, my primary observations upon completing these project was this:

  • Generally speaking…Citrix XenDesktop requires fewer desktop images (if not 1) but requires more server-based infrastructure to support OS streaming and published applications.  Compared with XenDesktop, VMware View requires significantly less server-based infrastructure, but requires more desktop images based on the application and configuration requirements of the organization.
  • There’s got to be some better solution….there must be some way to cut down on the number of both master images and server-based machines to provide a good, dynamic, and scalable VDI solution.

Enter application layering….

In 2011, I deployed Unidesk and it quickly became a “mandatory” component on all of our VDI projects.  With Unidesk we were able to minimize both the number gold images and the number of server-based resources required to support VDI initiatives…the Unidesk solution gave us the best of both worlds.  The only time multiple gold images are required is if a customer wants to support multiple OS’s such as Windows 7, Windows 8.1, Windows 10, etc.  But gone are the days when I need 11 Windows 7 gold images to account for distinct use cases and gone are the days when I need 50+ back-end servers to support standard enterprise applications.

Recently, we have been able to achieve the same goal using VMware App Volumes so the “single master image VDI environment that minimizes server-based requirements that also provides a dynamic and scalable infrastructure that’s relatively easy to manage” dream has become a reality.

What’s next VDI dream?

What’s the new dream in the realm of VDI Utopia?

Deploying only Non-Persistent Virtual Desktops

Maybe it’s deploying only non-persistent virtual desktops, an idea, a concept, and a question many organizations are looking into.  Why?

  • It’s easier….something happens to a desktop, you reboot it and it is reset back to its “clean” state
  • There is a belief (and I say this because I haven’t studied this first-hand) that the more non-persistent desktops you deploy, the fewer virtual desktops you’ll ultimately need.  If you can reduce the number of deployed virtual desktops, you reduce the number of servers required to host virtual desktops, you reduce the amount of storage that’s required to host virtual desktops….in short, you can reduce the cost of the VDI infrastructure.

This dream may soon become a reality as there are now tools out there, from VMware and Liquidware Labs as examples, that allow an organization to provide, if this makes sense, persistence in a non-persistent VDI environment.

A Single Non-Persistent Virtual Desktop Pool for the Entire Organization??

Or maybe it’s deploying non-persistent desktops from a single desktop pool….and I bring this up based on the VMware EUC video Delivering Secure Role-Based Desktops with VMware NSX and App Volumes

It seems VMware has a dream to break away from the traditional VDI pool-based approach and instead focus on a user-based approach, utilizing App Volumes and NSX, in order to reduce OPEX and complexity.  Basically, App Volumes would be used to dynamically deliver applications specific and NSX would be used to configure unique security policies based on the user’s role….the virtual machine itself becomes more or less irrelevant.

Conceptually it sounds great and I’m sure App Volumes and NSX will play important parts in VDI infrastructure for years to come, but in my experience, many users have multiple roles and some machines have unique purposes which may limit the effectiveness of a single desktop pool….hospitals and education are two organizational segments that come to mind.  For example, a single nurse may work within the ICU, ER, Labor and Delivery, OR, etc. but the machines themselves in those departments are typically specialized in order to perform that department’s unique function within the hospital, thus a single desktop pool may not be the answer.

When you get a chance, watch the video (it’s about 15 minutes).  Regardless of whether or not a single pool can support your environment, it is certainly interesting to think about and consider the trends and technologies that are driving the VDI landscape and I look forward to continued innovations as we march toward VDI Utopia.

Leave a comment

Filed under Liquidware Labs, Unidesk, VDI, VMware

VDI Assessment with Stratusphere FIT – Deploying the Agent through Active Directory

Here, we’ll look at how to deploy the Liquidware Labs Connector ID Key Software (agent) through Active Directory

Deploying the Agent using Active Directory
The MSI file is required to deploy the agent through Active Directory.
1. On the Connector ID Key Software, the MSI file can be downloaded by clicking AD Group Policy – Standard Version
Use AD Group Policy – Standard to download the MSI file
2. Copy the Liquidware Labs ADM to a given domain controller and import the template into Active Directory using the Group Policy Management Console. In this example, the ADM template was copied to the C:\Windows\INF directory.

3. In order to see the policies, filtering must be disabled using the following steps by unchecking “Only show policy settings that can be fully managed”

4. If using GPOs, you can also set the Hub Address for both the 32 and 64 Bit agents as shown below:

5. Create a new Software Installation package:

Be sure to use “My Network Places” to browse for share (the URL) which contains the agent software. If the share is not entered, the installation of the agent will fail.

6. Assign the package.

If there are problems deploying the client, you may need to enable the policy “Always wait for the network at computer startup and logon”

7. Link the new GPO to the domain, or more likely, an OU.  In this example, I linked the GPO to the domain.
The agent will install silently on the client computer.  Next, we need to verify success.
Verify Data is Collected by the Hub Appliance
1. Within Stratusphere, change to Stratusphere FIT menu using the down arrow on upper right hand portion of the console. Click Inventory | Machines
Any machine with an agent should be displayed. To verify that data is being collected, check the Last Contact heading. (The Last Contact heading is sortable)

Leave a comment

Filed under Liquidware Labs, VDI

VDI Assessment with Stratusphere FIT – Manual Agent Installation

Continuing with our VDI Assessment, now that we have the hub appliance installed, we can deploy the Connector ID Software (agents) to the physical computers to begin our data collection.  For Windows, there are EXE and MSI based installation packages.  The Connector ID software can be found by logging into the Administration module of your Stratusphere Hub then going to Hub Administration | Connector ID Keys | Connector ID Key Software.

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} Installing the agent manually with the .EXE file

First, we’ll go through the steps to install the agent manually using the EXE file to present what occurs when the agent is deployed.  
1.         Login to the Liquidware Labs administrator console and click Hub Administration | Connector ID Keys and then click Windows – Standard Version to download the .EXE file to the local workstation.
Download the EXE file using the Windows – Standard Version link
2.         Double-click the executable and when the Welcome screen launches, click Next.
3.         On the Hub Registration screen, select Use Defaults and click Next.  When this is selected, the agent will communicate with the hub appliance from which the .EXE was originally downloaded.  If you click on Customize installation, you can specify the IP address of the hub appliance, handy if you have multiple hub appliances, and you can also specify a machine group (a grouping of similar computers)
Configure Hub Registration
4.         On the Select Destination screen click Next
Default destination directory
5.         On the Completing the Install Wizardscreen, click Next.
6.         Click Finish to complete the installation.
7.         Open the Services console and verify that the Liquidware Labs services are running.
Verify that the Liquidware Labs services are running
The EXE file has installation switches that will allow for a silent installation (/s) so as to work with network login scripts or any other application deployment tool.  You can also, use the /x switch to uninstall the agent once the data collection period has ended.

Leave a comment

Filed under Liquidware Labs, VDI

VDI Assessment with Statusphere Fit – Installation

Remember from the previous post that a Stratusphere FIT VDI assessment is made of three components:

  • The Hub Appliance
  • The Database Appliance (Not required unless assessing over 1000 clients)
  • Network Station (Not required)

The hub appliance is required and forms the central management and reporting core of the Stratusphere platform.  When I deploy the hub appliance, I typically do so using VMware Workstation and a company laptop, then I take it onsite and leave it for 30 days or so for data collection.

The installation is really simple using VMware Workstation, honestly, I doubt the installation is very hard regardless of the hypervisor platform.  To setup the appliance using VMware Workstation, simply download the OVF template from the Liquidware Labs download site and import it into VMware Workstation.

Once imported, power on the VM.  The appliance will boot and will attempt to obtain an IP address from a DHCP server.  Open an console session and watch the boot process, once completed the hub appliance will provide information how to connect to the web administration console as shown below:

Hub Appliance Console Screen

In this example, I would launch my browser and connect to and login using the displayed credentials.  These credentials will get you into the web administration page.  You can certainly login to the appliance itself, but different credentials would be required.

Web Administration Login Page

The first thing you will be prompted to do is accept the license agreement.  Click I Agree to get to the License page.  On the License page, enter your name and company information.  If you have obtained your Stratusphere license from Liquidware Labs you can click I have a product license key and then import the license data from LL.  Otherwise, select Generate an evaluation license which will give you 5 client licenses and allow for the continuation of the installation, but get in touch with LL as soon as possible.  Check the box indicating you have read the license agreement and click Get Started.

License Page

Next, the Appliance Network Configuration page is displayed.  Here, you set the hostname, IP address, netmask, gateway, etc. of the hub appliance.  It is highly recommended that you use a static IP address.  If the address of the appliance changes, data collection will be impacted.  We will look at configuring the agents later and you’ll see that though changing the IP address may not be catastrophic it is inconvenient and could result in a “hole” in our data collection.  I have had customers use DHCP, but once the appliance has its address, a DHCP reservation is added using the MAC address of the hub appliance VM.  Perhaps the most important setting is the DNS Name.  In this case, I used the IP address of my appliance.  If this value is setup incorrectly, data collection will not work.  If a hostname is added within DNS Name, you must make sure that FQDN is resolvable by adding a host (A) record to your DNS lookup zones.  When the appropriate settings have been entered, click Save Changes.

Appliance Network Configuration

If the IP address was changed, you will be logged out and will need to log back in.  Click Hub Administration | Connector ID Keys | Connector ID Key Properties.  Here, you want to set the appropriate Callback Frequency and Inspection sample interval.  The defaults are 1 hour and 5 minutes.  Stratusphere FIT is not a real-time data collection tool in that the agents are not continuously and actively updating clients every second they’re running.  The Callback Frequency setting controls how often the agent sends it performance data to the hub appliance, the inspection sample interval controls when data is pulled from inside the client. 

Connector ID Key Properties

You may also consider changing a couple settings below what is shown in the screenshot above, specifically the automatic uninstall of the agent and machine group parameters.  Machine groups will be mentioned when we discuss the agents, but suffice to say, you can group like machines together using machine groups.  Machine groups are typically created based on location or department, or maybe a combination of both.  The automatic uninstall of the agent is a nice feature decreasing the burden on an administrator to ensure the agents are removed when no longer needed.

That’s really it in regards to a high-level overview of installing and configuring the hub appliance.  The next post will be client deployment options.

Leave a comment

Filed under Liquidware Labs, VDI

Liquidware Labs – Using Stratusphere FIT for VDI Assessments – Introduction

How many times have you heard “VDI stinks!” And how many times have we heard this because an assumption was made that everyone in the organization was a fit for a virtual desktop?  Certainly there are many factors that affect the success of a given VDI project but in this series of posts, I want to look at using Liquidware Labs Stratusphere FIT for VDI Assessments, specifically, installing and using this tool to perform real performance and data collection prior to the VDI rollout in order to properly plan and execute a VDI initiative. 

In the simplest terms, Liquidware Labs Stratusphere FIT is used to evaluate physical machines to see if they fit for VDI.  FIT generates details reports (there are 141 built-in reports) providing insight into an organizations desktop resource consumption in regards to networking, storage, CPU, and RAM among others.  The information gathered becomes the basis for a proper design and sizing of datacenter resources and virtual desktops.  Stratusphere FIT is downloaded as a virtual appliance(s) and is used by all the major players to perform VDI assessments.  There are virtual appliances for VMware, XenServer, Hyper-V, and RedHat if I recall correctly.

Stratusphere has three components: the Hub appliance, Database appliance, and Network Station.  The Application Hub, a database and the Connector ID Keys (agents/physical computers) are the only components needed during the assessments, network stations are NOT REQUIRED. 

The hub appliance is required and forms the central management and reporting core of the Stratusphere platform.  The Stratusphere Database Appliance (SDA) is an optional component used to store information when more than 1,000 desktops will be evaluated. This option allows a higher volume of CID Keys (agents) to call back to the Stratusphere Hub and a high performance option for better user interface response times.  Honestly, I’m not even sure what the network station does.

Now, for an accurate assessment, you’ll want to deploy the agents on as many physical desktops as possible.  In terms of a VDI assessment, the more data you have the accurate your design will be.  Some organizations may perform a “spot” assessment for a given department or grouping of computers, assuming these desktops perform the same function.  That’s ok, but be mindful that by spot checking, you may miss some “special use case” in your assessment that may result in a specific machine not being a good fit for VDI.

For small assessments, say up to 500 nodes, I prefer to run the hub appliance on a laptop using VMware Workstation and leave it onsite for 30 days.  If you will assess more than 500 nodes, consider downloading and configuring the desktop appliance.  Today, the desktop appliance can be used for assessments up to 10,000 nodes.
The desktop agent can be deployed in any number of ways; manually from the hub appliance web interface, SMS or GPOs, and any other software distribution tool that works with .exe and/or .msi files. The agent is very small and uses approximately 0.3% of a single CPU core and 8MB of RAM.  The agent must be pointed to a hub appliance and this too can be done manually during the install or through the Liquidware Labs GPO ADM template.

FIT is not real-time monitoring tool, but from the hub appliance, you can control how often data is collected and how often the agents report.

Once you have your data, there are 141 built-in reports in the system that will provide valuable insight into which desktops/users are ideal candidates for VDI and which desktops are not, at least initially.  Perhaps the coolest graph/chart in the system is the VDI Fit Map shown below:
This chart provides a high-level overview of each system that has been analyzed.  The clients best suited for VDI would be those found in the top-right quadrant, but the cool thing is you can click on any circle to get more information regarding that specific desktop to see why it may not be a good fit for VDI initially.  Perhaps there is an old application installed that’s a memory hog, maybe weather bug, whatever, but upon analysis, you may find that more desktops are prime VDI candidates.
Finally, in addition to the built-in reports, you can write our own queries using Excel or Postgres data utilities.  I’ll be posting more,  but if you’re looking at VDI, first look at performing an assessment using Stratusphere FIT….special thanks to Mark Jones and Chris Walker at Liquidware Labs, each have been a great resource.  Thanks guys!  

Leave a comment

Filed under Liquidware Labs, VDI