RG027 – Workspace Models 101

By Max Ranzau

 

In this article, I will attempt to describe  the Workspace Model feature of RES Workspace Manager, and how you can use these to your advantage. The Workspace Model feature was introduced in Workspace Manager 2010 and allows you to make exceptions to global settings for specific workpace containers. This is great for managing multiple environments where all global options don’t necessarily apply everywhere. If you still feel a bit in the dark what a workspace container is, perhaps go check out this article for workspace container usage scenarios, then come back here.

Overview

To get a grip on what the Workspace Model is, think about it this way. In your house or apartment, you are more than likely to have a circuitbreaker box somewhere, where all the power of your place is routed through. Here you can turn off the power for the livingroom, kitchen, stove, etc. Workspace Manager 2010 comes out of the box with such a circuitbreakerbox, where all the important features can be turned on or off. This is found in the Workspace Manager console below Setup | Workspace Model, on the Global Settings tab:

There are six  important things to know about the Workspace model to begin with:

  1. If you do a clean install, creating a new Workspace Manager datastore, everything is disabled, switched OFF or otherwise configured for minimal impact per default. This means that Workspace Manager will not do anything on the target computer where it is deployed.
  2. If you upgrade an existing Workspace Manager 2008 installation to Workspace Manager 2010, everything will be switched ON to ensure you do not loose any functionality in the upgrade. This is because everything was turned ON in Workspace Manager 2008 per default.
  3. If you change any of the items above to Enabled, or something else, this will reflect on the tab of that feature. In other words, if you switch Printers to Enabled, next time you go to the Composition | Printers node, you will notice that the printer mapping feature has been enabled. Here is a tip for you. Notice on the workspace model that whenever you have an item selected on the list, you will see this button: If you click it, you will automagically be teleported over to the correct node for the model item you are editing.
  4. The list of items on which you saw above, will be the default behavior of Workspace Manager, unless anything else is specified. We are going to look how to do just that in a minute.
  5. The core functionality of the workspace model was already present under the skin of Workspace Manager 2008, by way of the registry. In either HKLM or HKCU it was, and is still possible in 2010 to switch on/off individual Workspace Manager components using the keys below HKEY_LOCAL_MACHINE\SOFTWARE\Policies\RES\Workspace Manager\Settings. There is an old article about it here. It is however not necessary to do this anymore as the Workspace model is way more flexible and easy to work with, once you understand how it does it’s thing.
  6. The checkbox will, as it says on the tin, hide all setting from view where the setting is disabled. It will however leave a couple of items behind, namely the Shell setting as it per say isn’t disabled. See more about this below. Also the Managed Applications setting. If it’s set to Do Nothing, it is effectively disabled, yet it’s still shown here after the checkmark has been set. Overall, the purpose of the checkbox is to give you a quick overview of what’s actually switched ON per default.

Things that may need further explanation:

There are a few items in the screenshot above which needs to be discussed in further detail. For the most part, it’s fairly predictable what happens when you for example change Drive and Portmappings to enabled: Any specified networkdrives etc. in the Composition | Files and Folders | Drive and Port mappings, will now be processed.

However. there are some items that may not be completely obvious at first glance. Take for instance the first and third setting shown here on the right. I  get the question once in a while; “So, why isn’t there a disable option on the Shell item here? Why can you only chose between the Windows shell and the oldschool Workspace Manager shell here?”. The answer is that if you switched off the shell from within Workspace Manager, you would in fact be disabeling Workspace Manager. If that’s indeed what you want to do, you need to do this on the Agent properties. See this article for more info on that subject.

Another item we need to discuss is the Lockdown and Behavior node. We need to make a small detour here, as the setting “Disabled (but apply configured behavior)” has confused some. How can Disabled really mean disabled, when it’s still applying configured behavior? In order to understand this one better, we need to take a closer look at the settings to be found in that particular node:

So here’s the skinny: All the lines above marked with a gear icon () is a configuration item, thus if it’s box is ticked, it will STILL be processed, even if the entire node is set to disabled. The other lines which has a disabled padlock icon () are lockdown items. These are disabled because the Lockdown node is currently set to disabled, as shown above. Once you enable the node, all the padlock icons will become enabled (). The net result is that all the lockdown is disabled per default and configuration items which are enabled in a new installation are relatively benign. For example, none of the Hide configuration items are enabled. This makes it very easy to deploy Workspace Manager into an exsting production environment without being noticed.

