There is no need for tuning eDirectory. Period. You can tune your hardware (e.g. get better disk io, more ram, etc), but thats it - eDirectory just runs, tunes itself, stays consistent.
eDirectory (formerly known as NDS) is an X.500 compliant Directory Service and implements its own DAP (Directory Access Protocol) on top of NCP. As no one cares about X.500 or DAP today, you will probably want to use LDAP to access it. NLDAP is the LDAP server of eDirectory.
User Password handling is very different from other implementations.
By default, userPassword gets mapped to a public/private key pair - and is therefore never stored in plain text. This makes it almost impossible to migrate away from eDirectory and keeping the user passwords.
Also, newer versions of NDS support multiple authentication mechanisms (keyword: NMAS), so you should look into them.
If you are running anything below NDS version 8.6, upgrade now. Mixing 7.x or earlier, 8.0, 8.5+ is *NOT* a good idea (altough it should work if your Master replica is 8.5).
As mentioned above, you usually dont tune eDirectory - there is no need to. Cache sizes etc. will depend on your tree size and get set automatically. It's easy to outperform OpenLDAP on the same hardware with a big directory tree.
Replication relies on a working time synchronization, so if you have problems with replication, check timesync/ntp. eDirectory can support read-only slaves, but there is no point of doing it (every login/connect will write back to the user object, so this only creates load). Better have read/write replicas everywhere - maybe filtered (not recommended if you dont know what you are doing).
NDS has a nice Web Tool, called iMonitor. Go use it. You can access logging, debug stuff, etc. using iMonitor or the DSTRACE command line tool (on NetWare: SET DSTRACE=ON, on other opsys: run (n)dstrace). DSTRACE understands lots of different flags. Of interest will usually be +LDAP and some of the default flags. Use +SYNC if you are checking Replication problems and pay attention to the time vectors.
You can fix lots of problems by just running dsrepair in automatic mode.
dsrepair knows of some command line parameters named like -XK3, -XK4 etc. DO NOT USE THEM. They are dangerous and will cause data loss. Still they are sometimes useful, but then you a) need a backup, b) need a backup of all your replicas, c) know what you are doing.
Don't delete the Admin object (really: don't delete the last Admin object). If you do, you cannot restore it. Novell Technical Support can under some circumstances. If you have a NetWare server in your tree, you are lucky and won't need NTS: there are some NLMs floating around which can re-create an Admin object. Some of them are payware, some are free. You could ask User:Ch in this situation and he may dig out some self-written stuff for you.
Specialities on NetWare
NDS was (and still is) the Directory Service for NetWare. This creates a few specialities you should know;
- Once NDS is running, you cannot unload DS.NLM any more, but have to reboot. Starting without NDS is possible by adding -NDB to the server command line.
- The DS database files are located in SYS:_NETWARE, which you cannot access using NCP (from a client machine or an NCP client on the server). NLMs which dont use the redirector (= dont log in), can access this directory. Toolbox can, if you specify /nl (= no login).