Saturday, March 5, 2016

Running App Volumes and RES Workspace Together

Creating A Customized App Volumes AppStack Template
Script Logic For Pausing RES At Login
Adding Required Registry Keys To Master Image
Properly Configuring Authorized File Rules

1 – Overview.

Running App Volumes and RES together successfully involves creating a customized AppStack template, configuring RES to run special batch files at login/log off, and adding a few registry edits to the gold images you use for your desktop pools. If you’re leveraging RES Workspace’s Authorized Files features you’ll also have to make changes to your rules. This guide will walk your through all these major steps as well as elaborate upon the purpose and need for these steps.

Below are some useful references that informed this guide and are handy for gaining a more thorough understanding of the entire process.

Guidance from RES:

VMware KB article on creating an AppStack template:

Informative blog on cloning AppStacks and adding scripts to them:

VMware and RES partnering:

2 – Creating A Customized AppStack Template.

Why create an AppStack template?
For RES to run properly in an App Volumes environment special exclusions for RES need to be setup within snapvol.cfg on all your AppStacks. Also, each AppStack must be configured to execute specific commands from allvolattached.bat.
While you could just add the required edits to snapvol.cfg and allvolattached.bat to each of your AppStacks during the provisioning process, a better solution long term is to create a customized AppStack template containing these required edits. This will make the provisioning of AppStacks easier as well as minimize potential for errors.

2.1 Creating The Template.
Creating the new template involves creating a new VDMK, mounting it, adding the contents of a pre-existing template to it, and finally adding specific customizations for RES. Following are detailed steps for making this happen.

2.1.1 Setup a clean Windows machine.
Stand up a virtual machine that has access to the storage where AppStack templates are located. This virtual machine should not have anything installed on it, and absolutely must not have the App Volumes agent installed. Ideally, it should be running Windows 7, but can also be running Windows 8.

2.1.2 Add a new virtual disk to the Windows machine.
Add a thin provisioned disk to the clean virtual machine. The disk can be pretty much any size you want, but practically speaking you’ll want something in the range of 1 to 40 gigs.

2.1.3 Attach existing AppStack template to Windows machine.
Select to attach an existing hard disk to the Windows machine, then navigate to the AppStack template initially created during the App Volumes installation.

2.1.4 Initialize the new drive.
On the Windows machine, open up Computer Management and navigate to Disk management on the left hand pane. From there, initialize the new drive by selecting MBR (Master Boot Record) and clicking OK.

2.1.5 Create a New Simple Volume out of new disk.
Right click the new disk and click New Simple Volume. Navigate through the New Simple Volume Wizard choosing the NTFS file system. Set the Volume label to CVApps (same as the existing template), and select Perform quick format and then click Next to finish.

2.1.6 Unhide system files and folders
Open control panel and select Appearance and Personalization. Click, “show hidden files and folders,” under Folder Options. Select show hidden files, folders, and drives. Also ensure that these options are selected:
Hide empty drives in the computer folder
Hide extensions for known file types
Hide protected operating system files (Recommended)

2.1.7 Copy contents of pre-existing AppStack template to new VMDK.
Open Windows Explorer, and select existing drive, for example, “CVApps (E:).
Copy all files and folders form CVApps (E:) in to the new drive. In this example, the new drive is CVApps (F:).

2.1.8 Add proper exclusions to snapvol.cfg within the new template.
The following entries should be added to snapvol.cfg in the new template:

#---------RES SOFTWARE EXCLUSIONS BEGIN----------------------------------
exclude_path=\Program Files (x86)\RES Software\Workspace Manager\Data
exclude_path=\Program Files\RES Software\Workspace Manager\Data

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Wow6432Node\RES\Workspace Manager
exclude_registry=\REGISTRY\MACHINE\SOFTWARE\RES\Workspace Manager
exclude_registry=\REGISTRY\USER\SOFTWARE\RES\Workspace Manager

exclude_process_path=\Program Files (x86)\RES Software\Workspace Manager\Data
exclude_process_path=\Program Files\RES Software\Workspace Manager\Data
exclude_process_path=\Program Files (x86)\RES Software\Workspace Manager\svc
exclude_process_path=\Program Files\RES Software\Workspace Manager\svc
#---------RES SOFTWARE EXCLUSIONS END-----------------------

2.1.9 Edit allvolattached.bat
Aff the following commands to allvolattached.bat:

@echo off
setlocal enabledelayedexpansion
set SCRIPT_PATH=%~dp0
reg add "HKEY_LOCAL_MACHINE\Software\AppVolumes" /v AllVolAttached /t REG_DWORD /d "1" /f

