Category Archives: EUC

This section is about Horizon infrastructure components.

App Volumes: Architecture, Security, Storage, and Logs…Oh My!

So, you’ve gone and gotten yourself a copy of App Volumes, or are thinking about it? Welcome to the club. It is a pretty slick piece of software, and I am really enjoying working with it. We have replaced our Unidesk deployment with Horizon Enterprise using App Volumes for application delivery. If you already have App Volumes deployed, or are even just thinking about it, here is some info that may be of use. Shout out to @chrisdhalstead and @VirtualStef for all the great info presented here. They put on some great sessions at VMworld this year.

Architecture Considerations:

2 App Volumes Managers at minimum, load balanced.

SQL Express for Dev / Test ONLY

Clustered SQL servers

App Volumes – Storage


  • Read Only
  • 1:Many
  • 20GB Default Template
  • Dedicated Datastore Recommended for AppStacks
  • Right-Size your templates (No need for 20GB template for a 10MB program)

Writable Volumes

  • Read / Write
  • 1:1 Per User
  • 10GB Default Template
  • Right-Size your templates here too.

Optimize storage volumes for Writable Volumes

  • Consider RAID 1 or RAID 10

Flash Storage Array Support

User Concurrency for each application and storage requirement may impact IOPS

Security Considerations

Replace default self-signed SSL certificate for App Volumes Manager (svserver.crt)

Deploy ThinApp packaged applications to leverage isolation modes

Use a read-only Active Directory service account for App Volumes

  • vCenter Administrator Privileges required for mount operations.
  • ESXi root required if using local mount option

App Volumes – Agent Log Files

The App Volumes Agent has 2 log files that can be found on the machine. These two files are the svservice.log and the svdriver.log. Both of these logs can be found in the same directory:


The App Volumes Agent can be found in the Windows Services, as with any other agents. Check there if you’re not getting any response or issues from the agent.

App Volumes – Manager Log Files

The App Volumes Manager also has 2 log files that can be found on the App Volumes Manager server. These logs are called production.log and svmanager_server.log. Both of these logs can be found in the same directory:

C:\Program Files(x86)\CloudVolumes\Manager\*.log


Hopefully some of this info was helpful to you. If you have any questions or concerns about your deployment, feel free to leave a comment or tweet in my general direction. Happy Stacking!



How to query the Horizon Client version remotely

I already feel that this is the most serious post ever. Most of my posts have (what I call) clever titles. I couldn’t think of anything good, and wanted to make sure that this title got across what is happening here. This all stemmed from a VMTN post I saw here.

The poster had roughly 1000 remote VDI users, in a scenario where they didn’t have the ability to manage the local hosts that were being utilized to access the VDI environment. They wanted a way to query the remote host to find the Horizon Client version. This is to make sure that each one is using the same client version. This can be important to manage the user experience. You don’t want really old clients out there causing problems, or possibly be missing features. Now, you are pretty limited without access to the local system. Now, scripting a pull of 1000 clients isn’t my forte, but I figured maybe I could at least help advise where to find the info. My thought was that the Horizon Agent logs may have something in the connection string. There was nothing of value in the Agent logs. Shout out to @jshiplett for the assist. He pointed me in the direction of the PCoIP logs (Which are located on the VDI, not the host machine). This was the ticket.

PCoIP Log Location : DriveLetter:\ProgramData\VMware\VDM\logs

Note: This only works if you utilize PCoIP as the connection method. If you use RDP, this log will not update.

I fired up my VDI, and connected in with PCoIP. My host machine is a Mac running the Horizon 3.2 Client. I knew I’d be looking for a string or series of entries that included “Mac” or “Apple” as that would be the logging of my client info. I found the following series of strings:



You’ll see a full rundown of client info in this connection strings. It shows my host OS (Mac OS X), OS bits (64), Processor Architecture (x86), and…oh look… PCoIP Version… How about that. Now, I know the PCoIP version isn’t exactly 1:1 with the client version (It’s pretty close), but matching the PCoIP software versions would help you to regulate your client versions.

Now, I realize this doesn’t completely solve the posters problem. He’ll need to find a way to script a log pull of all that mess, and get it formatted. This is something that I can not even begin to get into yet. Don’t worry… I’m working on PowerCLI… I swear…

Alright kids, it’s time for me to get back to the VMworld 2015 festivities. Take it easy!


Sysprep: A story of failure…

