Welcome to the third post in the VMware App Volumes series. In the previous two posts we covered the installation and configuration of Cloud Volumes and in the second post we walked through the creation and assignment of an AppStack. Well in true IT fashion as nothing stays the same for long, in this post we are going to step through the process of updating the previously created AppStack. More precisely I will be updating the version of Notepad++ contained in the AppStack as well as adding Google Chrome to the cast of characters. Let’s get on with it!
In the first post covering VMware’s App Volumes, Installing and Configuring VMware AppVolumes Manager, we walked through the process of installing and configuring the App Volumes Manager server and dashboard. With a working management server our next task is to install the VMware App Volumes Agent.
In my lab environment the primary focus of for App Volumes is going to be leveraged with floating, non-persistent desktops running on VMware Horizon’s View. Keeping that in mind I will be deploying the App Volumes Agent onto separate MS Windows 7 images:
- Win7-AppVolProv – Clean Windows 7 install (hotfixes/service packs installed, View Agent, and App Volumes Agent) for creating and editing App Volume stacks
- Win7_x32-Gold – Golden Image used to create Horizon View desktop pool Note – For this release, the App Volumes Agent is supported on Windows 7 64 or 32 bit, Windows 8, or Windows Server 2008R2 virtual machines.
During VMworld 2014 it was announced that VMware was purchasing Cloud Volumes, an upstart for application virtualization technology. Fast forward to earlier this month and VMware officially released the product under the App Volumes name and made the software available to customers (as a standalone product or part of the Horizon View Enterprise bundle) as well as trial bits to give folks the chance to kick the tires.
App Volumes allows for the creation of containers or “AppStacks” for the delivery of a single application or multiple applications within a single stack. Shown in the picture below you can see with the use of the “CloudVolumes agent” the application stacks are decoupled from the operating system. Additionally, with the use of “Writable Volumes” user settings and changes can be captured and saved.
With all this goodness in hand, this first post in the series will cover the installation and configuration of the brains for App Volumes, the App Volumes Manager. In additional posts I will discuss the creation, presentation, and updating of AppStacks. Let’s get started!
- Created Active Directory Service Account – Used for both LDAP Reads and vCenter Server permissions
- Created “AppVolumes User” Role in vCenter (see eye chart at the end of the post for role permissions)
- Windows Server 2012R2 virtual machine configured with 2vCPU’s and 4GB of RAM
- MS SQL Database configured on remote MS SQL Server 2008R2 server
- Trial software bits from VMware website -> HERE
Mount the VMware App Volumes ISO to the “VMware App Volumes Manager” server and execute the installer. Click “Next” on the Installation Wizard dialog:
Accept the the licensing agreement and click “Next” to continue:
Choose the “Install App Volumes Manager” radial and click “Install” to continue:
The “App Volumes Manager Installation Wizard” dialog will be displayed. Click “Next” to continue:
Choose if you wish to have setup program install/configure a copy of SQL Server Express or utilize an existing SQL Server Database. For this example I am using an existing remote SQL Server Database:
Fill in the needed Database Server connectivity details and click “Next” when ready:
I had no need to change the default HTTP and HTTPS ports. Moving on, click “Next”:
I left the default Destination Location unchanged. Click “Next” to continue:
At this point we are ready for the actual installation. Click ‘”Install “ to proceed:
During my install this screen was accurate, it took about 8 minutes to complete the installation:
Once the installation completes click “Finish” to exit the installer:
With the completion of the installation we have to run through a quick “setup” process to configure VMware App Volumes Manager.
Launch the App Volumes Manager desktop icon:
A “Welcome to App Volumes Manager” webpage will be displayed. It provides an overview of the tasks that can be completed and initiated App Volumes Manager. Click “Get Started”:
The first tab that is displayed is the “License Information”. As I am using the trial version of the software we don’t have much to do here. One thing to point out, when using the trial version of the software only a single Appstack can be attached per user. Click “Next” to continue:
Second tab displayed is for the configuration Active Directory. Provide the details for your domain, domain controllers (if you want to specify) and user with “Read” access to your directory. I provided a service account that I created for both Active Directory and vCenter permissions. Click “Next” to continue:
Configure the Active Directory group that will be added to the App Volumes Admin Group. For lab use I added my Domain Admins group. Click “Next”:
Next up is the Hypervisor Credentials tab. I am using the “vCenter Server”, as I am assuming most folks will, and the service account I created assigned to the “App Volumes User” vCenter Role I created. I also provided my ESXi hosts root account and password to enable the “Mount on host” setting. Click “Next”:
In the Storage tab we are configuring the location of where the Appstacks and Writeable volumes that are created will be stored. In my lab environment I configured both to use the VSAN Datastore:
Confirm the Storage Settings to proceed. To choose whether to “Import volumes in the background” or “Import volumes immediately”
Provide the vSphere Datastore to upload the volume templates and provide login in credentials for the ESXi host used for the data transfers. Click “Upload” to continue:
Finally, verify the selections/settings made in the previous tabs provide in the Summary. Click “Next” to proceed:
With all the steps completed and configured you are taken to the App Volumes Manager Dashboard:
From here we are good to install our AppVolumes agent and create our first AppStack. Stay tuned!
vCenter Server Permissions
- Allocate space
- Browse datastore
- Low level file operations
- Remove file
- Update virtual machine files
- Create folder
- Delete folder
- Cancel task
- Local operations
- Create virtual machine
- Delete virtual machine
- Reconfigure virtual machine
- Local operations
- Assign virtual machine to resource pool
- View and stop sessions
- Create task
- Virtual Machine
- Add existing disk
- Add new desk
- Add or remove device
- Change resource
- Remove disk
- Power off
- Power on
- Create from existing
- Create new
- Clone template
- Clone virtual machine
- Create template from virtual machine
- Deploy template
- Mark as template
- Mark as virtual machine
- Modify customization specification
- Promote disks
- Read customization specifications
Objective 2.12 – Create ThinApp Applications and a ThinApp Repository
Create ThinApp Applications
Prior to creating and capturing a ThinApp package we will first need a “capture” system use. For this blog post I used a clean installation of MS Windows 7 32-bit with the following configuration:
- 2GB of RAM
- All relevant Service Packs and Hot Fixes applied
- VMware Tools installed
- Installed ThinApp Enterprise software
With my capture system setup and ready to go the last step is to take a snapshot of the virtual machine to allow us to “roll back” to the base image for additional ThinApp package creation. Now on with the show.
With a console session opened on the capture machine, Win7-ThinApp, launch the ThinApp Setup Capture utility:
You will be presented with the Setup Capture Welcome screen that gives you a review of the steps that will be used to create your application as well as a link to a quick start video. Click Next to continue when ready:
The first actionable step in the capture process is completing the Prescan. The capture process will scan the current state of the hard drive and registry files of the system. This will provide the baseline for the Postscan function later in the capture process to see what has changed on the system (IE, your application installation). Click Prescan to continue:
With the postscan complete it is now time to install the application you wish to capture. For this post I used Google Chrome as the test subject. You can minimize the Setup Capture – Install Application window as needed, just be sure not to close/cancel the task:
With the application installed click on Postscan to continue:
The post scanning can take a few minutes so might want to pop open your Twitter stream to kill sometime:
Once the post scan has completed we will need to select the application Entry Point. As one may guess, this is the how the application will be launched.
Next up is the integration with Horizon Application Manager. That is beyond the scope of this post as well as the VCP-DT exam, so click Next to continue:
One cool thing I like about ThinApp packages is the ability to define who can/can’t launch the application. As you can see below I am using the TA_Chrome_Users Active Directory group to grant permissions. You can also define a custom Access Denied Message:
Covering two screens in on shot here. Next two steps we are configuring the Isolation Mode and the Sandbox locations for the application. These settings control how and where data is read and written to when using the application. For additional details have a look at the following VMware KB article – Understanding the ThinAPp Sandbox and Isolation Modes
For this example I selected the option for Merged Isolation Mode and set the Sandbox for User Profile:
I chose not to participate in VMware’s quality assurance program, but the choice is yours:
ThinDirect provides the ability to redirect specific websites that are opened via Internet Explorer to be redirected and opened via Google Chrome:
Make note of the project location as this will contain the output of the build process. These files will be later used/copied over to your network share for user access:
Project being saved.
Under Advanced Configuration we have the chance to make changes to the Package.ini file (covered in some detail below). This file allows for additional configuration options for the package. Click Build to move on:
The build process will take a few minutes to complete:
Once the build process completes you will have your first ThinApp package ready to go. Click Finish to wrap it up.
Create or Identify Supported File Share
Assign Permissions To The Share
Going to cover two objectives for the price of one. In order to allow access to the ThinApp packages either via MSI or their executable VMware provides a few requirements:
- The MSI packages need to be stored on a Windows network share that is accessible via the View Connection Server and virtual desktops, ie in the same Active Directory domain or one that is trusted. The share must be configured for access leveraging computer accounts.
- The file share permissions must provide Read access to the built-in Active Directory group Domain Computers.
- For users to access and stream ThinApp packages you will need to configure Read & Execute NTFS permissions for the user group or groups.
Verify MSI Streaming Settings In The package.ini Files
- To allow for streaming of MSI packages you need to modify the
- file and more specifically the
- parameter. You can make this change during the initial capture of the application and set the value to
Identify Necessary ThinApp Package Components To Put On The Share
Noting the capture directory from above when creating the ThinApp package, copy over the needed .exe and .msi files to the file share that will be used to host the applications. In the example below, for the Chrome package copy over Google Chrome.exe and Google Chrome.msi:
Assign ThinApp Applications To Pools
Using your web browser of choice access and log into the View Administrator console. Under Inventory expand View Configuration and select ThinApp Configuration. In the right hand pane click on Add Repository:
Provide the Display Name and Share Path to the application repository. Click Save we completed:
With the repository location added it is time to add the ThinApp packages to the inventory. Under Inventory expand Inventory and select ThinApps from the tree. In the right hand pane click Scan New ThinApps:
From the ThinApp Repository drop down, select the repository location that was added. The setup wizard will then scan the location for any ThinApp packages. When completed click Next to continue:
With the scan complete select the corresponding MSI file or files you wish to scan. For the Google Chrome example I have selected the Google Chrome.msi file. Click Scan to continue:
With the scan completed you can see that the Google Chrome MSI package has been successfully added to the inventory. Click Fisnish to exit:
With our package added, lets get it assigned to some desktops. Again from the ThinApp menu click Add Assignment in the right hand pane. For this example I chose Assign Pools:
In my lab environment I currently only have a single desktop pool created, Test-Pool. Using the Add button I assigned the test pool to the Google Chrome application.
With the ThinApp assigned to a pool lets take a look at our efforts. In the screen shot below I am connected to one of the desktops in the Test-Pool. As you can see, on the desktop is the shortcut for Google Chrome as well as it being listed in the Add/Remove Programs section in Control Panel:
Phew, long post and lots of screens shots. Hope it was helpful!
One of the new and best features in the recently released VMware Horizon View 6 was the support of Microsoft Remote Desktop Services (RDS) hosts for application delivery. This has long been something Citrix has supported both in its MetaFrame/Presentation Server/XenApp/XenDesktop products over the years and something View administrators have been clamoring for. Now with the ability to publish a single application to user without the need to lunch a full desktop is in our hands and brings back a little history for me.
The one thing View administrators have gotten good at dealing with over the years is how to manage the user data or “Persona” for their users. Whether leveraging native folder redirection in Windows, Persona Manager from VMware, or a 3rd party product from Liquidware Labs or AppSense to do the job. Now with RDS, we just have one more profile to add to the list.
Managing RDS (or TS profiles from the last time I worked with it) is a pretty simple process as it leverages Microsoft Active Directory Group Policy Objects (GPOs) to control and manage the settings. In the Horizon View world much hasn’t changed other than VMware has provided a set of ADMX files to import to control/manage the behavior. One thing of note from the VMware documentation is the VMware settings are the preferred deployment strategy:
As a best practice, configure the group policies that are provided in the View ADMX files rather than the corresponding Microsoft group policies. The View group policies are certified to support your View deployment.
To begin testing in my lab environment I had a few prerequisites to get out of the way:
Downloaded the View GPU bundle zip file (the ADM/ADMX files are no longer located on a Connection Broker server)
Imported the ADMX files to the C:\Windows\PolicyDefinitions folder on my Domain Controller
Created an Active Directory OU (RDS_Hosts) to house my two RDS hosts, TS01-v6 and TS02-v6
Created a User Group named RDSH Users and placed a few users accounts in the group
With the housekeeping work taken care of, lets get down to some actual work. Within Group Policy Management Editor open I created a new GPO named RDS_Host_Policy (super technical I know) and linked the policy to the RDS_Hosts OU created above. With the ADMX properly imported if you browse to the following you will see the Remote Desktop Session Host node:
Computer Configuration –> Policies –> Administrative Templates –> Windows Components –> Horizon View RDSH Services
Under Remote Desktop Session Host you will see eight additional nodes for configuration (with links to the settings under each per VMware documentation):
In a production deployment pay close attention to all the setting that are available to you in the various nodes. For this post we are going to focus mainly on the Profiles node a more specifically the following setting, Set Path for Remote Desktop Services Roaming User Profile.
- This will allow me to redirect my roaming profile to a share (RDS_Profiles$) that is hosted on my lab file server (FS01):
- A word on the folder permissions, follow
- Microsoft KB article to get the required NTFS and SMB permissions configured. Below is a summary:
SMB Folder Permissions
With the share in place it was time to give it a test. In my Horizon View 6 lab I am currently publishing the all important Calculator app as well as Internet Explorer:
After launching each of the apps a few times and making some changes (home page, etc) I checked my profile share to make sure all checked out OK:
Everything checked out and I am good to go!
Thanks for reading,
Last week I posted (located here) on new hosts that I setup and deployed in my lab. One goal for the new lab hosts was to work with and get familiar with VMware’s VSAN product while leveraging it in my studies for my upcoming VCAP-DTA exam. Though the exam is based on View 5.2, I needed to upgrade my lab to View 5.3.1 (the minimum supported version of View). While fighting the urge to upgrade the lab to the latest and greatest shiny object, View 6.0, I went to work on getting VSAN deployed. Though I only have two physical hosts, I wanted to find away to setup VSAN and getting running without a 3rd host (whether physical or spoofing it with a virtual host).
Before going further I want to state that the following changes are NOT SUPPORTED and are for obvious reasons not recommended for a production environment. With these changes no “replica’’ virtual machine information is created, so with a lost of one of my hosts that VM and its data are lost. As I am running non-persistent desktops just for testing this is not an issue.
On with the show
With the disclaimer out of the way, lets get to it. As you can see from the screenshot below VSAN has been enabled on the two lab hosts. Each host is providing a single SSD drive for the read/write cache and two SATA magnetic drives for the persistent storage:
With the VSAN Datastore created and presented to each of the hosts I took to the Horizon View administrator console and try to spin up a quick desktop pool. After waiting a few minutes I received an error in vCenter that the replica creation had failed. I took a look at the settings for the desktop pool I created and received the following error:
The challenge is clearly highlighted in the screenshot, VSAN knows that only two hosts participate in the VSAN cluster and a minimum of three nodes are required for a proper configuration. Thinking that I could out smart View/VSAN I logged into the vCenter web client and created a new storage policy and set the “Number of failures to tolerate” to zero and “Force Provisioning” to yes:
With the new storage policy created I attached the policy to my View golden image desktop and tried to provision the desktop pool again. Second try, same result. Received the same message as the screen shot above, View/VSAN knows I am running with only two nodes. Keeping score, VSAN 2, Jason 0.
At this point I took to Google to do some research and see if anyone has tried this or ran into a similar situation. While the research was light on folks trying to run a two node VSAN cluster (not surprising, again NOT SUPPORTED) I did find an article that covered VSAN operability with VMware View 5.3.1:
Reading through the KB article I stumbled across the answer I was looking for under the Virtual SAN Storage Policy Profiles section of the article:
With Horizon View 5.3.1, there is no need for any user action associated with the default policy. The policy applies to both linked-clone desktop pools and full-clone desktop pools. The default policy for all virtual machines using the Virtual SAN datastore is as follows:
- Stripes: 1
- Resiliency: 1
- Storage provisioning: Thin
Even though I created a Storage Policy VSAN with View 5.3.1 leverages the “Default Policy” out of the box for virtual machines. This can be seen by running the following command via a console session on your ESXi host:
esxcli vsan policy getdefault
The output from the command is displayed below:
From the screenshot we can see that for each of the “Policy Class” attributes the setting “hostFailurestoTolerate” is configured for 1 (one), which in my configuration is not supported. Also the other option to note is the “forceProvisioning” set to 1 (one). Mentioned in the VMware KB article is an example of how to manipulate the default policy via ESXCLI commands.
I went to work and set the “hostFailuresToTolerate” and “forceProvisioning” options to 0 (zero) and 1 (one) respectively for each of the Policy Classes as seen by the screenshot below:
After the changes were made I again tried to provision my test desktop pool with VM’s to the VSAN Datastore. This time with a little more success, though it looks like I need to update my View Agent in the golden image.
Thanks for reading and post questions or comments below!