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…

Virtual Engine Receives RES Recognition

Virtual Engine are honoured to have been highlighted by RES Software in their 5 year milestone of the RES Software Valued Professional programme. Having two RSVP members is in itself a privilege, but to have received recognition for our efforts with the Virtual Engine Toolkit is also important to us.

Needless to say we are already working on the next major version of VET which incorporates a complete overhaul of the user interface. Thank you to Bob de K and the RES team for publically recognising the time and effort we contribute to the community.

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.

Updating Mandatory Profiles Part 2

Having seen that our original Updating Mandatory Profiles post is quite popular, I thought I’d follow it up with an update. The process described in the first post is quite labourious and error prone. I’d like to make people aware of how quick and easy the Profile Update Utility (PuU) makes updating a mandatory profile with ActiveSetup keys.

Here’s the new process:

  1. Obviously you’ll need to have downloaded (it’s free) and installed VET.
  2. Once installed, simply launch the Profile Update Utility.
  3. Select your mandatory profile by clicking the “Browse” button (step 1).
  4. Check the “Merge HKEY_CURRENT_USER ActiveSetup keys” checkbox (step 2).
  5. Click the “Go” button (step 3).

It doesn’t get much simpler than that! Note: This will merge the ActiveSetup keys from the currently logged on user. Therefore, you need to perform this action on a machine that you’ll be using the mandatory profile on.


The “Output Options” at the bottom of the PuU windows could probably do with some explaination as there is sometimes some confustion.

  1. Update Original Profile: Overwrites the source (Step 1) profile.
  2. Backup Profile: Copies the source profile (in Step 1) to a .bak file and then updates the original.
  3. Create New Profile: Copies the source profile (in Step 1), renames the original (in Step 1) to a .bak file and then updates the new copy.

Which option you use is up to you depending on how you manage the lifecycle of your mandatory profiles.

Enjoy – Iain

Locating Computer GPO Registry Values

I come across this scenario all the time that requires a HKLM registry setting to be configured. Typically this can be implemented via Group Policy but, for whatever reason, you which to set the resulting registry value directly. It might be because you don’t wish to cut a new GPO just for a couple of servers or workstations. A common requirement is to set the RDS licensing server as part of an automated deployment. Maybe you use RES Automation Manager like we do. However, this scenario is not limited to just RES Automation Manager. You could use the information in this post to configure a few specific settings as part of a WDS deployment for example.

Hopefully by now you are all familiar with the free Virtual Engine Toolkit (VET). No!? Shame on you! I suggest you take a look over here and see how it can help migrate from a unmanaged user environment to a managed one.

So you now know VET is especially good at converting user related GPOs into .REG files that can be imported in your UV/UEM tool of choice i.e. RES Workspace Manager or AppSense Environment Manager. One of VET’s hidden talents (and undocumented until now) is we can also convert computer related GPO’s into .REG files.

Using the settings above as an example I’ll run you through how we achieve this with RES Automation Manager and not in a GPO. If you’ve read our series on user GPO migration then you’re aware that GPO settings (not all!) are just registry settings. The problem we normally have, is where and what should these values be set to?

You could at this point download the Microsoft Group Policy Settings Reference guide and find the individual registry keys. You could use the Group Policy Search which Kees Baggerman spotted and pointed out in this blog post Winking smile. You can spend time Googling them at which point you would have to start manually adding them to the registry task in AM. But its much, much simpler to use VET!

NOTE: the same process could be used for migrating multiple existing computer related GPOs into AM but please be aware that the computer will probably need a reboot before the targeted settings come into force.

  1. First thing to we need to do is create a Dummy GPO where we can set the various policies we’d like included in AM. In my example I’ve called my GPO “Dummy GPO for VET” and configured the settings we’d like to apply as in our example above.SNAGHTML20d08061
  2. Next we need to launch VET and use the “Convert Group Policy Objects Wizard” to scan the SYSVOL folder for our newly created/existing GPO. Once VET displays the list of GPOs select the one that you wish to convert then click “Next”
    .image
  3. Select “Use subfolders for User and Machine policies”. Deselect “Also create RES Workspace Manager Building Block Files” then click “Next”, “Next” and “Finish”.image
  4. Looking in the “Documents\Machine” folder you’ll find the newly created .REG File containing our settings.
    image
  5. Now launch the RES AM console and create a new module which contains the “Registry Settings (Apply)” task. Its then a case of importing the .REG File created previously; so you should end up with something looking like this.
    image

It’s as simple as that! We’ve used a dummy GPO that is not applied to any computer objects, set our required settings and imported the exact resultant registry values into RES Automation Manager. You can probably think of other great use cases for this too.

You never know we might incorporate the ability for VET to generate RES Automation Manager building blocks in the future.. Hope this little gem helps someone in the future like it has me!

Nathan

12

Archives

Categories