Let’s Get Chocolatey

It’s taken a little while, but we are pleased to announce that the Virtual Engine Toolkit (VET) and the App-V Configuration Editor (ACE) are now available on Chocolatey! If you have Chocolatey installed on your systems then you can get going by running the commands listed below.

image

Microsoft Package Management

It gets even better if you’re running the Windows 10 Insider preview, the latest WMF 5.0 April 2015 preview or have installed the latest experimental OneGet build on Windows 7 and up, you can download these directly – today!

To do this, run the Install-Package ace or Install-Package vet commands, like so:

image
Other Packages

It doesn’t end here though. We have also published the following packages that you might find useful to the public Chocolatey feed:

Now – go get Chocolatey 😀

App-V 5 Configuration Editor User Guide

ACEWe’ve been working hard getting the App-V 5 Configuration Editor (ACE) ready for a BETA release; take a look at the ACE page for a bit more information about why it was developed.

With any new application it’s great to have some user guides, right (RTFM)?!? Rest assured that will come when it’s officially released, in the mean time we wanted to create this short blog to guide you through the ACE interface. There is also an assumption here you have an understanding of the App-V 5 Dynamic Configuration files and how they are used, if not you might want to take a look at this technet article.

USER INTERFACE

Main Toolbar:

You will notice there are three main buttons in the tool bar as shown below:

SNAGHTML105760e

image Opens an App-V XML file, i.e. a UserConfig.xml or DeploymentConfig.xml file. Once the file has been opened the contents will be parsed and displayed under the various tabs within the GUI.

image Saves the current App-V XML file, including any changes that have been made. You can give it a new name and Save As a different file, keeping your original one as is if necessary.

image Previews the changes that will be made to the App-V XML file before saving. This gives you the ability to check out the structure of the generated XML. It’s probably a good idea to point out here that you don’t need to preview the changes prior to performing a save.

Package Details:

This sections displays the Package Display Name, Package ID and Type of XML file opened, i.e. DeploymentConfig or UserConfig. Here is an example DeploymentConfig.xml opened below:

SNAGHTML10a6c4e

MAIN CONFIGURATION TABS

Once an App-V 5 configuration XML file has been opened you can then begin to make changes as required using the tabs set out below.

User Configuration

Under the User Configuration tab you can change and view various options and configurations:

SNAGHTML1151fa5

Options

Various global options change be changed here if you so desire, e.g. altering the COM integration mode.

Shortcuts

This tab allows you to view all the defined Shortcuts within the package.

NOTE: at this time its Read Only but is great for getting an overview of all the Shortcuts available.

SNAGHTML123eb5d

Scripts (User Context)

This is really where ACE starts to make life simple Smile. You can easily define which scripts you’d like to add and to which actions, e.g. PublishPackage, UnpublishPackage, StartVirtualEnvironment, TerminateVirtualEnvironment, StartProcess and ExitProcess. There is no need to worry about getting the syntax in the XML file right. There are are some excellent blogs out there talking about using scripts in App-V 5.0, so I suggest you take a look here at one from Tim Murgent and Microsoft’s own Steve Thompson if you need some further background information.

NOTE: You might have noticed that not all the script actions are available under this tab, that’s simply because those excluded aren’t permitted to run under the User Configuration section of the XML file.

I think most of the options are self explanatory but, it’s good to point out that leaving the Timeout value at 0 means no timeout period will be set, i.e. it will wait indefinitely for it to finish so use with caution.

SNAGHTML137e66e

Machine Configuration

Under the Machine Configuration tab you can alter global options, configure scripts and control the termination of processes.

NOTE: this tab will only be available when you open a DeploymentConfig.xml file. This is because machine configuration items cannot be set in the UserConfig.xml file.

SNAGHTML144b2d1

Options

Here you’ll find any options that can be changed if you so desire.

Terminate Child Processes

You can define the path to an executable, that when closed, will terminate any child process running within the virtual environment.

