Novell is now a part of Micro Focus

Implementing a Transparent Deployment of Novell Branch Office

Novell Cool Solutions: AppNote
By Gary Childers

Digg This - Slashdot This

Posted: 9 May 2006

Many enterprise network administrators have "satellite" syndrome - in addition to the central enterprise network and data center, with multiple, heterogeneous servers and network services, they also have the small satellite offices, geographically dispersed, but still needing many of the same type of network services that the corporate central office enjoys. The challenge is: How do we supply the needed network services to each of the branch offices, without spending "an arm and a leg"?

Some of these network services are best supplied centrally. Application services usually fall into this category. It is usually impractical to install mini "islands" of application servers to each branch site, especially when they all would need to share a common database. Most network applications also work best in a LAN environment, which often restricts them to the central office network.

Sometimes terminal services, usually via Windows Remote Desktop or Citrix ICA, can bring the centrally located application out to the remote user. Many newer versions of applications may also be Web-enabled, allowing remote users to access them from anywhere on the Internet.

Some network services, however, are best supplied locally. DHCP, and network file and print services typically fall into this category. You wouldn't want to be "dead in the water", unable to access your files or printers, or even unable to get an IP address, every time your WAN link was unavailable. The traditional approach to provide these needed local services has been to install regular (NetWare) servers at each remote site.

This traditional solution carries a certain overhead cost: NetWare servers need to have local replicas of the NDS database, so that users can log on without having to cross WAN links for authentication. The constant need for NDS synchronization also demands the use of more expensive private WAN links. And traditionally, each remote site server has also needed its own data backup solution (tape drive, backup software and tape media) to protect the business-critical information stored at the site.

To address these challenges, Novell developed Nterprise Branch Office, which places standardized, specialized servers at each of an organization's remote sites, paired with a dedicated Central Office server or servers to provide a synchronization of both user accounts and user data. This removes the overhead of needing constant NDS synchronization, with its requirement of dedicated WAN links, and it also replaces the traditional solution of tape backup at the remote sites in favor of data synchronization to the Central Office.

One of the major concerns that customers express when planning to deploy an Nterprise Branch Office (NBO) solution is that they want to have as little end-user training as possible (preferably, none at all). This article address the deployment of NBO servers in a "transparent" fashion - meaning that, if we do our jobs right, the end users may be blissfully unaware that any change at all has taken place on their network.

Default Installations of Nterprise Branch Office

The default installation of NBO is simple enough: you just image the server operating system from the bootable CD, and give the server an IP address when it is finished. Then you can access the Web-based management portal (https:<serverIPaddress>:2222) to configure the server for both user account provisioning (from the Central Office eDirectory to the NBO server eDirectory) and for data replication (from the NBO server to the Central Office server).

A successful implementation of an NBO solution, however, will start with the Central Office server. NetWare 6.5 is definitely preferred, and eDirectory is a must. If you are starting out with a pure NetWare 6.5 and eDirectory environment, this part might be a piece of cake - the only additional component you'll need to install is RSYNC on the Central Office server for data replication. But if you have an older, even upgraded eDirectory environment, you may have some additional steps to prepare the Central Office (see Prepare the Central Office, or the NBO Documentation).

Each NBO server lives in its own miniature eDirectory tree, and is (usually) configured to synchronize user accounts with a specific, geographically-oriented container (OU) within the Central Office or corporate eDirectory tree. LDAP is the protocol used for this user synchronization between trees. The "automatic user provisioning" means that when a user logs in for the first time on the NBO server, his or her user account will be automatically reproduced in the NBO server tree, the password synchronized, and even a home directory created for the user.

The User Login Experience

The user can connect to the NBO server using the NetWare client (NCP), a Windows client (CIFS), a Unix/Linux client (NFS), Macintosh (AFP), or even a Web browser (HTTP/HTTPS). (Note: NCP and Web access methods are enabled by default; the other access protocols need to be individually enabled and configured, if so desired.)

