Article

Authors: Devon Brooks and James Wood

Objective:

To implement a solution in which an existing user can travel throughout the enterprise and:

• receive a standard set of applications which function & install from a local server
• receive access to their home folder
• must not negatively affect WAN performance (executing/installing applications)
• must not negatively affect eDirectory performance (searching NAL object properties)

Preface:

Clients will log in using their own eDirectory account, no matter where they physically reside. In other words, when a client roams to a site/building that is not their own, they will change the context accordingly, and log in as if they are at "home". eDirectory alias= are not required.

This roaming user solution applies to both NetWare 6.0 and NetWare 6.5 environments, running ZFD v4.01 IR3 through IR7. It has not been tested on any other version as of this writing.

Implementation:

Implementing all of the following recommendations will completely satisfy the purpose outlined in the objective.

A client can roam (travel) to any site/building in the enterprise, even across WAN links, receive a standard set of NAL-delivered applications, receive access to their home user folder, and NAL application objects will always execute from the server on the local subnet.

As long as MSI's are implemented (as opposed to NAL-snapshot objects), eDirectory performance will not be negatively impacted.

Recommended Modifications:

Refer to the applicable appendixes for complete information on how to implement these modifications, and why they are required in order for the complete scenario to succeed.

1. force out DHCP option number 85 (IP of server on local subnet) - see Appendix A
2. force out NAL object to configure Novell Clients to use DHCP option 85 - see Appendix B
3. make all application objects and novell application launcher settings as identical as possible throughout the enterprise (in terms of application installation, path to files/folders, all MSI=s, etc) - see Appendix C
4. grant the highest level of your tree (usually an organization object) RF rights to the application installation folder(s)/volume(s) on all servers throughout the enterprise - see Appendix D
5. disable "Server:" field and "Servers" browse button from the Advanced Login screen of the Novell Client interface - see Appendix E
6. modify all application launcher configuration settings to "Configure remote access detection method", and modify all application objects to test the availability of the object based on NAL running in remote mode or local mode - see Appendix F
7. modify all container login scripts to map their "application installation/execution" drive letter to %FILE_SERVER\<volume>:, rather than the local, hard-coded server IP or DNS name. %FILE_SERVER is DHCP option number 85 (see "a").

Appendix A

Setting DHCP Option 85 - NDS Servers

When a computer boots and receives the DHCP info from the DHCP server, the "Server:" field in the Advanced Login tab of the Novell Client login screen can be automatically populated. This enables us to provide the IP address of the server that is on the local subnet to the Novell Client, therefore allowing the user to log in and authenticate to the local server for resources.

Upon providing a valid username, password, and tree/context, the Novell Client will perform the following tasks:

1. Connect to the server provided by DHCP (the IP of the server on the local subnet).
2. If the server in #1 does not hold a valid replica, the client will make a second connection to the server configured in the "Default Server" field in the General->Environment tab of the user=s properties in ConsoleOne. This second server connection (if required) will become the default server that the client will contact for eDirectory requests.
3. Proceed as normal with the standard login script process (OU, profile login script, personal login script, etc).

In this configuration, should a user be at a site/building that has a local server, which contains no replica, the user will be connected to the local server box for resources, and also be connected to the default server that is configured in ConsoleOne for eDirectory requests. Likewise, should a user be at a site/building that has a local server, which contains a replica, the user will be connected to the local server for both resources and eDirectory requests.

To configure and enable DHCP Option 85 using Novell DHCP, follow these steps:

1. Open the Novell DNS/DHCP Management Console.
2. Click on "DHCP Service tab".
3. Select the subnet you will be configuring Option 85 for.
4. Click on the "Other DHCP Options" tab.
5. Click the "Modify..." button.
6. Select ANDS Servers, Code 85" from the "Modify DHCP Options" screen, then click the "Add >>" button.
7. On the "Modify DHCP Options" screen, ensure that "NDS Servers" is selected under the "Selected DHCP Options" section, and click on the "Add ..." button.
8. On the "NDS Servers" screen, enter the IP Address of the Novell server at the location in question, then click the "OK" button.

It can also be configured using Microsoft DHCP, or many different types of routers.

Appendix B

Configuring the Novell Client to use DHCP Option 85

When a computer boots and receives the DHCP info from the DHCP server, the "Server:" field in the Advanced Login tab of the Novell Client login screen can be automatically populated.

