From the Skunkworks Dept. As we are approaching the release of Workspace Manager 2012 later this year, here's a sneakpeek into the goodiebag of good things to come. Specifically I've taken the RES Relay Server for a spin and kicked the tires in the lab, in order to give you a better understanding of what this thing is. This technote article should hopefully help you gain a better understanding on what new options we will have at our disposal for designing tomorrows workspace solutions.

<<< Click here to read the article

While we're at it, I've updated an old article RG004 – Workspace Manager commandline parameters, so it reflects the new parameters to unattended configure a Relay Server connection for a Workspace Manager 2012 agent. Click here to see the updates.

From the TechNote Dept: A new article by Patrick Kaak has been posted in the TechLibrary. This time around Patrick shows us the advantages of incorporating existing scripts into RES Automation Manager, illustrating by example how an otherwise semi-static script can be converted into a reusable runbook, which requires no editing what so ever. The example at hand utilizes Thomas Koetzing’s excellent Citrix Hotfix downloader script. By embedding it into an AM runbook you don’t have to ever edit it again. As usual for your convenience, an example buildingblock is included

<<< Click here to read the article

From the RES Community Hero Dept. Today I’d like to introduce a new blog site, which one of my good colleagues, Musa Cakar from RES Support has launched. The blog is called My Virtual Environment, or MYVE.nl. His first article is very useful, as it deals with reducing the size of Mozilla Firefox profiles, using the RES Workspace Manager. Be sure to check out the article here!

From the Technotes-R-Us Dept. With the Automation Manager 2012 currently available as RC2, a RESguru article describing the nuts, bolts and registry settings of the new Dispatcher+ has been overdue for a while. To the rescue comes Rob Aarts with a great article, which explains the ins and outs of the new dispatcher component. Also covered in the article is the Master Dispatcher/Cache feature. The most important registry settings to tweak the behavior of the Dispatcher are also covered. Finally the article also covers the new WebAPI for Automation Manager.

<<< Click here to read the article!

‘Twas a month before Xmas and through the hotel, nothing was stirring… well maybe, except for the 450+ geeks and guru’s who assembled at the Hilton Universal City, Los Angeles for the first major Citrix Technology Exchange event on Dec 2nd 2012. RES Software had been invited as a platinum sponsor of the event. Besides showing our products at the vendor’s tables, we also had a couple of presentation slots. I want to take a moment to specially thank my friend Rick Eilenberger at Citrix for putting this great event together. Be sure to check out his follow-up article here.

During one of the RES Software presentations, I had the pleasure of once again demonstrating the unparalleled awesomeness of the RES Automation Manager. This time I had the good Mr. Luca Lo Castro with me on stage, as he is indeed the evil mastermind behind this latest creation. What we have here is nothing less than one of the most awesome Run Books created for RES Automation Manager yet. The Runbook does the following:

• Unattended installation of Citrix Provisioning Server 6.0 (PVS)
• Unattended installation of Citrix XenApp 6.5 (XA)
• Unattended installation of Xen Desktop 5.5 (XD)
• Preparation of a Windows 7 image (application of best practices, per Citrix’s recommendations.

This is quite valuable for anyone who installs these products for a living, no matter if you are a consultant, a Citrix SE or perhaps a Citrix admin at a large installation. The cool part is that ALL of the above is done in less than 45 minutes! Add that to the approx. 15 minutes it takes to stand up the RES Automation Manager infrastructure, and ask yourself this: How long does it take you to stand up a XenDesktop + PVS + XA environment under normal circumstances? I trust you see my point. So what are the prerequisites for all this? You’ll need the following:

• Your 3 .ISO files, respectively for PVS, XA and XD. If you haven’t got them, download them from MyCitrix.com
• A server (200x, doesn’t really matter), which will hold your DBMS for Automation Manager and be a mount point for your ISO’s. Let’s call it Server1. If you can run a compatible datastore for Automation Manager, this could be your laptop!
• Mount the ISO’s on this server using Daemon Tools or similar. Alternatively, if you are using a VM, you can just mount the ISO’s directly on the virtual machine as DVD drives. Finally if you already have the ISO’s extracted somewhere, you can just share those folders. Either way, make sure you share the individual mount folders, so the contents of each ISO is available as a \\server1\share UNC path.
• You will also need 3 blank x64 Server 2008R2 servers. And I do mean blank. For example, not manually install the .Net 4 client profile ahead, as it will mess up the unattended installation of SQL Express. These servers will be the target servers for PVS, XA and XD. Lets call these machines Server A, B and C
• Finally you’ll need a blank Windows 7 machine. This is the machine which will be prepped for use with PVS (registry hacks applied, services configured etc) as the golden image.

To get things stood up, here are some guidelines to get you started:

1. Download and install the RES Automation Manager aka AM. Refer to the Getting Started guide.
2. Deploy the AM Dispatcher to Server1
3. Deploy the AM Agents to the 3 blanks Servers A..C
4. Import the buildingblock, which you will find at the end of this article.
5. In the AM console, go to Repository | Run Books
6. Rightclick on the Citrix POC-Sales runbook and select Schedule Job
7. Fill out the parameters for the runbook as described below
8. Hit OK, then hit the local Starbucks.. :)

