Monthly Archives: August 2015

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!


Passed the VCPD610 (VCP6-DT) Exam!

So, like my last exam (VCP5-DCV) I was scheduled to take the VCP6-DT exam at a certain date. I got anxious, and in a true testament to my impatience, I rescheduled the exam for the soonest possible time. I passed the exam with a 477 of 500 possible points. I am really glad its over. My goal is to hit the road to VCIX-DTM, and this is just a stepping stone. On to the next one!



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.