Good stuff on customizing Citrix StoreFront 3.x…handy references when wanting to add some spice to your StoreFront implementations:
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.
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:
- Move the VDI Admins group back to its original OU (which is what I did)
- Edit the SQL dbo.group_permissions table to change the DN value of the group name matching the DN in the new location
When running some P2Vs recently using the VMware vCenter Converter Standalone client (version 5.5.3) and was surprised to encounter extremely slow transfer rates….like 206 KB/s slow! The physical machines were several buildings away from the central datacenter so I expected some slowness but not this as these servers were really quite bland in their use case and utilization.
According to VMware Article ID 2020517, VMware vCenter Converter Standalone 5.x default the converter worker encrypts the data stream using SSL. Encrypting the traffic increases security, but it can decrease performance.
To disable the encryption of the P2V data stream:
1.Browse to C:\ProgramData\VMware\VMware vCenter Converter Standalone
2. Open the converter-worker.xml file using a text editor (I used Notepad)
3. Locate the <useSsl></useSsl> tag under the <nfc> heading. By default it has a value of true.
4. Change the value to false as shown below and then save and close the file.
5. Restart the VMware vCenter Converter Standalone Worker service on the machine.
6. Execute the P2V
In my case, the P2Vs jumped from 206 KB/s to roughly 4 MB/s which was fine given the physical topology of the environment and the fact that I wasn’t in any particular hurry or time crunch (I had about a 36 hr. window) to get the P2V completed.
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