The parameter screen needs a bit of explanation, because if you don’t fill things in right, then of course “interesting” things may happen. You know the drill: BS in, BS out. So let’s have a look at a screen I’ve already filled out below. Click to enlarge:

 The table below explains each field and what you need to enter. There’s a couple of blank spots, but as soon as I get them validated by Luca I’ll be sure to update the posting.

Those of you who are savy with Automation Manager may wonder why that AM resources aren’t utilized for this RunBook. The reason is twofold: First of all, you don’t wan’t to be waiting to upload the close to 8GB of the 3 ISO’s together to the datastore. Not that it can’t handle it, but think about that you would have to do that every time there is a new .ISO. it would make things really cumbersome. Second, by not using a linked resource we preserve the flexibility of the runbook, without having to modify it, i.e. we don’t need to edit any resource every time we go to a new place where we want to use the Run Book.

I guess at this point you want to have a go at the RunBook, so just click on the Christmas present on the right to download:

Enjoy!

Note: If you have problems with getting the runbook to work, again: Make sure the 2008 servers are blank. If still no luck, post your results in the forum, so we can get some eyes on it. The buildingblock is provided as-is. It’s not something that has been provided officially in the context of RES or RES Support.

From the So-Ein-Ding-Muss-Ich-Auch-Haben Department. Here the other day I came across a nice article by Michel Stevelmans, where he’s taken the time to dig out some really useful explorer registry keys. These are the settings one needs to pick up from the users registry in order to serve up a consistent desktop experience, when moving across a computing estate. While the article was written with a competing vendor in mind, I have the luxury of really not having to care about that. This article will show you how to to put this knowledge into practice with RES Workspace Manager – and yes, you guessed it: BuildingBlock Included!

<<< Click here to read the full article

From the Technotes-R-Us Dept. Ever wondered how to create nice uniform HTML signatures for your entire company, then to discover there’s someone that needs a different one. Fast forward 6 months you’re faced with having 5 or 6 different email signature templates for Outlook to juggle. If you want a sleek method of dealing with all that, you want to check out this article from resident co-Guru, Sascha Maier. Here you’ll learn how to not only embed different bitmaps into the signature according to group membership, but also how to distribute those bitmaps using RES Workspace Manager’s Custom Resource feature.

<<< Click here to read the article.

PS: This is our 60th article, w00t!

From the Technotes-R-Us Dept. A new article has been published in the Technote library by resident co-author Mr. Patrik Kaak. This time he takes us through how you troubleshoot if you have large User Settings files in Workspace Manager. This article illustrates how to figure out what’s actually being stored inside of these files.

<<< Click here to read the article.

From the Interesting Tidbits Dept. Here’s probably the shortest RESguru posting to date, but it’s been a little thing that has been itching to be posted for a while. In all it’s simplicity it’s about how you would reference an empty string in either Automation Manager or Workspace Manager. Since there isn’t a NULL operator per say, we have to rely on our old friend, Mr. PatternMatching. In other words for the uninitiated, RES products supports a pletora of wildcard operators within the text input fields of the products. You can also use variables and functions here. Also check out the RESpedia entry on patternmaching.

The use-cases are many, as you might need to check on environment variables, registry settings, AD properties, file versions or something completely different. Here is a quite simple one: Let’s say we want to check if a variable is set or not. All we have to do is use the pattern “?*” without the quotation marks. The questionmark determines that a single any-character must be present, and the asterisk says that any number of characters including none, may follow. Here on the right is a screenshot which illustrates the usage. PS: Thanks to Dave Bryant for sharing this nugget.

