Resources on Demand for Roaming Users

Novell Cool Solutions: Trench
By Koert Poelma

Digg This - Slashdot This

Posted: 2 Dec 1999

Koert spends three days of every week working IT miracles for The Storteboom Group in the Netherlands—the other two days he works in his consulting business. Three years ago, Koert recommended that Storteboom go with Novell and NDS because, and we quote, "The directory is the place to go, and it should be the best one. (Are there any directories other than NDS that work?)" We, of course, agree whole-heartedly with Koert.

A few weeks a ago, you published a tip about using aliases to simplify the task of managing access for mobile users. We have this situation at our company, and I've developed a solution that works very well.

Picture this (and this goes for a lot of you system engineers out there): Mobile users roam from location to location and always need local mappings to the nearest server. With NetWare IPX, this wasn't a problem. All you had to do was test for a network address, implement it in your scripts, and go. But with NetWare 5, this is a different ball game. If a user connects with IP, you can't test on an IPX address, even if it is available.

I gave this a bit of thought, and decided that any solution for this issue needed to maintain the following conditions:

Contextless login must work (great stuff).
IP must be distributed under DHCP.
Minimum installation issues on the portable machines.
Configuration parameters in NDS.
NAL applications (ZENworks) must only show up when applications are available on the local nearest server.
Normal workstations need to run without installation issues.

After investigating the topic in few TIDs, books, and other sources, I came up with the following solution:

For starters...I'll assume that the tree looks something like this:

organization--loc1-user1
--loc2-user2

And I'll assume that the different locations have login scripts and applications.

In addition, this solution assumes that you have met all of the following prerequisites :

Novell 5
ZEN works 2.0 (Upgrade if you're using ZENworks 1.1.)
One tree with locations connected by a WAN.

If you meet all the prerequisites and my assumptions about the tree and locations sound similar to your system, then you're ready to dive in and get started. Here's what you need to do:

On the portable workstations, create location profiles with the location name as variable %2.
Do this for all locations in separate profiles.
Create a login script for every location that contains the following lines:
;login script for location 1
if "%2"="loc2" ;reads variable %2 from the client
include .loc2.organization ;reads the container login script for loc2
exit "" ;do not parse the rest of this
login script or personal script
end
if "%2"="loc3" ;reads variable %2 from the client
include .loc3.organization ;reads the container login script for loc3
exit "" ;do not parse the rest of this
login script or personal script
end
;After all locations are tested, just move on with the rest of the login script
map f:=server1/sys:
etc.

;Login script for location 2
if "%2"="loc1" ;reads variable %2 from the client
include .loc1.organization ;reads the container login script for loc1
exit "" ;do not parse the rest of this
login script or personal script
end
if "%2"="loc3" ;reads variable %2 from the client
include .loc3.organization ;reads the container login script for loc3
exit "" ;do not parse the rest of this
login script or personal script
end
;After all locations are tested, just move on with the rest of the login
script
map f:=server2/sys:
etc.

You can do the distribution using ZENworks.
Enable the location tab on the WIN32 client.
Insert a system requirement per NAL application ENVIRONMENT VARIABLE must contain L=.
(Quick Tip: If Auto Refresh is on in ZENworks, do this in the evening or disable Auto Refresh.)

This can be done in several ways, for example <if file exist> works fine too. If you standardize on drive mappings, you don't need this (for example F: always maps to the local server/sys:).
Make sure all your NDS replicas are where you need them.

That's it. This solution works fine for our company. Everything moves with the user, local mappings work, and system changes can be done centrally by changing the login scripts.

Remarks, Gotchas, and Other Last Minute Thoughts

To smooth the way, here's a roundup of my notes and all the stuff I've discovered implementing this solution. I've included a bit of everything, so be sure to read all the bullets for best results.

If you need a personal login script for home directories on a default server in your network, you can do a GOTO in the login script instead of an EXIT.
In location profiles, it is possible to point directly to the login script of that location. If you use this feature, you need to do more configuring on the portables. Use the best of both worlds in your network.
Another issue came up with applications. If a user is an associate with an application, that application could not be in another location. So they see application objects in the NAL which are not local. Two things can happen:
1. The application won't start (usually)
2. The application starts over a slow WAN line (not nice)
The solution is simple, Test an application with ZEN 2.0 on file exists, use the executable. Applications still show up if they are on different servers but on the same drive mappings.
What happens to normal workstations? The login script tests on all location profiles. If there aren't any, the script continues to the normal mappings etc.
And last but not least, make sure all scripts are available at the different locations in the partitions.