Authorizing in WM – How it SHOULD work

By Max Ranzau

 

chockFrom the My-Two-Cents Dept. Working with RES Workspace Manager for about 1½ decade, I’ve been witness to many improvements. While the products gets better with each release, regardless of vendor it’s not always flowers and chocolate. By now, most seasoned Workspace Engineers familiar with the product, know the difference between learning mode and blocking mode on the security subsystems. Dialing in the security for a new client/customer always takes a bit of time, as you’ll have to deal with the security baseline – and then authorizing the things that are unique for said customer environment. The work I always seem to find myself spending time on is hopping back and forth between Authorized Files and either the Managed Application node or the Read-Only Blanketing node.

The issue at hand is this; every time that one has dealt with a log entry by right-clicking on it, said log entries will still be in the log. It makes it a challenge to maintain an overview of what’s been dealt with and what hasn’t – especially if you are using wildcard rules to kill multiple log entries with one stone. It would be wonderful if this process could be managed better. I’ve gone through the necessary steps in a previous article here. To optimize this work, below are a few of ideas off the top of my head how this ideally should work:

  • The security logs should be reworked to show a “Processed” or “Authorized” flag. Think of it like the little red flag you can set on your emails and tasks in Outlook.
  • When authorizing a specific log entry, there should be check boxes in the authorization dialog box to “Mark affected log entries as authorized” and/or a “Delete affected entries in log file”. Workspace Manager can already can filter views with the Attention flag etc. in Workspace Analysis, so it should be familiar territory, development wise.
  • In the Authorized file node there should be similar options to process all current log files through active authorizations so it becomes evident which things you haven’t dealt with yet.
  • Finally, it would be stellar to incorporate Patrick Grinsven’s excellent work on the DBlogCleaner tool (which is out in a new version, stay tuned)

Now, before some well-meaning person asks why I don’t put these ideas into UserVoice for voting etc, I will offer my thanks for the consideration, yet I am perfectly happy passing that baton with the associated credit to someone else. In other words, feel free to co-opt these ideas and make them your own.

 

Keeping Virtual Sandboxes under control

By Rob Aarts and Max Ranzau

Rob: After using VMware Thinapp in several projects I wanted to share some best practices The first one is about a common mistake I see made on a regular basis. Applications with several entry points for executables, are presented using Workspace Manager, using multiple managed applications. So far so good.

The problem arises when all entry points (from the same Thinapp capture) have their own Zero Profile setting pointing to the same Sandbox location. Are you still with me here? Let’s have a look at the example below:

p1

Here’s a working example:

  • When a user launches Application 1, Zero Profile settings are loaded and written to the sandbox.
  • The user then launches Application 2 and Zero Profile settings are loaded and writes to the same sandbox location.

What is likely to happen, is that settings for Application 1 become corrupted, due to it’s settings are being changed by another process while it’s running. I personally have seen some strange behavior from apps, which absolutely don’t like this messing are around with their appdata behind the scenes. It doesn’t take a degree in rocket science to imagine what may happen when Application 3 is launched. It will just increase the likelyhood of corruption.

The solution to avoid this mess is simple and was covered previously, although for natively installed applications only: Have a look at Max’s article RG056 in the tech library. Setting up a placeholder application as described in the article will allow you to configure  individual apps app to save the sandbox and direct The Zero Profile from Application 1, 2 and 3 to this placeholder App:

p2

Max: Once you have this set-up, the next challenge is to make sure your User-Settings capture configurations are not overlapping. As of WM SR3 there is a setting for global User settings to grab a setting exclusively. This means that if say 3 different global user settings grab the same registry value you can check one of them as exclusive and only that UserSetting will store it. Unfortunately this approach doesn’t work well for Managed Application based user-settings, as the capture-exclusive feature isn’t available there (yet?). Anyhow, there is a workaround for this. Let’s say you start with creating a suite-settings placeholder app, like described above for Office:

  1. You create a new managed app
  2. Under user settings, you add all the capture templates for Word, Excel, Powerpoint etc. and you have a nice list like shown below
  3. Then everything is cool and ready to rumble, right?

p6

Unfortunately that’s not quite the case, as the templates are likely to overlap. This is not the fault of the template designers, but a function of that they need each to be able to stand alone. This means we have a bit of cleaning up to do, but it’s quite easy. When you are on the User Settings|Capturing tab of the SuiteSettings app as shown above, do the following

  1. Click the Show details checkbox at the bottom of the dialog box
  2. Now click on the data column header to sort on files and registry entries being captured
  3. Look for identical rows (highlight)

p5

Note the line for the ‘Microsoft InfoPath Designer 2010’, which I have highlighted and disabled. I disabled it because that particular User Setting was already captured by the template called ‘Microsoft Infopath Filler 2010’ and as you may recall from our discusion above, we do not have the option to capture exclusively on Managed apps.

You disable an item by doubleclicking on it. Don’t fall for the temptation of removing the checkbox you immediately see, as that will disable the entire template, in which you are only interested in disabeling a certain file/reg grab. Instead  go to the Capturing tab, then select the offending/duplicate entry, double click again and THEN remove the Enabled checkbox you see. Sequence shown below:

p7

You can of course also delete the duplicate entries to tidy things up. In this case I kept them around for illustrative purposes. One thing I’d like to make you aware of: First, go to the global User Settings node, and at the bottom check both ‘Show details’ and ‘Show all User Settings’:

p4

dpNotice that once you link up multiple applications to the same suite app, you will see multiple entries of the same user-setting. This is not a bug or an indication that something unnecessary is being captured. For example, look at the example above where about half way down you see about 7 references to %APPDATA\Microsoft\Access and both Word, Excel etc are pointing to it. This does NOT mean the and Word and Excel templates had duplicate entries. It’s simply because the combination of the two checkmarks shows the canonical list of all combinations of apps and user settings, thus the repeats. In short: They’re mostly harmless. Don’t panic!

We hope with this little away-mission into advanced WM User Settings management to have given you some new thoughts on how to both wrangle virtual applications as well as suite settings for multiple apps.

Rob & Max