This article stems from that the fact that I’ve been asked several times the same question: “So, I’m looking to do VDI, and I want to use non-persistent / perishable images – but at the same time I want to allow my users to install their own apps. Can you software support that?”. That is what I’m going to address in this article.

For those of you wondering, this article had initially absolutely nothing to do with the whole Citrix/Ringcube thing, as I started writing a month prior to the press release last week. However since it’s a now a reality, it needs to be factored in. I now get questions like; “So, the RingCube/Citrix acuquisition – how does it affect RES?“. The short and precise answer is:

Not At All.

If I was in the business of, oh say… User Virtualization, perhaps I would have reason to worry, however neither layering nor virtualization has ever been in RES Software’s technology sphere. Seen from the point of the RES Workspace Manager, the RingCube offering is just another carrier platform, into which we can inject dynamic settings and manage security on top. Another thing to be aware of: Security around a layered environment is still very relevant to be managed as I presume that certain applications, such as games, torrent clients and other non-business apps aren’t wanted there either. The RES Workspace Manager can control what you are allowed to install, on a very granular level. I will explain this further into this article…

Let’s start with the basics: If you’re still not too familiar with VDI terminology, let’s get a few things straight first: A pure non-persistent, stateless or perishable image is essentially this: You connect to the data center and you get issued a workstation OS. The instance you get access to is a copy of a master image of a workstation, which has been created by the administrator or provider. You can usually make whatever changes to your machine as you want, but when you log out, the entire machine gets hosed and everything snaps back to default when you log in again because you get a fresh copy. Essentially the entire virtual machine acts like a Mandatory Profile. The only things that will get preserved are the items which are saved off to places outside of the virtual machine, being either network drives or perhaps redirected profile folders.

So, you want to allow users to be able to install their own software on top of that? I would argue that this would defeat the entire purpose of having a non-persistent image in the first place. It just doesn’t make sense! Now, before you get on your virtual high horse and yell Bloody Murder, hang on just a minute! Let’s try and break this issue down to its actual components. After that we’ll have look at what solutions are available to address this conundrum. Remember there’s no one shoe that fits all. The same holds true for virtual image types and solutions.

User base: To begin with, let’s look at your user base. If you’re a software development company and you are offering a virtual development/testing environment, it is more than likely that the software engineers will have the requirement to be able to install additional software. While VDI may offer a great solution to centralizing the development environment, enforcing non-persistent images in that type of environment would likely make your day go from better to bad to worse. On the other hand, if you are XYZ Rental Car Inc, there is a high probability that 99.9% of your users do not need the capability to install software, as they are effectively task-based workers. They would only need access to a very select set of applications and that’s it.

Standardization: If you want to standardize, the biggest mistake you can make is to set the bar after the needs of the few. Don’t try to shoehorn all users into one single type of image (persistent or non-persistent) if your user topology doesn’t lend itself to it. To make sure, look at the actual needs of the vast majority of your user population before you decide what should go into your master image. If you have no clue where and how to obtain this overview, may I humbly suggest the free RES Baseline Desktop Analyzer service, which can give you a marvelous overview of the environment as it is today – before you set out to do anything!

Consolidation: Having spoken to the potential requirement of having multiple images, I want to clarify something here. We may very well have a situation on our hands where we want to give some users a persistent image, while the rest can do fine with a non-persistent. For more details see the Connection Brokering section further below. You can divide applications into two groups: Those which are going to be delivered by the organization/datacenter (at RES we refer to those as Managed Applications) and those apps which are not. These particular apps we refer to as User Installed applications. As far as Managed Apps go, I still to this day see people who attempt to use image separation to restrict users from certain apps, resulting easily in 50+ image templates, which are in fact just collections/groups of corporate applications. This is a horrible non-scaling and quite inefficient way to manage a VDI environment, especially when you as an alternative could use the RES Workspace Manager to expose only the apps which the current user has access to. This effectively means you can consolidate all the access-based images into one big fat image, having hundreds of apps in the image. If however a given user only has access to 5 of these apps, then that’s all that user will ever be able to see or access by any means, even though there are many more apps on the computer. The user will never know about these other apps, and even if he does, there’s not a snowballs chance in hell that he can access them.

