
----------------------------------------------------------------------
NOV-NDS5.DOC -- 19971107 -- Email thread on NetWare Directory Services
----------------------------------------------------------------------

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




Date: Wed, 9 Apr 1997 15:43:49 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: Netware 4.1 Security

>I am running 9 Novell 4.1 servers over a WAN with container
>administrators in each state. How can I check users security,
>i.e. who has supervisor access etc. at both the NDS and file levels.
>
>I am aware of a utility that came with Netware 3 called SECURITY.
>I don't have a copy of this and am not sure if it would be of any
>use if I did have it. I would assume it would only work within a
>bindery context and wouldn't know about NDS rights.
>
>I have used RIGHTS /S /T from the [root] context. Is this the only way?
>or is there a another?

I use RIGHTS VOLUMENAME: /T /S to get trustee assignments for all
directories/files on a volume. Usually port this off to a file for easier
evaluation.

For NDS rights, I CX to the [Root] of the tree and type:  NLIST * SHOW ACL

This will show you the Access Control List (a.k.a. Object Trustees List)
for all objects in the [Root] context ([Root], Country, Organization) with
trustees and all Object and Property rights granted shown.

I then run this for any object I want to check trustees for (i.e., NLIST
"ORGANIZATIONAL UNIT" SHOW ACL /S). Usually run it for Organizational Units
and Server objects. (Sometimes for volumes as well, since people seem to
feel that granting NDS rights to volume objects will somehow translate into
file system rights).

Last thing I do is to run    NLIST USER SHOW "SECURITY EQUAL TO" /S    for
a listing of all security equivalences (groups, org.roles, other users,
servers, etc.)

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

Date: Sun, 13 Apr 1997 23:09:16 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: help with 672 NDS error

>We are unable to see a server (PRESCONT)  from another server (RYDDI).
>PRESCONT has the master replica of  a child partition (CONTRALORIA), but
>the PRESCONT server can see the RYDDI server but it shows a 672 error.
<snip>
>In RYDDI server (partition ROOT).
>      * Unattended full repair:
>This option always has errors, and they are "Illegal attribute for
>external object".
<snip>

External object at it again...

Besides the "Novell FAQ", Novell has this file called DSDOCxxx.
You can FTP this from the Novell site. It has insight information for you.

Because you have several problems I would advice following the
instructions that are in DSDOC.

It will probarly boil down to this:

Make *sure* time synchronization is OK on every server.

Make use of Partition Manager to pinpoint the replica that is most up
to date.  Back it up.  Make sure it's errorfree.  Back it up not
overwriting the former backup.  You might want to use DSMAINT for this.
Check and repair external addresses.  Send all objects to all replica's.
If some replica fails do the 'check and repair external addresses' routine
on that specific server also.  If that fails repair the DS and try again.
Be careful when the master replica has errors and a read/write replica
has not and/or is more up-to-date (speaking hours not minutes here).

Do one replica/server at a time.  Put time between your actions (let the
synchronization processes die out first).

If you see a replica that is days behind in synchronization status
then, ONLY if you have this option, delete it and recreate from scratch by
making use of your other (read/write or master) replica's.

When you're errorfree, replica synchronized and time synchronized
again decide about making use of recommended Novell patches.

If you can't follow what I'm saying then please consider consulting
a local specialist or spend $200 on a Novell tech call.

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

Date: Mon, 14 Apr 1997 21:03:59 -0400
From: Greg Small <gsmall@SYMPATICO.CA>
Subject: Re: SECURITY_EQUALS Bindery Property & NW 3.12

>"This user's SECURITY_EQUALS property has group <groupname> stored
>beyond the maximum of 32, so the group is not considered when
>determining Security Equivalences, Trustee Directory, and FIle
>rights. The group membership is ineffective and should be deleted."

There is a 3rd party utility called OVER32.ZIP which I have used to
determine who was near, at or over 32 entries in the table.

I believe this will also allow some kind of bindery change to make the
entries over 32 work as expected.

If you cannot find it EMAIL me at gsmall@spar.ca tomorrow and I'll ship it
off to you.

IMPORTANT NOTE -- FOR THOSE USING NW 4.1 and PROBABLY 4.11 -- the
equivalent problem shows up when either 57, 58 or 59 entries (I forget
exactly which) are reached.

I only used to see the OVER32 in 3.1 and now the "over5?" in 4.1 when I was
testing a lot of new apps and had all sorts of groups enabled.  The users
never reached this limitation -- that Novell obviosuly never expected ANYONE
to reach.

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

Date: Wed, 16 Apr 1997 14:01:52 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Admin User Corrupted

>My NW4.11 server crashed during a Backup Exec backup. Upon rebooting
>the NDS system was out of whack, I ran DSREPAIR and all is fine
>*except* that user ADMIN is now an "Unknown" object (as opposed to
>being a user object), I cannot login as ADMIN, unfortunatly I did not
>grant another user supervisor equivelency so when I run netadmin.exe
>as a regular user I don't have the privilege of deleting and
>re-creating the Admin object.  I can login as SUPERVISOR in bindery mode,
>but I can't run netadmin.exe without NDS login.

There is no utility (as far as I understand) for adding Admin-like rights
to an object in a tree.  If there is one with rights to [Root], you need
to call Novell, and ask their expert hackers to add or fix the Admin
account, using their special magical tools.

For future reference, making an object security-eqivalent to Admin
wouldn't fix the problem, because if Admin goes away, the other account
becomes security-equivalent to no one!  You need another account with
rights to [Root], not just equivalence, to cover that base.

---------

Date: Wed, 16 Apr 1997 14:33:01 -0600
From: Steve Miller <smiller@FTJ.COM>
Subject: Re: Admin User Corrupted

>My NW4.11 server crashed during a Backup Exec backup. Upon rebooting
>the NDS system was out of whack, I ran DSREPAIR and all is fine
>*except* that user ADMIN is now an "Unknown" object (as opposed to
>being a user object), I cannot login as ADMIN, unfortunatly I did not
>grant another user supervisor equivelency so when I run netadmin.exe
>as a regular user I don't have the privilage of deleteing and
>re-creating the Admin object.  I can login as SUPERVISOR in bindery
>mode, but I can't run netadmin.exe without NDS login.

There is a third party utility called MakeSU to make a new Admin object
from the console.  This utility is licensed to your tree.  A demo and
more info at at:

	ftp://ftp.netcent.com/makesu.zip.

I have not tried this program, but I like the other utilities put out by
this company, DreamLAN Network Consulting. ˙They make a toolkit (called
NDS Toolkit) that includes this utility or you can buy it by itself.
The last I knew the entire toolkit only cost $500 to $600.  I think the
MakeSU utility by itself might only be $100, and the guy at DreamLAN can
probably mail it to you.  Thats how we got our DSLogin utility from them.

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

Date: Sun, 20 Apr 1997 18:47:40 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: Remove NDS, corrupt ADMIN

>The install utility (NW411) has an option to remove NDS from the
>server. Unfortunatly, before it will allow me to remove NDS it asks
>for the ADMIN password, my ADMIN account is corrupt and unavailable.
>
>If I unload NDS (unload nds.nlm) and login as supervisor, in bindery
>mode, could I not delete some files at yhe DOS prompt, the NDS files?
>Is there a way? I could then reinstall NDS and voila, I would have an
>ADMIN account again.

Try loading INSTALL as follows:   LOAD INSTALL -DSREMOVE

This allows you to "force" the process, even when you get to situations
like you've described. After having told you that you have to login as
ADMIN (and you fail to do so), you'll get a "Would you like to continue
anyway?" type of message.

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

Date: Mon, 21 Apr 1997 14:27:41 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Compromise of a single NDS server

>Is it true that in Netware v.4.x, if a single server is compromised the
>whole NDS network could be compromised? To ellaborate:
>
>Say I get a rconsole password for a single 4.x server
>Can I create/access accounts on other servers in the tree (using commonly
>available hacking utilities like setpwd.nlm or burglar.nlm)

No, not the whole tree, but you would be able to modify the password for
any account that server held a RW/master Areplica for in the same way as
you can any account on a NW3.x server you have the passoerd for.

On our servers the rconsole passord bear not relationship to the ADMIN or
SUPERVISOR passwords, gaining rconsole access to the server leaves the
monitor lock-screen hurdle [we leave our console locked by default, even
in the machine room].

Security requires thought, not questions.

/please/ no knee-jerkreactions here. NT security is worse.

I don't doubt for a moment you're an IS Security Auditor -- your question
was simplistic; I know the kind since I'm getting atleast one dumb
questionaire a week from our Auditors on network security.

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

Date: Tue, 22 Apr 1997 10:31:22 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: ? Admin password

>Does anyone know how to recover an ADMIN password
>on a Novell 4.1 network; without reloading.

I'm assuming the problem is that you don't have an object with Supervisor
rights to [Root], right?  There are two things you can do:

1) Call Novell's technical support, and they can dial in to your network
   and create an object with rights to [Root].  $200, quality work.

2)  Have a look at

http://ourworld.compuserve.com/homepages/dreamlan/toolkit.htm.

"NDS Toolkit" is produced by DreamLAN Consulting Ltd.  (The president of
this company is Peter Kuo, author of one of my "must have" books,
"NDS Troubleshooting.")

There's a utility called MakeSU that creates a user object as described.
I tried the demo (after the last time someone asked this), and it really
does create an object with Supervisor rights to the [Root].  But, the
Demo assigns the object a password and doesn't tell you what it is,
so it's essentially non-functional.

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

Date: Tue, 22 Apr 1997 16:17:43 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: NDS Merge Question

>When you perform a NDS merge my understanding is that there can be no
>objects at the root level at either tree, correct?

