---------------------------------------------------------------------- NOV-NDS3.DOC -- 19961028 -- Email thread on NetWare Directory Services ---------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Thu, 23 May 1996 12:00:22 -0800 From: Mark Schoonover Subject: Re: Reply to Get Nearest Server Problem. >On 8 May 96 at 7:57, Alan P. Belliveau wrote: >>I'm having a bit of a problem with some workstations. I have 2 1000 user >>4.1 servers. SERVER A has REPLY TO GET NEAREST SERVER = OFF. I'm trying >>to get my workstations to attach to SERVER B. The workstations are still >>attaching to SERVER A on bootup. I don't know why. > >I have noticed this "feature" (bug) of netware 4.1. Someone told me >that it appears to depend on the order the servers attach to the >network, but I have not tested this theory. I also have found three >different locations to set the "Get nearest server option" at the >server. The first two are in INETCFG, under the expert option in both >the protocol/ipx and bind/ipx sections. The third is the set >command. > >In the end I decided it really did not matter which server the users >first attached, other than the 10% of users who are still at the >login prompt of a test server when it's downed. > >Why does it matter to you where the users get attached? OK, this seems to be a fundamental problem in dealing with Netware 4.1. First off, you do NOT login to a specific server per se. You login to NDS. Yes, NDS has to reside somewhere, and yes, it can reside on any given server. If you do not have a replica, master, read/write or read only partition on a local server, you'll login to NDS on the nearest server that has a partition available for this purpose. Once you're authenticated by NDS, then any other server that is known to NDS will become available for you to use, if you have appropriate rights, etc. You can map drives, capture printers, etc. In my situtation, I really don't care which server I 'login' to. I don't have a slow WAN link to contend with. Some users in one building login to an NDS partition that is on a local server to them AND has the aforementioned replica/partition. They in turn run their repsective login script and accesses information/services provided by server(s) in other buildings. Just think of NDS as being 'above' the server, with the server baing just like any other leaf object in NDS. ------------------------------ Date: Mon, 27 May 1996 13:15:07 +0800 From: Osman Elias Subject: Re: Group Naming BUG? >One high school's netadmin showed me something strange in NDS's group >name. She has hundreds of student objects in one container and had >created groups for each grade: senior1, senior2 and senior3. >However, she found that the login script with the "member of" couldn't be >executed properly. The following is the simplified part of the script: > > if member of "senior1" then begin > write "Senior 1" > end > if member of "senior2" then begin > write "Senior 2" > end > >No matter to which group the students belong, both write statements are >executed! > >Finally she changed the group names from senior1 to s_one, and the >problem's gone! I can't explain it. Is there anyone can tell me why? I have encountered this problem before. I took 3 days to solve the puzzle. Actually NDS needs UNIQUE container name for the FIRST 3 CHAR. --------- Date: Tue, 28 May 1996 09:18:20 +0100 From: Phil Randal Subject: Re: Group naming bug? This is a documented bug in the original NW4.1 login.exe program. Get ftp://ftp.novell.com/pub/updates/nwos/nw410/log412.exe to fix it. ------------------------------ Date: Wed, 29 May 1996 10:35:44 +0100 From: Peter Scherrer Subject: Re: Not droppning connections from NDS >I am having a strange problem with my 2 Netware 4.1 servers on the >same tree. > >I have 2 NW4.1 servers on the Student Tree serving 3 Student Labs. >The students are allowed to log in from any of the labs into the tree >and will be given access to the required servers depending on where >they log in from. > >The problem I am having is that a student could just logged out from >one lab and then go to the other lab and try to login but cannot >because we had restricted one login only and the system is saying the >the student is still log in. > >A check on MONITOR shows that that student is not log into any of the >servers but in NWADMIN in Enviroment entry of that student had a IPX >address which cannot be deleted and the only way we can overcome the >problem is to give the student another login , ie 2 logins. > >I am running DS.NLM v4.89c. That is a know problem. In the latest DSREPAIR.NLM (4.35?) is a parameter, that allows you to remove all IPX addresses that are older than a given time, default is 60 days, but it can be changed. The other solution for your problem would be to have the same user login at the the same station in the first lab, and then logout correctly. ------------------------------ Date: Fri, 31 May 1996 11:10:40 EA From: Greg J Priestley Subject: Re: NDS Alias problem >We are trying to alias remote-office users so >that when they log-in to the local tree the >WAN link is not opened unnecessarily to run >their home log-in script. > >The tree & accounts/aliases are: > > NLK > +--------------------+ > VCR KENT > (A) VCR_Usr Test_Usr > >When "VCR_Usr" (an alias of Test_Usr) logs in, >the following occurs: > >Your current context is vcr >Enter your password: >Alias login as: TEST_USR.kent >Your current tree is: NLK >You are attached to server ENG0. >Authenticating to server KENT1. >You are attached to server KENT1. >Executing KENT login script >Authenticating to server ENG0. > >The naughty bits are the "attaching to server KENT1" >and "Executing KENT login script" outputs. An alias is merely a pointer to the other "user". Hence you will still run the login script, etc, of that user which means, unless you specifically write your login script to not do this (based on testing context or location), that you will have your normal resources (which are on the far side of a WAN link). Fun fun fun. I'm mid way of doing a solution for this for a client and may knock up a report of my findings and solutions to this problems when I have it all up and running. ------------------------------ Date: Fri, 31 May 1996 11:35:22 -0600 From: Todd Herring Subject: NAME CONTEXT -Reply >I would like to place users in separate containers, as follows: > >O=BTI > OU=Accounting > User 1 > OU=Client Services > User 2 > OU=Professional > >If users 1 and 2 share the same workstation, I can't use the NAME >CONTEXT in >NET.CFG to specify the current context, because it changes depending >on who is logging in. Does anyone know of any workarounds? This is probably a FAQ-worthy question. I looked for it and didn't see anything in the latest FAQ, but this has been discussed a number of times (I posed this question once, too). Here are some possible solutions: 1. Teach users their distinquished names (ie, .USER.ACCOUNTING) 2. Create your own front end to LOGIN.EXE to ask the user where they belong. Give them a menu of choices -- Are you in A) Accounting B) Sales C) Marketing... I'm no programmer, but I managed to do this with a batch file and Nortons Batch Enhancer. 3. Find a third party program to perform number 2 above. Someone on this list offered one he had written. Not sure who. 4. Find a program called FLOGIN that I've heard will fix this. Again, don't know who, where, or how much. I've looked but haven't found it. Anyone know? 5. Wait for Novell to come out with something. Will Green River offer a solution? ------------------------------ Date: Fri, 31 May 1996 13:24:07 -0400 From: Rick Troha Subject: DS.NLM v5.01 Now Available For those running NW4.1, DS.NLM v5.01 is now available in file 41NDS9.EXE. ------------------------------ Date: Fri, 31 May 1996 23:47:16 -0700 From: Randy Grein To: "NetWare 4 list" Subject: Re: Moving a server All you really have to do is go to NWADMIN, grab the server object along with the volumes and drag them to the new container. Edit the server context in Autoexec.ncf and you're done. Of course this method retains all the user rights, etc. which you MAY not want to keep. ------------------------------ Date: Sat, 1 Jun 1996 14:17:28 -0400 From: Debbie Becker Subject: Re: NDS Woes . . . >At my site I am managing 140 users on four (4) NetWare 4.10 file >servers, SACFSA1, A2, A3 and AA. All object are kept within one >Organization without any Organizational Units. This is because there >are so many users requiring access to so many different resources, so >in essence it resembles a simple "flat" bindery. > >A1 contains the Master replica and A2 and AA hold R/W replicas. A3 is >simply there. (4th and subsequent servers default to no replica). >Early this week I did what should have been a simple task and ended up >being a major pain. SACFSAA was a P100 with 2ea. IDE HDDs. I was >short on space so I needed to replace these drives with a Seagate >2.4Gb SCSI. In doing so, since I would be replacing volume SYS I >decided to utilize DSMAINT. Following the instructions of DSMAINT, >all seemed to be going well... at least until I re-activated NDS on >this server. > >The next morning after the "upgrade" I ended up with approx 1/3 of my >objects being corrupt or missing. Several groups were gone, all but >one print server was gone, and thus many users were upset that they >could not print or access their files. I attempted to recreate the >missing objects but when doing so I'd either receive an error that the >object already existed or it would allow the recreation of the object >but soon the object would change names with an update to something >like 0_1 or 1_1. When I would look into these objects under "Other >Name" there would be the name by which it originally went by. Aside from the usual "make sure you're using the latest versions of DSREPAIR, DS.NLM," etc., I'd suggest that if you're going to bring a server down which has multiple replicas of the partition, you make a few changes. In your case, I'd have either changed the Master replica of the partition on A1 to a Read/Write -- or, more likely, have removed it altogether and placed the Master on A3. You can always re-place the replica after the hardware has been changed out and NW4 reloaded. Just seems like an easier, "no chances" way to do things... ------------------------------ Date: Sat, 1 Jun 1996 14:29:50 -0400 From: Debbie Becker Subject: Re: NDS Synch Problems on 56K Lines? >I have heard reports of NDS sync problems when WAN links >are only 56K. Has anyone experienced this? Is 64K any >better? 128K? Only input I have on this is that, apparently Novell Consulting Services recommends placing replicas only across "fast" WAN links (which they define as T3 or faster). --------- Date: Sat, 1 Jun 1996 16:19:05 -0400 From: "Martin C. Mueller" Subject: Re: NDS Synch Problems on 56K Lines? >>I have heard reports of NDS sync problems when WAN links >>are only 56K. Has anyone experienced this? Is 64K any >>better? 128K? > >Only input I have on this is that, apparently Novell Consulting Services >recommends placing replicas only across "fast" WAN links (which they >define as T3 or faster). We're living happily with a 64kbit ISDN-Link for three years linking two 4.1 servers. The tree's three replicas reside each on both servers. Never had any sync problems due to network speed, the tree even survived connection outages of more than one day. The line is being operated transparently by a CISCO-router within a LAN and serves the communication needs (TCP/IP and IPX) of about 25 people with the main computing resources on this side and the Internet on the other. --------- Date: Sat, 01 Jun 1996 08:20:24 -0400 From: Rick Troha Subject: Re: NDS Sync problems on 56K lines? >I have heard reports of NDS sync problems when WAN links >are only 56K. Has anyone experienced this? Is 64K any >better? 128K? One of my customers gets intermittant DS error 625 across a 56k frame relay link. The servers will exhibit the error for 10-15 minutes and then sync up again. Here's a little something from Novell on the subject from TID1202460: WAN LINKS Bad communication over a 56kb wan link is a common cause of -625 error. The most common scenario is one in which we may have a central location and several remote sights each across a 56kb wan link usually with frame relay. In these situations if a replica has to travel more than one 56kb link there will be communications problems resulting in a -625 error. To remedy this problem a faster link must be used or some changes in configuration must take place. There are changes that can be made to help prevent the loss of communications over 56kb wan links. It is suggested that an organizational unit be created to hold the necessary objects at the remote sight. This OU is then made into a partition and replicated on the server at the remote sight and then replicated on one or two servers both at the central sight. This way only one 56kb link is traversed to maintain syncronization and fault tolerance is maintained. This can be duplicated for each remote sight. There are two other common problems that fail to be recognized when designing and implementing a directory services tree across wan links. The first problem is the transfer rate over the wan link. The second problem concerns installing a remote server. If a 56kb wan link is to be used and there is not a guaranteed transfer rate there is potential for problems. Assume things are running fine one evening and you are attempting to do some partition operations. At the same time another company kicks off their backup across the wan and your throughput drops. If the line is not guaranteed 56kb you may now be at 20kb and then there are -625 errors everywhere and there is nothing you can do until the transfer rate comes back up. Many remote servers are created at a central location before being shipped out to the remote location. In most cases install takes place, things look great and the server is downed and shipped out. Once on sight the server is brought up, replicas sync across the 56kb link, and everything looks great. Assume a drive goes bad on this server and now we replaced the drive and install NetWare again. We have replicas on other servers so we will put a replica of the partition back on this server. When we attempt to get the replica we get -625 errors. The problem is that up until now the only traffic on the link is traffic to maintain syncronization. Now we are trying to pull a replica of a partition with all of its objects across and the link can't handle it. The best way to fix this is with a better link. There are problems where the link is sporadic or the link is providing consistent enough performance for SPX to function but not enough for NDS information to synchronize. This can be a difficult problem to isolate because often the other SPX applications work fine, but NDS still returns -625 errors when it tries to access a server on the other side of the link. In this specific case you may be able to work around this problem using a couple of DSTrace commands to increase the listening time. Listening time is the time after which IPX will time out if it gets no response from a device on the network. To use these commands you need to understand the following formula: Listening Time = Tick Count x Scale Factor + Shift Factor !Y !Z Tick This value is provided by IPX (or the transport protocol Count: that is being used) and is calculated by the server based on routing information it has received. Scale This value is multiplied. For this reason you need to be Factor: careful not to change the value too far from default (default value is 16, range is 1-80). Shift This value is used to granulate the scale factor (the Factor: default value is 10, range is 1-500). You can view current settings by setting dstrace=*p IPX:Retries = !X IPX:TimeOutScaleFactor = !Y IPX:TimeOutShiftFactor = !Z Here is an example of how to set the X, Y, and Z parameters: SET DSTRACE=ON SET DSTRACE=!X4 SET DSTRACE=!Y20 SET DSTRACE=!Z40 The !X parameter changes the number of IPX retries that occur before a -625 message is sent to the console. The default value is 3, and we recommend that you set the value no higher than 5. The range is from 1 to 500. Do not change the X, Y, and Z parameters unless absolutely necessary. If you increase these values, in some processes NDS performance will drop significantly. We suggest that instead of raising these values you improve the link used to increase the capacity. If you increase the Y parameter, we recommend that you create local copies of all of the objects referenced by the users so that the link is not used. This way the link will be used primarily for synchronization and not to access NDS objects. If you do not follow these recommendations, 4.x users may see a significant performance degradation. --------- Date: Mon, 3 Jun 1996 15:21:29 -0400 From: Barbara Lewis Subject: Re: NDS Synch Problems on 56K Lines? >I have heard reports of NDS sync problems when WAN links >are only 56K. Has anyone experienced this? Is 64K any >better? 128K? I have talked with some people in a banking environment where the company has branches all over the world and right now they have 56K lines. Novell has recommended a minimum of 64K and would prefer they get T1. ------------------------------ Date: Tue, 4 Jun 1996 12:09:19 -0600 From: Joe Doupnik Subject: Re: # of objects in a container >I am planning on having up to 10,000 student accounts on our >Netware 4.1 network. Based on advice obtained from this list and other >sources I have created 3 containers to hold the user objects. Because >of the various contexts this creates our students are having difficulty >during login. (Having to login .smithj.student1.lrc.vb). > >Question. Will the upcoming 32 bit version of NWAdmin allow us to >consolidate the student user objects in a single container? > >Or will Green River have a login that simplifies logins to various >containers? ---------- NWadmin is a Windows program, not NDS itself, and thus has no bearing on the number of objects in a container. The advice from Novell is stay under 1500 objects in a container because the NDS software (NLMs) takes too much time with more. You certainly do not want to contemplate 10K objects in one container. Green River doesn't solve this database size effect either. You will need to educate your users ever so slightly that context is rather like an Email address, so use the long form and achieve success. If ISO had any sense they would have used @path notation too. Joe D. ------------------------------ Date: Wed, 5 Jun 1996 08:25:17 -0800 From: Mark Schoonover Subject: Re[2]: Alias usage The preferred server statement is used for bindery server(s)/services only and is mutually exclusive to Preferred Tree. I've found it to be bad practice to use both at the same time. ------------------------------ Date: Thu, 6 Jun 1996 22:49:28 +-1000 From: Phil Montgomery Subject: Searching NDS live >An alias object is simply a "pointer" back to the original object (in >fact, if you look at Details for the alias object, you'll see that the >name for it is the original object name). > >If you're working in a relatively small environment (no WAN links, >small number of partitions) you might try one of the third party programs >(FSLOGIN or SFLOGIN) which allow you to login using the common name. The >program will then search the Directory and log you in (or give you a >listing of all objects with the same common name and ask which one you >are). If you're working with WAN links or lots of partitions, this can >become impractical (slow!) I agree that searching NDS live over large WAN links or many partitions can be slow. At Netoria (publishers of SFLOGIN) we have built a client server NDS indexing system known as 'fiNDS'. fiNDS is an NCP extension based NLM that builds and manages a server based NDS index. SFLOGIN communicates with fiNDS, using an API almost identical to Novell's NWDSSearch. However, fiNDS can locate any object almost immediately. In our testing we setup an NDS tree of 14 MILLION objects (SYS volume took four hours to mount!). Using fiNDS, SFLOGIN could locate any object is less than 0.25 seconds. An organisation can have one or multiple fiNDS servers, and they can use our own API to write their own programs that talk to the server. We will be releasing a beta of this technology in a few weeks. If you are interested then drop me a line or have a look at http://www.netoria.com. ------------------------------ Date: Mon, 10 Jun 1996 10:28:09 -0400 From: Debbie Becker Subject: Re: Merging 4.1 servers >I recently installed 2 4.1 file servers in an org. everything is >working fine. > >This org wants to merge both 4.1 servers into 1 superserver. are there >any tools that will let me do this, keeping current nds tree >definitions? how should I confront the issue? should i add the server >into the tree and bring users into the new context , then delete other >servers from NDS or can I use migrate to merge 4.1 servers? Any ideas >or experience doing the above??? Why would you need to create a new organization to do this? Remember, in NetWare 4.1, you're logging into the network, not on a server by server basis. From an NDS standpoint, all you need to do is to install the server into the existing tree. Place a replica of the partition on the server and make sure it's in sync. You *will* have some cleanup to do on the back end. You'll need to change any "Preferred Server" statements in the NET.CFG files on workstations. You'll need to check for "Default Server" property for users and change (use UIMPORT) if necessary. You will also have to make sure that mappings are referring to the same directories on the new server as on the old. In terms of file system, you'll need to backup (SMS compatible backup, please) from both servers and then selectively restore on the new one (*after* NDS has been installed) so that you still have your user directories, etc. In spite of this, you may end up having to rebuild some of the file system rights, so make sure that they're documented prior to doing this. ------------------------------ Date: Wed, 19 Jun 1996 15:38:08 +0100 From: Stuart Phethean Subject: Re: A large container, bindery emulation, nds traffic >I work at a small university with 6000 students and at this moment >these students are working on 3 netserver 10G 64M HP netserver LH >machines >2 contain apps and userdata >1 contains the printerqueues group data and mail (pegasus > mail is used with mercury) > >all 6000 students have their own account on the network and need to >be able to work from any student computer and all apps (about >500 pc's and 20 printers) >- large waiting times after changing adding nds objects/properties > >possible solutions >divide in more containers and multiple comntainers in one bindery >put printerqueues volumes fileservers in a different container to >speed up mapping capturing etc. > >does anyone have experience with these , what is the solution in your >organisation. We have, at present 13000+ users with each alphabetical group a ... z present in a separate container (ie 26 containers). Each container is also a replica, which is present on two other servers as well, so we have three central servers in all. Novell recommend ( and so do I !) not much more than 1000 users per container or replica. We had big server crashes when we had much larger containers. I set bindery contexts for containers a..h on server 1, i..q on server 2 etc etc. User admin using Uimport works fine. Servers do tend to work quite hard keeping in sync, but we are upgrading RAM this week from 64MB to 96MB. Dsrepair does take a while, but thats just a function of the total number of users and not the number or size of container. The LRU time in the cache statistics is about 40 - 50 minutes - on our other NW410 servers which just have more local information it is in the order of 1 - 2 DAYS! At present we have only the central user-id servers running NW410 - we will be gradually migrating our 28 NW312 applications servers to NW410 once we are confident that our central authentication servers are standing up to the load. At present most connectivity is via bindery emulation. ------------------------------ Date: Wed, 19 Jun 1996 23:51:25 +0200 From: "Arthur B." Subject: Re: A large container, bindery emulation, nds traffic >I work at a small university with 6000 students and at this moment >these students are working on 3 netserver 10G 64M HP netserver LH >machines >2 contain apps and userdata >1 contains the printerqueues group data and mail (pegasus > mail is used with mercury) > >All 6000 students have their own account on the network and need to >be able to work from any student computer and all apps (about >500 pc's and 20 printers) > >All objects are at this moment in one container. >bindery based applications can easily work like pegasus mail, >lanskool etc. >replica's are on all servers. > >We are in the process of putting all bindery based stuff on the >groups/mail server . > >Problems. > >- Long waiting times when logging in and when capturing to > printers. etc (all things that need to get information form the > ( nds/bindery ) Making good use of replicas should help you to speed up the process. Maybe you need to redesign your NDS tree if that doesn't help much. >- Replica actions (deleting a replica running dsrepair etc) last for > hours an working at that moment is almost impossible Doesn't SERVMAN has some settings to make this happen during off-hours? Not sure on this one though. Please check. >- large waiting times after changing adding nds objects/properties See above. If there really isn't anything to finetune anymore then maybe you're in need of a 100Mhz server backbone. >Possible solutions: >Divide in more containers and multiple comntainers in one bindery >Put printerqueues volumes fileservers in a different container to >speed up mapping capturing etc. Reevaluate your NDS tree design and your replica distribuation. With your amount of objects buying a good book about it could give you some answers and more too. >Does anyone have experience with these , what is the solution in your >organisation. Read before you plan. Plan before you work. Test first before you implement. Then work the plan. --------- Date: Wed, 19 Jun 1996 16:14:01 -0600 From: Joe Doupnik Subject: Re: A large container, bindery emulation, nds traffic [Floyd: repost of the above post snipped] I recall from Novell's Brainshare/Developer's Conference this year that the time to perform NDS operations grew exponentially or so as the number of objects in a container grew. Their recommendation was to cap that growth by putting the same number of objects into more containers, which I term "factoring the problem" from common mathematical techniques. Sort/merges face the same problem, and the NDS work is basically of that kind. See Don Knuth's series "The Art of Computer Programming." Partitions have one or more containers, and one or more servers. The servers form an exchange group holding identical data. Partitions are traffic control devices, not directly NDS speed ups (though going from one partition to another obviously slows down matters a lot *unless a replica is on the same server*). I suspect that the traffic is the same whether we have many or few containers, for a fixed number of servers. So, by factoring/multiple containers (those logical thingys) we should be able to reduce the lookup/replacement workload on a server and run faster. Their advice is keep the number of objects per container under 1500 or so for best performance. And, from private conversations, the troops are trying to find ways of speeding up these things. That's what I remember from the presentations without dragging out my notes. Anyone else have a better memory? Joe D. ------------------------------ Date: Fri, 21 Jun 1996 09:46:05 +1200 From: "Baird, John" Subject: Re SUPERVISOR user in NW4.10 There is actually a SUPERVISOR object on NW 4.x. According to a brief note in the NetNotes section of one of the recent Application Notes, the SUPERVISOR object exists in a context named "bindery" which is always present on a NW 4 server. This "bindery" context is the same one used to hold objects created in response to receipt of SAPS, which explains why it is possible to use a bindery function to scan a 4.x server for known file servers (as SLIST does), even when no bindery context is defined via the console "set bindery context" command. The SUPERVISOR object is apparently always present in the 'bindery" context, but becomes visible only after one or more NDS containers have been set to bindery contexts via "set bindery context=". ------------------------------ Date: Fri, 21 Jun 1996 12:39:29 -0600 From: Joe Doupnik Subject: Novell's NDS wisdom, in one file In directory pub\updates\nwos\nw410 is file DSDOC2.EXE, 1.7MB, which is an Envoy format (i.e., run under Windows) document describing a great many details and terms regarding NDS. I sense the doc is still rather fluid (it was changed again overnight) and has a ways to go. But this 363 page tome is a gold mine of useful information (what a job it must be to compose it!). Visit ftp.novell.com or official mirror sites near you. Joe D. ------------------------------ Date: Thu, 27 Jun 1996 19:52:10 -0400 From: "J. Darren Lofthouse" Subject: Re: removing nds >I can't remember how to remove the nds from a single server tree... Type: Load install -dsremove Then go to "directory options", and "Remove Directory Services from this server" ------------------------------ Date: Sun, 30 Jun 1996 14:40:09 -0700 From: Randy Grein To: "NetWare 4 list" Subject: Re: Tape Backup Systems >While at the Novell Connect your World Seminar, several vendors made this >claim (all associated with Cheyenne somehow) Although many products backup >your NDS, only Arcserve 6 backs up the extended NDS Schema. This would >mean that any product you installed that modified the NDS schema would >have to be reinstalled if you needed to restore your NDS from tape. >I would like to know if anyone else has heard this. This is unfortunately true. I spent some amount of time grilling Novell about this at Brainshare. It has to do with lack of support for extended schema backups in (of all things) SMS! It is fixed in Green River (NW 4.11), but Novell won't release any patches to correct the problem for 4.10, at least until after 4.11 is released in September. This is a pain, but not as fatal as it sounds. At least the information is still there in the backup, and all you have to do is re-install whatever extended the schema. ------------------------------ Date: Tue, 2 Jul 1996 09:57:09 -0400 From: Debbie Becker Subject: Re: Authenication Process I tend to use the Preferred Server statement in networks -- usually I prefer to leave the whole network in one tree. I point the Preferred Server toward a local server that contains a writeable replica containing the user's object (otherwise, the attachment will take place and when the user logs in s/he will re-attach to a server with a replica after some "tree walking", which tends to slow down the process). In my experience, the Default Server parameter will *always* override all preferred server statements. Default Server is the server through which you receive broadcast messages (i.e., the one that you'll be listed under in NetWare User Tools). Yes, there are *still* some server-based issues in NetWare 4! --------- Date: Tue, 2 Jul 1996 11:05:44 -0400 From: "J. Darren Lofthouse" Subject: Re: Authenication Process >In my experience, the Default Server parameter will *always* override all >preferred server statements. Default Server is the server through which >you receive broadcast messages (i.e., the one that you'll be listed under >in NetWare User Tools). Yes, there are *still* some server-based issues >in NetWare 4! The Preferred Server is the server that the client tries to attach to after being loaded. The Default Server is a NDS Object Property that, like you said, determines where you recieve your broadcast messages from. These are totally different so how can one "override" the other? Besides, the Preferred Server is done before you ever login to the network and the Default Server is dependent on what your login id is so how can Default Server affect Preferred Server? --------- Date: Tue, 2 Jul 1996 11:29:58 -0400 From: "Martin C. Mueller" Subject: Re: Authenication Process [in reply to the above 2 messages] It overrides in the sense, that after attaching to the Preferred Server, the client, having obtained the Default Server propertie's value, attaches to the Default Server, seemingly loosing attachement to the Preferred Server, since, if needed, is re-attaches to the Preferred Server. We had this situation here with two 4.0x servers connected by a WAN link. By chance and ignorance the Default Server happened to be across the link for some users. So the client did three attachments in succession, two over the slow link, which caused considerable trouble with early OS/2 requester versions. In the case, were the nearer server didn't hold a R/W replica of the partition in question, only two attachements were reported, because the client attached to the remote server (the one holding the replica on this case) right away. Nowadays here Preferred Server is the server nearest to the workstation (NET.CFG setting), Default Server is the server nearest to the workstation the particular user commonly logs in from and both servers hold writable replicas of all partitions. ------------------------------ Date: Sun, 14 Jul 1996 16:30:38 -0400 From: Debbie Becker Subject: Re: Supervisor right to Server >>I have created an Organisational Role with limited access to the file >>system but full access to the NDS so that certain administrators don't >>accidentally overwrite valuble files during software testing etc. >> >>Anyway, the way I did this was to reassign rights at the file server so >>as not to include the [S] right, which would otherwise flow down to the >>file system. > >First, give Admin or some other appropriate account an explicit >assignment of [S] to the server object. Next, apply an IRF on the server >object to block the S right. Your OrgRole object won't have access the >file system via NDS after doing this. If it does, then it's getting it some >other way -- security equivalence, group membership, or an explicit >assignment to the volume. The bottom line is, the [W] property right does >not give anyone access to the file system. Having [S] to a file server >object (either explicitly or through inheritence) is the only "bridge" >between NDS trusteeship and file system rights. > >>Now for my question, I noticed that if I assigned the [W] property right >>to all properties, I got all rights to the file system regardless of what >>object rights were assigned! Which property it is that, if given write >>access to it, allows full access to the file server's file system ? I agree entirely with Todd's solution (have made it SOP to assign one or two Supervisors to a server and then set an IRF). You should be aware, however, that there's more than one way to get that Supervisor access. Giving someone Supervisor Object right to the file server object also gives them (by default) Supervisor right to All Properties (including the Object Trustees List -- also known as the ACL). It's having the Write Property right to the ACL that actually gives the user the file system access. Have experienced this many times. I show examples in classes in which people at higher level containers (a secretary in the Corporate office, for example) is given Read and Write rights to All Properties of the container (in order to maintain a mailing list, for example -- yes Admin should have used Selected Properties, but didn't!) If there's not an IRF on the server two containers down, the secretary will end up with Supervisor access to the file system. ------------------------------ Date: Mon, 15 Jul 1996 20:24:19 +0100 From: Gabor Borsodi Subject: Re: NDS >I need to upgrade the hard drive on one of our NW41 servers. At the >same time I also want to remove compression. I understand that the only >way to do this is to reinstall Netware. My concerns are with NDS. I am No, it is not the only way. Please upgrade your NDS to v5.01 in 41nds9.exe, and read carefuly through the readme.txt and dsmaint.txt. The thing you will need is dsmaint.nlm. >not so clear on how I can get back my users, printers, queues, etc after >I reinstall Netware. We have a total of 5 NW41 servers. The one I am >ugrading was the first and is serving as the "Master". Here is what I >plan to do: > >1. Backup the server > >2. In NWADMIN (Partition Manager) change the > "Master" partition replica to "Read Write" and > assign another server as "Master" Then here comes the missing step with dsmaint. >2. Down Server, Remove the 2GB and install the 4GB (Funny numbering... :-)) >3. Reinstall NW41 on the 4GB As you will see here comes dsmaint to restore. >4. In NWADMIN (Partition Manager) choose "Receive Updates" to this server > Will I get everything (users, printers, etc) back? Using dsmaint, yes. >5. Restore data onto server > (I read that you need to restore the NDS first, then the data?) NDS will be already restored. You will need to restore only the volumes. ------------------------------ Date: Wed, 31 Jul 1996 08:31:20 -0600 From: NetWare News To: netwarenews@NetPub.COM Subject: Press Release -- NDS Update Media Alert July 30, 1996 Novell Directory Services Update Now Available to all NetWare 4.1 Users Enhancements Improve Network Performance What: Novell today announced the availability of a Novell Directory Services (NDS ) Update. The update significantly improves NDS capabilities, enabling users to enjoy improved performance and flexibility in their NetWare 4.1 network directory. Novell is delivering the NDS update as a single set of NetWare Loadable Module (NLM) files that network administrators can easily install onto existing NetWare 4.1 networks with no disturbance to users. The enhancement consists of a new DS.NLM (version 5.01) and a new DSREPAIR.NLM that improve message transmission accuracy by providing the following protocol-independent features: Prevents corruption sometimes encountered during transmission, especially with some older hardware Cuts tree repair time on large networks by as much as 70 percent Identifies and contains corrupted tree segments to protect the rest of the network Finally, the update serves as an intermediate step to Green River functionality. Novell strongly recommends all NetWare 4.x customers download this update, which is available free to registered NetWare 4 users. Implementation of this NDS update is suggested for organizations planning to run both NetWare 4 and Green River as part of their upgrade process. When: The NDS Update is available now. Network administrators can install the update over existing NLMs, and full installation instructions are included. Where: Users can download the update on the World Wide Web at http://netware.novell.com and on NetWire in the NWOSFILE library 01 (file 41NDS9.EXE). ------------------------------ Date: Thu, 1 Aug 1996 22:27:12 -0700 From: Randy Grein To: "NetWare 4 list" Subject: Re: restoring and home dirs?? >We couldn't get Pegasus Mail to work at all. After hours of trying >everything, it came to checking the User's NDS environments. Lo and >behold, all of the 'home directory' properties of every user was >empty. You've got to restore NDS or the bindery FIRST, then the directories. This could be the problem. ------------------------------ Date: Tue, 06 Aug 1996 16:06:40 -0400 From: Michael Yelland Subject: FAQ material ? Q. How do I recover from a corrupt DS.nlm A. If ever the DS.nlm becomes corrupted, DS won't load, and so there can be no logins either NDS or bindery, since NDS minus DS.nlm != bindery only. Server -na won't work since SYS will automatically mount which will also load DS. The solution is to run "server.exe -ns" which won't load startup or autoexec.ncf, then run "load a:\ds.nlm" then DS will load, then mount SYS: and you can log in and replace the DS.nlm on /SYS:SYSTEM ------------------------------ Date: Thu, 8 Aug 1996 22:45:03 -0400 From: Debbie Becker Subject: Re: 4.1 Server IRF's >I wish to take all reasonable measures to protect our servers from objects >in the tree with any and all rights except Supervisory. I will assume only >admins and equivalents will have S NDS rights at any time. I do not wish >to filter out the S right unless it appears mandatory for protection. First off, the NDS rights that will "flow" into the file system (i.e., give the NDS trustee Supervisor file system right to all volumes on the server) are the Write property right to All Properties of the server object. If you have the Supervisor object right, you will, by default, get Supervisor (including Write) right to All Properties as well. Note that you can have these rights to the container in which the server resides and get Supervisor file system rights as well, since rights that you have to the container apply to all objects in the container (including subcontainers and objects under them). To protect against this I follow certain steps when installing a new server: 1) After server installation I immediately assign a user as a trustee of the server and give him/her Supervisor right to the server object. This means this person will have full file system rights as well. In your case, I would make a group and assign all Supervisors/admins to it and assign the group as a trustee as well. NDS does seem to want to have a *user* object with the S right before allowing you to block it with an IRF, however. 2) I then set an IRF on the server object to block *all* object and property rights (except Browse object right). This will keep other users from "accidentally" getting access to the server through NDS. Have seen this happen more times than I care to think. Had students in a class once say that they had a consultant set up their 4.1 network and now everyone in the container had Supervisor file system rights to the server. Told them to check to see if the container was a trustee of itself with Supervisor object rights and, sure enough, it was. Why did he do this? One assumes because it was an easy way to make sure that everyone had all the rights they needed (not to mention a lack of knowledge about NDS!) ------------------------------ Date: Thu, 8 Aug 1996 22:45:13 -0400 From: Debbie Becker Subject: Re: Alias user Logins >I want to allow mobile usrs that visit our branch offices to be able to >login at the branch office. I'm thinking that I would use the alias object. > >How does one make an Alias user object use the container login script >where the Alias user object resides instead of the container login script >of the real user object? Last time I checked it out, Alias objects would only run the login script in the original object's container. To get the Alias object to use the Alias container login script you'll have to do something like: 1) Grant the Alias user the Read property right to Alias container Login Script property. 2) In the Original user's container login script you will have to add something that will point alias users to the new contianer script. You can do this by putting in: IF REQUESTER_CONTEXT="Alias_Container" THEN INCLUDE Alias_Container_Distinguished_Name EXIT END I'd put this at the beginning of the Original container login script, so that the user will only run the commands from the Alias container and not overwrite with the Original container script mappings, etc. And, please check me on the variables -- don't have the Red Books handy, but think this is the right one (Supervising the Network - login scripts). ------------------------------ Date: Fri, 9 Aug 1996 16:11:22 -0600 From: Joe Doupnik Subject: Re: Re2: NDS Partition that can't be deleted >>>I'm working with a new company that has a NDS partition that was >>>residing on a 4.1 server. The server was deleted from NDS, and now >>>when I go and try to delete the partition it gives me an error because >>>it can't find the server. >> >> Yes, it can happen. We presume you are using the very latest in >>ds.nlm/dsrepair.nlm, but if not do so now. Please read all the docs Novell >>provides on using dsrepair, and keep in mind that it is possible to create >>an indelible ghost (subordinate refs that won't vanish). For the moment >>the cure is to a) backup everything carefully and then b) call Novell. >> I have such a case, and I've talked with the fellow in charge of >>NDS. His comment is there is a fix in the works, but no timeline for its >>release. >> Joe D. > >I believe that an undeletable subordinate reference is my problem. I have >two concerns though. The system people here want to start adding servers >and making changes to the tree. Will this be safe? The second problem is >that the system people tell me that the NDS tree can't be backed up because >of this problem. Apparently the backup software (Palindrome) doesn't like >the >bad subordinate reference. Is there a work around short of recreating the >tree? > >I have heard that you can save parts of the tree with DS Standard. Would >it be possible to save each part of the tree separately, delete the tree >and then put the good pieces back together? ----------- The story goes like this. Yes, you can damage a tree if not careful. That means don't spread top level priv's around, and isolate sections so that damage is limited. But even damage at the bottom can corrupt a tree as indicated above (I have such a case). Novell is well aware of the problems (I've gone down my list, face to face) and is fixing them one by one. Backing up NDS. The solution is Green River, not before. TSANDS and TSA410 for GR permit safe and complete backup/restores. I'm running GR here. Last spring I had some changes made to this process and they should be in the shipping product. Expected ship date of GR/NW v4.11 is September. It can be installed right on the top of NW 4.10, quickly and safely, with no loss. General health. Always use the very latest ds.nlm/dsrepair.nlm, NOT the versions shipped with NW 4.10 (oh please). Read the guidance by Novell and follow those steps carefully. I know, that stuff reads like magical incantations, and that's pretty close to the truth. When in deep NDS trouble you will need to call Novell a.s.a.p. Don't try to fix something badly broken because you can easily make it worse. The future. After GR we expect to see federated domains where NDS is split into semi-independent regions to give more fault isolation as well as solve the serious political problems of sharing. There's more along this pathway but I'm not allowed to discuss such things. Joe D. --------- [continuing his own reply, on Aug 14, 1996 Joe D. added:] Backing up is one problem, restoring NDS is the *really big* problem. Here is my suggestion. Backup all files and everything else you value, and don't hesitate to make screen dumps of user related information. Then call Novell, pay $200, and follow their instructions. It is unwise to add material to a damaged tree, even though such additions typically succeed. I've done this, and had to force matters over the hurtles. But keep in mind that the more data there is the more that can be damaged, the harder it is to restore, and the more work involved when Novell collapses your tree to one server, tries to fix it, and you repartition back the way you were. It's not the data that is the big worry but rather the icky feathers from all the sacrifical chickens Novell uses. DSMAINT is available, as Novell will undoubtedly explain, to capture NDS files at one instant, but it is not a backup/restore method. DS Standard can be very useful, so by all means give it a try (slow with lots of data) as yet another safety net. I've tried most things here with those permanent subordinate references and nothing has succeeded. Novell agrees that the cure is to reinstall from scratch, and I'll do that as soon as the lower parts of my test tree can be moved to other trees. When I do it's bye bye NW 4.10, hello again 4.11. Joe D. ------------------------------ Date: Thu, 15 Aug 1996 12:25:10 -0600 From: Joe Doupnik Subject: Re: NDS Partition that can't be deleted >If you are having the problem I had there is a solution. I had >removed a server without moving the master replica of a partition. >After spending some time making matters even worse, I ended up with >only two subornidate referances to this partition (no master and no >read-write). > >Solution: Convert a subordinate referance to Master replica and >correctly delete the context and partition. This solution will only >work if you want get rid of all contexts in that partition. It >cannot recover any of the objects. > >I thought that this was documented with 41nds5.exe, but I cannot >find the referance. In any case if you feel that your situtation >fits this and feel secure monkeying with your nds in this manner, >then try "load dsrepair -A" Alas, this probably won't work. The change is from Subordinate to Subordinate, meaning nothing happens. Or if one changes the partition to Master and repeats the removal it again becomes Subordinate. The fundamental problem is references may not be deleted unless both ends of the reference cooperate to do so. If the other end, the original material, is absent then no cooperation and no removal. Needless to say, this is a fundamental design item which needs correction and which is reported to be under consideration. Joe D. >Note: Just in case you did not already catch my reservations about >this. This is a last ditch effort to removing a partition that you >can no longer access because you have no replicas of this partition >except subordinate referances. I would only suggest trying this >just before you get to the point of removing and reinstalling NDS on >all servers. If you are at that point there is not much left to hurt. ------------------------------ Date: Fri, 16 Aug 1996 22:40:45 -0400 From: Debbie Becker Subject: Re: 4.1 Server's IRFs >I suppose removing all but S rights from the netadmin OU and servers seems >in order? Also a backdoor account at the top OU level with S rights to >root and Organization (the same setup as the netadmin OU) would be logical? If you want to block the servers, make a user object (or two) Supervisor (object) to the server object and then block all rights except Browse (object) and Red (all properties) in an IRF on the server. In terms of protecting your admin users accounts, in classroom situations I tend to create a backdoor object (AltAdmin). I assign both Admin and AltAdmin *all* object and all properties rights to [Root] and Organization and Organizational Unit objects. I also tend to give them all rights for selected properties to the Object Trustees (ACL) property. I make Admin and AltAdmin trustees of one another and give them *all* rights to one another. I can then place an IRF on each object and block *all* object and property rights -- this makes them "invisible" to all users except one another. I also make each of them Security Equal to one another and to the server object (which will also give them Supervisor file system rights to all volumes on the server!) The administrative user object position in the tree makes no difference, incidentally -- it's the rights that you assign that make the difference. And I would be sure to make the rights assignments to the user objects for the administrators -- not to a container that they all reside in (as I've seen done in the field). After all, what happens if the OU object gets corrupted and loses it's rights? So do all objects in the container! ------------------------------ Date: Fri, 16 Aug 1996 22:40:59 -0400 From: Debbie Becker Subject: Re: Rights in 4.1 >I am in the process of switching over from 3.12 to 4.1. Most of it is working >fine, except that I cannot hide the root directory of users files from the >users. In other words, all users are in a server volume called USERS, with >their login_name as their home folder name. When they log in, I would like F: >to be their home directory. Right now, F: is equal to USERS:home_directory >(example: F:\MKLESSLER). If fact, as a user with no administrative rights I >can see all the other home directories and the directories within them (I use >the terms home folder and home directory interchangeably). I am guessing that >these Read and File Scan rights are inherited, but even if I deny them for an >individual user, that user does not lose them. If they are inherited (from >the organizational unit or the groups to which the user belongs?) how do I >get rid of them? Sounds like an OU or group has the rights and, in that case, the only way to get rid of the user's rights are to either delete the user from the OU/group or change the OU/group's rights to the root of the volume. If they only have R, F rights they were granted in the file system (probably at the root of the volume). Doubleclick on the USERS volume object (to get to the Details) and click on the "Trustees of the Root Directory" to see who is assigned rights here. You only need to worry about rights flowing through from NDS through the server object (and, in that case, the user(s) would have Supervisor file system right without a file system rights assignment at the root of the volume. Check the server object for "Trustees to this object" for info on who may have Supervisor file system right to all volumes on the server (anyone with Supervisor object, or Supervisor or Write All Properties rights). NDS trustees to the volume objects get *no* file system rights, so they're not a concern from that standpoint. I usually assign one or two people as trustees of the server object with the Supervisor object right and then place an IRF on the server blocking all but Browse object and Read All Properties. (Yes, I know some people don't like IRFs - I don't like them in the *file* system and avoid them wherever possible, but I *do* use them in Directory services in a consistent manner -- servers, administrative user objects, etc.) I do agree that you need to use the MAP ROOT command in mapping your users' home directories -- that, in combo with getting rid of the excessive rights, should improve your security considerably. ------------------------------ Date: Mon, 26 Aug 1996 14:07:32 -0400 From: "Brien K. Meehan" Subject: Re: Join state 0 >I have a partition which is in Join State 0. It has been this way >for a few days. I was trying to merge two partitions. I aborted the >process in the child partion but I cannot abort the process for the >parent partition. DSRepair "Cancel partition operation" says the >partition is not busy. I can't perform any other partition >operations or move any objects. I have 41NDS9, 410IT6 and 410PT3 >installed. One server has 410PT6 installed. I've run into a similar problem during a partion merge. All was in sync, DSTRACE showed YES to everything, but the state was stuck. I ran DSREPAIR and repaired the local database on the server that held the [Root], and it said there was one invalid time stamp. I also did the "repair time stamps" thing in replica and partition operations. So, if I were in your shoes, I would: - load dsrepair - advanced options menu - repair local ds database - No, no, no, yes, no, no, no (you'll see) - perform this operation, and look at a DSTRACE to see that it all syncs up. - back at advanced options, replica and partition operations - [Root] - repair time stamps and declare a new epoch You should be 100% comfortable running DSREPAIR if you chose to do this! ------------------------------ Date: Mon, 26 Aug 1996 23:38:26 -0400 From: Debbie Becker Subject: Re: Renaming 4.x server >Several months ago Debbie mentioned the formula for renaming a 4.0 server. > > 1. Load install and edit the server name in autoexec.ncf > 2. Down the server and restart it. > 3. Set dstrace = on > 4. Set dstrace = +limber > >I remember there was a coupld of other steps but I can't remember what they >were. > >Will the volume names in the tree be renamed or does that have to be done >manually. Does DSREPAIR need to be run afte the tree synchronizes. Well, you didn't forget much! Just check to see that the "Limber: start connectivitiy check" and "Limber: end connectivity check" both come out OK. Yeah, it *is* recommended that you run DSREPAIR after the tree synchronizes (give it overnight to make sure --- WAIT, WAIT, WAIT!) and check out any error messages. You *will* have to rename the volumes manually -- it's not done automatically, because, actually, volume object names don't have to be the same as the physical volume names (it just defaults that way when they're created). ------------------------------ Date: Tue, 27 Aug 1996 20:28:48 -0600 From: Joe Doupnik Subject: Re: Using UIMPORT for account >We have upgraded all of our servers this summer from 3.11 to 4.1 and we >are using NDS. > >At the start of each school year, we generate a large number of computer >accounts for all the incoming students and some of the returning students >that did not keep their Novell accounts during the summer. > >We are trying to use the UIMPORT program to install about 2200 new accounts. >On Sunday afternoon when we ran it the first time, it made about 300 accounts >before it brought 3 of our fileservers down. It appears that the NDS >was constantly trying to update itself and just gave up, causing the >3 filesevers to crash. Seems to be a familiar story. One of my NW 4.10 servers (a 486-50) died several times from the same effect when a server/OU lower in the tree was adding thousands of GroupWise accounts. The machine simply could not keep up with network traffic plus the intense NDS internal data shuffling and it ran itself out of memory and then out of business. >Since then we have run the NDS Repair program to fix some problems and updated >the NDS to version 5.1. But we have only been able to run the UIMPORT on I presume you mean DS.NLM v5.01. Values above 5.01 basically belong to the next version of NetWare (Green River), unless Novell has planned a numerical hole for 4.10-specific upgrades. >a small group of names (about 100+) before the servers start crashing again. >Has anyone experienced this problem? Is there a solution or method to >create a large amount of new users (and delete then next summer) without >having the NDS update until after we have completed the import? I think it's inherent in the, ah, er, scheme of things and one of the reasons to partition cleverly. Spoon feeding is the only answer I know of to keep under the 22 minute interval to complete a synchronization cycle, and smaller spoons to help servers survive the cpu crunch of merging database information. Less information about each user is another way of reducing the overall data exchange. I can say that Novell is aware of the database operations problem and is working on solutions. What the solutions will be, and when, I don't know, but database merging is an old old problem with well known techniques (say, indexed files) to keep the complexity from growing geometrically (as it does with our current flat files). Joe D. ------------------------------ Date: Tue, 3 Sep 1996 16:36:09 -0600 From: Joe Doupnik Subject: Re: Re[2]: Subordinate Partitions >>>I have attempted to delete a read/write replica of a partition only >>>to find that its status has been changed to that of a "subordinate >>>partition". >>> >>>I can't find any documentation on deleting a "subordinate partition". >>> >>>How can I delete such a partiton? >> >>You can't. A Subordinate Reference will always exist when you have a copy >>of the parent partition on a server but not a copy of the child partition. >> >>I highly suggest getting and reading the file DSDOC.EXE from Novell. It >>is a complete theory and operations guide to NDS. Everybody that manages >>NW4 servers should read it. > >This may sound strange, but since a subref is only generated where the >parent partition exists, but the child doesn't, then why not put a >replica of the child on the server that has the subref??? That way, >NDS will remove the subref. If you try to manually delete the subref, >you're really asking for trouble! ------------ Alas, it may be too late. The situation has occurred here, twice. I can't recall the details, but the basic idea was to disconnect a server, remove those objects from the other NDS servers and remove the disconnected server object too. Oops, big time, $200 to Novell, do not pass GO, and see indelible subsidary references. The approved method of removing a server is to have it running normally, use NWADMIN/NETADMIN to remove all of its objects, and discover one can't yet remove the server object. Then shut down that server and let the outside remove the server object. The first step disconnects references at both ends, by having each end cooperate with the other. If there is no cooperation then the sub refs don't go away, ever, so it seems. I have been informed by the guy in charge of NDS that there will be a fix for this made available sometime, but no word about when. Finally, when this general subject comes up folks usually don't mention the versions of DS.NLM and DSREPAIR.NLM involved. These turn out to be critical items, and the way to be safest is to load the latest versions from the updates directory on ftp.novell.com and mirrors. Certaintly trust not DS.NLM prior to 4.89, and get up to v5.01 if at all possible. That makes life interesting when NW 4.0x servers are part of the mix since they have earlier versions yet. [Hint, when Green River/NW 4.11 hits the streets you may readily see small NDS problems interoperting between it and what you have now, unless Novell provides updates for the prior versions of NW.] Joe D. ------------------------------ Date: Thu, 5 Sep 1996 11:17:14 -0400 From: Debbie Becker Subject: Re: Subordinate Partitions >>>>I have attempted to delete a read/write replica of a partition only >>>>to find that its status has been changed to that of a "subordinate >>>>partition". How can I delete such a partiton? >> >>Confusion can reign here if we are not careful! >> >>A sub ref is generated on a child partition's server(s) pointing to any other >>server, that contains a copy (master, r/w r/o) of the partition above >>that child partition's. Provided of course, the child server >>doesn't contain a copy of the partition above it. >> >>So the lowest server in the tree can have sub refs pointed at it (not >>on it), if for example, it had a copy of the root partition but not copies >>of partitions imediately below the root. >> >>In answer to the question above "why not put a replica of the child >>on the server that has the subref?" The answer is - The server that >>has the subref, is the child, or in it's partition. Having a >>copy of it's own partion causes it to subref to elsewhere. >> >>Unless you mean why not put a copy of the child on the server that is >>the subject of the subref! Then we go into how many copies of >>partitions are actually needed > >This may sound strange, but since a subref is only generated >where the parent partition exists, but the child doesn't, then >why not put a replica of the child on the server that has the >subref??? That way, NDS will remove the subref. If you try to >manually delete the subref, you're really asking for trouble! Quick notes on Subordinate References: Subordinate References (subrefs) are one of those server-based NDS things. Subrefs exist on servers which contain a replica (Master, Read/Write or Read Only) of a parent partition, but do not contain a replica of the child partition(s). Subrefs act as a pointer to the children ("do you know where your children are?") As an example: [Root] | Intermedia | ------------------------ | | | CORP MIS SALES_ Server CORP_S1 (in the CORP container) contains: R/W of [Root] partition (which includes Intermedia) and Master of CORP container. Since it has a copy of the parent [Root], it will need replicas of all child partitions (CORP, MIS and SALES) or a subref will automatically be created. It has the Master replica for CORP, but is missing any replica for MIS or SALES, so it will have a Subref to each of them. Subrefs *do* generate some network traffic. They are part of the replica ring and anytime replicas are being updated, they get contacted briefly (just to see if they're still out there, apparently!) It *is* important that they be out there, however, as no partitioning operations can be run unless all replicas (even subrefs) are available. You can get rid of subrefs by replacing them with a Read/Write or Master replica of the child partition(s). This, of course, will result in a great deal *more* synchronization traffic as they will be actively involved in sending/receiving changes to the partition. You can also delete the parent partition's replica (unless you really need it). In the example above, deleting the R/W of the [Root] partition would leave CORP_S1 server with Master of CORP partition and nothing else (subrefs disappear). Be cautious about replica placement. You don't want too many of them out there, and you also don't want them across unreliable links (even subrefs) as you may find yourself unable to complete partioning operations if your link is down. ------------------------------ Date: Mon, 9 Sep 1996 18:26:40 -0600 From: Joe Doupnik Subject: Re: Isolated NDS >I am due to set up a 2-user copy of Netware 4.10 in one of our teaching >rooms as a 'distribution server' for Windows 95. We already have one >Netware 4 server and therefore and NDS tree. > >I would like to be able to set the server up and remove it from the tree >without any hassle; although it is possible to isolate the room from the >rest of the LAN, I prefer a software approach. > >Should I create a separate tree, or add the server to the existing tree? >Would it be better creating an organisational unit and simply deleting >that when the server goes back? --------- This is a good spot to clarify the issue, maybe once and for all. The bottom line will be "don't put teaching servers in a production tree." Imagine a play server, a test/teaching machine, in a tree with other production servers. We all do that upon occassion. Everything is working just fine. Now turn off that server and rebuild it from scratch as another name, without taking any action on the main NDS tree. At this point the tree is irreversibly harmed. Why? For two reasons. The first is if the downed server is in a ring of replicas (sharing the same info amongst other servers) then the ring is suspended and all the updates that go with it. One has to work at it to partition off the play server and avoid all replicas from involving it, and that must be done before downing the server. The second reason is there are pointers between that server and the others. One set, called backlinks, point up the tree so one can find the others by going up the tree. A second set, named subsidary references, go down the tree. There are others too, such as aliases. Such pointers must be dissolved by mutual agreement of holders of both ends, and they will NOT be dissolved if either end is not present to agree. They must be dissolved to have a healthy tree. If the pointers are not disolved cleanly, by having all servers operating normally and admin uses nwadmin/netadmin to remove them, then the tree is broken irreversibly (call Novell, pay US$200, worry a lot). It is this circumstance which I keep harping on as being so easy to create and presently impossible to cure ourselves. Dsrepair can NOT fix the pointer situation at this time, but the latest version can remove vanished items from replica rings. Ds.nlm v4.89 that ships with NW 4.10 is buggy and should not be used with production trees; upgrade all servers to v5.01. That is my English language interpretation of affairs. Debbie may wish to amplify and correct. Novell is welcomed to correct me (Hi Dave), and maybe even mention the hope of unilaterally repairing dangling pointers. Jargon-speak renditions are found in Novell documents, without the clarity of knowing the situation or consequences. Thus it is clear that play/teaching servers should be entirely in their own trees and never in production trees. Joe D. --------- Date: Mon, 9 Sep 1996 19:06:01 -0600 From: Joe Doupnik Subject: Re: Isolated NDS Adding one more item to my previous message on not putting test servers in a production NDS tree. I suspect that a large number of sites do not create a secure time structure for NDS time keeping. They probably let servers hear any time statement, and when one is in the future we have a problem Houston (tm). The default TIMESYNC Synchronization Radius is 2E+09 millisec, or 24.85 days. Folks are curious about the year 2000 effect, and we can depend upon at least one person trying it. The gotcha's come from that 24 day window within which synchronization is believed. Other gotcha's may arise from further in the future but I haven't tried that here. A proper NDS time topology has servers listening and believing information from only particular named servers, never from whatever is on the wire. And we all check the Bios time/date when booting a server machine, right? Joe D. ------------------------------ Date: Wed, 11 Sep 1996 16:41:53 -0600 From: Joe Doupnik Subject: Re: Detaching from the tree. We have 50 something Novell 3.11 file servers and three 4.1 servers, running in the NDS mode. How do I take one of them right out of the NDS tree and run them in the bindery mode? I need to create a print queue and a print server in the bindery mode but it won't let me right now because "the file server is not knows to the bindery". ------------ You've grasped the bull by the wrong end. What you want is supporting a bindery level external print box, right? So create a print queue which will be served by than box's name, but do so in bindery emulation mode of Pconsole (see screen bottom, F4 key). In addition, you must have bindery context set on the NW 4 server. Let's try that again. The tiny box (I am presuming) does not speak NDS but it does speak Bindery stuff, and it is behaving as a NW print server. If so it advertizes a name, which you must use when coupling the queue with the external print server via Pconsole. I did all this a few weeks ago for a NW 4.11 server and it works just fine. NW 4 servers will not run without directory services. If you want NW 4 manuals again please visit netlab2.usu.edu, cd epub, or netlab1.usu.edu, cd pub/mirror/epub. Joe D. ------------------------------ Date: Fri, 13 Sep 1996 14:17:46 +0100 From: Richard Letts Subject: Re: Making a group a member of a group >>I have the following groups: >> >>nogroupmail.vb.tcc >>everyone.student1.vb.tcc >> >>When I try to add the groupeveryone.student1.vb.tcc to the group >>nogroupmail.vb.tcc I cannot. >> >>Is there any way to make a group a member of group? > >Groups contain user objects, not other groups. Get a copy of John Bairds >JrbUtils NDS utilities (the registered version) and use GrpAdd >nogroupmail.vb.tcc #everyone.student1.vb.tcc, apart from that, the only way I'm >aware of is to get a list of users in the group and manually add them. Pedantically groups can contain other groups, but as filestore rights (and group membership) is not transitive (if A=B and B=C A!=C) then it has no effect! Similarly a user .joe.finance.salford who is a member of .print-managers.purchasing.salford does not gain the access rights assigned to [the container] .purchasing.salford: user securuty equal to group group security equal to container user NOT security equal to container This is quite nifty if you want a central support group who look after printing and need access to other's printers but don't want them to have implict rights from the other department. if you wanted joe to have rights to everything in .purchasing.salford then you make joe security equal to the container. ------------------------------ Date: Mon, 16 Sep 1996 18:22:24 -0400 From: Debbie Becker Subject: Re: 4.1, move container %/or server to another tree >We have a 4.1 container that includes a server, users, printers, etc. >We are interested in moving this entire container to another tree. > >Does anyone know of a way to move an entire container? >If not, is there at least an easy way to move the server? I don't think that you can move a container and/or server to another tree easily. Looks to me like it's a remove and rebuild operation. Easiest way to remove/move a server: 1) Remove replicas from the server 2) Remove the server from the tree (Partition Manager) 3) Remove Directory services from the server 4) Down server - wait - bring server back up (just a safety measure -- I'm not sure this really *does* anything, but it's always worked for me) 5) Reinstall DS on the server -- install into the "new" tree ------------------------------ Date: Tue, 17 Sep 1996 10:49:14 -0400 From: Debbie Becker Subject: Re: NDS Problem! Urgent! >The following message appeared after to run LOAD DS.NLM > >Directory Services: Could not open local Database, it is inconsistent >Try to correct the error with DSREPAIR.NLM > >After to run DSREPAIR, appeared: > >DSREPAIR-4.10-015: Could not establish full access to record manager > Program execution cannot continue normally > > > >009: Directory Services remains locked, error -618 A -618 error is Inconsistent_Database and indicates that an error has been encountered in the database itself. Usually this means that the number of entries in a container doesn't match the number stored in the container's entry. Run DSREPAIR *ONLY ONCE* (which you've already done). If the error still persists, it probably means a call to Novell. *Don't* run DSREPAIR again (if you haven't already -- can't really tell from the message), as this will overwrite the .OLD files and make it impossible to restore the database. Once this has happened, you may have to remove DS from the server and reinstall it. ------------------------------ Date: Fri, 27 Sep 1996 14:44:28 -0600 From: Joe Doupnik Subject: Re: Netware 4.1 on a 33 MHZ server? >According to a Netware 4.1 book by QUE, it is either not wise or not >possible to install Netware 4.1 on a server with less than a 50 MHz >processor. We only have a 33 MHz processor. Do you know if this might have >been a reason why I had so much difficulty installing 4.1? Or, if it can >be installed what kind of performance hindrances and related problems >might ensue? ----------- You say two different statements are in that book: not wise, and not possible. Perhaps a rereading would indicte the intent of general advice and the reasons why. NW 4.x will run happily on a 386 and up, including lowly 386-16/SX machines. Please do read Novell's docs on the matter. NDS uses lots of cpu cycles in bursts to do its job, and the more cpu power there is then the faster that job gets done. A 486-33 will do the job, since I have such servers. However, one can create such a nightmare of complexity and quantity with NDS that the job becomes very difficult for any machine. The trick is intelligent NDS design, strongly flavored with hands-on experience and a network analyzer (nice but not required). Better reading is Novell's book "Novell's Guide to NetWare 4.1 Networks", Novell Press, written by two members of the NDS "tiger team" (Novell Consulting) who go round designing and fixing trees for big bucks customers. Excellent value for the money, the book that is. Joe D. ------------------------------ Date: Mon, 7 Oct 1996 14:31:59 -0600 From: Joe Doupnik Subject: Re: Continuing saga of NW4.1 server >My plan of attack this morning was similar to what I've done with >NW3.x servers: > >1. install netware under a temporary name >2. restore the files from backup >3. reboot as the old server as of the backup date. > >The only snag: it's not working as expected. I went through the >reinstall of NW4.1, which complained about not having the master >replica for itself. This was Friday evening. This morning I decided >on the temporary name deal & it appeared to work OK, except now I >keep getting a 673 error when I attempt to set up the bindery context >on this server. The documentation-on-CD provides no real ease of >use, but I'm certain I'm just missing something. > >The situation basically is: > >Server: GOLIARD - has the root master partition, and has a read/write >replica for AMHERST. > >Server AMHERST - has it's master partition and a read/write replica >of GOLIARDs - dies on a Thursday afternoon. Appears to be a bad >disk. ------------------ One important key is the existance of a copy of the NDS information for that server is held on others. Use that key. This is operating from memory, so please triplecheck Novells words on the matter. Remove NDS from the troubled server. Then reinstall it into the tree as its old name. Normally at this point there would be a fatal blockage because the magic cookie of this server has been lost and the other servers would declare it to be an imposter. But, things have improved to the point that if you know the password of the admin one level up then you can install the server. This will grab the replica scoop from the good servers and you are on the air. What does not happen is uniting NDS names and NDS object id's. Thus you will have to go back and reassign ownerships to this and that. NW 4.11 is supposed to cure this small problem when using tape backup and restores. Best to restore autoexec.ncf from tape too since it has the proper info about bindery context and so on. What one should not do is get anxious and run dsrepair on the other servers. It won't help and could make matters nearly irreversible. What one must do is upgrade all NW 4.10 server's DS.NLM to v5.01 from the update kit. Joe D. ------------------------------ Date: Tue, 8 Oct 1996 14:39:35 +0200 From: Hans Nellissen Subject: Re: Backuping Up NDS to Floppies >I recall that someone had mentioned there was a utility that was able to >backup nds to floppy . Does anyone else recall what the name of this >utility was ? or Where it is? Look for a zip-file called dsback.zip. My version was from --------- Date: Tue, 8 Oct 1996 08:55:04 -0700 From: Dave Quecke Subject: Re: NOVELL Digest - 7 Oct 1996 to 8 Oct 1996 - Special issue Here's the update to the URL that John Croft passed along. ftp://ftp.rz.fh-hannover.de/mnt1/novell/uti/dsback.exe --------- Date: Wed, 9 Oct 1996 18:19:39 -0400 From: "Martin C. Mueller" Subject: Re: Backuping Up NDS to Floppies >I recall that someone had mentioned there was a utility that was able to >backup nsd to floppy. You could do such a thing by copying sys:\_NETWARE to disk via any server- based shell like jcmd or nwshell. Restoration might succeed iff - there's only one server in the tree - otherwise the synchronization problems will most probably kill you - the backup's not to old (maybe hours) - the file system retained the user id's You can tweak the second point by fumbling the system clock - if that seems wise. After all - there's no such thing as NDS backup to external media up to 4.10 and you have to resort to replication. That will presumably change with 4.11. ------------------------------ Date: Thu, 17 Oct 1996 10:18:18 -0600 From: Joe Doupnik Subject: Re: DS Removal from NDS >Have a server (4.1) that has crashed. It is not the primary server. >How can I get this server out of the nds? --------- It must be done carefully. Rebuild the server and reinstall it into the NDS tree under its usual name. Then follow Novell's instructions to remove the server and contents (Hint: nwadmin, remove all items related to that server WHILE the server is active in the tree, and only then down the server and use nwadmin to remove the server object). Joe D. ------------------------------ Date: Thu, 17 Oct 1996 15:41:49 -0600 From: Joe Doupnik Subject: Re: DS Removal from NDS >>>I have a server (4.1) that has crashed. It is not the primary server. >>>How can I get this server out of the nds? >>--------- >> It must be done carefully. Rebuild the server and reinstall it into >>the NDS tree under its usual name. Then follow Novell's instructions to >>remove the server and contents (Hint: nwadmin, remove all items related to >>that server WHILE the server is active in the tree, and only then down the >>server and use nwadmin to remove the server object). >> Joe D. > >It's occurred to me that the "It must be done carefully" is contrary >to NDS's original design theory. In otherwords, the NDS is >distributed in order to protect itself from a single server crash, >yet a single server crash spells "trouble" for the NDS - due to >replica syncronization. > >Am I missing something here? ---------- No, that's a very reasonable requirement to impose. Alas, things are messier than that due to pointers between components and those replicas living in places where the real objects are not. Replicas are for speed, though until NW 4.11 they were also for safety, and in principle none is required. Without replicas we just have pointers to external things, but those pointers never seem to age away naturally (they hang on for dear life worse than Appletalk routing rumors). In the past there were several fatal "features" of NDS which precluded my recommending it in production mode. One was rebuilding a server from scratch would block that server from reentering the tree under its old name; magic cookies didn't match and the new version was declared to be an imposter. That was fixed by knowing the username of the admin of the next level up. The second was removing a component of the tree without notice left indelible references to it; both ends of a reference need to cooperate to remove the ref, else it stays. As of DS.NLM v5.70 we can now unilaterally remove these strays. The third was inability to safely restore a server from tape. NW 4.11 has finally dealt with that problem in its new TSANDS and TSA410 NLMs. Thus NDS should be viewed as a community affair, where orderly actions are required to avoid over-reactions and misunderstandings. We all need to go to NDS Law School to learn them, and there is plenty to learn. I think it's clear that NW 4.11 is the first "robust" issue of NDS based NetWare. Joe D. ------------------------------ Date: Fri, 18 Oct 1996 17:56:44 -0500 From: rkennedy@EOSINC.COM To: netw4-l@bgu.edu Subject: Re: NDS Syncronization Intervals >>You can find some of this information in "Netware 4 for Professionals", a >>New Rider Publishers book from back in 1993. The ISBN is 1-56205-217-9. >>Also, I found the informatoin provided in the Novell 532 Design and >>Implementation class a real help with some of these type of issues. Hope >>this helps you out. > >I'll check it out. If you receive the Novell Application Notes, or have access to it through Compuserve, there was a series of very good articles on the issues involved. On larger trees with high communications needs, in addition to NDS traffic, Novell actually recommends considering the use of separate trees where possible. Future releases of their NDS management tools will include the ability to manage areas within the same tree as if they are separate trees to reduce synch traffic. I've also seen some information that servers cannot synch over two separate 56K lines -- in other words two servers connected through a central location and on separate 56K lines. Don't forget too of how your time synch can be configured to allow turning off SAPs for time synch. I'm sure Novell has some "white papers" on the subject at their web site or there might be some information at the Netware Connection site: http://www.nwconnection.com Let me know what information you find out as we run a number of 56K lines within a 4.x environment of about 150+ servers and are looking at ways to make the use of the lines more efficient. We have tried to limit server communications through continual review of our partitions, time synch configuration, and some SAP filtering. The communications folk are looking at various switches etc. but I don't know if they have come to any conclusions yet. We are also looking to implement NLSP soon as our routers will now support it. --------- Date: Sat, 19 Oct 1996 11:58:13 +0200 (METDST) From: Jacek Przerwa To: netw4-l@bgu.edu Subject: Re: NDS Syncronization Intervals >I am designing our NDS tree to work well on 56k WAN links. I need to find >out where I can find specific information regarding default NDS >Syncronization Intervals, and modifieable parameters. There are some modules, which help you to filter NDS traffic (it may consume all WAN bandwith, if not properly implemented). You can gather some knowledge from attending courses 532 Design and Implementation (how to design NDS tree to avoid unnecessary WAN traffic) and 740 Internetworking with MultiProtocol Router (how to filter the NDS WAN traffic). You can also download (support.novell.com, if my memory serves me) the NDS documentation-dsdoc.exe file (I am not sure about the name), which covers issues like NDS modifieable parameters. --------- Date: Sun, 20 Oct 1996 00:11:55 -0500 From: rkennedy@EOSINC.COM To: netw4-l@bgu.edu Subject: Re: NDS Syncronization Intervals Sorry to post an update to my own response, but I was finally cleaning up my office and "low and behold" there were the App Notes I referenced. Specifically: "Universal Guidelines for NDS Tree Design" (Novell Application Notes, April 1996) "Ten Proven Techniques for Improving NDS Performance and Reliability" (Novell Application Notes, April 1996) "Managing Novell Directory Services Traffic Across a WAN: Part 1" (Novell Application Notes, June 1996) (I haven't seen part II yet) "A Study of Novell Directory Services Performance and Benefits" (Novell App Notes, July 1996) There was also a supplement to the July App Notes issue from Novell research titled "Connecting the Enterprise: Wide Area Networking Technologies" including articles on Bridging and Routing, Wide Area Networking, ATM and Frame Relay, Remote Office Connectivity, NetWare Link Services Protocol, and VSAT Networks. You can order these as back issues from Novell by calling 800/394-5088 in the US and Canada, or, 801/342-3451 for other locations. The cost is $8 per issue up to 9 copies, then the price reduces depending on the numbers ordered. ------------------------------ Date: Tue, 22 Oct 1996 15:36:28 -0600 From: Joe Doupnik Subject: Re: Renaming Volumes in 4.1 Netware >When dismounting, then renaming a volume in 4.1, should one delete the >old object first from nwadmin or the reverse? ------- The general rule about NDS that I try to follow is: Change things when all holders of the property are communicating because such relationships require all participants to agree. If you just zap the volume name then the other informants are not told, can't come to a unanimous agreement, and you have a broken tree. The only exception, so far, appears to be server objects themselves, where to remove them from the tree the server must be shut down (presumably after removing directory services). Other objects get the full agreement method, via netadmin/nwadmin. Joe D. ------------------------------ Date: Thu, 24 Oct 1996 18:13:09 +0100 From: Richard Letts Subject: Re: Client for 4.11? Joe Doupnik wrote.... > Client32 is needed to run ndsmgr (aka: partmgr in GUI clothing) and >nwadmn95 (public\win95, slicker nwadmin), and nwadmn3x (public). Nwadmin is >still present (public) as before. The Client32 material on the NW 4.11 CDROM >is not required per se. However I will say that the partition continuity check under ndsmgr you get a very nice display of servers vs. partitions with icons denoting the state and little warning tri-angles if there is a problem. clicking on the ico brings up a dialog box with the last DS error in it, and a questionmark icon next to it. clicking the questionmark gives you a clear description of the error, and what you need to do to fix it. Now, if it could produce this for the whole tree.... PS. You don't need a 4.11 server in the tree for this stuff, just the latest and greatest DS.NLM on the servers and client32 on the workstations ------------------------------ Date: Sat, 26 Oct 1996 12:11:36 -0400 From: Debbie Becker Subject: Re: NDS 4.1 / Login to another container >Surely someone has done this, but I can't figure it out. > >I have Netware 4.1 on multiple servers in different cities. >I have a frame relay WAN. > >I have some users who need to travel to one of my branch >offices, and login on that server's network. I have been >asssuming I should handle that with a User Alias object >in NDS. But I can't get the User Alias to run the container >login script that resides in the other city. I've always thought that Novell made that sound entirely too easy to do! The fact is that the alias user login will point back to the original user and run the original user container login script. It *will not* run the alias container login script unless you use some variables to point it to the right place. It's probably easiest to put your alias users into groups and then use IF..THEN statements in your original user container login script(s) along the lines of: IF MEMBER OF "ALIAS_USERS" THEN INCLUDE %REQUESTER_CONTEXT EXIT END Double-check me on the variable -- but I think that's the right on off the top of my head! ------------------------------ Date: Mon, 28 Oct 1996 11:52:44 +0000 From: Richard Klemme Subject: Mixing 4.10 & 4.11 >Q2: If so, are there (and would it be possible and wise to use them) >superior NDS management tools on that 4.11 server, to sort out a >problem on my tree (illegal and hidden object, prevents me from >replicating one of the partitions). There is a great utility we bought called Bindview EMS which runs under Windows and does this sort of analysis for invisible objects and other reports such as server info, secuity checks including password analysis, etc. It is pricey though, but worth it. It is licensed by tree, then by # of user objects and by # of servers. There is the 4.x module out now, with 3.x and NT to follow. We got it (one reason) as there was no equivalent for SECURITY.EXE on 4.x (but this does heaps more) when we upgraded from 3.11. There is info on http://www.bindview.com/ Also I recall there was utility may also do this on the Novell Consulting Services (NCS) home page, which has heaps of other goodies. Its at http://www.novell.com/corp/programs/ncs/ under the toolkit section.. I would highly recommend this page!! ------------------------------