Application Virtualization: To further increase the number of applications which can be running inside any given image, it pays to look into Application Virtualization. Which ever platform; App-V, Streaming Server, ThinApp, etc. is your favorite platform is quite inconsequential. There are two main things to keep in mind here: 1) As long as the application virtualization engine you chose can separate conflicting apps (multiple versions of DLL files’ etc), it can help you get more apps into the standard corporate image, thus further reducing the potential need for users to install their own stuff. 2) The other thing to remember is that all the major app virtualization platforms are supported by RES Software. Some of the government entities we have worked with over the years had in excess of 1.700 apps. In such cases, Application virtualization was most definitely the weapon of choice. We will circle back to Application Virtualization further ahead in this article, as it will come in handy for other purposes.

User Installed Applications: Managed applications aside, let’s look at the implications of a user installing an application. Again, there are two extremes and any number of combo’s in between them. In the low-impact end of the scale you may have small utilities and browser plugins. In the other end of the scale, it could be pretty much anything. For all you know the users in the high end of the application scale could be installing a copy of Visio or Office 20xx. Last time I looked a full Visio is 1.5GB So enter a another vendor who for ages would have been claiming something like; “Sure mate! We can soon do follow-me applications!” Before jumping on that bandwagon, the question you really want to ask yourself is this: If my users will be installing software, thereby potentially generating a payload of several Gigs, AND I want to use non-persistent images – That chunk of data has to be stored someplace, right? Additionally, said payload has to be delivered back into the user’s session each and every time the user gets a new non-persistent virtual machine. Make sure you think over really hard how that’s going to impact your infrastructure.

Connection brokering: Another thing you may want to factor in is the VDI brokering itself. With most VDI environments you can mix and match images according to the identity of the user. It should pose little challenge to configure your VDI brokering so when, say the sales people log in, they get a non-persistent image from the main pool 1. Then you’ll have the odd [often techsavy] ducks in the row, those few that you thought could do with a non-persistent image. However as it turns out, they actually have the need to install applications. 9 times out of 10 you could probably solve it then and there by quite simply having a smaller pool 2 of persistent-image virtual machines earmarked just for those specific users. Job done. From then on, when one of these users logs in, he’ll get his/her personal virtual machine, with all the junk previously installed. Junk you say, Max? So what if the user installs something that screws up his virtual machine, then what? Piece of cake – that’s what you’ve got your snapshots for!

Layering: Now that RingCube is to be part of the Citrix XenDesktop offering, its also necessary to look at how that fits in to the big picture. It seems likely that the Layering approach could very well grow into the solution we’ve all been looking for to contain all the changes the user does, including installing apps. As I understand it, it’s similar to good old Parallelis’s Virtuozzo, but for workstations, you could think of it conceptually as an App-V bubble for the OS. I know, I know – that’s not entirely accurate, but it kinda gives an idea how it fits in. I used the Ringcube’s MojoPack for years and it was a very cool solution, basically a complete PC with apps on a USB stick. But before we all jump into the frenzy of celebrating a new tool in the belt, let’s take a couple of deep breaths in a paper bag and consider the realities: 

• Regardless of carrier technology (pure vm, layer, app-virtualization bubble, etc) there is still data to be moved. As mentioned before, if you install a 1.5GB full installation of Viso, that is still around 1.5 GB sitting on a layer, that needs to move through the infrastructure to follow you. Make sure you understand the impact of this.
• Be sure you understand fully the extents of where it can follow you. Layering differs from classic type 1+2 hypervisors by allowing see-through to the filesystem of the underlying operating system and hardware. That means that apps which bind themselves to hardware (DRM, licensing) may not be as portable as you would initially think.

Nevertheless, layering is a very nice technology which may offer you some middleground between offering a persistent, and non persistent image. Just don’t go overboard and think it will be applicable to all apps for everyone everywhere. I’ve said it before: No shoe fits all. Layering is no exception.

In summary: You will do well if you utilize the base capabilities of your VDI environment to it’s maximum extent, without jumping 100% head first into the let’s-all-run-to-the-store-and-get-non-persistent-images kool-aid. Let me just make this clear: It’s useful, but do try to think of non-persistent VDI images as you would think of mandatory profiles: While they certainly serve a purpose, they aren’t for everyone. If you can get away with giving the vast majority of your users a non-persistent image, you’re in great shape. Leave the option open for employing a persistent personal image when nothing else applies, in order to keep the disk usage reasonable.

The opposing view.