... of the same name, correct.

>After the merge all
>containers that were below the root in each tree now reside side by
>side under the single root. My question is...Do I need to wory about
>any of the objects within the seperate containers, i.e. duplicate
>account names, group names, etc? [snip]

Think about it in terms of "Distinguished Names."  Duplicate distinguished
names can't exist anywhere in the tree.  For example, if I have an
Organization named "Sales" just under the root, I can't have another
organization called "Sales" just under the root - they'd both be "O=Sales"
by their distinguished names.

Now, if I had an organization unit called Humans, and another called Cats,
I could have objects in both O's with the same name.  It makes sense,
because their Distinguished Names would be different.  E.g.
  CN=Felix.OU=Humans.O=Lifeforms
  CN=Felix.OU=Cats.O=Lifeforms

So, the objects have the same, but their "real names," their distinguished
names, are different.

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

Date: Wed, 23 Apr 1997 11:29:31 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: splitting up large student OU's

>I currently have an organizational unit with about 4500 student ID's.
>While it seems to work ok for the most part, some of our performance
>problems are undoubtedly caused by the large number of objects in the OU.
>I am planning to split the OU into sub-containers but would like to see
>what others are doing in similar situations. We have 4 servers handling
>the 4500 users, so my initial thought was to create a separate OU for
>each server an put 1/4 of the objects in each OU. This would result in
>somthing like username.server1.student.acadia. If we did this approach I
>would use some easy scheme to determine which server the student was
>located on, although undoubtedly there would be confusion. Alternatively
>I could avoid a server-centric OU design and set up several OU's based on
>last name. This might produce something like username.abc.student.acadia
>and username.def.student.acadia and so on. I would have to assign home
>directories to the OU's to try to keep things as uniform as possible.
>While this approach avoids assigning a specific server to a student
>(which perhaps makes things a bit more flexible), it doesn't really avoid
>the confusion.
>
>What schemes are other people coming up with? I'm leaning to the server
>centric design but that's probably because I'm still thinking in
>simpler bindery-based terms. The best solution is a single OU like I have
>now, but unfortunately that doesn't appear to be an option.

We grappled with this problem late last year when planning for upgrading
our two student servers from NW 3.11 to 4.11. Under 3.11 we had students
with surnames beginning A-L on one server and M-Z on the other giving
a roughly 50-50 split. The total student usercodes is ~5000. What we have
done under 4.11 is retain this approach but to use two containers per
server, so the students are in ae.ug.lu, fl.ug.lu, mq.ug.lu or rz.ug.lu
depending on the first letter of their surname (and hence username),
where ae.ug.lu contains those students whose usernames begin with 'a'
through 'e'.  Students in the first two containers have their home and
mail directories on one server, students in the 2nd two, have them on
the other. To date, we have not encountered any problems with this scheme.

---------

Date: Wed, 23 Apr 1997 12:54:32 -0400
From: Doug Wilkinson <Doug_Wilkinson@BROWN.EDU>
Subject: Re: splitting up large student OU's

We are using something similar to what you suggest.   Our
accounts are divided into 26 OUs based on the first letter of their login
name.  We have about 14000 accounts setup this way and it is working ok so
far.

Keeping 26 partitions and three replicas of each isn't that big of a deal
as one might think.  Of course, the day we have to repair a serious NDS
problem may show us otherwise.  It may be overkill, but it makes it simple
for the users.

Everything is on a LAN, no WANs or slow links here (luckily).  I'm sure that
making fewer divisions would be just as easy.  DSREPAIR doesn't take long to
run (about 5 mins) but the only time we have run it is if a server abends,
and not because of some problem with NDS itself.

To deal with the multiple OUs, programmers here wrote a front end for
Windows/DOS and Macintosh workstations to automatically append the x.users
to the login name so the user doesn't have to know what container they are
in (not that it would take a genius to figure it out :-).  User creation is
done through UIMPORT from an external database.

Breaking users up by server wasn't a consideration for us due to the number
of divisions we needed and also because the idea of using server names
seems so anti-NDS.  Using container names based on the user's name was at
least the lesser of two evils.

---------

Date: Thu, 24 Apr 1997 13:28:42 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: splitting up large student OU's

>students randomly set in containers. (What if 50% of the students are
>named janssen?)

With 5000 students you are not going to get much change from year to year
in the alphabetic distribution of surnames. We debated at length how to
divvy the students between servers when we changed from one student server
to two. We looked at doing it by course or faculty but because many of the
papers making extensive use of computers are common to more than one course
there was no obvious way of doing this. One advantage we saw in doing it
by course was that if a particular server went down, then either all or none
of the students in a lab class would be affected. However, our server
downtime last year during teaching time was less than half a day per
server and most of that was due to the 35 minute startup time. With 4.11,
startup time is no more than 5 mins.

In the absence of any obvious way of dividing the students between servers,
we chose to do it alphabetically so that given a username we would know
immediately what server they were on. In deciding to use A-L and M-Z
which gave close to a 50-50 split, I checked this against the number of
pages for each in the local phone book and it matched pretty well. There
has been some drift so the distribution is not as close to 50-50 as it
once was, mainly due to greater numbers of Asian students, many of whose
names begin with 'C'.

---------

Date: Thu, 24 Apr 1997 02:47:41 +0100
From: Philip Zelazowski <phil@ZEMPIRE.DEMON.CO.UK>
Subject: splitting up large student OU's

>I currently have an organizational unit with about 4500 student ID's.
>While it seems to work ok for the most part, some of our performance
>problems are undoubtedly caused by the large number of objects in the > OU.
>I am planning to split the OU into sub-containers but would like to see
>what others are doing in similar situations. We have 4 servers handling
>the 4500 users, so my initial thought was to create a separate OU for
>each server an put 1/4 of the objects in each OU. This would result in
>somthing like username.server1.student.acadia. If we did this approach > I would use some easy scheme to determine which server the student was
>located on, although undoubtedly there would be confusion. > Alternatively I could avoid a server-centric OU design and set up
>several OU's based on last name. This might produce something like > username.abc.student.acadia
>and username.def.student.acadia and so on. I would have to assign home
>directories to the OU's to try to keep things as uniform as possible.
>While this approach avoids assigning a specific server to a student
>(which perhaps makes things a bit more flexible), it doesn't really
>avoid the confusion.

I've got only 1500 students at my school, but still a handful with a
throughput of some 500 a year. With this figure in mind I designed my
NDS over four geographic sites, the degree course, the year a student
graduates. The year containers are further grouped using groups to
demonstrate what kind of degree, ie 2yr_BA, 3yr_BA, MA. The starting
context for each site is the same, the organization itself - the school
name .o=ccad (Chelsea College of Art & Design.) The student has learned
the syntax for their rather long login name like this: myname.year I
finish.what I do.where I do it from - smithj.98.public_art.limegrove
They use the same login name at any machine from any of the four sites
scattered over west London, the system login scripts are duplicated
throughout the year containers (which contain the students) and will map
the student's data, email, preferences drives to the student's local
site server, while mapping operating system and applications drives and
machine specific files from the server local to the login. The file
structure is much simpler, the volumes are aliased as system,
applications, data, where system and applications are mapped to the
server local to the login and data mapped to the student's home server.
During login, the original context is changed to a container called
resources where all the aliases live with user friendly names to print
devices, volumes and so on. There's a resources container hanging off
each site container. The data volumes are organised (from the point of
view of the student) as data:students\year\login_name.

Though there is a huge amount of work in preparing just one account, the
NDS and file system is so sweet and easy to maintain that it it worth
it. The advantages from my point of view is that it is very easy to
train people up to login and use the network and resources. Dealing with
the throughput on the NDS is very simple - you add new year containers
for the new input, you delete old year containers as they leave you! The
same with the file system - you delete a year, you add a year. Once the
user object is created then my interest in the NDS is purely and quite
literally year in, year out. However, the complexity of the NDS reflects
not only logical organisation from an administrative but also from a
communications point of view. Using the free 1st Mail that comes with
netware it is very easy to email a class of students specifically, ie
3yr_BA_grp.99.fine_art.manresa_rd. This makes life easy for tutors and
administrators within the school. General email is handled differently.
I use netscape and a pop server for each operating system, with the pop
servers all converging on one set of email directories in the data
volume local to the user's home site. There is added name space support
on this volume so different operating systems can read and write the
same set of files. This makes for a totally uniform email platform
across all operating systems that is simple to use, works perfectly,
free and looks good. (We use netscape for nearly everything cyber.)
Emailing is simply addressed to login_name of the recipient if local, or
an ordinary email address out of the college. Email in is to
login_name@chelsea... This extra feature almost doubles the time it
takes to create a user account with the creation of individual email
directories, updating of pop server ini and mail policy files,
individual sig files and addition of certain individual rights at the
user object level.

All in all the NDS and file system structure are very easy to maintain a
steady throughput of students. The server load across sites is evenly
balanced - small site, small server; big site, big server. The only
problem was it took half an hour to build an account manually.  I wrote
a suite of basic programs centred around the netware uimport utility.
Information in via a form is fullname, login_name, degree, year of
graduation. Every 9 seconds a perfectly formed user object with all the
files and directories and rights and personalised ini files is created.
I am further automating this process so that it becomes part of
enrollment so that a) information needs to be typed in only once, and b)
it's out of my hair.

---------

Date: Thu, 24 Apr 1997 15:58:50 EST
From: "joe_flowers@ncsu.edu" <novell@HCL.CHASS.NCSU.EDU>
Subject: Re: splitting up large student OU's

We have ~14,500 student accounts here in our tree. Many many more
expected. Currently, the accounts are held on 3 NW 4.10 servers with
a little home directory space and WinPmail (NDS mode).