The PlusMenu

Okay, so back to the workspace model. While it’s nice that everything is in one place where you can switch things off/on from one central place, this doesn’t address the issue that one shoe doesn’t fit all. You will more than likely have scenarios where you want some stuff turned on for some users/machines/locations, while it should be off for others. A good example of this is the security subsystems: While read-only blanketing is a wonderful method for keeping your terminal/citrix servers filesystems consistent, this may perhaps not work to your advantage on some of your workstations for one reason or anoher. This is where the PlusMenu comes into play.  Right next to the Global Settings, you will find this symbol: When you click it, you will get the option to chose a workspace container like shown on the right. If you haven’t already created workspace containers, use the Add button to do so at this point. Note, per design you can’t use users, groups and other access control elements directly on a PlusMenu, however that’s not a big deal as you can just add access control on a Workspace container, while remembering to tick the Include All Computers checkbox on the workspace container’ Computer Control tab.

Once you’ve selected a workspace container, a new tab is created on the Workspace Model node. This tab represents a list of exceptions from the default Global Settings list. Just when you’ve created it, it will look like this:

Notice that all settings now currently are followed by the [Global] tag. This means that the settings are inherrited from the Global Settings tab. In short there is no difference configured yet on this tab so it will do nothing just yet. Also notice that certain settings cannot be configured as exceptions. Specifically, User Installed applications and the Shell are not configurable as exceptions. Reason being that these feature already have their own access control tab which allows for configuration of workspace containers, so having it here would not make sense. Second, the shell cannot be configured as an exception either as when the workspace model is evaluated, the shell is already loading.

Once you start making changes to the exception workspace models, you will have 3 choices: Enabled or Disabled [Global], Disabled or Enabled. The first choice is basically inherrit whatever the global setting for this item is set to. The second and third choice will allow you to override the global settings by explicitly enabling or disabeling the item.

Once, you’ve made the exceptions you want, it’s easy  to view these alone without having to see the Global settings. Just tick the checkbox . While we are at it, here is a little tip which may help speed things up when configuring the workspace models. Instead of using the drop-down list for selection of enabled/disabled, just doubleclick on the field and it will toggle through the available options. This btw works all over the Workspace Manager console.

A practical example

The last, but probably most important thing we need to look at is what happens if you have more than one exception model configured, where there is overlapping configuration settings for a given item. It’s important to know how Workspace Manager handles this, so we can take advantage of the decision logic. Let’s take a scenario like this:

  • You have created two workspace containers Workspace-A and Workspace-B
  • Workspace-A triggers only on computer control, i.e. it doesn’t care who you are but it activates when somebody logs into onto a computer in the workspace containers computer control list. You have added ComputerY to the list.
  • Workspace-B triggers only on Access Control, meaning that the computer control list has been put out of the equation by ticking the checkbox on the workspace containers Computer Control tab. Access control on the Workspace-B container has been configured to trigger on group membership of GroupY.
  • You have Printer mappings configured as Disabled on the Global settings tab
  • You two exception workspace models, one for Workspace A and one for Workspace B.
  • For Workspace-A, you Enable the Printer mapping
  • For Workspace-B, you Disable the printer mapping

In order to understand what happens when you log on ComputerX with a member of GroupY, we would need to know 3 basic rules to make sense of all this:

  1. All overlapping workspace models are processed from left to right. By overlapping means that the given workspace has someting configured for a given item, Printer mapping for example.
  2. The global settings tab is always processed (that is, only the enabled items on it)
  3. Processing will stop at the first exception workspace model attached to an active workspace container.

This is what happens:

  • The items on the Global Settings tab are evaluated. Here Printer mapping is disabled.
  • We logged into ComputerY, Workspace-A is active. Therefore the workspace model attached to Workspace-A is processed. Here printermapping is enabled and will then override the default.
  • Since there was a match on Workspace-A, the workspace model processing stops before it reaches Workspace-B.
  • Net result: Printermapping will be Enabled and stay so when we log in.

At this point usually two questions arrise; “Hey! this could be complicated, how do I troubleshoot this?” Second, “what if I want to change the order of processing between two workspace models?” Both are valid questions which I wil answer below.