(Note: this differs from integration instructions provided by RES. In the RES instructions, the HKEY_CURRENT_USER registry location is used. This can’t be updated by allvolattached.bat because allvolattached.bat runs as a system account. So, I’ve modified the scripts to use HKEY_LOCAL_MACHINE instead.)

2.1.10 Detach both VMDKs from Windows VM
Remove the VMDKs from the Windows OS, making sure not to delete the disks from the data store.

2.1.11 Copy the new template to cloud volumes app template folder
Use putty to copy the new template (both the flat and stub files) from the current location to the /cloudvolumes/apps_templates folder.

mv /vmfs/volumes/datastore/new_VMDK_file*.vmdk /vmfs/volumes/datastore/cloudvolumes/apps_templates/

2.1.11 Rename the template if desired
To rename the template navigate to the /apps_template directory from a putty session. Rename the stub and flat files according to these example commands:

mv OldName.vmdk NewName.vmdk
mv OldName-flat.vmdk NewName-flat.vmdk

Next, edit the stub VMDK using a text editor and update the flat-file refence with the new name.

3 – Script Logic For Pausing RES Workspace At Login.

A key requirement for running RES in combination with App Volumes is having RES Workspace pause at login until all AppStacks have been attached. Once they are attached then RES Workspace is resumed and the relevant app customization and personalization is downloaded. This functionality is achieved by first having RES Workspace push out a special script immediately at login. Running the script pauses RES Workspace and doesn’t allow RES to resume until it’s terminated. The script itself doesn’t terminate till it observes the creation of a special registry key, “HKEY_LOCAL_MACHINE\Software\AppVolumes\AllVolAttached.” This key gets created when the last AppStack is layered on at login and allvolattached.bat is launched. The end result is that RES is paused immediately after the user logs in and is only resumed once the finally AppStack is attached.

(Note: this differs from integration instructions provided by RES. In the RES instructions, the “HKEY_CURRENT_USER\Software\AppVolumes\,” path is used. This can’t be updated by allvolattached.bat because allvolattached.bat runs as a system account. So, I’ve modified the scripts to use “HKEY_LOCAL_MACHINE\Software\AppVolumes\” instead.)

3.1 Pushing Out The Scripts.
Three specific scripts manage the pausing and resuming of RES at login. On script is pushed out by RES immediately after a user logs in. A second one is executed after the final AppStack is created a login. Finally, a third one is pushed out by RES at log off.

3.1.1 Setup special script to be executed at login by RES Worksapce
Add the following script as an Execute Command for RES with the following options:

Run using Dynamic Privileges
Run task: At logon before other actions
Wait for task to finish before continuing
Change the order of execution in "Composition > Actions By Event > At Logon" so that the Execute Command is execution before network mappings are made

(Original script provided by RES modified. “regpath=HKCU\Software\AppVolumes “ was changed to, “regpath=HKLM\Software\AppVolumes”)

3.1.2 Configure allvolattached.bat with code to set registry value
This step has already been detailed earlier in the guide at 2.1.9. Here are the commands again:

@echo off
setlocal enabledelayedexpansion
set SCRIPT_PATH=%~dp0
reg add "HKEY_LOCAL_MACHINE\Software\AppVolumes" /v AllVolAttached /t REG_DWORD /d "1" /f

(See notes on 2.1.9.)

3.1.3 If you’re using a persistent desktop or roaming profile, run the script below to clean up the registry entry created by allvolattached.bat. This will ensure that the pausing and resuming of RES occurs properly the next time the user logs in. Within RES create an Execute Command with the following options and script below:

Run using Dynamic Privileges
Run hidden
Run task: At logoff

REM ---------SCRIPT BEGIN----------------------------------
@echo off
reg delete "HKEY_LOCAL_MACHINE\Software\AppVolumes" /f
REM ---------SCRIPT END------------------------------------

4 – Add Required Registry Keys To Master Image.

Special registry keys need to be added to the master images used to create desktop pools within your environment. These registry keys fine tune the behavior of App Volmes when AppStacks are attached to your desktop image.

4.1 On your master image you’ll need to create to registry keys at: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svservice\parameters]. These keys are DriveLetterSettings and VolDelayLoadTime.

4.1.1 Creating the DriveLetterSettings key.
System Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svservice\parameters]
Value Name: DriveLetterSettings
Data Type: REG_DWORD (DWORD Value)
Value Data: 2

4.1.2 Creating the VolDelayLoadTime key.
System Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svservice\parameters]
Value Name: VolDelayLoadTime
Data Type: REG_DWORD (DWORD Value)
Value Data: 0

5 – Properly Configuring Authorized Files Rules.

5.1 If you’re using Authorized Files in your RES implementation, the Authorized Files rules need to be changed because applications are started from the AppStack instead of the default location.