Some NDS partitions have been created (16 so far) in this structure to
help reduce slow-ups due to NDS synchronization.

Since we're expecting the ~14,500 to eventually turn into ~60,000, we
create student accounts like, for example,
Joseph Lynn Flowers,
.jlflower.j.f.student (which implies 26x26 containers)
Corresponding email address is jlflower@email.chass.ncsu.edu.
(I had to create another "helper" program for Mercury, to keep
Mercury from bogging down the servers when it was doing searches for
user objects in the .student structure. This problem blind-sided me.)

We divide up home directory locations (volumes) based on the first
letter in the student's last name versus student population distributions
and volume sizes.

We use the "#include .f.student" line for the "j.f.student" login
script and the "#include .student" for the ".f.student" login
script. Also, MAP ROOT U:=%HOME_DIRECTORY for home directory
mappings.

I also wrote a WIN95 GUI program to handle the logins in our student
labs, so the students only have to type in the "jlflower" portion of
their login name. (The login program "searches" the tree for the "jlflower"
object and passes Login Script processing on to CLIENT32).
If this program is not used, the .jlflower.j.f.student structure is
fairly intuitive for the user or lab assistant to figure out.

We create accounts from student class registration data, UIMPORT, and a
simple homegrown "coupling" program.

We delete accounts (based on the Last Login Date) using the JRB Utilities.

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

Date: Wed, 23 Apr 1997 14:49:21 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: NDS Merge Question

>When you perform a NDS merge my understanding is that there can be no
>objects at the root level at either tree, correct? After the merge all
>containers that were below the root in each tree now reside side by
>side under the single root. My question is...Do I need to wory about
>any of the objects within the seperate containers, i.e. duplicate
>account names, group names, etc? For example, with the trees being
>seperate user John Doe has one account, JDOE, in each tree. After the
>merge he will still have two accounts, but they will be in different
>containers and therefore possess different contexts, so there should
>not be a problem correct? I guess I need someone to confirm my logic
>on this? All the documentation I can dig up only mentions not having
>objects in the root. It is vague on the concept of duplicate object
>names.

if you merge
 o=salford tree=salford
with
 o=eccles tree=eccles
we ended up with:
 o=salford tree=salford
 o=eccles
if the 'o' had been the same we would have had problems.

the probkem we had was with the contents of the partitions:

 ou=..... o=salford
merging with
 cn=....2000 users.. o=eccles

the merge of the root partitions generates a root partition which is the
union of the merged pertitions, ie suddenly we had 2000 user obejcts in
the root partition... a bad thing.

make your root partition as small as posible before you merge (don't
delete objects from it, just split the sub-tees from the root)

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

Date: Sun, 4 May 1997 16:03:24 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: accessing user properties in login script

>I am trying to some different properties in the login script. The
>Location field in NWADMIN can be accessed as %L in a script, but I cannot
>find a way to access the Department field. The SETNAME JRB utility can be
>used to set the property using the name %Depart, but that does not seem
>to work in a script. It appears that the field is not available...

Many of the field names used in nwadmin/netadmin do not correspond
directly to the attribute names. Here is a list of mismatches that come to
mind:

  Attribute name                    Nwadmin field name

  CN                                Login name (the first value in CN)
				    Other name (2nd value in CN)
  Surname                           Last name
  OU                                Department
  SA                                Street address
  Physical Delivery Ofice Name      City
  S                                 State or Province
  L                                 Locality

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

Date: Sun, 4 May 1997 16:20:30 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: replcation causing problems with account setups

>I am trying to use UIMPORT to create accounts, but most of the time when
>I run the program, I get errors similar to this:
>
>F:\>p:uimport student.ctl student.dat
>Import context: student.acadia
> Creating user 999900T.sz
> Adding User
> Generating key pair
>**** Updating 999900T.sz ****
>|
>UIMPORT-4.26-991: An error occurred in NWDSMapNameToID.  This may mean
>that the skulker has not put object 999900T on server AXE1 yet. Error
>code: FDA7. | UIMPORT-4.26-991: An error occurred in NWDSModifyObject.
>Error code: FD9B.
>  User: .999900T.sz.student.acadia
>  Attribute: Profile
>  Value: .SSTUDENT.profile.acadia
>*** Done
>
>I have a good idea that the problem is caused by the fact that uimport
>has created the user in one partition and then when it goes to set other
>information for the user, it retrieves a partially replicated account
>from another partition. Is there anyway, aside from destroying the 2
>redundant copies of replica, to force all uimport requests to a
>particular partition?

As you suspect, the problem arises because Uimport is sending requests to
different servers. The object creation request has gone to server A,
uimport is almost certainly then creating the user's home directory on
server B, and the error FDA7 reported by NWDSMapNameToID will occur
when Uimport is obtaining the user's ID on server B for purposes of
creating a trustee assignment. Server B has not yet received an update
from server A announcing the new user. Error FD9B is reporting a similar
problem i.e. a request was sent to server B asking for an attribute value
to be added, and the attribute value was the new object name e.g. Uimport is
trying to add the new user to a group.

I dont know of any solution for Uimport. Its only recently that the SDK
has contained any mechanism for ensuring that NDS requests are sent to
a particular server, and the odds are that noone has gotten around to
updating Uimport to use this facility. However, as we have discussed off
line, JRButils creatobj now uses this facility.

---------

Date: Sun, 4 May 1997 12:19:02 EST
From: "joe_flowers@ncsu.edu" <NOVELL@HCL.CHASS.NCSU.EDU>
Subject: Re: replcation causing problems with account setups

<above message text snipped>

I'm curious. If you make sure you are authenticated to Server A and
Server B while logged in with complete "Admin" rights over both
servers, does this make any difference. We use UIMPORT here alot, but
I always make sure I'm authenticated to all the relevant servers
first. I haven't seen your error before. Is there a "timeout" count
for UIMPORT retries that can be increased ?

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

Date: Mon, 5 May 1997 15:59:24 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Supervisor Rights

>Objects in the O & OU of the tree show no supervisory rights to the
>objects and no inherited rights abnormalities, until you get to the first
>directory on the volume, any volume.
>
>At this point, the inherited rights filters show supervisor checked &
>grey. [This is not how I configured the network.] Every user has
>supervisor rights on every directory on the server.
>
>How can I remove the supervisor rights?

Don't panic.

You're confusing things a bit.  IRF's are not effective rights.
Also, object IRF's are not the same as volume IRF's.

On volumes, you can't filter out Supervisor rights, the way you can on
containers.  That's why it's greyed out - you can't turn it off.  This is
completely normal.  This is the way you want it.  You don't want anyone to
be able to filter out Supervisor rights to the file system, right?

Now, figure out if your users really have supervisor rights.  Use that
"effective rights" button that's all over NWAdmin.  If they have rights,
it's because they've been assigned.

Who are the trustees of the volume?  What are their rights?  Does someone
have Supervisor to the root?  Does the volume's own container have it?
Maybe "Everyone"?  No?

Maybe it's a security equivalence thing.  Who is equivalent to each trustee
of the root?  Who is equivalent to each container above the volume?

Check effective rights, and the existing trustees.  You will either find
where the rights are coming from, or find that they're not really assigned.

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

Date: Fri, 9 May 1997 13:33:26 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NDS tree surgery

>I've got an annoying NDS problem that I've been researching with no
>success.  I taught a NetWare 4.x class and created a container where
>students could run amok with full rights.  Now I've got several
>containers with an IRF that blocks everything except Browse.  This
>makes cleanup "challenging" since there's no way to delete the
>containers or the objects therein.  I've checked and the accounts
>used to create the containers are locked out as well.
>
>If there's a next time, I'll bring up a disposable tree for students
>to frolick in.  For now, I just want to lop off a branch of my NDS tree.
----------
	Here's an object (sic) lesson for your students and staff: always
create a safe administrative account on each server so that you can always
get in and override anything others have done. Do not use "equivalent to."
	Here's another: never put play servers in the same NDS domain as
production equipment. And the corrollary is never trust a server which has
been tinkered with by less than expert hands: clean the drives and make
fresh installations.
	Joe D.

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

Date: Tue, 13 May 1997 12:56:50 +0100
From: "David W. Hanson" <hansond@AFRC.GARMISCH.ARMY.MIL>
Subject: Re: NDS tree surgery

>Joe, could you describe how you can create an account that can't be locked
>out of an OU?  I'm probably missing something, but it seems that if anyone has
>the ability to create a container there's an opportunity for everyone to be
>locked out of it via an ill-conceived IRF.  No one had access to system files
>or configuration, or privs to do anything outside of their pen.  There's full
>control from [Root] down to where the IRF was created.  This is what the
>problem part of the tree looks like:

<snip>

I guess the key is to not grant any user objects supervisor rights to
their own object, if I read the DynaText correctly.  It is not
obvious however.  Maybe Debbie Becker can add some clarification...

Here is what the DynaText says about object IRFs and Supervisor
rights:

Blocking the Supervisor Object Right

The IRF of an object and its properties can block the Supervisor
object right. This allows distributed management of the Directory
tree.

However, NetWare utilities don't allow you to block the Supervisor
object right unless an object, including itself, is already granted
the Supervisor right to that object. This helps to prevent cutting off
Supervisor-level access to a part of the Directory tree.

WARNING: Any object can be assigned as a trustee to an object,
including to itself. But unless the trustee assignment is a User
object, blocking the Supervisor object right with the IRF still cuts
off that object from future control because you can only log in as a
User object.

Because the Supervisor right to objects and properties can be blocked,
you should also grant a trustee all other rights.

