Universitätsrechenzentrum
TU ChemnitzURZKurseUnterlagenAdmin-nt

4. Servereinsatz

4.1. Spezielle Anforderungen

Folgende Bedingungen und Forderungen bestehen im Pool-Umfeld des URZ und beeinflussen Nutzungstechnologie, Workstationkonfiguration und Servereinsatz:

• Ein Arbeitsplatz soll in kurzer Zeit eingerichtet werden können (realistisch sind weniger als 2 Stunden) . Danach - im Routinebetrieb - sollen keine manuellen Aufwendungen mehr zur Administration der Arbeitsplätze erforderlich sein (auch kein Backup).
• Die Anwendungssoftware und sämtliche Dienste müssen an allen Pool-Arbeitsplätzen für jeden Nutzer verfügbar sein.
• Die gleichzeitige Benutzung der Anwendungssoftware muß (im Rahmen der Lizenzbestimmungen) möglich sein.
• Die Nutzung eines Pool-Arbeitsplatzes darf nur "befugten" Personen gestattet sein. Anonyme Logins sind nicht statthaft. Accountinginformationen sind zu protokollieren.
• Jeder Nutzer soll auf alle Komponenten seines Arbeitsplatzes zugreifen können, dabei aber keinen Einfluß auf die Arbeit anderer Nutzer haben.
• Die eigene Arbeitsumgebung muß von jedem Nutzer selbst gestaltbar sein.
• Jeder Nutzer muß bei jeder Sitzung seinen Arbeitsplatz im Pool frei wählen können.
• Setup- und Preferences-Einstellungen soll der Nutzer nur einmal - an einem beliebigen Arbeitsplatz - durchführen . Diese Einstellungen müssen automatisch auf alle anderen Arbeitsplätze "wandern".
• Alle Arbeitsplätze müssen einem Nutzer die gleiche Arbeitsumgebung bieten.
• Jeder URZ-Nutzer benötigt ein HOME-Verzeichnis, das an jedem Arbeitsplatz - unabhängig von der aktuell benutzten Systemplattform - verfügbar ist.
• Der Druckdienst des URZ muß uneingeschränkt nutzbar sein.
• Eine große Anzahl von Nutzern (bis zu 6000) teilt sich zeitlich relativ wenige Maschinen (ca.100).
• Jährlich kommen zahlreiche Nutzer hinzu (ca. 1000) und ebenso viele verlassen die Einrichtung.
• Der Zugang eines Nutzers zu allen Poolmaschinen muß mit sofortiger Wirkung entzogen werden können (z.B. bei Verstoß gegen die Nutzerordnung).

Hinzu kommen Forderungen, die für jeden normalen Arbeitsplatz-PC auch stehen, wie:

• Stabilität
• Performance
• Virenschutz
• Softwarelizenz-Bestimmungen
• ....

Daraus ergibt sich, daß folgende Aufgaben nicht lokal von der Workstation, sondern von Servern übernommen werden müssen:

• Bereitstellung der HOME-Verzeichnisse
• Bereitstellung der Anwendungssoftware
• Speicherung der Benutzerprofile
• Authentifizierung der Nutzer
• DNS
• Systempolicy
• Lizenzüberwachung
• Ereignisprotokollierung
• Bereitstellung der Drucker

Vorhandene Serverlösungen sollten weitgehend in die Windows NT-Technologie integriert werden.

4.2. Fileserver
4.2.1. Windows NT mit AFS

Zur Datenspeicherung hat sich das verteilte Filesystem AFS seit 1994 im URZ bewährt. Da entsprechende Klientensoftware für Windows NT verfügbar ist, setzen wir AFS auch auf dieser Systemplattform ein.
Auf allen Pool-Arbeitsplätzen (und Servern) wurde die AFS-Klientensoftware von Transarc installiert. Dieses Softwareprodukt stellt den gesamten AFS-Filebaum an der NT-Workstation als Netzlaufwerk bereit. Jeder Nutzer ist dadurch u.a. in der Lage, auf sein HOMEDIR, das sich im AFS befindet, im UNIX und auch unter Windows NT zuzugreifen.

Die AFS3.5.-Klientensoftware wird von Transarc im Netz bereitgestellt. Die Installation erfolgt durch Starten des Programms setup.bat.

Bei der Konfiguration des AFS-Klienten (in der "Systemsteuerung") sind folgende Einstellungen wichtig:

Das Mounten des AFS-Filesystems geschieht im System-Loginscript wie folgt:

net use u: \\%computername%-afs\all /P:N

