The Z.E.N. side

Making an easy to refresh machine using GHOST, NT and Z.E.N.works

This Document is a work in progress. It is as accurate as I can make it without people having used the method to create a Lab Machine. If you use this document and you have any comments, both positive and negative, please let me know by mailing me.

This document is in two parts. This is the Z.E.N.works / NAL side of things, there is also an NT side to the story.

This document assumes that you're using the other half of this document. If not, read it so you know what I'm on about, then ignore it when you know better. If I made any mistakes, let me know by mailing me, otherwise I'll just sit here thinking I invented the best thing since sliced fruit bread in the morning.

The art of Z.E.N.

When a user logs in, their login script launches NAL in shell mode (NAL /S) so that when they quit the software, it logs them out, otherwise silly users will quit NAL with no applications and no obvious way of logging out.

The user's access is managed using ZEN policies. I use an NT workstation policy to setup the workstation (more about that later) and an NT user policy to lockup the workstation. The method for distributing these policies is NT Workstation Manager. The software hooks into NT and basically eliminates the need for managing anything within NT (as far as I know :-)

Using the workstation policy, you can create actions that happen when either events occur or when a time interval has happened. I use this method to log the user off when they lock the screen, or when the screen saver is activated (eg they weren't working on the machine) I also make the machines refresh at a set time each day.

Setting all this up is pretty straight forward. There seems to be only one catch. Workstation Manager needs to be initialised. Those six words have meant three months of work. However, I beleive that I have solved the problem. It's not pretty, but it works.

Before I tell you how, I need to tell you why.

The first question you may ask, is: "Onno, why don't you just make the image after workstation manager is initialised?". Because the workstation needs to be visible in the NDS tree, it needs to be unique (its own settings), thus the image that you so lovingly created needs to be tailored to each machine, no good.

The next question is: "Onno, why do you need workstation manager?". Because workstation manager and the novell schedular are the devices that run the actions that log the user off when they should be.

Then: "Onno, why don't you just lock the machines up tight as a drum and be done with it?". Because students will switch machines off mid-flight and kill any integrity NT hasn't already killed itself.

Then: "Onno, why don't you just ghost the machines off the net?". Because that works fine with 5 machines, but not with 500.

If you have more questions, ask me and I'll try to answer.

Ok, so now to the Workstation Manager initialisation. I have found that the only way to initialise the software is to login and logoff again. If you do it the official way it goes like this:

1. login
2. Workstation Manager initialises and places a cookie in the NDS tree, requesting a workstation to be registered into the tree
3. logoff
4. Launch NWAdmin on another machine and import the workstation
5. login
6. Workstation Manger locates its object in the tree and gets the actions associated with it
7. logoff
8. login
9. Workstation Manager initialises the actions and they become active
10. All Done...

You can tell this is pretty tedious. So I did it this way:

1. login
2. run NAL with registry settings to tell Workstation Manager where in the tree it is
3. Workstation Manger locates its object in the tree and gets the actions associated with it
4. A batch-file detects using the file C:\WS1STGO.ZEN that this is the first user to login and promptly logs them out.
5. logoff
6. login
7. Workstation Manager initialises the actions and they become active
8. All Done...

I told you it wasn't pretty.

There are a few things that need to be done in order for this to work.

1. The workstation must be in the tree. No big deal, the workstation gets registered by you when you create the lab the first time.
2. The workstation must have a name that you can incorporate into a NAL object. As far as I know it needs to be unique. (I am currently thinking about and investigating if this is really true. If not, then although I don't expect you can remote control the machine, you will be able to incorporate the workstation manager registry settings and actions into your image, thus eliminating the need for the logout/login.)
3. I digress, we were talking about a NAL object. It needs to be in NAL because otherwise each workstation image needs to be different. The only variable that I have found that Workstation Manager and NAL have in common is the IPX address. In NAL it's called %NETWORK_ADDRESS%. So you modify the registry setting in NAL to use this as the computer name. I suggest you pre-pend (as opposed to append) the name of the lab to the address, eg "ABACUS_%NETWORK_ADDRESS%"
4. You need the magic logout batch file

1. You'll notice a distinct lack of detail here, that's because the document is all of 15 minutes old.
2. Create a Search Policy
3. Create a User Policy
4. Create a Workstation Policy
5. Create the magic logoff batch file
6. Create Screen Saver log-off actions
7. Create Lock Screen log-off actions
8. Create Refresh action
9. Create NAL object to activate workstation
10. Copy associated files.

Modifications to this document:

7 July 1998 - Created the documentation for the ZEN side of things

1. [Top] Getting Started