An often heard argument against using 1:1 persistent images on some users, goes something like this: “Well, I’m only expecting my users to install browser plugins and such, and I want to give that possibility to every user. It sounds like overkill to me to have to store a persistent image for every user?” First of all, I couldn’t agree more. Second, I would whack you over the head with a rolled up magazine for not paying attention. There! Got your attention now, didn’t I? :) I said you should differentiate your users. Second, the dangerous keyphrase in the sentence above is “…and such…” as that’s equivalent to giving yourself a semantic wildcard! So once more, let’s recap: If your all your users will be installing all kinds of software, non-persistent VDI images, is definitely NOT the way forward. Give those particular users a persistent VM or consider a layering technology if it applies to your specific technology stack.

For the sake of argument, let’s however go with the core intent of the requirement above; browser plugins. These are typically rather small in nature, so using a bit of trickery you could actually get away with those in a non-persistent environment using readily available technology. Before we proceed, let’s not forget to factor in the following items:

• Baseline set of plugins: What plugins do you think your users need beyond flash, Adobe reader, Google Earth, and such? If you took the time to survey this (sorry, the BDA doesn’t currently support browser plugins at the time of writing, Jul 2011), you may very well find that a large group of users actually use pretty much the same standard plugins. By baking in the most commonly used plugins you can further reduce the resulting payload. The question you need to ask yourself here is: What plugins should I bake into the image per default?
• Security: We all know that there are plenty of toolbars and other IE plugins we really don’t want in our environment, and having them run in the datacenter on a virtual machine doesn’t make it any better. To rub salt in the wound, every company has the type of user who will install everything that he can click on. You can bank on that a large percentage of regular computer users will take the bait if there’s a blinking banner that says “You’re the 1.000.000.000th visitor – Click here to win a fantazillion dollars, just install our little [sneaky spyware] toolbar”. The question you need to ask yourself here is: How do I limit what the users can install?

The solutions:

Okay, so maybe even after all my preaching and rants so far, you’re still hell-bent on going full steam ahead using non-persistent images across the board. Let’s look at some solutions on how you can overcome or at least address some of the issues discussed above. Rather than bolting out the door with your checkbook in hand, there are real alternatives to how you can provide follow-me capability specifically for browser plugins. However, I do have to warn you – it may not be as slick as you’d hope for. That’s why as I mentioned in the intro, RES doesn’t engage in follow-me apps or virtualization in the first place. There are plenty of those fish in the pond already. Second, there is no sense for developing something, if the cards are stacked up against us from the beginning and it can’t be made to work flawlessly with ALL types of applications on ALL windows platforms. I guess that answers the initial question of this article: Does RES products provide a generic solution to let application installs follow the user? The answer to that is no, unless the app is installed 100% into a user’s profile, which in many cases isn’t a real option anyway, due to the previously mentioned payload size.

Browser plugins.

Let’s take an overall look at those darn browser plugins then. Google Chrome is actually the only browser which installs 100% into a user’s profile. While this may work from a Follow-Me perspective, this makes Chrome hell on wheels to install unattended from a central deployment point of view as there is currently still no option for alternative install paths. Since RES Workspace Manager’s Zero Profile technology can grab the contents of any part of the %userprofile% path and HKCU, Chrome plugins are a no-brainer in this respect. Internet Explorer plugins on the other hand reside in the %windir%\downloaded program files folder. As far as I know this path can’t be changed either. Mozilla Firefox per default saves its plugins underneath the installation folder. However in the case of FireFox the plugin folder can be moved.

So to boil things further down, your success rate of natively implementing a browser with follow-me plugins, depends a lot on the make and architechture of the browser. There is however another and completely browser-agnostic alternative to all this nonsense. It will still result in a payload being carried around with you, but at least you can contain it safely. The idea is quite simply to use Application Virtualization to encapsulate the browser. Now, this isn’t a catch-all solution as it will not help you with completely new apps that the users would download and install. Browser plugins are however a different animal, as they are extensions to an existing app.

The basic idea here is simply to pre-sequence the browser in question. Again this is mostly only relevant for IE as it’s the only browser where the plugin path is still hardcoded to outside the user’s profile. When executed insider a virtual bubble, all changes and add-on’s are then stored in the virtual bubble for the app. The contents of the bubble itself is stored in the user’s profile, and can then be cargo-lifted out by your favorite multitool, the RES Workspace Manager. There are 3-4 major players in this space including Microsoft App-V (formerly known as SoftGrid, VMware’s ThinApp, Citrix Streaming server, etc). The RES Workspace Manager supports them all. For this example I will use MS App-V as it’s the grand daddy of all the App-Virtualization vendors (yes, Softricity were the first ones to do it back in the late 90′s!) Second, since I happen to be a former instructor on App-V, I better stick to what I know something about.