Troubleshooting

First of all, if you forget all about the three rules above, it is indeed possible to mess things up good here, but it’s also possible to cause a nuclear meltdown – just ask the Russians! That being said, take care to understand what it is you are trying to archieve instead of just going beserk and click away, hoping Workspace Manager will sort it all out. Before setting out to use workspace models, I would advise you to:

  1. Have a clear picture of what you are trying to accomplish.
  2. Try to “think in models”, so before you lay out your Workspace containers and attach models, try beforehand to envision which models may be of use in a particular project.
  3. Try to restrain yourself from going overboard in workspace models. It’s easy zu snappen das springenwerk, corken poppen und fusen blowen! If you have more than 3 models you need to keep your head straight as there’s currently no administrative note field on the workspace models.

Having followed all of the above, it’s also usefull to know where to find info on what actually happended workspace-wise when a given user logged in. Like anything else login-related you will find this in the Workspace Analysis eventlog for the user:

The screenshot of the log above is taken from another environment, but as you can see, the log will reveal the end result in the session – exactly what settings are enabled and which are disabled.

Priorty

An important topic to cover, is  how to change the priority between two workspace models. The most important thing to know at this point: You cannot change priorities on the Setup | Workspace Model node. You have to go to a setting, such as printermappings and do it there. We will have a quick look at how that’s done.

Let’s start out where we left the practical example above. In Workspace-A we enabled printer mapping, and in Workspace-B we disabled it. Because Workspace-A came first and was active, the buck stopped there and printer mapping was enabled. Now, if we decide we want to change this behavior, we will have to change the priority.

Go to the Printers node and rightclick on either Workspace-A or Workspace-B. As you can see on the right here, you will then have the ability move the individual workspace to the left to increase priority or to the right to decrease.

You can also disable the effect of this exception workspace, by chosing the ‘Disable this tab’ option. The icon next to the name of the workspace will change to . This effectively means that the exeptions workspace model for this setting (Printers) will not be processed, regardless of it’s priority.

Another effect is, that if you go back to the Setup | Workspace model node, you will notice that the setting has changed to the value in the Global setting with the string [Global; override disabled] after it. This is just your confirmation that there are NO exceptions taking place and the Global setting for Printer mapping will be enforced. Another way of looking at it is that by disabeling an exception, you force-inherrit the global setting.

If you later re-enable the exception on a given feature node, Workspace Manager will remember the original exception that you put into the Workspace model. In the real world, you probably will want to use the Disable option only temporarily to take a given exception model out of the equation for one reason or another. If you are not using it, I would suggest that you may be better off deleting it.

Deleting exceptions

There are two ways of deleting a workspace exception model: 1) You can delete it on a given feature node, such as Printer mapping or 2) you can delete it on the Setup | Workspace model node. It is important to understand the differences between the two.

First we will examine the consequense of deleting a workspace model exception from a given feature node. Let’s say that Workspace-A enables Printer mapping, and also enables Drive and Port mapping, like shown here on the right.

This is a screenshot of the Workspace-A in the Setup|Workspace model view. Note: The hide-global-settings checkbox is selected. If we now go to the Printers node, rightclick on Workspace-A and delete it, Printers will appear to have disappeared when we come back to the Workspace Model overview. However, if we remove the hide-global-settings checkmark, we will see that the Printers setting has in fact just reverted back to inherriting the [Global] setting, hence no more Printer exceptions.

However, if we now go back to Drive and Port mappings and delete Workspace-A, something interesting happens. When we return to Setup | Workspace model, you will find that the Workspace-A tab is completely gone. The reason is that we just deleted the last exception on that workspace, so there is no reason to keep an empty/inactive model around. If that’s what you wanted to do, you should have just disabled the exeptions instead of deleting them.

This works two ways. If you instead went first to the Setup|Workspace model tab, rightclicked on a workspace exception model tab, your only option would be to delete it. This has the effect of removing ALL exceptions from all affected nodes at once. You can very easy clean up an exception model, making sure it leaves no unwanted residue this way.

Summary

By going through the various options of the Workspace Manager 2010 Workspace Model feature, I hope to have handed you a powerful tool to assist you in managing complex environments, while ensuring you keep a clear overview of what’s going on. If you have any questions, feel free to comment on the article or post something over at the RESug Forums

/Max

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.