[Bordermanager] Abend bij Reading NDS

[DGTL_Magician]

Wij hebben hier een aantal Bordermanager 3.5 servers staan. Een van deze servers geeft wat problemen. De server draait op Netware 5.1 service pack 4.
De bordermanager server 3.5 zit op service pack 3.
Het specifieke probleem is dat wanneer we proxy.nlm gaan laden de server het heel erg druk krijgt met iets (wat weten we niet ), de boodschap "Reading NDS configuration information" weergeeft, en vervolgens in een abend schiet.

We hebben de server een volledige Low-level format gegeven en geherinstalleerd (om verscheidene redenen) en nog steeds treedt de fout op.

[Verwijderd]

Wat staat er in het abendlog? Of is er uberhaupt geen?

[Koffie]

Ik meen dat je die melding ziet als de proxy onder andere je cache files inleest.
Probeer eens een LOAD PROXY -CC te doen ?
Porxy -cc staat voor ClearCache.
Alle files uit de cache/temp inet files worden dan deleted.

Ik gok dat het er weinig mee te maken heeft, maar het is een shot om te proberen.

Verder :
- Is je NDS wel 100% gezond ?
- Abend logfile
- Nieuwe BM installatie of zomaar ineens spontane probs ?

Hmm.. server volledig opnieuw geinstalleerd en je houd hetzelfde probleem ?

Dan kan ik me maar 1 ding indenken.

Je hebt een NDS met meerdere servers.
Een aantal specifieke settings voor die ene server zitten nog in de NDS, je installed de server opnieuw (geeft hem dus waarschijnlijke dezelfde naam) en je prob is terug.

Ik zou dus eens naar je NDS kijken (zowel met DSREPAIR als in NWAdmin om zo naar rare objechten te kijken in die server container).

[Verwijderd]

Ook wel van belang: heeft het in het verleden wel goed gewerkt? Hield het ineens op met werken, of na een wijziging?

Je geeft zelf al aan dat de server druk bezig gaat voordat hij in een Abend schiet, het zouden dus ook (SCSI?) verkeerde drivers kunnen zijn..

Btw. wat voor netwerk zit er aan? Token Ring kan nl. ook hele leuke abends veroorzaken als je een beaconing ring gebruikt..

[DGTL_Magician]

In het verleden werkte het prima. Het hangt gewoon aan een standaard Ethernet UTP netwerkje op een 100mbit switch. Ik ben vandaag ziek naar huis gegaan, vandaar dat de abend.log en config.txt nog ontbreken, die zal ik morgen wel ff posten. Maar in de abend.log staat weinig nuttigs. Ik heb bij de novell supportsite nog een Tid gevonden die in het verleden wel werkte op een andere BM server die ik beheerde. (Die ging over een corrupte hosts file.)

Daarnaast is de NDS gezond, dat weet ik 100% zeker, aangezien ikzelf nogal een eDirectory-freak ben. Heb al gedstraced, weinig nuttigs daar, geen fouten. DSRepair heb ik zowel een unattended gedraaid als een local DS repair.

Wat overigens wel vreemd is dat een volledige re-install van de server niet geholpen heeft. Niet voordat we de BM sp's hebben geinstalleerd, en niet nadien.

Server is uit de DS geweest en onder andere naam + server ID weer terug, dus BM objecten niet beschadigd. Het is in ieder geval een super-vage fout.

[ Voor 19% gewijzigd door DGTL_Magician op 11-02-2003 19:34 ]

[DGTL_Magician]

Verwijderd schreef op 11 februari 2003 @ 16:37:
Ook wel van belang: heeft het in het verleden wel goed gewerkt? Hield het ineens op met werken, of na een wijziging?

Je geeft zelf al aan dat de server druk bezig gaat voordat hij in een Abend schiet, het zouden dus ook (SCSI?) verkeerde drivers kunnen zijn..

Btw. wat voor netwerk zit er aan? Token Ring kan nl. ook hele leuke abends veroorzaken als je een beaconing ring gebruikt..

Het hield ineens op met werken, geen wijziging. De SCSI drivers zijn zowel als standaard Netware drivers alswel de HP geleverde drivers geprobeerd.

[Koffie]

Wat overigens wel vreemd is dat een volledige re-install van de server niet geholpen heeft. Niet voordat we de BM sp's hebben geinstalleerd, en niet nadien

Als een BorderManager na een install meteen klapt is dat het enige waar ik aan kan denkenk

Doing NetWare installs de hardcore manier:
- Pak een werkstation
- Installeer Netware
- Installeer BorderManager
- Zorg dat het zooitje werkt
- Maak met ServerImage een backup
- restore de image op de bewuste server
- Pas het zooitje aan (SCSI drivers, evt. SMP aanzetten etc)
- reboot server
- Start Brdsrv en bid

[DGTL_Magician]

Koffie schreef op 11 February 2003 @ 19:52:
[...]

Als een BorderManager na een install meteen klapt is dat het enige waar ik aan kan denkenk

Doing NetWare installs de hardcore manier:
- Pak een werkstation
- Installeer Netware
- Installeer BorderManager
- Zorg dat het zooitje werkt
- Maak met ServerImage een backup
- restore de image op de bewuste server
- Pas het zooitje aan (SCSI drivers, evt. SMP aanzetten etc)
- reboot server
- Start Brdsrv en bid