Before we continue, please be aware that the method below is NOT supported by Microsoft. It does still work though. The method to App-V sequence Internet Explorer is a bit different than from any other browser, due to the fact that it’s already installed in the OS. The procedure is as follows. Note, this is not an exhaustive tutorial to teach you how to Sequence with App-V. If you’re new to App-V, you’re probably better off consulting the experts here. If you on the other hand know what you’re doing in a App-V Sequencer, this is what to do:

1. Fire up your Sequencer and create a new package. Call it Virtual IE or something appropriate.
2. Using the packaging wizard, create a new folder on the Q: drive. Call it IEx.V1 for example
3. While in the Installation wizard (recording mode), copy cmd.exe to this folder. This copy step may not be strictly necessary, but it helps create a generic empty bubble, which you can use for other purposes. Having an empty bubble-app with a command prompt inside could come in handy another day.
4. Create a shortcut for the Commandprompt.
5. Run through the rest of the sequencer wizard and save the package (don’t save as an MSI package)
6. Once saved, open up the .OSD file with notepad.
7. Edit the FILENAME= tag (which will be pointing to CMD.EXE. Change the path and filename to %programfiles%\internet explorer\iexplorer.exe
8. Save exit and launch the .OSD file as you normally would

For testing purposes, you can manually create a desktop shortcut using the App-V client. In the above example, The ability of App-V to execute a locally installed executable inside a virtual bubble is utilized, so everything it changes (including plugin installs) is saved. Per default the App-V client stores the changes to the virtual application in the user’s appdata folder. You can redirect this path to somewhere else, but we don’t need to in this example. This is the point where I’d bring in the RES Workspace Manager again, as you can import the .OSD file directly into the Workspace Manager console and create a managed application from it. That should take care of the browser-installed IE plugins.

Mastering installation security

Where as browser plugins can be a royal pain to manage in terms of security – as it’s pretty much all or nothing – fortunately it doesn’t have to be the case with real application setups, such as setup.exe based installers and MSI’s. Let’s just remind ourselves that we probably only want to grant the capability to install software to users who have been assigned their own personal and persistent VDI image or have some sort of Layering technology installed. So how do we control what goes in the box? Enter the RES Workspace Manager’s User Installed Application feature. This is exactly what the doctor ordered, as it can restrict installation of software based on the following items:

• Do you wish to deny or allow a specific piece of software?
• Who is the publisher of the software? (i.e. only allow software from an approved list of vendors)
• What is the product name? (use for example to exclude known, non-desired software)
• What is the version of the software being installed? (prevent obsolete or perhaps untested beta software from being installed)
• Who are you? (the user, that is)
• What machine(s) are you (the user) allowed to install software on?
• What (optional) workspace container is the computer in, which you wish to install software on?
• What is the hardware specifics on this machine? (memory, screen resolution, etc – anything you can test on using Zone rules)

The above Workspace Manager filters can be mixed and matched to your hearts content. The only snafu you have to take into account, is that either a Zone or a Workspace Container must be specified for this feature to work. In other words it doesn’t make sense to allow installation if you don’t specify where it’s allowed. You would typically here specify a list of the persistent VDI’s either lobbed into a Workspace Container or specified by a zone rule. Finally there is the issue of permissions we need to look at:

Ensuring compatibility by process elevation.

The last piece of the puzzle is ensuring compatibility, as many application installers require the equivalent of local admin access when installing software. A typical example of this is MSIexec.exe which has to be invoked by a local admin. Fortunately the Workspace Manager includes provision for this. Quite simply by checking the box Run installation using Dynamic Privileges, when defining an allowed application, will take care of it. This feature is also available for regular WM Managed Applications. You will find it under the applications properties, below the Security tab

The grand conclusion

With this article, I hope to have illustrated the rationale of using the right type of VDI image for the right user type. That was what I originally set out to do, but then this whole RingCube thing came along and I had to take that into the equation. Anyway, armed with the tools and knowledge described here, you should be able to bridge the gap in those few special cases where you need to be able to install and retain plugins. As for allowing what software goes into the system, there is always an inherent risk of opening up the proverbial can of worms. This is the case no matter what the carrier platform for the user installed objects are, if it’s a layering technology or something else new. With the control elements that the RES Workspace Manager introduces, this risk is now very manageable.