For example, don't grant only the Supervisor right. Even though that
right allows or implies all rights to an object, if the Supervisor
right is blocked, the trustee is left with no rights.

Instead, grant all rights to the trustees, so that if Supervisor is
blocked by an IRF, the trustee still has Browse, Rename, Create, and
Delete rights.

To change the IRF of an object, you must have at least the Write
property right to the ACL property of that object.

As with previous versions of NetWare, the Supervisor right cannot be
blocked in the file system. A trustee who has the Supervisor right in
the root directory of a volume has the Supervisor right to the entire
volume, and it cannot be blocked with an IRF.

---------

Date: Tue, 13 May 1997 08:17:45 -0400
From: "Benninger, Paul (WS)" <pbenninger@INTEGON.COM>
Subject: Re: NDS tree surgery

>Joe, could you describe how you can create an account that can't be locked
>out of an OU?  I'm probably missing something, but it seems that if anyone
>has the ability to create a container there's an opportunity for everyone
>to be locked out of it via an ill-conceived IRF.

In the Novell on-line docs, there's a full, detailed description of how
to create an account such as this. I think if you do a search for
Workgroup Manager (I'm not 100% sure on the exact search string, but
I think that is it) it will explain what rights to give to the "manager,"
how to keep him from blocking your rights, etc. It works, we used to use
it in a former life, and we're addressing the issue in the current life.

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

Date: Tue, 27 May 1997 11:36:46 -0700
From: "Steven W. Smith" <SYSSWS@GC.MARICOPA.EDU>
Subject: Re: NDS tree surgery

On 5/9/97 I asked the list how to go about deleting a portion of the NDS
tree where administration had been blocked by an IRF.  Now that everything's
fixed I'd like to summarize what I learned from it.

1, The only way to fix it:  Call Novell.  They dial in with PC-Anywhere (or
equiv.) and edit the DS database with a magic utility (DSDUMP).  They can
either create a user object in the context with Supervisor privs, or delete
the offending objects (OUs, users, etc).  To avoid it, don't grant S priv.

2, Removing all replicas of a partition will render it unavailable, but will
not make it disappear (even after 'NDS external reference life span' has
elapsed).  Also see TID 2906066.

3, DSREPAIR advanced options "Destroy the selected replica on this server"
and "Remove this server from the replica ring" are dangerous.  The preferred
course is to use PARTMGR for such manipulations.  "Remove this server..." can
lead to servers disagreeing about what a replica ring should look like,
which can cause synchronization problems.  If "Subordinate Reference"
replicas annoy you, too bad, learn to ignore them.

4, An option I considered for fixing the synchronization problem was to remove
NDS from the problem server then re-install, allows the replica(s) to be
recreated from the Master's definition.  According to the tech I spoke to
this would have lead to the loss of trustee assignments on the server's
volumes.

  The original message with a couple of notes follows.  Thanks to all who
responded, hope this helps someone.
//
>  I've got an annoying NDS problem that I've been researching with no
>success.  I taught a NetWare 4.x class and created a container where students
>could run amok with full privs.  Now I've got several containers with an
>IRF that blocks everything except Browse.  This makes cleanup "challenging"
>since there's no way to delete the containers or the objects therein.  I've
>checked and the accounts used to create the containers are locked out as well.
>
>  If there's a next time, I'll bring up a disposable tree for students to
>frolick in.  For now, I just want to lop off a branch of my NDS tree.  One
>idea I'm considering is making the parent OU of the locked containers a new
>partition, then removing any/all replicas of the new partition.
>

  See #2 above.  The disposable tree is the way to go, unless you can teach
someone to be an admin without giving them Supervisor rights (debateable).
Thanks to David Hanson for info on S right and IRFs.

>  Another (less likely) option might be to try and restore (from backup) a
>"pre-quiz2" version of the parent container.  My feeling is that this won't
>work, but I haven't tried it.

  I tried it.  It didn't work and prompted a nasty sync problem and an
annoying, hung BackupExec job. :-O

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

Date: Wed, 28 May 1997 18:25:29 -0400
From: Bob Becker <becker@clark.net>
Subject: Re: NDS tree surgery

>Joe, could you describe how you can create an account that can't be locked
>out of an OU?

Let's say you want to create an administrative user (SubAdmin) for the Mktg
container.

1)  Create user object SubAdmin.

2)  Make SubAdmin a trustee of the Mktg container and grant [BCDR] object
rights and [RCWA] All Properties. Make a Selected Properties rights
assignment to the container's Object Trustee List (ACL) of [RC].

3)  Make Admin a trustee of the Mktg container and grant [SBCDR] object
rights and [SRCWA] All Properties. If you want to play it safe, grant Admin
a Selected Properties rights assignment to the container's Object Trustee
List (ACL) as well - [SRCWA], although this is redundant.

4)  Make Admin a trustee of SubAdmin and grant [SBCDR] object rights and
[SRCWA] All Properties. Again, if you want to play it safe, grant Admin a
Selected Properties rights assignment to SubAdmin's Object Trustee List
(ACL) as well - [SRCWA].

5)  Make SubAdmin a trustee of him/herself and grant [B] object right and
[RC] All Properties. Make sure that his/her Effective Rights to his/her own
Object Trustees List (ACL) is [RC].

6)  As an additional safeguard, I usually make Admin Security Equal to
SubAdmin and to any server objects that are in the Mktg container. (Servers
have [S] object right to themselves, so being security equal to them means
that you have [S] object right -- and Supervisor file system access.)

If a SubAdmin user has been set up in such a way as to allow them to cut
you out of the tree, you can also try putting the container into bindery
context and logging in as Supervisor or Admin and changing the SubAdmin's
password to gain access.

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

Date: Wed, 28 May 1997 18:25:33 -0400
From: Bob Becker <becker@clark.net>
Subject: Re: NDS Names/Name Lengths/LONG Names

>Our question is:  how much additional overhead is caused by using
>longer names for objects (up to 32 characters, I believe.)

I'd be most concerned with length of the distinguished name -- I believe
that the maximum length name is 256 (255?) characters. I've also seen posts
on various utilities that choke when they run into a name that's over a set
size (which seems to vary by utility, but is considerably less than 256
characters).

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

Date: Wed, 28 May 1997 18:25:35 -0400
From: Bob Becker <becker@clark.net>
Subject: Re: Position of NT Domain object in NDS

>"Rule of thumb: Place the NT Domain (or Workgroup) object in
>the same context that you want to create NDS accounts."
>
>This seems ok by the simple example that was included but I can't find
>any information for how to do find an organisation that would have an
>NDS-layout as below, i.e where users can be found in different contexts.
>Will the Novell Administrator for NT function with this type of NDS-design
>or where is the hook?

According to the Novell 555 course liaison (who's spent a lot of time
working with the product), this should be no problem. The NDS objects to be
synched can be in multiple containers in the tree. The NT objects that you
bring into the tree will be in the same container as the Domain object.

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

Date: Thu, 29 May 1997 13:02:14 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: Resetting users passwords on NW 4.11

>>>Is there any way to grant some assistant administrators the rights to
>>>reset users passwords without givieng them all rights to other user
>>>objects?
>
>>If you go this route, would recommend *not* giving the right at the
>>container level, as you will have to give it to All Properties, which
>>will allow full access to any and all properties of all objects from
>>that point down (and will also give them the Supervisor file system
>>right on all volumes of any servers in the path!)
>
>If you give the rights at the container level, you can remove all but
>browse object rights which will disallow creation, deletion, moves, etc.
>of NDS objects.

We were specifically talking Property rights here -- I'd only give Object
rights to people with full administrative functionality.


>Additionally, if you remove all but [CR] on the selected property
>BINDERY PROPERTY, it will disallow reassigning directory space
>restrictions, rights to files and directories, and other file-type
>functions. However, your assistant administrator will still be able to
>do other things within individual accounts besides resetting passwords,
>like resetting intruder lockouts, and adjusting all of the password
>restriction parameters.

Giving the Write right to All Properties at the container level effect
*all* objects in the container and will be inheirited further down the tree.

The [CR] Selected Properties assignment to a container will affect *only*
that container (not its objects or subcontainers).

Changing the Selected Property right for the container's Bindery Property
has no effect on rights on servers in the container and the subsequent
rights to the file system -- with Write to All Properties, the admin asst.
still has full rights to the servers in the container (and this translates
into the Supervisor right on the file system, the ability to create volume
restrictions, etc.)

It's a misconception that you have to have the Supervisor object right to a
server object in order to get this right -- you need no more than the Write
right to the server's Object Trustee List (ACL). You can get it from
Supervisor object right because this gives you Supervisor to All
Properties, which gives you the ability to Write to All Properties
(including the ACL).

What's even scarier is that you don't even have to use that Write right to
make yourself a trustee and grant yourself additional rights -- the second
you have the right, you also get file system access if there are servers in
the container.

I still don't like giving anybody the Write right to All Properties at a
container unless I want them to have full access to the properties of every
object from that point down -- fine for full admin folks, not so good for
help desk personnel. <g>

Not just talking theory here -- have worked extensively with it -- done
lots of troubleshooting on it for clients. Probably one of the most common
issues I see in the field concerns inappropriate NDS rights assignments
leading to file system access.

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

Date: Fri, 30 May 1997 20:59:54 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Moving a server

>We currently have two servers in an NDS tree called PCS. The primary
>file server, PCS,  handles file serving, backup operations, CDRom
>sharing. The other server, PHSWEB1, is a web server (WS30), IPX/IP
>gateway server, and and email server (Mercury). That's how things were
>when I came on seen. My coworker and I are in the process of
>redesigning the network. My part of this is to redo the servers. The
>main server was 4.10, with the web server running 4.11. I have created
>a new main server with a tree called PCS_TREE, and a server name of
>PHSFILE1. Now I want to be able to take PHSWEB1, which is currently in
>the tree PCS, and put it into the tree PCS_TREE without having to
>backup the machine and reinstall Novell.

