A ZENworks-Friendly Location Independence Strategy for NetWare Networks
Articles and Tips: article
Consultant
Novell Consulting, Asia Pacific Region
01 Oct 1998
Here's a way to give your users the same desktop configuration and applications wherever they log in, without having to transmit everything over WAN links.
- Introduction
- Overview of the Problem
- Nuts and Bolts of the Solution
- Other Possibilities to Try
- Summary
Introduction
Novell Directory Services (NDS) provides the ability for users to log in to the network from any location using their distinguished name either explicitly entered or provided in concert with the client context setting. This fundamental service provided by NDS works whether a copy of the User object is present in a replica on a local server or not. Users are thus ensured connections to all the resources they are associated with, including drive mappings used to access network utilities and applications software.
Regardless of where users physically connect to the network, they get mappings to their home environment as if they were physically there. However, physical entities such as files have to reside somewhere on disk. This provides some challenges for applications when a more practical source for files (such as a local server) may be close at hand, only to be ignored by the login process.
The effects of this phenomenon have been further amplified with the introduction of Application objects entered into NDS with the Novell Application Launcher (NAL) component of Novell's ZENworks product. Among other things, Application objects contain information concerning the location of files necessary to distribute and launch applications from the network. In networks with remote locations, administrators want to avoid as much as possible the transferring of application files across slow or expensive WAN links.
This AppNote describes a strategy that works in concert with ZENworks and NAL to allow users to log in from any location within the organisation and receive the files they need from the most appropriate server.
For more information on application distribution using ZENworks and NAL, see "Using ZENworks to Distribute and Manage Applications on a Network" in this issue, and "A Practical Guide to Using Novell Application Launcher (NAL) 2.01" in the January 1998 issue of Novell AppNotes.
Since this AppNote was written in Australia, it retains the original British spelling used by the author.
Overview of the Problem
Traditionally, networks that use NAL are set up to deliver application files in one of two ways:
Simply allow users to access applications from their home container regardless of where they are physically located. This has the undesirable effect of applications being distributed or launched via NAL across LAN or WAN boundaries, which is slow and consumes network bandwidth.
Provide users with a selection of duplicate Application objects that represent different execution paths for each physical location. For example, to deliver Microsoft Word at three service sites, three Application objects would be created: MSWord_SiteA, MSWord_SiteB, and MSWord_SiteC. The success of this method relies partly on users selecting the correct object. It also requires tremendous duplication and administration in maintaining many more Application objects than would otherwise be necessary.
In both cases, NAL-related paths are typically specified using the Universal Naming Convention (UNC), which includes the server name as part of the path. For example:
\\Svr\Volume\Dir
While UNC paths work well in many situations, they are by nature location specific. As a result, they are not appropriate for use in a location independence scenario.
The location independence strategy detailed here involves setting all NAL-related paths to logical drive pointers instead of UNC paths. For example, as long as drive X is mapped to a standard applications directory that exists on a nearby server, you can specify the location of an application's executable file as follows:
X:\apps\msword\winword.exe
What we are doing here is attempting to virtualise the connection to resources by mapping drive pointers to the nearest physical server that contains the target resources. In such a scenario, it doesn't matter how an Application object is associated with a user (for example, by inheritance) or where its source is. The target object may be accessed from a local replica of NDS containing the Application object, or the resolution may require tree walking across WAN boundaries. The focus here is what happens after the object's attributes are read and the application is to be executed. If the execution path includes a logical drive pointer, we have an opportunity to load any files we choose--as long as we map the referenced drive pointer correctly at login time.
The key idea that forms the basis of our location independence strategy is to separate referencing an Application object (reading its attributes such as the target execution path) and the actual accessing of the required files, which can be redirected by means of drive mappings. Although resource access is always controlled by NDS rights and file system rights, it is possible to use an Application object in your home container to launch an application from a server that is close to where you are physically located, thus avoiding the problem of files having to be copied or executed across the WAN.
Nuts and Bolts of the Solution
Many organisations that use IPX within local networks (if not across the WAN where IP has become popular) use a technique known as segmentation to divide the larger network into multiple physical networks. Each of these segments is assigned a unique IPX address which identifies the physical network in a given location. This forms the basis of our location independence solution, as the IPX address can be used to "locate" users within the physical network infrastructure. In other words, the IPX address can help pinpoint the actual geographic location or "locale" from which a user is logging in. Once the locale is determined, one or more suitable target servers can be configured from which the user can access resources.
This solution requires the following preparations:
You'll need to put together a list of segment addresses and which servers you want users to access when logging in on each physical networks. This configured list can be included in or referenced from a login script to provide the location determination and resource mapping logic.
You'll need to place a uniform call to the location determination logic in all container login scripts.
Application files will need to be replicated on all servers included on the configured list. These files include SYS:PUBLIC files used by workstations, application files referenced by NAL and hosted by the server volumes, and application deployment files (.AOT and .FIL files used in NAL distributions)
You'll need a way to grant "visiting" users access (Read and File Scan file system rights) to the local application files listed above.
Preparing the Configured List
At present, the best approach for preparing the configured list is to make use of the %NETWORK_ADDRESS login script variable. When the NetWare Client software encounters this variable in a login script, it returns the IPX address of the physical network segment to which the workstation is attached. This is the most reliable method to be sure of where the user is before proceeding to determine the most appropriate server to deliver the replicated resources.
%FILE_SERVER is another variable available to the client software at login time. This variable provides the name of the first server to respond, which may give you a hint as to where the user physically is or which is the most appropriate server to access. This cannot be guarranteed to return a server that contains the application files needed. For example, %FILE_SERVER may return the name of a local (or not so local) infrastructure server used for GroupWise, DNS or DHCP services.
Once you have the physical network address of a workstation, you can fill in environment variables to identify the following information about the particular workstation:
The location the workstation is in (as identified by the LOCALE variable)
The most appropriate server to access (as identified by the ZENSVR variable)
The name of a registry import script (as identified by the LOCREG variable) to configure things like local print queues and location workstation contexts.
Note: While this example uses IPX, an IP solution could also be prepared using the IP address to determine the physical location. Address ranges would have to be localised to replace the role played here by the %NETWORK_ADDRESS variable.
Example Location Script. The example login script shown below assumes a simple network with two physical sites (Sydney and Melbourne) and four physical network segments (three in Sydney and one in Melbourne), as illustrated in Figure 1.
Figure 1: Network configuration for the location independence example.
Notice the use of the %NETWORK_ADDRESS variable within the IF...THEN statements for each segment address. A catch-all section is provided in case a connection is made from a network segment not configured here.
;******************************************************
; LOCALE.INC – Location Script for Novell Networks
;
; Supplementary login script logic used to identify the physical network
; the workstation has connected to for efficient resource mapping.
;******************************************************
; Change control
; ==============
; 01/07/98 TBF * Initial configuration & distribution
; 12/07/98 TBF * Added new segment for SE Lab, redistributed to all servers
;******************************************************
; *** initialise environment variables
SET LOCALE =
SET ZENSVR =
SET LOCREG =
;
; *** Configure the network segments and make the appropriate
; *** assignments to the variables initialised above.
IF NETWORK_ADDRESS = "01015499" THEN BEGIN
SET LOCALE = "Sydney Location 1"
SET ZENSVR = "SYD-APPSVR01"
SET LOCREG = "01015499.reg"
GOTO COMMON
END
IF NETWORK_ADDRESS = "01321012" THEN BEGIN
SET LOCALE = "Sydney Location 2"
SET ZENSVR = "SYD-APPSVR02"
SET LOCREG = "01321012.reg"
GOTO COMMON
END
IF NETWORK_ADDRESS = "00000001" THEN BEGIN
SET LOCALE = "SE Test Lab"
SET ZENSVR = "SYD-APPTEST01"
SET LOCREG = "00000001.reg"
GOTO COMMON
END
IF NETWORK_ADDRESS = "01563092" THEN BEGIN
SET LOCALE = "Melbourne"
SET ZENSVR = "MEL-APPSVR01"
SET LOCREG = "01563092.reg"
GOTO COMMON
END
;
;*** Catch-all set of commands which execute if a segment
;*** is not specifically listed above.
SET LOCALE = "Unknown location"
SET ZENSVR = "%FILE_SERVER"
;
;*** Generic commands to display the results in the script window
;
COMMON:
WRITE "SUBNET : %NETWORK_ADDRESS"
WRITE "LOCALE : %<LOCALE<"<
WRITE "ZENSVR : %<ZENSVR<"<
WRITE "LOCREG : %<LOCREG<"<
;************* End of file *****************
How to Call It?
This logic now has to be included somehow in the login script execution process. This could be achieved by simply copying it into each container login script. However, this has significant administration disadvantages as each container script only serves a single container of users. Similarly, any updates would have to be made to every script that contained the code.
A better method is to reference the code using the INCLUDE statement and read it from an alternate repository. The syntax for doing this in the login script is simple:
INCLUDE <name of repository<
The repository can be another container script, a profile script, or an external file. The method you choose will depend on a number of factors. Obviously, the information must be updated as network segments are added or deleted. This should be considered as you weigh the pros and cons of the three options.
Option 1: Referencing Another Container Login Script. One option when using INCLUDE is to reference another container login script; for example, that of a parent container.
Pros - Several container login scripts can access a single set of location code. NDS rights are not normally a problem as the login script attribute has broad visibility by default.
Cons - The container object may be in another NDS partition and the login process therefore necessitates tree walking to locate the referenced container and read its login script attribute. This may adversely affect login speed or fail outright if the WAN is down.
Option 2: Referencing a Profile Login Script. Another option when using INCLUDE is to reference the login script attribute of another NDS object, such as a Profile object.
Pros - This is similar to referencing another container script, but it has the additional advantage of being more easily replicated. For example, you could place the Profile object in a replicated RESOURCES container along with the Application objects. If the container is replicated locally, this would provide good speed and a degree of immunity from WAN communication problems. Another plus is that NDS handles the replication for you.
Cons - NDS rights to read the Profile object would need to be granted to the users' containers. However, this is a normal part of implementing any replicated container of common resources.
Option 3: Referencing an External Text File. A third option when using INCLUDE is to reference an external text file; for example, LOCALE.INC on the SYS volume.
Pros - This method is easy to set up and configure. Speed is good even if files are large due to a large number of sites (segments). The file can be placed in the SYS:LOGIN directory where even unauthenticated users have read access.
Cons - The text file needs to be redistributed to all servers whenever a new segment is brought into service. (Novell Replication Services could be used to assist with this.)
Example Using Option 3. The example container login script code below uses the method of referencing a replicated file called LOCALE.INC which has been copied into the SYS:LOGIN directory of all file servers. It relies on the following standard drive mappings:
H : Home directory
G : Group directory on the local server
X : ZENWORKS directory on the APPS volume of the local server
Z (S1): SYS:PUBLIC directory of the local server
Note: "Local server" refers to the nearest appropriate server to the user's point of connection as identified by the location script above. The "local server" mappings are still subject to file system rights being granted.
To debug this process, set the client to display the login results window and not close it automatically. This window will display the results of the WRITE statements and show error messages if things are not working as anticipated.
;******************************************************
; Container login script for NC.SYD.ASIAPAC.NOVELL
;******************************************************
; Change control
; ===========
; 01/07/98 TBF * Initial configuration
; 08/07/98 TBF * Modified display statements
;
;======================================
WRITE "Executing script for NC.SYD.ASIAPAC.NOVELL ..."
NO_DEFAULT
MAP DISPLAY OFF
MAP ERRORS OFF
COMSPEC = C:\Windows\COMMAND.COM
SET PROMPT = "$P$G"
WRITE "Good %GREETING_TIME, %FULL_NAME."
WRITE "Your password expires in %PASSWORD_EXPIRES days."
WRITE
; Attempt to read location script from nearest server. If the
; LOCALE variable comes back empty the file was not found
; so display an error message.
;
; The next line shows a container based strategy to reference a
; container login script attribute
; SET LOCSRC = ".ZEN.ORG"
;
; The next line shows a file based strategy to reference a
; file from the nearest server
SET LOCSRC = "%FILE_SERVER/SYS:LOGIN\LOCALE.INC"
WRITE "Reading: %<LOCSRC<"<
INCLUDE %<LOCSRC<<
IF "%<LOCALE<" = "" THEN BEGIN<
; Locale information has not been distributed
WRITE "Bad or missing: %<LOCSRC<"<
END
WRITE ""
; *** Effect drive mappings based on variables
MAP INS S1:=%<ZENSVR</SYS:PUBLIC<
MAP X:=%<ZENSVR</APPS:ZENWORKS<
MAP ROOT G:=%<ZENSVR</USERS:SHARED<
MAP ROOT H:=%HOME_DIRECTORY
;*** Run the location based registry script in silent mode
@REGEDIT /s "SYS:LOGIN\%<LOCREG<" <<
; *** End of file
;******************************************************
Replicating the Application Files
Of course, successfully identifying the user's location and mapping the application's drive pointer to the nearest server containing application files is all for nothing if the required files are not there! A replication scheme for the application files is a fundamental part of the strategy. It is also the source of much of the work and discipline necessary for location independence to be successful.
The application files that need to be replicated include the following:
Files necessary to run any application that is to be run from the local server
Application distribution files used by NAL (including .AOT and associated distribution files saved with the .FIL extension)
In our example, the X drive is mapped to the ZENWORKS directory on the APPS volume of the server identified in LOCALE.INC. The directory structure on each ZENSVR listed in LOCALE.INC is shown in Figure 2.
Figure 2: Standard directory structure on all local servers.
Novell Replication Services (NRS) provides essential functionality in this regard to ensure the application files and other files referenced by NAL are ready for use. Alternatively, manual methods using batch files could be employed to achieve this replication.
Note: Don't forget to replicate the LOCALE.INC file to the LOGIN directories if that method is used. You'll also need to replicate the registry import scripts referenced within to configure local resources such as local print queues via a REGEDIT import script.
Smoothing the Way for NAL
In our example, the NAL Application objects list the executable path as X:\ZENWORKS... to enable users to access the most appropriate files in the current locations. Furthermore, if the distribution settings used for a distribution-style NAL object also reference a drive mapping instead of a UNC path, an application distribution, verification, or automatic repair will occur from the local server regardless of where and how the application object is sourced by NDS. (See also the excellent macro feature for the SOURCE_PATH of NAL objects, which points to where application files are to be copied when a distribution event occurs.)
Other Possibilities to Try
The location independence strategy illustrated above can be adapted in a number of ways to meet the individual needs of various networks. Here are a few other possibilities to consider.
Alternative Solution to a Single Configured List
The main advantage of using a single configured list is there is only one source of logic used in every site. This makes for uniformity and simplicity, but comes at the cost of having to maintain the integrity of the list, keeping it accurate and distributed in a timely fashion. This is not a significant overhead in many organisations, as a select group of people usually controls the creation and configuration of network segments. They are the obvious group to take ownership of maintaining the location independent scripts. Again, products such as NRS can help in the distribution process.
An alternative strategy involves having a small, single-entry locale script with all the same components but different settings at every site. That is, the container login scripts use the INCLUDE statement to reference a file as follows:
INCLUDE %FILE_SERVER\SYS:LOGIN\LOCALE.INC
This works the same as before, except the referenced file contains only the settings for the local site and not an exhaustive list of segment addresses. This has the advantage of being a small file that, once set up, does not have to be maintained or redistributed. The disadvantage comes in managing a library of LOCALE.INC files for every site, location, or segment in the organisation. It also has the disadvantage of being a less robust solution in situations where a foreign server may handle a user's login because the local server is busy.
Hint for Large Sites
In large sites with hundreds or even thousands or segment addresses, the collection of segment addresses and their related information can be divided up into multiple parts and accessed in clusters to reduce the size of the actual collection referenced.
Summary
The location independence strategy discussed in this AppNote provides a means to reference application files (or any replicated files, for that matter) on the basis of "the most appropriate server given the user's location." This strategy works well in most production environments. Although some work is involved in setting up and maintaining the components of any location independence strategy, the end result is much improved service delivery for your users.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.