
----------------------------------------------------------------------
NOV-NDS3.DOC -- 19961028 -- Email thread on NetWare Directory Services
----------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Thu, 23 May 1996 12:00:22 -0800
From: Mark Schoonover <schoonom@CCMAIL.SGO.SONY.COM>
Subject: Re: Reply to Get Nearest Server Problem.

>On  8 May 96 at 7:57, Alan P. Belliveau wrote:
>>I'm having a bit of a problem with some workstations. I have 2 1000 user
>>4.1 servers. SERVER A has REPLY TO GET NEAREST SERVER = OFF. I'm trying
>>to get my workstations to attach to SERVER B. The workstations are still
>>attaching to SERVER A on bootup. I don't know why.
>
>I have noticed this "feature" (bug) of netware 4.1.  Someone told me
>that it appears to depend on the order the servers attach to the
>network, but I have not tested this theory.  I also have found three
>different locations to set the "Get nearest server option" at the
>server. The first two are in INETCFG, under the expert option in both
>the protocol/ipx and bind/ipx sections.  The third is the set
>command.
>
>In the end I decided it really did not matter which server the users
>first attached, other than the 10% of users who are still at the
>login prompt of a test server when it's downed.
>
>Why does it matter to you where the users get attached?

OK, this seems to be a fundamental problem in dealing with Netware
4.1. First off, you do NOT login to a specific server per se. You
login to NDS. Yes, NDS has to reside somewhere, and yes, it can reside
on any given server. If you do not have a replica, master, read/write
or read only partition on a local server, you'll login to NDS on the
nearest server that has a partition available for this purpose. Once
you're authenticated by NDS, then any other server that is known to
NDS will become available for you to use, if you have appropriate
rights, etc. You can map drives, capture printers, etc. In my
situtation, I really don't care which server I 'login' to. I don't
have a slow WAN link to contend with. Some users in one building login
to an NDS partition that is on a local server to them AND has the
aforementioned replica/partition. They in turn run their repsective
login script and accesses information/services provided by server(s)
in other buildings. Just think of NDS as being 'above' the server,
with the server baing just like any other leaf object in NDS.

------------------------------

Date: Mon, 27 May 1996 13:15:07 +0800
From: Osman Elias <pemosm@EMY.ERICSSON.SE>
Subject: Re: Group Naming BUG?

>One high school's netadmin showed me something strange in NDS's group
>name.  She has hundreds of student objects in one container and had
>created groups for each grade: senior1, senior2 and senior3.
>However, she found that the login script with the "member of" couldn't be
>executed properly. The following is the simplified part of the script:
>
>	if member of "senior1" then begin
>	  write "Senior 1"
>	end
>	if member of "senior2" then begin
>	  write "Senior 2"
>	end
>
>No matter to which group the students belong, both write statements are
>executed!
>
>Finally she changed the group names from senior1 to s_one, and the
>problem's gone! I can't explain it. Is there anyone can tell me why?

I have encountered this problem before. I took 3 days to solve the
puzzle. Actually NDS needs UNIQUE container name for the FIRST 3 CHAR.

---------

Date: Tue, 28 May 1996 09:18:20 +0100
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: Group naming bug?

This is a documented bug in the original NW4.1 login.exe program.
Get ftp://ftp.novell.com/pub/updates/nwos/nw410/log412.exe to fix it.

------------------------------

Date: Wed, 29 May 1996 10:35:44 +0100
From: Peter Scherrer <SR@ZID.ISBURG.CH>
Subject: Re: Not droppning connections from NDS

>I am having a strange problem with my 2 Netware 4.1 servers on the
>same tree.
>
>I have 2 NW4.1 servers on the Student Tree serving 3 Student Labs.
>The students are allowed to log in from any of the labs into the tree
>and will be given access to the required servers depending on where
>they log in from.
>
>The problem I am having is that a student could just logged out from
>one lab and then go to the other lab and try to login but cannot
>because we had restricted one login only and the system is saying the
>the student is still log in.
>
>A check on MONITOR shows that that student is not log into any of the
>servers but in NWADMIN in Enviroment entry of that student had a IPX
>address which cannot be deleted and the only way we can overcome the
>problem is to give the student another login , ie 2 logins.
>
>I am running DS.NLM v4.89c.

That is a know problem. In the latest DSREPAIR.NLM (4.35?) is a
parameter, that allows you to remove all IPX addresses that are older
than a given time, default is 60 days, but it can be changed.

The other solution for your problem would be to have the same user
login at the the same station in the first lab, and then logout correctly.

------------------------------

Date: Fri, 31 May 1996 11:10:40 EA
From: Greg J Priestley <Greg_J_Priestley%PKF@NOTESANZ.NET.AU>
Subject: Re: NDS Alias problem

>We are trying to alias remote-office users so
>that when they log-in to the local tree the
>WAN link is not opened unnecessarily to run
>their home log-in script.
>
>The tree & accounts/aliases are:
>
>	       NLK
>     +--------------------+
>    VCR                   KENT
>  (A) VCR_Usr             Test_Usr
>
>When "VCR_Usr" (an alias of Test_Usr) logs in,
>the following occurs:
>
>Your current context is vcr
>Enter your password:
>Alias login as: TEST_USR.kent
>Your current tree is: NLK
>You are attached to server ENG0.
>Authenticating to server KENT1.
>You are attached to server KENT1.
>Executing KENT login script
>Authenticating to server ENG0.
>
>The naughty bits are the "attaching to server KENT1"
>and "Executing KENT login script" outputs.

An alias is merely a pointer to the other "user".  Hence you will still
run the login script, etc, of that user which means, unless you
specifically write your login script to not do this (based on testing
context or location), that you will have your normal resources (which are
on the far side of a WAN link).  Fun fun fun.

I'm mid way of doing a solution for this for a client and may knock up a
report of my findings and solutions to this problems when I have it all
up and running.

------------------------------

Date: Fri, 31 May 1996 11:35:22 -0600
From: Todd Herring <THERRING@SPEANET.IUPUI.EDU>
Subject: NAME CONTEXT -Reply

>I would like to place users in separate containers, as follows:
>
>O=BTI
>     OU=Accounting
>               User 1
>      OU=Client Services
>               User 2
>      OU=Professional
>
>If users 1 and 2 share the same workstation, I can't use the NAME
>CONTEXT in
>NET.CFG to specify the current context, because it changes depending
>on who is logging in.  Does anyone know of any workarounds?

This is probably a FAQ-worthy question.  I looked for it and didn't see
anything in the latest FAQ, but this has been discussed a number of
times (I posed this question once, too).  Here are some possible
solutions:

1.  Teach users their distinquished names (ie,  .USER.ACCOUNTING)

2.  Create your own front end to LOGIN.EXE to ask the user where they
belong.  Give them a menu of choices -- Are you in A) Accounting  B)
Sales  C) Marketing...   I'm no programmer, but I managed to do this with
a batch file and Nortons Batch Enhancer.

3.  Find a third party program to perform number 2 above.  Someone on
this list offered one he had written.  Not sure who.

4.  Find a program called FLOGIN that I've heard will fix this.  Again,
don't know who, where, or how much.  I've looked but haven't found it.
Anyone know?

5.  Wait for Novell to come out with something.  Will Green River offer a
solution?

------------------------------

Date: Fri, 31 May 1996 13:24:07 -0400
From: Rick Troha <rickt@NWSUP.COM>
Subject: DS.NLM v5.01 Now Available

For those running NW4.1, DS.NLM v5.01 is now available in file
41NDS9.EXE.

------------------------------

Date: Fri, 31 May 1996 23:47:16 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Moving a server

All you really have to do is go to NWADMIN, grab the server object along
with the volumes and drag them to the new container. Edit the server
context in Autoexec.ncf and you're done. Of course this method retains
all the user rights, etc. which you MAY not want to keep.

------------------------------

Date: Sat, 1 Jun 1996 14:17:28 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: NDS Woes . . .

>At my site I am managing 140 users on four (4) NetWare 4.10 file
>servers, SACFSA1, A2, A3 and AA.  All object are kept within one
>Organization without any Organizational Units.  This is because there
>are so many users requiring access to so many different resources, so
>in essence it resembles a simple "flat" bindery.
>
>A1 contains the Master replica and A2 and AA hold R/W replicas.  A3 is
>simply there. (4th and subsequent servers default to no replica).
>Early this week I did what should have been a simple task and ended up
>being a major pain.  SACFSAA was a P100 with 2ea. IDE HDDs.  I was
>short on space so I needed to replace these drives with a Seagate
>2.4Gb SCSI.  In doing so, since I would be replacing volume SYS I
>decided to utilize DSMAINT.  Following the instructions of DSMAINT,
>all seemed to be going well... at least until I re-activated NDS on
>this server.
>
>The next morning after the "upgrade" I ended up with approx 1/3 of my
>objects being corrupt or missing.  Several groups were gone, all but
>one print server was gone, and thus many users were upset that they
>could not print or access their files.  I attempted to recreate the
>missing objects but when doing so I'd either receive an error that the
>object already existed or it would allow the recreation of the object
>but soon the object would change names with an update to something
>like 0_1 or 1_1.  When I would look into these objects under "Other
>Name" there would be the name by which it originally went by.

    <big snip>

Aside from the usual "make sure you're using the latest versions of
DSREPAIR, DS.NLM," etc., I'd suggest that if you're going to bring a
server down which has multiple replicas of the partition, you make a
few changes.

In your case, I'd have either changed the Master replica of the partition
on A1 to a Read/Write -- or, more likely, have removed it altogether and
placed the Master on A3.

You can always re-place the replica after the hardware has been changed out
and NW4 reloaded.

Just seems like an easier, "no chances" way to do things...

------------------------------

Date: Sat, 1 Jun 1996 14:29:50 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: NDS Synch Problems on 56K Lines?

