Letzte Änderung: 17.9.98 von B. Tritsch
Mit dem LAN Server 2.0 und dem zugehörigen OS/2-Server wurde das Dateisystem HPFS386 eingeführt. Es enthielt einige Verbesserungen im Gegensatz zum normalen OS/2 High Performance File System (HPFS), wie z.B. den Ablauf auf der selben Ebene wie der Betriebssystemkern oder der Einsatz von Access Control Lists (ACLs) für zusätzliche Dateiattribute im Sicherheitsbereich. HPFS386 wird von Windows NT nicht unterstützt, wodurch ein paralleler Betrieb der beiden Betriebssysteme mit gemeinsamer Datennutzung auf einem multibootfähigen Rechner nicht möglich ist. Auch HPFS wird ab der NT-Version 4.0 nicht mehr offiziell von Microsoft unterstützt.
Die Integration der LAN Server-Funktionalitäten wurden bei den Microsoft-Systemen nicht mehr weiterentwickelt, nachdem sie kompatibel zur OS/2-Version 1.3 waren. Dennoch sind die gemeinsamen Ursprünge an einigen Stellen noch erkennbar. Die wichtigste Übereinstimmung besteht in dem verwendeten Protokoll für die Kommunikation zwischen Client und Server, den Server Message Blocks (SMB). Dadurch kann von Windows 95 oder NT-Clients auf Ressourcen eines OS/2-Servers und umgekehrt von OS/2-Clients auf exportierte Verzeichnisse eines NT-Servers zugegriffen werden. Beide Systemwelten nutzen dabei das NetBIOS-Interface, das eine einfache Programmierschnittstelle für Netzwerkapplikationen bereitstellt. Als Transportprotokoll wurde bis vor kurzem NetBEUI verwendet, das aber gerade sowohl bei IBM als auch bei Microsoft vollständig von TCP/IP abgelöst wird.
Leider sind die unterschiedlich gewählte Namenskonventionen bei den beiden Systemen sehr verwirrend. Microsoft spricht immer korrekt von TCP/IP und NetBEUI, während IBM die Begriffe TCP/IP, NetBIOS über TCP/IP und NetBIOS verwendet. NetBIOS über TCP/IP muß dabei zusätzlich zu TCP/IP installiert werden, um den vollen Funktionalitätenumfang für NetBIOS-Anwendungen zu erhalten. Bei NetBIOS als angebliches Protokoll wird in Wirklichkeit NetBEUI installiert. Diese Bezeichnung ist jedoch abträglich für das systemübergreifende Verständnis der Administratoren.
Abbildung: OS/2-Ressourcen
Um ein Netzwerk mit Rechnern zu strukturieren, benutzen sowohl OS/2 als auch Windows NT das Konzept der Domänen. Damit werden zentral Anmeldevorgänge überprüft und Benutzerrechte vergeben. Ein wichtiger Unterschied ist jedoch die Möglichkeit der OS/2-Domänen, Aliase für Netzwerkressourcen (d.h. exportierte Verzeichnisse eines Servers, Drucker und speziell bei OS/2 auch serielle Schnittstellen) zu verwalten. Diese Aliasnamen sind dann nicht mehr direkt mit einem dedizierten Server verbunden, sondern können auch im Bezug auf ihren Zielpunkt geändert werden. Wechselt also die physikalische Position der Ressource (wird z.B. ein Drucker an einen anderen Server angeschlossen), muß nur die Zuordnung des Alias auf dem Server geändert werden. Alle Clients können sofort weiter mit dieser Ressource arbeiten.
Die Zuordnung des Aliasnamen zu einem Server wird von den Domänen-Steuereinheiten (= IBM-Wort für Domäne-Controller) übernommen. Ein normaler Share dagegen, wie er unter Windows NT üblich ist (und auch von OS/2 unterstützt wird), hat immer eine direkte Kopplung zu einem zugehörigen Server-Namen. Ein weiterer wichtiger Unterschied zwischen den Systemen ist, daß Shares unter OS/2 immer nur bis zum nächsten Neustart bestehen, während sie bei Windows NT wieder so eingerichtet werden, wie sie beim Herunterfahren des Systems bestanden haben.
Abbildung: OS/2-Administrationswerkzeug zur Verwaltung von Aliases
In einer OS/2-Domäne kann für jedes Benutzerkonto festgelegt werden, welche Ressourcen es beim Anmelden zugeordnet bekommt. Sogar die Festlegung der lokalen Laufwerksbuchstaben kann individuell angepaßt werden. Dadurch ist es möglich, daß Pfadnamen auch beim Anmelden auf verschiedenen Rechnern immer vollkommen identisch bleiben. Diese Funktionalitäten werden unter Windows NT besonders bei der unternehmensweiten Installation von Applikationen schmerzlich vermißt, da sie homogene Bezeichnungen für alle betroffenen Pfade erlauben. Dies gilt sowohl für Anwendungen, die lokal auf dem Client als auch zentral zur allgemeinen Verfügung auf einem Server installiert werden. Um diese und auch andere Funktionalitäten - wie das Browsing von OS/2-Ressourcen - dennoch auf NT-Clients verfügbar zu machen, die sich an einem OS/2-Server anmelden, können IBM-Komponenten installiert werden, die eine Windows NT Workstation entsprechend modifizieren.Die Einbindung eines OS/2-Clients in eine NT-Domäne ist noch problematischer, da schon die Ansicht der Ressourcen mit dem Browser-Mechanismus nicht funktioniert. Gibt man jedoch die Ressourcennamen von Hand ein, kann eine Verbindung hergestellt werden. Hierzu müssen die Namen allerdings bekannt sein.
Vollkommen inkompatibel sind die beiden Systeme im Bezug auf die technische Umsetzung des Domänekonzepts. Es ist keine Kopplung von "gemischten" Domäne-Controllers im Bezug auf Ressourcen- und Benutzerdefinitionen möglich. Auch kann kein einfacher NT-Server in einer OS/2-Domäne und ein OS/2-Server nicht in einer NT-Domäne betrieben werden. In beiden Fällen findet der "Fremd"-Server nicht den Domäne-Controller. Der Grund liegt in der Verwendung von RPCs für diese Funktionalität in einer NT-Domäne, die ein OS/2-Server nicht verarbeiten kann. Der fremde Server kann daher nur in einer Arbeitsgruppe betrieben werden, die den selben Namen wie die Domäne hat. Dies bedingt jedoch eine deutliche Reduktion der Netzwerkfunktionalitäten, was man im besten Falle als eine friedliche Koexistenz der verschiedenen Systeme bezeichnen kann.
Zu neueren Versionen des OS/2-Servers (Warp Server) bietet IBM eine Reihe von kostenlosen Zusatzwerkzeugen. Dazu zählen die System Management Services, die in der Lage sind, außer dem Warp Server im LAN auch alle Windows- oder OS/2-Clients zu verwalten. Außerdem sind Backup- und Recovery-Services sowie fortgeschrittene Druckerdienste verfügbar. Mit den Directory and Security Services (DSS) verfügt IBMs Lösung zudem über einen Verzeichnisdienst, der zwar mehr bietet als beispielsweise Windows NT in der Version 4, jedoch nicht an die Novell Directory Services heranreicht.
Die Verwaltung der Ressourcen und der Benutzer erfolgt beim OS/2 Warp Server durch Drag&Drop. Auch im Hinblick auf die Verwaltung der Clients hat sich IBM beim OS/2 Warp Server viel Mühe gegeben. So kann man Anwendungsprogramme direkt in einem Folder auf dem Server zur Verfügung stellen und so direkt vom Server aus beim Client installieren, ohne sich selbst an die Konsole der Clients setzen zu müssen.
Mit den erweiterten Druckdiensten von OS/2 Warp Server können Postscript-Dateien auf einem PCL-Drucker ausgegeben werden. Das ermöglicht Clients einen einheitlichen (Postscript-) Zugriff auf den gesamten Drucker-Pool eines Netzwerks. Hierdurch lassen sich die üblichen Probleme mit unterschiedlichen Treibern für mehrere Drucker vermeiden.
Dennoch besteht ein Problem in der Verwaltung der bestehenden, sich zum Teil divergierende UNIX-Standards und in der Integration von Windows NT. Standardisierungen führen jedoch die unterschiedlichen Entwicklungslinien zusammen. Neben den Funktionalitäten ihrer Implementierungslinie haben die meisten UNIX-Derivate auch zusätzliche Funktionalitäten der anderen Linien und proprietäre Erweiterungen integriert. Dies macht die Administration von stark heterogenen UNIX-Umgebungen in der Regel sehr aufwendig.
Die zentrale Schaltstelle für die Konfiguration der UNIX-Netzwerkdienste für das Internet ist der Inet-Daemon (inetd).Während des Systemstarts wird er geladen und liest danach die Konfigurationsdatei /etc/inetd.conf. Diese enhält die Zuordnung von Portnummern zu den Diensten, die auf dem Rechner gestartet werden können. Statt jedoch die Portnummer direkt anzugeben, wird mit einem symbolischen Namen gearbeitet, der über die Datei /etc/services oder einer Nameservice-Map Services zu einer Port-Nummer aufgelöst wird. Diese Auflösung entspricht jener unter Windows NT mit Hilfe der Datei %SystemRoot% \System32 \drivers \etc \services.Das Network Filesystem (NFS) gestattet es, Dateisysteme zwischen den einzelnen UNIX-Derivaten und sogar zu Fremdsystemen verfügbar zu machen. Dies zeigt sich in einem freien Zugriff des einen Systems auf die lokalen Verzeichnisse und Dateien eines anderen. Technisch wird dies durch die Verankerung eines NFS-Servers (NFS-Daemon nfsd) im UNIX-Betriebssystem erreicht. Für die Anbindung von PCs muß jedoch noch ein zusätzlicher Daemon (Pcnfsd) etabliert werden, um die Authentifikation und Kommunikation zwischen den doch sehr unterschiedlichen Systemen zu gewährleisten.
NFS-Clients können nun exportierte Verzeichnisse von NFS-Servern an ihr eigenes Dateisystem anbinden. Diese Aktion nennt sich "Mount"-Prozeß. Ein Mount-Daemon mountd beantwortet dabei die Anfragen der Clients, während der NFS-Daemon die Zugriffe auf die Dateien abwickelt. Damit die Clients jedoch den Mount-Daemon kontaktieren können, muß auch ein sogenannte Portmapper zum Registrieren der verwendeten Port-Adressen installiert sein.
Die benötigten Laufzeit- und Konfigurationsdateien für den Betrieb eines NFS-Servers unter einigen UNIX-Derivaten sollen in der folgenden Tabelle aufgeführt werden.
Tabelle: Benötigte Dateien für den Betrieb eines NFS-Servers
UNIX |
Server-Prozesse |
Konfig.-Dateien |
Kommandos |
| Solaris | /usr/lib/nfs/mountd, /usr/lib/nfs/nfsd | /etc/vfstab, /etc/mnttab; /etc/dfs/dfstab, /etc/dfs/sharetab | share, shareall |
| Linux | /usr/sbin/rpc.mountd, /usr/sbin/rpc.nfsd | /etc/fstab, /etc/mtab; /etc/exports | exportfs |
| HP-UX | /usr/sbin/rpc.mountd, /etc/sbin/nfsd | /etc/fstab, /etc/mnttab; /etc/exports, /etc/xtab | exportfs |
| AIX | /usr/etc/rpc.mountd, /usr/etc/rpc.nfsd | /etc/filesystems, /etc/mtab; /etc/exports, /etc/xtab | exportfs |
| Digital UNIX | /usr/sbin/mountd, /usr/sbin/nfsd | /etc/fstab, /etc/mtab; /etc/exports, /etc/xtab | - |
Die Anbindung von NFS-exportierten Verzeichnissen auf PCs ohne NFS-Client-Anwendung kann über ein UNIX-basiertes Gateway geschehen. Dieses wandelt die NFS-Kommandos in SMB-Kommandos um. Die Samba-Suite ist eine bekannte und oft verwendete Software, die diese Funktionalität für die unterschiedlichsten UNIX-Plattformen realisiert. Auf diese Weise lassen sich UNIX-Rechner als sehr leistungsfähige File Server für Windows NT-Umgebungen einsetzen. Daneben existieren auch einige kommerzielle Versionen von Integrationsumgebungen, die eine UNIX-Plattform wie einen NT-Server aussehen lassen oder die Anbindung von NT-Clients an einen UNIX-Server erlauben. Die TotalNet-Suite, die durch Sun Microsystems in ihrer Solstice-Umgebung auf den Markt gebracht wurde, ist ein prominenter Vertreter hierfür. Ein TotalNet-Server verhält sich wie ein Primärer Domain Controller in einer NT-Umgebung, obwohl Sun Solaris seine Basis ist.
Da viele UNIX-Anhänger zum Teil gezwungenermaßen auf Windows NT umsteigen müssen, versuchen sie sich das Leben etwas einfacher zu machen. Daher werden UNIX-ähnliche Systemumgebungen und Werkzeuge für NT zur Verfügung gestellt, die sich zumeist auf die Kommandozeile einer alternativen Shell beziehen. Diese Shells stellen eine wichtige Schnittstelle zum Betriebssystem dar, indem sie für Zuordnungen der Eingabe-/Ausgabekanäle sorgen, Aliase auflösen, Parameter auswerten oder Wildcards expandieren.
Der Kommandointerpreter Cmd von Windows NT ist ebenfalls solch eine Shell, bietet jedoch recht wenig Komfort, wenn man sie mit den bekannten UNIX-Shells Sh, Ksh, Bash, Csh oder Tcsh vergleicht. UNIX-Anwender benötigen daher in der Regel eine Portierung von einem dieser Interpreter. Hierbei müssen verschiedene Abweichungen zwischen den Systemen abgefangen werden, so z.B. die Unterscheidung von "/" und "\", die Konventionen bei den Laufwerkskennungen, die Interpretation von Leerzeichen in NT-Pfaden, das fehlende Konzept der "Signals" unter Windows NT oder die unterschiedliche Behandlung von Groß- und Kleinschreibung. Gerade letzteres ist ein zentrales Unterscheidungsmerkmal zwischen den Systemen, Windows NT ist dabei im Gegensatz zu UNIX nur "Case-Preserving" und nicht "Case-Sensitive".
Das MKS Toolkit und OpenNT bieten als kommerzielle Distributionen jeweils einen Satz von UNIX-Werkzeugen, Shells und speziellen NT-Diensten. OpenNT überzeugt dabei sogar mit der Implementation eines Telnet-Server-Dienstes und der Möglichkeit, X11-Applikationen mit Hilfe eines speziellen Posix-Subsystems unter NT zu übersetzen und ablaufen zu lassen. Als nichtkommerzielle Alternative bietet sich dagegen die Gygnus GNU Win32-Distribution an, deren Werkzeuge kostenlos zu beziehen sind und im Quellcode vorliegen.
Solange sich dies auf den Austausch von Datenträgern bezieht, können mit dem Werkzeug PC Exchange, das mit jedem MacOS ausgeliefert wird, FAT-formatierte Disketten gelesen und geschrieben werden. Problematisch sind dabei nur die unterschiedlichen Konventionen für Dateinamen. Während NTFS bis zu 255 Buchstaben unterstützt, kann die Version 2.1.1 von PC Exchange (MacOS 8) nur die 8.3 DOS-Version von Dateinamen unterstützen. Erst PC Exchange 2.2 (MacOS 8.1) unterstützt die neueren NT-Namenskonventionen und zeigt Dateinamen bis zu 31 Zeichen an. Die Begrenzung auf diese Länge liegt im MacOS selbst und seinem Finder begründet, die nur Namen mit maximal 31 Zeichen verwalten können.
Auch die unterschiedlichen Konventionen, wie Dateiformate mit Applikationen gekoppelt werden, macht den Austausch von Informationen zwischen den Systemen nicht einfach. Windows NT nutzt wie alle anderen Microsoft-Betriebssysteme die Dateierweiterungen (wie z.B. .txt, .doc) für die Assoziation von Benutzerdateien mit den Anwendungsprogrammen. Das MacOS greift hier auf ein anderes Schema zu. Jeder Datei werden zwei unsichtbare Kennungen (Labels) zugeordnet, die mit den Attributnamen Stype und Creator versehen sind. Über diese Attribute werden die Zuordnungen zu Applikationen geregelt. Aus diesem Grund kann ein Mac ohne Modifikation nichts mit den Dateierweiterungen im NT-Stil anfangen. Es besteht jedoch die Möglichkeit auf dem Macintosh eine Zuordnungstabelle zwischen den Dateierweiterungen und den Attributen Stype und Creator zu erstellen, was eine Lösung für das obengenannte Problem darstellt.
Sollen Mac-Disketten auf einem PC gelesen werden, stehen eine Reihe von Werkzeugen zur Verfügung, die auf dem PC installiert werden können. Ein prominentes Beispiel hierfür ist z.B. MacOpener 3.0 von DataViz. Es muß auf dem Macintosh jedoch beim Ablegen der Dateien darauf geachtet werden, daß bestimmte Zeichen nicht für einen NT-kompatiblen Namen verwendet werden dürfen. Im speziellen sind das die folgenden Zeichen:
Wird ein Netzwerk zur Verbindung zwischen Macintosh und Windows NT eingesetzt, so kann auf die jeweils freigegebenen Ressourcen (Verzeichnisse und Drucker) zugegriffen werden. Jedoch ist hierfür die Installation und Konfiguration verschiedener Werkzeuge nötig.
Apple hat mit seinem MacOS schon seit langer Zeit eine AppleShare Server-Software ausgeliefert, die es kleinen Gruppen von Macintosh-Benutzern erlaubt hat, einfach Dateien auszutauschen. Dies ist mit dem Peer-to-Peer-Ansatz von Windows für Workgroups vergleichbar. Die Leistungsfähigkeit dieser Lösung nimmt jedoch rapide mit einer steigenden Anzahl von Benutzern ab. Auch dedizierte AppleShare-Server können die Belastung von großen Mengen an Dateitransfers nicht in angemessener Weise bewältigen. Aus diesem Grund ist der Service für Macintosh auf NT-Servern für viele Umgebungen eine adäquate Lösung. Die NT-Plattform bietet für die Aufgabe als Datei-Server eine deutlich höhere Leistungsfähigkeit und verhält sich nach außen wie ein AppleShare-Server.
Abbildung: Macintosh-Zugriff auf eine exportierte NT-Festplatte.
Greifen eine Reihe von Macintoshs auf entsprechend konfigurierte NT-Server zu, so bestehen keinerlei Einschränkungen in der Macintosh-konformen Behandlung von Dateien. Obwohl die Dateien physikalisch auf einem NT-Server gespeichert werden, kann dieser die Stype- und Creator-Informationen verwalten. Diese Funktionalität kann jedoch nur erreicht werden, wenn auf dem NT-Server als Dateisystem NTFS zum Einsatz kommt.Der NT-Service für Macintosh erlaubt keine Peer-to-Peer-Verbindungen zwischen den verschiedenen Plattformen. Soll z.B. eine NT-Workstation direkt auf die exportierten Ressourcen eines Macintosh zugreifen, müssen zusätzliche Werkzeuge installiert werden. Dies gilt insbesondere für den Fall, daß als Übertragungsprotokoll AppleTalk verwendet werden soll. Ein oft verwendetes Werkzeug für diesen Fall ist PC MacLAN von Miramar Systems, das dem PC die Teilnahme an den Funktionalitäten zum Austausch von Dateien im Macintosh-Stil erlaubt. Der NT-Benutzer sieht die freigegebenen Macintosh-Ressourcen in seiner Netzwerkumgebung, die das Gegenstück zum Mac Chooser ist. Umgekehrt kann der PC auch seine Ressourcen so exportieren, daß andere Macintosh-Benutzer darauf zugreifen können. Bei diesem Vorgehen sollten jedoch zwei wichtige Einschränkungen beachtet werden:
Soll sich ein Macintosh völlig nahtlos in eine NT-Umgebung integrieren, ohne daß ein NT-Rechner umkonfiguriert wird, müssen andere Ansätze gewählt werden. Der Macintosh darf dann nicht mehr mit dem AppleTalk-Protokoll kommunizieren, sondern muß hierfür einen NT-Standard benutzen. Das Produkt Dave von Thursby Software Systems erfüllt genau diese Forderung. Es nutzt die TCP/IP-Protokollumgebung auf dem Macintosh und erweitert sie um die benötigten NetBIOS-Funktionalitäten für den Ressourcenzugriff. Für die Konfiguration von Dave muß daher ein gutes Verständnis von Windows-Netzwerken vorliegen.
Zeigt Dave den Inhalt eines NT-Verzeichnisses an, nutzt es die Präferenzen von PC Exchange, um die Zuordnungen zwischen Dateierweiterungen und Anwendungsprogrammen durchzuführen. Dave setzt dabei das Icon einer angezeigten Datei nach ihrem ersten Aufruf dauerhaft, d.h. eine nachträgliche Modifikation der Zuordnungstabelle hat keine Auswirkung auf das einmal gesetzte Icon. Aus diesem Grund sollte die Zuordnungstabelle von PC Exchange angepaßt werden, bevor Dave gestartet wird und der Zugriff auf einen neuen Dateityp erfolgt. Andernfall besitzen die schon einmal aufgerufenen Dateien auf Dauer generische Icons.
Neben Windows NT ist Novell NetWare seit Jahren ein etabliertes und leistungsfähiges Netzwerkbetriebssystem im PC-Bereich. In vielen Unternehmen und Institutionen stellt sich mit dem steigenden Einsatz von Windows NT die Frage nach der Integration eines bestehenden oder neu aufzubauenden Novell Netzwerkes in eine NT Umgebung. Sowohl Microsoft als auch Novell stellen hier verschiedene Lösungen bereit, die jeweils einen unterschiedlichen Integrationslevel bieten. Ein allgemeines Rezept, welche der Lösungen für einen konkreten Anwendungsfall adäquat ist, kann natürlich nicht gegeben werden. Hier ist eine gründliche Analyse der Anforderungen an das Netz sowie eine Strategie zur Entwicklung der Netzwerkinfrastruktur erforderlich, d.h. insbesondere die Beantwortung der Frage, mit welcher Priorität beide Systeme jetzt und in Zukunft nebeneinander eingesetzt werden sollen.
Microsoft liefert mit Windows NT drei verschiedene Möglichkeiten, eine NetWare Umgebung zu integrieren, bzw. zu migrieren:
Client Services for NetWare (CSNW)
Gateway Services for NetWare (GSNW)
File and Print Services for NetWare (FPNW)
Außerdem wird ein Werkzeug zur Migration eines NetWare Servers zu einem NT Server angeboten.
Die CSNW stellen, wie der Name schon sagt, eine reine Client-Komponente zum Zugriff einer NT Maschine auf bestehende NetWare Server dar. Sind als Netzwerkservice zu installieren und erfordern das IPX/SPX-Protokoll (NWLink IPX/SPX-kompatible Transport). Nach der Installation sind die Datei- und Druckdienste der NetWare Server über das NetWare Core Protokoll (NCP) möglich. Die Authorisierung am NetWare Server erfolgt dabei transparent für den Benutzer. Es werden NetWare Login-Scripte unterstützt, wenn auch nicht in vollem Funktionsumfang. Die NetWare Directory Services (NDS) werden nicht voll unterstützt, so daß einige NetWare Werkzeuge, insbesondere einige Administrationstools nicht einsetzbar sind. Für eine einfache Clientanbindung sind die CSNW in den meisten Praxisfällen jedoch ausreichend und als Dauerlösung für ein Netzwerk geeignet, in dem NT Server und NetWare Server nebeneinander existieren bzw. NT Workstations auf NetWare Server zugreifen müssen.
Die GSNW bilden eine Komponente, die auf einem NT Server zu installieren sind. Sie stellen über eine Gateway-Funktion einen einfachen Zugriff der Clients auf die NetWare Server via Server Message Blocks (SMB) zur Verfügung. Auf dem NetWare Server wird dabei ein spezieller Account sowie eine Gruppe eingerichtet. Über diesen Account stellt der NT Server die Verbindung zum NetWare Server her. Auf dem NT Server werden dann alle zu exportierenden Verzeichnisse in der herkömmlichen Weise für die Clients freigegeben. Der Account auf der NetWare Seite muß also über die Summe der Berechtigungen verfügen, die zum Zugriff aller Clients notwendig sind. Der Hauptnachteil dieser Variante liegt in der schwachen Performance. Allerdings sind auf der Clientseite keinerlei Veränderungen erforderlich. Aus diesen Gründen eignet sich diese Lösung eher als Übergang während einer Migrationsphase, wenn die Clients in der Mehrzahl Microsoft Netzwerk Clients sind.
Die FPNW ermöglichen den Einsatz eines NT Servers in einer NetWare Umgebung. Sie sind ebenfalls auf einem NT Server zu installieren. Der NT Server stellt sich dabei im Netz über das Service Advertising Protokoll (SAP) als NetWare 3 Server dar. Alle Netware Clients können dabei ohne weitere Änderungen auf die Datei- und Druckdienste des NT Servers zugreifen. Nachteil dieser Variante ist, daß die FPNW lediglich die sogenannte NetWare Bindery unterstützen und ein Zugriff über die NDS nicht möglich ist. Auch diese Variante ist daher eher für eine Migrationsphase einer kompletten NetWare Umgebung in eine NT Umgebung geeignet und zwar so lange, bis alle NetWare Clients umgestellt sind.
Mittels des zu NT Server mitgelieferten Migrationswerkzeuges ist die Umstellung eines bestehenden NetWare Servers in einen NT Server möglich. Zuerst wird dabei ein herkömmlicher NT Server mit den GSNW installiert. Über die GSNW kann dann die Verbindung zum NetWare Server aufgenommen und das bei der GSNW Installation enthaltene Migrationstool gestartet werden. Da die NDS nicht unterstützt wird, wird bei der Migration von NetWare 4 Servern in der Bindery Emulation gearbeitet. Hier ist insbesondere darauf zu achten, daß auf alle zu migrierende NDS-Kontexte ein Bindery Kontext gesetzt ist. Mit dem Migrationswerkzeug können alle Nutzer- und Gruppeninformationen des NetWare Servers übertragen werden. Außerdem ist die Kopie des Dateisystems, bzw. Teilen davon mit den bestehenden Berechtigungen möglich. Lediglich die verschlüsselten Passworte können nicht übernommen werden. Hier wird alternativ die Vergabe eines einheitlichen Passwortes oder die Generierung einer zufällig erstellten Passwortliste angeboten.
Während die von Microsoft angebotenen Lösungen mehr auf die Umwandlung einer bestehenden NetWare Umgebung in eine Windows NT Umgebung bzw. maximal auf deren Koexistenz zielen, konzentrieren sich die von Novell naturgemäß auf eine Integration von NT Workstations in eine reine NetWare Umgebung bzw. auf eine Koexistenz beider Systeme. Novell versäumte es dabei lange, eine brauchbare Anbindung von Windows NT in eine Netware Umgebung anzubieten. Um so umfangreicher waren in den letzen Jahren die Anstrengungen in dieser Richtung, die viele Lösungen unterschiedlicher Qualität hervorbrachten. Heute sind aus dieser Entwicklung im wesentlichen zwei Ansätze hervorgegangen, die einen akzeptablen Weg zur Integration von NetWare und Windows NT darstellen:
Z.E.N. Works
NDS for NT
Z.E.N. Works (Zero Effort Networking) stellt eine Sammlung unterschiedlicher Werkzeuge dar, die eine gute Integration von NT Workstations in eine NetWare Umgebung ermöglichen und sogar ohne den Einsatz einer NT Domain auskommen können. Grundlegender Bestandteil ist dabei der IntranetWare Client for Windows NT, der schon seit längerem mit Novell NetWare ausgeliefert wird. Vergleichbar ist diese Client Komponente mit den CSNW, wobei die Einbindung in die NetWare Welt homogener erfolgt. Als Protokoll wird auch hier das IPX/SPX installiert. Die NDS wird voll unterstützt, so daß alle NetWare Werkzeuge in vollem Umfang einsetzbar sind. Demgemäß sind die Konfigurationsmöglichkeiten des Clients bzgl. NetWare deutlich umfangreicher als bei den CSNW. Auch die NetWare Login Scripte werden in vollem Funktionsumfang mit einem eigenen Prozessor unterstützt, der keinen Kommandoprompt benötigt. Zur einfacheren Verwaltung der NetWare Umgebung wird ein Explorer SnapIn installiert, das z.B. eine schnelle Rechtevergabe auf NetWare Volumes ermöglicht. Nachteil dieses Clients ist, daß durch ihn die Graphical Identification and Authentication (GINA) -DLL ausgetauscht wird und Systeme, die auf der MS-GINA basieren, wie z.B. Citrix Winframe diesen Client nicht, bzw. nicht mit vollem Funktionsumfang benutzen können.
Wird nur der IntranetWare Client eingesetzt, ist, um netzweite User Accounts zu ermöglichen noch das Vorhandensein einer NT Domain erforderlich. Um dies zu umgehen, entwickelte Novell als Bestandteil von Z.E.N. Works den Workstation (WS) Manager. Diese Komponente ist ebenfalls auf dem Client zu installieren und nimmt während des Einlogvorganges eine Authentifizierung über die Novell NDS vor. Wird der Benutzer authorisiert, legt der WS Manager einen lokalen Account auf Basis der NDS Information auf der Workstation an, über den der Nutzer Zugang zur Maschine erhält. Über in der NDS zugewiesene Policies kann die Berechtigung des Nutzers bzw. seine Zuordnung zu bestimmten Gruppen (Power User, Administrators, ...) festgelegt werden. Man hat die Möglichkeit existierende lokale Accounts auf diese Weise zu verwalten oder auch die Accounts nach dem Ausloggen wieder zu entfernen, so daß sich in der lokalen Nutzerdatenbank keine überflüssigen Accounts ansammeln. Gravierendster Nachteil dieser Variante ist, daß aufgrund der Tatsache, daß jeder Account mit seiner eigenen SID versehen wird, eine Rechtevergabe auf der lokalen Maschine an globale Accounts schwer bzw. nicht möglich ist.
Weitere Bestandteile von Z.E.N. Works, auf die an dieser Stelle nicht näher eingegangen werden soll, sind die Zuweisung von umfangreichen Policies, die Zuweisung von Druckern und die Verteilung der entsprechenden Treiber sowie die Verteilung von Softwarepaketen über den mitgelieferten NetWare Application Launcher (NAL). Alle Zuweisungen sind dabei in der NDS auf per User und per Workstation Basis sowie zeit- als auch ereignisgesteuert möglich. Die bislang beschriebenen Komponenten sind Bestandteil des sogenannten Z.E.N. Works Starterpacks, das kostenlos von Novell bezogen werden kann. In der Vollversion, die käuflich zu erwerben ist, sind außerdem noch ein Remote Control und ein Inventory der einzelnen Workstations enthalten.
Einen anderen Weg, Windows NT in eine NetWare Umgebung zu integrieren, verfolgt NDS for NT. Hier wird davon ausgegangen, daß neben der NetWare Umgebung eine oder mehrere NT Domains existieren. Um den damit verbundenen doppelten Administrationsaufwand für die Nutzerverwaltung zu umgehen und die Möglichkeiten der NDS für die NT Welt zugänglich zu machen, wurde ein Weg gefunden, die NT Domains über die NDS zu verwalten. In einer herkömmlichen Domain Struktur erfolgt der Zugriff auf die Sicherheitsdatenbank wie im folgenden Schema abgebildet.
Es ist zu erkennen, daß sowohl die Zugiffe der Applikationen des Servers (Verwaltungswerkzeuge etc.) als auch die der Workstations in der Domain auf Sicherheitsinformationen per Remote Procedure Call (RPC) über die SAMSRV.DLL erfolgen, welche alle Anforderungen an den Security Account Manager (SAM) weitergibt, die dieser aus der Domain Database beantwortet.
Novell hat mit der NDS for NT die SAMSRV.DLL gegen eine DLL ausgetauscht, die alle Zugiffe auf den SAM in die NDS umleitet. Schematisch ist dies in der folgenden Abbildung zu sehen:
Damit können nun alle Informationen in der NDS gehalten und verwaltet werden. Die Migration der NT Nutzer und Gruppen in die NDS wird während der Installation mit einem mitgelieferten Migrationswerkzeug vorgenommen. Sind dabei die Nutzer auf der NetWare Seite schon vorhanden, erfolgt eine einfache Zuweisung andernfalls wird ein neues Objekt angelegt. Für die Domain wird ein eigenes Objekt in der NDS angelegt, das einer Organisational Unit (Container Objekt) ähnelt. Hier sind alle Zuordnungen der Nutzer und Gruppen zur Domain enthalten, wodurch ein Nutzer auch mehreren Domains zugewiesen werden kann und die unter NT üblichen Trust Beziehungen zwischen Domains überflüssig werden (obgleich sie in der NDS mit angegeben werden können). Es können zur Verwaltung sowohl die NetWare- als auch die NT Administrationstools (NWAdmin, User Manager, ...) eingesetzt werden. Weiterhin gibt es eine Erweiterung die die Verwaltung von MS-Exchange Mailkonten via NDS for NT ermöglicht. Die Installation von NDS for NT muß auf jedem Domain Controller der entspechenden Domain (PDC und alle BDC) durchgeführt werden. Mitgeliefert wird auch ein Deinstallationswerkzeug, das alle bis dahin gemachten Änderungen in die ursprüngliche Domain Database integriert und den SAM wieder aktiviert.