Mjah, ook dat wilden we al proberen. We hebben meerdere locaties, en daar staan ook nog Bordermanager servers, zelfs wel een van hetzelfde type. Morgen maar ff kijken dus. In ieder geval komt mijn abend.log en config.txt er ook nog wel ff aan.

[metalant]

Hmm, waarom draai je met NW5SP4?

Probeer het eens met de laatste versie: NetWare 5.1 Support Pack 5. Daar draai ik al een hele tijd mee op onze BM 3.5 server.

Welke NDS versie draai je? EDirectory 8.6, of 8.7, of een oudere?

[Koffie]

Op zich leuk zo'n SP , echter neemt dat niet weg dat BM3.5EE out of the box zonder probs moet en kan runnen op een NW5.1 out of the box

[DGTL_Magician]

metalant schreef op 11 februari 2003 @ 20:15:
Hmm, waarom draai je met NW5SP4?

Probeer het eens met de laatste versie: NetWare 5.1 Support Pack 5. Daar draai ik al een hele tijd mee op onze BM 3.5 server.

Welke NDS versie draai je? EDirectory 8.6, of 8.7, of een oudere?

We draaien 8.6.2, maar op de andere servers, en op deze server in het verleden was dat nooit een probleem.

Koffie schreef op 11 februari 2003 @ 21:44:
Op zich leuk zo'n SP , echter neemt dat niet weg dat BM3.5EE out of the box zonder probs moet en kan runnen op een NW5.1 out of the box

idd, just my point. Omdat we alle servers op dezelfde service packs, eDirectory versie, etc. willen houden draaien we nog SP4. En om voor dit ene probleem 35 servers te upgraden naar SP5 is ook niet de bedoeling.

[Arfman]

Maar uiteindelijk zul je toch ooit naar SP5 moeten

Anyway: hijh hangt op Reading NDS .. heb je al geprobeerd om de access rules weg te halen en kijken wat er dan gebeurt ?

[DGTL_Magician]

Arfman schreef op 12 February 2003 @ 10:11:
Maar uiteindelijk zul je toch ooit naar SP5 moeten

Anyway: hijh hangt op Reading NDS .. heb je al geprobeerd om de access rules weg te halen en kijken wat er dan gebeurt ?

Zoals ik al zei heb ik de server helemaal opnieuw geinstalleerd. De oude server uit de NDS getrokken, nieuwe objecten (andere naam + server id) aangemaakt, niet eens geconfigureerd. Gelijk hangt ie al bij het starten.

[BasXcore]

Het probleem kan zijn dat de server nog geen Time Synchronisation heeft met je NDS waardoor hij vastloopt op het verzoek van de BMMON.nlm of er Licentie's zijn in de NDS.

Dit probleem kan je oplossen door de Toolbox te gebruiken van Novell (Toolbiox.nlm). Met de DELAY optie kan je de PROXY.nlm laten delayen voor 5min.

Dit probleem kom ik vaak voor vooral in grote NDS omgevingen (WAN enz)...

Kijk op http://nscsysop.hypermart.net voor meer van dit soort oplossingen...

[-rAz-]

Dat probleem hadden wij ook wanneer de timesync nog niet ok was. Delay van de proxy of manueel starten heeft bij ons geholpen

[DGTL_Magician]

BasXcore schreef op 12 February 2003 @ 12:18:
Het probleem kan zijn dat de server nog geen Time Synchronisation heeft met je NDS waardoor hij vastloopt op het verzoek van de BMMON.nlm of er Licentie's zijn in de NDS.

Dit probleem kan je oplossen door de Toolbox te gebruiken van Novell (Toolbiox.nlm). Met de DELAY optie kan je de PROXY.nlm laten delayen voor 5min.

Dit probleem kom ik vaak voor vooral in grote NDS omgevingen (WAN enz)...

Kijk op http://nscsysop.hypermart.net voor meer van dit soort oplossingen...

Die site ken ik, in het verleden ook wel meegemaakt dat de timesync niet in orde was. Echter, in dit geval is dat zeker niet zo. Een abend.log en config.txt komen er zo nog aan.

Tijd is gesynchroniseerd met het netwerk. Echter, hij ziet niet alle servers, alleen zichzelf en de primary timeserver. Zou dus een SLP probleem kunnen zijn. Op de master ziet 'ie wel alle servers al time in sync.

relevante info uit abend.log:

code:

*********************************************************

Server LWG_TMPBM halted Wednesday, 12 February 2003  14:03:37 
Abend 1 on P00: Server-5.00k-957: CPU Hog Detected by Timer

Registers:
    CS = 0008 DS = 0010 ES = 0010 FS = 0010 GS = 0010 SS = 0010
    EAX = FCE0E615 EBX = D43C2C80 ECX = 00000000 EDX = D350F960
    ESI = D55E86FC EDI = D55E86F4 EBP = D55E7EA4 ESP = D55E7E00
    EIP = 00000000 FLAGS = 00000082 
    

