New Technote: Workspace Containers, Inside-Out

It is a pleasure to announce a new technote in the library. This particular one focuses on the usage of Workspace Containers in PowerFuse 2008 and up. For some, the workspaces have been a conceptual hard pill to swallow. It is the ambition of  this article to shed some light on the often overlooked capabilities of Workspace containers.

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. 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…

Examle 1 – Using workspace containers as computer lists

Perhaps an example would serve to illustrate: A customer 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 mess 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: “Waitjustaminute, 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.

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-2008 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 last 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 here 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.

To wrap things up, the four 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.

Happy Workspacing!

Max++

Share/Save

Leave a reply

Click here to cancel reply.

Name (required)

Mail (will not be published) (required)

Website

CAPTCHA Code *