SNAGHTML14d302a

Scripts (System Context)

Very much like the Scripts tab under User Configuration you can define which scripts you’d like to add to which actions, e.g. AddPackage, RemovePackage, PublishPackage and UnpublishPackage.

NOTE: You might have noticed that not all the script actions are available under this tab, that’s simply because those excluded aren’t permitted to run under the Machine Configuration section of the XML file.

SNAGHTML1522226

XML

You can view both the source (original) XML and/or preview the generated XML under this tab.

SNAGHTML18ecc7a

Source XML

This is simply where you can view your source App-V XML file as it was when you opened it.

Generated XML

Once you click the Preview button image this pane will display any changes that will be made to the App-V XML file, giving you the ability to check out the structure of the XML before saving if you wish.

NOTE: You don’t have to preview the changes prior to performing a save.

The example below (highlighted in yellow) shows the changes made by ACE in the generated XML format.

SNAGHTML19082ed

Hopefully this brief guide has given you a good overview of how to use ACE. Hopefully you’ll agree its pretty intuitive to use and should make editing the App-V 5 Dynamic Configuration files a lot, lot easier (well we think so anyway!) 🙂

DISCLAIMER: THE APP-V CONFIGURATION EDITOR IS FREE TO USE AT YOUR OWN RISK, WE CANNOT BE HELD RESPONSIBLE FOR ANY DAMAGE IT MIGHT CAUSE.

VET v1.2 Group Policy Import Bug

This post is just a heads-up on some errors we’ve seen importing Group Policy Objects into RES Workspace Manager with the latest Virtual Engine Toolkit v1.2 release. In version v1.2 we introduced the ability to convert GPO permissions and OU links. To achieve this we needed to alter the way in which we enumerated the Group Policy Objects present within the source Active Directory domain.

VET v1.2 directly scans the SYSVOL volume (this approach has changed in VET v2.0). Unfortunately, if there is an errant folder that persists in the SYSVOL (but is no longer present in Active Directory) this error is not correctly trapped. The net result is a spectacular .NET exception error!

Internally we have code that fixes this issue, but it’ll be a few days before @nathan_sperry has digitally signed the new executable and built a new MSI installer. When this update is available, you will receive an update notification informing you that there’s an update available.

SNAGHTML2c21ba

In the meantime, if you receive a crash when importing GPOs, you’ll need to track down the errant policy folder and either delete the redundant GPO folder or remove the \USER\registry.pol or \MACHINE\registry.pol file.

Whilst the VET v1.3 is primarily a bug fix we are introducing something completely new, e.g. it’s nothing to do with VET, PuU, JET or JETCMD. It’s something we have been using internally and at customers for a long time. Stay tuned for more information…

RES Workspace Manager – JETCMD Example Use Case

We recently announced the release of our new free Job Execution Tool (JET). If you haven’t had chance to read the announcement yet you can find it here. In this post, I’m going to detail one of the various use cases for JETCMD. This should give you an idea why we developed it in the first place and how powerful it can be.

My use case is going to focus around using JETCMD in conjunction with RES Workspace Manager to invoke a RES Automation Manager job at logoff time. The purposes of this job is to delete the locally cached user’s profile from the machine which the user has just logged off from. With the constant debate raging on whether we should be using mandatory or local (temporary) profiles, we now have a way of deleting local profiles at log off without fudging HKLM settings in the registry (perhaps another blog post?!). Regardless of how or why we should or shouldn’t be doing this, your immediate reaction at this point might be that RES Workspace Manager already integrates with RES Automation Manager! You would be correct, however we have the following restrictions:

  1. The integration only allows job scheduling at user login or when launching a managed application; not at logoff ;
  2. Run Books can’t be invoked – only Projects and Modules;
  3. You cannot dynamically pass job parameters at runtime, i.e. they are embedded into the Automation Task in RES Workspace Manager.

