[prev in list] [next in list] [prev in thread] [next in thread]
List: novell
Subject: NOVELL Digest - 17 Aug 2002 - Special issue (#2002-349)
From: Automatic digest processor <LISTSERV () LSV ! SYR ! EDU>
Date: 2002-08-17 21:26:11
[Download RAW message or body]
There is one message totalling 1351 lines in this issue.
Topics in this special issue:
1. Unsubscribe
The NOVELL list is hosted by L-Soft international's LISTSERV(TM) software
at Syracuse University. To unsubscribe, send a SIGNOFF NOVELL command
to LISTSERV@LSV.SYR.EDU. If you have questions about the list, write
to NOVELL-REQUEST@LSV.SYR.EDU.
----------------------------------------------------------------------
Date: Sat, 17 Aug 2002 23:15:19 +0200
From: Janita Ras <janita@ADEPT.CO.ZA>
Subject: Unsubscribe
Janita Ras
Service Delivery Manager - Infrastructure
Sasol Oil, SMX and Agri.
All remote sites for South Africa.
janita@adept.co.za
082 498 8258
-----Original Message-----
From: Novell LAN Interest Group [mailto:NOVELL@LSV.SYR.EDU] On Behalf Of
Automatic digest processor
Sent: 17 August 2002 06:53
To: Recipients of NOVELL digests
Subject: NOVELL Digest - 16 Aug 2002 to 17 Aug 2002 - Special issue
(#2002-348)
There are 4 messages totalling 1309 lines in this issue.
Topics in this special issue:
1. JRBImport - I am so screwed!
2. JRBImport - I am so screwed! (An idiot too...)
3. NT Domains are there but aren't...
4. NOVELL Digest - 15 Aug 2002 to 16 Aug 2002 - Special issue
(#2002-346)
The NOVELL list is hosted by L-Soft international's LISTSERV(TM)
software
at Syracuse University. To unsubscribe, send a SIGNOFF NOVELL command
to LISTSERV@LSV.SYR.EDU. If you have questions about the list, write
to NOVELL-REQUEST@LSV.SYR.EDU.
----------------------------------------------------------------------
Date: Sat, 17 Aug 2002 07:49:03 -0500
From: Matthew Jeppsen <mjeppsen@TIGER.NWSC.K12.AR.US>
Subject: JRBImport - I am so screwed!
In the middle of the summer I ordered jrbimprt online. I got an e-mail
with an attached zip file (JRB800A.ZIP), and filed it away for when it
came time to create student user accounts. I just opened the zip file to
find that it DOES NOT CONTAIN jrbimprt.
My eval copy has also expired. School starts Monday.
I am about to try, but I don't have high hopes about contacting JRB
Software before Monday.
Could someone e-mail me a copy of jrbimprt? If there is any question as
to my honesty, I can fax you a copy of the purchase order, as well as
the paid invoice to JRB.
Matt Jeppsen
Technology Coordinator
Prairie Grove School District
Office: 479-846-4264
Cell: 479-790-1549
-----------------------------
Date: Sat, 17 Aug 2002 07:55:06 -0500
From: Matthew Jeppsen <mjeppsen@TIGER.NWSC.K12.AR.US>
Subject: Re: JRBImport - I am so screwed! (An idiot too...)
False alarm, never mind, sorry for the bandwidth waste. I just found the
correct zip file.
Ghod, I never thought I'd be that close to heart failure...
Matt Jeppsen
Technology Coordinator
Prairie Grove School District
-----Original Message-----
From: Matthew Jeppsen [mailto:mjeppsen@tiger.nwsc.k12.ar.us]
Sent: Saturday, August 17, 2002 7:49 AM
To: 'Novell LAN Interest Group'
Subject: JRBImport - I am so screwed!
In the middle of the summer I ordered jrbimprt online. I got an e-mail
with an attached zip file (JRB800A.ZIP), and filed it away for when it
came time to create student user accounts. I just opened the zip file to
find that it DOES NOT CONTAIN jrbimprt.
My eval copy has also expired. School starts Monday.
I am about to try, but I don't have high hopes about contacting JRB
Software before Monday.
Could someone e-mail me a copy of jrbimprt? If there is any question as
to my honesty, I can fax you a copy of the purchase order, as well as
the paid invoice to JRB.
Matt Jeppsen
Technology Coordinator
Prairie Grove School District
Office: 479-846-4264
Cell: 479-790-1549
-----------------------------
Date: Sat, 17 Aug 2002 11:26:35 -0500
From: Rich Molettiere <rmoletti@OPS.ORG>
Subject: NT Domains are there but aren't...
Windows2000 with 4.83 SP1, MS Client active and the workstation is a member of the \
local domain NORTH. We access NT4-based apps in the SASI domain housed at our \
district office.
Browsing My Network Places sometimes displays only the NORTH domain; others all the \
NT domains in the district. A ZEN app object that points to the NT-based app will \
sometimes work or will fail with "access denied." However, on the failure, \
"sometimes" you can browse to the app and launch it OR doing a START:RUN and then \
\\sasi332\ (the domain server on which the NT app resides) will open the sasi332 \
desktop and you can then browse by opening the folders. Eventually, you can launch \
the app.
The problem is the inconsistency - the district support folks are
talking about some sort of conflict with Windows95 desktops (we still have a
few) and/or IP protocal preferences on the desktop or ???
Does this make sense to anyone because it doesn't to me.
-----------------------------
Date: Sat, 17 Aug 2002 11:41:55 -0500
From: Chad Brown <cbrown@KFCU.ORG>
Subject: Re: NOVELL Digest - 15 Aug 2002 to 16 Aug 2002 - Special issue
(#2002-346)
Before we made a novell 4.2 SP9 nds and all volumes migration on an
isolated switch, SP2 was removed from our novell 6 server because of
tsaproxy.nlm and unload nuwagent.nlm errors. The novell 6 migration
wizard apparently is not compliant with SP2 yet after checking these
errors.
How did I remove SP2, we completely reloaded novell 6 and only added
SP1; really need to hear good words about SP2 before going to SP2.
Chad
-----Original Message-----
From: Novell LAN Interest Group [mailto:NOVELL@LSV.SYR.EDU] On Behalf Of
Automatic digest processor
Sent: Friday, August 16, 2002 12:02 PM
To: Recipients of NOVELL digests
Subject: NOVELL Digest - 15 Aug 2002 to 16 Aug 2002 - Special issue
(#2002-346)
There are 21 messages totalling 1055 lines in this issue.
Topics in this special issue:
1. NW6 SP2 (4)
2. JRB Utilities (3)
3. Unsubscribe
4. Insights on Service Location Protocol (3)
5. Oops...sorry for the bandwidth waster. :)
6. Xeon 2.2 GHz procs (2)
7. IPX Ping
8. TCP/IP communicaion problems... (2)
9. Win2K, ZfD 3.2 and context-less login (2)
10. Intel 100 Pro Cards (Was Xeon 2.2 GHz procs) (2)
The NOVELL list is hosted by L-Soft international's LISTSERV(TM)
software
at Syracuse University. To unsubscribe, send a SIGNOFF NOVELL command
to LISTSERV@LSV.SYR.EDU. If you have questions about the list, write
to NOVELL-REQUEST@LSV.SYR.EDU.
----------------------------------------------------------------------
Date: Fri, 16 Aug 2002 07:54:40 -0500
From: lindblom@MICO.COM
Subject: NW6 SP2
The question has been asked when SP2 became available by someone on the
list but I would like to ask again, is SP2 ready for prime time? I will
be
doing a migration this weekend and I'm considering SP2 but have not
heard
much about it.
John
-----------------------------
Date: Fri, 16 Aug 2002 09:02:46 -0400
From: John Navarro <john_navarro@BUSINESSWEEK.COM>
Subject: Re: NW6 SP2
I have installed it on two boxes and haven't seen any problems thus far.
lindblom@MICO.COM wrote:
> The question has been asked when SP2 became available by someone on the
> list but I would like to ask again, is SP2 ready for prime time? I will
be
> doing a migration this weekend and I'm considering SP2 but have not
heard
> much about it.
>
> John
>
>
-----------------------------
Date: Fri, 16 Aug 2002 08:16:29 -0500
From: Dave Moon <dmoon@PERU.K12.IN.US>
Subject: JRB Utilities
I have the boss talked into buying the import program but need a website
and address to contact for it.
Dave Moon
Peru Community Schools
-----------------------------
Date: Fri, 16 Aug 2002 08:15:29 -0500
From: Patrick Sullivan <psullivan@EXECINC.COM>
Subject: Unsubscribe
Please unsubribe me from this list.
Thanks.
-----------------------------
Date: Fri, 16 Aug 2002 09:34:19 -0400
From: John Navarro <john_navarro@BUSINESSWEEK.COM>
Subject: Re: JRB Utilities
www.jrbsoftware.com
Dave Moon wrote:
> I have the boss talked into buying the import program but need a
website and address to contact for it.
>
>
>
> Dave Moon
> Peru Community Schools
>
>
-----------------------------
Date: Fri, 16 Aug 2002 14:45:29 +0100
From: Tim Heywood <tch@IQX.CO.UK>
Subject: Re: NW6 SP2
Both here and on the Main forums the response hase been very good. So
far I have seen nothing that was a showstopper. Most of the problems
have come where people failed to check all was well before they applied
the SP.
Tim
*************************
Tim Heywood
Scotland
(God's Country)
Novell Support Connection Sysop
*************************
-----------------------------
Date: Fri, 16 Aug 2002 09:49:06 -0400
From: John Hanna <John@COASTAL.EDU>
Subject: Re: JRB Utilities
http://www.jrbsoftware.com It works a LOT!!!! better than uimport.
> -----Original Message-----
> From: Novell LAN Interest Group [mailto:NOVELL@LSV.SYR.EDU]On Behalf Of
> Dave Moon
> Sent: Friday, August 16, 2002 9:16 AM
> To: NOVELL@LSV.SYR.EDU
> Subject: JRB Utilities
>
>
> I have the boss talked into buying the import program but need a
> website and address to contact for it.
>
>
>
> Dave Moon
> Peru Community Schools
>
>
-----------------------------
Date: Fri, 16 Aug 2002 10:24:16 -0400
From: Marc Gosselin <MGosselin@PIERCELAW.EDU>
Subject: Re: NW6 SP2
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
I've installed it on 6 and had a problem only on the first one. When I
rebooted it would not come up correctly. I emailed this list with the
problem, got a couple of answers (the same I might add) and that
resolved the issue. All is well. They've been running since Wednesday
with no issues. Not long but usually problems come up right away.
Marc
>>> john_navarro@BUSINESSWEEK.COM 08/16/02 09:02AM >>>
I have installed it on two boxes and haven't seen any problems thus
far.
lindblom@MICO.COM wrote:
>The question has been asked when SP2 became available by someone on
the
>list but I would like to ask again, is SP2 ready for prime time? I
will be
>doing a migration this weekend and I'm considering SP2 but have not
heard
>much about it.
>
>John
>
>
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2716.2200" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 8pt Tahoma; MARGIN-LEFT: 2px">
<DIV><FONT size=2>I've installed it on 6 and had a problem only on the
first
one. When I rebooted it would not come up correctly. I emailed this list
with
the problem, got a couple of answers (the same I might add) and that
resolved
the issue. All is well. They've been running since Wednesday with no
issues. Not
long but usually problems come up right away.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Marc</FONT></DIV>
<DIV><BR><BR>>>> john_navarro@BUSINESSWEEK.COM 08/16/02 09:02AM
>>><BR>I have installed it on two boxes and haven't seen any
problems
thus far.<BR><BR>lindblom@MICO.COM wrote:<BR><BR>>The question has
been asked
when SP2 became available by someone on the<BR>>list but I would like
to ask
again, is SP2 ready for prime time? I will be<BR>>doing a migration
this
weekend and I'm considering SP2 but have not heard<BR>>much about
it.<BR>><BR>>John<BR>><BR>><BR></DIV></BODY></HTML>
-----------------------------
Date: Fri, 16 Aug 2002 09:39:08 -0500
From: David Reagan <dreagan@COMMANCHE.SWMED.EDU>
Subject: Re: Insights on Service Location Protocol
Good information Joe!
Speaking of IP connectivity, I am curious if anyone out there has tried
using dns entries for the servers to allow clients to get where they
needed
to in the event their clients are not configured to SLP or their
attempts to
reach a agent fail, i.e. the broadcasts do not cross segments.
Especially
since the client will automatically try a dns search as well as slp...
I do like your idea of a DA on each server. We have a single DA that
all
servers are configured to talk to, but have considered the advantages of
a
DA at each for the reasons that you give.
Thanks again for the detailed info, as always most appreciated to hear
someone else's perspective on things such as this. Especially given the
confusion that many folks have with IP/SLP after years of good old
broadcast-based IPX.
David Reagan
dreagan@commanche.swmed.edu
UT Southwestern Medical Center at Dallas
-----Original Message-----
From: Novell LAN Interest Group [mailto:NOVELL@LSV.SYR.EDU]On Behalf Of
Joe Doupnik
Sent: Thursday, August 15, 2002 3:56 PM
To: NOVELL@LSV.SYR.EDU
Subject: Insights on Service Location Protocol
While talking with many managers about SLP it seems that a fair
amount of doubt and confusion exists about deploying SLP with NW
servers.
This note is a very brief discussion of how to succeed with SLP,
omitting
all the neat technical inner workings and even some manager details.
SLP has three major components: Service Agents, Directory
Agents,
and User Agents, all bits of software. SLP comes in versions 1 (NW prior
to v6) and version 2. SLP version is important to note.
Let's summarize SLP v1 versus v2 effects first. Version 1 had a
default Scope of an empty string, nicnamed "unscoped." It accepted
formal
strings too. Version 2 uses only formal strings, the default Scope
spelling
being "DEFAULT." In both versions a DA will periodically advertise for
SAs to come and register. In version 2 SAs can advertise for DAs, in
version
1 then cannot. Adverts are multi/broadcasts, and are thus very limited
in
range (often to the nearest router). A version 1 DA will collect data
from
every Scope; a version 2 DA collects from only its named Scope(s).
User Agents either query DAs or advertise for SAs. They may
advertise
for DAs too if none is known.
DAs do not talk to other DAs. Same with SAs and UAs. UAs can
talk
to SAs and DAs, SAs talk to DAs and respond to UAs. DAs are aloof.
SLP data is held in two databases on a NW server. One is in
cache
memory and the other is in an SLP NDS container which is tied to a given
Scoep. That container is normally in the same NDS context as the server
object which hosts the DA. The container is serviced only by DAs. More
on
this important point in a minute.
A server with no DA (SLPDA is not loaded) will let its SAs roam
about finding other DAs, if possible. We can control this behavior
through
Monitor, Server parameters, SLP section, "SLP DA discovery options".
That
item does not mean what it says; it means how the server's SAs can
discover
DAs, it does not control DAs. There is more to this item but I will skip
it
for now. Try setting of 7.
If a server has a DA loaded then its SAs are compelled to
register
with that DA, no matter what else we say about configuration. File
etc\slp.cfg
does not override this self-registration effect.
UAs find DAs (or SAs) by either dynamic multi/broadcast or by
static
routes. Same for SAs discovering DAs. Dynamic discovery is bad news, and
the
receiver is unware of its goodness or not; so avoid this technique. In
any
case, many sites kill broadcast and multicast traffic at routers, and
that
remains good advice. So, we have a discovery aspect to consider.
Dymamic discovery fails more often that it succeeds and is thus
unsuitable for robust work. Static routes are better. We may create them
manually (in the client or in etc\slp.cfg) or have clients use DHCP to
acquire only NDS and SLP information. Putting a DHCP server on a NW
server
and having it hand out only NDS and SLP data, not assign IP addresses,
is
a good idea.
Here is the next bit. By default DAs store dat in their own NDS
container. Several DAs using the same Scope but different containers do
not share data. We can get SA data into each by forcing each SA to
register
with each DA. You can quickly imagine what that fully meshed network
approach does: what a beast to maintain, not to mention the traffic.
Each
to each, a classical N by N problem.
The better design is to force each DA to keep its data in a
common
pool, meaning in the same NDS container as used by other DAs. Use
ConsoleOne
to configure a DA this way, the SLPDA object.
Don't configure SAs. Ignore etc\slp.cfg. Put a DA on every
server.
That forces each SA to register with its own DA, an internal operation,
and
none other. DAs then pool that information into one NDS spot. A user
making
a query then has available for answers all the information of that
Scope,
not just the piece which a particular DA hears from the wire via SLP
packets.
That fully meshed network disappears, and what remains is normal NDS
sync
traffic between servers. Some DA adverts will occur, but Monitor, ...SLP
can be used to turn them off.
SLP v1 and v2 systems can be joined only if the same Scope name
is
used. Pour all data into that single NDS container and DAs of both
versions
can respond.
Back to Monitor and how SAs discover things. Please read the
gibberish
on command SLP DA Discovery Options. It really says if a static
assignment
is given then don't use dynamic (multi/broadcast). Simply having SLPDA
loaded
on that server is a static assignmemt. Any value other than 1 means
static
overrides dynamic abilities. Denying dynamic also means the server will
not
pick up stray trash from the dirty network streets and think it good.
Where are we? Use one NDS container for an SLP Scope. Load DAs
on
each server (rather like a cell phone tower), don't use dynamic DA
discovery,
don't use slp.cfg, offer DHCP support to clients, use name-ful Scopes.
The
SLP container may be partitioned and replicated independent of the main
body
of NDS materail. This is the desired single-tree solution.
SLP is ignorant of NDS and trees. NW's storage of SLP data is
tied
to
NDS. How can we get SLP information spread across more than one tree?
Only by having each interesting SA be forced to register with
another
DA in another tree. We must use etc\slp.cfg for this, and we need not
add
our
own server to that list because the matter is forced by SLPDA anyway.
Once
an
SA's data is known to another tree then pooling will spread the word all
over
the other tree; only one linkage per SA is needed. Best to think hard
about
whether such cross tree registrations are really necessary.
That's a summary. Give it some thought.
Joe D.
-----------------------------
Date: Fri, 16 Aug 2002 09:41:34 -0500
From: David Reagan <dreagan@COMMANCHE.SWMED.EDU>
Subject: Oops...sorry for the bandwidth waster. :)
My apologies to all for sending a reply along with Joe's entire post...
A bit too quick on the send button these days. :)
David Reagan
-----------------------------
Date: Fri, 16 Aug 2002 10:53:02 -0400
From: "Walters, Rob" <RWalters@COMPBENEFITS.COM>
Subject: Re: Xeon 2.2 GHz procs
VGFraW5nIHRoZSBmb3JrIGluIHRoZSByb2FkIHRoYXQgeW91IHB1dCB0aGVyZS4uLg0KDQpJ
IGhh
dmUgc2VlbiBhIHNpbWlsYXIgcHJvYmxlbSB0byB5b3Vycy4uLnRoZSBzZXJ2ZXIgc2l0cyB0
aGVy
ZSBhbGwgcHJldHR5LWxpa2UsIGJ1dCBub2JvZHkgY2FuIHRhbGsgdG8gaXQuICBBdCBmaXJz
dCBJ
IHN1c3BlY3RlZCB0aGF0IGl0IG1heSBiZSBzb21ldGhpbmcgcmVsYXRlZCB0byB0aGUgRGVs
bCBo
YXJkd2FyZSwgYnV0IHRoZW4gSSByZWFsaXplZCB0aGF0IEkgaGF2ZSBhIENvbXBhcSBzZXJ2
ZXIg
dGhhdCBvdXIgUEMgZ3V5cyB1c2UgdG8gc3RvcmUgYWxsIHRoZWlyIHNodHVmZiBvbiB0aGF0
IGRv
ZXMgdGhlIHNhbWUgdGhpbmcuICBUaGUgb25lIHRoaW5nIHRoZSBhbGwgaGF2ZSBpbiBjb21t
b24g
aXMgdGhlaXIgTklDLi4uSW50ZWwgMTAwIFByby4gIE5vdywgSSBrbm93IGFsbCB0aGUgQ29t
cGFx
IGd1eXMgb3V0IHRoZXJlIGFyZSBzY3JlYW1pbmcgIkJ1dCB0aGUgQ29tcGFxIGRvZXNuJ3Qg
aGF2
ZSBhIEludGVsIE5JQyBpbiBpdCEhISIuICBJIGluc3RhbGxlZCBvbmUgaW4gdGhlIENvbXBh
cSBi
b3ggdG8gcmVwbGFjZSB0aGUgMTBNYiBjYXJkIHRoYXQgY2FtZSBzdGFuZGFyZC4gIEFuZCB0
aGUg
RGVsbCBoYXJkd2FyZSBpcyBjb21wcmlzZWQgb2YgZm91ciBkaWZmZXJlbnQgbW9kZWxzLi4u
UEUg
NDQwMCwgUEUgMjUwMCwgUEUgMTQwMCBhbmQgUEUgNTAwU0MuDQoNCkkgaGF2ZSB0cmllZCB0
aGUg
bmV3ZXN0IGRyaXZlcnMgZnJvbSBJbnRlbCBhbmQgZnJvbSBEZWxsLCBidXQgbmVpdGhlciBo
YXZl
IHNlZW1lZCB0byByZWFsbHkgbWFrZSBtdWNoIG9mIGEgZGlmZmVyZW5jZS4gIFRoZSB0aW1l
IGJl
dHdlZW4gb2NjdXJyYW5jZXMgdmFyaWVzIGZyb20gNy0yMCBkYXlzLCBidXQgaXQncyBhIHNh
ZmUg
YmV0IHRoYXQgaWYgdGhlIHNlcnZlciBkb2Vzbid0IGdldCByZWJvb3RlZCBpbiB0aGF0IHBl
cmlv
ZCBvZiB0aW1lLCBpdCdzIGdvaW5nIHRvIGdldCByZWJvb3RlZCBzb29uZXIgb3IgbGF0ZXIu
DQoN
ClNvLCBJIHN1cHBvc2UgdGhlICQ2NCBxdWVzdGlvbiB3b3VsZCBiZSB3aGF0IE5JQyBhcmUg
eW91
IHJ1bm5pbmcgaW4geW91ciBHYXRld2F5IHN5c3RlbT8NCg0KUm9iDQoNCi0tLS0tT3JpZ2lu
YWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpcyBNb29yZSBbbWFpbHRvOmNtb29yZTAxQE1ZUkVB
TEJP
WC5DT01dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDE1LCAyMDAyIDQ6MjAgUE0NClRvOiBO
T1ZF
TExATFNWLlNZUi5FRFUNClN1YmplY3Q6IFJlOiBYZW9uIDIuMiBHSHogcHJvY3MNCg0KDQpG
b3Ig
d2hhdCBpdCBpcyB3b3J0aCwgbXkgc2VydmVyIGFuZCBhbm90aGVyIHNlcnZlciBpbiBhbm90
aGVy
IERpdmlzaW9uIGhhdmUgaGFkICJjb21tdW5pY2F0aW9ucyIgc3RvcHBhZ2VzIGF2ZXJnaW5n
IGFi
b3V0IGV2ZXJ5IDggZGF5cyBiZWZvcmUgTm92ZWxsIGhhZCB1cyBpbnN0YWxsIE5XQ0xJQjMu
ICBU
aGVuIG1pbmUgbGFzdGVkIDEwIGRheXMuICBTZXJ2ZXIgZG9lcyBub3QgbG9jayB1cCwgYnV0
IHF1
aXRzIGNvbW11bmljYXRpbmcuICBXaWxsIG9ubHkgZG8gYSBsb29wYmFjay4gIEJvdGggc2Vy
dmVy
cyBhcmUgRHVhbCBYRU9OIHByb2Nlc3NvcnMuICBCb3RoIHdvcmtlZCBmaW5lIHdpdGggTlc1
LjAg
U1A2YSwgcHJpb3IgdG8gdGhlIHVwZ3JhZGUgdG8gTlc2LjBTUDEuICBPbmUgaXMgYSBEZWxs
IDQ0
MDAgd2l0aCAxIEdCIG9mIFJBTSBhbmQgYW5vdGhlciBpcyBhIEdhdGV3YXkgd2l0aCAyIEdC
IG9m
IFJBTS4gIE90aGVyIHNlcnZlcnMgaW4gdGhlIERlcGFydG1lbnQgYXJlIG5vdCBEdWFsIFhF
T05z
IGFyZSB0aGV5IGRvIG5vdCBoYXZlIHRoZSBwcm9ibGVtLg0KDQoNCkNvdWxkIHlvdSBiZSBh
IGxp
dHRsZSBtb3JlIHNwZWNpZmljIGluIHlvdXIgcXVlc3Rpb24vcHJvYmxlbT8gIFdoYXQgc3Bl
Y2lm
aWNhbGx5IGFyZSB5b3Ugc2VlaW5nIGFzIGZhciBhcyBwcm9ibGVtcy9pc3N1ZXM/ICANCg0K
dGhh
bmtzLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiUmljaGFyZCBT
ZWlm
ZXJ0LCBKciIgPHJmc0BDTEFSS1NPTi5FRFU+DQpUbzogTk9WRUxMQExTVi5TWVIuRURVIA0K
RGF0
ZTogVGh1LCAxNSBBdWcgMjAwMiAwODozMjowNiAtMDQwMA0KU3ViamVjdDogWGVvbiAyLjIg
R0h6
IHByb2NzDQoNCkhleSBvdXQgdGhlcmUsDQogICAgICAgIEFueW9uZSBoYXZlIGFueSBpc3N1
ZXMg
d2l0aCBYZW9uIHByb2Nlc3NvcnMsIHNwZWNpZmljYWxseSBhIHBhaXIgb2YNCnRoZW0sIGlu
IGEg
TlcgNiBib3g/ICBTcGVjaWZpY2FsbHkgYSBEZWxsIDQ2MDAgd2l0aCA0RyBvZiBSQU0sIGJ1
dCBq
dXN0DQppbiBnZW5lcmFsLiAgTlcgNiBpcyBwYXRjaGVkIHdpdGggU1AxIGFuZCB0aGUgcHJl
LVNQ
MiBzZXJ2ZXIuZXhlLCBidXQNCndhcyBoYXZpbmcgcHJvYmxlbXMgZXZlbiB3aXRoIHRoZSBT
UDEg
c2VydmVyLmV4ZS4gIFRoYW5rcyBmb3IgYW55IGluZm8uDQoNClJlZ2FyZHMsDQpSaWNoDQoN
Ci0t
DQpSaWNoYXJkIFNlaWZlcnQsIEpyDQpBc3MndCBEaXJlY3RvciBvZiBOZXR3b3JrIE9wZXJh
dGlv
bnMNCkNsYXJrc29uIFVuaXZlcnNpdHkgLSBPSVQNClBvdHNkYW0sIE5ZICAxMzY5OQ0KKDMx
NSkg
MjY4LTY3MjUNCnJmc0BjbGFya3Nvbi5lZHUNCg=
-----------------------------
Date: Fri, 16 Aug 2002 11:04:00 -0400
From: "Richard Seifert, Jr" <rfs@CLARKSON.EDU>
Subject: Re: Xeon 2.2 GHz procs
Hmmm,
Interesting. To follow on this note, I am running an Intel
CE100 card
in my Dell. My symptoms sometimes are that the server seems to be ok
but nobody can talk to it. Sometimes it just freezes and I get no abend
log, or any other indication as to what happened. This happens anywhere
from 1-10 days. Don't know if a periodic controlled reboot helps,
haven't tried that yet.
I am very interested in the hyper-thread part of this whole
conversation, though. It seems related to my PE4600. TID 2963292 looks
relevant. I have not been able to successfully download SP2 yet due to
a slow connection somewhere between here and there. Does anyone know if
the PSM files in SP2 match the ones out there in the beta PSM2.exe
update?
Rich
"Walters, Rob" wrote:
>
> Taking the fork in the road that you put there...
>
> I have seen a similar problem to yours...the server sits there all
pretty-like, but nobody can talk to it. At first I suspected that it
may be something related to the Dell hardware, but then I realized that
I have a Compaq server that our PC guys use to store all their shtuff on
that does the same thing. The one thing the all have in common is their
NIC...Intel 100 Pro. Now, I know all the Compaq guys out there are
screaming "But the Compaq doesn't have a Intel NIC in it!!!". I
installed one in the Compaq box to replace the 10Mb card that came
standard. And the Dell hardware is comprised of four different
models...PE 4400, PE 2500, PE 1400 and PE 500SC.
>
> I have tried the newest drivers from Intel and from Dell, but neither
have seemed to really make much of a difference. The time between
occurrances varies from 7-20 days, but it's a safe bet that if the
server doesn't get rebooted in that period of time, it's going to get
rebooted sooner or later.
>
> So, I suppose the $64 question would be what NIC are you running in
your Gateway system?
>
> Rob
>
> -----Original Message-----
> From: Chris Moore [mailto:cmoore01@MYREALBOX.COM]
> Sent: Thursday, August 15, 2002 4:20 PM
> To: NOVELL@LSV.SYR.EDU
> Subject: Re: Xeon 2.2 GHz procs
>
> For what it is worth, my server and another server in another Division
have had "communications" stoppages averging about every 8 days before
Novell had us install NWCLIB3. Then mine lasted 10 days. Server does
not lock up, but quits communicating. Will only do a loopback. Both
servers are Dual XEON processors. Both worked fine with NW5.0 SP6a,
prior to the upgrade to NW6.0SP1. One is a Dell 4400 with 1 GB of RAM
and another is a Gateway with 2 GB of RAM. Other servers in the
Department are not Dual XEONs are they do not have the problem.
>
> Could you be a little more specific in your question/problem? What
specifically are you seeing as far as problems/issues?
>
> thanks...
>
> -----Original Message-----
> From: "Richard Seifert, Jr" <rfs@CLARKSON.EDU>
> To: NOVELL@LSV.SYR.EDU
> Date: Thu, 15 Aug 2002 08:32:06 -0400
> Subject: Xeon 2.2 GHz procs
>
> Hey out there,
> Anyone have any issues with Xeon processors, specifically a
pair of
> them, in a NW 6 box? Specifically a Dell 4600 with 4G of RAM, but
just
> in general. NW 6 is patched with SP1 and the pre-SP2 server.exe, but
> was having problems even with the SP1 server.exe. Thanks for any
info.
>
> Regards,
> Rich
>
> --
> Richard Seifert, Jr
> Ass't Director of Network Operations
> Clarkson University - OIT
> Potsdam, NY 13699
> (315) 268-6725
> rfs@clarkson.edu
--
Richard Seifert, Jr
Ass't Director of Network Operations
Clarkson University - OIT
Potsdam, NY 13699
(315) 268-6725
rfs@clarkson.edu
-----------------------------
Date: Fri, 16 Aug 2002 09:22:00 -0600
From: Tim Madden <tmadden@ASPENRES.COM>
Subject: IPX Ping
While troubleshooting IPX on a new NT box, I brought up IPXPING on one
of my two NW 4.11 servers, NW2. Sure enough, I couldn't IPXPing it and
assume the IPX stack on the NT box is corrupt. Just as a sanity check,
I tried to IPXPing NW1 from NW2. No dice. Hmmm...that's strange.
Okay, so can I IPXPing NW2 from NW1? Logic would tell me no but, sure
enough, there it is happily responding.
However, I can't IPXPing ANY NT boxes I have running IPX. I have
verified that all boxes in question are forced to same frame type and
network number. Also, we have a proprietary app that is IPX only and
must communicate with the NT boxes. This app is running great to all
but the new NT box (which is why I'm troubleshooting it to begin with).
So, I can IPXPing NW2 from NW1, but not NW1 from NW2. I cannot IPXPing
any NT box from either NW box. NW servers are in same tree and have
been running happily for 5 years. There are no other obvious problems,
i.e. Time Synch, inaccessibility from clients, etc. Same versions of
NW, IPXS & IPXPing. I do see that NW2 has IPXRTR loaded and I'll
investigate it's possible interference, but would appreciate any other
thoughts.
Tim Madden, CNA, CCNA, A+
MIS Manager
Aspen Research Group
-----------------------------
Date: Fri, 16 Aug 2002 10:23:24 -0500
From: Peter Van Lone <Peter.VanLone@MBTMADISON.COM>
Subject: Re: Insights on Service Location Protocol
Good over-view Joe -- and an interesting "not the way they do it in the
manual" twist on deployment.
Just for the record, I've deployed it the way the TIDs and the manuals
have described in a couple WAN environments (60+ servers and slow links
in one case) and it has worked like a charm.
NW5.1 servers using a named scope, No DA's across the WAN, only 2 DA's
(an extra for fault tolerance) at the central site using a dedicated
container that was it's own partition. All other servers using slp.cfg
and clients configured with static assignments. We also added the DHCP
info -- but this seemed to not be reliable, which is why we statically
configured the clients.
The idea that all devices could query a local DA server for ALL SLP info
in the tree is powerful. Especially since a central DA means that if the
WAN link to the DA goes down then clients are sort of stuck -- no way to
get info about anything that is not local.
I guess as long as the partition was not too large, then the sync
traffic generated by partition replication would be only SLIGHTLY more
than the traffic generated by SA/UA queries back to a central DA? Have
you had a chance to think about traffic comparisons between the 2
approaches? Would you take the same approach (A DA on every server)if
there were 50 remote sites, each with 1-5 servers and some with slow
links back? That's a lot of replicas and a lot of synch traffic, isn't
it?
Thanx again for the thought-provocation!
-----------------------------
Date: Fri, 16 Aug 2002 16:56:15 +0100
From: Ian Kennedy <ian.kennedy@DTU.OX.AC.UK>
Subject: TCP/IP communicaion problems...
Hi, we have a strange problem with our netware servers.
The machines are NW5.1sp3 boxes with the latest tcpip.nlm
for sp3 (version 5.42u).
The other week our airconditioner died so we had to move
the servers to another building. In doing this they moved
from one subnet to another. Physically from one port on a
big cisco switch to another, logically one IP network to
another.
After the switch we noticed that performance was dramatically
slower. Mostly the connection was fine but seemed to suffer
'dark' patches where no communication would be possible. After
about 5-10 seconds the comms would spontainiously restart.
To investigate this we setup ping to ping from one network server
to another machine elsewhere in the university. We also setup
a ping to another server on the same subnet. The results where
interesting. If we talk of our orignal subnet as A and the place
we moved to being B the results where as follows:
B - B 100% returned
B - A 96% returned
ie the loss due to crossing the switch is 6% whereas the local
loss was 0%.
Since the aircon has been fixed we've moved the machines back
to the original subnet, however, the problem has not gone away.
We now have the following results:
A - A 100% returned
A - B 96% returned
It seems that the server can communicate with a machine in the
same subnet that it is in, but, the moment we ask it to talk
accross the switch it drops packets. What's very odd is that
other machines in either the A ot B subnet do not get this problem.
They can ping accross the switch without issue.
We've tried changing the ethernet card to no avail. The results
remained the same. If you watch the ping screen the packet loss
is not evenly distributed. Most of the time the data flows fine
but then ping stops getting responces for a period of 10-30
seconds and then it clears and starts working again.
Also, worth noting is that there are two machines that are doing
this exact same thing, each with different hardware. One server
has an Intel Pro100B the other a Intel Intelegent Server adapter.
Granted both are from intel but they do use different driver files.
One final thing. If I do the same pings with IPXPing then the results
are 100% no matter where I possition the server or ping to. So it
would seem to be down to TCP/IP.
Any thoughts would be extreemly usefull
TIA
Ian
-----------------------------
Date: Fri, 16 Aug 2002 10:07:24 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Insights on Service Location Protocol
> Good over-view Joe -- and an interesting "not the way they do it in the
> manual" twist on deployment.
>
> Just for the record, I've deployed it the way the TIDs and the manuals
> have described in a couple WAN environments (60+ servers and slow links
> in one case) and it has worked like a charm.
>
> NW5.1 servers using a named scope, No DA's across the WAN, only 2 DA's
> (an extra for fault tolerance) at the central site using a dedicated
> container that was it's own partition. All other servers using slp.cfg
> and clients configured with static assignments. We also added the DHCP
> info -- but this seemed to not be reliable, which is why we statically
> configured the clients.
>
> The idea that all devices could query a local DA server for ALL SLP
info
> in the tree is powerful. Especially since a central DA means that if
the
> WAN link to the DA goes down then clients are sort of stuck -- no way
to
> get info about anything that is not local.
>
> I guess as long as the partition was not too large, then the sync
> traffic generated by partition replication would be only SLIGHTLY more
> than the traffic generated by SA/UA queries back to a central DA? Have
> you had a chance to think about traffic comparisons between the 2
> approaches? Would you take the same approach (A DA on every server)if
> there were 50 remote sites, each with 1-5 servers and some with slow
> links back? That's a lot of replicas and a lot of synch traffic, isn't
> it?
>
> Thanx again for the thought-provocation!
---------------
I don't have numbers or shrewd reliable info on the NDS
replication
part of things. But we can make a stab at the problem.
Sharing a partition means a replica ring for it. Data is not
moved around the ring on each cycle, but rather a query is made about
the timestamp of the latest change, the synch'd up to stamp. If changes
occur then there is a query about "um, ok, which items have changed and
their values please". These result in packets, but small ones and at
a rate determined by both ring sync and whether changes cause immediate
or slow updates.
Stable nets usually have slow changes occuring to the list of
services. Thus changes are also slow. What remains is the ring heartbeat
looking for news. I suspect this is of the order of say time sync
traffic,
or smaller, but I am guessing.
Deeper down what we really need to design is the set of services
known to clients in various regions of our network. In most cases
complete
knowledge is not wanted, and thus either Scope names or a set of
different
NDS replicas are tools to cause partition of SLP information on a
regional
basis.
We want a region to supply all of its information when we ask
any
server in the region. Otherwise the client is obliged to go round to
server
after server (ok, DA after DA) asking about things, which in turn means
configuring many DAs in each client, plus the traffic involved in such
queries. To ensure regional uniformity we use two tools: each server has
a DA and all of those DAs pool their information in NDS. We can
supplement
this with one or more DHCP servers offering addresses of DAs for the
region
so that clients need not be configured manually. DHCP INFORM queries
take
care of supplying both DA addresses and Scope.
If we don't pool then clients receive different sets of answers
from different servers. We know what fun it is decoding trouble calls
in that environment. To repeat previous discussion, a particular DA
receives SA registration requests by either dynamic multicast traffic
or by SAs statically configured to contact a DA. The DA puts such info
into its databases (cache and NDS). Queries cause a DA to look into its
database for answers. So far, what the DA can answer depends on what it
has in its database, due allowance given for Scope name. Thus we can
imagine a DA's "feeding range" as being local traffic, plus whatever
gets into its database by other means. If no NDS pooling occurs then
various DAs can and usually do have different data.
Compounding the collection process is the characteristic of
an SA being told it can use dynamic or static methods of DA discovery.
By default the method is dynamic until a local DA is installed and then
it become static and to that particular DA. File etc\slp.cfg can add to
the list of static addresses. Such dynamic versus static behavior can be
controlled via Monitor, Server parameters, SLP, the DA discovery option.
To get back to the current discussion, our decisions are over
what region to collect SLP information and how to offer it to clients
on a reliable basis. We then face the situation of NDS replication
traffic, and the consequences of simply having a replica ring which may
be interrupted by server outages.
Golly, it takes a lot of talking before we learn how to say
things compactly. I'm trying (and trying...).
Joe D.
-----------------------------
Date: Fri, 16 Aug 2002 12:10:16 -0400
From: John Hanna <John@COASTAL.EDU>
Subject: Re: TCP/IP communicaion problems...
Here are some things you may want to check.
1) Make sure the duplex and speed are hard set to the same on the
servers
and the switch ports. I recommend half duplex at least until you find
your
problem out.
2) make sure you have the gateway set on your servers. I have seen
marginal
problems with traffic leaving the subnet on servers without the gateway
set.
3) Check to see if you have someone else competing for your IP address.
This sounds possible since, traffic goes fine and then quits for a few
minutes it could mean the arp table is changing, most windows boxes will
arp
to see if the address is already in use, if it is, it will disable the
interface, but not until it has cause problems for about the period of
time
you state.
HTH
> -----Original Message-----
> From: Novell LAN Interest Group [mailto:NOVELL@LSV.SYR.EDU]On Behalf Of
> Ian Kennedy
> Sent: Friday, August 16, 2002 11:56 AM
> To: NOVELL@LSV.SYR.EDU
> Subject: TCP/IP communicaion problems...
>
>
> Hi, we have a strange problem with our netware servers.
> The machines are NW5.1sp3 boxes with the latest tcpip.nlm
> for sp3 (version 5.42u).
>
> The other week our airconditioner died so we had to move
> the servers to another building. In doing this they moved
> from one subnet to another. Physically from one port on a
> big cisco switch to another, logically one IP network to
> another.
>
> After the switch we noticed that performance was dramatically
> slower. Mostly the connection was fine but seemed to suffer
> 'dark' patches where no communication would be possible. After
> about 5-10 seconds the comms would spontainiously restart.
>
> To investigate this we setup ping to ping from one network server
> to another machine elsewhere in the university. We also setup
> a ping to another server on the same subnet. The results where
> interesting. If we talk of our orignal subnet as A and the place
> we moved to being B the results where as follows:
>
> B - B 100% returned
> B - A 96% returned
>
> ie the loss due to crossing the switch is 6% whereas the local
> loss was 0%.
>
> Since the aircon has been fixed we've moved the machines back
> to the original subnet, however, the problem has not gone away.
> We now have the following results:
>
> A - A 100% returned
> A - B 96% returned
>
> It seems that the server can communicate with a machine in the
> same subnet that it is in, but, the moment we ask it to talk
> accross the switch it drops packets. What's very odd is that
> other machines in either the A ot B subnet do not get this problem.
> They can ping accross the switch without issue.
>
> We've tried changing the ethernet card to no avail. The results
> remained the same. If you watch the ping screen the packet loss
> is not evenly distributed. Most of the time the data flows fine
> but then ping stops getting responces for a period of 10-30
> seconds and then it clears and starts working again.
>
> Also, worth noting is that there are two machines that are doing
> this exact same thing, each with different hardware. One server
> has an Intel Pro100B the other a Intel Intelegent Server adapter.
> Granted both are from intel but they do use different driver files.
>
> One final thing. If I do the same pings with IPXPing then the results
> are 100% no matter where I possition the server or ping to. So it
> would seem to be down to TCP/IP.
>
> Any thoughts would be extreemly usefull
> TIA
> Ian
>
-----------------------------
Date: Fri, 16 Aug 2002 12:52:29 -0400
From: "Richard Seifert, Jr" <rfs@CLARKSON.EDU>
Subject: Win2K, ZfD 3.2 and context-less login
Hello all,
We have labs that are runnung Win2K with the 4.83 client
installed with
PT2, but not SP1. We are running ZfD 3.2, but only for authentication
to the 2K box and some locking down through policies. No w/s imports or
anything like that. We are also using the lgncl package from the Cool
Solutions site for context-less login. It works quite nicely on PCs
w/out the workstation management portion of the client installed.
However, with ZfD interacting with the PCs in the labs, the context-less
login acts a little strange. When the PC is re-booted, the c/less login
won't find the context correctly. Then after that, sometimes it will
work and sometimes you have to type the username a couple times for it
to find the context. Anyone had any experiences like this, or have any
pointers? Thanks for any help?
Regards,
Rich
--
Richard Seifert, Jr
Ass't Director of Network Operations
Clarkson University - OIT
Potsdam, NY 13699
(315) 268-6725
rfs@clarkson.edu
-----------------------------
Date: Fri, 16 Aug 2002 12:55:14 -0400
From: Sommer Sharp <meaou@UFL.EDU>
Subject: Re: Win2K, ZfD 3.2 and context-less login
We are using a freware program called NoCTX dith ZfD 3.2. Zero problems
loging into different trees/contextes.
Sommer Sharp, Postmaster
Systems Programmer
College of Veterinary Medicine
University of Florida
352-392-4700
> > > rfs@CLARKSON.EDU 8/16/02 12:52:29 PM >>>
Hello all,
We have labs that are runnung Win2K with the 4.83 client
installed with
PT2, but not SP1. We are running ZfD 3.2, but only for authentication
to the 2K box and some locking down through policies. No w/s imports
or
anything like that. We are also using the lgncl package from the Cool
Solutions site for context-less login. It works quite nicely on PCs
w/out the workstation management portion of the client installed.
However, with ZfD interacting with the PCs in the labs, the
context-less
login acts a little strange. When the PC is re-booted, the c/less
login
won't find the context correctly. Then after that, sometimes it will
work and sometimes you have to type the username a couple times for it
to find the context. Anyone had any experiences like this, or have
any
pointers? Thanks for any help?
Regards,
Rich
--
Richard Seifert, Jr
Ass't Director of Network Operations
Clarkson University - OIT
Potsdam, NY 13699
(315) 268-6725
rfs@clarkson.edu
-----------------------------
Date: Fri, 16 Aug 2002 13:00:55 -0400
From: "Walters, Rob" <RWalters@COMPBENEFITS.COM>
Subject: Intel 100 Pro Cards (Was Xeon 2.2 GHz procs)
(Sorry for the repost...Joe D informed me that all some people saw from
my last post was trash...trying to use percussive maintenance to get Outlook to \
format this in plain text.)
Taking the fork in the road that you put there...
I have seen a similar problem to yours...the server sits there all pretty-like, but \
nobody can talk to it. At first I suspected that it may be something related to the \
Dell hardware, but then I realized that I have a Compaq server that our PC guys use \
to store all their shtuff on that does the same thing. The one thing the all have in \
common is their NIC...Intel 100 Pro. Now, I know all the Compaq guys out there are \
screaming "But the Compaq doesn't have a Intel NIC in it!!!". I installed one in the \
Compaq box to replace the 10Mb card that came standard. And the Dell hardware is \
comprised of four different models...PE 4400, PE 2500, PE 1400 and PE 500SC.
I have tried the newest drivers from Intel and from Dell, but neither have seemed to \
really make much of a difference. The time between occurrances varies from 7-20 \
days, but it's a safe bet that if the server doesn't get rebooted in that period of \
time, it's going to get rebooted sooner or later.
So, I suppose the $64 question would be what NIC are you running in your
Gateway system?
Rob
-----Original Message-----
From: Chris Moore [mailto:cmoore01@MYREALBOX.COM]
Sent: Thursday, August 15, 2002 4:20 PM
To: NOVELL@LSV.SYR.EDU
Subject: Re: Xeon 2.2 GHz procs
For what it is worth, my server and another server in another Division have had \
"communications" stoppages averging about every 8 days before Novell had us install \
NWCLIB3. Then mine lasted 10 days. Server does not lock up, but quits \
communicating. Will only do a loopback. Both servers are Dual XEON processors. \
Both worked fine with NW5.0 SP6a, prior to the upgrade to NW6.0SP1. One is a Dell \
4400 with 1 GB of RAM and another is a Gateway with 2 GB of RAM. Other servers in \
the Department are not Dual XEONs are they do not have the problem.
Could you be a little more specific in your question/problem? What specifically are \
you seeing as far as problems/issues?
thanks...
-----------------------------
Date: Fri, 16 Aug 2002 12:02:04 -0500
From: Peter Van Lone <Peter.VanLone@MBTMADISON.COM>
Subject: Re: Intel 100 Pro Cards (Was Xeon 2.2 GHz procs)
Just FYI -- I saw your last post just fine.
> -----Original Message-----
> From: Walters, Rob [mailto:RWalters@COMPBENEFITS.COM]
> Sent: Friday, August 16, 2002 12:01 PM
> To: NOVELL@LSV.SYR.EDU
> Subject: Intel 100 Pro Cards (Was Xeon 2.2 GHz procs)
>
> (Sorry for the repost...Joe D informed me that all some people saw
from my
> last post was trash...trying to use percussive maintenance to get
Outlook
> to format this in plain text.)
>
> Taking the fork in the road that you put there...
>
> I have seen a similar problem to yours...the server sits there all
pretty-
> like, but nobody can talk to it. At first I suspected that it may be
> something related to the Dell hardware, but then I realized that I
have a
> Compaq server that our PC guys use to store all their shtuff on that
does
> the same thing. The one thing the all have in common is their
NIC...Intel
> 100 Pro. Now, I know all the Compaq guys out there are screaming "But
the
> Compaq doesn't have a Intel NIC in it!!!". I installed one in the
Compaq
> box to replace the 10Mb card that came standard. And the Dell
hardware is
> comprised of four different models...PE 4400, PE 2500, PE 1400 and PE
> 500SC.
>
> I have tried the newest drivers from Intel and from Dell, but neither
have
> seemed to really make much of a difference. The time between
occurrances
> varies from 7-20 days, but it's a safe bet that if the server doesn't
get
> rebooted in that period of time, it's going to get rebooted sooner or
> later.
>
> So, I suppose the $64 question would be what NIC are you running in
your
> Gateway system?
>
> Rob
>
> -----Original Message-----
> From: Chris Moore [mailto:cmoore01@MYREALBOX.COM]
> Sent: Thursday, August 15, 2002 4:20 PM
> To: NOVELL@LSV.SYR.EDU
> Subject: Re: Xeon 2.2 GHz procs
>
>
> For what it is worth, my server and another server in another Division
> have had "communications" stoppages averging about every 8 days before
> Novell had us install NWCLIB3. Then mine lasted 10 days. Server does
not
> lock up, but quits communicating. Will only do a loopback. Both
servers
> are Dual XEON processors. Both worked fine with NW5.0 SP6a, prior to
the
> upgrade to NW6.0SP1. One is a Dell 4400 with 1 GB of RAM and another
is a
> Gateway with 2 GB of RAM. Other servers in the Department are not
Dual
> XEONs are they do not have the problem.
>
>
> Could you be a little more specific in your question/problem? What
> specifically are you seeing as far as problems/issues?
>
> thanks...
-----------------------------
End of NOVELL Digest - 15 Aug 2002 to 16 Aug 2002 - Special issue
(#2002-346)
************************************************************************
*****
-----------------------------
End of NOVELL Digest - 16 Aug 2002 to 17 Aug 2002 - Special issue
(#2002-348)
************************************************************************
*****
------------------------------
End of NOVELL Digest - 17 Aug 2002 - Special issue (#2002-349)
**************************************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic