🚀 go-pugleaf

Couldn't have said it better myself :)   Novell also has a good TID on
checking DS heath.   Don't have the number at my fingertips though.

Shaun Norris
Ottawa, ON, Canada


Andy Konecny wrote:

> In article <37A11E99.83A52DD4@bigfoot.com>, Akira wrote:
> > BTW, how would you check to see if DS is stable?
> >
> 1) make sure the timezone information is correct,  it is set in the
> Autoexec.ncf
> making sure the clients also have the right setting is important too.
>
> 2) make sure time is in sync
> Time    for the local condition
> Load DSRepair,  "time synchronization"  will check with all the servers
> this server talks with.  If you have problems with time sync then you
> WILL have problems with DS
>
> 3) check health of local DS replicas
> Load DSRepair
>   Unattended repair,
>    if errors run again,  if still errors, look into them and fix
>
> 4) check flow of DS traffic
> Set DSTrace=ON
> Set DSTrace=*H
> switch(Alt-Esc) to the DSTrace screen and watch for a bit,
>    "All Processed=Yes"  is what you want to see
>    if you see any "All Processed=No" (will be in red) then get to the
> root of it
>
> A general rule is that you don't want to make notable time changes or
> structural DS changes when there are DS errors happening (unless it is
> to fix the problems)
>
> one way to keep time accurate is to use RDATE.nlm if your server can
> see the InterNet.  RDate should be in most of the NetWare tools
> collections out there.  NetWare5's TimeSync has this functionality
> built in to it now, but only via TCP while RDate can us UDP which helps
> transversing firewalls.
>
> Andy Konecny
> Ainsworth, Communication Services
> in Toronto, Canada