RG065 – The beginning of the end, for PwrGate

By Max Ranzau

 

einFrom the NostraRanzau Dept. This article describes some very interesting developments which I came across in in the recent Service Release 4 for Workspace Manager 2012. To be accurate the feature we’re discussing today was already available in the SR3.6 updatepack, but since it’s rolled into the official SR4, that doesn’t matter much.

Anyway, back to the matter at hand. For eons, the way Workspace Manager has created Managed Applications was – and still is to create a shortcut that indirectly refers to the applications executable, by way of a AppID reference. A command line on a RES created explorer shortcut, would look something like this PWRGATE.EXE <AppID>. The AppID number is an integer that refers to a unique number in the RES Workspace Manager datastore, assigned to each application upon creation/import.

This method of launching managed applications has been the same for many years and has served us well. With the introduction of Process Interception in early Workspace Manager 2012, we began to move away from this approach: Process Interception, using the built-in filter drivers, was upon launch of a given process name or wildcard, able to inject Configuration Actions and User Settings into the interceptconfig2environment. This however only worked for already existing shortcuts in the target environment, or if the user launched the given process binary directly. That meant you had to run Workspace Manager’s startmenu subsystem in merge Mode and turn off the disabling of process interception (yes, I know…). For each existing app, for which you wanted to apply process interception based configuration, you created a new Managed app and switched on process interception there as well.

pwrgate-appHowever, up until now – if you created new regular managed apps from scratch within Workspace Manager – not using process interception, the resulting explorer shortcut would still contain a PwrGate.exe command line, as described above. This is the important change in SR4. When you enable this setting ( still a registry key at this point), all new shortcuts will be created with the native binary, specified in the command line of the managed app and PwrGate will be used no more.

Now, let’s roll up our sleeves and try this thing out. On top of an existing environment, I’ve installed the Service Release 4, imported some MS Office applications and configured the startmenu mode to Replace mode. As expected the entire start menu is empty except for my office apps. As you can see on the right, the resulting shortcuts for new apps look the just the same as before. According to the SR4 releasenotes on page 14, we need to do the following to stop creating PwrGate shortcuts:

  1. Per agent where this should happen, go to the right registry path HKLM\Software\Wow6432Node\RES\Workspace Manager (x64) or HKLM\Software\RES\Workspace Manager (x86). Create a new REG_SZ string called InterceptManagedApps = Yes. There are some more options for this value we will talk about further down.
  2. Make sure Process Intercept is turned on (or un-disabled) globally, under Applications|Settings
  3. For each managed app, which should not have a pwrgate shortcut, make sure that the app is set to “Intercept process and apply configuration”, as shown on the screenshot above. Tip: If you have many apps, just rightclick somewhere on the startmenu and chose QuickEdit|Properties|Intercept to batch change all the apps within a given start menu.

Next time you login – voilá! The shortcuts are is back to their native explorer state, pointing directly to the executable, but with RES Workspace Manager controling both the vertical and the horizontal!

Note: The InterceptManagedApp value can also include exclusions for certain apps for which you still want to retain the usual PwrGate <AppID> shortcut for, for one reason or another. One reason I can think of is that if you happen to be using Workspace Manager’s licensing and enforcement system – at least for the time being you probably will still need a pwrgate managed shortcut, that’s just my own guess though. In order to exclude managed apps from having Process Intercepted shortcuts created = Regular PwrGate shortcuts, add them to the value of InterceptManagedApp = Yes|winword.exe|excel.exe|somethingelse.exe|…

bug1I tested this feature out in the initial UpdatePack releases and there were a few kinks that needed to be ironed out. Even though the SR4 behaved as expected, you may possibly experience that Win7 explorer throws some errors such as the one shown on the right when you refresh. This was due to Windows trying to create a new AppUserModelID. There is more info on that on MSDN. According to the SR4 release notes; “the AppUserModelID is used for stacking and pinning application shortcut icons on the taskbar and in the Start Menu, generating the list of Recent items in the Start Menu and the Jump Lists. Therefore, the changed command line used by RES Workspace Manager for managed application shortcuts will cause some unwanted side effects and issues”. While it looks like we got this nailed down in SR4 so it works smoothly, do keep a lookout for it and let the friendly folks in support know if it should rear it’s head again.

As the beginning of the article said, this is the beginning of the end for good ol’ PwrGate.exe While it has served our customers nicely for a decade and a half it will soon be time to let process interception take over the job of launching managed apps completely. Keep your eyes peeled for this functionality in future releases.

 

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

You must be logged in to post a comment.