Letzte Änderung: 18.5.98 von B. Tritsch
Zurück zum Index "PC- und MS-Windows-Support"
Mit seiner Lösung Windows NT Server gewinnt Microsoft zunehmend Anteile in angestammten Marktsegmenten von Netzwerkbetriebssystemen wie UNIX oder Novell NetWare. Dabei propagiert die Gates-Company das Produkt nicht nur als Netzwerkbetriebssystem, sondern auch als Internet/Intranet-Plattform. Dennoch werden die angestammten Betriebssystemen insbesondere in größeren Firmennetzen nicht einfach ersetzt, sondern müssen zumindest temporär gemeinsam betrieben werden. Zudem lassen sich auch viele andere Gründe finden, warum Firmen nicht vollständig auf Windows NT als allgemein verwendetes Betriebssystem umsteigen wollen oder können. Nicht zuletzt spielen vorangegangene Investitionen, vorhandenes Know-how oder spezielle eingesetzte Software-Produkte eine wesentliche Rolle. Aus diesem Grund spielt dann die Integration von Windows NT eine zentrale Rolle. Im folgenden sollen die wichtigsten Betriebssysteme neben Windows NT und deren Möglichkeiten zur NT-Anbindung aufgezeigt werden.
Novell, etabliertester Player im Netzwerk-Betriebssystemsektor, muß angesichts der immer beliebteren NT-Plattform zunehmend mit Problemen rechnen. Um Kundenabwanderungen entgegenzuwirken, versuchte Novell mit der Einführung von Intranetware im Jahr 1997 deutliche Zeichen in Richtung Inter- und Intranet zu setzen.
Novell NetWare enthält viele Eigenschaften, die in Richtung Intranet zielen. So wird es zusammen mit dem Netware WWW-Server, Netware SMP, TCP/IP inklusive DHCP und Sicherheit gemäß dem Standard C2 ausgeliefert. Zusätzlich gehört der Netscape Navigator, ein IPX/SPX-zu-TCP/IP-Gateway, FTP-Dienste und der Netware-Multiprotokoll-Router (MPR) inklusive WAN-Erweiterung zum Lieferumfang.
Windows NT und Novell NetWare unterscheiden sich grundsätzlich. NetWare wurde einzig als Netzwerkbetriebssystem konzipiert, der NT-Server entstand aus einem leistungsfähigen Workstation-Betriebssystem.
Die Stärke der NetWare liegt vor allem in den mächtigen Datei- und Druckdiensten, die auf dem NetWare Core Protocol (NCP) basieren. Bei der Entwicklung von Windows NT wurde hingegen neben File- und Print-Services auch die Fähigkeiten eines Applikations-Servers integriert. Durch Funktionen wie Speicherschutz für Applikationen und Subsystemen will sich Windows NT als Alternative für anspruchsvolle Client/Server-Applikationen wie z.B. SAP R/3 etablieren. Eine Sammlung solcher Client/Server-Applikationen stammt mit BackOffice direkt von Microsoft.
In manchen Bereichen bietet Windows NT ähnliche Funktionen wie NetWare (z.B. Umleitung des Datenstroms auf unterschiedliche Drucker-Ports, Beschränkung der Benutzerrechte). Während jedoch bei Windows NT der Drucker-Manager zentraler Anlaufpunkt ist, werden bei NetWare mehrere Module (Pconsole, Rprinter usw.) zum Verwalten von Netzwerkdruckern benötigt. Windows NT 4.0 verwendet dabei im Gegensatz zu NetWare Verwendung einheitlicher Druckertreiber für Server und Clients.
Obwohl Festplatten heute sehr günstig sind, spielt die Kompression von Daten in großen Netzwerken eine wichtige Rolle. NetWare ist durch seine automatische Datenkompression Windows NT überlegen. Unter Windows NT müssen Dateien und Verzeichnisse erst manuell zur Datenkompression ausgewählt werden.
Ein weiteres Manko von Windows NT im Dateisystem ist die fehlende Unterstützung von Speicherplatzbeschränkungen pro Benutzer (Disk Quotas). Während in NetWare standardmäßig Volume Disk Restrictions pro User definiert werden können, ist man bei Windows NT auf Third-Party-Produkte angewiesen. Alternativ kann man auch auf NT 5.0 warten, das Disk Quotas enthalten wird.
Im Gegensatz zu Windows NT 4.0 besitzt Novell NetWare einen ausgereiften Verzeichnisdienst, dem Network Directory Service (NDS). Hiermit können Ressourcen im Netzwerk leicht in eine logische Struktur gebracht werden. Was jedoch fehlt, sind ein Mail- und ein DNS-Server. Besonders interessant ist das NetWare Dateiattribut „Execute Only". Hierdurch kann der Administrator verhindern, daß Raubkopien von Anwendungsprogrammen durch Benutzer erstellt werden.
Sowohl Windows NT als auch NetWare bieten graphische Administrationswerkzeuge. Bei Windows NT liegen alle Verwaltungswerkzeuge als grapische Anwendungen vor, mit dem Resource Kit auch als Kommandozeilen-Tools. Dagegen wechselt die NetWare für die Fernwartung oder das Datei-Management in einen NetWare-Blockgraphik-Modus. Die Administrationswerkzeuge von NetWare und von Windows NT lassen sich zumeist ohne vorherige Installation von CD-ROM oder über das Netzwerk verwendet werden.
Die Installation bzw. Modifikation von Systemmodulen ist unter Windows NT etwas problematischer als bei der NetWare. In der Regel ist ein Neustart von NT nach der erfolgreichen Durchführung einer Änderung nötig. Unter der NetWare läßt sich dagegen fast jedes Modul dynamisch laden bzw. entladen.
Von besonderer Bedeutung in einem Netzwerk ist der einzige Anmeldevorgang mit Zugriff auf alle Netzwerkdienste. Während die NetWare 4.0 mit einem zentralen Network Directory Service (NDS) arbeitet, wird die Administration von Windows NT 4.0 von dem unflexibleren Domänekonzept erschwert, das sich erst unter Windwos NT 5.0 deutlich verbessert. Novell NetWare unterstützt mit seinem NDS einen „Single Point of Administration". Unter Windows NT ist mit dem Benutzer- bzw. Domäne-Manager nur eine eingeschränkte Verwaltung von Benutzern und Gruppen möglich. Die NDS der NetWare können zusätzlich Netzwerkdrucker, Applikationen und andere Netzwerkkomponenten verwalten. Generell kann jedoch auch festgestellt werden, daß Windows NT gegenüber der NetWare 4.x eine leistungsfähigere Sicherheitsüberwachung gestattet.
Das Thema Integration von NT in NetWare-Umgebungen ist auch in größeren Unternehmen nicht abgeschlossen. Es lassen sich dabei eine Reihe von Situationen unterscheiden:
Ein wichtiges Kriterium ist die Stärke von Windows NT als Anwendungs-Server. Während die NetWare deutliche Stärken als File-Server-Betriebssystem hat, zeigt es beim Einsatz als Anwendungs-Server architekturbedingt deutliche Schwächen. Viele Anwendungs-Server werden daher nur zögernd auf die NetWare portiert, so z.B. Lotus Domino oder Oracle Server. Andererseits muß Microsoft erst noch den Beweis antreten, daß es mit NT 5.0 den Vorsprung von NetWare insbesondere bei den Verzeichnisdiensten aufholen kann.
Für viele Unternehmen ist nicht die Entscheidung zwischen den beiden Systemen wesentlich, sondern viel mehr ihre nahtlose Integration. Hierbei kann zwischen den Ansätzen von Microsoft und von Novell unterschieden werden.
Microsoft hat eine Reihe von Komponenten realisiert , mit denen Windows NT- und NetWare-Umgebungen integriert beziehungsweise NetWare-Umgebungen zu Windows NT migriert werden können. Die Bestandteile von NT im Bezug auf NetWare sind folgende:
Hinzu kommen als Zusatzkomponenten die Services for NetWare. Diese bestehen wiederum aus zwei Teilanwendungen, den File and Print Services for NetWare (Abbildung eines NetWare 3.12 Servers auf einen Windows NT Server) sowie den Directory Synchronization Manager for NetWare (Synchronisation der Paßworte zwischen NetWare 3.x Servern und Windows NT Servern über eine spezielle Datenbank). Die Basis für die Integration bildet dabei der NWLink IPX/SPX-kompatible Transport, wie Microsoft seine Implementierung des Novell-Protokolls IPX/SPX etwas umständlich nennt.
Über den Client Service for Netware lassen sich Windows NT Workstation und NetWare Server integrieren. Es handelt sich dabei um einen Dienst, mit dem man sowohl auf NetWare 3.x als auch auf NetWare 4.x Server zugreifen kann. Für die meisten Zwecke ist dieser Client gut verwendbar. Es gibt aber auch einige Einschränkungen. Die gravierendsten sind die Beschränkung auf IPX als Transportprotokoll und die fehlende Unterstützung von NDS-basierten Anwendungen. Dadurch lassen sich beispielsweise keine Administrationsprogramme von NetWare einsetzen.
Der Gateway Service for NetWare des NT Servers erweitert diese Funktionalität um einen Brückenkopf zu NetWare Server. Clients können dadurch über die SMBs (Server Message Blocks), die von Microsoft Clients verwendet werden, auf den Windows NT Server zugreifen. Dieser leitet dann die Zugriffe an den NetWare Server weiter.
Ein solches Konzept wirkt zwar auf den ersten Blick recht interessant, weist aber einige schwerwiegende Nachteile auf. Zu diesen zählen an erster Stelle die eingeschränkte Sicherheit und Kontrollierbarkeit, da nur noch ein Benutzer für die Zugriffe des Windows NT Servers auf den NetWare Server verwendet wird. Auch die Performance kann bei einer solchen Lösung nie voll überzeugen. Dieser Dienst ist daher vor allem in Migrationsphasen von Interesse, in denen nur noch in Einzelfällen auf NetWare Server zugegriffen werden muß, die neuen Clients aber schon ohne NetWare-Client-Software eingerichtet werden sollen.
Der Gateway Service for NetWare stellt aber auch die Basis für das Migrationsprogramm für NetWare dar. Mit diesem Programm lassen sich bestimmte NetWare Server auf den Windows NT Server migrieren. Dazu wird zunächst der Windows NT Server eingerichtet, auf den die Informationen überspielt werden sollen. Anschließend wird eine Verbindung zu dem NetWare Server hergestellt, der migriert werden soll. Benutzer- und Gruppeninformationen ebenso wie Zugriffsrechte können dann ausgelesen werden. Auch Dateien lassen sich dabei automatisch vom NetWare 4 zum Windows NT Server kopieren.
Die meisten Einstellungen des NetWare Servers lassen sich auf diese Weise übernehmen. Was jedoch nicht über den Migrationsmechanismus funktionieren kann, ist die Übertragung der verschlüsselten Paßworte. Zudem gibt es einige konzeptionellen Unterschiede zum Beispiel bei der Form und Bedeutung von Anmeldeprogrammen. Ein mit dem Migrationsprogramm migrierter Server muß daher noch manuell optimiert werden. Ein wesentlicher Teil der Migration erfolgt jedoch automatisch.
Zum heutigen Zeitpunkt hat Microsoft daher eine Reihe von Werkzeugen, mit denen Windows NT und NetWare-Umgebungen integriert werden können. Zentrales Interesse innerhalb vieler Unternehmen findet jedoch das genaue Aussehen der Migrationswerkzeuge der NDS auf Windows NT 5.0.
Novells Antwort auf die Microsoft-Herausforderung sind einige Produkte für die Einbeziehung von Windows NT und der NDS. Die Basis für die Integration stellt der Intranetware Client for Windows NT dar, die eine Alternative zum Client Service for NetWare von Microsoft ist. Sein Vorteil liegt in der vollen NDS-Unterstützung und darin, daß auch über TCP/IP auf NetWare Server zugegriffen werden kann. Der Nachteil liegt in der schwächeren Integration in Windows NT. Die Vor- und Nachteile der beiden Clients halten sich insgesamt aber die Waage.
Einen Schritt weiter geht der Intranetware Client for Windows NT mit dem integrierte Workstation Manager, Diese Software kann kann für eine Windows NT Workstation ein Objekt in der NDS erzeugen. Das Objekt enthält Informationen, die bei der Anmeldung von Intranetware Client for Windows NT verwendet werden, um dynamisch ein Benutzerkonto auf der Windows NT Workstation zu erzeugen. Das wirkt zwar nicht wie eine optimale Lösung, aber sie funktioniert. Es kann damit auf einen Windows NT Server und die Einrichtung einer Domäne verzichtet werden.
Vergleichbar mit dem Directory Synchronization Manager von Microsoft ist der Novell Administrator for Windows NT. Dieser richtet den NDS Network Replication Service als Dienst auf jedem Domain Controller und jeder in die Verwaltung einbezogenen Windows NT Workstation ein. Dieser empfängt Änderungsanmeldungen von den NDS und trägt diese in die Benutzerkontendatenbank von NT ein.
Der wirklich große Entwicklungsschritt ist die NDS für Windows NT. Damit kann der Verzeichnisdienst von NetWare auf Windows NT Servern ausgeführt werden. Ein NDS-basiertes Netzwerk kann damit völlig ohne NetWare Server realisiert werden. Realisiert wird dies durch den alternativen Zugriff auf die NDS statt auf die NT Security-Datenbank SAM. Das Ziel von Novell ist es, die NDS durch die Portierung auf unterschiedlichste Plattformen als zentralen Verzeichnisdienst für heterogene Netzwerke zu etablieren.
Die NDS können für verschiedene Aufgaben im Netz verwendet werden. Dazu gehören unter anderem die automatische Verzeichnisreplikation und –synchronisation, Internet- und Intranet-Zugriffsverwaltung, Proxy Caching, Software-Verteilung und Reparatur von beschädigten Applikationen.
Trotz des kleinen Marktanteils von zwei Prozent ist das Netz-Betriebssystem Banyan Vines wegen seines leistungsfähigen Verzeichnisdienstes Streettalk eine interessante Lösung. Streettalk ist dabei mit dem Novell Directory Service vergleichbar.
Streettalk bildet schon seit mehr als einem Jahrzehnt den strategischen Kern von Banyan Vines. Benutzer und Ressourcen wie Verzeichnisse, Dateien, Datenbanken, Drucker, Warteschlangen, Speichereinheiten, Dienstprogramme, Gateways Druck- und Dateidienste im Netz können vom Anwender über einen logischen Namen angesprochen werden, ohne daß er wissen müßte, auf welchem Server diese Objekte residieren. Diese einfachen, Server-ungebundene Ansprache funktioniert über Weitverkehrsverbindungen hinweg, selbst in einem weltweit verteilten Netz. Weder Benutzer noch Netzwerkadministratoren müssen also den Standort der einzelnen Objekte kennen und sich auch nicht auf unterschiedlichen Servern einloggen.
Der Prozeß der Öffnung von Streettalk wurde bereits vor einigen Jahren mit der Portierung des Vines-internen Verzeichnissystems gemeinsam mit den Management-, Sicherheits-, Email- sowie Datei- und Druckdienst unter dem Namen ENS (Enterprise Network Services) eingeleitet. Die Zielplattformen waren dabei SCO UNIX, HP UNIX, AIX, Sinix, Solaris und Novell NetWare. Mittlerweile sind die Banyan-Kerndienste, insbesondere Streettalk, auch für Windows NT verfügbar, um dort das starre und unwirtschaftliche Domänekonzept durch ein flexibles Verzeichnissystem zu ersetzen. Hierbei nutzt Streettalk in allen Installationfällen TCP/IP. Darüber hinaus wurde in Streettalk generell eine herstellerunabhängige LDAP-2-Schnittstelle gemäß RFC 1777 implementiert.
Mit dem OS/2 Warp Server von IBM steht dem Anwender für den Einsatz im Inter- und Intranet ein Netz-Betriebssystem mit einigen kleinen Schwächen, aber insgesamt überzeugenden Leistungen zur Verfügung. OS/2 und Microsoft Windows können dabei auf eine lange und gemeinsame Historie im Netzwerkbereich zurückblicken. Ursprünglich war OS/2 sogar ein gemeinsames Projekt von IBM und Microsoft. Aus diesen Zeiten stammen auch noch die Namen LAN Manager und LAN Server für die integrierten Client/Server-Komponenten.
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.
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.
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.
Apples MacOS kann zwar nicht unbedingt als Server-Betriebssystem bezeichnet werden, dennoch spielt es traditionell noch immer in einer Reihe von Unternehmensbereichen eine große Rolle, insbesondere im Graphikdesign und in der Werbung. Immer mehr besteht jedoch die Notwendigkeit, oftmals parallel gewachsene Macintosh- und NT-Infrastrukturen zu integrieren.
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-Palttform 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.
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.
Sobald Dave installiert ist, eröffnen sich eine Reihe von Möglichkeiten, auf NT-Ressourcen zuzugreifen. Der Chooser bietet ein zusätzliches Icon, das im Grunde wie das AppleShare-Icon funktioniert. Es kann jedoch auch Dave Access verwendet werden, das einen erweiterten Satz an Optionen für den Netzwerkzugriff und die Anzeige von Dateien bietet.
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.
Novells NetWare, lange Zeit der Platzhirsch im Bereich der Netz-Betriebssysteme, gerät vor allem durch Microsofts Windows NT zusehends in Bedrängnis:
1995
2000