A default installation of NBO may require the end user to initially log into the NBO server using a Web browser (http:<serverIPaddress>), simply to trigger the initial user and password synchronization to occur between the NBO server and the Central Office tree. In a pure NetWare 6.5 and eDirectory Central Office environment, this may not be an issue at all, but in a mixed Central Office tree, we need to be sure that Universal passwords are enabled for the user accounts that are to be synchronized.

If you find that users can not initially be auto-provisioned by directly logging into the NBO server with the Novell client, you may have to perform these configuration changes on the Central Office tree:

Enable Simple Password Settings for NBO Users in the Central Office Tree:

  • - On a workstation logged into the Central Office tree as an admin, open ConsoleOne
  • - In ConsoleOne, browse to the container object for the replicated users in the Central Office tree (e.g.: Sales.Albany.ACME), and select Properties. Open the NDS Rights tab.
  • - Select the container object from the Assigned Trustees list, then click Assigned Rights.
  • - Click Add Property, and select the SAS:Login Configuration attribute, then click OK.
  • - Click Add Property, and select the SAS:Login Configuration Key attribute, then click OK.
  • - Check the Write, Add Self, and Inheritable check boxes for the SAS:Login Configuration and SAS:Login Configuration Key attributes. Click OK.
  • - Create test user accounts in the users' Central Office Tree container, and then login to the NBO server with each user account directly, using the Novell client. Test the LDAP synchronization by resetting the password for the test users in the Central Office Tree container, and verify that the change successfully propagates to the NBO server by logging into the NBO server again as those test users. You should be prompted that the password had expired, and be able to reset it during login.

If you experience difficulties in getting passwords to synchronize between the NBO tree and the Central Office tree, you may need to consult TID10096650. Also, The client workstation should have the latest Novell client installed with the NMAS option enabled for changing passwords in an NBO 2.0 tree.

The User Printing Environment

If your Nterprise Branch Office deployment is replacing a traditional NetWare server and NDPS printing environment, you may find yourself wishing you still had the good old NDPS feature of automatically provisioning printers according to group memberships. Have no fear - the feature isn't gone, it's just hidden under the covers.

The default method of providing network print services for NBO is by installing the IPP client to all of the workstations, and the users then have to use the Virtual Office Web portal to self-provision their network printers. But if you want to retain the NDPS auto-provisioning method, you just need (as before) the NDPS component which is installed with the Novell client.

The NBO Web management portal doesn't currently have the functionality for managing (auto-provisioning) NDPS printers, as was in NWAdmin or is now in iManager, although it does include a simple GUI for installing printer drivers to the NBO server. NBO servers do not run iManager by default, and don't provide easy access to NWAdmin, either.

Thus I prefer to copy the Central Office server's SYS:\Public\Win32 folder to my workstation to access NWAdmin locally, enabling me to run it after logging on to the NBO server (as supervisor) with the Novell client. This gives me the traditional "NDPS Remote Printer Management" tab on user and group objects, so that I can assign and auto-provision network printers to my heart's content.

Mapping Drives to Other Servers

One of the benefits of the "monolithic" tree design of the traditional NetWare environment, that becomes lost when converting to the Nterprise Branch Office model, is the ability to map drives to other NetWare servers in the corporate tree, directly and transparently. But now, since the NBO server lives in its own little "mini-tree", how do we go about mapping drives to servers in the corporate tree?

This may not be a big issue in some network environments - branch office users may be limited by design to only accessing network resources at their own site. But some environments require the branch office users to access, perhaps through a drive mapping, network resources at the Central Office, as well as on their local server.

Individual, end-user persistent desktop drive mappings are a clumsy way to resolve this issue, and they typically bring up a secondary login dialog to authenticate to the second NDS tree. A better way, since the NBO users accounts are already synchronized with Central Office tree user accounts, is to utilize the NetWare TREE login script command in the NBO server's login script to transparently authenticate and map drives to the Central Office servers. See "The Two Trees" for more on this concept.

DHCP Options

An essential network service provided by Nterprise Branch Office servers is DHCP, to provide all of the site's workstations with dynamic IP addresses. The DHCP service on NBO servers is identical to that provided by NetWare 6.5 servers (remember, NBO 2.0 is simply NetWare 6.5 under the covers). However, while the GUI interface of the NBO Web management portal makes it quite easy to setup the basic DHCP subnet, dynamic subnet address ranges, and address exclusions, it doesn't go much beyond that.

For some network environments, the DHCP "Other Options" that are accessible in the Java-based DNS/DHCP Management Console are essential to network operations. If you find that you need these additional DHCP options from an NBO server, again, have no fear, they are still there, albeit hidden again under the covers.

The Java-based DNS/DHCP Management Console is always run from a workstation. If you should need to install it, you should easily find it at SYS:\Public\DNSDHCP on the Central Office server. In order to run it, login to the NBO server's tree (as supervisor), and then run the DNS/DHCP Console against that tree. Then you will see that all of the DHCP "Other Options" are alive and well, and can be configured for your environment.

Branch Office Server Login Script

If your goal is to make the replacement of a traditional NetWare server with an NBO server as transparent as possible to the end users, then you will want the new (NBO) server's login script to mirror, as much as possible, the container login script that was used before. For the most part, this merely means creating similar directories on the NBO server as were used on the previous server, and creating corresponding MAP commands in the NBO login script to present the users with the same drive letters upon login.