>I have heard reports of NDS sync problems when WAN links
>are only 56K.  Has anyone experienced this?  Is 64K any
>better?  128K?

Only input I have on this is that, apparently Novell Consulting Services
recommends placing replicas only across "fast" WAN links (which they define
as T3 or faster).

---------

Date: Sat, 1 Jun 1996 16:19:05 -0400
From: "Martin C. Mueller" <mcm@MATHEMATIK.UNI-KL.DE>
Subject: Re: NDS Synch Problems on 56K Lines?

>>I have heard reports of NDS sync problems when WAN links
>>are only 56K.  Has anyone experienced this?  Is 64K any
>>better?  128K?
>
>Only input I have on this is that, apparently Novell Consulting Services
>recommends placing replicas only across "fast" WAN links (which they
>define as T3 or faster).

We're living happily with a 64kbit ISDN-Link for three years linking two
4.1 servers. The tree's three replicas reside each on both servers.
Never had any sync problems due to network speed, the tree even survived
connection outages of more than one day. The line is being operated
transparently by a CISCO-router within a LAN and serves the
communication needs (TCP/IP and IPX) of about 25 people with the main
computing resources on this side and the Internet on the other.

---------

Date:	Sat, 01 Jun 1996 08:20:24 -0400
From:	Rick Troha <rickt@nwsup.com>
Subject: Re: NDS Sync problems on 56K lines?

>I have heard reports of NDS sync problems when WAN links
>are only 56K.  Has anyone experienced this?  Is 64K any
>better?  128K?

One of my customers gets intermittant DS error 625 across
a 56k frame relay link. The servers will exhibit the error
for 10-15 minutes and then sync up again.

Here's a little something from Novell on the subject from
TID1202460:

WAN LINKS

Bad communication over a 56kb wan link is a common cause of -625 error.
The most common scenario is one in which we may have a central location
and several remote sights each across a 56kb wan link usually with frame
relay.  In these situations if a replica has to travel more than one 56kb
link there will be communications problems resulting in a -625 error.
To remedy this problem a faster link must be used or some changes in
configuration must take place.

There are changes that can be made to help prevent the loss of
communications over 56kb wan links.  It is suggested that an organizational
unit be created to hold the necessary objects at the remote sight.  This OU
is then made into a partition and replicated on the server at the remote
sight and then replicated on one or two servers both at the central sight.
This way only one 56kb link is traversed to maintain syncronization and
fault tolerance is maintained.  This can be duplicated for each remote
sight.

There are two other common problems that fail to be recognized when
designing and implementing a directory services tree across wan links.
The first problem is the transfer rate over the wan link.  The second
problem concerns installing a remote server.

If a 56kb wan link is to be used and there is not a guaranteed transfer
rate there is potential for problems.  Assume things are running fine one
evening and you are attempting to do some partition operations.  At the
same time another company kicks off their backup across the wan and your
throughput drops.  If the line is not guaranteed 56kb you may now be at
20kb and then there are -625 errors everywhere and there is nothing you
can do until the transfer rate comes back up.

Many remote servers are created at a central location before being shipped
out to the remote location.  In most cases install takes place, things look
great and the server is downed and shipped out.  Once on sight the server
is brought up, replicas sync across the 56kb link, and everything looks
great.  Assume a drive goes bad on this server and now we replaced the
drive and install NetWare again. We have replicas on other servers so we
will put a replica of the partition back on this server.  When we attempt
to get the replica we get -625 errors.  The problem is that up until now
the only traffic on the link is traffic to maintain syncronization.  Now
we are trying to pull a replica of a partition with all of its objects
across and the link can't handle it.  The best way to fix this is with a
better link.

There are problems where the link is sporadic or the link is providing
consistent enough performance for SPX to function but not enough for NDS
information to synchronize.

This can be a difficult problem to isolate because often the other SPX
applications work fine, but NDS still returns -625 errors when it tries to
access a server on the other side of the link. In this specific case you
may be able to work around this problem using a couple of DSTrace commands
to increase the listening time. Listening time is the time after which IPX
will time out if it gets no response from a device on the network. To use
these commands you need to understand the following formula:

     Listening Time = Tick Count x Scale Factor + Shift Factor
					!Y		!Z

Tick	This value is provided by IPX (or the transport protocol
Count:	that is being used) and is calculated by the server based
	on routing information it has received.

Scale	This value is multiplied. For this reason you need to be
Factor:	careful not to change the value too far from default (default
	value is 16, range is 1-80).

Shift	This value is used to granulate the scale factor (the
Factor:	default value is 10, range is 1-500).

You can view current settings by setting dstrace=*p
	IPX:Retries = !X
	IPX:TimeOutScaleFactor = !Y
	IPX:TimeOutShiftFactor = !Z

Here is an example of how to set the X, Y, and Z parameters:

	SET DSTRACE=ON
	SET DSTRACE=!X4
	SET DSTRACE=!Y20
	SET DSTRACE=!Z40

The !X parameter changes the number of IPX retries that occur before a -625
message is sent to the console. The default value is 3, and we recommend
that you set the value no higher than 5. The range is from 1 to 500.

Do not change the X, Y, and Z parameters unless absolutely necessary. If
you increase these values, in some processes NDS performance will drop
significantly. We suggest that instead of raising these values you improve
the link used to increase the capacity. If you increase the Y parameter, we
recommend that you create local copies of all of the objects referenced by
the users so that the link is not used. This way the link will be used
primarily for synchronization and not to access NDS objects. If you do not
follow these recommendations, 4.x users may see a significant performance
degradation.

---------

Date: Mon, 3 Jun 1996 15:21:29 -0400
From: Barbara Lewis <Barbara_Lewis@WASH-BALT.USCONNECT.COM>
Subject: Re: NDS Synch Problems on 56K Lines?

>I have heard reports of NDS sync problems when WAN links
>are only 56K.  Has anyone experienced this?  Is 64K any
>better?  128K?

I have talked with some people in a banking environment where the company
has branches all over the world and right now they have 56K lines.  Novell
has recommended a minimum of 64K and would prefer they get T1.

------------------------------

Date: Tue, 4 Jun 1996 12:09:19 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: # of objects in a container

>I am planning on having up to 10,000 student accounts on our
>Netware 4.1 network.  Based on advice obtained from this list and other
>sources I have created 3 containers to hold the user objects.  Because
>of the various contexts this creates our students are having difficulty
>during login.  (Having to login .smithj.student1.lrc.vb).
>
>Question. Will the upcoming 32 bit version of NWAdmin allow us to
>consolidate the student user objects in a single container?
>
>Or will Green River have a login that simplifies logins to various
>containers?
----------
	NWadmin is a Windows program, not NDS itself, and thus has no
bearing on the number of objects in a container. The advice from Novell
is stay under 1500 objects in a container because the NDS software (NLMs)
takes too much time with more. You certainly do not want to contemplate
10K objects in one container. Green River doesn't solve this database size
effect either.
	You will need to educate your users ever so slightly that context
is rather like an Email address, so use the long form and achieve success.
If ISO had any sense they would have used <object>@path notation too.
	Joe D.

------------------------------

Date: Wed, 5 Jun 1996 08:25:17 -0800
From: Mark Schoonover <schoonom@CCMAIL.SGO.SONY.COM>
Subject: Re[2]: Alias usage

The preferred server statement is used for bindery server(s)/services
only and is mutually exclusive to Preferred Tree. I've found it to be
bad practice to use both at the same time.

------------------------------

Date: Thu, 6 Jun 1996 22:49:28 +-1000
From: Phil Montgomery <Phil_Montgomery@NETORIA.COM>
Subject: Searching NDS live

>An alias object is simply a "pointer" back to the original object (in
>fact, if you look at Details for the alias object, you'll see that the
>name for it is the original object name).
>
>If you're working in a relatively small environment (no WAN links,
>small number of partitions) you might try one of the third party programs
>(FSLOGIN or SFLOGIN) which allow you to login using the common name. The
>program will then search the Directory and log you in (or give you a
>listing of all objects with the same common name and ask which one you
>are). If you're working with WAN links or lots of partitions, this can
>become impractical (slow!)

I agree that searching NDS live over large WAN links or many partitions
can be slow.  At Netoria (publishers of SFLOGIN) we have built a client
server NDS indexing system known as 'fiNDS'.

fiNDS is an NCP extension based NLM that builds and manages a server
based NDS index.  SFLOGIN communicates with fiNDS, using an API almost
identical to Novell's NWDSSearch.  However, fiNDS can locate any object
almost immediately.

In our testing we setup an NDS tree of 14 MILLION objects (SYS volume
took four hours to mount!). Using fiNDS, SFLOGIN could locate any object
is less than 0.25 seconds.  An organisation can have one or multiple
fiNDS servers, and they can use our own API to write their own programs
that talk to the server.

We will be releasing a beta of this technology in a few weeks.  If you
are interested then drop me a line or have a look at
http://www.netoria.com.

------------------------------

Date: Mon, 10 Jun 1996 10:28:09 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Merging 4.1 servers

>I recently installed 2 4.1 file servers in an org. everything is
>working fine.
>
>This org wants to merge both 4.1 servers into 1 superserver. are there
>any tools that will let me do this, keeping current nds tree
>definitions? how should I confront the issue? should i add the server
>into the tree and bring users into the new context , then delete other
>servers from NDS or can I use migrate to merge 4.1 servers? Any ideas
>or experience doing the above???

Why would you need to create a new organization to do this? Remember, in
NetWare 4.1, you're logging into the network, not on a server by server
basis. From an NDS standpoint, all you need to do is to install the server
into the existing tree. Place a replica of the partition on the server and
make sure it's in sync.

You *will* have some cleanup to do on the back end. You'll need to change
any "Preferred Server" statements in the NET.CFG files on workstations.
You'll need to check for "Default Server" property for users and change
(use UIMPORT) if necessary. You will also have to make sure that mappings
are referring to the same directories on the new server as on the old.