Take the following application as an example:
C:\Program Files\Folder\Application.exe
Without App Volumes these Authorized Files rules can be used:
C:\Program Files\Folder\Application.exe
%Program Files%\Folder\Application.exe
With App Volumes the following paths will be used instead of the application path:
• \device\harddiskvolume3\Program Files\Folder\Application.exe
• \device\harddiskvolume4\Program Files\Folder\Application.exe
So the following rule can be used to allow the application:
• \device\harddiskvolume*\Program Files\Folder\Application.exe

Sunday, February 21, 2016

Interacting With The App Volumes REST API Through PowerShell

In December of last year Chris Halstead created an App Volumes API reference that blew my mind. (Check it out here:VMware App Volumes API Reference) He walks you through executing App Volumes management functions remotely using it's REST API and Google Postman as a client. After replicating the process in my lab it felt natural to ask, "can I do this in PowerShell natively?" Well, I went kind of crazy figuring out how but finally had some success. It's all about leveraging the Invoke-RestMethod cmdlet. You can find info about it here: Invoke-RestMethod

The first order of business is to login into the API. This is how:

$body = @{
username = “justin"
password = “VMware1!”

Invoke-RestMethod -SessionVariable DaLogin -Method Post -Uri "http://appvolumes.lab.local/cv_api/sessions” -Body $body

So above, "justin" is my AD username and "VMware1!" is the password for that account. "Appvolumes.lab.local" is the name of my App Volumes server. Here's the output:

Using the -Session variable option when executing this cmdlet is key. It creates a web request session object you use to authenticate in subsequent commands. In the command above the web request session object is assigned to a variable called ‘DaLogin’. I can now leverage this variable going forward when making API calls. For example, I can obtain info about App Volumes users with the following command:

Invoke-RestMethod -WebSession $DaLogin -Method Get -Uri "http://appvolumes.lab.local/cv_api/users”

Or, I can obtain information about app stacks with this:

Invoke-RestMethod -WebSession $DaLogin -Method Get -Uri "http://appvolumes.lab.local/cv_api/appstacks”

And, since we're talking powershell, we can easily pin point specific pieces of info we're looking for.

Invoke-RestMethod -WebSession $DaLogin -Method Get -Uri "http://appvolumes.lab.local/cv_api/appstacks” | FT id, name, created_at

Now, using the id # gleamed for the last command I can go on to assign and attach an app stack to a user. Here's the command:

Invoke-RestMethod -WebSession $DaLogin -Method Post -Uri "http://appvolumes.lab.local/cv_api/assignments?action_type=Assign&id=1&assignments%5B0%5D%5Bentity_type%5D=User&assignments%5B0%5D%5Bpath%5D=CN%3Djustin%2CCN%3DUsers%2CDC%3Dlab%2CDC%3Dlocal&rtime=true&mount_prefix="

These are just a few examples of some of the shenanigans we can get into using PowerShell and the App Volumes REST API. For additional examples and details of different API calls you should definitely check out Mr. Halstead's blog.

Thursday, January 7, 2016

VMware vmFork Script

You can take vmFork for a test spin utilizing the latest PowerCLI Extension fling. Below is a script I put together for demonstrating Instant Clone within your own lab. It's based on these two VMware blog posts:

If you're interested in more details, I'd definitely start with these two posts above. Otherwise, if you want to get up and running very quickly with an instant clone demo, follow these steps below. Not only will running this script create instant clones, but it will also give each clone a unique IP address. Further, when your done it can tear down the demo for you by deleting your clones and shutting down the parent VM. Here are the steps:

1. Create a Windows 2012R2 VM.

2. Install latest release of PowerCLI available here.

3. Download the latest PowerCLI extensions from here.

4. If necessary, flag your zip file as unblocked before continuing. (You may experience security issues later that are harder to correct.)

5. Unzip the PowerCLI Extensions to preferably c:\program files (x86)\VMware\VMware Infrastructure\vSphere PowerCLI\Modules or an appropriate path.

6. Create a file named post-clone.bat and add the following lines codes displayed:

7. Create a powershell script by any name you like and add the lines of code showed at the bottom of this page. Ensure it's in the same directory as post-clone.bat

8. At the top of the file there's a section where you populate the script with information about your environment and how you want to child VMs created.

9. Run PowerCLI as an administrator.

10. Set your execution policy "Set-ExecutionPolicy RemoteSigned"

11. Execute your script and make it rain VMs!!!!!!!

Here's what it looks like in vCenter:

You can clean up this environment by pressing any key at the PowerShell prompt. It will go on to delete all your child VMs and shutdown the parent VM.

The Script Itself: