Tag Archives: VMware View

What’s the Next Step to Achieving VDI Utopia?

One Master VDI Image

If you’ve been deploying VDI technologies for some time, you’re probably familiar with the VDI Utopian goal of “one master image” and with the technologies available today, is this goal achievable?

Now, going back to the IT stone ages of 2009, when I first started deploying VDI technologies (referring to VMware View and Citrix XenDesktop….I’m not counting XenApp for the purposes of this article), my first two projects, which you can read more about here, were pretty eye opening.

  • Citrix, to their credit, could kinda-sorta provide a single master image with XenDesktop assuming all applications could be published from XenApp servers.  However, this required a Provisioning Server infrastructure that some administrators couldn’t quite understand or get a handle on AND it could require many XenApp servers and multiple XenApp server silos depending upon the required applications.  Though I did get a single master image on the desktop side, I did have to manage multiple XenApp server-based images to support application publishing.  As I wrote in the post referenced above, to support 300 Windows XP desktops and their required applications, 50+ Citrix servers were required.  So, does this really count in achieving the goal of one master image?
  • VMware, at this time as best I can can recall, didn’t make any, “Use VMware View and you’ll only need one master image!” promises.  Again, if I can recall 2009 correctly, VMware did claim that VMware View was “simpler” than XenDesktop in terms of deployment and configuration.  I found the claim to be true in that I only needed a single connection server to support 125 virtual desktops.  However, to support the 125 virtual desktops and their different functions within the organization, I needed 11 master images.

Simplified, my primary observations upon completing these project was this:

  • Generally speaking…Citrix XenDesktop requires fewer desktop images (if not 1) but requires more server-based infrastructure to support OS streaming and published applications.  Compared with XenDesktop, VMware View requires significantly less server-based infrastructure, but requires more desktop images based on the application and configuration requirements of the organization.
  • There’s got to be some better solution….there must be some way to cut down on the number of both master images and server-based machines to provide a good, dynamic, and scalable VDI solution.

Enter application layering….

In 2011, I deployed Unidesk and it quickly became a “mandatory” component on all of our VDI projects.  With Unidesk we were able to minimize both the number gold images and the number of server-based resources required to support VDI initiatives…the Unidesk solution gave us the best of both worlds.  The only time multiple gold images are required is if a customer wants to support multiple OS’s such as Windows 7, Windows 8.1, Windows 10, etc.  But gone are the days when I need 11 Windows 7 gold images to account for distinct use cases and gone are the days when I need 50+ back-end servers to support standard enterprise applications.

Recently, we have been able to achieve the same goal using VMware App Volumes so the “single master image VDI environment that minimizes server-based requirements that also provides a dynamic and scalable infrastructure that’s relatively easy to manage” dream has become a reality.

What’s next VDI dream?

What’s the new dream in the realm of VDI Utopia?

Deploying only Non-Persistent Virtual Desktops

Maybe it’s deploying only non-persistent virtual desktops, an idea, a concept, and a question many organizations are looking into.  Why?

  • It’s easier….something happens to a desktop, you reboot it and it is reset back to its “clean” state
  • There is a belief (and I say this because I haven’t studied this first-hand) that the more non-persistent desktops you deploy, the fewer virtual desktops you’ll ultimately need.  If you can reduce the number of deployed virtual desktops, you reduce the number of servers required to host virtual desktops, you reduce the amount of storage that’s required to host virtual desktops….in short, you can reduce the cost of the VDI infrastructure.

This dream may soon become a reality as there are now tools out there, from VMware and Liquidware Labs as examples, that allow an organization to provide, if this makes sense, persistence in a non-persistent VDI environment.

A Single Non-Persistent Virtual Desktop Pool for the Entire Organization??

Or maybe it’s deploying non-persistent desktops from a single desktop pool….and I bring this up based on the VMware EUC video Delivering Secure Role-Based Desktops with VMware NSX and App Volumes

It seems VMware has a dream to break away from the traditional VDI pool-based approach and instead focus on a user-based approach, utilizing App Volumes and NSX, in order to reduce OPEX and complexity.  Basically, App Volumes would be used to dynamically deliver applications specific and NSX would be used to configure unique security policies based on the user’s role….the virtual machine itself becomes more or less irrelevant.

Conceptually it sounds great and I’m sure App Volumes and NSX will play important parts in VDI infrastructure for years to come, but in my experience, many users have multiple roles and some machines have unique purposes which may limit the effectiveness of a single desktop pool….hospitals and education are two organizational segments that come to mind.  For example, a single nurse may work within the ICU, ER, Labor and Delivery, OR, etc. but the machines themselves in those departments are typically specialized in order to perform that department’s unique function within the hospital, thus a single desktop pool may not be the answer.

When you get a chance, watch the video (it’s about 15 minutes).  Regardless of whether or not a single pool can support your environment, it is certainly interesting to think about and consider the trends and technologies that are driving the VDI landscape and I look forward to continued innovations as we march toward VDI Utopia.

Leave a comment

Filed under Liquidware Labs, Unidesk, VDI, VMware

“You must be in the Administrators group to login” error when logging into App Volumes Manager

If using VMware App Volumes to deploy applications to your virtual desktops, you may encounter the following issue when logging into the VMware App Volumes management console:


“You must be in the Administrators group to login!?!?”  App Volumes manager worked just fine the last time I used it so naturally you’ll check the status of your App Volumes server and services, the SQL server and services and assuming you find them running, you’ll start to wonder, “What has changed?”

It may lead you to the office of the primary IT administrator(s) to ask, in a nice soft voice for sure, “What the heck did you do? Did you make any changes?”  Of course, the typical response is, “I swear I didn’t change anything….except move the VDI Admins security group to another OU….but surely that has nothing to do with this error right?”

Ordinarily moving groups across OUs is a pretty harmless process, but in this case, it does affect App Volumes.  When moving security groups, specifically those security groups configured with App Volumes permissions, the SQL table containing the DN of those groups is not updated so the logon to App Volumes manager fails.

As an example, when App Volumes was initially configured, the VDI Admins group had a DN of CN=VDI Admins,OU=Groups,DC=domain,DC=com.  If you move the VDI Admins group to a different OU to change its DN, you will receive the error shown above.

To resolve the login problem, you can:

  1. Move the VDI Admins group back to its original OU (which is what I did)
  2. Edit the SQL dbo.group_permissions table to change the DN value of the group name matching the DN in the new location

2_SQL Change

Leave a comment

Filed under VDI, VMware

Common Program Groups are Hidden when using VMware UEM

When working with VMware UEM, you may find that once you install the UEM Agent, your applications “disappear” from the Start Menu.  The applications didn’t disappear from the computer as you can still see them if you open Programs and Features, you can also browse the directory structure and launch them manually, and so you may ask yourself, “Why did installing the UEM Agent cause my Start Menu to go berzerk?”


Turns out the solution is pretty simple though it has lead some to search and search to find it.  Within UEM, there is a Hide common program groups policy, and when that policy is enabled, UEM will hide the common program groups from the Start Menu.

To disable the Hide common program groups policy:

1. Open the UEM Management Console, click the User Environment tab, expand Windows Settings, and then click Policy Settings.

2. Right-click Hide common programs groups and select Disable.


3. With the policy disabled, reboot the computer/virtual machine.  Once you log back in, you should see the common program groups



Leave a comment

Filed under VDI, VMware

The Death of Citrix Provisioning Server?

I won’t go into great detail in regards to benefits of layering technologies when deploying VDI solutions.  I will say, and perhaps this is an oversimplification, that the goal of any layering technology (such as Unidesk or VMware App Volumes) is to simplify the deployment, management, and updating of operating systems and applications that comprise a virtual desktop environment using a building block approach.

In my head, I visualize OS and application layers as Lego’s.  I think of the OS layer as that big green piece which serves as the foundation and the smaller blocks, representing the application layers, are used to build whatever my mind imagines. Though I may have a finite number of pieces, I can use those pieces in an infinite number of ways.

So, what does this have to do with Citrix Provisioning Server?

Citrix Provisioning Services (PVS), often referred to as the “secret sauce” of any XenApp/XenDesktop deployment, provides a streaming service which allows physical or virtual computers to obtain an image from the network. When using PVS, an administrator prepares a Master Target Device for imaging by installing an operating system and any required applications on that device.  A vDisk image is created from the Master target device’s hard drive and saved to the network.  The Provisioning Server(s) are then configured to stream the vDisk to configured target devices on demand, in real time.

To date, PVS has been the primary method of deploying, managing, and updating server images to ensure consistency throughout the XenApp environment.  However, going forward, will PVS continue to be the primary method used to deploy new XenApp servers and ensure consistency throughout the environment?  As good as PVS is, I’ve encountered 2 main problems in which it is used in XenApp environments:

1. Gold image sprawl

  • Even in the most basic PVS environments, organizations will inevitably have multiple master images.
    • Some applications won’t work together with others and so multiple master images need to be created to separate applications which don’t necessarily mix well.
    • Multiple images may be created to support the publishing of different versions of the same application, for example, Office 2010 and Office 2013.  Since they cannot exist on the same server/image, a new image would be needed to publish both Office 2010 and Office 2013 simultaneously.
    • In regards to the previous two bullet points, I’ve assumed an organization has chosen to simply publish applications, but what if XenApp is used to publish desktops and different departments have different applications?  I know you can get crafty and “hide” the Program Files menu as well as the C:, using application publishing the Receiver to place application shortcuts on the desktop and I have seen customers do that to avoid deploying a master image for each unique use case….but I’ve also seen others deploy separate gold images to meet the need to each department.

2. Complexity

  • Though its true PVS makes deploying and managing XenApp easier, it can be complex in its own right
    • If a customer has no previous experience with PVS, I have experienced longer learning curves when deploying and attempting to teach the technology to new administrators.  I say attempting because I realize part of the problem in “getting” PVS may be in my teaching.  Regardless, it can take some time for the “light bulb” to go off and the administrator to feel confident in using the technology.
    • Depending gold image sprawl, you may also see PVS sprawl.  If the number of gold images and/or the number of user connections increase, you’ll likely need more Provisioning Servers to do the work.

Toward the end of last year, upon thinking of an upcoming project and the number of master images I’d need to support the various application mixtures, I had the thought that my life would be much easier if I could use application layering (specifically Unidesk in this case) to deploy my XenApp servers, avoiding PVS altogether.  In fact, I went so far as to open a case with Unidesk asking if this were possible, here’s the actual question I asked Unidesk support:

I got to thinking, “Is there any way I can use Unidesk to build Citrix XenApp servers?  And once I assign the layers to these servers, can I then publish them out like I would a typical XenApp scenario?  Can I replace Provisioning Server with Unidesk?”

Maybe I don’t love PVS as much as the next guy….but I thought, “O, to eliminate PVS!  O, to avoid the complexity of multiple master images! O, to be able to deploy XenApp servers using application layering!”….that may be somewhat of an embellishment, but the thought was a good one.  I firmly believed that if I could deploy XenApp servers with layers, I could eliminate gold image sprawl and the complexity of PVS.

Well unbeknownst to me, Unidesk and VMware, through App Volumes, thought the same thing and now (or very shortly), I will be able to use both Unidesk and VMware App Volumes to deploy XenApp servers using OS and application layering! Because layering separates the OS from the applications, an organization should be able to consolidate their PVS images into a single OS template (big green Lego pad) and then use application layers (Lego blocks) to construct and customize the XenApp server based on its specific purpose or use case.

Granted, layering won’t eliminate server silos; if you need to simultaneously publish Office 2010 and 2013, you’ll still need a group of XenApp servers with an Office 2010 application layer and another group with Office 2013, but layering will eliminate the need for multiple master images to support such a scenario.  Additionally, when using layering technologies to deliver XenApp, complexity is reduced since a PVS infrastructure, and all that it entails, is no longer required.

Think of the voice of the narrator from the old Batman TV show….”Is this the end of PVS?!”  I’ll commit to doing my part but ultimately, you’ll be the one who determines the answer.

Leave a comment

Filed under Citrix, Unidesk, VDI, VMware

Installing/Restoring/Migrating vCenter and View Composer Onto a New System

The last couple of days, I have been helping a colleague restore a vCenter server that was also running View Composer. The server, for lack of a better explanation, simply “went nuts.”  Random services stopped and wouldn’t start, you could ping it and then you couldn’t, you could be working on it and then the VM would shutdown saying the REDO log is bad, if you browsed the datastore folder it was stored in you would have the impression there were a few snapshots but none were seen in Snapshot Manager….just weird!  Naturally, there was not a backup and so we contacted VMware support and though very helpful and determined, after hours of multiple people trying to restore this server to life, we had to call it so around lunchtime today, our vCenter server was declared dead.

I suppose a vCenter server dying isn’t the end of the world, but this server also ran View Composer so how could we most easily restore the connection between vCenter, Composer, and View itself.  We followed the steps below (generally speaking as some of these seem like a good idea after the fact) to restore vCenter along with View Composer:

1. Connect the vSphere client to an ESX host and begin building a new Windows VM that will become the new vCenter and while Windows is loading, perform the following:

2. Open View Administrator, expand View Configuration and select Servers.  On the vCenter Servers tab, click Disable Provisioning.


3. If not already hosed, stop all VMware vCenter services on the existing vCenter server and backup the ADAM Database. vCenter uses an ADAM (Active Directory Application Mode) database to store information related to licensing, custom roles, and Linked Mode configuration.

  • Start a command prompt as an administrator
  • Run the command dsdbutil
  • At the dsdbutil prompt, run the command activate instance VMwareVCMSDS
  • Run the command ifm
  • To backup the ADAM database, run the command create full <some empty directory>
    • In the screenshot below, my first attempt to backup failed because the target directory was not empty.
  • After the backup is successful, type quit at the ifm and dsdbutil prompts


4. If necessary, backup the vCenter and View Composer databases.  In our case, SQL Server was running on the existing vCenter server so we used SQL Management Studio to backup the vCenter and View Composer databases.  **Notate the database names, use the same names on the new vCenter server.

5. Finally, we copied the ADAM, vCenter, and View Composer database backups to a network location and shutdown the existing vCenter server.


Just as an FYI, we made sure to install the same versions of SQL, vCenter, and View Composer so check your versions and make sure you have what you need for installation.

6. Rename and Re-IP the new vCenter server to match the old reboot.  Copy down the ADAM, vCenter, and View Composer backup files.

7. Install SQL, create new databases for vCenter and View Composer (again, matching the old name), and then restore vCenter and View Composer using the backup taken in step #4.

8. Configure the Data Source (ODBC) System DSNs for vCenter and View Composer.

9. Install vCenter Server

10. Restore the ADAM database: (may be a good idea to take a snapshot of the vCenter server here)

  • Stop the following services in the order listed
    • VMware VirtualCenter Management Webservices
    • VMware VirtualCenter Server
    • VMwareVCMSDS
  • Backup the existing ADAM files in the %ProgramData%\VMware\VMware VirtualCenter\VMwareVCMSDS directory by simply copying them to an alternate location
  • Run the following command to copy the ADAM backup to the VMwareVCMSDS directory
    • xcopy /os backup_location\adamntds.dit “%ProgramData%\VMware\VMware VirtualCenter\VMwareVCMSDS” 
    • the backup location is the folder path in which the adamntds.dit was copied in #6, an example is shown below
    • xcopy /os C:\Backup\VMwareVCMSDS\adamntds.dit “c:\Program Files\VMware\Infrastructure\VirtualCenter Server\VMwareVCMSDS”
  • Start the following services in the order listed
    • VMware VirtualCenter Server
    • VMwareVCMSDS
    • VMware VirtualCenter Management Webservices

11. Install View Composer and reboot the vCenter server.

12. When the reboot completes, launch the vSphere client and reconnect to your vSphere servers.

13. Open View Administrator and on the Dashboard page, under the System Health heading, you should have red boxes for vCenter Servers and View Composer because the certificates for each are untrusted and need to be verified.

  • Expand vCenter Servers
  • click the vCenter hyperlink (https://vcenterFQDN_or_IP:443)
  • When the vCenter Server Details page appears, click Verify and then OK


14. Repeat step #13 for View Composer and both should now display green boxes.

15. Finally, test Composer by recomposing existing virtual machines or provision new ones.  Assuming the operations are successful, you have successfully restored the vCenter server and View Composer services.

Leave a comment

Filed under VDI, VMware