In Appendix A, it was explained how to force out the IP of the server on the local subnet using DHCP.

The following registry key forces the Novell Client to "see" and "use" that value that DHCP is forcing out:

This registry key is the equivalent of manually performing the following task:

1. In the "Novell Client Configuration" properties (right-click the red "N" in the system tray, left-click AProperties), click the "DHCP" settings tab.
2. Place a check-mark in the "Use Server:" box.
3. Ensure the "from Login Service:" drop-down list is set to "Default".
4. If a pop-up message is displayed, click "Yes" to synchronize remaining login services.
5. Place a check-mark in the "binary data" box.
6. Click OK to save changes.

A NAL object can be easily created to force out this registry change to the enterprise, which requires a reboot to take effect.

Upon reboot, in the Advanced Login tab of the Novell Client, the "Server:" field will be populated by DHCP. The value will be what was configured for this subnet in the DHCP Management Console, as described in Appendix A.

Appendix C

Make all application objects throughout the enterprise as identical as possible

In our environment, all clients receive a set of internal applications delivered to them upon login through NAL, accessible through their Start button.

It is required to make all NAL objects as identical as possible, including:

• Installation paths (<drive>:\app\app.exe)
• Template paths (<drive>:\templates\template folder)
• Application packaging routines (all MSI=s, all NAL=s, etc).

In our environment, we recommend that all applications should be packaged as MSI=s. The use of Novell Snapshot results in slower performance in a WAN infrastructure, due to NAL object properties being stored in eDirectory. When a client roams to another site/building, those see this article.">eDirectory objects are pulled across the WAN if there is no replica on the local resource server.

In our environment, our container login scripts executes NALDESK.EXE (which is installed on the local workstations), which in turn searches eDirectory for all NAL=s that are associated to the user, and then populates the Start button menu as well as Application Explorer.

In this configuration, when a client from Site A travels to Site B and logs into the network, NAL will operate in "Remote Mode", rather than "Local Mode". In other words, NAL "knows" that it is operating in a subnet other than the user=s "home" subnet. Based on this, NAL will search eDirectory and populate the menu with the applicable NAL=s. (See Appendix F for more information on NAL operating modes, and NAL object availability criteria.)

To help explain this process, as an example, if a client from Site A roams to Site B and logs in, the following will occur:

• <drive> is mapped to the application folder(s)/volume of local server in Site B
• NAL is executed, searches eDirectory, and displays applicable NAL objects

When a client executes a NAL object, which is configured to install/run an application from <drive>, the application will install from the local server available on the subnet, rather than across the WAN. Even though the NAL objects search eDirectory across the WAN to initially discover and then display the objects, once NAL is populated, the NAL execution itself is performed locally.

For example, you may have NOTEPAD.EXE copied to all of your servers, and a NAL object to execute it. No matter what container a user is from, no matter where this client travels and then logs into the network from, the "Notepad" NAL object will always execute from the local <drive> on the local server, rather than across the WAN.

Appendix D

Grant the highest object in your tree (usually an organization object) RF rights to the application installation folder(s)/volume(s) on all servers

The IP address of the server on the local subnet is determined by DHCP (see Appendix A). Once the Novell Client is configured to "use" this DHCP value (see Appendix B), container login scripts can be configured to map the applicable <drive> to the application installation folder(s)/volume(s) of the local server (see Page 1, "Modifications:", section (g)).

Typically, a client will only have RF rights to the volumes on the server that is local to them, in order to facilitate application installation/execution.

In this configuration, a client can theoretically roam to any location in the enterprise. As explained in Appendix C, NAL objects are configured to execute/install from the local server. It is therefore required that all clients have the ability to "see" the local application installation folder(s)/volume(s) on every server.

As such, we grant RF rights to the highest object in the tree (usually an organization object) to all application installation folder(s)/volume(s) on every server in the enterprise.

Appendix E

Disable "Server:" field and "Servers" button on the Advanced Login tab of the Novell Client login interface

In Appendix A, it was outlined how DHCP can force out option 85, which is the IP address of the server that is on the local subnet (site/building).

In Appendix B, it was outlined how the Novell Client can be configured to "see" this value that DHCP is forcing out. In other words, when the Advanced Login tab of the Novell Client login interface is selected, the IP address of the local server will automatically be configured in the "Server:" field.