Merging the trees is the way to go.
Check out info on DSMERGE.

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

Date: Sat, 31 May 1997 15:50:45 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: Resetting users passwords on NW 4.11

>All I'll say is: try it first. I've done it here as a solution to a
>similar problem. We set up a specific container for the help desk
>people, made that container a trustee of the managed container(s),
>and turned off all but read and compare on the bindery property
>(in addition to the settings in my previous message, which were
>pretty much right out of Novell's online docs minus the object props.),
>and they cannot modify user space restrictions, or rights to files and
>directories for the people in the managed containers.

Been there, done that (but tested it again just to make sure Novell hadn't
changed anything on me recently--it's been known to happen! <g>).

Created ADMIN container and made it trustee to INTERMEDIA (my Organization,
and where my server object resides). Gave ADMIN container Browse object
right and Read, Compare, Write and Add Self for All Properties. Made a
Selected Propeties rights assignment to INTERMEDIA's Bindery Property of
Read and Compare only.

Logged in as a user object in the ADMIN container and did the following:
*  Removed a user's rights to his home directory.
*  Created a new directory on the root of the SYS: volume and restricted
its size.
*  Restricted the amount of space that a user could access on the SYS: volume.
*  Gave a user rights to the SYS:SYSTEM directory and removed all rights in
the     IRF.
*  Tested all of the above (logging in as users affected and seeing what
the effects     were). All changes made to the file system were in effect.

This has been my experience consistently, working on many different
systems. Do you, perhaps have IRFs up on your servers blocking those
inherited All Properties rights (and, thus, access to the file system)?

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

Date: Mon, 2 Jun 1997 22:32:54 -0400
From: Pierre Marceau <pierre@MARCEAU.EMPATH.ON.CA>
Subject: Re: Lost Admin user in NDS

>We just had our ADMIN user deleted in the tree of a 4.11 server and
>the three of us who had rights that were equivalent have lost them
>and now only have the rights of the group EVERYONE.

This happened to me a little while back my solution was to use the
INSTALL.NLM -DSREMOVE option. The install.nlm has an option to remove
directory services, however as you select this option it ask's for
the admin password to continue, as Homer would say, "DOIGHT!" So what
you have to do is "load install -dsremove" now when you get to the
spot where it asks for the admin account and password simply press
ESC and presto NDS is gone. Now you can install NDS and you will have
an admin account again. Rebuild your tree manually, you should have
noted the names and locations of any users, print servers and other
NDS objects so as to rebuild them as effortlessly as posible. I was
able to restore my TREE from my NDS compliant tape backup. Remember
your system login script is embedded in the DS database so print it
before you remove NDS.

Learn from this lesson, it's not good enough to be Admin Equivelent.
When you get your tree back go to the highest level, look at the
rights assigned to the Admin user, assign the same rights to another
user, ADMIN2 for example.

Good Luck, hope your tree is not too big!

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

Date: Mon, 9 Jun 1997 00:52:12 -0700
From: "Philip J. Koenig" <pjk@CRL.COM>
Subject: Re: Removing CDROM volumes from NDS?

Martin C. Mueller replied:
>>After installing NW 4.x, the volume name of the install disk (ie
>>NW_411 or somesuch) gets inserted as a volume object in NDS.  Even
>>after removing and purging the CD from the server list (and unloading
>>CDROM.NLM) the volume object remains in NDS.
>>
>>So this "phantom volume" continues to be listed as part of the server
>>in NDS, causing "not available" errors in NWadmin etc. Is it safe to
>>just delete these objects?  I rarely mount CD's but would like to
>>know if it's normal to have to manually delete the volume object
>>everytime I mount a CD and finish with it.
>
>A volume gets an NDS-object only if someone explicitly does it, eg. via
>INSTALL.NLM, option "Upgrade mounted volumes into the Directory".
>Particularily mounting a CD doesn't do it. Deleting a Volume ID is
>uncritical, only thing to remember is, that there may be pointers to it
>from within other NDS objects (print queue volumes, of course not
>applicable to a CD) or login scripts (map commands in NDS-syntax).

Fabulous, yours was the most informative answer so far.

Certainly this gets done during Netware install then, I may have not
understood the implications of the abovementioned question during
install.

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

Date: Tue, 10 Jun 1997 15:07:32 +1000
From: Mark Cramer <m.cramer@QUT.EDU.AU>
Subject: Re: How to force DS to connect to another server

>We have found that after a server has been down, it can take over two
>hours for NDS to synchronise. The problem appears to be the failure of
>a server to establish a connection to another for exchange of updates.
>After a reboot of server A this morning, server A established connections to
>other servers within a few minutes. Other servers with the exception of server
>B re-established connections to server A. Server A was successfully sending
>updates to server B, but server B because it had failed to log into server A
>was unable to send updates to server A and was reporting -625 errors. The
>problem resolved itself after a couple of hours when server B finally logged
>into server A. Maybe what happened is that server B recognised A was online and
>tried to log in while SYS was still mounting, failed, and then didn't try again
>for a couple of hours, whereas the other servers succeeded on the first
>attempt.
>
>Is there a DSREPAIR or DSTRACE option to force a server to attempt a
>connection to another? The 'set dstrace=*u' command seemed like a
>possibility but didn't do the job.

Hi John, you did do the Set Dstrace=*u on server B? to tell it server A was
back up. I've never seen this not produce the "Established communication with
server A" message, unless there are comms problems between (and independent of)
the servers themselves.

Do you get any message on server B's console when you try the set dstrace=*u,
after A comes back up?

I normally do a set dstrace=*u then *h on the server holding the master
replica, when a r/w replica comes back up.

---------

Date: Tue, 10 Jun 1997 11:18:31 -500
From: Jon Dustin <jdustin@USM.MAINE.EDU>
Subject: Re: How to force DS to connect to another server

[continuing the above thread]

If I am feeling impatient, I will use DSREPAIR to 'force' the servers
to see each other. I use ADVANCED OPTIONS, SERVERS KNOWN TO THIS
DATABASE, and press ENTER on one of the servers. From there you can
choose an option REPAIR ALL NETWORK ADDRESSES or REPAIR SELECTED
SERVER'S ADDRESS.

You will have to perform this task in both directions, so that the
servers will login to each other. Then schedule an immediate
synchronization and all should be well.

---------

Date: Wed, 11 Jun 1997 16:35:49 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: How to force DS to connect to another server

[JRB, replying to both of the above replies in one message...]

>If I am feeling impatient, I will use DSREPAIR to 'force' the servers
>to see each other. I use ADVANCED OPTIONS, SERVERS KNOWN TO THIS
>DATABASE, and press ENTER on one of the servers. From there you can
>choose an option REPAIR ALL NETWORK ADDRESSES or REPAIR SELECTED
>SERVER'S ADDRESS.
>
>You will have to perform this task in both directions, so that the
>servers will login to each other. Then schedule an immediate
>synchronization and all should be well.

I am sure I tried that and it failed with either another -625, or -119
which we were getting on some occasions. The server was listed as down.
I had the opportunity to try again this morning when the server was
listed as up, but -625 errors were being reported by DSTRACE, and it
worked. Is that consistent with your experience?

>Hi John, you did do the Set Dstrace=*u on server B? to tell it server A was
>back up. I've never seen this not produce the "Established communication with
>server A" message, unless there are comms problems between (and independent
>of) the servers themselves.
>
>Do you get any message on server B's console when you try the set dstrace=*u,
>after A comes back up?
>
>I normally do a set dstrace=*u then *h on the server holding the master
>replica, when a r/w replica comes back up.

Using dstrace=*u on server B did not appear to have any effect, and it did not
produce any messages on the console, possibly because B regarded A as being
down, despite the fact that A was logged into B and happily sending updates.

This raises the question of what causes NDS on one server to decide that
another server is 'up'. Does this occur when it establishes a connection
to that server, or is 'up' status a prerequisite for it to attempt
establishment of a connection. While DS on server B considered server A
to be down, there were no problems for a client logged into B making
a bindery connection to A, or with an NDS login to B authenticating to A.
The problem seemed to be limited to server B not establishing a connection
to A for transfer of updates.

---------

Date: Wed, 11 Jun 1997 09:36:55 +0100
From: "David W. Hanson" <hansond@AFRC.GARMISCH.ARMY.MIL>
Subject: Re: How to force DS to connect to another server

>>>We have found that after a server has been down, it can take over two
>>>hours for NDS to synchronise. The problem appears to be the failure of
>>>a server to establish a connection to another for exchange of updates.

I have had success with using DSREPAIR, Advanced Options, Repair
local database.  I know it sounds a little drastic, but it did seem
to force synchronization...

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

Date: Tue, 10 Jun 1997 11:56:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: new epoch

>Can someone define EPOCH for me?
-----
	I could suggest a dictionary. You know, that thick book which
is more than a spelling checker. It's related to the word era, based
on time. As an example, this the era when folks don't configure their
mailers properly and thus send unwanted gibberish attachments to email
messages (hint).
	Epoch is the time base of the system. NDS keeps messages in order
by timestamp, and needs to so that an old message is recognized as having
likely inaccurate information compared to recent messages and hence should
be discarded.
	Using DSREPAIR to "declare a new epoch" means in practice to stop,
wait for the declarer to say The time a the tone will be ..., and then
let servers progress from that point forward. Those servers ahead of the
time hack are obliged to forget and then relearn information based on the
announced time. One does not want to "declare" frequently because it is a
serious disruption to NDS synchronization activities, but when we need it
we really need it.
	The common mistake on epoch things is let a server get days or
years ahead of the tree. Oh boy, that's serious stuff. Ditto in the
other direction. So we always check the time when rebooting a server
and only after that check do we let the machine start server.exe. The
smarter the system manager the more often time/dates are set wildly wrong,
an observed situation based on not wanting to follow directions.
	Joe D.

---------

Date: Wed, 11 Jun 1997 00:19:33 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: new epoch

>Can someone define EPOCH for me?

You mean to say that the help screen doesn't tell you enough?
When the cursor is at 'repair time stamps and declare a new epoch',
press F1. Check out page 2 out of a total of 5.

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

Date: Wed, 18 Jun 1997 09:58:33 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: for the NDS expert

>Unlike supervisor, Admin is just another user with rights assigned to
>all objects. It gets it's file and directory rights from having the
>supervisor right to the volume objects.

Wrong.

Supervisor object right to volume objects gives you zip. It's being an NDS
trustee of the *server* object with any combination of rights that will
give you the Write Property right to the Object Trustees list (ACL) --
including Supervisor object, Supervisor All Properties, Read/Write All
Properties, Write All Properties -- that gives you Supervisor file system
right on *all* volumes attached to that server.

---------

Date: Wed, 18 Jun 1997 21:21:52 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: for the NDS expert

[Above msg text deleted]

>So, what will the S right to the Vol object do for you? I thought the
>reason Admin had rights to all files and directories was because he
>had S right to [Root], so S right to a server, so S right to a Vol,
>so S right to all files & dirs.  You're saying the S right to the
>server gives S right to files & dirs, so what does the S right to the
>Vol do for rights to files & dirs.  As you (Debbie) say above, zip?
>
>Do you have any further info on why this is?
>
>This thread started with a question of not being able to access the
>"Trustees of the object" option for a file or dir.  While writing my
>answer, which was originally the same as most others - check for
>IRFs- it dawned on me that files & dirs are not NDS Objects at all.
>This is the answer the original poster was looking for (he told me
>via private e-mail).  But, that process shed a lot of light for me on
>how everything ties together.  I'm looking for a little more
>enlightenment on why S right to a Vol doesn't provide S rights to the
>file structure.

I don't have a clue as to why Novell set it up this way (aside from
confusing the heck out of people and making a living for some of us). <g>