Windows NT merkt sich über das Sitzungsende hinaus, welche Netzlaufwerke gemountet sind. Das Laufwerk U:, das wir im Loginscript montieren, wird deshalb "nicht persistent" (Option /P:N) bereitgestellt.

Der Nutzer kann aber während seiner Sitzung weitere Netzlaufwerke montieren.

Allerdings geschieht das Mounten von Netzlaufwerken im Windows NT prinzipiellnicht nutzerbezogen! D.h. ohne administrative Eingriffe bekommt ein Nutzer auch die Laufwerke bereitgestellt, die jener Nutzer gemountet hatte, der zufällig zuvor an der gleichen Workstation arbeitete.
Aufgrund unterschiedlicher Zugriffsbefugnisse sind diese Netzverbindungen aber nicht zu gebrauchen, es kommt zu Fehlermeldungen beim Loginvorgang und die ordnungsgemäße Herstellung der Netzverbindungen des aktuellen Nutzers wird gestört.

Deshalb werden im Systemloginscript vorsorglich alle Buchstaben des Alphabets mit

SUBST X: /D >NUL

bzw.

NET USE X: /delete >NUL

freigegeben.

Der Nutzer erhält beim Login automatisch ein AFS-Token, wenn das Paßwort für Windows NT mit dem AFS-Paßwort identisch ist. Wir empfehlen diese Übereinstimmung unerfahrenen Nutzern.

Nutzer, die immer genau unterscheiden können, welches Paßwort verlangt wird, können in allen drei Systemwelten (UNIX, AFS, Windows NT) verschiedene Paßworte verwenden.

(Prinzipiell kann das AFS-Filesytem natürlich auch im Fenster "Arbeitsplatz" durch den Button "Netzlaufwerk verbinden" montiert werden.)

Leider ist folgende Konstruktion beim "net use" nur dem Administrator unter Verwendung von Submounts erlaubt:

\\%computername%-afs\pfadname

Deshalb ist es im Loginscript eines nicht privilegierten Nutzers unmöglich, ein anderes AFS-Verzeichnis außer AFS-Root als Netzlaufwerk zu mounten.

• er kann sein AFS-Paßwort nicht von Windows NT aus ändern
• er kann keine AFS-Gruppen bilden

Zur Realisierung dieser Aktionen muß sich der Nutzer an einem UNIX-System anmelden.

Mit AFS3.5 stehen die gleichen Kommandos wie in der UNIX-Welt zur Verfügung (kpasswd und pts), die in einer DOS-Box einzugeben sind.

Andere Fileserverlösungen sind:

• SAMBA-Server : Die Filesysteme aus der UNIX-Welt (AFS, NFS) können unter Windows NT verfügbar gemacht werden
• • Vorteil: keine zusätzliche Softwarekomponente an der Workstation (Kosten); der SMB-Server (Programme: smbd und nmbd) ist freie Software
  • Nachteile: geringere Performance, gegenseitige Beeinflussung, Sicherheitsbedenken (Paßwortübertragung im Klartext, AFS-Token nicht lokal), für etwa 20 Klienten ist ein Server nötig (relativiert das Kostenproblem)

• NT- oder Netware-Server: entscheidender Nachteil: jeder Nutzer besitzt im UNIX und unter Windows NT je ein HOME-Verzeichnis (doppelte Verwaltung, doppelte Bereitstellung von Plattenspeicherkapazität, zweimal Backup, usw.)

4.2.2. Bereitstellung der HOME-Verzeichnisse

Damit der Nutzer sein HOME-Verzeichnis als Laufwerk sieht, verwenden wir im Systemloginscript folgende Anweisung:

SUBST H: U:\tu-chemnitz.de\home\urz\d\dgr

Aufgrund der Struktur unseres Teilbaumes für HOME-Verzeichnisse ist die vorletzte Komponente des Pfadnamens variabel (Anfangsbuchstabe des Nutzerkennzeichens). Da die BATCH-Programmierung unter Windows NT unflexibel wie im DOS ist, mußte die SUBST-Anweisung in einem kleinen C-Programm realisiert werden.

In jedem Benutzerkonto ist als BASIS-Verzeichnis (MS-Vokabel für HOMEDIR) das lokale Laufwerk H: einzutragen.

4.2.3. Bereitstellung der Anwendungssoftware

Anwendungspakete werden so installiert, daß sie - soweit wie möglich - im AFS stehen.

Den Zugriff auf die entsprechenden AFS-Verzeichnisse erlauben wir einer AFS-Gruppe, deren Mitglieder IP-Adressen sind.

Wir hatten geplant, den AFS-Pfad, in dem alle Anwendungen stehen, einem Laufwerksbezeichner zuzuweisen. Diese Zuweisung sollte - analog zum HOME-Verzeichnis - mit SUBST erfolgen.

