Finally removed the last 2 Netware based OES servers from our network …
one fileserver thats been with us since the 1990’s and always had its
‘soul’ transferred to new hardware over the years without complaining…
the other a server that we just still had running because it could make
backups of the other Netware server.
Spent the 1st 30 minutes after downing the last one glaring at ndstrace
and the help-desk phone lines half expecting the whole network to
collapse but things seem to hold… Now the waiting starts to see which
obscure app was using that old server for ldap services or forgotten
workstation with
important-program-X-that-is-only-used-once-a-year-yet-only-launched-5-minutes-before-a-deadline
that is still using the dscat that was running on there as well.
But its still the end of an era for us, now to see how OES2/11 holds up
without Netware holding its hand
Lots of cleanup to do as well with old eDir objects that nobody knew
what they were for so they were just left there over the years in fear
of breaking something random. Radius profiles, NW5.0 license files etc
etc.
now to see how OES2/11 holds up
without Netware holding its hand[/color]
I’d be interested to hear your experience after you’ve been running
that way for a while. There are quite a few others here in the same
boat that more than likely have advice etc…but you’ll probably find
most of them in the OES forums
Well, few hours after downing the file server stuff started breaking …
We have an app that has a unc link somewhere to the old server and
nobody knows how to find it yet, next to that a lot of office files are
giving problems because they are trying to find old templates that no
longer exist on the server that is not around any more.
Other then that things are going ok, we already had a SLES server as
our master eDir replica and CA.
jamesgosling sounds like they ‘said’:
[color=blue]
eDirectory runs like a dream on SLES! DSREPAIRS on warp drive![/color]
So my response to jamesgosling’s comment is…
Usually, but I had a major issue that started last friday evening. One
oes11 server had ndsd core, apparently there were db block issues in
nds.db that caused the core. after which ndsd would not start.
Had a second server do the same thing over the weekend. Spent 20ish
hours on the phone w/ NTS to get things running properly again, had
major tree & schema damage from this…
Oh I don’t doubt you Stevo, I’ve just not seen it before that’s all.
Last deployment I saw was in a large environment (40-60,000 users). When
we moved eDirectory over to SLES the performance went through the roof,
really knocked our socks off!
jamesgosling sounds like they ‘said’:
[color=blue]
Oh I don’t doubt you Stevo, I’ve just not seen it before that’s all.
Last deployment I saw was in a large environment (40-60,000 users).
When we moved eDirectory over to SLES the performance went through
the roof, really knocked our socks off![/color]
So my response to jamesgosling’s comment is…
I’m not saying it doesn’t run great, we just had a weird hiccup. I’m
just hoping that’s not the last straw. My boss is in a mood lately,
and anything that doesn’t perform (basically the way things do on
commercials) could be going out the window.
Douglas Black sounds like they ‘said’:
[color=blue]
What does that leave? A roomful of people with abacuses?[/color]
So my response to Douglas’s comment is…
I don’t know. I’m a little concerned. Someone said they thought they
heard him say (when he stopped in here for a minute the other day and
our edir was in a funk) “Well this might be the straw that broke the
camel’s back”.
If he decides to ditch Novell for ms, I might just be looking for a job.
If he decides to ditch Novell for ms, I might just be looking for a job.
[/color]
Hey, managing a Microsoft environment is job security if nothing else.
All you have to do is learn how to say “Windows really is an
enterprise-level OS” with a straight face.
Douglas Black sounds like they ‘said’:
[color=blue]
Hey, managing a Microsoft environment is job security if nothing
else. All you have to do is learn how to say “Windows really is an
enterprise-level OS” with a straight face.[/color]
So my response to Douglas’s comment is…
I just don’t think I can do that, definitely not with a straight face
Yes had also such a disaster with a DSfW server some time ago. In my
opinion Novell has forgotten to think on proper disaster recovery
procedures in all of its lastest products - maybe except groupwise.
This issue can occur and it could be cured easily, if Novell would - in
the case of a corrupt dib - just allow the ndsd to startup without dib
and automatically recreate the dib from the still intact replicas on
the other servers. But that option is not even available. In former
times of old Netware (like 4.x) you could just remove edir and
afterwards readd it, but that’s getting you directly into full disaster
on an OES Linux box.
W. Prindl
Stevo wrote:
[color=blue]
jamesgosling sounds like they ‘said’:
[color=green]
eDirectory runs like a dream on SLES! DSREPAIRS on warp drive![/color]
So my response to jamesgosling’s comment is…
Usually, but I had a major issue that started last friday evening.
One oes11 server had ndsd core, apparently there were db block issues
in nds.db that caused the core. after which ndsd would not start.
Had a second server do the same thing over the weekend. Spent 20ish
hours on the phone w/ NTS to get things running properly again, had
major tree & schema damage from this…[/color]
Yes had also such a disaster with a DSfW server some time ago. In my
opinion Novell has forgotten to think on proper disaster recovery
procedures in all of its lastest products - maybe except groupwise.
This issue can occur and it could be cured easily, if Novell would - in
the case of a corrupt dib - just allow the ndsd to startup without dib
and automatically recreate the dib from the still intact replicas on
the other servers. But that option is not even available. In former
times of old Netware (like 4.x) you could just remove edir and
afterwards readd it, but that’s getting you directly into full disaster
on an OES Linux box.[/color]
I have removed the directory off OES-Linux and reinstalled into the
directory with out issues. The most important thing is that the directory is
sync’d and time is in sync on all the servers. It was removed and put back
in the directory in about 15 minutes normally.
That almost sounds like data corruption caused by faulty SAN
communication ?
Any idea what caused either problem ?
I always try to read up on disasters other people are having so if it
happens to me I might recognize it sooner and hopefully have a few
things to try and fix it, so far that’s worked pretty well
Although I’ve been very lucky disaster wise (knock on wood!)… I almost lost our entire DS once because DirXML wanted to delete
everything when I wanted to start over and deleted all the AD objects …
lucky me it first deleted the account it was logged in with itself…
When I started working the eDir was in shambles pretty much … tons of
sync problems and server lockups because of 1 specific server … and
then the NCE (or A … I forgot) left … I did some terrible things to
our DS from TID’s that had big letters saying ‘DO NOT DO THIS WITHOUT
NTS TELLING YOU TO’ like destroying replicas and I have no idea what
else … But eventually I managed to straighten everything out and we got
rid of the bad server. When adding an identically named server back into
the tree like a year later there was an immediate excess of red text in
ndstrace … since then we blacklisted the name
All my other problems were either caused by broken service packs,
BackupExec(when Symantec took it over) or hardware failures.
W_Prindl;2215831 Wrote:[color=blue]
Yes had also such a disaster with a DSfW server some time ago. In my
opinion Novell has forgotten to think on proper disaster recovery
procedures in all of its lastest products - maybe except groupwise.
This issue can occur and it could be cured easily, if Novell would -
in
the case of a corrupt dib - just allow the ndsd to startup without dib
and automatically recreate the dib from the still intact replicas on
the other servers. But that option is not even available. In former
times of old Netware (like 4.x) you could just remove edir and
afterwards readd it, but that’s getting you directly into full
disaster
on an OES Linux box.
W. Prindl
Stevo wrote:
[color=green]
jamesgosling sounds like they ‘said’:
[color=darkred]
eDirectory runs like a dream on SLES! DSREPAIRS on warp drive![/color]
So my response to jamesgosling’s comment is…
Usually, but I had a major issue that started last friday evening.
One oes11 server had ndsd core, apparently there were db block issues
in nds.db that caused the core. after which ndsd would not start.
Had a second server do the same thing over the weekend. Spent 20ish
hours on the phone w/ NTS to get things running properly again, had
major tree & schema damage from this…[/color][/color]