So how can JETCMD help us? As you’ve probably guessed JETCMD will allow us to both invoke the appropriate RES Automation Manager job at log off and pass the required parameter(s) to delete the relevant profile. The following are the outline steps involved to accomplish this task:

  1. Create a Module, Project or Run Book in the RES Automation Manager console that will be invoked by JETCMD (making note of the job GUID);
  2. As JETCMD is part of the free Virtual Engine Toolkit (VET) you’ll need to download from here and install it;
  3. Add the JETCMD.exe as a “Custom Resource” within RES Workspace Manager. Note: JETCMD.EXE can found in the “%ProgramFiles%\Virtual Engine\JETCMD” or “%ProgramFiles(x86)%\Virtual Engine\JETCMD”, depending whether it was installed on a 32 or 64-bit system;
  4. Optionally create “Environment Variables” within RES Workspace Manager, which will hold various command line parameters to pass to JETCMD such as TYPE, JOBGUID, USER and PASSWORD. Using this method makes the task you create in RES Workspace Manager extremely powerful and flexible;
  5. Create the “Execute Command” in RES Workspace Manager that runs JETCMD at logoff. Ultimately this will invoke and schedule the target RES Automation Manager job.

Now lets cover each step in slightly more detail:

STEP 1

I’m not going to cover how you create a Module, Project or Run Book in the RES Automation Manager console in detail. Rather, I am assuming that you have already created one that you would like to be invoked by JETCMD (and have noted down the relevant job GUID!). For the sake of my use case, I’m using a great tool called DelProf2 from Helge Klein (@HelgeKlein) within a RES Automation Manager module. I’ve used the following “Command (Execute)” task.

image

What you see above might look a little cryptic so I’ll briefly explain:

  1. The $Workspace{E2EBA027-FA6B-42AB-9358-C7656E99822E} reference is just a resource link that points to the DELPROF2.EXE that has been added as a resource within the RES Automation Manager console. When the RES Automation Manager task executes it will download the executable and run it;
  2. The /U switch will be passed to DELPROF2 and signifies that we would like it to run unattended, i.e. with no confirmation;
  3. To only delete a particular user profile, the /id switch is used to include only profile directories whose name matches this pattern;
  4. Used in conjunction with the /id switch, the $[UserName] is the RES Automation Manager parameter used to hold the user’s name of the profile I wish to delete (refer to JET_PARAMNAME in Step 5 for more details).

STEP 2

Nothing really to explain here other than download and install VET on your machine – simples! Smile.

STEP 3

Before we carry on with this step lets quickly describe what a “Custom Resource” is. This is an abstract from the RES Workspace Manager Administration Guide:

image

To import JETCMD as a custom resource, just follow these steps:

  1. In the RES Workspace Manager console, click on “Administration” in the navigation pane;
  2. Click on the “Custom Resources” node in the same left hand pane;
  3. Right click in the right hand pane, select “New” and browse to the location of the JETCMD.exe;
  4. The JETCMD.exe should now appear as a “Custom Resource” in the RES Workspace Manager console as shown below: image

STEP 4

Now while I did say this step was optional, I would highly recommend using “Environment Variables” to hold the parameters that JETCMD will use. This allows more visibility of these values and the potential to change them dynamically depending in the ACL’s used behind the “Environment Variables“. For example, utilising environment variables will allow you change the target RES Automation Manager job based on location or security group without having to create additional tasks!

  1. In the RES Workspace Manager console, click on “Composition” in the navigation pane;
  2. Click on the “Environment Variables” node in the same left hand pane;
  3. Right click in the right hand pane, select “New”;image
  4. Give the “Environment Variable” a suitable Name, Administrative Note and Value and change the ACLs etc. accordingly. In my instance I’ll accept the defaults;image
  5. I’m going to create 6 “Environment Variables” to make managing my “Execute Command” as simple and flexible as possible, as you can see below;image
  • JET_TYPE = RES Automation Job type to invoke i.e. Module, Project or RunBook;
  • JET_JOBGUID = The Module, Project or Run Book GUID that can be found in RES Automation Manager console;
  • JET_RESAMUSER = The RES Automation Manager console user to authenticate as;
  • JET_RESAMPWD = The password for the user as specified in JET_RESAMUSER;
  • JET_PARAMNAME = Parameter name(s) that’s specified with the RES Automation Manager job;
  • JET_PARAMVALUE = Parameter value(s) that’s used in-conjunction with JET_PARAMNAME (Refer to $[UserName] in Step 1).

