Horizon View 6.2.2 Gotchas

Hey guys!

A customer and I upgraded their 1500+ seat production VDI+RDSH deployment from VMware Horizon View 6.0 to the latest 6.2.2 this week, and encountered a few issues that are not particularly talked about. This will be more of a brief than my typical post due to time constraints, but I will likely go back to add color as soon as possible.

  1. The first revelation isn’t directed toward VMware at all – This was a facility that utilizes Dragon for dictation, and their support for the PowerMic II’s is dismal. When we upgraded the Horizon View Agent on a user linked-clone pool that was configured for Dragon, the microphone was no longer detected. After a long weekend with no response, my customer was told the issue is likely bandwidth related. That’s a heck of a leap given the circumstances and troubleshooting we recanted to them, especially with no investigation on their part.
  2. For the VMware side of the house – Holy moley was this a hard upgrade for some reason. We walked through all of the pre-reqs (Including new firewall ports) for the new version of Horizon View but felt the smite of the installer itself instead – Even when if reported a clean installation, there were issues with a partial upgrade with most components:
    1. View Composer was partially upgraded even though it claimed success.
    2. View Connection Servers claimed success but still said 6.0 in the Administrator Console. VMware told us that this is a graphical bug they’re trying to squash.
    3. View Security servers would not pair, likely due to corrupted installs with mixed data.
    4. IPSec connectivity between security and connection servers was suspect in this customer environment, even with no network firewall between them and the appropriate rules configured in the Windows Firewall. This led to an early morning call due to loss of external connectivity.
    5. In order to use VMware Blast for RDSH applications, a second installer is required. We’re waiting until all agents are updated before deploying as per VMware’s recommendation.
    6. External access through the PCoIP Secure Gateway wouldn’t work until both the View Agent and the users Horizon Client were updated to the latest version. This was unexpected and not documented in the VMware Compatibility Matrix. You can imagine the scramble to resolve that one.
    7. Teradici Tera1-based zero clients will be no longer VMware certified (or supported by Teradici) at the end of April 2016. As it is, they can not have the latest 4.8 firmware applied to them, requiring …..
    8. Enable TLS 1.0 and 1.1 if you’re hardware or software is unable to communicate securely. Or decide to remediate the actual issue (Deprecated hardware/software) instead of compromising security. This will be required end-to-end.

That’s it for now – As I said, I plan to come back and color these in as time permits.

Be careful out there!


Migrating VMware View vCenter to a new host

Hey everyone!

The end of support for Windows Server 2003 is coming, and a lot of organizations are scrambling to migrate their production systems before the  July 14, 2015 deadline. Many groups are still running the vCenter (5.0 or 5.1) that VMware View utilizes on Windows Server 2003, and I was recently asked about the migration path. For a vCenter/Windows OS compatibility matrix, click here.

There are two scenarios: One where the vCenter server maintains the same hostname and IP address, and one where the name and IP change. Today’s post deals with the first scenario and tomorrows will address the second.

Migrating vCenter to a new host without VMware View downtime
IMPORTANT NOTE: Proceed at your own risk. This operation is not supported by VMware. Click HERE for the KB.

  1. Export RSA Keys from old server
    1. Open an administrative command prompt and navigate to navigate to the %windir%\Microsoft.NET\Framework\v2.0xxxxx directory
    2. The ASP.NET IIS registration tool exports the RSA public-private key pair from the SviKeyContainer container to the keys.xml file and saves the file locally. Type: aspnet_regiis -px “SviKeyContainer” “c:\keys.xml” -pri. 
    3. Copy the .XML file to the new server or network storage.
  2. Document Database user names and passwords

  3. Shutdown Virtual Center Services (And Composer if co-existing) on the vCenter server being replaced

  4. Log into the View Administrator portal and disable virtual machine provisioning.

    1. Expand View Configuration
    2. Go to Servers\vCenter Servers
    3. Select the vCenter that will be migrated, and select ‘Disable Provisioning’
  5. Perform end-to-end backups of your environment (vCenter, Composer, ADAM). KB for that HERE.
  6. Shutdown old vCenter Server.
  7. In Active Directory, delete the old vCenter computer object.
  8. On the new vCenter Server, Rename the machine to the same as the old vCenter Server, Assign is the same static IP as the old vCenter, and join to the domain.
  9. Migrate RSA Keys to New VCenter Server
    1. On the destination computer, open an administrative command prompt and navigate to the %windir%\Microsoft.NET\Framework\v2.0xxxxx directory.
    2. type: aspnet_regiis -pi “SviKeyContainer” “path\keys.xml” –exp
  10. Install SQL Native Client (sqlncli.msi)
  11. Configure ODBC System DSN Connection for VCenter (Native 64-bit) and View Composer (Native 64-bit).
  12. Perform a simple installation of the vCenter Server and components (same version as what was running on old VCenter Server)
  13. If View composer is not standalone, Install View Composer. This may be a good time to split View Composer off of the vCenter server if that’s your ultimate goal.
  14. Ensure that all services started and are running.
  15. Connect to vCenter using either the vSphere client or Web Client (Depending on version). Ensure that hosts have reconnected and everything looks as you’d expect.
  16. In View Administrator, you may need to go to the Dashboard and Verify the SSL Certificates for the new VCenter.
  17. Enable Provisioning in View Administrator (should just work)
  18. Double-check any customization specs in the new VCenter Server.
  19. Test Recomposing and Provisioning of new Linked Clones.