Running process: NLS LSP Thread  4 Process
Created by: NetWare Application
Thread Owned by NLM: NLSLSP.NLM
Stack pointer: D55E7D10
OS Stack limit: D55E08C0
Scheduling priority: 67371008
Wait state: 5050030  (Blocked on Semaphore)
Stack: --FCE0E615  ?
       D34B74CA  ?
       --D55E7E48  ?
       --00000001  ?
       --00000001  ?
       --D62A9940  ?
       --00000001  ?
       --00000001  ?
       --D708D2E0  ?
       --00000001  ?
       --D12101AD  (UNICODE.NLM|gHTable+7CED)
       D11FD03A  (UNICODE.NLM|UnicodeToLocal+1AC)
       FC011D63  (SERVER.NLM|kRWReadUnlock+B7)
       --D0DD5A04  ?
       --00000001  ?
       --D55E7EC9  ?
       --D55E7E90  ?
       --D12101A2  (UNICODE.NLM|gHTable+7CE2)
       D11FCFF9  (UNICODE.NLM|UnicodeToLocal+16B)
       --D0DD5A00  ?
       --00000001  ?
       --D12101A0  (UNICODE.NLM|gHTable+7CE0)
       --D55E7EC8  ?
       --D55E0045  ?
       --D55E7EA0  ?
       -D1EA8A78  (DS.NLM|StoreDSTaskID+1C)
       -D1EA8A78  (DS.NLM|StoreDSTaskID+1C)
       --D55E7EC8  ?
       --00000000  ?
       --00000000  ?
       FC01DF95  (SERVER.NLM|FreeMemoryDefault+D5)
       --D628BAE0  ?
       --D628BAE0  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       -0003C378  (LOADER.EXE|loaderPublicList+DC8)
       --D55E7ED8  ?
       --D55E86F4  ?
       --D55E86FC  ?
       --D43C2C80  ?
       D34AD0BE  ?
       --D6287560  ?
       --D6E92040  ?
       --00000000  ?
       0002993D  (LOADER.EXE|GetRealModeInterruptMask+18A7)
       --00000000  ?
       --00000000  ?
       --ABC75020  ?
       --00000000  ?
       --D55E7F34  ?
       --D55E86F4  ?
       --D55E86FC  ?
       --D43C2C80  ?
       D34B8D36  ?
       --D62875EC  ?
       --D6287560  ?
       --D6E92040  ?
       --00000000  ?
       --D6E92040  ?
       --00000000  ?
       --0000000F  ?
       --3E2A727B  ?
       --D6E92040  ?
       --00000001  ?
       --00000001  ?
       --D6E92040  ?
       --00000000  ?
       --00000000  ?
       --D6E92040  ?
       --D6E920C0  ?
       --00000000  ?
       --3E4A45ED  ?
       --D55E7FA0  ?
       --D55E86F4  ?
       --D55E86FC  ?
       --D43C2C80  ?
       D34966B3  ?
       --D6287560  ?
       --00000001  ?
       --D55E7F7C  ?
       D310BC73  (THREADS.NLM|free+F)
       --D543B320  ?
       D34E87DB  (NLSLSP.NLM|NLSNDSGetEntriesRegister+20AA)
       --D543B320  ?
       D34DD2C5  ?
       --D543B320  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       --00000000  ?
       --C000400F  ?
       --D55E86FC  ?
       --D43C2C80  ?
       D34D5C55  ?
       
Additional Information:
    The NetWare OS detected a problem with the system while executing a process owned by SERVER.NLM.  It may be the source of the problem or there may have been a memory corruption.



*********************************************************

Server LWG_TMPBM halted Wednesday, 12 February 2003  14:21:09 
Abend 3 on P00: Server-5.00k-957: CPU Hog Detected by Timer

Registers:
    CS = 0008 DS = 0010 ES = 0010 FS = 0010 GS = 0010 SS = 0010
    EAX = FCE0E615 EBX = D00A5E80 ECX = 000000CD EDX = D1C51980
    ESI = 000000CD EDI = 00000089 EBP = D2433C54 ESP = D2433C4C
    EIP = 00000000 FLAGS = 00000092 
    