Dabei traten aber folgende Probleme auf:

• Der Lizenzmanager arbeitete nicht einwandfrei.
• Benutzerprofile werden nicht geschlossen und auf den Server zurück kopiert, sobald eine Anwendung, die sich auf einem substituierten Laufwerk befindet, Angaben ins Benutzerprofil einträgt.

Alle Files, die zu Anwendungen gehören und im AFS stehen, müssen deshalb durch den vollständigen Pfadnamen (ausgehend von AFS-Root = U:) referenziert werden.

Viele Anwendungen tragen bei der Installation Werte in die Registrier-Datenbank ein. Dort kann alles gespeichert werden, was irgendwie konfigurierbar ist. Die meisten Eintragungen erfolgen in den Hauptschlüsseln "HKEY_LOCAL_MACHINE" und "HKEY_CURRENT_USER".

Die Eintragungen in "HKEY_LOCAL_MACHINE" lassen sich (ebenso wie die bei der Installation lokal abgelegte DLL's, Fonts, usw.) mittels SMS auf alle Poolmaschinen verteilen.
Darauf wird in einem späteren Kapitel noch eingegangen.

Die Eintragungen im "HKEY_CURRENT_USER" muß aber jeder Nutzer durch ein individuelles Setup selbst durchführen.

Es läst sich einrichten, daß im Startmenü neben dem Applet zum Start der Anwendung eine zweite Schaltfläche für das individuelle Setup angeboten wird. Diese müßte der Benutzer einmalig vorm ersten Aufruf einer Anwendung anklicken.

Da wir davon ausgehen, daß es dabei zu vielen Fehlbedienungen kommen würde, sind wir bei allen Anwendungen, für die es sich realisieren lies, wie folgt vorgegangen:

• Jede zu konfigurierende EXE wird umbenannt und durch ein selbstgeschriebenes C-Programm ersetzt.
• Dieses Programm registriert im HOME-Verzeichnis bzw. in HKEY_CURRENT_USER, welche Setups der Nutzer bereits durchgeführt hat.
• Ist für die (scheinbar) gestartete Anwendung ein individuelles Setup erforderlich, wird es eingeschoben, indem zunächst das dazugehörige Konfigurationsscript ausgeführt wird. Dieses Script enthält die erforderlichen Regedit-Kommandos, erstellt Subverzeichnisse im HOMEDIR, kopiert Files ins HOMEDIR ....
• Danach wird die eigentliche EXE mit dem (modifizierten) Namen gestartet.
• Falls ein README-File vorhanden ist, wird es angezeigt.

Aber nicht jede Anwendung erlaubt es, daß sie unter einem anderen Namen gestartet wird. In diesem Fall rufen wir aus dem Startmenü unser C-Programm nicht mit Namen der Anwendung auf. Das hat leider zur Folge, daß die Anwendung nicht individuell konfiguriert werden kann, wenn sie bei der erstmaligen Verwendung über eine Dateiverknüpfung angeklickt wird.

4.2.4. Benutzerprofile

Benutzerprofile werden zum Speichern von Einstellungen benutzt, die der Anwender bei seiner Arbeit am PC vornimmt. Dadurch findet der Nutzer bei jeder weiteren Anmeldung die gleiche Arbeitsumgebung vor.

Es wird zwischen veränderlichen und verbindlichen Benutzerprofilen unterschieden.

• Wird mit einem veränderlichen Profil gearbeitet, findet der Nutzer den PC bei der erneuten Anmeldung so vor, wie er ihn verlassen hat.
• Setzt er ein verbindliches Profil ein, sieht der PC bei jedem Login gleich aus. Einstellungen, die während der Sitzung erfolgen, werden nicht gespeichert.

Folgendes wird im Benutzerprofil festgehalten:

• Informationen zur Konfiguration des Arbeitsplatzes, des Dateimanagers, des Explorers und des Desktops
• Einstellungen der Task-Leiste
• Anordnung des Startmenüs
• die zuletzt verwendeten Dokumente
• Konfigurationsparameter der MS-DOS-Console
• Verbindungen zu Netzwerkdruckern
• benutzerspezifische Einstellungen der Systemsteuerung
• Lesezeichen der Online-Hilfe
• Eintragungen im Registry-Schlüssel "HKEY_CURRENT_USER"
• Anwendungsdaten

Das Benutzerprofil ist ein Verzeichnis, das folgende Ordner und Files enthalten kann:

Neben den Ordnern, mit denen die Einstellungen des Desktops, der Taskleiste incl. des Startmenüs beschrieben werden, befindet sich im Benutzerprofil das File NTUSER.DAT. Es enthält die Einstellungen aus dem Registry-Schlüssel "HKEY_CURRENT_USER".

(Ein Benutzerprofil wird übriges verbindlich, wenn die Datei NTUSER.DAT in NTUSER.MAN vom Administrator umbenannt wird.)

Während einer NT-Sitzung befindet sich das Profil auf der lokalen Festplatte im Verzeichnis %SYSTEMROOT%\PROFILES\benutzername. Einstellungen, die der Nutzer durchführt, werden (zunächst) dort registriert.

Es muß zwischen

• lokalen Benutzerprofilen und
• servergespeicherten Nutzerprofilen

unterschieden werden. Der wesentliche Unterschied besteht darin, daß bei einem servergespeicherten Benutzerprofil die lokale Version des Profiles auf einen Server kopiert wird, sobald sich der Benutzer vom System abmeldet. Servergespeicherte Profile werden verwendet, wenn ein Benutzer an jeder Arbeitsstation der Domain die gleiche Umgebung vorfinden soll.

Das Benutzerprofil wird bei der Anmeldung eines Benutzers geladen, d.h. der Profileordner wird auf die Workstation kopiert (wenn es sich um ein servergespeichertes Profil handelt) und die Informationen aus NTUSER.DAT werden in den Registry-Schlüssel "HKEY_CURRENT_USER" übernommen. Bei der ersten Anmeldung wird das Nutzerprofil aus einem Standardprofil, das sich auf jedem NT-PC befindet, erstellt. Die Datei NTUSER.DAT wird dabei aus dem Ordner %SYSTEMROOT%\PROFILES\Default User entnommen. Der Administrator kann die Originaldatei durch eine bereits modifizierte Datei NTUSER.DAT ersetzen. Diese kann z.B. ein Nutzerprofil enthalten, in dem die Netzwerkdrucker bereits eingerichtet sind und der Arbeitsplatz sinnvoll konfiguriert ist.

Wir setzen veränderliche, servergespeicherte Profile ein, die jedem Nutzer individuell zugeordnet sind.

Das Benutzerprofil wird im HOMEDIR des Nutzers im VerzeichnisH:\PUBLIC\NT\PROFIL gespeichert. Es befindet sich damit ebenfalls im AFS.

Gegenüber der Speicherung des Profils auf dem PDC (oder einem anderen NT-Fileserver) ergeben sich einige Vorteile:

• auf dem PDC muß immer ausreichend Speicherplatz verfügbar sein
• das Verzeichnis muß mit einem separaten Backupverfahren regelmäßig gesichert werden
• für den Verbindungsaufbau zwischen der WS und dem PDC beim Logout sind freie Klientenlizenzen erforderlich
• der PDC muß immer verfübar sein
• häufig funktionierte das Rückschreiben des Profiles beim Logout nicht

Das zuletzt genannte Problem ist besonders verhängnisvoll, weil es dadurch zu Differenzen zwischen den tatsächlich im Registry-Schlüssel  "HKEY_CURRENT_USER" eingetragenen Informationen und unseren Flags in H:\PUBLIC\NT\sw_inst kommt.

Das Problem kann auch im AFS auftreten, falls beim Logout die Gültigkeit des AFS-Tokens nicht lange genug verzögert wird. Zum Zeitpunkt des Schreibens ist dann der Nutzer bereits "system:anyuser" - ohne Schreibrechte für sein HOMEDIR. Abhilfe schafft folgender Eintrag im Registry-Key: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters:

LogoffTokenTransferTimeout=30

Weitere Gründe für das Scheitern des Rückschreibens eines Benutzerprofiles sind:

• das Erreichen der Quota
• volle Festplatte (Partition)
• keine freie Lizenz zum Verbindungsaufbau Workstation --> Server
• Der Nutzer kann sein Profil auch zerstören, wenn er sich an mehreren Workstations gleichzeitig anmeldet und die Abmeldung nicht nacheinander vornimmt.

4.3. Benutzerkonten

Jeder Benutzer muß über ein Benutzerkonto verfügen, damit er sich beim System anmelden kann.

Wir wollten möglichst ohne eine weitere Benutzerverwaltung (neben AFS und UNIX) auskommen. Es gab deshalb Überlegungen, daß sich der Benutzer gegenüber der Windows NT Workstation als "Gast" anmeldet und die eigentliche Authentifizierung im Loginscript gegenüber AFS erfolgt.

Das Benutzerkonto wird aber nicht nur zur Authentifizierung benötigt, sondern auch zur Zuordnung von Profilpfad und Homeverzeichnis. Beides läßt sich später (im Loginscript eines anonymen Nutzers) nicht mehr "umdefinieren".

Wir mußten deshalb eine Windows NT Domain mit einem PDC und einem BDC einrichten.

In der Domain existiert für jeden Nutzer ein Benutzerkonto.

Es enthält allgemeine Verwaltungsinformationen wie Name und Vorname sowie Regeln zur Gültigkeit des Nutzerpaßwortes.

Jeder Benutzer besitzt eine interne ID. Die ID von gelöschten Benutzerkonto wird nicht wieder benutzt ---> ein Nutzerkonto, das gelöscht und erneut angelegt wird, erhält nicht die gleiche ID.

Jeder Benutzer ist Mitglied von verschiedenen Gruppen:

Als Profilname ist die Angabe H:\PUBLIC\NT\PROFIL nicht möglich, weil zum Zeitpunkt des Nutzerprofil-Ladens das Scheinlaufwerk H: noch nicht existiert. Der Laufwerksbuchstabe H: wird im Login-Script erst später substituiert.

Als HOMEDIR kann dagegen H: angegeben werden.

Das Anmeldescript wird bei jedem Login des Benutzers ausgeführt. Es kann ein Stapelprogramm (BAT oder CMD) oder ein ausführbares Programm (EXE) sein.
Im Benutzerkonto steht als Anmeldescriptname ein relativer Pfadname. Er bezieht sich auf das Verzeichnis %WINDIR%\SYSTEM32\REPL\IMPORT\SCRIPTS des Computers, der die Echtheitsbestätigung beim Login vornimmt (entspricht der Freigabe NETLOGON).
--> das Anmeldescript muß auf jedem Domain-Controller stehen !

Der lokale Pfad wird nach dem erfolgreichen Login eines Benutzers in die Variablen %HOMEDRIVE% und %HOMEPATH% eingetragen.

Alle Nutzer haben nur eine zeitbefristete Nutzungsberechtigung, deren Ende im Benutzerkonto eingetragen wird.

Die Benutzerkontendatenbank steht im File: %WINDIR%\SYSTEM32\CONFIG\SAM
Die Größe, die dieses File annehmen kann, richtet sich vor allem nach der Größe der Registrierdatenbank. Dieser Wert kann unter Systemsteuerung --> System --> Leistungsmerkmale --> Ändern modifiziert werden.

Folgende Kalkulation für die zu erwartende Größe des Files kann aufgestellt werden (Quelle: lutz.mueller-hipper@human-network.com):

• 1024 Byte pro Nutzerkennzeichen
• 0512 Byte pro Workstation in der Domain
• 0512 Byte pro globale Benutzergruppe
• 0012 Byte pro Mitglied einer globalen Gruppe
• 0512 Byte pro lokale Benutzergruppe
• 0036 Byte pro Mitglied einer lokalen Gruppe

Microsoft gibt folgende Richtwerte an:

Zu beachten ist, daß der Speicherplatz von gelöschten Accounts nicht selbständig wieder freigegeben wird.

Die separate Sicherung der Benutzerdatenbank ist mit den Tools regback und regrest aus dem Windows NT Ressource Kit möglich. Beim regback werden die gelöschten Accounts nicht gesichert --> der okkupierte Speicherplatz kann so freigegeben werden.

Vermutlich kann regrest nur an der Maschine ausgeführt werden, an der auch regback erfolgte. Beim Restore des PDC (nach einem Plattencrash) wollten wird die aktuelle Benutzer- und Computerdatenbank auf diesem Weg vom BDC übernehmen. Wir glaubten damit alle Änderungen, die seit Erstellung der Datensicherung stattfanden, schnell nachvollziehen zu können. Das war leider ein Irrtum! (siehe Abschnitt 4.6)

Ein Werkzeug zum Prüfen der Integrität der SAM (analog pwck aus der UNIX-Welt) existiert (vermutlich) nicht.

Vorsicht ist auch bei der Wahl der Benutzerkennungen geboten. Mir ist leider keine Liste jener Bezeichner bekannt, die nicht benutzt werden sollten.
Wir hatten z.B. Probleme mit der Kennung "nul", die für einen Nutzer namens Naumann, Ulf von unserer Datenbank generiert worden war. Das WinNT-Benutzerkonto wurde ohne Beanstandung angelegt (einschließlich der Angaben für das Basisverzeichnis und den Pfad für das Benutzerprofil). Der Nutzer konnte sich aber nicht anmelden, weil der lokale Profilordner C:\WINNT\PROFIL\NUL nicht angelegt werden kann. Es besteht offenbar ein Konflikt mit dem Gerätename "NUL". Unklar ist allerdings, warum für Unterverzeichnisse und Gerätenamen, der gleiche Namensraum benutzt wird.

4.4. Systemrichtlinien (Policies)

Systemrichtlinien sind Zusammenstellungen von Konfigurationsparametern. Sie erlauben die zentrale Vorgabe von Registry-Einstellungen. Der Administrator kann damit allgemeingültige Einstellungen vornehmen und Benutzer bzw. Computer mit Restriktionen versehen.

Das Programm zur Konfigurierung der Systemrichtlinien gehört nur zur NT-Server-Version. Es wird gestartet über Start --> Programme --> Verwaltung --> Systemrichtlinien-Editor (oder unter Ausführen: poledit)

Der Systemrichtlinieneditor kann nur bestimmte Registry-Einträge bearbeiten und kennt zwei Betriebsmodi:

• Registry-Modus: die Systemrichtlinien werden direkt in die Registrierdatenbank eingetragen.
• Dateimodus: die Systemrichtlinien werden in einer Datei gespeichert.

Standardmäßig werden Systemrichtlinien in die Datei NTCONFIG.POL eingetragen.Diese Datei muß in der Freigabe NETLOGON auf jedem Domaincontroller stehen.

Diese Datei kann mit dem Systemrichtlinieneditor bearbeitet werden.

Der Administrator kann Computer, Benutzer und -gruppen benennen, für die Systempolicies gelten sollen. Leider lassen sich Computer nicht zu Gruppen zusammenfassen, d.h. für alle Workstations, die anderen Richtlinien unterliegen sollen als der Standardcomputer, müssen Policies einzeln angelegt werden.

Benutzer- und Computerrichtlinien lassen sich kopieren.

In der Benutzerrichtlinie lassen sich eine Fülle von Restriktionen festlegen.

Vorsicht ist aber bei Einschränkungen für den Standardcomputer bzw. den Standardbenutzer geboten, denn diese gelten auch für Administratoren!

Die benutzerspezifischen Einschränkungen betreffen:

Es kann z.B. festgelegt werden, daß die Mitglieder der Gruppe "pool_user"

• in der Systemsteuerung --> Anzeige die Bildschirmauflösung nicht verändern dürfen
• ein bestimmtes Hintergrundbild und Farbschema erhalten
• Programme, mit denen die Registry editiert werden kann, nicht benutzen dürfen (sehr inkonsequent, weil der Nutzer andere Programme (z.B. ein selbst entwickeltes), welche die Registry modifizieren, trotzdem ungehindert benutzen darf)
• nur benannte Programme ausführen können
• ....

Ferner kann vorgegeben werden, in welchen Verzeichnissen benutzerdefinierte Programme, Desktop-Symbole, Startmenü usw. liegen

Anmerkung: Vor der Variable %HOMEPATH% steht noch %HOMEDRIVE%

Weitere mögliche Einschränkungen sind:

Die computerspezifischen Einschränkungen betreffen:

Unter Netzwerk --> Aktualisierung der Systemrichtlinien wird festgelegt, ob Systemrichtlinien eingesetzt werden und wie das Policy-File heißt, das die Systemrichtlinie enthält (Standard: NTCONFIG.POL).

Für unsere Technologie sind diese Einstellungen, auf die im Kapitel "Workstationkonfiguration" weiter eingegangen wird, sehr wichtig.

Beim Anmelden eines Benutzers überschreiben die Eintragungen aus den Systempolicies die Einstellungen der lokalen Registry. Für viele Parameter kann der Administrator deshalb 3 Werte vorgeben:

• aktiviert (Haken)
• deaktiviert (weißes Feld)
• keine Änderung (graues Feld)

Grau dargestellte Felder in der Systemrichtlinie, lassen den ursprünglichen Wert unverändert.

Da ein Nutzer mehreren Gruppen angehören kann, für die eine Systemrichtlinie existiert, sind für diesen Nutzer Richtlinien denkbar, die sich widersprechen. Eine Option kann z.B. für die Gruppe "pool_user" deaktiviert, für die Gruppe "sw_adm" dagegen aktiviert sein.

Welche Gruppe den Vorrang besitzt, wird mit der Gruppenpriorität geklärt. Sie wird so festgelegt:

4.5. Drucken

Eine wichtige Forderung bei der Einführung von Windows NT im URZ war die vollständige Integration der in der UNIX-Umgebung vorhandenen Drucker und die uneingeschränkte Anwendung des Abrechnungssystems.

Windows NT unterscheidet:

• lokale Drucker, die meist an der parallelen Schnittstelle eines Druckservers angeschlossen sind.
  Jeder NT-Server und jede NT-Workstation kann als Druckserver eingesetzt werden.
• Netzwerkdrucker, die eine eigene Netzkarte besitzen. Sie werden über das Netzwerk vom Druckserver angesprochen.

Ein Druckserver kann sowohl lokale als auch Netzdrucker bedienen. Der Druckertreiber wird nur auf dem Druckserver installiert und (wenn es sich um einen Netzdrucker handelt) automatisch auf die Arbeitsstationen kopiert.

Der eigentliche Druckvorgang zerfällt in zwei Teile:

• Übertragung des Files von der Anwendung zum Spooler (das Anwendungsprogramm ist beschäftigt)
• Übertragung der Daten von Spooler zum Drucker (im Hintergrund)

Ein lokal angeschlossener Drucker wird so eingerichtet:

Die Schnittstelle, an die der Drucker angeschlossen ist, muß ausgewählt werden.

Der Drucktyp ist auszuwählen, damit die richtigen Treiber geladen werden.

Abschließend muß noch entschieden werden, ob der Drucker freigegeben werden soll und ob eine Testseite zu drucken ist.

Bevor das funktioniert muß die Druckerverbindung im Registry-Schlüssel "HKEY_CURRENT_USER" eingetragen sein.

Dazu benutzt der Anwender aber nicht etwa "regedit", sondern er verfährt so .

Die im Netz vorhandenen Drucker binden wir wie folgt ein:

Auf einem Domain-Controller wurde der Microsoft TCP/IP-Druckdienst installiert.
Systemsteuerung --> Netzwerk --> Dienste --> Hinzufügen

Damit steht als Druckeranschluß der LPR-Port zur Verfügung (am Arbeitsplatz - nicht als Netzwerkdrucker! ) .

Man kann diesen Port wie eine parallele oder serielle Schnittstelle verwenden. Der entsprechende Anschluß ist hinzufügen:

Über diesen Port kann nun auf einen vorhandenen Drucker zugegriffen werden.

Der dem Druckertyp entsprechende Treiber muß geladen werden. Viele Treiber befinden sich auf der Windows NT Installations-CD.

Der Drucker erhält einen NetBIOS-Namen.

Und wird unter dem gleichen Namen freigegeben.

Im Window "Drucker" wird der neue Drucker angezeigt.

Wichtig ist noch die Einstellung folgender Eigenschaften:

Diese Eintragungen dienen "nur" zur Information der Benutzer.

Ohne folgende Einstellung verschwinden Druckaufträge.

Aber so geht es:

4.6. Serverbackup

Unser Betreben war es, auf den Domain-Controllern für Windows NT so wenig wie möglich Files zu halten, die periodisch zu sichern sind.

Die kritischsten Daten stehen in der Benutzerkonten-Datenbank des Primary-Domain-Controllers.
Diese werden automatisch auf jedem Backup-Domain-Controller repliziert.

Fällt der PDC nur kurz aus (er muß z.B. mal wieder gebootet werden), existieren noch die BDC zur Überwachung der Domain. Allerdings kann die Domain in dieser Zeit nicht verwaltet werden. Das Anlegen von Benutzerkonten, das Ändern von System-Richtlinien und Benutzerpaßworten ist z.B. ohne PDC nicht möglich.

Bei längerem Ausfall des PDC kann jeder BDC zum PDC hochgestuft werden - die Verwaltung der Domain ist dann wieder möglich. Das Hochstufen geschieht unter Startmenü --> Programme --> Verwaltung --> Server-Manager.
Diese Maßnahme kann auch notwendig werden, wenn nach einem Plattencrash das (hoffentlich vorhandene) Backup auf dem PDC eingespielt werden muß. Die Maschine insbes. die SAM hat danach den Modifikationsstand vom Zeitpunkt der Anfertigung der Datensicherung. Alle Änderungen an Benutzer- und Computerkonten, die zwischenzeitlich erfolgten, werden nachvollzogen, indem man einen BDC zeitweise zum PDC erklärt. Die genaue Vorgehensweise ist der FAQ-Liste von http://www.ntfaq.com entnommen.

Bei der Rückkehr des ursprünglichen PDC sollte Windows NT erkennen, daß bereits ein PDC läuft. Der alte PDC müßte automatisch zum BDC rückgestuft werden. Bevor der ursprüngliche PDC wieder "ans Netz geht", kann aber auch so verfahren werden:

Anschließend kann der ursprüngliche PDC (der nach dem Ausfall zum BDC wurde) wieder seine eigentliche Stellung einnehmen. Dabei ist wie oben beschrieben vorzugehen. Der BDC der "aushilfsweise" PDC war, wird dabei automatisch BDC.

Zum Sichern der Systemplatten setzen wir GHOST von Symantec ein (siehe http://www.symantec.com/region/de/schonzeit/). Dabei fertigen wir ein Abbild der Festplatte oder der Partition an und brennen dieses auf eine CD. Das Abbild wird unter MS/DOS mit der GHOST.EXE erstellt. Das MS/DOS-System, die erforderlichen Driver sowie die genannte GHOST.EXE passen auf eine Diskette von der wir beim Sichern des Systems und beim evtl. notwendigen Restore booten.

Das Backup-Programm, das zu den Tools der NT-Verwaltung gehört, ist zum Sichern der Systempartition nicht geeignet. Beim Schreiben der Platte auf Band wird bei einigen Files festgestellt, daß diese exklusiv geöffnet sind und von keinen weiteren Prozeß gelesen werden dürfen. Die betreffenden Files werden von der Datensicherung ausgeschlossen.
(Ich kann nicht einschätzen, ob man notfalls auf die Sicherung der betreffenden Files verzichten könnte, z.B. weil sie auf der NT-Installations-CD stehen. Da keine bootfähigen Bänder erstellt werden können, muß - bevor überhaupt eine Bandsicherung eingelesen werden kann - zuvor ein funktionsfähiges System installiert sein, das sofort vom Band wieder überschrieben würde. Eine derartige Verfahrensweise ist ohnehin unpraktikabel!)

Dieses Tool kann deshalb nur für Platten und Partitionen genutzt werden, die z.B. Nutzerdaten oder Anwendungsprogramme enthalten. Die Handhabung ähnelt der des Dateimanagers.

Gestartet wird die Bandsicherung über
Startmenü --> Verwaltung (Admin) --> Bandsicherung

Das Fenster Laufwerke ist zu öffnen.
Die Bandsicherung beginnt mit der Auswahl der zu sichernden Daten. Nachdem alle Objekte "angeklickt" sind, kann auf die Schaltfläche Sicherung gedrückt werden.

Befindet sich bereits ein Band im Laufwerk, erscheint folgende Dialogbox.. Sie zeigt Informationen zum eingelegten Band an. Der vorgeschlagene Bandname kann geändert werden.

Es erfolgt noch eine letzte Warnung, ob das Band überschrieben werden darf.

Über den Fortgang der Bandsicherung wird ständig informiert.

Restore vom Band

Bevor Daten von einem Band restauriert werden können, muß die Backup-Software einsatzfähig sein. Das bedeutet, daß z.B. bei einem totalen Plattencrash erst das Betriebssystem komplett installiert werden muß. Im Anschluß sind die Treiber für das Bandlaufwerk zu laden.

Beim Restore mit NTBACKUP.EXE ist zunächst das Sicherungsband ins Laufwerk zu legen und das Fenster Bänder zu öffnen.

Die rückzustellenden Files / Verzeichnisse / Laufwerke sind auszuwählen.

Nach Betätigung der Schaltfläche "Wiederherstellen" wird das Band gelesen.

4.7. Accounting

Um Daten über die Auslastung der PC's zu erhalten, stellen wir im Benutzermagager unter Richtlinien --> Überwachen folgendes ein:

Im Ereignisprotokoll der Domain-Controller werden diese Vorgänge aufgezeichnet. Diese Protokolle findet man unter Startmenü --> Programme --> Verwaltung (allgemein) --> Ereignisanzeige

Es besteht die Möglichkeit dieses Protokoll als ASCII-File abzulegen.

Allerdings ist dieses File sehr kryptisch aufgebaut. Jeder Verbindungsaufbau wird aufgezeichnet.

Wir setzen einige selbst entwickelte Scirpts ein, um dieses Protokoll ins wtmp-Format (aus der UNIX-Welt) zu transformieren. Pro PC entsteht ein ASCII-File mit diesem Aufbau:

tott#console#local#Thu#Jan#15#19:02#19:04#(00:02)
otto#console#local#Fri#Jan#16#07:17#07:20#(00:03)
jwin#console#local#Fri#Jan#16#07:21#07:24#(00:03)

Somit können alle weiteren Statistiken mit den gleichen Tools vorgenommen werden.

Zur Homepage des URZ Dietmar Grunewald , Dezember 1999, letzte Änderung:  04.09.2001

Ursula Riedel 05. April 2003	Technische Universität Chemnitz, Straße der Nationen 62, 09107 Chemnitz Impressum - Copyright © 2005 by TU Chemnitz, URZ, alle Rechte vorbehalten.	Druckansicht