User experience and expected behavior

It’s not exaggerating to say that this is an intense change-the-tires-while-doing-60-on-the-highway kind of operation, but in my testing of an 25 linked clone environment there was no impact. Any existing desktop connections or new connections to existing desktops should observe little or no disruption of service.

Resolve VMware View desktops in “Already Used” state


This blog post should be a refresher, but I had to change this setting recently and thought I’d throw it out there on the blog as well.

In this situation, the client is running Horizon View 6 and predominately uses floating linked clone desktops that are set to refresh once a user logs out. For an unknown reason, this client does not prevent users from performing power operations on the View desktop that they’re connected to. This resulted in a few desktops in an “Already Used” state throughout the day as users presumably shutdown or restart their virtual desktops instead of logging off.

IT has been resolving this by manually refreshing desktops in this state. However, there’s an automated way to correct this problem if its happening to you!Enter PAED-DirtyVMPolicy. This per-pool setting (View 5.1.1 and newer) allows control over how “Already Used” desktops are treated.

There are three policy settings:

pae-DirtyVMPolicy=0. Mark virtual machines that were not cleanly logged off as ‘Already used’ and block user access to them. This is the default behavior in View 4.6 and later releases.

pae-DirtyVMPolicy=1. Allow virtual machines that were not cleanly logged off to become available without being refreshed. View Client users can access these desktops.

pae-DirtyVMPolicy=2. Automatically refresh virtual machines that were not cleanly logged off. View Client users can access these desktops after the refresh operation is completed.

Source: https://www.vmware.com/support/view51/doc/view-512-release-notes.html?ClickID=dkhs0xbx0kzhztss2ynnshxsykxz2zhozybk

To apply these a policy, RDP to a connection server and fire up ADSI Edit:

1) Connect to dc=vdi,dc=vmware,dc=int on localhost:

2) Expand the Server Groups OU:

3) Choose a pool experiencing the issue:

4) Right-click and select Properties on that pool:

5) Scroll down until you find pae-DirtyVmPolicy. Set this to a 1 or 2 to resolve.

6) Repeat for all affected pools.

NOTE: It would be a good idea to prevent users from performing power options on View Desktops via Group Policy and let the View Manager handle it. That group policy would change settings here: User Config>Admin Template>Start Menu and Taskbar>Remove and prevent access to the Shutdown, Restart, Sleep, and Hibernate

VMware vExpert 2015!

Hello all!

First week of February- first three days in a VMware AirWatch bootcamp and the remainder roaming the Mascone Center in San Francisco at PEX. If you’re looking for a Mobile Device Management/Enterprise mobile security/File sync and share solution, AirWatch is for you. I’m also interested to see how tightly Airwatch will get integrated into the Horizon roadmap at some point in the future.

The 2015 vExpert announcement came out on my way home from VMware PEX. I’m absolutely humbled to be included on a list of absolute VMware rockstars for the first time.

I guess I have to double my efforts on this blog and my other outlets to prove (to myself) that I belong on this whos-who list!

My P2V Conversion Guide

Hey all!

I’m on an engagement with a client that includes a dozen or so hard-to-p2v physical servers. I’m sure I’ll have other posts as I work through the issues, but one of the Jr. Administrators on their staff asked if I had a best practices or how to guide for successful P2V’s.

So to add to the web pile of guides on this subject, I bring you my take on virtualizing existing servers!


Edit VM Hardware V10 VMs

Hey all!

There’s a an updated version of vSphere out, vSphere 5.5 update 2.

  • Hosts can have 6TB of RAM installed
  • Microsoft SQL 2012 sp1 and 2014 support
  • Drops web client support for Windows XP and Vista
  • Drops IBM DB2 as a supported for the vCenter database
  • Other improvements and bug fixes