Running process: Server 04 Process
Created by: NetWare Application
Thread Owned by NLM: SERVER.NLM
Stack pointer: D2433C3C
OS Stack limit: D2430040
Scheduling priority: 67371008
Wait state: 3030070  (Yielded CPU)
Stack: --FCE0E615  ?
       FC0426D5  (SERVER.NLM|ValidateModuleHandle+15)
       --D2433C60  ?
       FC044F7F  (SERVER.NLM|GetNextLoadedListEntry+23)
       --00000089  ?
       --D67769C0  ?
       D17B548B  (SLP.NLM|gather_module_names+67)
       --00000089  ?
       --5F776E28  ?
       --75646F6D  ?
       --3D73656C  ?
       --4454454E  ?
       --4C4E2E42  ?
       --2900294D  ?
       --72646400  ?
       --2E30313D  ?
       --2E343031  ?
       --34322E32  ?
       --D4002939  ?
       --D408E3DC  ?
       --D17D3840  ?
       D17A599C  (SLP.NLM|parseAttribute+164)
       --D17D3840  ?
       --D408E3A0  ?
       --D408E3A0  ?
       --D17D3868  ?
       --D408E3A0  ?
       --00000058  ?
       --D408CE60  ?
       --00000000  ?
       --00000000  ?
       --D17D7A00  ?
       --D17D3840  ?
       --D408CE60  ?
       D17A57FC  (SLP.NLM|SLPParseAttributes+10C)
       --D408CE60  ?
       --D2433C00  ?
       --D408CE60  ?
       --D408CE60  ?
       --D17D3840  ?
       --00000000  ?
       --00000089  ?
       --00000000  ?
       --D6776A09  ?
       --D17D3840  ?
       --00000001  ?
       --00000007  ?
       --D12E4960  (WS2_32.NLM|spxPingAddress+1BE0)
       D17B5339  (SLP.NLM|register_services+2BD)
       --D3F21260  ?
       --5F776E28  ?
       --656D616E  ?
       --47574C3D  ?
       --504D545F  ?
       --28294D42  ?
       --5F706C73  ?
       --73726576  ?
       --3D6E6F69  ?
       --372E3176  ?
       --2829332E  ?
       --646E6962  ?
       --3D797265  ?
       --45555254  ?
       --60000029  ?
       --630C9DC0  ?
       --600004B6  ?
       --600C9DC0  ?
       --F50C9DC0  ?
       --58D07F3D  ?
       --AF0C9DC1  ?
       --3C1E1D17  ?
       --80000000  ?
       --DBD00178  ?
       --6900028E  ?
       --010004B6  ?
       --80000000  ?
       --01D10744  ?
       --45000000  ?
       --00D07EFA  ?
       --60D081FF  ?
       --520C9DC0  ?
       --FFD07EFA  ?
       --40FFFFFF  ?
       --2D0C9DB3  ?
       --35001A8C  ?
       --80001A8C  ?
       --28D10744  ?
       --646E6962  ?
       --3D797265  ?
       --45555254  ?
       --60000029  ?
       --630C9DC0  ?
       --600004B6  ?
       --600C9DC0  ?
       --F50C9DC0  ?
       --58D07F3D  ?
       --AF0C9DC1  ?
       --3C1E1D17  ?
       --80000000  ?
       --DBD00178  ?
       
Additional Information:
    The NetWare OS detected a problem with the system while executing a process owned by SERVER.NLM.  It may be the source of the problem or there may have been a memory corruption.

[ Voor 83% gewijzigd door DGTL_Magician op 12-02-2003 15:01 ]

[BasXcore]

Das je Novell License Service provider;
Ik raad je aan om eerste de server op starten en alle BM gerelateerde dingen uit te #.

Start dan de server op en typ zo vaak als het moet "display servers" in. Wacht tot de complete lijst is opgemaakt. Start daarna DSREPAIR, en check de time synchronisation status. Wacht net zo lang tot je server binnen een sync van max "7" zit.

Start dan de BM op in deze volgorde :
Load BRDSRV.NLM /noload
Load ACLCHECK /S
Load IPXF
? Load Proxy -M
Load AUTHGW (indien van toepassing)
Load VPMASTER (indien van toepassing)

En waarschijnlijk, Voila ..... Zo niet, alle licentie's m.b.t. deze BM verwijderen en opnieuw installeren. En vergeet niet je License te koppelen aan je server!!!

[ Voor 12% gewijzigd door BasXcore op 12-02-2003 15:33 ]

[Arfman]

DGTL_Magician schreef op 12 februari 2003 @ 10:43:
[...]

Zoals ik al zei heb ik de server helemaal opnieuw geinstalleerd. De oude server uit de NDS getrokken, nieuwe objecten (andere naam + server id) aangemaakt, niet eens geconfigureerd. Gelijk hangt ie al bij het starten.

Ja, maar je Access Rules zitten ergens in je NDS (waar weet ik niet, dat weet je zelf probably wel) .. en je NDS is nog steeds dezelfde

[DGTL_Magician]

Arfman schreef op 12 February 2003 @ 16:26:
[...]


Ja, maar je Access Rules zitten ergens in je NDS (waar weet ik niet, dat weet je zelf probably wel) .. en je NDS is nog steeds dezelfde

Dat weet ik, maar de bordermanager objecten e.d. zijn ook opnieuw aangemaakt. Dus ook de Access Rules enzo.

[DGTL_Magician]

BasXcore schreef op 12 februari 2003 @ 15:31:
Das je Novell License Service provider;
Ik raad je aan om eerste de server op starten en alle BM gerelateerde dingen uit te #.

Start dan de server op en typ zo vaak als het moet "display servers" in. Wacht tot de complete lijst is opgemaakt. Start daarna DSREPAIR, en check de time synchronisation status. Wacht net zo lang tot je server binnen een sync van max "7" zit.

Start dan de BM op in deze volgorde :
Load BRDSRV.NLM /noload
Load ACLCHECK /S
Load IPXF
? Load Proxy -M
Load AUTHGW (indien van toepassing)
Load VPMASTER (indien van toepassing)

En waarschijnlijk, Voila ..... Zo niet, alle licentie's m.b.t. deze BM verwijderen en opnieuw installeren. En vergeet niet je License te koppelen aan je server!!!

Allemaal al gedaan. De Timesync is goed. BM start ik om deze reden altijd al handmatig op met een startpx.ncf script. Alsvolgt:

startpx.ncf

code:

?load brdsrv.nlm
?load aclcheck /s /q /p <servernaam>
?load proxy -cc

Ook als ik de server een half uur laat staan dan doet hij exact hetzelfde.

[Verwijderd]

Heb je al geprobeerd om gewoon de CPU Hog timeout hoger te zetten in
Monitor/Server Params/ ?

[DGTL_Magician]

Verwijderd schreef op 12 February 2003 @ 20:57:
Heb je al geprobeerd om gewoon de CPU Hog timeout hoger te zetten in
Monitor/Server Params/ ?

OMG, daar zeg je me wat
Ik ben al zo gewend aan het feit dat Bordermanager 3.5 gewoon brak is als er een config fout is. Morgen gelijk ff proberen. En als dat niet werkt, ff bordermanager in eigen tree hangen, kijken of ie dan ook crashed. Zo ja, zit het in de patch combo die we gebruiken, zo nee is er toch een NDS fout.

[DGTL_Magician]

BasXcore schreef op 12 February 2003 @ 15:31:
Das je Novell License Service provider;
Ik raad je aan om eerste de server op starten en alle BM gerelateerde dingen uit te #.

Start dan de server op en typ zo vaak als het moet "display servers" in. Wacht tot de complete lijst is opgemaakt. Start daarna DSREPAIR, en check de time synchronisation status. Wacht net zo lang tot je server binnen een sync van max "7" zit.

Start dan de BM op in deze volgorde :
Load BRDSRV.NLM /noload
Load ACLCHECK /S
Load IPXF
? Load Proxy -M
Load AUTHGW (indien van toepassing)
Load VPMASTER (indien van toepassing)

En waarschijnlijk, Voila ..... Zo niet, alle licentie's m.b.t. deze BM verwijderen en opnieuw installeren. En vergeet niet je License te koppelen aan je server!!!

Overigens hebben wij een MLA licentie. Deze moet je dus juist _niet_ koppelen aan de server.

[BasXcore]

DGTL_Magician schreef op 13 February 2003 @ 08:53:
[...]

Overigens hebben wij een MLA licentie. Deze moet je dus juist _niet_ koppelen aan de server.

Yes, klopt.

[Verwijderd]

Hoe is het afgelopen met die hog timeout?

[DGTL_Magician]

Verwijderd schreef op 13 februari 2003 @ 13:51:
Hoe is het afgelopen met die hog timeout?

Als ik hem op 1 uur zet, dan hangt de server zonder in een abend te schieten.

Ik ga vanmiddag alle licenties eens verwijderen en de MLA's er opnieuw inhangen. Want als ik de server in een aparte (eigen) tree hang, dan start de proxy wel. Ik heb ook geprobeerd om de server in een andere container te plaatsen, daar ook de licenties bij en ze expliciet aan die ene server hangen, echter nog steeds crash. Ik vermoedt dat de License Service Provider ook omhoog in de tree kijkt.

[Arfman]

Als ik me niet vergips kijkt de LSP helemaal tot aan [Root] voor licenses. Dit kun je instellen, echter daar heb ik geen ervaring mee. Zeker iets om in je achterhoofd te houden als je een 64K WAN hebt o.i.d.

[DGTL_Magician]

Arfman schreef op 13 February 2003 @ 15:08:
Als ik me niet vergips kijkt de LSP helemaal tot aan [Root] voor licenses. Dit kun je instellen, echter daar heb ik geen ervaring mee. Zeker iets om in je achterhoofd te houden als je een 64K WAN hebt o.i.d.

Mjah ons WAN is overal minimaal 384k, dus moet op zich werken. Je kunt het niet echt instellen. Je hebt 2 opties.
1) Tot aan de root van je tree.
2) Tot aan de root van je partitie.
Maar bij ons draait alles dus in 1 partitie (vele malen sneller als meerdere partities voor een aantal kleine locaties.)

[DGTL_Magician]

Ook het vervangen van de licenties heeft niet geholpen. Ik zit er nu echt doorheen. Ik kan er helemaal niet meer bij. Support forums bij Novell komen er ook niet uit.

[Arfman]

Incident openen bij Novell of kan/mag dat niet (meer) ?

[LeNNy]

Het kan ook goed zijn dat de hardware in je server brak is. Heb je dat al gechecked? cpu hog timeout betekend de max. tijd dat de proc met 1 process bezig mag zijn.

Heb je al een desktop pc genomen om te testen of het probleem zich nog steeds voordoet.

[DGTL_Magician]

LeNNy schreef op 14 February 2003 @ 00:31:
Het kan ook goed zijn dat de hardware in je server brak is. Heb je dat al gechecked? cpu hog timeout betekend de max. tijd dat de proc met 1 process bezig mag zijn.

Heb je al een desktop pc genomen om te testen of het probleem zich nog steeds voordoet.

Heb ik al gedaan, en ja ik weet wat CPU Hog timeout betekend. Mijn Desktop PC met 256mb tijdelijk opgewaardeerd tot tijdelijke BM server doet exact hetzelfde. Staat ook al eerder in mijn topic.

[DGTL_Magician]

Arfman schreef op 14 februari 2003 @ 00:12:
Incident openen bij Novell of kan/mag dat niet (meer) ?

Hoe/waar doe ik dat?

[Verwijderd]

If all else fails.. misschien toch maar eens het laatste SP proberen? Misschien dat ie dan tenminste duidelijk maakt waar het probleem zit?

[LeNNy]

DGTL_Magician schreef op 14 February 2003 @ 09:02:
[...]

Hoe/waar doe ik dat?

Ik denk dat het hier:
http://support.novell.com/additional/emea-phone.html

Wel staat.

Succesd iig. Bednkt wel dat een incident wel wat kost. Je kunt een incident bestellen bij azlan (op rekening) of deze via je credit card betalen.

Suc6 iig.

