Aug 01, 2017 - 4 Comments - Virtual Vibes -

Using PowerShell to Self Deliver RunVirtual

In previous blog posts I have talked about various models for RunVirtual detailing how we can deliver and manage the feature in conjunction with connection groups. In this post I would like to share with you a simple script which you can include in your package delivery to provision the RunVirtual registry values. This ‘self delivery’ approach will allow you to include this script as part of a ‘connector’ package within your connection group to make integration of local to virtual even easier. I have recently worked with a handful of clients for who this script has come in handy for, most recently for a financial organisation who wanted to move away from a virtualised Office (due to a raft of various issues) and go back to having it locally installed. They however wanted to still keep their various office plugins virtualised and user targeted:

In this design the connector package is a member of the connection group, it also contains a script which queries its own GUIDs (from the manifest) which it uses to populate the RunVirtual registry keys under the local Office process names:

The Script

The simple PowerShell script below will query its own package and version GUID and populate RunVirtual keys for any processes listed in the ApplicationExes variable (pre-populated with Office exes). The script can be called with either a -Publish to populate the keys or a -Unpublish to clean up the keys. The script itself is of course sequenced into the package under the scripts folder.

Once Connector.ps1 above has been saved into the package the script can be called within the deployment or user configuration files for the publish / unpublished actions as shown:

The great thing about the approach above is it doesn’t matter if you ever happen to update the connector package, the script will always lay down the correct GUIDs, so what you end up with is a self contained ‘worker package’ that just sits inside your connection groups ready to do any necessary RunVirtual work on behalf of its other members. Feel free to use the script above and tailor it to your needs. For further reading check out this post here where I further discuss real world RunVirtual.

4 Responses to Using PowerShell to Self Deliver RunVirtual

  1. AJ

    Nice article and ps script 🙂 I’m about to make my own little tool for my own organization, doing much of the same stuff with a dummy package for runvirtual. But also going to add the possibility to choose and read all *.exe files from a certain filestructure: Like %programfiles%\program\ with our without the flag on to look trough subfolders. That way we can make it even more dynamical if needed. And also the ability to have a registry key or xml file with certain excluded exe files that won’t ever be added if we don’t remove this flag first.

    1 Aug 2017 - Reply
    • Thamim Karim

      Great, love the idea of scanning for .exe so they do not need to be hard coded.

      12 Oct 2017 - Reply
  2. MarkC

    Hi Tham, great work usual. Just wanted to get your thoughts as to whether this solution is suitable for Internet Explorer plugins or do you just tend to go with Dynamic Virtualization where possible. (One limitation being that they must be globally published which is a pain)

    6 Oct 2017 - Reply
    • Thamim Karim

      Hi Mark,

      Most implementations I have seen tend to go with dynamic virtualisation although I agree the global publishing is a pain. However there is no reason you couldn’t take iexplore.exe out of DV registry and utilise the model described above in place.

      12 Oct 2017 - Reply

Leave a Reply

Your email address will not be published. Required fields are marked *