I can see the original need for Supervisor object right to the server
giving the user Supervisor file system right for all volumes -- the
Supervisor object right assigned Admin (the original user in the tree) to
the [Root] is inherited down the tree and allows Admin the rights (through
this inheritance) to setup the file system on all volumes on the brand new
(first) server in the tree. Guess they thought this was more efficient than
using volume objects (although the volume object is a more *intuitive* link
into the file system in my mind -- took me a long time to get to the point
where I could keep that straight!)

You can certainly give file system rights to the volume using the volume
object -- but you have to use the Object, Details option and click on the
"Trustees of the Root Directory" volume and add trustees with their *file
system* rights here.

I also wish that Novell had given different names to different types of
rights -- I find it's very difficult students to keep them separated. It's
confusing to have Supervisor object right, Supervisor property right and
Supervisor file system right -- not to mention Read and Write for
properties and file system (but that's another issue altogether....)

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

Date: Fri, 25 Jul 1997 12:36:05 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Schema extensions... Fear and loathing?

David Harris wrote:
>When NetWare 4.0 came out, it was originally a no-no to extend the NDS
>schema, because:
>
>1: Modifications to base schema classes (like "User") could not be
>removed without a complete reinstallation.
>
>2: Trees/servers could not be merged when any of the candidates had had
>modifications made to its schema.
>
>In a lot of ways, this seemed to defeat the whole point of NDS, but when
>I was originally writing the NDS support for Pegasus Mail, people made it
>very, very clear to me that I should not consider modifying the schema.
>As a result I had to develop techniques that were inherently more awkward
>than straight schema modifications.
>
>As far as I am aware, problem (2) may have been resolved with NetWare
>4.11, but problem (1) may still exist.

I believe problem (1) is fixed by later versions of DSREPAIR, which
provides the opportunity to "Rebuild operational schema" in the "Repair
local database" section.  I'm under the impression it plops a schema
definition into the tree, and repairs the database so that no objects
have "illegal" attributes, effectively un-modifying your schema extensions.

... and (2) is also solved by later versions of DSREPAIR, which allow you
to import schemata from other servers into yours.

>What do people feel about software that modifies the schema now? Is there
>still a resistance to it?

It depends.  If it's a server administration utility or augmentation, I
think it's appropriate.  I've seen other utilities that extend the schema
for no good reason at all, or to do things that could be done more
effectively using a file.  I was evaluating a utility (I can't remember
what it was now) that created a "(Utility) License" class, without even
asking me!  I was, let's just say, annoyed.  I like to be INFORMED of any
schema modifications that 3rd party software is going to do - there was no
documentation about this change! I called the company and asked what
modifications it made (at the time there was no easy way to find out),
and couldn't get an answer.  I removed the software, and vowed never to
use anything from that company again.  I wish I could remember who it was
now...

... so if you're going to modify the schema, please be up front about it.
And provide snap-ins to manipulate objects of your new classes.

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

Date: Wed, 30 Jul 1997 08:28:12 +0100
From: "Erik Bos, AMC afd. PC-LAN" <A.H.Bos@AMC.UVA.NL>
Subject: (Fwd) NDS Object tracking

>I have been wondering if there is a way to look at the properties of
>an NDS object such as you could see who created it, when it was
>created, when the object was last modified, etc.  Kind of like the
>File and Directory attributes that you can see through FILER.  I
>have not been able to find this functionality within the utilitities
>that I currently have.  Can someone point me in the right direction?

There is a utility called Onsite Admin, you can download it from
Novell.Com , with this utility you can get all info in a NDS object
in one shot. It works great!

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

Date: Thu, 31 Jul 1997 10:27:30 +0100
From: "Richard Letts, Salford Univ." <r.j.letts@SALFORD.AC.UK>
Subject: NDS design issue...

>I have a major problem.
>
>Our situation:  300+ INW411 servers throughout South Africa. 300
>Individual trees for each server.

>For instance Server name : PTA1    (Pretoria)
>               Tree name:     PTA-1
>
>We have to merge them now, but I've found that the organizations don't
>merge, only the trees.

>
>                [HQ]
>[1]   [2]   [3]   [4]   [5]   [6]   [7]   [8]   [9]    (9 Provinces)


>Between 15 and 50 sites under each province. Cisco 2500
>and 4000 router network.
>
>What type of structure should we implement in NDS? I was thinking about
>one tree, one O for each province and HQ, and OU's for each site. Each
>site may have up to 5 servers, but most of them only one. We have 9
>provincial network controllers, and a couple of techies at HQ. Any
>problems with my proposed setup? Any better ideas? I'd love some, coz
>planning NDS is still a bit fuzzy to me...

What speed links between the sites? what network topology?

NDS design
rules

 1. Make the top of your tree geographic

 2. Only locate replicas where they can talk to each other over fast
    links (eg in a region)

 3. Keep [root] and any partitions replicated over WAN links small


Timesync

Establish timesync between ALL of the servers in your tree now, using
configured lists and time-provider groups within each province with a
primary reference server in the HQ and primary servers in each province,
and each province's servers getting their time from within their province

Timesync is really important to NDS stability, and there is nothing to
prevent servers from different trees sharing the same timsync now.

Pre-merge changes

On each server make [root] as small as possible ideally nothing in it (ie
only the one OU, and split that OU into a separate partition, even if it's
only on one server)!  move the users if you have to. when you merge trees
all servers holding [root] in the original trees will hold [root] of the
merged tree! if root contains 100 users then all your root servers have to
replicate all 100 users during the merge process!

Import the remote schemas into the central tree as soon as possible; in
that way you'll get the schema's synced beforehand.

Go slowly. NDS works best when you take your time.

It might be better to merge the trees within each province separately if
you trust the network controllers out there, or for you to have a
check-list. then you merge the provincial tree with the HQ tree.

Again... Go slowly. NDS works best when you take your time.

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

Date: Thu, 31 Jul 1997 23:36:35 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: NDS Tree Design

>Our situation:
>300+ INW411 servers throughout South Africa. 300 Individual trees
>for each server.
>For instance Server name : PTA1 (Pretoria)
>                Tree name: PTA-1
>
>We have to merge them now, but I've found that the organizations
>don't merge, only the trees.

Well, seeing the possible problems you could implant in a wrongly choosen tree
and distribution design may I suggest  you make yourself a specialist on this
issue first?

Meaning get hold of good books, buy technical info if need be, browse the
Internet and surround yourself with a few spare fileservers and routers and
test and learn until you know NDS inside out. Then think up a design. Test it
in a test environment. Let others shoot at it and test it out. Deploy it in
small nearby areas and keep on testing. Then make it a reality for everybody.

I'm saying this not to give an easy answer but asking the listgroup for tips is
one thing.

Overseeing the current, nearby and future problems is something that only your
group can be expected to handle.

As with all admins your network is unique in the world. With its own specific
problems. Politics, strange router connections, outages, different software
(IOS!) versions, security issues, local admins with their own views, powerusers
that mean well, virii, etc.

Not only does the final design need to be able to handle all of these aspects.
Think of the future too. What kind of modifications are you expecting in the
future? How are you going to handle upgrading NDS? What if some side demands
additional schemas? How are you going to insure that all sites keep the same
time? Any side that goes down for several days every now and then? Some areas
that have constant troubles with the phone lines? Any political issues (our
tree should be named: "I'll show them who has power for bypassing me" if you
know what I mean) to be expected? What if NT Server pops up? Are routers
filtering too much? Do you cut out the link to a side that breaches security
(eg you find out they are hooked up to Internet without hardware firewall)? How
do you handle failing primary servers and router lines? How do you handle loss
of key personel? Etc.

IOW designing a tree is one thing. Keeping it running with as less problems and
downtime as possible is something else. Simply because things that have nothing
to do with the design itself may pop up and interfere with it.

One tip concerning political issues. At some point in time your perfectly
designed tree will be attacked by someone that only has power but lacks any
sort of skills and know-how. It would help your argument then if you can say
(within 5 minutes! So prepare) that the requested modification can be made at
the cost of: 3.7 hours 100% downtime for an estimated number of 1721 people and
83 hours of reduced performance, possible corruption (so need to do it all
again) and sudden broken disconnections, etc., etc. for an estimated number of
8973 people. Furthermore an increase of 14% in administrational costs because
of double work, etc., etc. Estimated extra costs for the first year: $314.500.
And you need a temporary increase of 5 persons at the helpdesk to handle the
expected increase in support calls ofcourse. Letting people sign contracts will
not be enough to stop them from complaining, protecting their kingdom or simply
showing off.

Also be prepared to answer why you didn't use NT Server. Technical
statements alone will probably not be enough.

As I see it the workload will be mostly consumed by politics and handling human
emotions (if people see that their known and trusted world is changing because
of some outsider they are going to respond in all sorts of ways) and less
because of technical issues during the first year. After a while they will have
learned to life with it. But perhaps by then you're are looking towards
something else ;)