[LePlatDuJour]

Um.. Tenzij de regels veranderd zijn sinds ik er werkte zullen ze er niet eens naar kijken tenzij je de laatste officiele sp op hebt gezet. Nog een laatste strohalm: abend.novell.com

[Loesje]

Een 'incident' kijken ze altijd naar, want daar betaal je voor tenzij het idd. een bug in Netware betreft. Heb je de abend-log al naar Novell gestuurd om te laten bekijken? Dat kan je gratis 4 keer per jaar doen. Ze trekken de log dan door een parser heen die kijkt of ze het probleem al eerder gezien hebben.
Dat zou ik eerst doen.

[DGTL_Magician]

Loesje schreef op 14 februari 2003 @ 16:21:
Een 'incident' kijken ze altijd naar, want daar betaal je voor tenzij het idd. een bug in Netware betreft. Heb je de abend-log al naar Novell gestuurd om te laten bekijken? Dat kan je gratis 4 keer per jaar doen. Ze trekken de log dan door een parser heen die kijkt of ze het probleem al eerder gezien hebben.
Dat zou ik eerst doen.

Mjah, dat is wel een idee inderdaad. Ik heb nu eerst de gehele NDS nagekeken. Elke Replica dragende server een aantal DSRepairs gedraaid totdat alle fouten wegwaren. Licenties laat ik er het hele weekend uit zodat ze over het hele WAN gesynchroniseerd raken. Over het weekend heb ik de server mee naar huis genomen om hem volledig te installeren en te patchen. Maandag hang ik hem dan weer in de tree, en plaats ik de licenties terug. Vervolgens laat ik de master dsrepairen, en updates versturen naar alle replica's.
Daarna start ik de proxy weer, en hoop dat alles goed gaat.

[LePlatDuJour]

Als ik een incident onder ogen kreeg, de abend.log opvroeg en zag dat de server niet gepatched was (althans niet t/m de laatste officiële patch) dan mocht ik formeel niets anders doen dan zeggen: eerst patchen, dan kijken we weer. Niet dat daar niet zo af + toe de hand mee werd gelicht...

Je kunt de abend.log inderdaad opsturen, naar abend.novell.com. Wellicht dat dat helpt.

Wat ik tot dusver gezien heb van je abend.log lijkt op problemen met de licensing objects of services. Ik weet dat er met de oudere SPs wat problemen mee waren, maar helaas heb ik er te weinig verstand van om er iets nuttigs over te zeggen. Bovendien, als je de Novell fora al hebt geprobeerd en geen antwoord hebt gekregen wordt het inderdaad tijd om een incident te openen. Zou wel 'ns 'n NDS dial-in kunnen worden.

Suc6.
Brt

[DGTL_Magician]

LePlatDuJour schreef op 14 February 2003 @ 18:09:
Als ik een incident onder ogen kreeg, de abend.log opvroeg en zag dat de server niet gepatched was (althans niet t/m de laatste officiële patch) dan mocht ik formeel niets anders doen dan zeggen: eerst patchen, dan kijken we weer. Niet dat daar niet zo af + toe de hand mee werd gelicht...

Je kunt de abend.log inderdaad opsturen, naar abend.novell.com. Wellicht dat dat helpt.

Wat ik tot dusver gezien heb van je abend.log lijkt op problemen met de licensing objects of services. Ik weet dat er met de oudere SPs wat problemen mee waren, maar helaas heb ik er te weinig verstand van om er iets nuttigs over te zeggen. Bovendien, als je de Novell fora al hebt geprobeerd en geen antwoord hebt gekregen wordt het inderdaad tijd om een incident te openen. Zou wel 'ns 'n NDS dial-in kunnen worden.

Suc6.
Brt

Mjah, ik ben een redelijke NDS kenner, en dus had ik dat zelf ook al opgemerkt. Alleen een snelle recreate van de licenses hielp niet. Daarom bovenstaande actie maar eens gedaan, ik heb eigenlijk goeie hoop dat BM dan weer gaat draaien.

[Verwijderd]

ff wat tips die mij zo te binnen schieten:

- Doe een 'dsrepair -a' - Advanced - Check external references. Misschien zitten er wel wat objecten vast (obituaries)

- Verwijder alle licentie meuk (ook het NLS_LSP object van de server) en laat de NDS syncen. Check de sync met Dstrace. Na de sync weer een dsrepair en als alles goed is voeg dan de licenties toe en draai op de server 'setupnls', dan wordt het server NLS_LSP object ook opnieuw gemaakt op grond van de zojuist toegevoegde licenties.

- Heb je TCP/IP en IPX of IP only? Bij IP-only check je SLP instellingen.

- Staat er een R/W op de server? Een R/W van de partitie waar de server in zit wil ook wel eens helpen.

[DGTL_Magician]

Verwijderd schreef op 15 februari 2003 @ 19:43:
ff wat tips die mij zo te binnen schieten:

- Doe een 'dsrepair -a' - Advanced - Check external references. Misschien zitten er wel wat objecten vast (obituaries)

- Verwijder alle licentie meuk (ook het NLS_LSP object van de server) en laat de NDS syncen. Check de sync met Dstrace. Na de sync weer een dsrepair en als alles goed is voeg dan de licenties toe en draai op de server 'setupnls', dan wordt het server NLS_LSP object ook opnieuw gemaakt op grond van de zojuist toegevoegde licenties.