STEP 5

The last step involves creating an “Execute Command” in the RES Workspace Manager console that will be executed upon logoff time.

  1. In the RES Workspace Manager console, click on “Composition” from the left hand pane;
  2. Click on the “Execute Command” node in the same left hand pane;
  3. Right click in the right hand pane, select “New”;image
  4. Adjust the “Execute Command” options so “Run Hidden” and “Run Task At Logoff” are selected as shown below:image
  5. The next most import factor here is obviously the command line specified. As I’m using “Environment Variables” my command line looks like this.
    %RESCUSTOMRESOURCES%\JETCMD.EXE /type:%JET_TYPE% /jobguid:%JET_JOBGUID% /agent:LOCAL /user:%JET_RESAMUSER% /password:%JET_RESAMPWD% /encrypted /paramname:%JET_PARAMNAME% /paramvalue:%JET_PARAMVALUE%

    You’ll notice I’m also using the %RESCUSTOMRESOURCES%Environment variable” – which is used internally by RES Workspace Manager to resolve the location of the “Custom Resources” folder.

And there you have it, a common use case for JETCMD with RES Workspace Manager. I hope by now you can see how flexible and powerful JETCMD can be Smile.

We’d love to hear you comments!!.

Nathan.

VET v1.2 Released!

Virtual Engine are pleased to announce the general availability of version 1.2 of the Virtual Engine Toolkit (VET). The latest Windows installer and documentation is available for download now on the Virtual Engine web site.

We’ve put together a series of short videos demonstrating each new feature. In the “What’s New” video series we cover the following features:

  • Job Execution Tool (including JETCMD and JETPWD);
  • Migrating Group Policy Security Permissions (VET);
  • Group Policy Objects Wizard Search (VET);
  • Group Policy Migration Report (VET);
  • Enabling the Aero theme (PuU);
  • Importing International Settings (PuU).

For more videos on the Virtual Engine Toolkit, please check out our YouTube channel.

VET v1.1 Released!

Virtual Engine are pleased to announce the general availability of version 1.1 of the Virtual Engine Toolkit (VET). The latest Windows installer and documentation is available for download now on the Virtual Engine web site.

We’ve put together a short overview video demonstrating each new feature. In the “What’s New” video we cover the following features:

  • Conversion of Group Policy Objects to RES Workspace Manager building blocks;
  • Conversion of Active Directory published printers and site definitions to RES Workspace Manager building blocks;
  • Direct import into the RES Workspace Manager console;
  • Multiple profile updates with the Profile Update Utility (PuU);
  • Ad-hoc registry changes in the Profile Update Utility (PuU).

For more videos on the Virtual Engine Toolkit, please check out our YouTube channel.

What’s New in VET v1.1

With the public release of the Virtual Engine Toolkit (VET) v1.1 just around the corner, we’ve put together a short overview video demonstrating each new feature. In the “What’s New” video we cover the following features:

  • Conversion of Group Policy Objects to RES Workspace Manager building blocks;
  • Conversion of Active Directory published printers and site definitions to RES Workspace Manager building blocks;
  • Direct import into the RES Workspace Manager console;
  • Multiple profile updates with the Profile Update Utility (PuU);
  • Ad-hoc registry changes in the Profile Update Utility (PuU).

For more videos on the Virtual Engine Toolkit, please check out our YouTube channel here.

Archives

Categories