In terms of file system, you'll need to backup (SMS compatible backup,
please) from both servers and then selectively restore on the new one
(*after* NDS has been installed) so that you still have your user
directories, etc. In spite of this, you may end up having to rebuild some
of the file system rights, so make sure that they're documented prior to
doing this.

------------------------------

Date: Wed, 19 Jun 1996 15:38:08 +0100
From: Stuart Phethean <S.J.Phethean@SOTON.AC.UK>
Subject: Re: A large container, bindery emulation, nds traffic

>I work at a small university with 6000 students and at this moment
>these students are working on 3 netserver 10G 64M HP netserver LH
>machines
>2 contain apps and userdata
>1 contains the printerqueues group data and mail (pegasus
>  mail is used with mercury)
>
>all 6000 students have their own account on the network and need to
>be able to work from any student computer and all apps (about
>500 pc's  and 20 printers)

<snip>

>- large waiting times after changing adding nds   objects/properties
>
>possible solutions
>divide in more containers and multiple comntainers in one bindery
>put printerqueues volumes fileservers in a different container to
>speed up mapping capturing etc.
>
>does anyone have experience with these , what is the solution in your
>organisation.

We have, at present 13000+ users with each alphabetical group a ... z
present in a separate container (ie 26 containers). Each container is
also a replica, which is present on two other servers as well, so we
have three central servers in all. Novell recommend ( and so do I !)
not much more than 1000 users per container or replica. We had big
server crashes when we had much larger containers.

I set bindery contexts for containers a..h on server 1, i..q on
server 2 etc etc. User admin using Uimport works fine. Servers do
tend to work quite hard keeping in sync, but we are upgrading RAM
this week from 64MB to 96MB. Dsrepair does take a while, but thats
just a function of the total number of users and not the number or
size of container. The LRU time in the cache statistics is about 40 -
50 minutes - on our other NW410 servers which just have more local
information it is in the order of 1 - 2 DAYS!

At present we have only the central user-id servers running NW410 -
we will be gradually migrating our 28 NW312 applications servers to
NW410 once we are confident that our central authentication servers
are standing up to the load. At present most connectivity is via
bindery emulation.

------------------------------

Date: Wed, 19 Jun 1996 23:51:25 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: A large container, bindery emulation, nds traffic

>I work at a small university with 6000 students and at this moment
>these students are working on 3 netserver 10G 64M HP netserver LH
>machines
>2 contain apps and userdata
>1 contains the printerqueues group data and mail (pegasus
>  mail is used with mercury)
>
>All 6000 students have their own account on the network and need to
>be able to work from any student computer and all apps (about
>500 pc's  and 20 printers)
>
>All objects are at this moment in one container.
>bindery based applications can easily work like pegasus mail,
>lanskool etc.
>replica's are on all servers.
>
>We are in the process of putting all bindery based stuff on the
>groups/mail server .
>
>Problems.
>
>- Long waiting times when logging in and when capturing to
>  printers. etc (all things that need to get information form the
>  ( nds/bindery )

Making good use of replicas should help you to speed up the process.
Maybe you need to redesign your NDS tree if that doesn't help much.

>- Replica actions (deleting a replica running dsrepair etc) last for
>  hours an working at that moment is almost impossible

Doesn't SERVMAN has some settings to make this happen during off-hours?
Not sure on this one though. Please check.

>- large waiting times after changing adding nds   objects/properties

See above.
If there really isn't anything to finetune anymore then maybe you're
in need of a 100Mhz server backbone.

>Possible solutions:
>Divide in more containers and multiple comntainers in one bindery
>Put printerqueues volumes fileservers in a different container to
>speed up mapping capturing etc.

Reevaluate your NDS tree design and your replica distribuation.
With your amount of objects buying a good book about it could give
you some answers and more too.

>Does anyone have experience with these , what is the solution in your
>organisation.

Read before you plan.
Plan before you work.
Test first before you implement.
Then work the plan.

---------

Date: Wed, 19 Jun 1996 16:14:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: A large container, bindery emulation, nds traffic

[Floyd: repost of the above post snipped]

	I recall from Novell's Brainshare/Developer's Conference this year
that the time to perform NDS operations grew exponentially or so as the
number of objects in a container grew. Their recommendation was to cap
that growth by putting the same number of objects into more containers,
which I term "factoring the problem" from common mathematical techniques.
Sort/merges face the same problem, and the NDS work is basically of that
kind. See Don Knuth's series "The Art of Computer Programming."
	Partitions have one or more containers, and one or more servers.
The servers form an exchange group holding identical data. Partitions are
traffic control devices, not directly NDS speed ups (though going from one
partition to another obviously slows down matters a lot *unless a replica
is on the same server*). I suspect that the traffic is the same whether
we have many or few containers, for a fixed number of servers.
	So, by factoring/multiple containers (those logical thingys) we
should be able to reduce the lookup/replacement workload on a server and
run faster. Their advice is keep the number of objects per container under
1500 or so for best performance. And, from private conversations, the troops
are trying to find ways of speeding up these things.
	That's what I remember from the presentations without dragging out
my notes. Anyone else have a better memory?
	Joe D.

------------------------------

Date: Fri, 21 Jun 1996 09:46:05 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re SUPERVISOR user in NW4.10

There is actually a SUPERVISOR object on NW 4.x. According to a brief note
in the NetNotes section of one of the recent Application Notes, the
SUPERVISOR object exists in a context named "bindery" which is always
present on a NW 4 server. This "bindery" context is the same one used to
hold objects created in response to receipt of SAPS, which explains why
it is possible to use a bindery function to scan a 4.x server for known
file servers (as SLIST does), even when no bindery context is defined
via the console "set bindery context" command. The SUPERVISOR object is
apparently always present in the 'bindery" context, but becomes visible
only after one or more NDS containers have been set to bindery contexts
via "set bindery context=".

------------------------------

Date: Fri, 21 Jun 1996 12:39:29 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Novell's NDS wisdom, in one file

	In directory pub\updates\nwos\nw410 is file DSDOC2.EXE, 1.7MB,
which is an Envoy format (i.e., run under Windows) document describing
a great many details and terms regarding NDS. I sense the doc is still
rather fluid (it was changed again overnight) and has a ways to go. But
this 363 page tome is a gold mine of useful information (what a job it
must be to compose it!).
	Visit ftp.novell.com or official mirror sites near you.
	Joe D.

------------------------------

Date: Thu, 27 Jun 1996 19:52:10 -0400
From: "J. Darren Lofthouse" <DarrenMail@AOL.COM>
Subject: Re: removing nds

>I can't remember how to remove the nds from a single server tree...

Type:  Load install -dsremove

Then go to "directory options", and "Remove Directory Services from
this server"

------------------------------

Date: Sun, 30 Jun 1996 14:40:09 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Tape Backup Systems

>While at the Novell Connect your World Seminar, several vendors made this
>claim (all associated with Cheyenne somehow) Although many products backup
>your NDS, only Arcserve 6 backs up the extended NDS Schema.  This would
>mean that any product you installed that modified the NDS schema would
>have to be reinstalled if you needed to restore your NDS from tape.
>I would like to know if anyone else has heard this.

This is unfortunately true. I spent some amount of time grilling Novell
about this at Brainshare. It has to do with lack of support for extended
schema backups in (of all things) SMS! It is fixed in Green River (NW
4.11), but Novell won't release any patches to correct the problem for
4.10, at least until after 4.11 is released in September. This is a pain,
but not as fatal as it sounds. At least the information is still there in
the backup, and all you have to do is re-install whatever extended the
schema.

------------------------------

Date: Tue, 2 Jul 1996 09:57:09 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Authenication Process

I tend to use the Preferred Server statement in networks -- usually I
prefer to leave the whole network in one tree. I point the Preferred
Server toward a local server that contains a writeable replica containing
the user's object (otherwise, the attachment will take place and when the
user logs in s/he will re-attach to a server with a replica after some
"tree walking", which tends to slow down the process).

In my experience, the Default Server parameter will *always* override all
preferred server statements. Default Server is the server through which you
receive broadcast messages (i.e., the one that you'll be listed under in
NetWare User Tools). Yes, there are *still* some server-based issues in
NetWare 4!

---------

Date: Tue, 2 Jul 1996 11:05:44 -0400
From: "J. Darren Lofthouse" <DarrenMail@AOL.COM>
Subject: Re: Authenication Process

>In my experience, the Default Server parameter will *always* override all
>preferred server statements. Default Server is the server through which
>you receive broadcast messages (i.e., the one that you'll be listed under
>in NetWare User Tools). Yes, there are *still* some server-based issues
>in NetWare 4!

The Preferred Server is the server that the client tries to attach to
after being loaded. The Default Server is a NDS Object Property that, like
you said, determines where you recieve your broadcast messages from. These
are totally different so how can one "override" the other? Besides, the
Preferred Server is done before you ever login to the network and the
Default Server is dependent on what your login id is so how can Default
Server affect Preferred Server?

---------

Date: Tue, 2 Jul 1996 11:29:58 -0400
From: "Martin C. Mueller" <mcm@MATHEMATIK.UNI-KL.DE>
Subject: Re: Authenication Process

[in reply to the above 2 messages]

It overrides in the sense, that after attaching to the Preferred Server,
the client, having obtained the Default Server propertie's value, attaches
to the Default Server, seemingly loosing attachement to the Preferred
Server, since, if needed, is re-attaches to the Preferred Server.

We had this situation here with two 4.0x servers connected by a WAN
link. By chance and ignorance the Default Server happened to be across
the link for some users. So the client did three attachments in
succession, two over the slow link, which caused considerable trouble
with early OS/2 requester versions. In the case, were the nearer server
didn't hold a R/W replica of the partition in question, only two
attachements were reported, because the client attached to the remote
server (the one holding the replica on this case) right away.

Nowadays here Preferred Server is the server nearest to the workstation
(NET.CFG setting), Default Server is the server nearest to the
workstation the particular user commonly logs in from and both servers
hold writable replicas of all partitions.

------------------------------

Date: Sun, 14 Jul 1996 16:30:38 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Supervisor right to Server

>>I have created an Organisational Role with limited access to the file
>>system but full access to the NDS so that certain administrators don't
>>accidentally overwrite valuble files during software testing etc.
>>
>>Anyway, the way I did this was to reassign rights at the file server so
>>as not to include the [S] right, which would otherwise flow down to the
>>file system.
>
>First, give Admin or some other appropriate account an explicit
>assignment of [S] to the server object.  Next, apply an IRF on the server
>object to block the S right.  Your OrgRole object won't have access the
>file system via NDS after doing this.  If it does, then it's getting it some
>other way -- security equivalence, group membership, or an explicit
>assignment to the volume.  The bottom line is, the [W] property right does
>not give anyone access to the file system.  Having [S] to a file server
>object (either explicitly or through inheritence) is the only "bridge"
>between NDS trusteeship and file system rights.
>
>>Now for my question, I noticed that if I assigned the [W] property right
>>to all properties, I got all rights to the file system regardless of what
>>object rights were assigned! Which property it is that, if given write
>>access to it, allows full access to the file server's file system ?

I agree entirely with Todd's solution (have made it SOP to assign one or two
Supervisors to a server and then set an IRF).

You should be aware, however, that there's more than one way to get that
Supervisor access. Giving someone Supervisor Object right to the file server
object also gives them (by default) Supervisor right to All Properties
(including the Object Trustees List -- also known as the ACL). It's having
the Write Property right to the ACL that actually gives the user the file
system access. Have experienced this many times.

I show examples in classes in which people at higher level containers (a
secretary in the Corporate office, for example) is given Read and Write
rights to All Properties of the container (in order to maintain a mailing
list, for example -- yes Admin should have used Selected Properties, but
didn't!) If there's not an IRF on the server two containers down, the
secretary will end up with Supervisor access to the file system.

------------------------------

Date: Mon, 15 Jul 1996 20:24:19 +0100
From: Gabor Borsodi <THULYA@BME-EIK.EIK.BME.HU>
Subject: Re: NDS

>I need to upgrade the hard drive on one of our NW41 servers.  At the
>same time I also want to remove compression. I understand that the only
>way to do this is to reinstall Netware.  My concerns are with NDS. I am

    No, it is not the only way. Please upgrade your NDS to v5.01 in
    41nds9.exe, and read carefuly through the readme.txt and dsmaint.txt.
    The thing you will need is dsmaint.nlm.

>not so clear on how I can get back my users, printers, queues, etc after
>I reinstall Netware. We have a total of 5 NW41 servers.  The one I am
>ugrading was the first and is serving as the "Master".  Here is what I
>plan to do:
>
>1. Backup the server
>
>2. In NWADMIN (Partition Manager) change the
>   "Master" partition replica to "Read Write" and
>    assign another server as "Master"

    Then here comes the missing step with dsmaint.

>2. Down Server, Remove the 2GB and install the 4GB

    (Funny numbering... :-))

>3. Reinstall NW41 on the 4GB

    As you will see here comes dsmaint to restore.

>4. In NWADMIN (Partition Manager) choose "Receive Updates" to this server
>   Will I get everything (users, printers, etc) back?

    Using dsmaint, yes.

>5. Restore data onto server
>   (I read that you need to restore the NDS first, then the data?)

    NDS will be already restored. You will need to restore only the
    volumes.

------------------------------

Date:	Wed, 31 Jul 1996 08:31:20 -0600
From:	NetWare News <NWNEWS@novell.com>
To:	netwarenews@NetPub.COM
Subject: Press Release -- NDS Update

Media Alert
July 30, 1996

Novell Directory Services Update Now Available to all NetWare
4.1 Users

Enhancements Improve Network Performance

What:
Novell today announced the availability of a Novell Directory
Services  (NDS ) Update. The update significantly improves
NDS capabilities, enabling users to enjoy improved
performance and flexibility in their NetWare  4.1 network
directory. Novell is delivering the NDS update as a single set of
NetWare Loadable Module (NLM) files that network
administrators can easily install onto existing NetWare 4.1
networks with no disturbance to users.

The enhancement consists of a new DS.NLM (version 5.01) and
a new DSREPAIR.NLM that improve message transmission
accuracy by providing the following protocol-independent
features:
Prevents corruption sometimes encountered during
transmission, especially with some older hardware
Cuts tree repair time on large networks by as much as 70
percent
Identifies and contains corrupted tree segments to protect the
rest of the network

Finally, the update serves as an intermediate step to Green
River functionality. Novell strongly recommends all NetWare 4.x
customers download this update, which is available free to
registered NetWare 4 users. Implementation of this NDS
update is suggested for organizations planning to run both
NetWare 4 and Green River as part of their upgrade process.

When:
The NDS Update is available now. Network administrators can
install the update over existing NLMs, and full installation
instructions are included.

Where:
Users can download the update on the World Wide Web at
http://netware.novell.com and on NetWire in the NWOSFILE
library 01 (file 41NDS9.EXE).

------------------------------

Date: Thu, 1 Aug 1996 22:27:12 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: restoring and home dirs??

>We couldn't get Pegasus Mail to work at all.  After hours of trying
>everything, it came to checking the User's NDS environments.  Lo and
>behold, all of the 'home directory' properties of every user was
>empty.

You've got to restore NDS or the bindery FIRST, then the directories.
This could be the problem.

------------------------------

Date:	Tue, 06 Aug 1996 16:06:40 -0400
From:	Michael Yelland <myelland@plan9.itp.eds.com>
Subject: FAQ material ?

Q. How do I recover from a corrupt DS.nlm

A. If ever the DS.nlm becomes corrupted, DS won't load, and so there can be
no logins either NDS or bindery, since NDS minus DS.nlm != bindery only.
Server -na won't work since SYS will automatically mount which will also
load DS. The solution is to run "server.exe -ns" which won't load startup
or autoexec.ncf, then run "load a:\ds.nlm" then DS will load, then mount
SYS: and you can log in and replace the DS.nlm on /SYS:SYSTEM

------------------------------

Date: Thu, 8 Aug 1996 22:45:03 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: 4.1 Server IRF's

>I wish to take all reasonable measures to protect our servers from objects
>in the tree with any and all rights except Supervisory. I will assume only
>admins and equivalents will have S NDS rights at any time. I do not wish
>to filter out the S right unless it appears mandatory for protection.
<snip>

First off, the NDS rights that will "flow" into the file system (i.e., give
the NDS trustee Supervisor file system right to all volumes on the server)
are the Write property right to All Properties of the server object. If you
have the Supervisor object right, you will, by default, get Supervisor
(including Write) right to All Properties as well. Note that you can have
these rights to the container in which the server resides and get Supervisor
file system rights as well, since rights that you have to the container
apply to all objects in the container (including subcontainers and objects
under them).

To protect against this I follow certain steps when installing a new server:
1) After server installation I immediately assign a user as a trustee of the
server and give him/her Supervisor right to the server object. This means
this person will have full file system rights as well. In your case, I would
make a group and assign all Supervisors/admins to it and assign the group as
a trustee as well. NDS does seem to want to have a *user* object with the S
right before allowing you to block it with an IRF, however.
2)  I then set an IRF on the server object to block *all* object and
property rights (except Browse object right). This will keep other users
from "accidentally" getting access to the server through NDS.