It helps if you involve people in your doings. Talk with them, don't send only
memo's. It does cost extra time in the short run. It saves a bundle in the long
run. And because you talk with them and involve them everything will be easier
in the long run.

All in all you've a very interesting project ahead of you. Almost wish
I could be part of it.

---------

Date: Thu, 31 Jul 1997 21:45:45 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NDS Tree Design

>Well, seeing the possible problems you could implant in a wrongly choosen tree
>and distribution design may I suggest  you make yourself a specialist on this
>issue first?
	<omissions>
>I'm saying this not to give an easy answer but asking the listgroup for tips is
>one thing.
>Overseeing the current, nearby and future problems is something that only your
>group can be expected to handle.
>As with all admins your network is unique in the world. With its own specific
>problems. Politics, strange router connections, outages, different software
>(IOS!) versions, security issues, local admins with their own views, powerusers
>that mean well, virii, etc.
	<more omission>
>One tip concerning political issues. At some point in time your perfectly
>designed tree will be attacked by someone that only has power but lacks any
>sort of skills and know-how. It would help your argument then if you can say
>(within 5 minutes! So prepare) that the requested modification can be made at
>the cost of: 3.7 hours 100% downtime for an estimated number of 1721 people and
>83 hours of reduced performance, possible corruption (so need to do it all
>again) and sudden broken disconnections, etc., etc. for an estimated number of
>8973 people. Furthermore an increase of 14% in administrational costs because
>of double work, etc., etc. Estimated extra costs for the first year: $314.500.
>And you need a temporary increase of 5 persons at the helpdesk to handle the
>expected increase in support calls ofcourse. Letting people sign contracts will
>not be enough to stop them from complaining, protecting their kingdom or simply
>showing off.
---------
	Boy, the above paragraph needs to be written in Red phospher!
Let me restate the problem in other terms for emphasis.
	It is very easy to fall into a fearsome trap of being technically
excellent and lose touch with the serviced population, our customers.
When that happens the customers can become unhappy and may have to resort
to brute force in lieu of cogent discussion because they feel inadequate
talking with experts. Then the brute force needs countering, but none is
permitted, etc. I happen to have fallen to this trap recently and life is
very difficult indeed.
	There are two ways out of it. One is to ensure folks are aware of
and integrated into the strategic decision making process as well as local
improvements. That's far from easy, but it is essential. Those folks then
are at least aware of limitations and are able to approach matters
incrementally with a basic idea of what is going on. They then are not your
natural enemies/barbarians_at_the_gate. The name for this is "working
together", from Boeing's experience.
	The second way is to not argue from opinion but instead let the
data speak for you. In this case data is most often the costs of providing
the wanted service. Costs include management fees.
	These approaches have a correllary problem of avoiding network design
and management by mob rule or by bullies. To avoid that "snag" there must be
mutual trust between the networking folks and the customers, and it's up to
the former to develop that trust. See the first way as a method to achieve
this trust.
	Last week I devoted part of a formal presentation to a large audience
of top system managers on just this topic. I happen to be living the story.
These problems are exceptionally difficult to deal with, and require both
significant effort and much careful thought. Once in confrontation mode things
are bad, believe me.
	Let me add two aphorisms I used as illustration:
	1. Beware the experts for they develop tunnel vision, by me last
December. Apply it to yourself first, as I did to myself. Experts also
include the self-appointed variety regardless of real knowledge.
	2. The problem with communication is the assumption that it has
occurred, from the book "Twenty-First-Century Jet" by Karl Sabbach. This
is by the Boeing engineer heading the B-777 project where this effect
occurred with a vengence.

>Also be prepared to answer why you didn't use NT Server.
>Technical statements alone will probably not be enough.

	This is too true. Again, explain the management costs to maintain
an NT server environment, and the things one can no longer do readily.
In other words, better mousetraps most often do not sell themselves.

>As I see it the workload will be mostly consumed by politics and handling human
>emotions (if people see that their known and trusted world is changing because
>of some outsider they are going to respond in all sorts of ways) and less
>because of technical issues during the first year. After a while they will have
>learned to life with it. But perhaps by then you're are looking towards
>something else ;)
>
>It helps if you involve people in your doings. Talk with them, don't send only
>memo's. It does cost extra time in the short run. It saves a bundle in the long
>run. And because you talk with them and involve them everything will be easier
>in the long run.

	Again, Arthur is right on target. There is no substitute for going
to much trouble for face to face meetings; it's the personal touch. The
idea is you are interested enough to go to that trouble, as a person, and
while you are there treat the customers as intelligent people.
	I'll wager that the great majority of computer shops do not go to
their customers and keep them involved, and that the more technically adept
the shop the more likely that major trouble will occur.
	Joe D.

---------

Date: Fri, 1 Aug 1997 10:19:10 +0100
From: Joe Harrison <joe@BRA01.ICL.CO.UK>
Subject: Re: NDS Tree Design...

I can't say how much I agree with what Joe D. and Arthur have said on this
subject, it's vital to CYA politically as well as the technical issues.

Can I just add that Cheyenne do a utility named DS Standard that seems to be
technically respected; this is an NDS modeling tool and in theory you can
build the entire thing in simulation before committing to the real deal. You
can get an crippleware evaluation copy from them, I'll be giving it a try
myself later this week in fact.

Cheyenne don't seem to have a South African contact number but if interested
try e-mailing them at sales@cheyenne.com

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

Date: Sun, 3 Aug 1997 23:41:10 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: NDS design question

>>[ROOT} and have a value of NET so that a user would see the their name
>>as user.xxx.wcpss.net  Is there a way to put this in?
>
>Sure, you could create an OU with that name. But just for this
>purpose to create an OU seems a bit odd...

Except for the fact that you can't place an OU under the [Root] ...

Presently, using Novell's utilities, there doesn't seem to be a way to
place any object under the [Root] except for a Country or Organization
(and, as you noted, the Country object naming is restricted to the
2-character codes in keeping with the X.500 naming standards).

There *is* an object type called Locale, which seems to completely
circumvent the usual restrictions on placement. The only time I've ever
implemented it was playing around on a test install, when I created a
server context something like
OU=container.L=place.OU=another.L=again.O=organization.L=location.C=US.L=somewhere

Perhaps a third-party utility (DSStandard?) would allow you to create this
container under the [Root] -- you could then move the Organization under
this.

Keep in mind that all distinguished names for all objects in your tree will
change after you make the move. If you're running Windows/DOS, check
Novell's documentation on the use of NCUPDATE to make the transition a
little easier...

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

Date: Wed, 13 Aug 1997 14:49:34 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: Check Equivalent To Me

>In Directory Services section of Servman there is SET parameter
>wich is: "Check Equivalent To Me".  What exactly is this parameter
>and how I can use it ?

The "Equivalent To Me" attribute was introduced in NW 4.10 and forms
a backlink for security equivalences. If A is security equivalent to B,
then A's "Security Equals" attribute contain's B's name and B's
"Equivalent To Me" attribute contains A's name.

I suspect what this parameter is controlling is whether this attribute
should be checked when determining a user's rights at authentication.
Normally checking the user's "Security Equals" attribute should be
adequate, but maybe there are situations where a name can be added to
an object's "Equivalent To me" attribute, without the other object's
"Security Equals" attribute being updated.

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

Date: Thu, 11 Sep 1997 10:37:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Subordinate Reference

>What are Subordinate reference replicas.

	It is nothing more than a pointer to lower down in the tree. It
indicates how to get down there. Replicas automatically have pointers,
superior references if one were to be precise, up the tree.
	Joe D.

---------

Date: Thu, 11 Sep 1997 13:04:18 -0500
From: Paul Burrer <pburrer@FLASH.NET>
Subject: Re: Subordinate Reference

Subordinate replicas are placed on servers where a copy (Master,
Read/Write, Read -although I never use read onlys-) of a parent partition
is, and a child is not.

---------

Date: Thu, 11 Sep 1997 12:12:28 -0600
From: Barbara Lewis <BLLewis@NOVELL.COM>
Subject: Re: Subordinate Reference

