Novell is now a part of Micro Focus

Limiting App Distribution to Users AND Workstations

Novell Cool Solutions: Feature
By Edward Falzon

Digg This - Slashdot This

Posted: 20 Sep 2000

Current version: ZENworks for Desktops 3

Original Article

A little while ago, I designed a way to limit an application to a set of users, while ALSO limiting it to a set of workstations. This question has been posed in the Q&A, and also I've been explaining this concept all over Australia, and I'm getting a lot of "Ooh's" and "ahh's." Here's my solution.

The Setting

  • There are 26 workstations in the network (named "A" to "Z").
  • There are 50 users (1 to 50), who all roam to every computer from day to day.
  • The company has just three licenses of MS-Word, and Microsoft won't allow them to install it to every PC, even if only three people use at a time.

The Goal

Allow a group of ten users (User 1 to User 10) to access the MS-Word Application object, but ONLY if they're on Workstations A, B or C.

The Problems

  1. If we associate the MS-Word to the users, then those users will be able to access the App from any PC. So we then have to use System Requirements to specify the computer name (e.g. %P_STATION% or the "WorkstationObject" value in the registry). This method works great if you want to allow multiple users to use the App on a single workstation only. Unfortunately, it's not possible to specify "OR" in the System Requirements; only "AND". So if we want the users to access the AO from multiple PC's, we can't say, "Must be Computer A or B or C." We would have to say "Must NOT be Computer D AND must not be Computer E AND must not be Computer F..." for EVERY computer on the network! Not acceptable.
  2. We could associate the AO to the 3 workstations, so it can only run on them, but that means ANY user can load the App at those workstations. Under System Requirements, we could check an environment variable for the user name, but we run into the same problem, having to specify "NOT User 11 and NOT User 12..." For everyone who's not allowed to use the Application. Again, not acceptable.

The Concept

We need to "think outside the square." Who says we have to specify the association and/or system requirements for an application, in a single App object? Let's use TWO Application objects to deliver a single application.

The Solution

Associate the MS-Word Application object directly to the users (or the User Group object, probably). In the System Requirements tab, specify that the App will only run on PC's that have the Registry value HKLM\Software\SOE\ MSWordAllowed=TRUE (by the way, SOE = Standard Operating Environment)

So, unless that Registry setting is there, with the value of "TRUE", the App won't appear.

Then - this is the clever part - create a SECOND Application object. This App might be called, "MSWordValidation". The AO does just one thing: It creates a Registry setting: HKLM\Software\SOE\ MSWordAllowed=TRUE. Associate this second AO to all the workstations that are allowed to run MS-Word (again, probably use a Workstation Group object), and set it to Force Run.

The Result

Only authorised users have access to MS-Word, and only if the special Registry key is there. The special Registry key is ONLY on the workstations that we tell it to be on, so we can now dictate which users can access the Application (by associating directly to the MS-Word AO), and on which computers (by associating the workstation objects to the "validating" AO).

Edward Falzon is a member of the ZENworks Cool Solutions Board of Review, and one of the creators of the popular 3rd-party tool, ZENith. If you have any questions about this article you may contact him at

Additional Ideas

Merijn van de Schoot NEW

In response to "Limiting App Distribution to Users AND Workstations", a feature article by Edward Falzon, I also have a tip:

In our network environment we are also limiting applications to a user and to a workstation, but the story behind is slightly different.

We have several sites on different locations, and we service them from one main site using NDS and, of course, ZEN. All sites are wired to each other, some of them using a T1 (2 megabit) and others connected through an ISDN (64kbit) Dial-On-Demand.

Throughout the entire network we are using Windows NT workstation on the client side and NetWare 5 & ZEN on the server side.

Every computer within our networking environment has a unique name, but each name starts with an unique site identifier.

An employee is a member of the group "Microsoft Office." This group is linked to Apps.Word on site 1, but also to Apps.Word on site 2, site 3, etc.

In the application object Apps.Word on site 1 we add a System Requirement stating e.g. "Environment value COMPUTERNAME contains SITE1-"

In the application object Apps.Word on site 2 we add a System Requirement stating e.g. "Environment value COMPUTERNAME contains SITE2-"

If an employee logs onto the network he or she will get Word from the fastest possible server, on site 1, on site 2, on site 3... Everywhere in the entire network.

(...I don't want to think about what would happen if Word were getting installed over a Dial-On-Demand 64kbit network connection!)

If there is an update we copy all files, an automated process at night, to all different sites. This way nobody gets disturbed but the next day a new version of Word will get installed at full speed from the local server.

We are also using this solution to prevent some applications from running on Citrix (Environment value WINSTATIONNAME does not exist) or to force an application to run through Citrix if an employee is behind a slow link, but if the same employee is on our main site he can access the application directly. It's all happening without clicking on the right icon, because there is only one icon available where he is.

Comment from Edward

Merijn van de Schoot's idea is quite clever. I would suggest, however, that one use the Application Site List feature of ZENworks to accomplish the same thing, but more natively. By daisy-chaining the Word application between all sites, users automatically use whichever Word App is nearest to them when they log in.

The Application Site List feature is designed for roaming users, and users at Site 1 would be associated to Word.Apps.Site1. The benefit of this method is that there's no need for a user to walk the tree, if they're at their home site, whereas associating a Group object to all Word apps at every site will ALWAYS involve tree-walking, because each application needs to check its system requirements.

John Dehaeze

We had a similar problem concerning the WAN links and departmental differences. I didn't want to distribute app-A from site-A if user-A went to work on site-B. (Because this app-A isn't available for site-B users in the first place!)

What we use is a system requirement on app-A that checks if the user's login_context equals the workstation's registration context (HKLM/software/novell/ workstation manager/identification/ registered in). If they don't match, the user isn't working on a workstation from his department (even works for a LAN exceptions)!

You can read registry keys with the REGREAD script command, and you can set system variables with the SET script command.

This way you can keep your APP high in the NDS-tree and associate the complete Organizational Unit (LAN-site) with this application.

There was a small problem concerning the naming format of the workstation context, but with some smart scripting you can solve it in no time.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates