In this article it’s my ambition to clarify what the heck these Workspace Containers are, and go through some practical examples on how they can be utilized best. Note this article has been updated Jan 31st with two more example on how to utilize the power of Worspace Containers and has been renumbered from RU002 to conform to the article number standard employed on RESguru.com
To start from the very beginning – In it’s simplest form, a Workspace container can merely be a list of computers. Not just any computers, but some very specific computers which are uniquely identified by the RES PowerFuse agent running on them.
Your first thought as a seasoned PowerFuse engineer might be; “Well, Duh! I can do that with PowerZones!” Yes, however only to a certain degree. PowerZones only caters for the geography (where is the computer) and the geometry of the computer (chassistype, ram, cpu, romburner present, etc.). It does not uniquiely identify the computer. The Workspace container will allow you to build a list of uniquely identified computers. The list will remain the same no matter if the computers later are moved, renamed* or the underlying IP configuration changes.
There are some additional dimensions to the workspace container, but let’s not get ahead of ourselves and make things overly complicated, just yet… :) In this article you will find 6 real-world examples on how you can harness the power of the Workspace container.
Examle 1 – Using workspace containers as computer lists
A corporation in the Nordics has a corporate campus, consisting of 5 buildings, each with 4 floors, with three wings; north, south and east. Each of the total 60 wings has 1-2 printers which should be mapped to workstations present in the area. The problem the customer was facing, was that neither the computer naming convention nor the IP scheme allowed us to geographically pinpoint where the machine was at. To add insult to injury, the machines had been renamed once or twice so even the name did not correspond to any existing inventory records which were on hand. Does this situation perhaps sound familiar to you? :-)
A Workspace Container was created for each wing, such as Building B, 2.nd floor, North wing – In short B2N. The computers physically present in the B2n wing were added to the workspace named the same. The customer needed to manually enumerate the machines out there. There was no way of doing that automatically since the current infrastructure would not lend itself to this. Secondly, if any machine was moved physically later on, the affected WorkSpace containers would need to be updated. Using Workspace Containers for this particular scenario, had the advantage that we’re independent of the following:
- Lack of underlying IP infrastructure
- Lack of consistent naming convention
- Lack of cohesion between current names and CMDB registered names.
- Future renaming of computers
Technically, one could have used nested PowerZones for this, however due to the lack of missing infrastucture underpinnings (ip subnets, naming conventions, etc), it would not have been as elegant. The customer would have been forced to build Powerzones consisting of multiple “(Partial) Computername” rules, each referring to a unique computer. Besides being cumbersome to build en mass, there is the question of how long it will take to parse if you litteraly have hundreds of powerzones to munch through. The WorkSpace Container approach to this, would be much more elegant.
Example 2 – Using Workspace Containers to distinguish environments
Another way of putting the Workspace Container to good use, is to utilize it in large SBC server farm environments. A customer has a serverfarm consisting of +200 Citrix servers. About 50 of these were dedicated to a special invoicing application which many branch offices were using. Another 20 servers were dedicated to another apps and the rest were general purpose servers for the rest of the appsuites, such as Office, etc. Besides the SBC environment
The savvy PowerFuse admin might be thinking: “Nowwaitjustadarnminute, Mr. RESguru – I can do that siloing with ServerGroups already in the PowerFuse Citrix integration. True, but what if different settings apply to these farms? Again the name of the game is reducing administrative complexity. Contrary to common belief, we IT people have lives too..! Workspace containers will let you define your lists of servers as, say Silo1, Silo2 and Silo3 etc and any setting in PowerFuse can then be assigned to these.
Another aproach is to define a hybrid environment, typically consisting of Workstations, Laptops and a SBC environment of one sort or another. It doesn’t take a rocket scientist to figure out that only the most rudimentary settings can be shared between the 3 mentioned environments since the base configuration may vary greatly. The SBC environment will be more restricted and the laptops will have configuration elements which deal with the fact that they may be off the corporate networks for extended periods. On the left is a screenshot from the PowerFuse 7x-to-2008 migration slidedeck which speaks to the value of using workspaces for this exact purpose.
Example 3 – Using Workspace Containers as a security abstraction layer
A third way of utilizing workspace containers would be to use the container as a kind of abstraction layer between configuration settings and access control. For example, a customer is in the midst of a rollout project, where access control has not been determined yet. Yes this actually happens. The problem is that it is not currently known what kind of access method is to be used to describe who is getting the items. This can evidently be problematic if you all of a sudden have to go back and change applications, drives, registry settings etc from a group to an OU. Enter the workspace container. Instead of assigning interim groups etc, just leave the access control blank for any given item and assign it to a workspace.
Using workspaces together with applications in particular has it’s advantages in PowerFuse 2008 SR5. As you may know there’s currently a limitation on how you can assign access control on an application. For example, you cannot mix and match say groups and ou’s. Besides this, you are not able to invert neither a selected PowerZone or group, meaning you cannot directly specify; “Give access to this app only if you are NOT member of a given group or PowerZone”. Using the workspace container to circumvent this limitation is a clean and structured approach. A practical use is highlighted in the RG001 article here.
Example 4 – Using Workspace Containers to describe a situation
The next example I want to share with you may perhaps be considered a bit exotic, per say. However, it helps illustrate the level of granular control you can obtain by using Workspace containers. Let’s have a look at the dialog where we define a Workspace container on the right. As mentioned in the beginning of the article, in it’s simplest form, a Workspace container is merely a list of computers. That list can be defined under the Computer Control tab. That list can be combined with the Access Control tab, where you can specify the identity of the user and/or the physical characteristics/location of the computer. This means that we can add two extra dimensions to the simple computer list. All of a sudden we are now describing a usage situation. This way, used to it’s fullest extent the Workspace container can be used to describe certain computers, being used in a certain location, by certain users.
Example 5 – Using Workspace Containers to select environment for an application
One of the really cool features in PowerFuse 2010 is the ability to create user selectable workspace containers on an application. Great, so what can we use this for? Simple. Say you’ve got a client-server application which is used to connect to 3 different environments such as development, test and productions. Previously, you would have had to create 3 different applications in PowerFuse, possibly having to manage redundant settings. With PowerFuse 2010 you are now able to create a workspace container which has some settings attached. Let’s say that switching a given application between environments requires you to change to a different ODBC connection, some registry settings and an .ini file setting to put it to the extreme.
What you need to do is just create a workspace container for each environment. Create the required settings and attach them to the proper workspace through the Workspace Control tab. Once this is done, you go and edit your application. Select the Access Control | Workspace Containers tab and configure the app. Look at the example here on the right. Note, there are a few other things you will need to do. It is my ambition to write a seperate article on this topic in the near future.
When the user starts the application after the next refresh or login, PowerFuse will display a dialog box similar to the one shown here, before starting the app. I have written the RG023 article, which in detail explains how to set this up.
Example 6 – Using Workspace Containers to configure global options
Yet another example of what you can use workspace containers for, is the PowerFuse 2010 menu (Plusmenu’s in daily terms). All over the PowerFuse console, you have settings which up until PowerFuse 2008 only were configurable for given groups using registry settings, like described in this old article.
In PowerFuse 2010, you now have the ability to configure global settings, such as CPU management or pretty much anything else specifically for certain workspace containers, using the PlusMenu [+]. This is called the Workspace Model. I have written an article RG027, dedicated to examining the usage of this feature.
- – -
To wrap things up, the examples above are just ideas for some of the things you can use workspace containers for. In a future article I’ll be covering filters and scope control to complete the picture.