A subordinate reference is created under the conditions
described below.  It is usually referred to as a pointer, but
it is slightly more than that.  (Not much, though.)  It has a complete
copy of all the information for the partition root object of it's
partition.

One of the things that makes a partition root object
special is that it has a few hidden properties, one being
a list of all servers that have a replica of the partition.
The subordinate reference replica uses that information
to make it the pointer to the complete partition information.

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

Date: Mon, 27 Oct 1997 11:51:09 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: General Info

The following files can be used to check your NDS (for those of us who
have NW4.1x).

Dsmaint in two versions - DS410x.exe for Nw4.10, Ds411x.exe for
Intranetware (note you can use the Install.Nlm to perform the same
operations as Dsmaint.Nlm under Intranetware). Search for files at
http://support.novell.com

Scantree.exe - a Dos based utility for scanning the tree of your NDS.
Search for it as SCANDS.EXE at http://support.novell.com - Note that
this utility is NOT supported by the Novell Tech Services so use with
care. Usage -> SCANTREE /d > filename

Dsdiag.NLM - Diagnoses the NDS. This program is still in Beta, so
preferably use on a non operational server in your tree. Refer to TID
2928396 for info on where to download this file.

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

Date: Mon, 27 Oct 1997 22:33:12 +0100
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: recreating deleted Admin object

>Well, I'm sorry to have to be the bearer of bad tidings, but unless you
>had another user object with rights to the [Root] as per the Admin user,
>you have no recourse but to re-install NDS on your server.

You have several options left still.

First use DSMAINT to make a snapshot of your NDS so you have something to
restore if below options fail.
1. LOAD A:\DSMAINT
2. Prepare server for hardware upgrade
3. Restore
The whole procedure takes about a minute and leaves a special file in
SYS:SYSTEM containing the snapshot.

Second. Secure all your backup tapes.
Right now they are worth gold.

Option 1.
Call Novell for about $200. If you didn't use DSREPAIR too much Novell still
can re-instate your automaticly made backup of NDS (from the last time you run
DSREPAIR) that still should have a valid ADMIN account. Perhaps they will even
use the file DSMAINT makes to make the recovered NDS up-to-date.
Perhaps Novell can do even more.
BTW each of your three servers can contain such a backup NDS. No worry if only
one server was DSREPAIRed too much.

Option 2.
Another option is to scout the Internet for hacktools.
Be sure to find one that works with NDS not Bindery.
Hacktools have no warranty whatsoever. Use at own risk etc. etc.

Option 3.
See if you can still use your SMS compliaint backup program to restore only
NDS.  Some of these programs simply add NDS records to the current records.
It'll leave a mess to clean up but at least you'll have your Admin account
back.  Access your backup programm by logging in as the Bindery SUPERVISOR
if need be.

Option 4.
As suggested: re-install NDS and restore from backup tapes.
Practise this on testservers and/or less important servers before tackling
the main server.

---------

Date: Tue, 28 Oct 1997 09:48:44 +1300
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: "Re-create"  (default) Admin object

>What happend was the user Admin (default enterprise NDS administrator) was
>accidentally deleted.  And now we don't have other users in the tree to
>perform the NDS administrative tasks.   What I want is to "re-create"  the
>user Admin and assign all NDS administrative rights to this Admin user.  I
>know that I have to reinstall the server.  I will take this as the last
>resort.  Until then I am seeking help from any kind person.
>For your info the Novell software we are using is IntranetWare 4.11.

DreamLAN Consulting have a program which can solve your problem. Here is
a message from Steve Miller posted to this a few months back giving the
relevant info.


>>My NW4.11 server crashed during a Backup Exec backup. Upon
>>rebooting
>>the NDS system was out of whack, I ran DSREPAIR and all is fine
>>*except* that user ADMIN is now an "Unknown" object (as opposed to
>>being a user object), I cannot login as ADMIN, unfortunatly I did not
>>grant another user supervisor equivelency so when I run netadmin.exe
>>as a regular user I don't have the privilage of deleteing and
>>re-creating the Admin object.
>>
>>I can login as SUPERVISOR in bindery mode, but I can't run
>>netadmin.exe without NDS login.
>
>There is a third party utility called MakeSU to make a new Admin object
>from the console. This utility is licensed to your tree. To see a demo and
>for more information, get ftp://ftp.netcent.com/makesu.zip. I have not tried
>this program, but I like the other utilities put out by this company,
>DreamLAN Network Consulting. They make a toolkit (called NDS Toolkit)
>that includes this utility or you can buy it by itself. The last I knew the
>entire toolkit only cost $500 to $600. I think the MakeSU utility by itself
>might only be $100, and the guy at DreamLAN can probably mail it to you.
>Thats how we got our DSLogin utility from them.
>
>Steve Miller
>stevem@ftj.com

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

Date: Tue, 28 Oct 1997 12:45:39 -0700
From: Tim Madden <tmadden@ASPENRES.COM>
Subject: Re: INW 4.11 -- reinserting server into tree

>Please help.  I haven't been able to find this scenario on in the
>Novell TIDs. Here's the story. We have a INW 4.11 server that failed
>and we thought it would need to be replaced. We removed it from the
>replica ring and NDS. Now the server is repaired.  It has a
>read/write replica that thinks it is still part of our tree.  The
>master replica thinks the server doesn't exist. How would we get
>this server back into our tree? Can we safely connect it to our
>network and let it sink with the other replicas and then recreate
>the server object in NDS?

Why not just remove DS with install.nlm and then reinstall into the
existing tree?  Partitions and replicas can be re-established once
it's safely reinstalled.  Your tree *is* okay with out the server,
correct?

---------

Date: Tue, 28 Oct 1997 12:03:41 -0800
From: "David H. Wentworth" <David.Wentworth@UCOP.EDU>
Subject: Re: INW 4.11 -- reinserting server into tree

We tried removing DS with install.nlm and got error -625, cannot remove
directory services. I looked up "-625" in DSDOC2 and got "Explanation:
This error indicates the inability to communicate across the network either
between a client and a server or between two servers." So it seems we can't
remove DS as long as the server is isolated from the servers it thinks it
should be talking to. Our tree is fine (in sync) without the server.

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

Date: Wed, 29 Oct 1997 12:09:07 +0800
From: Leonard Holling <lholling@RANDOMWA.COM.AU>
Subject: Re: Novell Replication Services

>While evaluating Novell Replication Services, I have run into a very big
>snag. Here is the situation. Most of our company's production data and
>applications are being held on the SYS: volume. As you may know,
>Volume-to-Volume replication of the SYS: volume is not supported in NRS.
>The only replication that we are able to use through NRS is
>Volume-to-Directory. This method does not suit our structure very well as
>it replicates the whole directory structure from the Master server to the
>target directory on the Replica server. What I would like to know is if
>there is any way possible to have NRS perform Volme-to-Volume  replication
>on the SYS: volume or some kind of work-around that would make
>Volume-to-Directory replication behave like Volume-to-Volume replication,
>i.e. replicate one directory on the master server to the same directory on
>the replica server without the rest of the directory structure. Any insight
>or solution to this dilemma would be greatly appreciated.

There is a way. You could download the next beta of NRS and this does support
the SYS: Volume replication.

The filename is NRSEXTB3.EXE available from Novell on their web site.

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

Date: Thu, 30 Oct 1997 16:23:13 GMT+1
From: Steinar Kleven <Steinar.Kleven@AHS.HIST.NO>
Subject: New management tool.

A free management tool for NDS and NW 4.x servers based on perl is
available at http://www.ahs.hist.no/distr/NDSm/.

It's written as an extension to perl, and it tested with Standard
release of Perl running on a NT 4.0 ws.

If you get bored of waiting for a LDAP enabled script program you
can fetch this extension. There is NO charge, NO images and NO
promotions on the NDSm pages. This is offered to the users of Novell
NOS just to make life a bit easier.

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

Date: Fri, 7 Nov 1997 11:20:06 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: NW4.1 Printing

Without refering to your question about guest access to your print
queues, I'd like to take a sec (or two) and refer to the object called
[Public]. (not to teach you, but to use your q as a pointer to an
explanation).

*This is where one would normally put up a HUGE red light wish flashes
with sirens and a voice screaming DANGER*

[Public] as everyone knows, is not to be equated with the old lovable
group we call EVERYONE, excepting in one issue, and that is that
EVERYONE of the OBJECTS gets something from [Public]. That's it.

[Public] as an object (I like to call it a floating object since it
isn't viewable as an actuall object in the NDS tree), is used primarily
for pre Authentication stages. This of course means, that the reason
users can see the LOGIN directory is due to [Public] having the rights
to view and execute (files not people) there. This right is given to
users/objects/clients BEFORE actually being authenticated to the tree.

If this is the case, what would happen if I gave, say, the C right to
[Public] on my server object, or my tree etc ?

View the issue as far as [Public] is concerned as - that is a Dangerous
object to play around with. If I make a mistake, I am [in deep doodoo]

This is for everyone interested, not only for Bill, as I know from
teaching this subject (ok, so you've all found me out, I'm a minor CNI),
that users/sys admins think that using [Public] is a great way to give
rights and not have to worry about it again......WRONG.

---------

Date: Fri, 7 Nov 1997 19:09:45 -0500
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: NW4.1 Printing

Actually not quite as big a problem as it appears -- at least in NW4.1x,
[Public]'s rights are limited prior to login. You can assign rights in
various places in your file system, NDS, etc., but prior to login, you
only have access to those rights for the LOGIN directory.

That said, I always recommend that folks use [Root] if they really want to
give rights to *everyone* in the tree. Novell has changed the way [Public]
works in the past and I prefer not to be caught by surprise (and with too
many rights available) if they should do so again!

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

