AppNote: The Two Trees - Simultaneously Accessing Nterprise Branch Office Servers and the Corporate Tree
Novell Cool Solutions: AppNote
By Gary Childers
Digg This -
Updated: 22 Jun 2005
A lot of folks are trying out Novell's Nterprise Branch Office (NBO) product, in order to realize the savings on hardware and administrative costs, and are finding that the hardest part is the transition period between using traditional NetWare servers, and using the Branch Office servers.
The Two Trees
There is certainly a transition necessary in upgrading the corporate (Central Office) NDS tree, enabling Universal passwords, and all that, to prepare for the auto-provisioning of users at the Branch Offices. There is also a bit of a learning curve for the admin to understand how LDAP authentication happens between each Branch Office server tree and the corporate NDS tree. But often what many admins also find challenging is providing for the different ways that users do their work, while making the transition from traditional NetWare to NBO servers. There is precious little documentation on that subject, probably because each organization often uses their network resources in different ways, making it hard to document every possible use case. This article seeks to help with that.
One assumption we often make in regard to branch offices is that the branch site users merely get DHCP addresses, store data files, access network printers, and perhaps even get email from the branch office network server. If that is true for 100% of the branch office users, then deploying Nterprise Branch Office might be a snap (once the Central Office tree is properly prepared). Users were previously logging into the corporate tree, but accessing all network resources from their local NetWare server. Now they just login to their local (synchronized) Branch Office tree, and access the same network resources from the Branch Office server.
But there is usually the 5% - 10% of users who don't fit the mold, or the one (critical) application that is the exception, that seems to throw in the monkey wrench for us.
Let's give an example: users at Branch1 access DHCP, file and print from a traditional NetWare server, and we propose to replace that with an NBO server. That's simple enough - we image the NBO server, configure it for the IP LAN, the DHCP subnet, and configure the LDAP authentication for the appropriate context in the corporate NDS tree. We then migrate the users' data to the NBO server, update their NetWare clients to login to the new NBO tree, and configure the NBO server login script to give them the same drive mappings as they had previously. If all goes according to plan, the users aren't really aware that the server was upgraded - everything works (for them) just as it had before.
But then come the exceptions. UserA is special, and she has to map a drive to a remote NetWare server in the corporate tree, as well as mapping the standard drives on the local NBO server. Or in some cases, all the users have to temporarily map a drive in the login script to a central NetWare server in the corporate tree (perhaps to update antivirus signatures). What to do?
The TREE Command
TREE command to the rescue. The TREE command is a NetWare login script command that changes the focus of any subsequent script commands to reference the specified tree. This allows us to perform the needed drive mappings to the NBO server, then execute the TREE command, and then start mapping drives to servers in the specified separate NDS tree.
Nterprise Branch Office (2.0) is, after all, NetWare 6.5 under the covers (version 3.0 however will be based on a Linux kernel). The Branch Office server sits in its own little eDirectory tree, and has the same type of users, groups and login scripts as regular NetWare (NDS). Although the NBO users are auto-provisioned and synchronized (using LDAP) with corresponding users in the corporate NDS tree - that's the biggest difference - mostly the NBO server works just like NetWare does.
So the TREE command can be placed in the NBO server's login script (which is always the remote.APPUSERS container), and redirect our drive mapping commands to servers in the corporate NDS tree. For the exception user, who needs to map a special drive to a remote server, the authentication will occur on the user account that resides in the corporate tree (which is synchronized with the NBO user account).
Example - Using Synchronized User Accounts
Here's an example: back to UserA above, who wants to map the standard drives to the local NBO server, but also map a special drive to a server in the corporate tree. The login script in the NBO tree (in remote.APPUSERS) would look something like this:
MAP root H:= %HOME_DIRECTORY
MAP root I:= %FILE_SERVER\DATA:\APPS
MAP root S:= %FILE_SERVER\DATA:\Shared
IF MEMBER OF ".SPECIAL.APPUSERS" THEN
MAP root J:= \\SERVER6\DATA\Special
This script maps H, I and S to the users home folder, APPS and SHARED folders, respectively, on the NBO server. Then, if the user is a member of the "SPECIAL" group, it changes the focus to the corporate NDS tree, and maps a drive to the server there. Of course, this presumes that you have already created a group in the APPUSERS container on the NBO server called SPECIAL, and added the user to that group.
The TREE command here uses an IP address of a server in the corporate tree (ideally the Central Office server) as a reference to the corporate NDS tree, since it has no SLP name resolution to that tree. The map command then maps a drive to the server in the corporate tree. The second TREE command returns the focus back to the NBO tree, in case you have any other drive mappings to make - now we are looking at the local NBO server's tree again. The NO_DEFAULT command is the standard ending command so that the client does not process the default login script.
The "%1" variable in the first TREE command uses the login name that was used to authenticate to the Branch Office tree, and passes that same name to the central office tree. When combined with the appropriate context, such as ".%1.Branch1.OU.ORG" (with the leading period) in the example above, this variable references the matching user in the corporate tree (such as: "UserA.Branch1.OU.ORG"). This assumes that a synchronized user, with the same password, exists in the corporate tree. Since the NBO users were provisioned using the LDAP connector to the Central Office tree, these matching NBO users were thus created when they first logged into the NBO server.
Note: The "%1" variable is similar to the "%CN" variable. However, there seems to be a glitch when using ".%CN.Branch1.OU.ORG" as the fully distinguished name, so the "%1" is used instead. Specifying the full context with %CN (such as ".%CN.Branch1.ou.org") causes the TREE command to fail to match the user, and a secondary login box appears asking for the username and password again. Also, using "%CN" without specifying a context will default to searching for the user in the Central Office server context. However, using the "%LOGIN_NAME" variable with the context (".%LOGIN_NAME.Branch1.ou.org"), will work just fine. Note, however, that the %LOGIN_NAME variable is limited to just 8 characters.
This whole scenario assumes that you are using the LDAP authentication connection between the corporate tree and the NBO tree, and thus have duplicate (synchronized) user accounts in each tree. If you have deployed NBO servers without using the LDAP authentication connection between the trees, you might have to use a variation of this second solution below.
Example - Using a Generic User AccountIn the second exception scenario above, all users need to map a drive to a server in the corporate tree in order to perform some function, like update antivirus signatures. The use of the TREE command is similar here, but it may include a generic user account, to login users to the corporate tree as a generic user, irrespective of what user account they used in the NBO tree. In that case, the login script section might look like this:
IF MEMBER OF ".VIRUSUPDATE.APPUSERS" THEN
TREE 192.168.1.101/.AVUPDATE.OU.ORG; virusupdate
MAP root V:= \\AVSERVER\SYS\Public\AVUpdate
MAP DEL V:
In this case the TREE command still references the IP address of the Central Office server to locate the corporate tree, but it specifies the generic user "AVUPDATE" in the context "OU.ORG". Of course, it presumes that the user already exists in the specified context in the corporate tree. The semicolon and following string in the TREE command actually provides the password used to login this generic user. A drive is mapped, a process is executed, and then the drive mapping is deleted. The second TREE command once again returns the focus in the login script back to the NBO tree.
Note: use this (password) option carefully, since the automatic login can be considered a security risk. Make sure that the generic user has the least amount of access rights as is necessary. Since this implementation only uses this generic user to pull down virus updates, and then deletes the mapping, the use can be considered acceptable.
This generic user solution can also be used in cases where we want all users at every branch site to map a drive to a central server for standardized document templates, and the like.
Example - the Roving User
Another "exception" case often involves the roving user, who may be based at one branch office site, but often roams around to work at other sites. Plus, during the NBO server deployment process, you will have some sites that are migrated to Branch Office servers, while others are still on traditional NetWare servers in the corporate NDS tree. In the first example we looked at the user who logs into the NBO tree, and still maps drives to servers in the corporate tree. But what if the situation is reversed? Now a user wants to go to the branch office site with the NBO server, but login with their corporate tree user account, so as to map their drives to their regular locations on the home office servers in the corporate tree. Yet they still want access to resources on the local NBO server.
In this case we merely reverse the solution, since the needs are now reversed. The corporate user wants to log into the corporate tree, but map drives to NBO server. This perhaps applies to the roving user who is visiting the branch office, or to the Central Office user who just needs a drive mapped to the branch office NBO server.
For the one-off exception user we might just add the additional login script commands to their user account's personal login script. But if there are multiple such users in a context, even just two, it's better to put them in a group, and add the usual "IF MEMBER OF" statement in the container login script. It's always better to centralize the solution, where we can.
Let's say UserB logs into the corporate tree CORP_TREE at the OU.ORG container. This is what the particular section in the user's container login script might look like:
IF MEMBER OF ".Branch1-ACCT.OU.ORG" THEN
MAP root J:= \\192.168.51.11\DATA\ACCT
This section then applies to members of the Branch1-ACCT group that we specify in the OU.ORG container of the CORP_TREE. The TREE command now references the branch office tree NBO-Branch1_T by the IP address of the NBO-Branch1 server (192.168.51.11). It also specifies a user account ACCTADMIN that we created in the APPUSERS container in the NBO tree.
This works much like the generic user in the last scenario. But this time we didn't specify a password, and since it isn't using a synchronized user account, it will stop and ask us for authentication. A login box will pop up while this script is executing, to provide the password for the specified user. Then the drive mapping is made, and again the TREE command returns the focus back to the corporate tree CORP_TREE.
If the situation is different, and we are logging in as a user that is synchronized by the LDAP connection to the NBO tree, then we might use the TREE command with the "%1" variable, as we did in the first scenario. That allows the NetWare client to pass the authentication (username and password) used for the corporate tree on to the NBO tree, avoiding the need for the second login prompt. Then the container script in the corporate tree, for a site where the traditional NetWare server might have been replaced by an NBO server, would look something like this:
MAP root H:= %HOME_DIRECTORY
MAP root I:= 192.168.51.11\DATA:\APPS
MAP root S:= 192.168.51.11\DATA:\Shared
IF MEMBER OF ".SPECIAL.APPUSERS" THEN
MAP root J:= \\SERVER6\DATA\Special
This script mirrors the one listed above for the Branch Office tree (see above), except that the "%FILE_SERVER" variable is replaced by the IP address of the NBO server, just to avoid any name resolution problems. The situation is just reversed: the NBO user who logs in directly to the NBO tree will process the NBO script, as normal. If the NBO user is roving, and logs into the container in the corporate tree for his site, then the Novell client will process the container script as above, which redirects drive mappings back to the NBO server.
This way, the roving users can login directly to the NBO tree when they are at that particular "home" site, and access the local server drives as well as the remote server drive. But when the users are roving to other sites that are in the corporate tree, they can login to the corporate tree container for their "home" site, and the container login script redirects them back to the NBO server tree and drive mappings, while still giving them access to the remote server drive in the corporate tree. The user has the same drive mappings, no matter where he logs in.
For more information on using various NetWare login script commands, see the "Login Script Commands and Variables" section in the Novell Client online documentation at http://www.novell.com/documentation/noclienu/index.html.
Nterprise Branch Office admins are often delighted to see the easy-to-use Web interface for configuring network printers on the NBO server. It is much simpler and direct than the old NDPS method of adding "resources" to the NDPS Broker, and "printer agents" to the NDPS Manager. This can be especially valuable when delegating the Branch Office printer management to others - the simpler, the better.
However, some Novell customers rather like the level of control and auto-provisioning of network printers by groups that was provided under the old NDPS scheme. The new iPrint features certainly offer some welcome capabilities (like, print from anywhere in the world), and ease of administration, but what about some of the old advantages?
Well, iPrint is essentially NDPS on steroids, so the old functionality is really still there - again, under the covers. The familiar NDPS Broker and Manager are still running on the NBO server. They are, undoubtedly, enhanced with the addition of the IPP protocol, and have the advantage of the Web-based administration. But if you still need the ability to assign access control to printers, this can still be accomplished using iManager, or even NWAdmin (which, by the way, is still in the SYS:\Public\Win32 directory on the NBO server). Printers can be auto-provisioned to groups in iManager using the RPM tab on the group object, or in NWAdmin using the NDPS Remote Printer Management tab on either the group object or the user object.
iManager does not run by default on the Nterprise Branch Office server (though it is installed), so many admins may find it easier to make a quick trip to NWAdmin to configure NDPS Remote Printer Management. Most of us old-timers already have a copy of NWAdmin on our local PC anyway.
The Web interface used to manage the NBO server (https://serverip:2222) also has an easy-to-use section for setting up the DHCP service. Just add a subnet, add a DHCP client address range, and add any address exclusions you may need, enable the service, enable DHCP Ping, and bing-bada-boom, you're ready to go. But some admins also need to specify the "Other DHCP Options" for their environment, and thus find this easy-to-use Web interface a little too confining.
That's really no problem. If you've installed the traditional Java-based DNS/DHCP Console on your workstation (it can still be installed from SYS:\Public\DNSDHCP on the NBO server, as always), then it works just as well for the NBO server as it does on your traditional NetWare servers (remember, NBO is just NetWare underneath). Just perform an NCP login (using the NetWare client) as supervisor to the NBO server first, and run the DNS/DHCP Console against the NBO tree. You can then specify all of your special "Other" options to your heart's content.
In most implementations of Nterprise Branch Office, the end users are largely unaware that any significant change has occurred (at least, that's the way we want it to happen). Network drive mappings just happen at login, network printers are provided, and they are free to focus on their particular work, not the network.
Deploying Nterprise Branch Office can certainly provide savings in server hardware and administration costs. However, there is definitely a bit of a learning curve for us network administrators, who are used to the single corporate NDS tree, to wrap our minds around the concept of many little eDirectory trees, all synchronized by LDAP connections to the corporate tree. While it is easy to love the fact that we can abandon tape backups at all the branch sites in favor of data synchronization to the Central Office, some of the other peculiarities of the Nterprise Branch Office model will take a little getting used to.
This article hopes to alleviate some of the issues that appear to be "snags" that can hold up the Branch Office implementation - those little exceptions in use case that often drive us to distraction. I hope your experience is a good one.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com