Bei Word gibt es im Netzwerk immer wieder Probleme mit temporären Dateien.
Für Winword 2.0 muß man den Pfad in der WIN.INI setzen:
[Microsoft Word 2.0] DOC-path=F:\DOKU\DOC AUTOSAVE-path=F:\irgendwo INI-path=W:\WINWORD programdir=W:\WINWORD
In WinWord 6.0 können diese Einstellungen alle in EXTRAS/OPTIONEN/DATEIABLAGE getätigt werden.
Außerdem sollten auch im Umgebungsbereich (SET) die Verzeichnisse, auf die TEMP und TMP zeigen, existieren und die richtigen Rechte haben.
Unsere Kunden bekommen ein Windows auf's Netz - im Verzeichnis SYS:WIN31 (mit einem Search-Map versehen) wird mit SETUP /A alles installiert. Jeder Benutzer hat ein User-Verzeichnis (i. d. Regel mit MAP ROOT G:=SYS:USER/%LOGIN_NAME% gemappt). Hier richte ich mir in meinem eigenen G:-Laufwerk mit SETUP /N die erste Win-Version im Verzeichnis G:\WIN31 ein. Mein Ziel bei Win-Installationen ist immer folgendes: der Anwender soll zwar alles Nötige zur Verfügung gestellt bekommen, aber er soll so gut wie nichts verstellen können. Auf die Weise kann er davon ausgehen, daß er beim nächsten Start von Windows alle Fenster so vorfindet, wie er es gewohnt ist - wenn man weiß, welches Unheil unerfahrene "Maus-Klicker und -Schieber" so auf dem Desktop anrichten können, ist das immer gut zu wissen.
Jetzt installiere ich erstmal alle notwendigen Grafiktreiber. Auch werden alle Gruppen angelegt, die nötig sind. So schmeiße ich aus der Hauptgruppe fast alles 'raus, lege mir eine Gruppe "Supervisor" an und erstelle eine Gruppe "Programme", in die später alle Programme reinkommen.
Ich lege auf dem Server ein Verzeichnis SYS:INI an. In diesem Verzeichnis wird für jeden Grafiktreibertyp ein Verzeichnis angelegt. Bspw.: SS8X6 für SpeedSTAR 800x600 usw. In diese Verzeichnisse (darauf haben alle Lesezugriff), kommen die gemeinsam genutzten Gruppen-Dateien (*.GRP). Im Verzeichnis INI lege ich für jeden Benutzer eine PROGMAN.INI als %LOGIN_NAME%.PRG an.
Im Login-Script wird jetzt für jede Station - abhängig von der Grafikkarte - ein MAP ROOT J:=SYS:INI\<entsprechendes Verzeichnis> mit anschließendem COPY J:\*.GRP G:\WIN31 gemacht. In den *.PRG-Dateien in SYS:INI kann man wunderbar editieren, welcher Benutzer welche Gruppe sehen soll und wo die liegen soll (die PRG-Datei holt er sich beim Aufruf von Windows). Jeder Benutzer hat in G:\WIN31 eine AUTOSTART- und eine PRIVAT-Gruppe. Alle anderen kommen immer wieder von J: - so ist sichergestellt, daß auch die Gruppen immer gleich bleiben.
Wozu die GRP's für jede Grafikkarte? Weil Win sonst jedesmal die GRP-Dateien an den jeweiligen Treiber anpassen muß - das kostet Zeit.
Jetzt kommt die WIN.INI aus meinem Verzeichnis auch ins INI-Verzeichnis. Die SYSTEM.INI kommt als %STATION%.SYS ins INI-Verzeichnis, wobei im LOGIN-Script für jede Station mit SET STATION=P_STATION <<4 eine eindeutige Veriable gesetzt wurde (die enthält die letzten 8 Ziffern der Ethernet-ID). Die SPART.PAR-Datei (die den Verweis auf die stationsabhängige Auslagerungsdatei auf C: enthält, kommt ebenfalls als %STATION%.PAR ins INI-Verzeichnis.
Im INI-Verzeichnis liegen also demnach:
Die PROGMAN.INI für jeden Benutzer Die SYSTEM.INI für jede Station Die SPART.PAR für jede Station Die WIN.INI des Supervisors.
Jetzt wird erstmal der ganze Kram aus meinem G:\WIN31 für jeden Benutzer kopiert - jeder erhält also ein G:\WIN31. Natürlich ohne meine eigenen Gruppen. Nur mit der leeren AUTOSTART und PRIVAT-Gruppe.
Ab hier gibt es zwei Möglichkeiten: entweder legt man auch für jeden Benutzer eine eigene WIN.INI in INI ab (einfach...), oder man erzeugt eine, in der beim Start von Windows einige Stellen für den jeweiligen Benutzer ausgetauscht werden. Im ersteren Fall hat man den Nachteil, daß es Zeit kostet, Änderungen an den INI-Dateien für alle 120 Benutzer durchzuführen. Im letzteren Fall hat man das Problem, das es irre viel Gefummel ist, bis es läuft. Danach ist's aber sehr einfach, kurz mal was an der WIN.INI zu machen...
Interessant wären die Batches, mit denen Windows aufgerufen
wird.
Wenn man obiges gelesen hat, versteht man vielleicht auch dieses (die
umfangreiche Version mit nur einer WIN.INI):
@echo off cls echo. ncopy H:\INI\WIN.INI I:\WIN31\WIN.INI >nul rem hier wird die WINI.INI nur erstmal kopiert ncopy H:\INI\%LOGIN_NAME%.PRG I:\WIN31\PROGMAN.INI >nul rem die eigene PROGMAN.INI ncopy H:\INI\%STATION%.SYS I:\WIN31\SYSTEM.INI >nul rem die stationsabhängige SYSTEM.INI ncopy H:\INI\%STATION%.PAR I:\WIN31\SPART.PAR >nul rem die stationsabhängige SPART.PAR ncopy H:\INI\%STATION%.CTR I:\WIN31\CONTROL.INI >nul rem auch die mußte ich bei einem Kunden variabel gestalten, rem da die Grafiktreiber unterschiedliche Farben machten ncopy J:\*.GRP I:\WIN31 >nul rem da kommen die Gruppen flag I:\WIN31\SPART.PAR RO >nul rem noch ein Schreibschutz drauf. Die SPART.PAR muß übrigens rem auf jedem PC einmalig unter Windows erstellt werden I: rem hier ist das Userverzeichnis I: und nicht G: wie oben if %STATION% == 12345678 goto WS01Config if %STATION% == yyyyyyyy goto WS02Config .... if %STATION% == xxxxxxxx goto WS07Config if %STATION% == zzzzzzzz goto WS08Config rem je nach Station gehts jetzt weiter rem (die Env.-Var %STATION% wird im LOGIN-Script gesetzt). :WS01Config rem USERNAME rem damit man später noch weiß, wer an dem Platz sitzt cd \win31 rem ins eigene Userverzeichnis wechseln QR Commit0 device= win.in* >nul QR Commit1 Panasonic win.in* >nul QR Commit2 KX-P4450i,PCL4X,LPT1: win.in* >nul QR Anschluss LPT1 win.in* >nul rem ich habe in der WIN.INI die Variablen "Commit0", "Commit1", rem "Commit2" und "Anschluss" gesetzt. Die werden vom Programm rem QR (ein Stringtauscher - mehr dazu weiter unten!) übersetzt in rem das, was hinter der Varible steht, also "Commit1" -> "Panasonic" rem - womit ich für jeden Benutzer unterschiedliche rem Druckervoreinstellungen machen kann. QR Col1 64 win.in* >nul QR Col2 128 win.in* >nul QR Col3 255 win.in* >nul QR Col4 224 win.in* >nul rem Hier noch ein paar Farbwerte... cd \ goto WindowsStart :WindowsStart rem Hier geht's dann los! win31 %1 rem Windows starten (die WIN.COM im userverzeichnis heißt WIN31.COM!) cls echo. i: cd\win31 copy SYSTEM.INI I:\WIN31\INI\%STATION%SYS.INI >nul copy CONTROL.INI I:\WIN31\INI\%STATION%CTR.INI >nul copy WIN.INI I:\WIN31\INI\%LOGIN_NAME%.INI >nul copy PROGMAN.INI I:\WIN31\INI\%LOGIN_NAME%.PRG >nul rem Damit man zur Not Änderungen an den INI-Dateien nicht einfach rem durch einen Windows-Neustart überschreibt... Da muß man aufpassen! dir J:\*.GRP /B >DELETE.IT xdel @DELETE.IT /N >nul rem Damit werden wieder alle GRP-Dateien gelöscht. del DELETE.IT >nul del SYSTEM.INI >nul del WIN.INI >nul del CONTROL.INI >nul del PROGMAN.INI >nul rem Damit ist das Verzeichnis beim User wieder total jungfräulich! cd.. flag I:\WIN31\SPART.PAR RW >nul del I:\WIN31\SPART.PAR >nul echo.
Die andere Veriante (mit vielen WIN.INI's) sähe etwa so aus:
@echo off cls echo Der Start von Windows 3.1 wird vorbereitet... echo. flag g:\windows\spart.par rw >nul ncopy f:\win31\ini\%LOGIN_NAME%.ini g:\windows\win.ini >nul ncopy f:\win31\ini\%LOGIN_NAME%.prg g:\windows\progman.ini >nul ncopy f:\win31\ini\%P_STATION%.ini g:\windows\system.ini >nul ncopy f:\win31\ini\%P_STATION%.par g:\windows\spart.par >nul ncopy j:\*.grp g:\windows >nul flag g:\windows\spart.par ro >nul win31 %1 cls echo Windows 3.1 wird beendet... echo. ncopy g:\windows\system.ini g:\windows\%P_STATION%.old >nul ncopy g:\windows\win.ini g:\windows\%LOGIN_NAME%.old >nul echo.
Windows kopiert bei Netzwerkinstallationen von Windows 3.x bei herkömmlicher Installation zwar die (Video-)Treiber, aber packt sie nicht aus. Windows kann diesen gepackten Treiber natürlich nicht laden und meldet, daß die Datei beschädigt sei.
Abhilfe:
Mit dem Utility EXPAND, das bei Windows dabei sein sollte, die Treiber von Diskette in ein temp Verzeichniss expandieren/kopieren. Rechte auf das gemeinsame Windows Verzeichnis bekommen und die Treiber reinkopieren. Die Datei OEMSETUP.INF in OEMx.INF, wobei x eine Zahl ist, umbenennen und ebenfalls reinkopieren.
Jetzt einfach einen OEM Treiber installieren und als Quelle das gemeinsame Windowsverzeichniss angeben. Damit klappt es.
Eigentlich ist Win (3.1 oder WfW 3.11) unter Novell kein Problem, man
muß sich nur vorher im klaren sein, was man auf dem Server und was an
der Station vorhanden sein soll.
Sollen die Nutzer an verschiedenen Stationen arbeiten können,
braucht Windows vom lokalen Rechner die entsprechenden Hardware-Infos (i.A.
System.Ini). Auf der anderen Seite sollten dann die User-abhängigen
Daten (so ziemlich alle anderen Inis, Group-Dateien usw.) nur für den
jeweiligen Nutzer verwendbar sein.
Mein Vorschlag wäre ein Server-basierter Betrieb mit ca. 100kB lokal, je ca. 1 MB auf dem User-Verzeichnis des Servers (pro User) und ca. 40-50 MB je nach Anzahl der Workstations und Konfigurationen (alle Treiber müssen dann zentral vorhanden sein) auf einem zentralen Serververzeichnis.
Nachteil:
geringfügig langsamer als bei Betrieb von der lokalen Platte (bei
486er egal), relativ großer Platzbedarf auf dem Server und ohne
zusätzlichen Aufwand kann der gleiche User sich mit Windows nur an einer
Station einloggen.
Vorteil:
Zentrale Wartung der Treiberdateien (OEMSETUP.INF muß allerdings
bearbeitet werden), zentrale Datensicherung, ausreichende Transparenz
für den Standard-User, zentrales Backup.
Wenn unter Windows 3.1x das Netzwerk (Novell Shell 3.26 und höher bzw. Netware 3.xx) im Windows-Setup nicht eingetragen ist oder uralte Treiber verwendet werden, sind in einen DOS-Task alle Environment-Variablen verschwunden (also z.b PATH etc.).
Neue Treiber findet man unter NWDLLx.* und WINDRx.* im Internet oder bekannten Mailboxen, zur Not tun es auch die Versionen aus WINUP9.
1. Alle Win-Disketten wie im Handbuch beschrieben in ein Verzeichnis F:\WIN3x expandiert, alle Files auf RO gesetzt und das Verzeichnis im Login-Script mit MAP S1:=F:\WIN3x gemappt.
2. Für jeden Benutzer ein Homeverzeichnis F:\HOME\benutzername gesetzt und diese im Login-Script mit MAP ROOT G:=SYS:HOME\%LOGIN_NAME gemappt.
3. Die einzelnen Windows-Versionen mit SETUP USER installiert. Und zwar im Verzeichnis \HOME\benutzername\WINDOWS. Auf dieses Verzeichnis habe ich einen Pfad S2:=G:\WINDOWS gesetzt.
4. Ein Verzeichnis F:\USER angelegt. In dieses Verzeichnis kommen gesammelt die WIN.INI's aller Benutzer, jeweils mit dem Namen %LOGIN_NAME.INI versehen. Alle Benutzer haben nur Leserechte in diesem Verzeichnis. Im Login-Script DOS SET LOGIN = %LOGIN_NAME gesetzt. Wichtig: LOGIN_NAME darf max. 8 Zeichen lang sein, sonst muß der Name im Login-Script gekürzt werden (so nach dem Motto
IF LOGIN_NAME = "WAHNSINNSKOMIKER" DOS SET LOGIN = "KOMIKER" END
5. Ein Verzeichnis F:\STATION angelegt. Hier kommen die stationsabhängigen SYSTEM.INI's rein. Jeweils mit dem Namen %STATION_ID.INI versehen. Im Login-Script setze ich eine Variable über z. B.
IF P_STATION == "000884654673" THEN DOS SET STATION = "84654673" END
Über diese Variable kann später die entsprechende SYSTEM.INI beim Start von Windows aus F:\STATION geholt werden.
6. Auf jeder Station eine Swap-Datei von 10000 KB eingerichtet. Die SPART.PAR im Windows-Verzeichnis in "stationsnummer.PAR" umbenannt und dann auch ins F:\STATION kopiert. Da die schreibgeschützt im Windows-Verz. liegt, muß man damit etwas aufpassen.
7. Eine Batchdatei WINX.BAT geschrieben:
rem Die wichtigen Dateien holen ncopy F:\USER\%LOGIN%.INI G:\WINDOWS\WIN.INI >nul ncopy F:\STATION\%STATION%.INI G:\WINDOWS\SYSTEM.INI >nul flag G:\WINDOWS\SPART.PAR RW ncopy F:\STATION\%STATION%.INI G:\WINDOWS\SPART.PAR >nul flag G:\WINDOWS\SPART.PAR RO rem Windows starten win /3 rem Sicherheitshalber nach dem Beenden von Windows die jetzt eventl. rem geänderten INI's retten ncopy G:\WINDOWS\WIN.INI G:\WINDOWS\WIN.OLD ncopy G:\WINDOWS\SYSTEM.INI G:\WINDOWS\SYSTEM.OLD
8. Im Verzeichnis STATION habe ich noch für jede Grafikkarte/Auflösung ein Verzeichnis \GROUPS angelegt (also GROUPS1 für die Benutzer der SpeedSTAR in 800x600, GROUPS2 für SpeedSTAR in 600x400 und GROUPS3 für Paradis mit 800x600).
In diesen Verzeichnissen liegen die Gruppendatei der Gruppen, die von den Benutzern nicht geändert werden dürfen. Hier kommt nur der Supervisor ran.
9. Im Login-Script je nach Grafikkarte der Station ein Verzeichnis H:=SYS:\STATION\GROUPSx gemappt. Dann muß in der PROGMAN.INI jedes Benutzers der Pfad auf diese Gruppen natürlich noch per Hand gesetzt werden. Dieser ist dann aber unabhängig von der jeweiligen Grafikkarte, da die Gruppen über das gemappt Laufwerk H: gefunden werden. Aufpassen bei der Gruppe Zubehör. Novell hat Umlaute ja nicht so gerne -> Umbenennen!
Der Vorteil, Gruppen, INI's etc. in jeweils einem Verzeichnis zentral zu lagern liegt auf der Hand: Änderungen, die überall durchzuführen sind, werden etwas vereinfacht, da man nicht durch 1000 Verzeichnisse huschen muß. Man kann dann ganz gut in allen INI's die Änderungen mit einem Editor durchführen.
Ich setze im System-Login-Script oder in der AUTOEXEC.BAT die DOS- Umgebungsvariable WINPMT auf [WIN] $P$G. Wenn ich unter Windows im DOS-Vollbild arbeite, erscheint dann [WIN] F:\> als Prompt.
Dadurch vergesse ich nicht, daß Windows noch im Hintergrund abreitet.
Falls beim Starten von Windows 3.1x ein oder mehrere Fenster mit der Meldung "Restoring irgendwelche Printdevices" erscheint, sind permanente Captures (oder Mappings) mit NWUser.Exe oder dem Dateimanager eingetragen worden. Da diese Mappings die normalen Mappings aus dem Login Script überschreiben, sollte man sie löschen und Laufwerke einheitlich in dem Login Script mappen.
Du kannst sie mit dem NWUser oder in der Win.Ini im Abschnitt [Network] löschen.
In der PROGMAN.INI kann der Abschnitt [restrictions] hinzugefügt werden.
[restrictions] NoRun= NoClose= NoSaveSettings= NoFileMenu= EditLevel=
NoRun=1 schaltet den "Ausführen"-Befehl im Datei-Menue ab. Der "Ausführen" Befehl erscheint grau (d.h. nicht aufrufbar) im Datei-Menue und der Anwender kann vom Programmmanager nur Programme starten, die als Symbole in den Gruppen erscheinen.
NoClose=1 schaltet den "Windows beenden"-Befehl im Datei-Menue ab. Der Anwender kann den Programmmanager nicht über das Datei-Menue oder über das System-Menue oder mit ALT+F4 verlassen (der "Windows beenden"-Befehl und der "Schließen"- Befehl sind grau.
NoSaveSettings=1 schaltet den "Einstellungen beim Beenden speichern" Befehl im Optionen Menue ab. Der "Einstellungen beim Beenden speichern" Befehl ist im Optionen-Menue grau und alle Änderungen, die der Anwender bei der Darstellung von Windows und bei den Symbolen macht, werden nicht gespeichert. Diese Einstellung überschreibt die SaveSettings= Einstellung im [Settings] Abschnitt der PROGMAN.INI Datei.
NoFileMenu=1 entfernt das Datei-Menue aus dem Programmmanager. Alle Befehle dieses Menues sind nicht mehr verfügbar. Die Anwender können nur die Anwendungen aus den Gruppen mit Doppelklicken oder der EINGABETASTE starten. Wenn Sie den Befehl "Windows beenden" nicht zusätzlich abgeschaltet haben (NoClose=1), können die Anwender Windows über das System-Menue und über ALT+F4 immer noch verlassen.
EditLevel=n aktiviert Einschränkungen, was die Anwender im Programmmanager verändern dürfen. Sie können einen der folgenden Werte für n bestimmen:
erlaubt dem Anwender, alle Änderungen zu machen (Dies ist der Standardwert).
verhindert, daß der Anwender Gruppen erzeugt, löscht oder umbenennt. Bei dieser Einstellung sind die "Neu", "Verschieben", "Kopieren" und "Löschen" Befehle im Datei-Menue nicht verfügbar, wenn eine Gruppe angewählt ist.
enthält alle Einschränkungen von EditLevel=1 und hindert den Anwender zusätzlich Programmsymbole zu erstellen oder zu löschen. Bei dieser Einstellung sind die "Neu", "Verschieben", "Kopieren" und "Löschen" Befehle im Datei-Menue überhaupt nicht verfügbar.
enthält alle Einschränkungen von EditLevel=2 und hindert den Anwender zusätzlich die Befehlszeile der Programme zu ändern. Bei dieser Einstellung kann der Text in "Befehlszeile" im Dialogfeld "Programmeigenschaften" nicht geändert werden.
enthält alle Einschränkungen von EditLevel=3 und hindert den Anwender zusätzlich irgendeine Information zu den Programmsymbolen zu ändern. Bei dieser Einstellung kann keiner der Bereiche im Dialogfeld "Programmeigenschaften" geändert werden. Der Anwender kann das Dialogfeld sehen, aber alle Bereiche erscheinen grau.
Um die Befehle wieder einzuschalten oder die EditLevel=Einschränkungen wieder rückgängig zu machen, entfernen Sie die entsprechende Einstellung aus der PROGMAN.INI Datei oder setzen Sie den Wert auf 0.
Quelle: Microsoft Corporation, Microsoft Windows, Seiten: 227-229, Die technische Referenz
Datenbankanwendungen, die die Jet-Engine benutzen, wie z.B. Access 1.1 und 2.0 und sehr viele Record Locks produzieren, bringen einen Netware 3.11 Fileserver zum Abend mit der Meldung:
Station 1: Record Lock Treshold exceeded
Das ist vor allem bei Access ein bekanntes Problem, aber auch durchaus mit anderen Programmen denkbar. Dafür gibt es folgende Lösungen:
Folgende Settings auf maximale Werte stellen:
set maximum record locks per connection = 10.000
set maximum file locks per connection = 1.000
set maximum record locks = 20.000
set maximum file locks = 100.000
Den Fix ttsfix.nlm aus 311PTx.EXE bzw. einspielen. Dieser Fix schaltet einen Trigger ab, der bei einer Überschreitung der maximalen Locks pro Connection den Server mit einem Abend abwürgt.
Beide Maßnahmen sichern den NW 3.11 Server vor einem Absturz. Bei NW 3.12 sollten diese Werte zwar auch hochgesetzt werden, Abstürze sollte es dort aber keine geben, der TTSFIX ist dort schon standardmäßig eingebaut.
Ein Win95 PC kann (in Anwesenheit eines echten Novell Servers) einen Novell Server emulieren. Der Win95 PC taucht dann mit SLIST in der Serverliste auf und man kann sich sogar einloggen und sich Laufwerke und CDROM des Win95 PC mappen - ganz normal, wie unter echtem Netware 3.1x. Das ganze basiert auf einem Novell Server 3.1x oder 4.x mit Bindery Emulation, der im Netz verfügbar sein muß. Von diesem Server liest der Win95 PC die User aus der Bindery ein. Für diese User kann man dann getrennt festlegen, was die auf dem Win95 PC nutzen dürfen und was nicht.
Man nehme:
Unter Netzwerk wählt man hinzufügen und wählt
"DIENST" - "DATEI UND DRUCKERFREIGABE FÜR NETWARE
NETZE". Unter Eigenschaften muß nun noch die "SAP ANZEIGE"
auf AKTIVIERT gestellt werden, sonst taucht der neue Server nicht auf. Der
Computername, den man eingetragen hatte, wird übrigens der Servername.
Unter ZUGRIFFSSTEUERUNG muß man nun noch "ZUGRIFFSSTEUERUNG AUF
BENUTZEREBENE" aktivieren. Jetzt den Novell Server angeben, dessen
Userdatenbank verwendet werden soll.
Das IPX/SPX von Microsoft muß natürlich installiert sein und
die Kommunikation zu anderen WfW Clients geht dabei verloren.
Die Unterstützung von remote-bootenden Workstations über Boot-ROM und Boot-Image ist in Win95 integriert. Auf der Win95-CD ist unter \admin\reskit\helpfile das file Win95rk.hlp zu finden. Hier kannst Du recht detailliert auch Anweisungen zur Generierung eines entsprechenden Boot-Images für Netware entnehmen.
Bei Windows 95 wird zum Empfang von Messages, die z.B. per SEND Befehl nicht mehr NWPOPUP wie bei Windows 3.1x verwendet, sondern WINPOPUP.EXE (aus dem Windows-Verzeichnis) gestartet (am besten im Startup-Verzeichnis)
Windows 3.1x Installation auf einer Diskless Workstation:
Da die EMM386.EXE beim Start von Windows 3.1x nachgeladen wird und das "Bootlaufwerk" bei einer Diskless Workstation zu diesem Zeitpunkt nicht mehr aktiv ist, muß man schon beim Booten angeben, wo zu einem späteren Zeitpunkt nach dem EMM386 gesucht werden soll:
CONFIG.SYS:
DEVICE=EMM386.EXE [weitere_Parameter] Y=f:\bla\bla\EMM386.EXE
Bei Benutzung von QEMM gilt das gleiche, da hier immer nach VIDRAM.VXD gefragt wird:
CONFIG.SYS:
DEVICE=QEMM.EXE [weitere_Parameter] VXDDIR=<netzwerkverzeichnis>
<netzwerkverzeichnis> ist das Verzeichnis, in dem die *.vxd Dateien stehen.
In allen Textfiles und im ResKit zur Win95-CD ist die Rede davon, das server-basierte Setup nicht wie bisher mit SETUP /A, sondern mit NETSETUP.EXE aufzurufen.
Bei OEM-Versionen (meistens mit neuen Rechnern ausgeliefert) ist dieses Programm nicht dabei. Netsetup ist nur auf einer Vollversion bzw. bei einem Update dabei! Dort liegt die Datei unter \Admin\Nettools\Netsetup.exe
Wenn man sich unter WIN95 am Server anmeldet, öffnet sich evtl. ein (oder mehrere) Fenster, die man jedesmal mit ALT-F4 schließen muß, damit es weiter geht.
Das ist jedoch ein Windows "Problem" und hat mit Novell eigentlich nichts zu tun.
Wenn das Fenster wiedermal auf dem Schirm zu sehen ist, dann schließe es nicht, klicke es mit der rechten Maus-Taste an, wähle den Menue-Punkt 'Eigenschaften'. Dort kannst Du u.a. einstellen, daß das Fenster automatisch geschlossen werden soll.
Es ist einem im Netz eingeloggten User nicht mehr möglich,
seinen lokal angeschlossenen Drucker mit Windows-Software zu benutzen
(Druckausgaben von DOS-Boxen funktionieren seltsamerweise).
Das gleiche Problem hatten wir auch. Bei uns lag die Lösung nach
langem Probieren daran, daß in der Config.Sys der EMM386.EXE nicht
eingetragen war. Als ich den eingetragen hatte, funktionierte das Drucken.
Grund: !???
Probleme beim Drucken von Rechnern unter Win95 und dem Novell oder MS 32bit-Client:
Die DOS-Umgebungsvariablen TEMP und TMP dürfen keinesfalls innerhalb eines innerhalb von Windows gestarteten Login-Scripts oder Batchfiles gesetzt bzw. verändert werden; tut man es doch, dann weiß Win95 offenbar nicht mehr, wo es bei der Erstellung der Druckdaten diese zwischenlagern soll... je nachdem wie es der Zufall dann so will, findet Windows seine Sachen wieder oder auch nicht...
Beim Login unter dem VLM-Client wird der Login-Script ja noch im DOS-Abschnitt des Windows-Starts, also vor dem Hochfahren der Windows-Oberfläche ausgeführt, so daß die o.g. Probleme nicht auftreten. Mit den 32bit-Clients jedoch läuft auch die Abarbeitung des Login-Scripts bereits innerhalb der 32bit-Umgebung.
Also: Falls es überhaupt notwendig sein sollte, TEMP oder TMP zu ändern, dann sollte das sicherheitshalber innerhalb der AUTOEXEC.BAT geschehen.
(Bei Verwendung des Novell 16bit VLM-Clients trat dieser seltsame Effekt übrigens nicht auf.)
Windows 3.1x NetWare Troubleshooting Tips
In the Windows SYSTEM.INI file, verify the following settings:
Under the [boot] section header:
network.drv=netware.drv
Under the [386Enh] section header:
network=*vnetbios,vnetware.386,vipx.386
Update to the latest NetWare drivers, a minimum level of IPXODI v2.10 and NETX v3.32 or VLM v1.10 for proper support of the Windows 3.1 environment.
Check for duplicate copies of the NWPOPUP.EXE, VNETWARE.386, VIPX.386 and NETWARE.DRV files.
Verify that the NETWARE.DRV file is at least 125,000 bytes in size.
Use WINSTART.BAT with care. There is a bug with WINSTART.BAT processing
under Windows 3.1 on some PCs, which can cause Windows to hang-up when
exiting.
In your NET.CFG (or SHELL.CFG) file, be sure to allocate plenty of file handles. FILE HANDLES=80 is a recommended minimum.
Novell recommends including the statement "TimerCriticalSection=10000" under the [386Enh] section header of SYSTEM.INI when using VIPX.386 v1.15 or higher.
Compiled by Brett Warthen (Infinite Technologies) Fourth Edition: 8.7.94
NEU!
Normalerweise fragt ein Windows 95 Rechner in einem Netzwerk beim Starten immer nach einem Paßwort. Es geht aber auch anders:
Win 95 mit Netzwerk ganz normal so einrichten, daß das Einloggen über den Dialog geht, bei dem man dann nur den OK Button drücken muß. Weder für Win95 noch für Netware darf für den aktuellen User ein Paßwort verlangt werden.
anmelden
Ins Netzwerksetup von Win95 gehen und für die primäre Anmeldung statt des Client für Netware Netze die Windows 95 Anmeldung aktivieren.
fertig. Shutdown, rebooten, zuschauen, Explorer zum Test öffnen.
Mit dem Microsoft Client für Netware Netze funktioniert das, mit dem Novell Client32 allerdings nicht!
Copyright © by Stefan Braunstein (sbraunst@POBoxes.com)
Letzte Aktualisierung am 1. Dezember 1997