Don’t worry, this story has a happy ending…finally.

I have been working with one of our customers to get them migrated out of our old Unidesk environment, into the new Horizon 6 environment. We provided them a template machine cloned off of our Gold Master. This is one of two pools that will not be managed with App Volumes and Mirage simply because of the issues we’ve had with this users pool in the past. I am not going to get into all that at this time.

They completed their app configuration, and tested it. They certified the template. I then went in and completed the final steps we normally go through for the template. I verified VMtools and the Horizon agent, cleaned up some temp files, then ran the ClonePrep tool from Symantec to clear all the SID’s (this allows for a clean Symantec SID so that you don’t have issues joining the master server. More can be found on that here. I then shut the machine down and created the snapshot. Easy right?

Once that was all set, I setup the pool and pushed the provisioning. Everything was going great. Composer was doing its thing. Everything was great until we got to the Sysprep customization. It just sat there. And sat there. And sat there. Checked the console, and they still had the template name. Never rebooted.

At this point I assumed something was broken. I started doing some digging. Normally, I don’t disjoin the template from the domain and it doesn’t give issues. I also normally don’t release the IP on the template. Also, normally no issues. I tried all of the following:

1. Disjoin from domain

2. Release the IP

3. Apply MS hotfix KB2550978 for VMXNET3

4. Created a new Sysprep config in vSphere

None of these fixes worked at all. I tried to create a clone of the VM straight from vSphere and that didn’t work. This lead to thinking it was a Microsoft issue. It was time to look at Sysprep itself. The log files can be found:


The errors in the Sysprep logs stated:

failed to query pending cbs operations

A quick search on this lead me to a registry key fix:

Make the following change to your registry:
Key: RegistrySizeLimit 
Value: 0xffffff (4294967295) 2) Reboot 

3) As a Administrator open a Command Prompt and run “SFC /SCANNOW”. The command should complete successfully and if any errors were found, they should be corrected. 

After the reboot, I tried the vSphere clone again. Still failing. Though, this time, I had a much different set of errors.

SYSPRP RunExternalDlls:Not running DLLs; either the machine is in an invalid state or we couldn’t update the recorded state

SYSPRP WinMain:Hit failure while processing sysprep cleanup external providers

I did some searching on this, and found some terrible news. All of the “accepted answers” from MS or from others, was that the image was toast and needed to be rebuilt. This was just simply not acceptable. I could not have this user build their whole image again. I read just about every post on every search result I could find. I finally found someone saying that if the machine you were trying to sysprep, was in fact sysprepped itself to be created, that could cause an issue.

Bingo. We clone all our templates off the gold master, and sysprep them to give them the DNS name, etc. The following steps cleared out the Sysprep files and set the re-arm skip to 1, allowing Sysprep to once again be run off the machine:

1. Navigate to %WINDIR%\System32\Sysprep\Panther

2. Delete or Move / Rename all of the files in the Panther directory

3. Open RegEdit

4. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\

5. Change the GeneralizationState key to 7

6. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\

7. Change the SkipRearm key to 1

8. Complete template finalization steps

9. Shutdown / Snapshot

Voila! Sysprep ran like a dream. First on the vSphere clone, then on the recompose of the busted pool. That was a rough one.

Hopefully this doesn’t happen to you, but if it does, never fear.


App Volumes 2.9 “Upgrade” – And Migration

Well, it’s 7:00AM on a Saturday. Of course, that means its the only real time I have to take any production systems offline. Today’s task involves getting App Volumes migrated to a new storage frame. In order to do this, I need to upgrade it from 2.6 to 2.9 so that I can take advantage of Storage Group Automation. More on that shortly. If you’re not familiar with App Volumes, it is a semi-recent acquisition by VMware of a company called Cloud Volumes. It is a seamless virtual application delivery platform. See here:

This product is fantastic. Though, I have found a small issue. You may have noticed above that the word upgrade is in quotes. This is because there is no upgrade.  You have to fully uninstall the management server and re-install the newer version on top of the existing database and app stacks on your storage. Yes, you retain your existing app stacks. It just seems sketchy. This process is outlined in the App Volumes 2.9 user guide found here.

The first step is to completely uninstall the existing App Volumes Manager. Note that this does unmount all app stacks! The services will be unavailable. No reboot is required when doing this. Next, mount the App Vols 2.9 ISO to the management server. I find it is easier later to just unload all the files from the ISO to a share. That way I can access the agent later without the ISO. When you are going through the install, make sure that you select to use an existing DB server. Point it at your SQL instance, and make sure that the overwrite checkbox is UNCHECKED.