On the NBO server, the SYS: volume is never intended for end-user drive mappings, so avoid that (it's not a good idea on traditional NetWare servers, either). The SYS: volume on the NBO is pretty much unavailable, anyway, when the server is in its normal "locked" mode. The ADMIN: volume, also, is designed for server-specific functions, so we don't want to put user data there, either. This only leaves us with the DATA: volume - that's where to put all the end-user's data.

When migrating data from a traditional NetWare server to an NBO server, one peculiarity might catch you off-guard, so I'll forewarn you: you might assume that the proper place for the users' home folders would be in DATA:\Users, which is already created by default. If all of your users were local-only user accounts, not synchronized with user accounts in the Central Office tree, then this assumption would be correct (for example, the Supervisor account's home directory is in DATA:\Users). But for auto-provisioned (replicated) user accounts, the home directories are created in DATA:\Users\remote - signifying that the original user account is in a remote (Central Office) directory.

This can be a tad confusing on the first go-around, especially if you migrated all of the user home folders to DATA:\Users, and then the users log in and don't see any of their data. But upon auto-provisioning each user account on the NBO server (which occurs when they first log in), the %HOME_DIRECTORY attribute is automatically set to DATA:\Users\remote\<UserName>. Thus if you pre-populate the users' home folders in the DATA:\Users\remote folder during the data migration, then they should see all of their data when they first log in.

The default login script for the NBO server (which is actually the container script for the remote.appusers in the local eDirectory tree) looks like this:


This simply gets you started with a home directory and shared drive mapping. Most admins may wish to have a more traditional-looking login script, to mirror what the users are accustomed to seeing when they logged into the traditional NetWare server:

WRITE "You are logging into the %FILE_SERVER Branch Office Server."

IF MEMBER OF ".<groupname>_<OU>_<Org>.APPUSERS" THEN
  MAP root G:= %FILE_SERVER\DATA:\GROUP\<groupname>

IF MEMBER OF ".<othergroup>_<OU>_<Org>.APPUSERS" THEN
  MAP root G:= %FILE_SERVER\DATA:\GROUP\<othergroup>

MAP root S:= %FILE_SERVER\DATA:\Shared


Notice that the groups to which users belong to in the corporate (Central Office) tree are also automatically replicated to the NBO server's tree, and created in the local "Appusers" container. They also have appended to them the full context of their counterparts in the Central Office tree, with underscores ("_") serving to separate the container names. Thus "SalesGroup.Albany.ACME" in the corporate tree becomes "SalesGroup_Albany_ACME.APPUSERS" in the NBO tree.

A tad bit confusing at first, I'll grant you. But what this does is automatically replicates all of the groups to which a user belongs to in the corporate tree, so that if there are drive mappings or access rights assigned to those groups, they can also provided (using these replicated groupnames) for the replicated users on the NBO server. Just remember that the replicated users are placed in the "remote.appusers" container on the NBO server's tree, and the replicated groups are placed in "appusers", with the Central Office's context automatically appended, to signify where they came from.

With the sample login script above, end users who were used to seeing drive mappings for particular shared group drives, with particular drive letters (G:, I:, and S:, in this case), can end up seeing the exact same thing, when they are migrated over to the NBO server.

NOTE: There is one little glitch you might see if you use the NBO Web management portal to edit the login script. Each time you edit the script, it ends up placing two "carriage returns" for every one that you've entered, so that when you save and then re-open the script, you see extra spaces between each line. This is merely a cosmetic error, but some admins prefer to use ConsoleOne or NWAdmin to modify the NBO server login script, if only to avoid seeing the unwanted extra spaces.

One more thing: if you should want to login as the Supervisor account using the Novell client, and wish to run a login script, remember that the Supervisor user is a local account (non-replicated), and therefore its user account resides in the "Appusers" container. To provide automatic drive mappings for the Supervisor account, edit the "Appusers" container login script, to be something like:

MAP root S:= %FILE_SERVER\DATA:\Shared


If you wanted to create any other local (non-replicated) user account for any special purposes, you would want to also place them in the "Appusers" container along with the Supervisor.

NOTE: A word of caution: If you elect to use ConsoleOne or NWAdmin to perform any type of eDirectory management on an NBO server, you will notice that you can see many NDS objects, particularly in the "APPS" container (O=APPS), that are normally "hidden" from you in the NBO Web Management portal. For the most part, leave them alone - don't "mess" with them. Especially, don't attempt to change the Admin user password, since if you do, you will likely have to reinstall the NBO server. This is precisely why the Supervisor account (in the "Appusers" container) is provided.

Data Migration to the Nterprise Branch Office Server

Any time you have to migrate from one server to another, even if it is for identical NOS platforms to upgrade just the hardware, then the migration of the data is an important issue. Normally, just a raw copy of files is not good enough - we usually want to retain some of the "metadata" as well - the extended NetWare attributes, file ownerships, and trustee rights for the files and folders.

If the original server performed a very simple function, like merely serving home directories and a single shared folder, then this task is easy. We might just as easily copy all of the raw data to the NBO server, and manually specify the trustee rights for user home directories and for the shared folder.

However, if there is a large number of user home directories on the old server, or if there is a very complex arrangement of trustee rights assigned to groups and individual users, then we have a bit more of a challenge facing us. The "NetWare Copy" feature built into the Novell client is useful in retaining NetWare attributes for files copied within a single tree, but is of no avail when copying files to a different tree. Similarly, any tape backup and restore solution, which preserves the NetWare extended attributes, will be useless for migrating files into a new tree.

Here is one manual method that can be quite effective: File and folder attributes can be captured on the old NetWare server to a text file, using TRUSTEE.NLM. Then the text file needs to be edited to accommodate the change in environment. Finally, the modified text file can be used with TRUSTEE.NLM on the destination (NBO) server to re-create the NetWare owner and trustee attributes on the migrated files.

For example: if the users' home directories are stored at VOL1:\Users on the old server, you could run the following command on that server to capture the data:


This would produce the text file capturing the trustee assignments and NetWare attributes, with entries such as this:


In order for this text file to be useful on the destination server, which is in a separate eDirectory tree and has a different volume name (DATA:), we need to edit this file, using a search-and-replace feature, to correctly specify the volume and user names that are valid on the NBO server. Since the data volume on the NBO server is named DATA:, and the replicated user home directories are stored in "\users\remote", then all instances of "VOL1:\Users" in this text file should be replaced with "DATA:\users\remote".

The Central Office admin account ("Admin.ACME") should be replaced by the NBO Supervisor account ("[Supervisor]" or "Supervisor.APPUSERS"). All other user names, since they will be replicated from the specified container in the Central Office tree to the NBO server, will remain the same - but the context will now change. Thus all instance of "Albany.ACME" in this example should be replaced with "remote.APPUSERS".

Then our modified trustees.txt file would look like this:


Finally, we could copy the modified trustees.txt file to the new server, once we have copied all of the users' data files to the new server's DATA: volume, and then run this command:


This prompts TRUSTEE.NLM to parse through the text file, and set the trustee and ownership attributes on each file appropriately. This type of manual trustee save-and-restore method is useful for any type of NetWare data migration, or simply to backup the NetWare trustees and attributes of files. The same procedure can be used on a shared folder or volume, as well.

HINT: If you have a large number of files, and are interested in only saving the trustee assignments on the directories, you can use these switches to limit the output:


The "/ET" switch limits the output to trustee entries only, and the "/D" switch limits it to directories only. For more details on TRUSTEE.NLM, see TID2971887.

After saying all this about the use of TRUSTEE.NLM, I need to advise you - you may not have to use it, or you may not have to use it very much. For the user home directories, if you were to simply copy the data in the correct locations for each user (under DATA:\users\remote), and the usernames match the names of the home directories exactly, then the NBO auto-provisioning mechanism will take care of the problem for you.

When the user logs in for the first time to the NBO server, the server uses the configured LDAP connection to verify that the user exists in the specified context, and then authenticates the user from the original user account in the Central Office tree. It then replicates the user account to the NBO server's eDirectory, with the same password, attributes and group memberships, and then automatically creates a home directory for the user in DATA:\users\remote. But if that directory already exists with the exact name as the replicated user, the auto-provisioning mechanism merely assigns trustee rights (SRWCEMFA) to the user for the existing home directory.

If your existing usernames and home directories do not match exactly (such as, JaneJohnson with a home folder JJOHNSON), then you may have to use the manual method with TRUSTEE.NLM. It may also be necessary when you have a complicated trustee rights scheme assigning rights in a shared folder and subfolders to groups or individual users.

Implementing Customized Trustee Assignments

Some admins may feel uncomfortable with allowing end users to have total access rights (SRWCEMFA) to their home directories, since the "A" (Access Control) right allows users to grant other users rights to access their directories. Some company policies also do not allow this, as well. NBO servers use the simple default of full rights for users to their home directories, including the "S" (Supervisor - which assumes all other rights) and the "A". Some admins may wish to change this.

If there is not a large number of users, it could be a simple matter for the admin to manually go through each user home directory, removing the "S" and "A", leaving each user with full access rights (RWCEMF), but no administrative rights. But if there are a large number of users, the utilization of TRUSTEE.NLM, as above, can help the admin to quickly replace each instance of "SRWCEMFA" with "RWCEMF", effectively removing their administrative rights to their home directories.

NOTE: in order for users to use the salvage utility (either from the Novell client or in the NetStorage portal) they must have the "S" (Supervisor) right to a particular directory. Removing the Supervisor right will disable end users from exercising the salvage utility.

Imaging Branch Office Servers Using Configuration Files

If it is your job to deploy a large number of Branch Office servers, the basic imaging process for NBO server OS installation makes it easy to get the server up and running. Just boot to the NBO installation CD, answer yes to the "Are you sure?" question, and let it go. But this only gives you the cookie-cutter operating system, and you still need to configure the server for the particular site where it will function.

In order to pre-configure the NBO server during imaging, we need to use a configuration file (named autoload.nbo) on a settings diskette, which can establish a host of specific server settings before we even login for the first time.

The very first NBO server in your environment will probably be built in a test lab, so that you can gain familiarity with the ins and outs of the product. You will want to go through all the configuration options manually, just to familiarize yourself with what parameters are where, and how to set or change them.

But once you have an NBO server up and running, you can produce a settings disk to get you started with pre-configuring other servers, to make the server build process that much quicker (see "The EASY Way")

The Nterprise Branch Office server configuration file can be downloaded from the Branch Office Web Management Portal, or can be found on the ADMIN volume of the server in the \config directory, as "<servername>.nbo".

Edit the file to use to image a new Branch Office server, specifying the particular server parameters in advance to apply to the new server. Some of the parameters listed here are already the default settings.

To edit the configuration file, open the existing <servername>.nbo file and change the following parameters (use Search and Replace in Notepad or other text editor to find and replace strings):

Replace all instances of the current server name with the new server name.
Replace all instances of the current server IP address with the new server IP address.

Under TAPSettings_Protocols:
If necessary, replace these LDAP settings with those appropriate for your network:

set authsource ldap host1= <LDAP server IP address>
set authsource ldap context=<LDAP context string>
set authsource ldap admin=<LDAP admin name>
set protocol cifs workgroup=<CIFS workgroup name>	(optional)
set protocol cifs comment=<CIFS comment>	(optional)
add protocol cifs share=<CIFS share path>	(optional)

Under TAPSettings_Backup:
If necessary, replace these Replication settings with those appropriate for your network:

set replication enable=yes
set replication address=<Replication serverIPaddress>
set replication port=873
set replication mode=daily
set replication start=21:00		(time of day in 24-hour format)
set replication stop=03:00		(time of day in 24-hour format)
set replication interval=1:00		(time interval in HH:mm format)
set replication verbose=yes		(produce verbose logging of replication jobs)
set replication backup delete=yes
set replication restore delete=no
set replication ssl=yes
set replication backup update=no
set replication restore update=yes
set replication compress=no
clear replication excludedirectory
add replication excludedirectory=DATA:\ZENWORKS\
set replication partial=yes

Under TAPSettings_DHCP:
set dhcp enable=yes
set dhcp ping=yes
clear dhcp subnet
add dhcp subnet=<subnet name>,address=<subnet address>,mask=<subnet mask>,lease=3d 0h 0m 0s
clear dhcp subnet "Default Subnet" range
add dhcp subnet "<subnet name>" range=<servername> DHCP Range,start=<start of DHCP range>,end=<end of DHCP range>,exclude=no
clear dhcp subnet "default subnet" address
add dhcp subnet "<subnet name>" address=<excluded address>,exclude=yes

Under TAPSettings_DNS:
set dns name=<SERVER NAME>
set dns domain=<DNS domain>
clear dns server
add dns server=<DNS serverIPaddress>
add dns server=<DNS serverIPaddress>
add dns server=<DNS serverIPaddress>

Under TAPSettings_Gateway:
set gateway router=no
set gateway rip=no
set defaultgateway=<gateway IP address>

Under TAPSettings_Time:
set time mode=synchronize
clear time synchronize server
add time synchronize server=<NTP serverIPaddress>
add time synchronize server=<NTP serverIPaddress>
add time synchronize server=<NTP serverIPaddress>

Save the resulting file as autoload.nbo. These are by no means all of the parameters contained in the NBO settings file, but they are the ones most likely that you will need to change, to accommodate the specific environment in which your server will operate. Of course, those settings that may be common to all of your servers, such as DNS and NTP servers, will not have to change, once correctly specified in the autoload.nbo file.

When building servers, we are quite used to making all of these settings manually, either during the server installation process or shortly thereafter. Using this settings file in combination with the simple NBO server imaging process just pre-supplies all of these parameters in a text file, so that we don't have to manually enter them at the server console. This saves us time.

As with any type of technology deployment, we should always be mindful to implement anything new to a computing environment in a careful, measured approach. So often we are tempted to exercise the "Nike" method (Just Do It). But when many end users depend upon our successful implementations, then it is far wiser to have more of a "Think, Plan, Do" methodology. This includes staging a proof-of-concept phase (install the product in an isolated lab environment that is similar to your production environment), a pilot phase (limited deployment of the product to select users to test its functionality in the real production environment), and a roll-out phase, when the product is systematically deployed to all of the targeted users.

For many technology deployments, you have to insert training phases, before the pilot, before the roll-out, and during the roll-out, just to reduce the headache of end users having to learn new procedures and concepts with the new product.

Hopefully, if this article serves it purpose, we can reduce the end-user training needs to a bare minimum for deployments of Nterprise Branch Office. As previously stated, if we do our jobs right, the end users may be blissfully unaware that any change at all has taken place on their networks. Now wouldn't that be nice?

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

© Copyright Micro Focus or one of its affiliates