But also improved and not necessarily trumpeted in the announcement? A new and improved C# Client, complete with 100+ bug fixes and the ability to edit Virtual Hardware Version 10 machines!

I just tried it out on a VM in my lab, and I get this dialog:

This is a huge step forward for the C# Client! Even if you can’t use it to configure advanced HW10 features, it can be used to increase number of vCPUs, Memory, disk space…. all of the important stuff.

The rumor mill can also be heard saying that the C# client will gain full functionality in the coming year.

Important note: I didn’t need to upgrade my lab to the latest upgrade to edit HW version 10- I was able to just use the new C# client available on the installation media.

A Guide to Migrating VMware 5.1 Databases from SQL Express to SQL

Hey All!

I had a somewhat messier database migration at my most recent site, and it made me do a bunch of research that would make sense to share here. Most of this information came from KBs or scattered across the Internet… so welcome to your one-stop-shop for how to migrate VMware databases, and what I had to do when things went wrong.

I had to migrate a pair of environments today. One of them was a View install that has more moving parts, so I’ll illustrate that here.


Getting Started / SQL Pre-Reqs

I’m not going to fill up this blog post with how to set up SQLBest practices. I assume that you know that already. I included links just in case. What I WILL include are things that are needed after SQL is set up:

  1. Open port TCP 1433 on any Firewall program running on the machine.
  2. Set ‘Maximum Server Memory‘ (SQL Memory Max) to something sane for your environment.
  3. Open SQL Configuration Manager and expand SQL Network Configuration. Make sure that TCP/IP is enabled. Disable Dynamic Ports.
  4. Good. Now create a new SQL user account– I used VMwareUser.


View Composer

I started with the View Composer database because it didn’t have a strong dependency on the other components- The other good reason is that VDI administrators tend to be different than your vCenter administrators and may have different availability windows.

  1. Go through each pool and disable any refit operations that occur on logoff.
    1. This is mostly a safety thing. I want to be sure that there are no desktop operations running until I say “
  2. Disable the View Composer service
  3. Create a backup of the View Composer database using a File Backup in SQL Express.
  4. Copy the database backup to network storage or a local drive on the new SQL server.
  5. Create a new shell database on the shiny SQL server. Call it something nice- this is name will only be seen by you or the DBA team.
  6. Right click the new database, go to ‘Tasks’ and select ‘Restore Database‘. Select the backup file, and on the Options tab select ‘OVERWRITE’.
  7. Make VMware User dbo of the restored Composer database.
  8. Back on the server running View Composer, edit the Composer DSN. This is a 64-Bit DSN, so Administrative Tools > Data Sources (ODBC).
  9. Modify the SVIWebConfig. Sorry :-/
  10. Start up View Composer. If it starts without error, re-enable refit operations on the pool.


Update Manager

Theres a strong argument to start Update Manager fresh instead of migrating old information – in my case, the customer wanted to maintain some custom baselines… so migrate away!

  1. Disable the VMware Update Manager service.
  2. Create a backup of the VIM_UMDB database using a File Backup in SQL Express.
  3. Copy the database backup to network storage or a local drive on the new SQL server.
  4. Create a new shell database on the shiny SQL server. Call it something nice- this is name will only be seen by you or the DBA team.
  5. Right click the new database, go to ‘Tasks’ and select ‘Restore Database‘. Select the backup file, and on the Options tab select ‘OVERWRITE’.
  6. Make VMware User dbo of the restored VUM database.
  7. Back on the server running Update Manager, edit the Update Manager DSN. This is a 32-Bit DSN, so c:\Windows\SysWOW64\odbcad32.exe
  8. Edit the vci-integrity.xml file to reflect the new database information. I’m really sorry about this.
  9. Reconfigure VUM using the VMware Update Manager Configuration Utility 
    1. Modify the Database settings
    2. Re-Register with vCenter.


vCenter Database