On Page 1, under "Modifications:", section (g) explains that all login scripts must be modified to map the applicable drive letter, <drive>, to %FILE_SERVER\<volume>:, rather than the local server=s DNS or IP name. This variable is DHCP Option #85 (see Appendix A).

Using this configuration, where the login scripts map to %FILE_SERVER\<volume>:, it is required that we do not allow the user to change the server in the Advanced Login tab of the Novell Client.

When user roams from Site A to Site B, the computer at Site B will have the IP of the local server in Site B automatically configured in the Advanced Login. Should the user change that value back to the IP (or DNS name) of their server in Site A, the login script would map <drive> to a server that is not on the local subnet. As a result, applications would be processed over the WAN rather than locally, thus ruining the configuration.

With this in mind, we have to disable the "Server:" field and the "Servers" browse button from the Advanced Login tab of the Novell Client login interface. The following two registry keys can accomplish this:

A NAL object can be easily created to force out these registry changes to the enterprise, which does not require a reboot to take effect. This change will "grey out" the "Server:" field and the "Servers" button, which will prevent the user from changing their server.

Appendix F

Configure NAL to detect "local" or "remote" operating mode, and subsequently configure the availability of all NAL objects to be displayed based on this operating mode

NAL can detect if it is running in a "local" or "remote" mode. To configure, follow these steps:

1. In ConsoleOne, right-click the container that has the user objects you want to configure this for (usually a site or building container), and left-click "Properties".
2. Choose the "Zenworks" -> "Launcher Configuration" tab.
3. There is an option called "Configure Remote Access Detection Method". Unless this option has previously been configured, click "Add" to open the "Launcher Configuration" window. (If this open has been configured previously, you do not need to click the "Add" button, but rather can find it in this window=s list.)
4. On the "User" tab, scroll down and select "Configure Remote Access Detection Method".
5. On the right-hand side, configure the "Values:" to "Detect Using Network ID".
6. Under "Detect Using Network ID", set the value of the four empty boxes to the Network ID of the local subnet/container. Refer to the help section of ConsoleOne to determine the Network ID of the local subnet (a process that involves the AND=ing process).
7. Set the "Local if users Network ID is:" to "Equal to this Network ID".
8. Ensure "Use as top of configuration tree" has a checkmark beside it.

The Network ID is set on each workstation when it boots and receives it=s DHCP info.

When NAL is executed via the login script, NAL searches eDirectory based on the configuration specified in this page. If the Network ID of the workstation that is logging in does not equal the Network ID configured here, NAL will be running in "Remote" mode. Likewise, if the Network ID of the workstation that is logging in equals the Network ID configured here, NAL will be running in "Local" mode.

In other words, when a client logs into a workstation that is not on the local subnet, NAL compares the network ID, sees that the client is not logging in from their "home" site/building, and will run in "Remote" mode.

Subsequently, NAL objects can be configured to hide or display based on this criteria.

In our network environment, there are more NAL objects available at a larger sites than at a smaller sites. As such, we want to "hide" the extra NAL objects that a client has at their home (larger) site while they are logged in at a smaller site. (If we do not do this, a NAL that is available at their "home" OU but not their "roaming" OU will not function correctly, so therefore we want to hide it to avoid problems.)

To configure this, follow these steps:

• In ConsoleOne, open the properties of a NAL object.
• Choose the "Availability" tab, click "Add", then click "Remote Access".
• In the pop-up window that displays, set "Show application icon even if criteria are not met:" is set to False.
• Set "Remote Access Connection Method is:" to "LAN Connection".

"LAN Connection" is another term for when NAL is operating in "Local" mode, while "Remote Access Connection" is when NAL is operating in "Remote" mode.

Configuring this availability tab in this way, we are saying, in technical terms, that if NAL is operating in "Local" mode, this object will be displayed. If NAL is operating in "Remote" mode, this object will not be displayed.

In other words, display this application if the client (and NAL) is logging in from their "home" subnet/container.

As an example, a "Notepad" NAL object is an application that is available at our large sites, but not at our smaller sites. When a client roams from a large site to a smaller site, the menu & NAL=s that are displayed upon login are from the client=s large site, and we therefore do not want the Notepad NAL to be displayed, since there is no corresponding file/folder structure on the application installation folder(s)/volume(s) on the local resource server.