- Heb je TCP/IP en IPX of IP only? Bij IP-only check je SLP instellingen.

- Staat er een R/W op de server? Een R/W van de partitie waar de server in zit wil ook wel eens helpen.

't is ei'k best een kunst Zo reageren, zoveel leuke tips, echter ze halen niks uit. Als je mijn hele draadje had gelezen had je gezien dat ik al een andere server had opgezet, dat ik ook de SLP instellingen heb gechecked en ook de Licenties had uitgesloten. Het synchroniseren is waar ik nu op gok, lees enkele posts hierboven.

[Verwijderd]

't is ei'k best een kunst Zo reageren, zoveel leuke tips, echter ze halen niks uit. Als je mijn hele draadje had gelezen had je gezien dat ik al een andere server had opgezet, dat ik ook de SLP instellingen heb gechecked en ook de Licenties had uitgesloten. Het synchroniseren is waar ik nu op gok, lees enkele posts hierboven.

Ik heb nergens gelezen of je in de live omgeving setupnls hebt gedaan, je hebt dan wel licenties uitgesloten maar misschien wel niet goed. Ik heb ook nergens gelezen of je wel of geen obituaries hebt. Vandaar die tips. Maar in ieder geval succes ermee

[DGTL_Magician]

Verwijderd schreef op 16 February 2003 @ 15:56:
[...]


Ik heb nergens gelezen of je in de live omgeving setupnls hebt gedaan, je hebt dan wel licenties uitgesloten maar misschien wel niet goed. Ik heb ook nergens gelezen of je wel of geen obituaries hebt. Vandaar die tips. Maar in ieder geval succes ermee

Mjah, iig de test bak draait ook in de live omgeving (heb ik eerder gezegd) dus daarmee heb ik het uitgesloten

De obituary's had ik idd niet genoemd, wel gechecked.

[DGTL_Magician]

ok..
Dit wordt met de dag vager
Na de ettelijke repairs en wachten op synchronisatie heb ik de server opnieuw ingericht met:
NW51
NW51SP5
eDirectory 8.6.2
eDirectory 8.6.2 sp1
[in de tree gehangen]
Bordermanager 3.5

Vervolgens startte ik de proxy, en weer kwam hij niet voorbij Reading NDS configuration information.
De server blijft echter gewoon draaien en schiet niet in een abend.
Als ik nu probeer DSREPAIR te draaien (na een reboot, dus zonder proxy) blijft DSREPAIR hangen op Waiting for Local DS to release files (oid)

Ook bij het eraftrekken van de NDS blijft de server hangen.
Lijkt mij dus dat mijn NDS probleem is opgelost, maar dat er nog een corrupte Local DS of een andere fout in een NLM aanwezig is.

[LePlatDuJour]

Hmjm. Omschrijf 'ns wat je bedoeld met "opnieuw inrichten"?

[DGTL_Magician]

LePlatDuJour schreef op 18 februari 2003 @ 12:40:
Hmjm. Omschrijf 'ns wat je bedoeld met "opnieuw inrichten"?

Eerder al omschreven. Wissen, en alle software er opnieuw op mikken.

Maar mijn probleem schijnt opgelost te zijn. Na 3 uur kwam Bordermanager op (zonder abend) en hij werkte weer.

[Loesje]

Zou NW51SP5 het dan gefixt hebben, denk je?

[LePlatDuJour]

NDS Janitor langsgeweest? Vreemd hoor.

[Arfman]

Jah, vertel ons eens wat het nu was

[DGTL_Magician]

Neej, SP5 hielp dus ook niet. En ook Bordermanager service packs niet.
Ik heb 2 dagen besteed aan DSrepairs draaien totdat ik overal 0 - 5 fouten had (en das een werk op het aantal locaties dat we hebben ) Voordat ik dit deed heb ik met NDSManager en NWAdmin alles wat te maken heeft/had met Bordermanager weggegooid (server-object, volumes, licenties LDAP, etc.) Daarna rustig uit laten synchroniseren, en tada! Bordermanager startte!

[Arfman]

Dan had je dus best veel fouten in je NDS .. lijkt me ook niet gezond

[DGTL_Magician]

Arfman schreef op 21 February 2003 @ 09:02:
Dan had je dus best veel fouten in je NDS .. lijkt me ook niet gezond

Mjah, ik werk hier net 3 weken ;-)
Ik zie ook dat er hier 16 (!!!!) replica dragende servers staan voor 1 partitie. Ik ben in ieder geval al flink aan het reorganiseren met mijn collega's

offtopic:
Je ondertitel kan weer veranderd worden: HK weer open

[ Voor 16% gewijzigd door DGTL_Magician op 21-02-2003 12:15 ]

[Verwijderd]

>Mjah, ik werk hier net 3 weken

Dan mag je baas blij zijn met jou, denk ik....

[DGTL_Magician]

Verwijderd schreef op 21 February 2003 @ 12:20:
>Mjah, ik werk hier net 3 weken

Dan mag je baas blij zijn met jou, denk ik....

Hoezo?
Ik werkte al 2,5 jaar in Drachten voor dezelfde baas, ben net 3 weken bij de hoofdvestiging in Leeuwarden begonnen om me met het WAN bezig te houden. Van die 3 weken zijn al 7 dagen naar Bordermanager gegaan

[Arfman]