Here’s the big one. Make sure you have a window of time for this one to be down that extends for both vCenter and SSO – SSO shouldn’t cause an outage, but if there are any configuration issues vCenter won’t be able to start… better to be safe and have a longer outage window than required. While vCenter is offline, no administrators will be able to get in and run the environment, no power operations will occur for VDI desktops, and DRS won’t work (Among other things)

  1. Disable the VMware vCenter  service.
  2. Create a backup of the VIM_VCDB database using a File Backup in SQL Express.
  3. Copy the database backup to network storage or a local drive on the new SQL server.
  4. Create a new shell database on the shiny SQL server. Call it something nice- this is name will only be seen by you or the DBA team.
  5. Right click the new database, go to ‘Tasks’ and select ‘Restore Database‘. Select the backup file, and on the Options tab select ‘OVERWRITE’.
  6. Make VMware User dbo of the restored vCenter database.
  7. Open the Registry Editor. I’m really sorry about this too.
    1. Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > VMware, Inc > VMware VirtualCenter.
      1. Ensure that HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB\1 contains the correct DSN.
      2. Edit HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB\1 to the SQL username ‘VMwareUser’
      3. Ensure that HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB\4 has the right SQL driver.
      4. Edit HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter/DbInstanceName and clear it (Don’t delete though!)
      5. Edit HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter/DbServerType and change the Value to Custom.
      6. Open an Administrative Command Prompt. CD to “C:\Program Files\VMware\Infrastructure\VirtualCenter Server” and run the command vpxd.exe -p
        1. Enter password information when requested.
  8. Recreate the SQL Rollup Jobs.
  9. Open another configuration file in notepad: C:\ProgramData\VMware\VMware VirtualCenter\vcdb.properties
    1. Put a hash mark (#) to comment out everything in this file EXCEPT  usevcdb=true
      1. NOTE: The file could be modified to contain correct information, but the above method seems to work fine as well. To each their own.
  10. In the same directory, open dabase_name.properties in notepad. Verify that the Tomcat information is correct.
  11. Attempt to start the vCenter Service.


Single Sign On

Reinstall Single Sign On. Just kidding, although migrating this component has made many an engineer pull their hair out. I had my own issues during this migration and the vast number of suggestions I received went along the lines of “It’s better to reinstall vSphere if SSO is having any issues”. I powered through, and now you can too!

  1. Backed up the SSO configuration using the “Generate vCenter Single Sign-On backup bundle” link in the Start -> Programs menu from the SSO server.
  2. Disable the vCenter Single Sign-On  service.
  3. Create a backup of the RSA database using a File Backup in SQL Express.
  4. Copy the database backup to network storage or a local drive on the new SQL server.
  5. Create a new shell database on the shiny SQL server. Call it something nice- this is name will only be seen by you or the DBA team.
  6. Right click the new database, go to ‘Tasks’ and select ‘Restore Database‘. Select the backup file, and on the Options tab select ‘OVERWRITE’.
  7. Create new users (Or verify that the users migrated during the restore process) RSA_USER and RSA_DBA
  8. Check that the RSA_User that was migrated doesn’t have any mappings using this query against the restored database: sp_change_users_login report
  9. Create a new SQL User named RSA_USER at the SQL Server level. Give it the same password as RSA_USER had on the original SQL Express installation.  Set the default database to the newly restored SSO database.
  10. Run this query against the SSO database to re-map the RSA_USER account: sp_change_users_login ‘update_one’, ‘RSA_USER’, ‘RSA_USER’
  11. Recreate the RSA_DBA SQL user account and give it DBO over the SSO database.
  12. On the SSO Server:
    1. Navigate to the ssocli command – In my case, it was C:\Program Files\VMware\Infrastructure\SSOServer\Utils. Run the following command: ssocli configure-riat -a configure-db –database-host new_host_name
      1. Enter the SSO Master password that was used when SSO was initially set up.
    2. Go up a directory and open up the ..\SSOServer\webapps\ims\WEB-INF\classes\jindi.properties file in Notepad.
      1. Modify com.rsa.db.hostname to the hostname of the new SQL server
      2. Change the com.rsa.instanceName to the SQL Database Name here (instanceName seems inappropriate)
    3. Navigate to C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes\config.properties
      1. Change the dburl= line to the information for the new server.
  13. Start SSO and hope for the best.



Some cleanup items at this point:

  1. Go into the registry and break the dependencies on SQL Express for vpxd.
  2. Restart all VMware services twice to ensure proper operation
  3. Make sure that the Web Client works correctly and that performance graphs load as expected
  4. Restart the server to make sure all comes back up.
  5. ???
  6. Profit!

Differences between VM Hardware Versions

Hey all!
I was asked by a client for a comparison chart, so I thought I’d put it up here as well:

Virtual Hardware Version




ESXi 5.5
Fusion 6.x
Workstation 10.x
Player 6.x

  • vSATA Disk Controller increases devices per channel
  • vGPU support for non-Intel VMs
  • Larger vDisk (62TB) maximum size


ESXi 5.1
Fusion 5.x
Workstation 9.x
Player 5.x

  • Support for Intel VT-x/EPT and AMD-V/RVI
  • Ability to reclaim space from thinly provisioned disks
  • vGPU Graphics for Intel GPUs
  • vCPU performance counters


ESXi 5.0
Fusion 4.x
Workstation 8.x
Player 4.x

  • 32-way SMP
  • 1TB RAM in a single VM
  • Basic software 3D support
  • USB 3.0
  • UEFI Bios


ESXi/ESX 4.x
Fusion 3.x
Fusion 2.x
Workstation 7.x
Workstation 6.5.x
Player 3.x
Server 2.x

  • VMXNet3
  • 8-way SMP
  • 256G RAM in a single VM
  • Enhanced vMotion Compatibility (EVC)
  • Hot Plug support for devices

Note that VM Hardware version 10 VMs are controlled predominately through the vSphere Web Client.

Cant start View Composer service after migrating Composer database

Hey all!

This is another story fresh from the field- luckily one with a happy ending.

I was engaged on a fairly quick project to migrate the internal VMware and Horizon View databases from a default SQL Express instance to a new SQL server that the client built and configured. This is something that I’ve done many times in the past, and has routinely gone to plan.

It’s important to remember that every every environment is unique. This particular environment required an additional hour of time to get View Composer back up and churning out ReFit operations! As in most things, but particularly advanced IT work…. Prior results don’t guarantee a repeatable checklist!

The process we took for the database migration was as follows:

  1. Create a backup file on SQL Express.
  2. Back up the View Composer database in SQL Express.
  3. Rename the backup file and transfer to network storage/C$ drive of the new SQL server.
  4. Create a shell database in SQL on the destination machine.
  5. Restore the Composer backup OVER the new SQL database.
  6. Create a new SQL account and make it owner of Composer database.
  7. Repoint the Composer DSN on the machine running View Composer using SQL account credentials.

Seems pretty simple, and has worked many times in the past. This time as I said, things didn’t go to plan.

After the migration, going into Services and trying to restart the View Composer service gave an error. In the logs for Composer, I saw that it was trying to connect with the old DSN name and blank credentials.

I checked the DSN, and retested the connection – Correct credentials, and the test was successful as expected. Where is Composer getting this info?

Turns out, I needed to change another thing in this environment.

I needed to follow this KB to edit the SVIWebConfig, substituting sane values for our environment:

After performing the above, Composer started and all was well with the world.

Then I had to migrate the vCenter databases and ran into another weird DSN problem… which will be the subject of another Blog post!

HomeLab: Installation and Configuration

Hey All!
If you saw my previous post, I identified components that would make a pretty decent beginning to a home lab.
I made those purchases via Amazon, and assembled the components. Luckily everything worked fantastically out of the box – I was secretly worried that my lack of recent computer building experience would bite me when it came to assembly: it seems that building computers is an awful lot like riding a bike in that regard.

Alright. So now we have two black boxes that power on and display the friendly message:
Operating System Not found.

Now what?

Note: I assume everyone reading this blog is a VMware vExpert and Microsoft MVP and get licensing that way. Otherwise, license VMware and Microsoft products as you normally would. Both also offer trial periods of their software. 

  1. Install ESXi on our new hosts:
    The decision was made to use USB flash for ESXi and dedicate the internal drives to running VMs, so the time has come to mess with the USB Flash drive.We don’t have any internal optical drives in our set-up, nor did I have any externals readily available. Turns out we can do this entirely without wasting a disk!

    1. Download RUFUS Windows utility. RUFUS = Reliable USB Formatting Utility (with Source)
      Similar tools exist for other Operating Systems. For what it’s worth, I ran RUFUS on a Windows VM on my Mac. 
    2. Download ESXi ISO from VMware Download page.
    3. Load the ISO into RUFUS.
    4. Replace Menu.C when prompted by RUFUS.
    5. Click ‘Close’ when complete.
    6. Boot ESXi Host using USB key (You may need to modify boot order for this step)
    7. When ESXi installer loads, perform a normal ESXI installation. Install to USB Flash (This will wipe out the installer ISO)
    8. When complete, you have a working ESXi system. Hooray! In my case I did this to both boxes.
  2. Configure a management network on each host
  3. Use the vSphere client to connect directly to a host
  4. Create a new VM for vCenter
    1. Mount your Windows Server ISO in your new vCenter VM
    2. Configure machine to VMware best practices (You can probably get by with less for this sized environment)
    3. Install Windows
    4. Mount the vCenter installation media (From VMware’s Downloads page)
    5. Perform a simple install of vCenter
  5. Create a new VM for Active Directory
    1. Mount your Windows Server ISO in your new AD DC VM
    2. Follow this tutorial

This is the very beginning of the home lab. In future posts, I’ll detail the AD Configuration and other Lab related things!