Let the installer do its thing. Leave the connection ports default, unless you changed them for your installation. Once the installer is done, you should be able to log back into the Manager with the same credentials you did before.



All you do now is update your templates with the new agent, and recompose the pools. If you want, do it manually. Whatever you’re into.


And now what everybody has been waiting for….



I had to complete this upgrade today, because of my real problem. We are migrating our VDI environment off of a shared EMC VNX storage frame to a new dedicated Compellent storage frame. App Volumes 2.6 doesn’t make this an easy task. App Volumes 2.9 includes a nifty little update called Storage Group Automation. This allows the software to replicate the stacks to the new storage for you.

You start off by going into Infrastructure -> Storage Groups. From there you’ll want to create a new storage group. Give it a name like “temp_migration.” Leave auto import app stacks unchecked, but do select Automatically Replicate AppStacks. This is the key to the software moving stuff for you. Select Spread for the Distribution Strategy. Select what volume you want for your Template Storage. Under Storage Selection, choose Direct, then select the existing AppStack LUN as well as the new LUN.



Once you hit Create, the magic starts automatically. As soon as all the copy operations are done in vCenter, you should be fully replicated. Simply go in and delete the Storage Group.


Horizon POC: A Mirage on the Horizon

I have officially dove head first into a full Horizon Enterprise POC in the Lab. Up to this point, my only experience has been with Horizon View. I am glad to have the opportunity (and licensing) to give Mirage, Workspace, and AppVols a go. There should be several posts coming regarding my experiences.

I’m just going to start out with a HUGE shout out to @jshiplett for his Mirage Series at This was MORE than helpful during my install experience.

My initial plan was to set out and build it out to flip to production, when the time comes.  This would have had a separate server for each. I realize now that since Mirage is a fairly easy distributed platform, I can throw it all together in one server for now.  I have installed all the components into Mirage. I initially created two VDI in the Horizon View POC environment, and I have registered them into the Mirage environment. At this point, I have used one to create the reference CVD. My plan is to buy a 2-in-1 that I can use to test the P2V2P functionality, for disaster recovery. I’m sure I will have way more to update. Please send any info, words of advice, or links that you may have!



Lord of the ThinClients: An Unexpected Journey (Updated)

It has come to my attention that our VDI environment is entirely too small. We are currently running roughly 500 VDI, in 20-ish pools, across 2 different View instances (5.0.0 and 6.0.1), spanning 3 different vCenter Servers. The old 5.0.0 instance is a running catastrophe due to the integration of Unidesk on half of the ~230 VDI running on View 5.0.0. Unidesk is a fine product, that I’m sure works in some cases. However, it does not for us. It was implemented before I came into the picture.

ANYWAYS, The new hotness is a Horizon View 6 instance. It is running segregated on it’s own ESX 5.5u2 / vCenter 5.5u2 environment. This is backed with 8Gig FC SAN connectivity and 10GigE fiber network connectivity. This is the wave of the future. It was built, from scratch, so we could completely eliminate the old instance and vCenters, and to start fresh. So this is where we are at. Management would like to bring the VDI offering to the forefront of the customers subscribed services. They are in the middle of their XP phase-out, and have a large series of Hardware Refresh projects for workstations coming up. We would like to POC and turn-over the Horizon 6 suite. View, Mirage, Workspace, and AppVols specifically. We want to be able to show the customer how we can provision, manage, and protect their end-user-computing infrastructure, while saving them overhead cost. This is where my journey begins. We are going to be getting 2 Chromebook 11’s and 2 Wyse thin / zero clients for POC testing. From my brief investigations, it seems the only way to really use Horizon on the Chromebook is through the Blast web UI. Is this accurate? Is there any chromebook where I could install the Horizon Client and utilize it as I would on a Windows workstation? Is the added portability something that we would bulk-sell the customer on, or would we use Thin / Zero clients, and offer the up-charge of a portable Chromebook if they need to be mobile? Any and all input from people who went through this would be appreciated. Please feel free to spread this around. I can be reached on twitter @ALDTD, and via email at if anyone can lend their advice and input.



I have ruled out Chromebooks almost entirely. I do not want the user to have to rely on the HTML access via Blast for access. We are going to explore Mirage-managed endpoints for mobile users who need to go offline.