Erm .. 16 REPLICA DRAGENDE SERVERS ?!?! omfg .. werk jij bij de NORAD ofzo ?

Totaal niet nodig (normaal gesproken), het aantal replicadragende servers moet precies genoeg zijn om toch failover te hebben, en niet zoveel dat de hele NDS er 'sloppy' door wordt.

[LePlatDuJour]

16 reps... dat betekent óf 16 wan sites, óf matige partitionering, óf iemand die graag van werk houdt :-)

[DGTL_Magician]

Mjah, er is maar 1 partitie, met 16 replica's.
Het komt door het hoge aantal ( 8 ) locaties, en omdat we ook nog segmenteren in netwerken. Ik heb gekeken en er kunnen sowieso 6 replica's van de Bordermanager en Groupwise servers af. Daarnaast als we in de komende zomervakantie 4 locaties bijeen trekken in een nieuwbouw pand tot 1 komen we in ieder geval weer binnen aanvaardbare normen.

In het verleden is bedacht: beter te veel replica's als te weinig

[ Voor 3% gewijzigd door DGTL_Magician op 21-02-2003 18:10 ]

[DGTL_Magician]

LePlatDuJour schreef op 21 februari 2003 @ 13:30:
16 reps... dat betekent óf 16 wan sites, óf matige partitionering, óf iemand die graag van werk houdt :-)

We hebben meerdere Trees op verschillende WAN locaties. Alleen alles wat binnen vestiging Leeuwarden valt zit in 1 tree, deze tree heeft dus 16 replica's Zie post hierboven wat ik er aan ga doen

't is natuurlijk ook niet gek dat er dan een paar foutjes in de eDirectory komen

[Arfman]

Mwah mah .. opzich zou je niet metene hoeven denken dat door deze partitionering fouten in je NDS/eDir komen. Als het echter over een WAN moet, moet dat WAN ook juist geconfigureerd zijn qua priority en bandbreedte, anders krijg je echt vage sync errors, of duurt het volledig syncen van bv. het backlink process uuuuren ...

[DGTL_Magician]

Arfman schreef op 22 February 2003 @ 15:26:
Mwah mah .. opzich zou je niet metene hoeven denken dat door deze partitionering fouten in je NDS/eDir komen. Als het echter over een WAN moet, moet dat WAN ook juist geconfigureerd zijn qua priority en bandbreedte, anders krijg je echt vage sync errors, of duurt het volledig syncen van bv. het backlink process uuuuren ...

Mjah, daar hoef je je geen zorgen over te maken. QoS is goed geregeld, ook in verband met het Voice over IP systeem wat erover draait. 16 replica's zijn er sowieso te veel.

[Verwijderd]

>Hoezo? Ik werkte al 2,5 jaar in Drachten voor dezelfde baas, ben net 3 weken bij de hoofdvestiging in Leeuwarden begonnen om me met het WAN bezig te houden. Van die 3 weken zijn al 7 dagen naar Bordermanager gegaan

Ah zo.... klonk alsof je er net werkte. Ik bedioelde het absoluut als een zwaar compliment!

[DGTL_Magician]

Verwijderd schreef op 22 February 2003 @ 20:34:
>Hoezo? Ik werkte al 2,5 jaar in Drachten voor dezelfde baas, ben net 3 weken bij de hoofdvestiging in Leeuwarden begonnen om me met het WAN bezig te houden. Van die 3 weken zijn al 7 dagen naar Bordermanager gegaan

Ah zo.... klonk alsof je er net werkte. Ik bedioelde het absoluut als een zwaar compliment!

Ik werk er ook net, promotie
En bedankt voor het compliment. Ik las dat jij ook op een school werkte?

[Verwijderd]

Ja, klopt. Met 400 win2000-clients, netware5.1 als basis op 5 servers. En 3 win2000-servers ernaast. Komen nog 2 win2000-servers erbij. Ook Linux komt er steeds meer bij als lijm-middel.

[DGTL_Magician]

Verwijderd schreef op 23 February 2003 @ 13:11:
Ja, klopt. Met 400 win2000-clients, netware5.1 als basis op 5 servers. En 3 win2000-servers ernaast. Komen nog 2 win2000-servers erbij. Ook Linux komt er steeds meer bij als lijm-middel.

Das best netjes. Wij hebben hier zo'n 700 clients (Win95/98) Netware 5.1 met eDirectory 8.6.2 op zo'n 21 servers. De rest van de 35 servers in totaal draaien Linux en Windows 2000/NT.

[Verwijderd]

Wij doen het beheer met 2 man. Jullie?

[DGTL_Magician]

Verwijderd schreef op 25 February 2003 @ 12:59:
Wij doen het beheer met 2 man. Jullie?

Serverbeheer 2 man.
Ik voor het WAN (we hebben nog meer vestigingen namelijk, met allemaal eigen beheerders.)
1 man voor het LAN, ik ondersteun hem daarin.
Daarnaast hebben we een coordinator en 3 man die zich bezig houden met werkstations en applicaties.

In totaal hebben we een 3000+ werkstations en een stuk of 70 servers verspreid over 4 vestigingen. Die vestigingen hebben allemaal een aantal beheerders. De meeste vestigingen zijn ook nog uitgesmeerd over meerdere locaties. Zo heeft onze vestiging 7 locaties.

[Verwijderd]

Hoppla... heftig....