Have seen this happen more times than I care to think. Had students in a
class once say that they had a consultant set up their 4.1 network and now
everyone in the container had Supervisor file system rights to the server.
Told them to check to see if the container was a trustee of itself with
Supervisor object rights and, sure enough, it was. Why did he do this? One
assumes because it was an easy way to make sure that everyone had all the
rights they needed (not to mention a lack of knowledge about NDS!)<g>

------------------------------

Date: Thu, 8 Aug 1996 22:45:13 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Alias user Logins

>I want to allow mobile usrs that visit our branch offices to be able to
>login at the branch office. I'm thinking that I would use the alias object.
>
>How does one make an Alias user object use the container login script
>where the Alias user object resides instead of the container login script
>of the real user object?
<snip>

Last time I checked it out, Alias objects would only run the login script in
the original object's container.

To get the Alias object to use the Alias container login script you'll have
to do something like:

1)  Grant the Alias user the Read property right to Alias container Login
Script property.

2)  In the Original user's container login script you will have to add
something that will point alias users to the new contianer script. You can
do this by putting in:
      IF REQUESTER_CONTEXT="Alias_Container" THEN
	 INCLUDE Alias_Container_Distinguished_Name
	 EXIT
      END

    I'd put this at the beginning of the Original container login script, so
that the user will only run the commands from the Alias container and not
overwrite with the Original container script mappings, etc.

And, please check me on the variables -- don't have the Red Books handy, but
think this is the right one (Supervising the Network - login scripts).

------------------------------

Date: Fri, 9 Aug 1996 16:11:22 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Re2: NDS Partition that can't be deleted

>>>I'm working with a new company that has a NDS partition that was
>>>residing on a 4.1 server.  The server was deleted from NDS, and now
>>>when I go and try to delete the partition it gives me an error because
>>>it can't find the server.
>>
>>	Yes, it can happen. We presume you are using the very latest in
>>ds.nlm/dsrepair.nlm, but if not do so now. Please read all the docs Novell
>>provides on using dsrepair, and keep in mind that it is possible to create
>>an indelible ghost (subordinate refs that won't vanish). For the moment
>>the cure is to a) backup everything carefully and then b) call Novell.
>>	I have such a case, and I've talked with the fellow in charge of
>>NDS. His comment is there is a fix in the works, but no timeline for its
>>release.
>>	Joe D.
>
>I believe that an undeletable subordinate reference is my problem.  I have
>two concerns though.  The system people here want to start adding servers
>and making changes to the tree.  Will this be safe?  The second problem is
>that the system people tell me that the NDS tree can't be backed up because
>of this problem.  Apparently the backup software (Palindrome) doesn't like
>the
>bad subordinate reference.  Is there a work around short of recreating the
>tree?
>
>I have heard that you can save parts of the tree with DS Standard. Would
>it be possible to save each part of the tree separately, delete the tree
>and then put the good pieces back together?
-----------
	The story goes like this.
	Yes, you can damage a tree if not careful. That means don't spread
top level priv's around, and isolate sections so that damage is limited.
But even damage at the bottom can corrupt a tree as indicated above (I have
such a case). Novell is well aware of the problems (I've gone down my list,
face to face) and is fixing them one by one.
	Backing up NDS. The solution is Green River, not before. TSANDS and
TSA410 for GR permit safe and complete backup/restores. I'm running GR here.
Last spring I had some changes made to this process and they should be in
the shipping product. Expected ship date of GR/NW v4.11 is September. It can
be installed right on the top of NW 4.10, quickly and safely, with no loss.
	General health. Always use the very latest ds.nlm/dsrepair.nlm, NOT
the versions shipped with NW 4.10 (oh please). Read the guidance by Novell
and follow those steps carefully. I know, that stuff reads like magical
incantations, and that's pretty close to the truth.
	When in deep NDS trouble you will need to call Novell a.s.a.p. Don't
try to fix something badly broken because you can easily make it worse.
	The future. After GR we expect to see federated domains where NDS
is split into semi-independent regions to give more fault isolation as well
as solve the serious political problems of sharing. There's more along this
pathway but I'm not allowed to discuss such things.
	Joe D.

---------

[continuing his own reply, on Aug 14, 1996 Joe D. added:]

	Backing up is one problem, restoring NDS is the *really big* problem.
	Here is my suggestion. Backup all files and everything else you
value, and don't hesitate to make screen dumps of user related information.
Then call Novell, pay $200, and follow their instructions.
	It is unwise to add material to a damaged tree, even though such
additions typically succeed. I've done this, and had to force matters over
the hurtles. But keep in mind that the more data there is the more that
can be damaged, the harder it is to restore, and the more work involved
when Novell collapses your tree to one server, tries to fix it, and you
repartition back the way you were. It's not the data that is the big worry
but rather the icky feathers from all the sacrifical chickens Novell uses.
	DSMAINT is available, as Novell will undoubtedly explain, to capture
NDS files at one instant, but it is not a backup/restore method. DS Standard
can be very useful, so by all means give it a try (slow with lots of data)
as yet another safety net.
	I've tried most things here with those permanent subordinate
references and nothing has succeeded. Novell agrees that the cure is to
reinstall from scratch, and I'll do that as soon as the lower parts of my
test tree can be moved to other trees. When I do it's bye bye NW 4.10,
hello again 4.11.
	Joe D.

------------------------------

Date: Thu, 15 Aug 1996 12:25:10 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NDS Partition that can't be deleted

>If you are having the problem I had there is a solution.  I had
>removed a server without moving the master replica of a partition.
>After spending some time making matters even worse, I ended up with
>only two subornidate referances to this partition (no master and no
>read-write).
>
>Solution: Convert a subordinate referance to Master replica and
>correctly delete the context and partition.  This solution will only
>work if you want get rid of all contexts in that partition. It
>cannot recover any of the objects.
>
>I thought that this was documented with 41nds5.exe, but I cannot
>find the referance.  In any case if you feel that your situtation
>fits this and feel secure monkeying with your nds in this manner,
>then try "load dsrepair -A"

	Alas, this probably won't work. The change is from Subordinate
to Subordinate, meaning nothing happens. Or if one changes the partition
to Master and repeats the removal it again becomes Subordinate.
	The fundamental problem is references may not be deleted unless
both ends of the reference cooperate to do so. If the other end, the
original material, is absent then no cooperation and no removal. Needless
to say, this is a fundamental design item which needs correction and
which is reported to be under consideration.
	Joe D.

>Note: Just in case you did not already catch my reservations about
>this. This is a last ditch effort to removing a partition that you
>can no longer access because you have no replicas of this partition
>except subordinate referances.  I would only suggest trying this
>just before you get to the point of removing and reinstalling NDS on
>all servers. If you are at that point there is not much left to hurt.

------------------------------

Date: Fri, 16 Aug 1996 22:40:45 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: 4.1 Server's IRFs

>I suppose removing all but S rights from the netadmin OU and servers seems
>in order? Also a backdoor account at the top OU level with S rights to
>root and Organization (the same setup as the netadmin OU) would be logical?

If you want to block the servers, make a user object (or two) Supervisor
(object) to the server object and then block all rights except Browse
(object) and Red (all properties) in an IRF on the server.

In terms of protecting your admin users accounts, in classroom situations I
tend to create a backdoor object (AltAdmin). I assign both Admin and AltAdmin
*all* object and all properties rights to [Root] and Organization and
Organizational Unit objects. I also tend to give them all rights for selected
properties to the Object Trustees (ACL) property. I make Admin and AltAdmin
trustees of one another and give them *all* rights to one another. I can then
place an IRF on each object and block *all* object and property rights --
this makes them "invisible" to all users except one another. I also make each
of them Security Equal to one another and to the server object (which will
also give them Supervisor file system rights to all volumes on the server!)

The administrative user object position in the tree makes no difference,
incidentally -- it's the rights that you assign that make the difference. And
I would be sure to make the rights assignments to the user objects for the
administrators -- not to a container that they all reside in (as I've seen
done in the field). After all, what happens if the OU object gets corrupted
and loses it's rights? So do all objects in the container!

------------------------------

Date: Fri, 16 Aug 1996 22:40:59 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Rights in 4.1

>I am in the process of switching over from 3.12 to 4.1. Most of it is working
>fine, except that I cannot hide the root directory of users files from the
>users. In other words, all users are in a server volume called USERS, with
>their login_name as their home folder name. When they log in, I would like F:
>to be their home directory. Right now, F: is equal to USERS:home_directory
>(example: F:\MKLESSLER). If fact, as a user with no administrative rights I
>can see all the other home directories and the directories within them (I use
>the terms home folder and home directory interchangeably). I am guessing that
>these Read and File Scan rights are inherited, but even if I deny them for an
>individual user, that user does not lose them. If they are inherited (from
>the organizational unit or the groups to which the user belongs?) how do I
>get rid of them?

Sounds like an OU or group has the rights and, in that case, the only way to
get rid of the user's rights are to either delete the user from the OU/group
or change the OU/group's rights to the root of the volume.

If they only have R, F rights they were granted in the file system (probably
at the root of the volume). Doubleclick on the USERS volume object (to get to
the Details) and click on the "Trustees of the Root Directory" to see who is
assigned rights here. You only need to worry about rights flowing through
from NDS through the server object (and, in that case, the user(s) would have
Supervisor file system right without a file system rights assignment at the
root of the volume. Check the server object for "Trustees to this object" for
info on who may have Supervisor file system right to all volumes on the
server (anyone with Supervisor object, or Supervisor or Write All Properties
rights). NDS trustees to the volume objects get *no* file system rights, so
they're not a concern from that standpoint.

I usually assign one or two people as trustees of the server object with the
Supervisor object right and then place an IRF on the server blocking all but
Browse object and Read All Properties. (Yes, I know some people don't like
IRFs - I don't like them in the *file* system and avoid them wherever
possible, but I *do* use them in Directory services in a consistent manner --
servers, administrative user objects, etc.)

I do agree that you need to use the MAP ROOT command in mapping your users'
home directories -- that, in combo with getting rid of the excessive rights,
should improve your security considerably.

------------------------------

Date: Mon, 26 Aug 1996 14:07:32 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Join state 0

>I have a partition which is in Join State 0.  It has been this way
>for a few days.  I was trying to merge two partitions.  I aborted the
>process in the child partion but I cannot abort the process for the
>parent partition.  DSRepair "Cancel partition operation" says the
>partition is not busy.  I can't perform any other partition
>operations or move any objects.  I have 41NDS9, 410IT6 and 410PT3
>installed.  One server has 410PT6 installed.

I've run into a similar problem during a partion merge.  All was in sync,
DSTRACE showed YES to everything, but the state was stuck.  I ran DSREPAIR
and repaired the local database on the server that held the [Root], and it
said there was one invalid time stamp.  I also did the "repair time stamps"
thing in replica and partition operations.

So, if I were in your shoes, I would:

- load dsrepair
- advanced options menu
- repair local ds database
- No, no, no, yes, no, no, no (you'll see)
- perform this operation, and look at a DSTRACE to see that it all syncs up.
- back at advanced options, replica and partition operations
- [Root]
- repair time stamps and declare a new epoch

You should be 100% comfortable running DSREPAIR if you chose to do this!

------------------------------

Date: Mon, 26 Aug 1996 23:38:26 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Renaming 4.x server

>Several months ago Debbie mentioned the formula for renaming a 4.0 server.
>
>     1.  Load install and edit the server name in autoexec.ncf
>     2.  Down the server and restart it.
>     3.  Set dstrace = on
>     4.  Set dstrace = +limber
>
>I remember there was a coupld of other steps but I can't remember what they
>were.
>
>Will the volume names in the tree be renamed or does that have to be done
>manually. Does DSREPAIR need to be run afte the tree synchronizes.

Well, you didn't forget much! Just check to see that the "Limber: start
connectivitiy check" and "Limber: end connectivity check" both come out OK.

Yeah, it *is* recommended that you run DSREPAIR after the tree synchronizes
(give it overnight to make sure --- WAIT, WAIT, WAIT!) and check out any
error messages.

You *will* have to rename the volumes manually -- it's not done
automatically, because, actually, volume object names don't have to be the
same as the physical volume names (it just defaults that way when they're
created).

------------------------------

Date: Tue, 27 Aug 1996 20:28:48 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Using UIMPORT for account

>We have upgraded all of our servers this summer from 3.11 to 4.1 and we
>are using NDS.
>
>At the start of each school year, we generate a large number of computer
>accounts for all the incoming students and some of the returning students
>that did not keep their Novell accounts during the summer.
>
>We are trying to use the UIMPORT program to install about 2200 new accounts.
>On Sunday afternoon when we ran it the first time, it made about 300 accounts
>before it brought 3 of our fileservers down.  It appears that the NDS
>was constantly trying to update itself and just gave up, causing the
>3 filesevers to crash.

	Seems to be a familiar story. One of my NW 4.10 servers (a 486-50)
died several times from the same effect when a server/OU lower in the tree
was adding thousands of GroupWise accounts. The machine simply could not
keep up with network traffic plus the intense NDS internal data shuffling
and it ran itself out of memory and then out of business.

>Since then we have run the NDS Repair program to fix some problems and updated
>the NDS to version 5.1.  But we have only been able to run the UIMPORT on

	I presume you mean DS.NLM v5.01. Values above 5.01 basically belong
to the next version of NetWare (Green River), unless Novell has planned a
numerical hole for 4.10-specific upgrades.

>a small group of names (about 100+) before the servers start crashing again.

>Has anyone experienced this problem?  Is there a solution or method to
>create a large amount of new users (and delete then next summer) without
>having the NDS update until after we have completed the import?

	I think it's inherent in the, ah, er, scheme of things and one of
the reasons to partition cleverly. Spoon feeding is the only answer I know
of to keep under the 22 minute interval to complete a synchronization cycle,
and smaller spoons to help servers survive the cpu crunch of merging database
information. Less information about each user is another way of reducing the
overall data exchange.
	I can say that Novell is aware of the database operations problem
and is working on solutions. What the solutions will be, and when, I don't
know, but database merging is an old old problem with well known techniques
(say, indexed files) to keep the complexity from growing geometrically (as
it does with our current flat files).
	Joe D.

------------------------------

Date: Tue, 3 Sep 1996 16:36:09 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Re[2]: Subordinate Partitions

>>>I have attempted to delete a read/write replica of a partition only
>>>to find that its status has been changed to that of a "subordinate
>>>partition".
>>>
>>>I can't find any documentation on deleting a "subordinate partition".
>>>
>>>How can I delete such a partiton?
>>
>>You can't. A Subordinate Reference will always exist when you have a copy
>>of the parent partition on a server but not a copy of the child partition.
>>
>>I highly suggest getting and reading the file DSDOC.EXE from Novell. It
>>is a complete theory and operations guide to NDS. Everybody that manages
>>NW4 servers should read it.
>
>This may sound strange, but since a subref is only generated where the
>parent partition exists, but the child doesn't, then why not put a
>replica of the child on the server that has the subref??? That way,
>NDS will remove the subref. If you try to manually delete the subref,
>you're really asking for trouble!
------------
	Alas, it may be too late. The situation has occurred here, twice.
I can't recall the details, but the basic idea was to disconnect a server,
remove those objects from the other NDS servers and remove the disconnected
server object too. Oops, big time, $200 to Novell, do not pass GO, and
see indelible subsidary references.
	The approved method of removing a server is to have it running
normally, use NWADMIN/NETADMIN to remove all of its objects, and discover
one can't yet remove the server object. Then shut down that server and let
the outside remove the server object. The first step disconnects references
at both ends, by having each end cooperate with the other. If there is no
cooperation then the sub refs don't go away, ever, so it seems.
	I have been informed by the guy in charge of NDS that there will
be a fix for this made available sometime, but no word about when.
	Finally, when this general subject comes up folks usually don't
mention the versions of DS.NLM and DSREPAIR.NLM involved. These turn out
to be critical items, and the way to be safest is to load the latest
versions from the updates directory on ftp.novell.com and mirrors.
Certaintly trust not DS.NLM prior to 4.89, and get up to v5.01 if at all
possible. That makes life interesting when NW 4.0x servers are part of the
mix since they have earlier versions yet. [Hint, when Green River/NW 4.11
hits the streets you may readily see small NDS problems interoperting
between it and what you have now, unless Novell provides updates for the
prior versions of NW.]
	Joe D.

------------------------------

Date: Thu, 5 Sep 1996 11:17:14 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Subordinate Partitions

>>>>I have attempted to delete a read/write replica of a partition only
>>>>to find that its status has been changed to that of a "subordinate
>>>>partition". How can I delete such a partiton?
>>
>>Confusion can reign here if we are not careful!
>>
>>A sub ref is generated on a child partition's server(s) pointing to any other
>>server, that contains a copy (master, r/w r/o) of the partition above
>>that child partition's.   Provided of course, the child server
>>doesn't contain a copy of the partition above it.
>>
>>So the lowest server in the tree can have sub refs pointed at it (not
>>on it), if for example, it had a copy of the root partition but not copies
>>of partitions imediately below the root.
>>
>>In answer to the question above "why not put a replica of the child
>>on the server that has the subref?"  The answer is - The server that
>>has the subref, is the child,  or in it's partition.    Having a
>>copy of it's own partion causes it to subref to elsewhere.
>>
>>Unless you mean why not put a copy of the child on the server that is
>>the subject of the subref!   Then we go into how many copies of
>>partitions are actually needed
>
>This may sound strange, but since a subref is only generated
>where the parent partition exists, but the child doesn't, then
>why not put a replica of the child on the server that has the
>subref??? That way, NDS will remove the subref. If you try to
>manually delete the subref, you're really asking for trouble!

Quick notes on Subordinate References:

Subordinate References (subrefs) are one of those server-based NDS things.

Subrefs exist on servers which contain a replica (Master, Read/Write or Read
Only) of a parent partition, but do not contain a replica of the child
partition(s). Subrefs act as a pointer to the children ("do you know where
your children are?")

As an example:

	  [Root]
	     |
      Intermedia
	     |
   ------------------------
   |          |            |
CORP   MIS   SALES_

Server CORP_S1 (in the CORP container) contains:  R/W of [Root] partition
(which includes Intermedia) and Master of CORP container.

Since it has a copy of the parent [Root], it will need replicas of all child
partitions (CORP, MIS and SALES) or a subref will automatically be created.
It has the Master replica for CORP, but is missing any replica for MIS or
SALES, so it will have a Subref to each of them.

Subrefs *do* generate some network traffic. They are part of the replica ring
and anytime replicas are being updated, they get contacted briefly (just to
see if they're still out there, apparently!) It *is* important that they be
out there, however, as no partitioning operations can be run unless all
replicas (even subrefs) are available.

You can get rid of subrefs by replacing them with a Read/Write or Master
replica of the child partition(s). This, of course, will result in a great
deal *more* synchronization traffic as they will be actively involved in
sending/receiving changes to the partition.

You can also delete the parent partition's replica (unless you really need
it). In the example above, deleting the R/W of the [Root] partition would
leave  CORP_S1 server with Master of CORP partition and nothing else (subrefs
disappear).

Be cautious about replica placement. You don't want too many of them out
there, and you also don't want them across unreliable links (even subrefs)
as you may find yourself unable to complete partioning operations if your
link is down.

------------------------------

Date: Mon, 9 Sep 1996 18:26:40 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Isolated NDS

>I am due to set up a 2-user copy of Netware 4.10 in one of our teaching
>rooms as a 'distribution server' for Windows 95. We already have one
>Netware 4 server and therefore and NDS tree.
>
>I would like to be able to set the server up and remove it from the tree
>without any hassle; although it is possible to isolate the room from the
>rest of the LAN, I prefer a software approach.
>
>Should I create a separate tree, or add the server to the existing tree?
>Would it be better creating an organisational unit and simply deleting
>that when the server goes back?
---------
	This is a good spot to clarify the issue, maybe once and for all.
The bottom line will be "don't put teaching servers in a production tree."
	Imagine a play server, a test/teaching machine, in a tree with other
production servers. We all do that upon occassion. Everything is working
just fine.
	Now turn off that server and rebuild it from scratch as another name,
without taking any action on the main NDS tree. At this point the tree is
irreversibly harmed. Why?
	For two reasons.
	The first is if the downed server is in a ring of replicas (sharing
the same info amongst other servers) then the ring is suspended and all the
updates that go with it. One has to work at it to partition off the play
server and avoid all replicas from involving it, and that must be done before
downing the server.
	The second reason is there are pointers between that server and the
others. One set, called backlinks, point up the tree so one can find the
others by going up the tree. A second set, named subsidary references, go down
the tree. There are others too, such as aliases. Such pointers must be
dissolved by mutual agreement of holders of both ends, and they will NOT be
dissolved if either end is not present to agree. They must be dissolved to
have a healthy tree.
	If the pointers are not disolved cleanly, by having all servers
operating normally and admin uses nwadmin/netadmin to remove them, then
the tree is broken irreversibly (call Novell, pay US$200, worry a lot). It
is this circumstance which I keep harping on as being so easy to create and
presently impossible to cure ourselves. Dsrepair can NOT fix the pointer
situation at this time, but the latest version can remove vanished items from
replica rings. Ds.nlm v4.89 that ships with NW 4.10 is buggy and should not be
used with production trees; upgrade all servers to v5.01.
	That is my English language interpretation of affairs. Debbie may
wish to amplify and correct. Novell is welcomed to correct me (Hi Dave),
and maybe even mention the hope of unilaterally repairing dangling pointers.
	Jargon-speak renditions are found in Novell documents, without the
clarity of knowing the situation or consequences.
	Thus it is clear that play/teaching servers should be entirely in
their own trees and never in production trees.
	Joe D.

---------

Date: Mon, 9 Sep 1996 19:06:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Isolated NDS

	Adding one more item to my previous message on not putting test
servers in a production NDS tree.
	I suspect that a large number of sites do not create a secure time
structure for NDS time keeping. They probably let servers hear any time
statement, and when one is in the future we have a problem Houston (tm).
The default TIMESYNC Synchronization Radius is 2E+09 millisec, or 24.85 days.
Folks are curious about the year 2000 effect, and we can depend upon at
least one person trying it. The gotcha's come from that 24 day window
within which synchronization is believed. Other gotcha's may arise from
further in the future but I haven't tried that here.
	A proper NDS time topology has servers listening and believing
information from only particular named servers, never from whatever is on
the wire. And we all check the Bios time/date when booting a server machine,
right?
	Joe D.

------------------------------

Date: Wed, 11 Sep 1996 16:41:53 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Detaching from the tree.

We have 50 something Novell 3.11 file servers and three 4.1 servers,
running in the NDS mode.  How do I take one of them right out of the NDS
tree and run them in the bindery mode?  I need to create a print queue
and a print server in the bindery mode but it won't let me right now
because "the file server is not knows to the bindery".
------------
	You've grasped the bull by the wrong end.
	What you want is supporting a bindery level external print box,
right? So create a print queue which will be served by than box's name,
but do so in bindery emulation mode of Pconsole (see screen bottom, F4 key).
In addition, you must have bindery context set on the NW 4 server.
	Let's try that again. The tiny box (I am presuming) does not speak
NDS but it does speak Bindery stuff, and it is behaving as a NW print
server. If so it advertizes a name, which you must use when coupling the
queue with the external print server via Pconsole.
	I did all this a few weeks ago for a NW 4.11 server and it works
just fine.
	NW 4 servers will not run without directory services.
	If you want NW 4 manuals again please visit netlab2.usu.edu,
cd epub, or netlab1.usu.edu, cd pub/mirror/epub.
	Joe D.

------------------------------

Date: Fri, 13 Sep 1996 14:17:46 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Making a group a member of a group

>>I have the following groups:
>>
>>nogroupmail.vb.tcc
>>everyone.student1.vb.tcc
>>
>>When I try to add the groupeveryone.student1.vb.tcc to the group
>>nogroupmail.vb.tcc  I cannot.
>>
>>Is there any way to make a group a member of group?
>
>Groups contain user objects, not other groups.  Get a copy of John Bairds
>JrbUtils NDS utilities (the registered version) and use GrpAdd
>nogroupmail.vb.tcc #everyone.student1.vb.tcc, apart from that, the only way I'm
>aware of is to get a list of users in the group and manually add them.

Pedantically groups can contain other groups, but as filestore rights (and
group membership) is not transitive (if A=B and B=C A!=C) then it has no
effect!

Similarly a user  .joe.finance.salford  who is a member of
.print-managers.purchasing.salford  does not gain the access rights assigned
to [the container]  .purchasing.salford:
	user securuty equal to group
	group security equal to container
	user NOT security equal to container

This is quite nifty if you want a central support group who look after
printing and need access to other's printers but don't want them to have
implict rights from the other department. if you wanted joe to have rights
to everything in .purchasing.salford then you make joe security equal to
the container.

------------------------------

Date: Mon, 16 Sep 1996 18:22:24 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: 4.1, move container %/or server to another tree

>We have a 4.1 container that includes a server, users, printers, etc.
>We are interested in moving this entire container to another tree.
>
>Does anyone know of a way to move an entire container?
>If not, is there at least an easy way to move the server?

I don't think that you can move a container and/or server to another tree
easily. Looks to me like it's a remove and rebuild operation.

Easiest way to remove/move a server:
1)  Remove replicas from the server
2)  Remove the server from the tree (Partition Manager)
3)  Remove Directory services from the server
4)  Down server - wait - bring server back up (just a safety measure -- I'm
not sure this really *does* anything, but it's always worked for me)
5)  Reinstall DS on the server -- install into the "new"  tree

------------------------------

Date: Tue, 17 Sep 1996 10:49:14 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: NDS Problem! Urgent!

>The following message appeared after to run LOAD DS.NLM
>
>Directory Services:  Could not open local Database, it is inconsistent
>Try to correct the error with DSREPAIR.NLM
>
>After to run DSREPAIR, appeared:
>
>DSREPAIR-4.10-015: Could not establish full access to record manager
>				Program execution cannot continue normally
>
><snip>
>
>009: Directory Services remains locked, error -618

A -618 error is Inconsistent_Database and indicates that an error has been
encountered in the database itself. Usually this means that the number of
entries in a container doesn't match the number stored in the container's
entry.

Run DSREPAIR *ONLY ONCE* (which you've already done).  If the error still
persists, it probably means a call to Novell. *Don't* run DSREPAIR again (if
you haven't already -- can't really tell from the message), as this will
overwrite the .OLD files and make it impossible to restore the database. Once
this has happened, you may have to remove DS from the server and reinstall
it.

------------------------------

Date: Fri, 27 Sep 1996 14:44:28 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Netware 4.1 on a 33 MHZ server?

>According to a Netware 4.1 book by QUE, it is either not wise or not
>possible to install Netware 4.1 on a server with less than a 50 MHz
>processor. We only have a 33 MHz processor. Do you know if this might have
>been a reason why I had so much difficulty installing 4.1? Or, if it can
>be installed what kind of performance hindrances and related problems
>might ensue?
-----------
	You say two different statements are in that book: not wise, and
not possible. Perhaps a rereading would indicte the intent of general
advice and the reasons why.
	NW 4.x will run happily on a 386 and up, including lowly 386-16/SX
machines. Please do read Novell's docs on the matter.
	NDS uses lots of cpu cycles in bursts to do its job, and the more
cpu power there is then the faster that job gets done. A 486-33 will do the
job, since I have such servers. However, one can create such a nightmare of
complexity and quantity with NDS that the job becomes very difficult for any
machine. The trick is intelligent NDS design, strongly flavored with
hands-on experience and a network analyzer (nice but not required).
	Better reading is Novell's book "Novell's Guide to NetWare 4.1
Networks", Novell Press, written by two members of the NDS "tiger team"
(Novell Consulting) who go round designing and fixing trees for big bucks
customers. Excellent value for the money, the book that is.
	Joe D.

------------------------------

Date: Mon, 7 Oct 1996 14:31:59 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Continuing saga of NW4.1 server

>My plan of attack this morning was similar to what I've done with
>NW3.x servers:
>
>1. install netware under a temporary name
>2. restore the files from backup
>3. reboot as the old server as of the backup date.
>
>The only snag: it's not working as expected. I went through the
>reinstall of NW4.1, which complained about not having the master
>replica for itself. This was Friday evening. This morning I decided
>on the temporary name deal & it appeared to work OK, except now I
>keep getting a 673 error when I attempt to set up the bindery context
>on this server.  The documentation-on-CD provides no real ease of
>use, but I'm certain I'm just missing something.
>
>The situation basically is:
>
>Server: GOLIARD - has the root master partition, and has a read/write
>replica for AMHERST.
>
>Server AMHERST - has it's master partition and a read/write replica
>of GOLIARDs - dies on a Thursday afternoon. Appears to be a bad
>disk.
	<omissions>
------------------
	One important key is the existance of a copy of the NDS information
for that server is held on others. Use that key.
	This is operating from memory, so please triplecheck Novells words
on the matter. Remove NDS from the troubled server. Then reinstall it into
the tree as its old name.
	Normally at this point there would be a fatal blockage because the
magic cookie of this server has been lost and the other servers would
declare it to be an imposter. But, things have improved to the point that
if you know the password of the admin one level up then you can install
the server. This will grab the replica scoop from the good servers and
you are on the air.
	What does not happen is uniting NDS names and NDS object id's.
Thus you will have to go back and reassign ownerships to this and that.
NW 4.11 is supposed to cure this small problem when using tape backup and
restores.
	Best to restore autoexec.ncf from tape too since it has the proper
info about bindery context and so on.
	What one should not do is get anxious and run dsrepair on the other
servers. It won't help and could make matters nearly irreversible.
	What one must do is upgrade all NW 4.10 server's DS.NLM to v5.01
from the update kit.
	Joe D.

------------------------------

Date: Tue, 8 Oct 1996 14:39:35 +0200
From: Hans Nellissen <dbphilos@UNI-DUESSELDORF.DE>
Subject: Re: Backuping Up NDS to Floppies

>I recall that someone had mentioned there was a utility that was able to
>backup nds to floppy . Does anyone else recall what the name of this
>utility was ? or Where it is?

Look for a zip-file called dsback.zip. My version was from

<snip>

---------

Date: Tue, 8 Oct 1996 08:55:04 -0700
From: Dave Quecke <djQuecke@WORLDNET.ATT.NET>
Subject: Re: NOVELL Digest - 7 Oct 1996 to 8 Oct 1996 - Special issue

Here's the update to the URL that John Croft passed along.

	ftp://ftp.rz.fh-hannover.de/mnt1/novell/uti/dsback.exe

---------

Date: Wed, 9 Oct 1996 18:19:39 -0400
From: "Martin C. Mueller" <mcm@MATHEMATIK.UNI-KL.DE>
Subject: Re: Backuping Up NDS to Floppies

>I recall that someone had mentioned there was a utility that was able to
>backup nsd to floppy.

You could do such a thing by copying sys:\_NETWARE to disk via any server-
based shell like jcmd or nwshell. Restoration might succeed iff

- there's only one server in the tree - otherwise the synchronization
  problems will most probably kill you
- the backup's not to old (maybe hours)
- the file system retained the user id's

You can tweak the second point by fumbling the system clock - if that seems
wise.

After all - there's no such thing as NDS backup to external media up to
4.10 and you have to resort to replication. That will presumably change
with 4.11.

------------------------------

Date: Thu, 17 Oct 1996 10:18:18 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DS Removal from NDS

>Have a server (4.1) that has crashed.  It is not the primary server.
>How can I get this server out of the nds?
---------
	It must be done carefully. Rebuild the server and reinstall it into
the NDS tree under its usual name. Then follow Novell's instructions to
remove the server and contents (Hint: nwadmin, remove all items related to
that server WHILE the server is active in the tree, and only then down the
server and use nwadmin to remove the server object).
	Joe D.

------------------------------

Date: Thu, 17 Oct 1996 15:41:49 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DS Removal from NDS

>>>I have a server (4.1) that has crashed.  It is not the primary server.
>>>How can I get this server out of the nds?
>>---------
>>	It must be done carefully. Rebuild the server and reinstall it into
>>the NDS tree under its usual name. Then follow Novell's instructions to
>>remove the server and contents (Hint: nwadmin, remove all items related to
>>that server WHILE the server is active in the tree, and only then down the
>>server and use nwadmin to remove the server object).
>>	Joe D.
>
>It's occurred to me that the "It must be done carefully" is contrary
>to NDS's original design theory. In otherwords, the NDS is
>distributed in order to protect itself from a single server crash,
>yet a single server crash spells "trouble" for the NDS - due to
>replica syncronization.
>
>Am I missing something here?
----------
	No, that's a very reasonable requirement to impose. Alas, things
are messier than that due to pointers between components and those replicas
living in places where the real objects are not. Replicas are for speed,
though until NW 4.11 they were also for safety, and in principle none is
required. Without replicas we just have pointers to external things, but
those pointers never seem to age away naturally (they hang on for dear
life worse than Appletalk routing rumors).
	In the past there were several fatal "features" of NDS which
precluded my recommending it in production mode. One was rebuilding a
server from scratch would block that server from reentering the tree under
its old name; magic cookies didn't match and the new version was declared
to be an imposter. That was fixed by knowing the username of the admin
of the next level up. The second was removing a component of the tree
without notice left indelible references to it; both ends of a reference
need to cooperate to remove the ref, else it stays. As of DS.NLM v5.70
we can now unilaterally remove these strays. The third was inability to
safely restore a server from tape. NW 4.11 has finally dealt with that problem
in its new TSANDS and TSA410 NLMs.
	Thus NDS should be viewed as a community affair, where orderly
actions are required to avoid over-reactions and misunderstandings. We all
need to go to NDS Law School to learn them, and there is plenty to learn.
	I think it's clear that NW 4.11 is the first "robust" issue of NDS
based NetWare.
	Joe D.

------------------------------

Date: Fri, 18 Oct 1996 17:56:44 -0500
From: rkennedy@EOSINC.COM
To: netw4-l@bgu.edu
Subject: Re: NDS Syncronization Intervals

>>You can find some of this information in "Netware 4 for Professionals", a
>>New Rider Publishers book from back in 1993. The ISBN is 1-56205-217-9.
>>Also, I found the informatoin provided in the Novell 532 Design and
>>Implementation class a real help with some of these type of issues. Hope
>>this helps you out.
>
>I'll check it out.

If you receive the Novell Application Notes, or have access to it
through Compuserve, there was a series of very good articles on the
issues involved.  On larger trees with high communications needs, in
addition to NDS traffic, Novell actually recommends considering the use
of separate trees where possible.  Future releases of their NDS
management tools will include the ability to manage areas within the
same tree as if they are separate trees to reduce synch traffic.  I've
also seen some information that servers cannot synch over two separate
56K lines -- in other words two servers connected through a central
location and on separate 56K lines.

Don't forget too of how your time synch can be configured to allow
turning off SAPs for time synch.

I'm sure Novell has some "white papers" on the subject at their web site
or there might be some information at the Netware Connection site:
http://www.nwconnection.com

Let me know what information you find out as we run a number of 56K
lines within a 4.x environment of about 150+ servers and are looking at
ways to make the use of the lines more efficient.  We have tried to
limit server communications through continual review of our partitions,
time synch configuration, and some SAP filtering.  The communications
folk are looking at various switches etc. but I don't know if they have
come to any conclusions yet.  We are also looking to implement NLSP soon
as our routers will now support it.

---------

Date: Sat, 19 Oct 1996 11:58:13 +0200 (METDST)
From: Jacek Przerwa <jprzerwa@doctorq.com>
To: netw4-l@bgu.edu
Subject: Re: NDS Syncronization Intervals

>I am designing our NDS tree to work well on 56k WAN links.  I need to find
>out where I can find specific information regarding default NDS
>Syncronization Intervals, and modifieable parameters.

There are some modules, which help you to filter NDS traffic (it may consume
all WAN bandwith, if not properly implemented).

You can gather some knowledge from attending courses 532 Design and
Implementation (how to design NDS tree to avoid unnecessary WAN traffic) and
740 Internetworking with MultiProtocol Router (how to filter the NDS WAN
traffic).

You can also download (support.novell.com, if my memory serves me) the NDS
documentation-dsdoc.exe file (I am not sure about the name), which covers
issues like NDS modifieable parameters.

---------

Date: Sun, 20 Oct 1996 00:11:55 -0500
From: rkennedy@EOSINC.COM
To: netw4-l@bgu.edu
Subject: Re: NDS Syncronization Intervals

Sorry to post an update to my own response, but I was finally cleaning
up my office and "low and behold" there were the App Notes I referenced.
Specifically:

"Universal Guidelines for NDS Tree Design" (Novell Application Notes,
April 1996)

"Ten Proven Techniques for Improving NDS Performance and Reliability"
(Novell Application Notes, April 1996)

"Managing Novell Directory Services Traffic Across a WAN: Part 1"
(Novell Application Notes, June 1996) (I haven't seen part II yet)

"A Study of Novell Directory Services Performance and Benefits" (Novell
App Notes, July 1996)

There was also a supplement to the July App Notes issue from Novell
research titled "Connecting the Enterprise: Wide Area Networking
Technologies" including articles on Bridging and Routing, Wide Area
Networking, ATM and Frame Relay, Remote Office Connectivity, NetWare
Link Services Protocol, and VSAT Networks.

You can order these as back issues from Novell by calling 800/394-5088
in the US and Canada, or, 801/342-3451 for other locations.  The cost is
$8 per issue up to 9 copies, then the price reduces depending on the
numbers ordered.

------------------------------

Date: Tue, 22 Oct 1996 15:36:28 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Renaming Volumes in 4.1 Netware

>When dismounting, then renaming a volume in 4.1, should one delete the
>old object first from nwadmin or the reverse?
-------
	The general rule about NDS that I try to follow is:

	Change things when all holders of the property are communicating
because such relationships require all participants to agree.

	If you just zap the volume name then the other informants are not
told, can't come to a unanimous agreement, and you have a broken tree.
	The only exception, so far, appears to be server objects themselves,
where to remove them from the tree the server must be shut down (presumably
after removing directory services). Other objects get the full agreement
method, via netadmin/nwadmin.
	Joe D.

------------------------------

Date: Thu, 24 Oct 1996 18:13:09 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Client for 4.11?

Joe Doupnik wrote....
>	Client32 is needed to run ndsmgr (aka: partmgr in GUI clothing) and
>nwadmn95 (public\win95, slicker nwadmin), and nwadmn3x (public). Nwadmin is
>still present (public) as before. The Client32 material on the NW 4.11 CDROM
>is not required per se.

However I will say that the partition continuity check under ndsmgr you get a
very nice display of servers vs. partitions with icons denoting the state and
little warning tri-angles if there is a problem. clicking on the ico brings up
a dialog box with the last DS error in it, and a questionmark icon next to it.
clicking the questionmark gives you a clear description of the error, and what
you need to do to fix it.

Now, if it could produce this for the whole tree....

PS. You don't need a 4.11 server in the tree for this stuff, just the latest
and greatest DS.NLM on the servers and client32 on the workstations

------------------------------

Date: Sat, 26 Oct 1996 12:11:36 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: NDS 4.1 / Login to another container

>Surely someone has done this, but I can't figure it out.
>
>I have Netware 4.1 on multiple servers in different cities.
>I have a frame relay WAN.
>
>I have some users who need to travel to one of my branch
>offices, and login on that server's network.  I have been
>asssuming I should handle that with a User Alias object
>in NDS.  But I can't get the User Alias to run the container
>login script that resides in the other city.

I've always thought that Novell made that sound entirely too easy to do!

The fact is that the alias user login will point back to the original user
and run the original user container login script. It *will not* run the
alias container login script unless you use some variables to point it to
the right place.

It's probably easiest to put your alias users into groups and then use
IF..THEN statements in your original user container login script(s) along
the lines of:

IF MEMBER OF "ALIAS_USERS" THEN
   INCLUDE %REQUESTER_CONTEXT
   EXIT
END

Double-check me on the variable -- but I think that's the right on off the
top of my head!

------------------------------

Date: Mon, 28 Oct 1996 11:52:44 +0000
From: Richard Klemme <rklemme@OZNET02.OZEMAIL.COM.AU>
Subject: Mixing 4.10 & 4.11

>Q2: If so, are there (and would it be possible and wise to use them)
>superior NDS management tools on that 4.11 server, to sort out a
>problem on my tree (illegal and hidden object, prevents me from
>replicating one of the partitions).

There is a great utility we bought called Bindview EMS which runs
under Windows and does this sort of analysis for invisible objects
and other reports such as server info, secuity checks including
password analysis, etc. It is pricey though, but worth it. It
is licensed by tree, then by # of user objects and by # of servers.
There is the 4.x module out now, with 3.x and NT to follow.
We got it (one reason) as there was no equivalent for SECURITY.EXE
on 4.x (but this does heaps more) when we upgraded from 3.11.

There is info on http://www.bindview.com/

Also I recall there was utility may also do this on the
Novell Consulting Services (NCS) home page, which has
heaps of other goodies.

Its at http://www.novell.com/corp/programs/ncs/
under the toolkit section..

I would highly recommend this page!!

------------------------------

