OSSOS
- Netzwerk-Hilfen Stand: 21.02.2019
OSSOS
- Netzwerk-Hilfen Labs
Zur OSSOS - Homepage
BImport ist innerhalb und außerhalb der Musterlösung einsetzbar.
Kurzbeschreibung: (Aktuelle
Version: BImport 4.23) für paedML-Novell-4.x / 3.x freigegeben
(Vorversion 2.x: BImport 2.55) für ML-2 freigegeben, siehe hier.
Registrierung und Nutzungsbestimmung
(Achtung: Auch Schulen, die BImport 3/4 kostenlos nutzen dürfen, benötigen
Lizendaten. Informationen dazu liegen der paedML Novell ab Version
3.0 für baden-wüttembergische Schulen bei. Falls Sie diese Lizenzdaten
nicht über das LMZ beziehen können, können Sie sich an den Programmautor
wenden. ->Einzelheiten der Lizenzdatenvergabe).
Entwicklung der Versionen von BIMPORT: bimport_history.txt
Update und Vollversionen siehe: bimport_download.html
Achtung: Die Version 4.x erfordert neue Lizenzdaten! Nutzer der paedML-Novell-3.x können BImport 3.x weiter nutzen.
0 Inhalt
Vorwort
Konzept von BIMPORT
Installation von BIMPORT
Voraussetzungen: eDirectory:Container und Template
Voraussetzungen: Dateisystem: HOME-Verzeichnis
Voraussetzungen: Klassen-Container
Erzeugung der Datenquelldatei
Anlegen der Benutzer mit BIMPORT
ACL-Attribut
Löschen der Benutzer mit BIMPORT (mit Datenquelldatei)
Versetzung mit BIMPORT
Benutzer-Abgleich in der Musterlösung
Benutzer-Update (ohne Datenquelldatei)
Löschen der Benutzer (ohne Datenquelldatei)
Ändern eines Benutzernamens
Export von Benutzerdaten aus dem eDirectory für BIMPORT und GroupWise
Mehrere Server im eDirectory-Baum
Weitere Eigenschaften von BIMPORT
Lizenzdaten
Lizendaten nach abgelaufenem Ablaufdatum setzen
Dialoge in BIMPORT
BImport-3/4 ist eine Neuentwicklung. Sie umfasst alle Leistungen der Vorgängerversion 2.x und stellt neue Leistungen bereit. Neben einem neuen Layout im LMZ-Design, im BImport-Design oder im weitgehend frei einstellbaren Design und der Wahl der Sprache Deutsch oder Englisch gibt es an Neuerungen
 |
 |
 |
|
BImport im LMZ-Design, im BImport-Design (jeweils deutsch) und im BImport-Design (englisch). |
|
Im Folgenden wird dieses Manual auf Basis der Musterlösung paedML-Novell beschrieben. Die Rede ist also von Schülern, Lehrern usw... Natürlich ist BImport auch unabhängig von einer Schulumgebung einsetzbar. Statt Schülern, Lehrern setze man dann das allgemeine Wort Benutzer. Auch andere hier schulbezogen beschriebene Aspekte sind entsprechend umzusetzen.
Scheut man die Einrichtung individueller Accounts, also auch für jeden Schüler, so bleiben nur gruppenbezogene Benutzermodelle. So könnte sich z.B. jeder Schüler einer bestimmten Klasse mit demselben Usernamen und demselben Passwort einloggen. Es gäbe dann auf Schülerseite nur so viele Accounts, wie es Klassen gäbe. Die Nachteile solcher Modelle liegen auf der Hand. So verlangen solche Modelle z.B. ein kooperatives Verhalten gegenüber Mitschülern der Klasse, die ja ihre Dateien im jeweils gleichen "Homeverzeichnis" ablegen müssten. Auch sind individuelle Email-Adressen nicht aus dem Usernamen ableitbar.
Die Lösung der daraus entstehenden Schwierigkeiten besteht nun doch im Anlegen individueller Accounts für jeden Benutzer des Netzwerks. Daraus ergibt sich jedoch sofort die Frage, wie man mit vertretbarem Aufwand 500 oder gar 2000 Schülern einen eigenen Account einrichtet.
Hier hilft uns das Programm BIMPORT, das in der Lage ist, viele Benutzer "auf einen Rutsch" in das eDirectory (NDS) einzutragen, zu ändern oder zu löschen. BIMPORT bezieht die Daten der einzutragenden Benutzer aus einer Textdatei. Eine INI-Datei beschreibt die Struktur der Textdatei und den Importvorgang.
Die Benutzerdaten, aus denen die Textdatei besteht, kommen dabei in aller Regel aus der Schülerverwaltung. Tipps zu einem solchen Export werden weiter unten gegeben. Ebenso diskutieren wir Fragen zur Existenzdauer, Versetzung, usw.. ebenfalls weiter unten. Für den Moment gehen wir von einer klassenweisen Importgruppierung aus.
Was also ist zu tun ? Hier eine Übersicht:
Die folgenden Beschreibungen basieren auf der Struktur der Novell Musterlösung der Zentralen Expertengruppe Netze (ZEN) des Landesmedienzentrums Baden-Württemberg und gehen von folgenden technischen Voraussetzungen aus (natürlich sind auch andere Strukturen ohne weiters möglich):
| Server | GSERVER03 | |
| Volumes | DOCS | in LFB\HOME\SCHUELER befinden sich die Klassenverzeichnisse. Darunter die Schüler-Homedirectories z.B.: ...SCHUELER\KLASSE1A\SperlingH |
| DATA | in LFB\pgm\bimport befindet sich BImport.exe, bimportstart.ini, bimport.ini, bimportdesign.ini, bimportlicence.ini, ... | |
| DOCS | in LFB\home\verwalter\benadmins\benutzer befinden sich eine oder mehrere bimport.ini und weitere Datendateien |
| eDirectory | OU Schueler.Benutzer.LFB.Schulen.ml3 | KLASSE1A |
| KLASSE1B | ||
| ... |
Da die Musterlösung 3+4 mehrschulfähig ist, werden zur Schulunterscheidung Schulkürzel benutzt. Hier ist dies beispielhaft LFB.
(BImport benötigt Lizenzdaten, falls es nicht nur als Demoversion getestet werden soll.)
BImport benötigt keine Installation, sondern muss lediglich in die gewünschten Verzeichnisse kopiert werden. Dazu gibt es zwei grundsätzliche Möglichkeiten:
1.Alles in ein Verzeichnis:
Man entpacke die ZIP-Datei in ein Verzeichnis, auf das der Verwalter von BImport
mindestens RWCEMF-Rechte hat. Damit kann er dann auch die INI-Dateien anpassen
und abspeichern.
(
In der Musterlösung 3+4 ist dies das Verzeichnis DATA\LFB\pgm\BImport (mit der Beispielschule LFB). Darauf hat allerdings der BenAdmin nur RF-Rechte.)
2. Programm in schreibgeschütztes, Daten in schreiberlaubendes Verzeichnis:
Der Admin oder ein Programm-Admin entpackt die komplette ZIP-Datei in das schreibgeschützte Verzeichnis, also z.B. in DATA\LFB\pgm\BImport. Von dort wird NICHTS verschoben! Damit liegen dort auch das Manual, Nutzungbestimmungen, Link auf die BImport-Homepage, Designdatei, Lizenzdatei und eine DEFAULT-bimport.ini, die immer dann greift, wenn etwas mit der bimportstart.ini nicht stimmen sollte.
In der bimportstart.ini wird nun diejenige INI-Datei eingetragen, die beim Aufruf von BImport wirken soll. Man kopiere also zuvor die bimport.ini in ein nicht-schreibgeschütztes Verzeichnis, in dem später auch die Schülerdaten bearbeitet werden sollen, also am besten in ein spezielles Verzeichnis des Benutzer-Admin BenAdmin, der sich um die Belange der Benutzerverwaltung kümmern soll. In bimportstart.ini trage man hinter den Schlüssel BImportINI den Pfad und Dateinamen eben dieser bimport.ini ein. Diese bimport.ini z.B. im Verzeichnis benutzer des BenAdmin sei inzwischen z.B. in bimport_schueler.ini umbenannt worden. Dann würde also in bimportstart.ini z.B. eingetragen:
BImportINI=\\Gserver03\DOCS\LFB\home\verwalter\benAdmins\benutzer\bimport_schueler.ini
In diesem Verzeichnis liegen dann später auch die Datenquelldatei, Logdateien, usw... (siehe weiter unten), mit denen der BenAdmin arbeiten wird.
Will der BenAdmin mit verschiedenen BImport-INI-Dateien arbeiten, so kann er über das Menü "Datei/Öffne INI-Datei" eine andere INI-Datei auswählen. Der Öffne-Datei-Dialog führt dabei sofort in das Verzeichnis, aus dem die zuletzt benutzte INI-Datei aufgerufen wurde, also in das Richtige.
Damit ein anderer Benutzer als der Admin (hier der BenAdmin) überhaupt genügend Rechte hat, um mit BImport Benutzer mit diversen Eigenschaften (vor allem Volume-Restrictions oder HomeDir-Restrictions auf NSS-Volumes) zu erzeugen, muss der Admin ihm einige Rechte geben. Nach momentanem "Forschungsstand" sind dies:
| SERVER-Objekt | NETWARE 6 für Volume Restrictions |
OES Linux für Volume Restrictions |
OES Linux für HomeDir-Restrictions |
|
| Objekt-Rechte | Browse | - | - | |
| Eigenschafts-Rechte | alle Rechte bis auf Supervisor | - | - | |
| VOLUME-Objekt (alle Volume-Objekte, auf denen Volume-Restrictions vergeben werden sollen) |
Objekt-Rechte | Browse | - | - |
| Eigenschafts-Rechte | Compare, Read | - | - | |
| Volume (alle Volumes, auf denen z.B. Verzeichnisse/Dateien erzeugt/gelöscht werden sollen. Also für Datei- und Verzeichnisoperationen) |
Verzeichnis-Rechte | alle Rechte bis auf Supervisor und Access [RWCEMF] |
Supervisor [S] |
alle Rechte bis auf Supervisor [RWCEMFA] auf das zu verwaltende Verzeichnis (z.B. DOCS\LFB) |
(In OES Linux scheint die ConsoleOne 1.3.6e/h Volume Restrictions weder anzuzeigen noch zu löschen, aber setzen zu können, der iManager 2.6.0 zeigt nur Fehler an; iManager 2.7.3 scheint es zu können.)
Die entsprechenden Einstellungen am Beispiel der "Musterlösung 2 " (Novell Netware 6) sehen sie hier zur Orientierung in ConsoleOne-Darstellung:
| SERVER-Objekt | ConsoleOne-Darstellung (NETWARE 6) |
 |
|
| VOLUME-Objekt |  |
| Volume |  |
Die entsprechenden Einstellungen am Beispiel der "Musterlösung 3+4 " (Novell OES Linux) sehen sie hier zur Orientierung in ConsoleOne-Darstellung:
| SERVER-Objekt | ConsoleOne-Darstellung (OES Linux) |
| keine Einträge nötig | |
| VOLUME-Objekt | keine Einträge nötig |
| Volume | Wenn Volume Restrictions möglich sein sollen, muss der Benutzer-Admin (hier im Beispiel die OU, die Bentzer-Admins enthält), das Dateisystem Supervisor-Recht auf das gesamte Volume haben.  Sollen nur Verzeichnisbeschränkungen (HomeDir-Restrictions) möglich sein, wie es die Standardeinstellung in der ML3+4 ist, so reichen die Rechte [RWCEMFA] auf den Teil des Volumes der vom Benutzer-Admin gemanagt werden soll (hier im Beispiel LFB:  |
Ab der ML 4 wird jedoch statt ConsoleOne die Benutzung des iManagers empfohlen, mit dem diese Einstellungen entsprechend vorgenommen werden können.
In den folgenden Abschnitten beschäftigen wir uns mit der Textdatei und weiteren Voraussetzungen für den Einsatz von BIMPORT. Alle dazu erforderlichen Daten- und INI-Dateien legen wir ins Verzeichnis DOCS\Home\BenAdmin (ML2), DOCS\LFB\home\verwalter\benadmins\benutzer (ML3+4) oder ein anderes geeignetes Verzeichnis. Im Folgenden wird beispielhaft die Situation der ML3+4 benutzt. Ggf. muss dies in die eigene Situation umgesetzt werden.
3 Voraussetzungen: eDirectory:Container und Template
Das BIMPORT-Programm muss wissen, in welchen eDirectory-Container die neuen Benutzer
importiert werden sollen. Für den Schülerimport legen wir natürlich
gemäß unserer Netzwerkstruktur den Container .Schueler.Benutzer.LFB.SCHULEN.ml3
fest. Darin liegen als OUs die Klassen. Wählen wir für unser Beispiel
also .Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3.
Voraussetzung 1: Die org. Einheit .Klasse1a.... muss vor dem Importprozess erzeugt werden!
In der ML übernimmt dies die Schulkonsole, andernfalls muss dies von Hand geschehen. (Ggf. muss im Loginscript dieser OU ein Verweis auf ein "höher" liegendes Loginscript eingetragen werden, z.B.:
include .Schueler.Benutzer.LFB.SCHULEN.ml3).
Natürlich kann BIMPORT die neuen Benutzer auf Basis von Benutzer-Schablonen importieren. Hier wählen wir also ein user_template aus dem Container .Schueler.Benutzer.LFB.SCHULEN.ml3. Der Name dieser Schablone kann frei gewählt werden; wir verwenden hier den (in der paedML-Novell üblichen) Namen Template_Schueler. Falls es "zwischen" den Klassen- und dem Schueler-Container noch Container gibt, z.B. .Klasse1a.Technik.Schueler.Benutzer.LFB.SCHULEN.ml3, kann zur Ausnutzen der BImport-Eigenschaft "Parent-Template" ein Template in der "Zwischen"-OU liegen. Dies muss dann mit dem Wort Template beginnen; es folgt ein Unterstrich und dann der Name der betreffenden OU, also in unserem Beispiel Template_Technik. Es ist auch möglich, wenngleich nicht unbedingt nötig, in jeden der Klassencontainer eine eigene Schablone zu legen. Dazu müsste die "Basisschablone" z.B. in den Container .Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3 kopiert werden. Im Zusammenhang mit dem weiter unten beschriebenen Abgleich der Benutzer mit den eDirectory kann dort aber ein Template mit dem dann vorgeschriebenen Namen User_Template liegen.
Beachten Sie beim Template den Eintrag Pfad bei Basisverzeichnis. Hire muss der Pfad bis zum Oberverzeichnis der Klassenverzeichnisse eingetragen sein.
Also im Template_Schueler: <SCHULE>\home\schueler (<SCHULE> ersetzen SIe natürlich durch Ihr Schulkürzel).
Im Zwischen-Template Template_Technik in der OU Technik.Schueler.Benutzer.LFB.SCHULEN.ml3: <SCHULE>\home\schueler\Technik.
In einem User_Template z.B. in der OU .Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3 muss jedoch der volle Pfad bis zum Klassenverzeichnis benutzt werden: <SCHULE>\home\schueler\Klasse1a.
4 Voraussetzungen: Dateisystem: HOME-Verzeichnis
Vor der Verwendung von BIMPORT muss auch dasjenige Verzeichnis im Dateisystem der Festplatte erzeugt werden, in dem die HOME-Directories der neuen Benutzer erzeugt werden sollen. Wieder richten wir uns beispielhalt nach unserer Netzwerkstruktur der ML3+4 und der Schule LFB und erzeugen DOCS\LFB\home\schueler\klasse1a, DOCS\LFB\home\schueler\Technik\Klasse1a, usw.
Voraussetzung 2: Das Klassenstammverzeichnis (z.B.DOCS\LFB\home\schueler\klasse1a muss vor dem Importprozess erzeugt werden! In der ML übernimmt dies die Schulkonsole, andernfalls muss dies von Hand geschehen.
5 Voraussetzungen: Klassen-Container
Zunächst müssen, falls dies nicht durch ein Tool, wie die Schulkonsole, erfolgt, im Container Schueler.Benutzer.LFB.SCHULEN.ml3 die Klassencontainer erzeugt werden, die jeweils die Schüler einer Klasse aufnehmen sollen. Hier beschränken wir uns auf die Container Klasse1a und Klasse1b.
Erzeugen Sie die Klassencontainer Klasse1a und Klasse1b als Organisationseinheit
(OU) im Container Schueler.Benutzer.LFB.SCHULEN.ml3.
Bemerkung: Die Klassencontainer-Bezeichnungen dürfen keine Leerzeichen
enthalten (also z.B. nicht KLASSE 1A).
Tragen Sie im Login-Skript der neu erzeugten Container jeweils folgende Zeile ein:
include .schueler.unterricht
(Andernfalls wird das Loginscript des Containers Schueler nicht ausgeführt!)
6 Erzeugung der Datenquelldatei (Textdatei)
BIMPORT muss die Namen und Daten der neu anzulegenden, der zu ändernden oder zu löschenden Benutzer kennen. Dazu entnimmt es die erforderlichen Daten einer Textdatei. Diese Textdatei muss ein bestimmtes Format haben. Für jeden Benutzer gibt es dort eine Zeile, die wiederum in einzelne Felder aufgeteilt ist. Es gibt minimal 3 (oder sogar 2) und maximal 8 Felder. Die ersten 3 sind obligatorisch. (Das Klassenfeld darf dabei unter bestimmten Voraussetzungen leer bleiben oder sogar fehlen.) Um welche Felder es sich handelt, zeigt die folgende Liste:
| User Name | Login-Name |
| (Klasse) | Klassenbezeichnung |
| Surname | Nachname |
| ID | eindeutige Kennung |
| Given Name | Vorname |
| Full Name | voller Name |
| Volume Restrictions | Platzbeschränkung auf Volume (z.B.mit 40 MB). Die Vol.Restr. können auch als HomeDir-Restrictions umgedeutet werden |
| Versetzung | Leer, Leerzeichen oder Nichtversetzungskennzeichen |
Die tatsächlich benutzten Felder und deren Reihenfolge kann bei den Einstellungen in BImport festgelegt werden!
Jeder Feldinhalt wird von doppelten Anführungszeichen (Feldbegrenzer) eingeschlossen,
die Felder durch Komma (Feldtrenner) getrennt. (Feldbegrenzer und Feldtrenner können unter Einstellungen auch selbst festgelegt werden.)
Die Daten-Textdatei sieht also (mit allen
Feldern) etwa so aus:
"SperlingH","Klasse1a","Sperling","154287","Hans","Hans Sperling",".gserver03_docs.dienste:40000"
"AmselB","Klasse1b","Amsel","739745","Bettina","Bettina
B. Amsel",".gserver03_docs.dienste:40000"
...
oder optional mit Versetzungsfeld:
"SperlingH","Klasse1a","Sperling","154287","Hans","Hans Sperling",".gserver03_docs.dienste:40000","N"
(Einzelheiten zur Versetzung siehe weiter unten.)
Alternativ darf das Feld Volume Restrictions, wenn es überhaupt vorhanden ist, auch nur aus einer Zahl bestehen, also z.B. so:
"SperlingH","Klasse1a","Sperling","Hans","Hans Sperling","40000"
Da die Volume Restrictions aber im Normalfall dem Template entnommen werden, darf dieses Feld auch ganz fehlen, also z.B. so:
"SperlingH","Klasse1a","Sperling","154287","Hans","Hans Sperling"
(Bemerkung: Je nach Einstellung kann BImport die Volume Restrictions auch als Begrenzung für das jeweilige Homeverzeichnis auffassen.)
Legen Sie auf den Vornamen oder den vollen Namen keinen Wert so reicht auch z.B.:
"SperlingH","Klasse1a","Sperling","154287"
Das ID-Feld wird im Abgleich-Modus von BImport für die Musterlösung benutzt, kann aber für den normalen Import auch entfallen. Die tatsächlich benutzten Felder und deren Reihenfolge muss aber unter Einstellungen in BImport festgelegt werden.
Wollen Sie die Schüler jeder Klasse klassenweise mit einem eigenen Klassen-Template (also pro Klassencontainer) importieren (nicht empfohlen!), so reicht nun wirklich minimal z.B.:
"SperlingH","","Sperling"
ACHTUNG: Beachten Sie, dass das Klassenfeld, wenn auch leer, vorhanden sein muss !
Alles bisher über die Datenstuktur der Textdatei, also der Quelldatei, Gesagte, gilt für den Fall der Standard-Feldstruktur, wie sie besteht, wenn sie nicht über den Menüpunkt "Datei/Einstellungen 1" bzw. über den "Einstellungen"-Button geändert wurde.
Über den Button "Einstellungen" oder über das Menü "Datei//Einstellungen 1" können Sie jedoch auch eine selbstgewählte Feldstruktur erzeugen:
 Anpassungsbeispiel:  |
Markieren Sie Feldnamen und verschieben Sie sie mit Hilfe der Pfeil-Buttons zwischen den Listen. Beachten Sie dabei: In der Liste der aktiven Felder müssen die beiden Felder User und Surname stehen. Anderfalls können Sie keine INI-Datei abspeichern und weder einen Import noch ein Löschen von Benutzern durchführen. Und natürlich müssen die aktiven Felder auch wirklich Ihrer Quelldatei entsprechen! Darüberhinaus können Sie einige Sonderzeichen verändern, wenn gewünscht. Auch diese Zeichen müssen natürlich mit Ihrer Quelldatei übereinstimmen. |
Bemerkung: Gibt es kein Klassenfeld (natürlich gleichzeitig weder in der aktiven Liste noch in der Quelldatei), so ist dies gleichbedeutend mit einem leeren Klassenfeld der Form "", so wie oben beschrieben. Die Benutzer werden dann im gerade eingestellten Basiscontainer erzeugt.
Das Problem an Ihrer Schule wird sein: Wie komme ich an eine derartige Textdatei für jede Klasse bzw. fuer die ganze Schule, ohne sie von Hand schreiben zu müssen ?
Hier können jedoch leider nur allgemeine Hinweise gegeben werden:
Wenn ein Daten-Export möglich ist:
Regeln für die Bildung des Anmeldenamens:
Die geforderten Punkte an die Datenquelldatei werden z.B. vom Programm Edutools (www.elantools.de) erfüllt. Für einen Abgleich von Schülerdaten und dem eDirectory liefert in der Musterlösung 2, 3 und 4 die Schulkonsole diese Daten.
Bemerkung zur Umlautumwandlung: Ist das Häkchen für die Umlautumwandlung bei den Einstellungen von BImport gesetzt, so werden in den Feldern
User, Klasse und Surname (bis BImport-Version 3.13)
User, Klasse, Surname, Given Name und Full Name (ab BImport-Version 3.14)
Umlaute aufgelöst. Ab BImport-Version 3.14 gilt dies im Gegensatz zu den Vorgängerversionen auch für den Nachnamen, den Vornamen und den vollen Namen. Dies hat Vorteile, wenn solche Benutzer nach GroupWise übernommen werden.
Wer nachträglich bei bereits vorhandenen Benutzern die Umlautumwandlung für
den Vornamen und den vollen Namen durchführen will, kann einfach die Update-Funktion von BImport nutzen.
Ab BImport-Version 3.14b hat das Häkchen für die Umlautumwandlung drei Zustände, nämlich:
 |
Umlautumwandlung (mit Given Name und Full Name) |
| keine Umlautumwandlung | |
| Umlautumwandlung (ohne Given Name und Full Name) |
Umwandlungen:
Ç/ç → C/c Ñ/ñ → N/n ß → ss Š/š → S/s Ý/ý → Y/y ÿ → y Ž/ž → Z/z
Ä → Ae ä → ae Æ → Ae æ → ae Ö → Oe ö → oe Œ → Oe œ → oe Ü → Ue ü → ue Ø → Oe ø → oe ß → ss
7 Anlegen der Benutzer mit BIMPORT
Nun sind alle Vorarbeiten erledigt. Der Serienimport mit BIMPORT kann beginnen.
Wenn Sie das Programm BImport z.B. aus dem Verzeichnis DATA\LFB\pgm\BImport bzw. über den NAL aufrufen, den Knopf "Benutzer Import" wählen, sehen Sie folgendes Bild:
Der untere mittlere Teil zeigt, dass BImport bereits den eDirectory-Baum SCHULBAUM03 gefunden hat. Der Context verweist auf den Container Schueler. Wir befinden uns auf dem Server GSERVER03 und haben uns als BenAdmin (in der ML sollte dies ein BenAdmin sein), in anderer Umgebung vielleicht als Admin eingeloggt.
Im oberen Teil des Fensters sind Voreinstellungen zu sehen, die änderbar sind. In der Regel finden Sie jedoch die für die Musterlösung passenden Voreinstellungen vor.
Diese Felder, die im Folgenden beschrieben werden, können direkt editiert werden. Bequemer ist jedoch ein Klick auf den jeweils rechts vom Feld stehenden Button oder ein Doppelklick direkt auf das Feld. Daraufhin öffnet sich eine Dialogbox (entweder ein Dateiauswahldialog oder ein eDirectory-Browser im NWAdmin-Stil oder der Mini-eDirectory-Browser), mit deren Hilfe das Gesuchte bequem ausgewählt werden kann. (Siehe Abschnitt Dialoge in BImport weiter unten).
In unserem Beispiel verwenden wir die Datenquelle benutzer.txt, die die Schülerdaten in den oben besprochenen Form (inklusive Klassenangabe) bereithält. Der Basis-Container ist auf Schueler.Benutzer.LFB.SCHULEN.ml3 eingestellt. Zusammen mit den Klassenangaben in benutzer.txt ergibt sich daraus für jeden Schüler der vollständige Context, also z.B. Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3 für einen Schüler der Klasse 1a.
Da mit dem Anlegen des Users im eDirectory auch ein Homeverzeichnis auf der Festplatte erzeugt wird, muss BImport wissen, wo dies geschehen soll. In der Musterlösung soll dies auf dem Volume DOCS im Verzeichnis DOCS\LFB\home\schueler geschehen. Die notwendigen Angaben stehen unter Home-Volume und BasisHomeDir. Diese Angaben werden normalerweise allerdings direkt aus dem Template, hier Template_Schueler.Schueler.Benutzer.LFB.SCHULEN.ml3, gelesen. Soll das wirklich so sein, so muss natürlich ein Häkchen in der CheckBox für das Template stehen. Dies ist normalerweise die Standardeinstellung. (Wird kein Template benutzt, so müssen die Eingaben Home-Volume und BasisHomeDir von Hand gemacht werden.)
Der Klick auf den "Start"-Button importiert nun die Benutzer. Ist ein Benutzer schon vorhanden, so erfolgt lediglich ein Update. Die dem Benutzer zugefügten Eigenschaften, werden auf Wunsch dem Template entnommen. Dabei wird zwischen Import und Update unterschieden. (Siehe weiter unten bei der Erklärung der Attribute.)
In einer Logdatei werden während der Arbeit von BImport Ergebnisse
und Fehler protokolliert. Die zugehörige CheckBox sollte also aktiviert
sein. Dabei wird der Dateiname, hier benutzer.log, beim Abspeichern auf die Festplatte
etwas abgeändert, je nachdem, ob gerade ein Import/Update oder ein Löschen
usw. stattfindet. Und zwar wird in den Dateinamen ein _I , _A, _U, _L, _V , _E bzw. ein _T eingefügt.
Aus bimport.log wird also:
| Import/Update | benutzer_I.log |
| Abgleich ML | benutzer_A.log |
| Update | benutzer_U.log |
| Löschen | benutzer_L.log |
| Versetzen | benutzer_V.log |
| Vorgaben testen | benutzer_T.log |
| Export | benutzer_E.log |
Über den Menüpunkt "Bearbeiten/Log-Anzeige" können Sie sich die Logdateien anzeigen lassen:
Um eventuelle Fehler auch auf dem Bildschirm zu sehen, sollte die Fehler auf Bildschirm-CheckBox angeklickt sein. (Bei vielen Fehlern erscheinen dann allerdings viele Fehler-Boxen).
Haben Sie die Schülerdaten als reine ASCII-Daten vorliegen, sollten Sie unbedingt die Ascii->Ansi-CheckBox aktiviert haben (DOS). Heutzutage werden die Daten wohl nicht mehr in ASCII vorliegen. Seien Sie also vorsichtig, mit einer Umwandlung!
Damit eventuell vorhandene Umlaute und weitere Sonderzeichen (z.B. in Ägis Sørensen) keine Schwierigkeiten bereiten, werden diese mit Hilfe der Umlautumwandlung aufgelöst (Aegis Soerensen), wenn die zugehörige Checkbox aktiviert ist (eine empfehlenswerte Einstellung):
| Zum Beispiel wird aus | der Benutzername: |
| ÄSørensen | ASoerensen |
| PMüller | PMueller |
| EPrieß | EPriess |
Das Gleiche gilt für Nachnamen und Klassenbezeichnungen. Dagegen erhalten
Vornamen und volle Namen keine Umlautumwandlung (bis BImport-Version 3.13).
Siehe auch die Bemerkung zur Umlautumwandlung. im Abschnitt Erzeugung der Datenquelldatei weiter oben.
(Beim AbgleichML -von der Schulkonsole gestartet- werden diese Dinge unabhängig von der gewählten Einstellung korrekt behandelt.)
Achtung: Die Umlautumwandlung geht von Ansi-Zeichen aus. D.h. entweder liegen Ihre Daten im ANSI-Format vor oder, falls sie im ASCII-Format (z.B. aus MS-DOS) vorligen, haben Sie die Ascii-zu-Ansi-Umwandlung eingeschaltet.
Über den Button "Einstellungen" oder das Menü "Datei/Einstellungen 1"
erhalten Sie eine Eingabemaske,
in der Sie Folgendes festlegen können:
| Datei- und Containerfelder | die bereits oben besprochenen Felder | ||||
| Unterverzeichnisse im Homeverzeichnis | Im Homeverzeichnis kann ein weiteres oder mehrere Unterverzeichnisse angelegt werden. Sogar ganze Unterverzeichnis-Strukturen können erzeugt werden. Soll das Homeverzeichnis z.B. die Unterverzeichnisse
enthalten, so ist ins Eingabefeld einzutragen:
|
||||
| Abgleich-Datenquelle | Datenquelldatei für einen Abgleich zwischen dieser Quelldatei und dem eDirectory. Unterhalb des Basiscontainers werden alle Benutzer, die nicht in dieser Quelldatei stehen in einen Abgang-Container verschoben, alle Benutzer, die zwar im eDirectory vorhanden, aber in einer anderen Klasse sind, in die Klasse verschoben, die die Quelldatei angibt und alle eDirectory-Benutzer, die mit der Quelldatei übereinstimmen lediglich einem Update unterzogen. Diese Funktion wird zur Zeit über die Schulkonsole gestartet, die bereits eine korrekte Quelldatei anliefert! |
||||
| Versetzung Containerzuweisungs-Datei | Für eine Versetzung enthält diese Datei Angaben, von welcher in welche Klasse versetzt werden soll. | ||||
| Ändere Quelldatei | Bei der Versetzung wird die Datenquelldatei mit geändert und eine Sicherungskopie (.old) angelegt, oder es wird die Datenquelldatei unverändert gelassen und eine geänderte neue Datei (.new) angelegt. | ||||
| In Datenquelldatei wird beachtet | Die Nichtversetzung eines Benutzers wird entweder durch ein Versetzungsfeld im Benutzerdatensatz der Datenquelldatei (Inhalt "N" oder Nichtversetzungskennzeichen) bzw. durch das Nichtversetzungszeichen am Zeilenanfang oder gar nicht gesteuert. Das Nichtversetzungszeichen hat Vorrang vor dem Versetzungsfeld! | ||||
| Environment | Wenn in Loginscripts die Environmentvariablen SCHULE, SCHULSERVER und/oder ZENTRALSERVER eingetragen werden, z.B.: (für Benutzer-Admins) können in BImport-INI-Dateien diese Variablen benutzt werden, z.B.: BasisContainer=Schueler.Benutzer.%schule%.SCHULEN.ml3 qVolume=.%schulserver%_DOCS.Server.DIENSTE.ml3 BImport liest die Environment-Variablen und ersetzt die Platzhalter, wenn diese Funktion gewählt ist. Auch wird beim Speichern die INI-Datei entsprechend geschrieben. |
||||
| Template | Template-Verwendung gewünscht | ||||
| Parent | Wenn sich in einem "Zwischen"-Container ein eigenes Template befindet (s.o.), wird dieses statt des im Feld Template eingestellten "Standard"-Templates benutzt, solange Benutzer aus Containern unterhalb des Zwischen-Containers bearbeitet werden. (Also dasjenige Template, das eine Stufe höher als der Benutzer liegt). Wird diese Einstellung ausgeschaltet, wird das User_Template (das genauso heißen muss) desjenigen Containers benutzt, in dem der Benutzer liegt, falls vorhanden, ansonsten das normale "Standard"-Template, welches im Templatefeld vorgewählt wurde. |
||||
| Standard | Ist dieses Häkchen gesetzt, so wird grundsätzlich das
im Feld Template eingestellte "Standard"-Templates benutzt, sofern die Template-Benutzung überhaupt eingeschaltet ist. (In diesem Fall spielt die Einstellung von Parent keine Rolle). |
||||
| Logdatei | Eine Logdatei wird erzeugt | ||||
| ASCII-Ansi | ASCII nach Ansi Umsetzung (heute wohl nicht mehr nötig) | ||||
| Vorgabentest | Das Häkchen "Vorgaben-Test" besagt, dass vor
einer BImport-Aktion (Import/Löschen/Versetzung) ein Test erfolgt, der
feststellt, ob in der NDS alle nötigen Container, im Dateisystem alle
nötigen "Ober"-Homeverzeichnisse und ggf. das Template vorhanden
sind. Nur wenn dieser Test erfolgreich ist, wird die Aktion ausgeführt. Unbedingt empfohlen! |
||||
| Umlautumwandlung | Wie oben beschrieben | ||||
| SearchForServersBySLP | Beim Start von BImport werden Server mittels SLP gesucht, andernfalls der Defaultserver. (SLP dauert länger!) | ||||
| Departmentfeld, |
In das Abteilungsfeld und/oder Beschreibungsfeld des Users lässt sich (zusätzlich zu den/der event. bereits vorhandenen oder aus dem Template übernommenen Abteilungen/Beschreibung) in der 1.Zeile der Containernamen einfügen, in dem sich der User befindet. Dies kann der vollständige Containername (z.B.: Klasse1a.Schueler.Benutzer.LFB.Schulen.ml3) oder der einfache Containername (z.B.: Klasse1a) sein. (Nützlich z.B. für Groupwise bei sortierter Anzeige nach diesen Feldern). BImport erkennt bei einem Update der User natürlich, ob dieser
Name dort schon steht und schreibt ihn nicht etwa ein zweites Mal hinein. Im AbgleichML-Modus (Musterlösung) wird bei Schülern, die in den Container Abgleich geschoben werden, der Eintrag |
||||
| Delete/Rename Inhibit | Um ein versehentliches Löschen der eigenen Homeverzeichnisse zu verhindern, ist es sinnvoll, auf das jeweilige Homeverzeichnis die Flags "Delete Inhibit" und "Rename Inhibit" zu setzen. Dies erreichen Sie mit dem Setzen des zugehörigen Häkchens. Jeweils drei Zustände sind möglich:
|
||||
| Wartezeit | Wartezeit in Millisekunden nach kritischen
NDS-Operationen Bem: Unabhängig von dieser Wartezeit (also auch, wenn diese auf 0 steht), wird vor dem Setzen der HomeDir-Rechte ggf. maximal 10 mal 100 Millisekunden auf das Erzeugen des Homeverzeichnissen gewartet. |
||||
| UniqueID | Die UniqueID wird von BImport genauso wie von ConsoleOne gesetzt, nämlich als (nichtqualifizierter) Benutzername, also z.B. SpechtB für SpechtB.Lehrer.Benutzer.LFB.Schulen.ml3. Bem: Die UniqueID sollte eindeutig sein! Also sollten die Benutzernamen eindeutig gewählt werden. Jeweils drei Zustände sind möglich:
|
||||
| Begrenzung: HomeDir statt Volume | Statt der im Template eingetragenen Volume Restriction wird diese als HomeDir-Restriction angewendet. Ist weder im Template noch in der Datenquelldatei eine Volume-Restriction eingetragen, so kann ein Default-Wert gewählt werden: -1: Keine Begrenzung (vorhandene wird gelöscht) Achtung: Ab der paedML-Novell-3.3.3 werden standardmäßig für das Volume DOCS keine Volume-Quotas verwendet. BImport würde also Fehler produzieren. Sie sollten also möglichst die HomeDir-Restrictions anwenden! |
||||
| Bindestrich in Namen zulassen | Aus den Benutzernamen werden standarmäßig die Zeichen Mit einem Häkchen bei "Bindestrich zulassen" jedoch, verbleiben Bindestriche in Benutzernamen. |
||||
| Template-Attribute |
Die Eigenschaften von Objekten in der NDS nennt man in der Sprache der NDS Attribute. So hat ein Userobjekt z.B. das Attribut Usernamen.
Dieses wiederum hat einen Wert, z.B. SperlingH. Für das
Userobjekt gibt es weit mehr als 100 Attribute. BImport benutzt zwei solche Listen, eine für den Benutzerimport und eine für das Benutzerupdate. Je nachdem, welche Sorte man bearbeiten will, muss entsprechend der Knopf "Import" oder "Update" oberhalb des Attributfensters gesetzt sein. |
Die vollständige Liste der Template-Attribute hat folgende Eintragungen:
(Bemerkung: Alle Attributnamen erscheinen in der eDirectory-Syntax und sind selbsterklärend, bis auf das Attribut OU. Hier handelt es sich um das "Department"-Attribut.)
Diese Attribute werden von BImport bearbeitet. Dabei läßt sich mit Hilfe der Häkchen in den Checkboxen vorwählen, welche Attribute inklusive der zugehörigen Werte gelesen bzw. bearbeitet werden sollen. Folgende drei Zustände sind möglich:
|
Häkchen gesetzt |
| Häkchen nicht gesetzt | |
| Häkchen grau unterlegt |
Folgende Regeln gelten:
Benutzer Import |
|
Häkchen gesetzt |
Attribut inklusive Werte werden zum neuen User hin übernommen, falls sie im Template überhaupt existieren. |
Häkchen nicht gesetzt |
Attribut inklusive Werte werden beim User ignoriert |
| Grau unterlegt | Attribut inklusive Werte werden beim User ignoriert |
Benutzer Update |
|
Häkchen gesetzt |
Attribut inklusive Werte werden beim bereits vorhandenen User gesetzt bzw. erneuert, falls sie im Template überhaupt existieren. Falls das Attribut im Template nicht existiert, wird dieses Attribut beim User NICHT geändert. Achtung: Attribute, die bearbeitet werden, werden beim User immer zuerst gelöscht und dann neu aus dem Template übernommen. |
Häkchen nicht gesetzt |
Attribut wird beim bereits vorhandenen User gelöscht. |
| Grau unterlegt | Attribut wird beim bereits vorhandenen User NICHT geändert |
Benutzer löschen |
|
Häkchen egal |
Das Template spielt beim Löschen keine Rolle |
Benutzer versetzen |
|
Häkchen gesetzt/nichtgesetzt oder grau |
Ein Template wird angewendet und die Häkchen werden beachtet. |
Benutzer abgleichen (ML) |
|
Häkchen gesetzt/nichtgesetzt oder grau |
Bei verschobenen und aktualisierten Usern werden die Häkchen beachtet (außer Password Expiration Interval und Time). Bei nach Abgang verschobenen Usern wird kein Template angewendet. |
Insbesondere beim Benutzer-Update ergeben sich daraus interessante Möglichkeiten.
Ein Beispiel: Sie wollen für bereits vorhandene Benutzer, die durch eine bestimmte Datenquelldatei bestimmt sind, nachträglich eine Gruppenzugehörigkeit löschen und zwei neue setzen.
Lösung: Die neuen Gruppen werden im Template unter "Group
Membership" eingetragen.
1.Möglichkeit:
In BImport werden bei den Template-Attributen alle Häkchen gesetzt, deren
Attribute beim Benutzer nicht verändert werden sollen.
In Wirklichkeit werden sie beim Benutzer gelöscht und dann neu gesetzt,
also auch unsere neuen Gruppeneintragungen.
2.Möglichkeit:
Alle Attribut-Felder werden auf "grau" gesetzt, außer "Group Membership"
und "Sequrity Equals".
Auch die Änderung von Quotas (Volume- oder HomeDir-Restrictions) ist eine schöne Anwendung des Benutzer-Updates.
ACHTUNG: Das Template spielt in BImport natürlich nur dann eine Rolle, wenn die CheckBox "Template" aktiviert ist.
Vorsicht beim Attribute ACL. Hier gilt:
Template hat Trustee-Einträge |
||
Modus |
Häkchen |
Wirkung beim User-Objekt |
Import |
gesetzt |
Übernimmt die Trustee-Einträge vom Template. |
leer |
Es werden keine Trustee-Einträge gesetzt !!! |
|
grau |
Setzt die Default-Trustee-Einträge. Template-Trustee-Einträge werden nicht beachtet. |
|
Update |
gesetzt |
Löscht vorhanden Trustee-Einträge und setzt die Template-Trustee-Einträge. |
leer |
Löscht vorhanden Trustee-Einträge !!! |
|
grau |
Es wird nichts verändert. |
|
Template hat KEINE Trustee-Einträge |
||
Modus |
Häkchen |
Wirkung beim User-Objekt |
Import |
gesetzt |
Setzt die Default-Trustee-Einträge. |
leer |
Es werden keine Trustee-Einträge gesetzt !!! |
|
grau |
Setzt die Default-Trustee-Einträge. |
|
Update |
gesetzt |
Löscht vorhandene Trustee-Einträge und setzt die Template-Trustee-Einträge. |
leer |
Löscht vorhandene Trustee-Einträge !!! |
|
grau |
Es wird nichts verändert. |
|
Eine "sichere" Standard-Einstellung für das ACL-Attribute ist daher: Häkchen grau.
Jetzt lassen wir BImport arbeiten: Je nachdem, ob Sie importieren/updaten oder löschen wollen, drücken Sie den entsprecheden Knopf in der Modus-Auswahl. Ein Klick auf den Start-Button startet nun den Prozess. Die Usernamen der zu bearbeitenden Schüler erscheinen und ein Fortschrittsbalken gibt einen zeitlichen Überblick. Eine abschließende "Fertig-Meldung" sagt, wenn's fertig ist.
In der Logdatei lassen sich nun die Einzelheiten nachlesen.
Im Anzeigefeld Context ist jetzt auch der jeweils angesprochene Klassen-Container zu sehen.
Starten Sie BImport.exe
Machen Sie sich mit der Programm-Oberfläche vertraut.
Importieren Sie die Schüler aus Ihrer Datenquelldatei benutzer.txt
Überprüfen Sie das Resultat
- im eDirectory
- über das Menü Bearbeiten/Log-Anzeige oder mit einem Texteditor
in der jeweiligen bimport.log
- mit dem Explorer im Verzeichnis \home\schueler\klasse1a bzw. klasse1b
Updaten Sie die Schüler aus Ihrer Datenquelldatei benutzer.txt durch Wahl den Knopfes "Benutzer Update". Dabei werden die Templateattribute für das Update zugrunde gelegt.
8 Löschen der Benutzer mit BIMPORT im Import-Fenster (zum Schuljahresende)
Eine Strategie ist es, zum Schuljahresende alle Schüler-Benutzer zu löschen und für das neue Schuljahr neu anzulegen. Keine gute Idee ist es, dafür die Klassencontainer im eDirectory zu löschen. Falls Sie denen nämlich Eigenschaften zugewiesen haben, müssen Sie alles neu erzeugen.
Besser ist es, hier ebenfalls BIMPORT einzusetzen. Dazu benötigt man genau wie beim Import jeweils eine Daten-Textdatei. Glücklicherweise sind die Daten-Textdatei(en) genau dieselbe(n) wie beim Import. Heben Sie die Datenquelldatei(en) mit Ihren Schülerdaten also gut auf !
Alles funktioniert wie beim Import/Update. Allerdings spielt jetzt das Template
keine Rolle (egal, ob das Template-Häkchen gesetzt ist oder nicht).
(Von der Datenquelldatei werden beim Löschen nur die Felder
User und ggf. Klasse ausgewertet).
Wählen Sie den Modus "Löschen" und drücken Sie den Start-Button.
Beim Löschen von Benutzern werden zwar die User-Einträge im edirectory gelöscht, nicht jedoch die dazugehörigen Home-Verzeichnisse. Das ist in der Netzwerkwelt so üblich: Es könnten ja sonst versehentlich wichtige Daten gelöscht werden !
In diesem Sinne also: It's not a bug, it's a feature !
Mit Setzen des Häkchens "Lösche HomeDir" löscht BImport jedoch auch die Homeverzeichnisse!
Das Löschen der Homeverzeichnisse ist jedoch auch mit dem Explorer leicht. Markieren Sie einfach alle Unterverzeichnisse z.B. im Verzeichnis DOCS\LFB\home\schueler\Klasse1a und löschen Sie sie.
(Gibt's beim Löschen Probleme, so könnte ein vorheriges Anwenden der Befehle
flag *.* /rw /sub
flag *.* /N /Do /sub
ausgeführt in einer DOS-Box vom Startverzeichnis DOCS\LFB\home\schueler aus, helfen.
Um das Löschen der Homeverzeichnisse zu erleichtern, löscht BImport während des Löschens der User aus dem eDirectory auch die Flags "Delete Inhibit" und "Rename Inhibit", und zwar unabhängig davon, wie die zugehörigen Häkchen unter "Optionen/weitere Einstellungen" gesetzt sind!
Wenn Sie am Schuljahresende/anfang Ihre Schüler nicht einfach löschen und neuanlegen, sondern versetzen wollen, lesen Sie den Abschnitt Versetzung weiter unten.
ACHTUNG: Verwenden Sie GroupWise, sollten Sie die User über ConsoleOne und nicht über BImport löschen, da andernfalls die User in GroupWise "übrigbleiben".
Wenn Sie am Schuljahresende/anfang nicht alle Schüler löschen und anschließend neu erzeugen wollen (obwohl dies die Chance bietet, etlichen "Schrott" loszuwerden), bietet BImport eine komfortable Möglichkeit, Schüler zu vesetzen.
Was bedeutet es, z.B. den Schüler SperlingH aus Klasse1a in die Klasse2a zu vesetzen ?:
- Der User SperlingH muss aus dem Container Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3 in den Container Klasse2a.Schueler.Benutzer.LFB.SCHULEN.ml3 verschoben werden.
- Außerdem muss das Homeverzeichnis SperlingH von DOCS:LFB\Home\Schueler\Klasse1a nach Docs:LFB\Home\Schueler\Klasse2a verlegt werden.
Woher bekommt BImport die dazu nötigen Informationen ?
Zunächst weiß BImport aus der Quelldatei (z.B. benutzer.txt), dass SperlingH sich in Klasse1a befindet. Jetzt wird aber noch eine zweite Textdatei benötigt (z.B. containerzuweisung.txt), die enthält, welche Klasse in welche versetzt wird. Diese Containerzuweisungsdatei muss folgendermaßen aufgebaut sein:
Pro Zeile steht eine Zuweisung, z.B.:
"Klasse1a","Klasse2a"
"Klasse1b","Klasse2b"
"Klasse8c","Klasse9c.Fra"
"Klasse9c.Fra","Klasse10c"
Jeweils links steht die Quell-Klasse und rechts die Ziel-Klasse, also werden
z.B. alle Schüler der Klasse1a nach Klasse2a versetzt, usw...
Wie an den letzten beiden Beispielzeilen zu sehen, sind auch "komplexere"
Strukturen erlaubt (auch in der Quelldatei benutzer.txt).
(Fehlerhafte Zeilen werden von BImport nicht beachtet.)
Sinnvoll ist es, allen Abschlussklassen eine "Abgangsklasse zuzuweisen, also z.B.:
"Klasse13","Abgang"
Alle Schüler der Klasse "Abgang" werden dann zu gegebener
Zeit von Hand endgültig aus dem System gelöscht.
(Denken Sie daran, im eDirectory einen Container Abgang
und im Dateisystem ein Ober-Homeverzeichnis Abgang
zu erzeugen).
Wenn also BImport einen Schüler versetzt, z.B. SperlingH, so weiß BImport aus der Quelldatei, dass SperlingH in Klasse1a ist. Es schaut bei der Containerzuweisung nach, wohin Klasse1a versetzt wird (hier Klasse2a). Dabei spielt die Groß/Kleinschreibung der Klassencontainerbezeichnungen keine Rolle.
Wenn nichtversetzte Schüler keine Rolle spielen sollen, genügen die soeben beschriebenen Informationen für die Versetzung.
Über den Button "Versetzung" oder über das Menü "Bearbeiten/Versetzung" sehen Sie folgenden Bildschirm:
Ganz oben können Sie sich Ihre Containerzuweisungsdatei wählen. Zur Kontrolle sehen Sie auch, welchen Quelldatei z.Z. eingestellt ist. Wenn nichtversetzte Schüler nicht beachtet werden sollen, so ist der Punkt "weder noch" zu wählen. Über den oberen Start-Button wird die Versetzung gestartet. Der Verlauf wird mit dem Fortschrittsbalken angezeigt. Ein Protokoll finden Sie anschließend in benutzer_V.log.
User, die sich im BasisContainer befinden, können nicht versetzt werden! Dementsprechend ist eine Zeile, wie z.B.:
"","Klasse2a"
in der Containerzuweisungsdatei ungültig und wird von BImport nicht beachtet.
Für die Versetzung werden die Templateattribute für das Update zugrunde gelegt. Dabei wird das Attribut "Home Directory" immer vorgewählt, auch wenn es unter Einstellungen nicht gesetzt war.
Nichtversetzte Schüler
Wollen Sie nichtversetzte Schüler in ihren bisherigen Klassen belassen, soll Bimport diese Schüler also bei der Versetzung gar nicht beachten, so müssen Sie den Punkt "Versetzungsfeld/Nichtversetzungskennzeichen" wählen und natürlich müssen Sie zuvor die Quelldatei, z.B. benutzer.txt, anpassen. Dafür gibt es zwei Möglichkeiten:
1.Möglichkeit:
Als erstes Zeichen in den Datenzeilen derjenigen Schüler, die nicht versetzt werden sollen (es sind ja normalerweise nicht so viele), wird von Hand das Nichtversetzungskennzeichen (so wie bei den Quelldatei-Vorgaben angegeben; Default: =, ein Gleichheitszeichen; Eselsbrücke: Schüler bleibt in der gleichen Klasse) geschrieben, also z.B.:
="SperlingH","Klasse1a","Sperling","Hans","Hans Sperling"
2.Möglichkeit:
Die Schülerdatensätze der Nichtversetzten enthält ein Versetzungsfeld, so wie Sie das zuvor bei den Quelldatei-Vorgaben festgelegt haben. Dieses Versetzungsfeld enthält entweder das Nichtversetzungskennzeichen oder ein kleines oder großes N. Ein paar Beispiele:
"SperlingH","Klasse1a","Sperling","Hans","Hans Sperling","="
"SperlingH","Klasse1a","Sperling","Hans","Hans Sperling","N"
"SperlingH","Klasse1a","Sperling","Hans","Hans Sperling","n"
Gibt es kein Versetzungsfeld im Datensatz oder enthält das Versetzungsfeld nichts ("") oder etwas anderes als die Nichtversetzungsangaben, so wird dies als "zu versetzen" aufgefasst.
Sie dürfen -wenn auch wenig sinnvoll- beide Möglichkeiten mischen. Beginnt aber der Datensatz mit dem Nichtversetzungskennzeichen, ist egal, ob es ein Versetzungsfeld gibt oder nicht, oder was darin steht. Der Schüler wird nicht versetzt! Beispiele:
="SperlingH","Klasse1a","Sperling","Hans","Hans Sperling",""
="SperlingH","Klasse1a","Sperling","Hans","Hans Sperling","N"
="SperlingH","Klasse1a","Sperling","Hans","Hans Sperling","J"
Gleichzeitige Versetzung in der Quelldatei
Während BImport versetzt, wird auch die Quelldatei entsprechend mitverändert,
damit Sie nach der Versetzung wieder eine den neuen Gegebenheiten angepasste
Quelldatei (z.B. zum Update oder zum Löschen) haben. Dabei können
Sie wählen, ob die Quelldatei, z.B. benutzer.txt direkt verändert
werden soll (eine Sicherung der alten Datei findet sich dann in benutzer.old)
oder ob sie nicht verändert werden soll (der neue Stand befindet sich
dann in benutzer.new).
Im ersten Fall muss das Häkchen bei "Ändere Datenquelldatei"
gesetzt werden, im zweiten nicht.
Schüler, die nicht versetzt werden sollen, bleiben mit ihrer alten Klasse erhalten. Jedoch wird in der Quelldatei das Nichtversetzungskennzeichen gelöscht und das Versetzungsfeld geleert!
Schüler, die aus irgendwelchen anderen Gründen (Fehler) von BImport nicht versetzt wurden, werden auskommentiert (ein Kommentarzeichen wird an den Anfang der Datensatzzeile gesetzt).
Lesen Sie unbedingt das Versetzungsprotokoll in benutzer_V.log und die neue Quelldatei!!!
Versetzung, wenn Homeverzeichnisse zwischen Servern oder Volumes verschoben werden
Siehe hierzu "Scheinbare Trustee-Unstimmigkeiten" im Abschnitt Mehrere Server im eDirectory-Baum.
Über das Menü "Bearbeiten/Teste Vorgaben" können Sie sich anzeigen lassen, ob alle Vorgaben stimmen. Diesen Vorgaben-Test gibt es für die vier Aktionen Import/Update, Abgleich, Löschen und Versetzung, da hier jeweils unterschiedliche Vorgaben eine Rolle spielen:
Falls alle Vorgaben stimmen, sehen Sie lediglich über dem Fortschrittsbalken im BImport-Bild eine entsprechende Meldung.
Im Fehlerfall erscheint ein Fenster, dass vielleicht so aussehen könnte:
In jedem Fall (ohne oder mit Fehler) wird die Protokolldatei benutzer_T.log erstellt. Lesen Sie diese!
BImport liest beim Vorgabentest die Klassencontainer-Angaben aus der Quelldatei
und prüft, ob diese Container im eDirectory unterhalb des BasisContainers
liegen. Ebenfalls wird geprüft, ob die "Ober"-Homeverzeichnisse
unterhalb des BasisHomeDir liegen und einiges mehr.
Im Falle des Tests bei der Versetzung, wird außerdem die zweite Spalte
der Containerzuweisungsdatei, also die Zielklassen) gelesen. BImport prüft,
ob auch diese Container bzw. die Ober-Homeverzeichnisse existieren.
Eine solcher Vorgabentest läuft jedesmal vor einer der Aktionen Import/Update, AbgleichML, Löschen, Versetzung ab, sofern das Häkchen "Vorgaben-Test" nicht entfernt wurde.
11 Benutzer-Abgleich in der Musterlösung (Datenabgleich zwischen Quelldatei und eDirectory)
Speziell in der Musterlösung 2+3+4 kann über die Schulkonsole BImport automatisch in den Verarbeitungsmodus AbgleichML gestartet werden. Zuvor hat die Schulkonsole Schülerdaten aus der Schulverwaltung für BImport aufbereitet.
Ab dem BasisContainer werden dabei nicht mehr vorhandene Schüler in den Container Abgang verschoben, ggf. Schüler versetzt oder nur aktualisiert.
Ist dieser Vorgang erfolgreich, schließt sich BImport nach einer Erfolgsmeldung automatisch und kehrt zur Schulkonsole zurück. Andernfalls bleibt BImport geöffnet, so dass die Fehler analysiert werden können.
Die von der Schulkonsole für diesen Vorgang erzeugte Datenquelldatei kann auch im AbgleichML-Modus ein weiteres Mal in BImport abgearbeitet werden. Dann findet die gleiche Bearbeitung der Benutzer statt, so, als wäre BImport von der Schulkonsole gestartet worden: Allerdings könnte dies jetzt -wie soeben beschrieben- auch mit veränderten Templatedaten durchgeführt werden.
Die von der Schulkonsole erzeugte Datenquelldatei hat gegenüber einer normalen BImport-Datenquelldatei einen Header, der einige Daten an BImport weitergibt, z.B.:
[Einstellungen]
parentTemplate=1
HomedirRestriction=1
IDField=Title
AbgangContainer=Abgang
BasisContainer=Schueler.Benutzer.LFB.Schulen.ml3
Mit parentTemplate, HomedirRestriction, AbgangContainer und BasisContainer werden BImport-Einstellungen überschrieben. AbgangContainer gibt relativ zum BasisContainer an, wohin Abgänger verschoben werden sollen. IDField gibt an, auf welches eDirectory-Attribut des Benutzers die ID gespeichert werden soll. (Ist z.Z. fest auf das Title-Attribut eingestellt.). Bindestriche in Benutzernamen, sofern vorhanden, bleiben erhalten.
Die Standardeinstellungen finden Sie im Dokument "Benutzerverwaltung mit der Schulkonsole" (zur Zeit so, wie oben angegeben).
Das ID-Feld wird hier zwingend von der Schulkonsole in der angelieferten Datenquelldatei gesetzt. D.h. in den Einstellungen von BImport müssen mindestens vier Datenfelder definiert sein und zwar User, Klasse, SurName, ID und zwar in dieser Reihenfolge!
Mit parentTemplate=1 wird jeweils dasjenige Template benutzt, das sich genau eine Container-Ebene oberhalb desjenigen Containers befindet, in den ein Schüler importiert bzw. aktualisiert wird. Im Normalfall sitzen die Klassencontainer direkt unter der OU Schueler. Also wird das Standardtemplate Template_Schueler.Schueler.Benutzer.LFB.Schule.ml3 benutzt. Liegen jedoch "Zwischencontainer" vor,
 |
wie im abgebildeten Beispiel der Container Oberstufe mit den Klasse 13a bis 13d und befindet sich im Container Oberstufe das Template Template_Oberstufe, dann wird für Schüler in den Klasse 13a bis 13d dieses Template benutzt statt des Standardtemplates Template_Schueler, ansonsten das Standardtemplate. Mit parentTemplate=0 wird das Template User_Template, das -falls vorhanden- direkt im Klassencontainer liegen muss, also z.B. in Klasse 1a oder 13a, verwendet. (Die Schulkonsole kann solche Templates in den Klassecontainern erzeugen. Diese sind dann identisch zum Standardtemplate und könnten auf Wunsch von Hand verändert werden, z.B. für unterschiedliche Quotas.) Natürlich muss in den BImport-Einstellungen die Templatebenutzung eingeschatet sein. In diesem Fall spielen die dortigen Häkchen für Parent und Standard keine Rolle, da sie durch die von der Schulkonsole kommenden Datenquelldatei überschrieben werden. |
12 Benutzer-Update (ohne Datenquelldatei)
Oft möchte man bereits im eDirectory vorhandenen Benutzern neue Eigenschaften geben, z.B. eine neue Speicherplatzbeschränkung oder ein neues Passwortablaufdatum und vieles mehr. Dies ist mit Novell-Bordmitteln nicht so leicht möglich, jedenfalls ist es mit Bordmitteln immer dann schwierig, wenn viele Benutzer betroffen sind. Eine extrem nützliche Eigenschaft von BImport ist es deswegen, mit Hilfe eines Templates viele Benutzereigenschaften auch im Nachhinein ändern zu können. Über die Import/Update-Funktion ist dies zwar auch möglich, man benötigt aber eine Datenquelldatei.
Um auch ohne Datenquelldatei beliebige Benutzer mit Hilfe eines Templates updaten zu können, gibt es das "reine" Update:
Über den Button "Wähle Benutzer" oder einen Doppelklick auf das Listenfenster lassen sich Benutzer über den Mini-eDirectory-Browser Benutzer in das Listenfenster einlesen. Wird dabei im Mini-eDirectory-Browser ein Container ausgewählt, so werden dessen Benutzer übernommen. Natürlich lassen sich auch einzelne Benutzer auswählen. Die Windows-üblichen Markierungsfunktionen wirken hier im Mini-eDirectory-Browser. Das Wählen kann beliebig oft durchgeführt werden. Jedesmal werden die dabei neu gewählten Benutzer zusätzlich in das Listenfenster übernommen. Mit "Lösche Liste" wird das Listenfenster geleert.
Mit den in Windows üblichen Markierungsfunktionen können in dieser Liste Benutzer markiert werden, über die nebenstehenden Buttons auch alle, oder die Markierung kann wieder aufgehoben werden.
 |
 |
Oben rechts im Fenster für die Template-Attribute sollte man ggf. Häkchen setzen, löschen oder grau schalten, je nachdem, ob man eine Eigenschaft aus den Template übernehmen, löschen oder unverändert lassen will.
Bei jeder Anwahl der BImport-Update-Seite wird zunächst das Standardtemplate vorgeschlagen, so, wie es bei den Einstellungen gewählt wurde. Hier kann man nun auch für den Update-Prozess ein anderes Template wählen. (Bei einem späteren Aufruf der BImport-Update-Seite erscheint dann wieder das Standardtemplate.)
Ein Klick auf den Start-Button startet den Update-Prozess, der zuvor noch ein Hinweisfenster bereit hält, das auf den Umfang der bearbeiteten Benutzer (alle oder nur markierte) hinweist und eine Erinnerung an die Templateattribute enthält, z.B.:
Der Ja-Button führt nun das Update aus, während Nein den Prozess abbricht.
Die bearbeiteten Benutzer haben jetzt ein Häkchen und wurden über Zähler und Fortschrittsbalken mitverfolgt. Diese Benutzer werden in eine interne Liste gespeichert und können während der laufenden BImport-Sitzung sowohl im Update- als auch im Löschen-Fenster in das Listenfenster zurückgeholt werden.
BImport schreibt auch für den Update-Prozess eine ausfühliche Log-Datei mit, die unter dem Menüpunkt "Bearbeiten/Log-Anzeige/ für Update" einzusehen ist.
Achtung: Wenn Sie dasselbe Template wie beim Import benutzen (oder auch sonst), so sollten Sie die beiden Attribute Password Expiration Interval und Password Expiration Time, sofern im Template eingestellt, erhalten, also die betreffenden Häkchen ausgrauen. Ansonsten laufen Sie Gefahr, ein eventuell schon abgelaufenes Datum bei den Benutzern einzutragen, so dass sich diese nicht mehr anmelden können!
Das Home Directory Attribut lässt sich nur auf grau oder mit Häkchen setzen. D.h.: der Home-Directory-Eintrag im eDirectory kann nicht gelöscht werden (, denn er ließe sich im Update-Modus ohne Datenquelldatei nicht wieder automatische neu erzeugen).
13 Löschen der Benutzer (ohne Datenquelldatei)
Ähnlich wie bei der Update-Funktion kann man im Fenster mit Hilfe des MINI-eDirectory-Browsers beliebige Benutzer auswählen, die sich endgültig löschen lassen. Dabei ist man also nicht mehr von einer Datenquelldatei abhängig. Auch die Homeverzeichnisse können auf Wunsch mitgelöscht werden (Häkchen "Lösche HomeDir").
Wenn das Häkchen "Datenquelldate ändern" gesetzt ist, wird auch die im Feld Datenquelle angegebene Datenquelldatei mit geändert, sofern sich die zu löschenden Benutzer darin befinden. Die betreffenden Zeilen werden einfach herausgenommen. Der alte Zustand wird in der Datenquelldatei mit der Endung BAK gesichert, also z.B. benutzer.bak, während die Datei benutzer.txt die Änderungen enthält. (Templates spielen bein Löschen keine Rolle.)
14 Ändern eines Benutzernamens
Ab und zu ist es nötig, einen Benutzernamen zu ändern, z.B. nach einer Heirat, oder auch nur, um Schreibfehler zu korrigieren. Unter dem Menüpunkt "Bearbeiten/Benutzername ändern"
erscheint:
Wie bei der Update- oder Löschfunktion kann man durch Klick auf den Button neben dem Benutzerfeld mit Hilfe des MINI-eDirectory-Browsers (oder durch Doppelklick auf das Benutzerfeld selbst) einen beliebigen Benutzer auswählen, z.B.:
Aus dem eDirectory werden Anmeldename. Nachname, Vorname, voller Name und die ID gelesen, soweit vorhanden, und in die Felder gesetzt, in denen die Änderungen vorgenommen werden können.
Falls es wichtig ist, die Datenquelldatei auf einem aktuellen Stand zu halten, kann diese mit aktualisiert werden. Dazu ist das Häkchen bei "Datenquelldatei ändern" zu setzen und die korrekte Datenquelldatei auszuwählen.
Falls das Häkchen "Logdatei" gesetzt ist, wird für den gesamten Änderungsvorgang ein Protokoll in der angegebenen Logdatei (als Update-Logdatei) erstellt.
Wird der Änderungsvorgang mit Klick auf den Start-Button gestartet, wird zunächst überprüft, ob es den Anmeldenamen schon ein zweites Mal gibt. Dabei wird ab demjenigen Container gesucht, der unter StartContainer eingetragen ist. Wird als z.B. SperlingH in SperlingP (... Peter Sperling) geändert, könnte die Warnung so aussehen:
Bis zu 5 Doubletten werden im Fenster angezeigt, ggf. mehr in der Update-Logdatei.
Hier kann man sich entscheiden, ob man die Doublette zulassen will oder lieber nicht. Auch könnte sein, dass eine ID (im Title-Feld des eDirectory-Objektes) schon vergeben wurde. Die Warnung sieht dann etwa so aus:
Auch hier kann entschieden werden, ob die Änderung akzeptiert wird oder nicht.
Der Normalfall wird wohl eine eindeutige Änderung sein (oder die Akzeptanz von Doubletten). Nach der Änderung bietet sich etwa folgendes Bild:
Geändert wurde nicht nur das eDirectory-Objekt, sondern es wurde natürlich auch das Homeverzeichnis umbenannt:
Falls die Datenquelldatei (hier: benutzer.txt) mit geändert wurde, wurde dort also aus
...
"SperlingH","Klasse1a","Sperling","5","Hans","Hans Sperling"
...
...
"SpatzH","Klasse1a","Spatz","5","Hans","Hans Spatz"
...
Die alte Datei erhielt die Endung .bak (hier: aus der alten benutzer.txt wurde benutzer.bak; benutzer.txt enthält die Änderung).
Ein ausfühliches Protokoll findet sich im Update-Log, dass über den Menüpunkt "Bearbeiten/Log-Anzeige/für Update" eingesehen werden kann.
Der Start-Button bleibt zunächst deaktiviert, da ja eine weiter Änderung mit den momentan im Fenster dargestellten Daten nicht möglich wäre. Erst nach erneuter Benutzerauswahl, wir er wieder freigegeben.
(Templates spielen hier keine Rolle.)
15 Export von Benutzerdaten aus dem eDirectory für BIMPORT und GroupWise
Über den Menüpunkt "Bearbeiten/Export" können Benutzerdaten aus dem eDirectory in eine Datei exportiert werden. Dies kann als Datendatei im BIMPORT-Format oder als CSV-Datei in einem Format für den Benutzerimport in GroupWise mit Hilfe des Programms GWIU geschehen.
BIMPORT-Format
Das BIMPORT-Format richtet sich nach den Einstellungen der Feldstruktur für die BIMPORT-Datenquelldatei. Dabei wird aber grundsätzlich das Feld "Versetzung" weggelassen.
Bevor über den "Wähle Benutzer"-Button die Liste (genauso, wie bei anderen BIMPORT-Menüpunkten, z.B. Update oder Löschen) mit Benutzern gefüllt wird, sollte der Start-Container-Eintrag überprüft bzw. gesetzt werden. Danach kann die Liste gefüllt werden. Es sollten und können dabei nur Benutzer gewählt werden, die auch unterhalb des Start-Containers liegen, da beim Export für das Klassen-Feld die Differenz aus tatsächlichem Benutzer-Context und dem Start-Container gebildet wird.
So wird z.B. das exportierte Klassenfeld für SpatzH.Klasse1a.Schueler.Benutzer.S01.SCHULEN.ml3 zu "Klasse1a" oder AmselB.Klasse1a.Elektro.Schueler.Benutzer.LFB.SCHULEN.ml3 zu "Klasse1a.Elektro".
In der CheckBox-Liste oben rechts werden standardmäßig diejenigen Felder in der Reihenfolge angeben, wie sie in der BIMPORT-Feldstruktur festgelegt wurden. Ebenfalls standardmäßig sind bis auf "Volume Space Restriction" die Häkchen für die Felder gesetzt. Hier kann aber je nach Zweck durch Setzten oder Löschen der Häkchen gewählt werden, was tatsächlich exportiert werden soll.
Wenn alles korrekt eingestellt und gewählt worden ist, wird der Export mit dem "Start"-Button gestartet. Es erscheint noch ein Datei-Auswahl-Fenster, im dem der Pfad und Name der Export-Datei gewählt wird. Danach wird die Export-Datei erzeugt. Mit den oben im Bild gesetzten Einstellungen könnte das Ergebnis etwa so aussehen:
"AmselB","Klasse1a","Amsel","2","Bettina","Bettina Amsel"
"SpatzH","Klasse1a","Spatz","5","Hans","Hans Spatz"
"SperberA","Klasse1a","Sperber","5","Karl","Karl Sperber"
also eine ganz normale BIMPORT-Datenquelldatei, die wiederum von BIMPORT als Datenquelldatei benutzt werden kann.
Falls gewählt, wird auch eine Logdatei erzeugt, die über den Menüpunkt "Bearbeiten/Log-Anzeige/für Export" eingesehen werden kann. (Der Logdateiname setzt sich aus dem gewählen Namen mit angehängtem _E zusammen, also z.B. benutzer_E.log.)
CSV-Format (für ältere GroupWise-Versionen)
Für älrere GroupWise-Versionen, die noch über das eDirectory verwaltet werden, gibt es noch Folgendes: Das CSV-Format ist ein spezielles Format, das für das GroupWise-Import-Utility GWIU gedacht ist. Die erste Zeile einer solchen Export-Datei beschreibt, welche Felder in den Folgezeile enthalten sind. BIMPORT kann folgende Felder erzeugen: Surname (Nachname), GivenName (Vorname), NetID (vollständig qualifizierter Benutzer), Domain (GroupWise-Domain), PO (GroupWise PostOffice), AccountID (Anmeldename), Department (Abteilung), MailboxExpDate (Ablauf-Datum/Zeit). Die folgenden Zeilen beschreiben nach diesem Muster jeweils einen exportierten Benutzer, also etwa:
Surname,GivenName,NetID,Domain,PO,AccountID,Department
Gross,Annette,GrossA.Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3,Domain,POfficeL,GrossA,Klasse1a
Gross,Annette,GrossA-LFB.Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3,Domain,POfficeL,GrossA-LFB,Klasse1a
Specht,Bernd,SpechtB.Klasse1a.Schueler.Benutzer.LFB.SCHULEN.ml3,Domain,POfficeL,SpechtB,Klasse1a
(hier ohne MailboxExpDate dargestellt).
Im Exportfenster muss dafür rechts oben die Export-Auswahl auf GroupWise gesetzt werden (hier noch mit älteren Bildern dargestellt):
Vor der Erzeugung der Export-Datei ist natürlich die gewünschte Groupwise-Domain und das GroupWise-Postoffice zu wählen und ggf. das Mailbox-Verfallsdatum anzugeben:
Falls das MailboxExpDate-Feld angehakt ist, muss das zugehörige Eingabefeld mit einem Datum und einer Zeit in der Form JJJJMMTTHHMM ohne Leerzeichen eingegeben werden, also für den 31.12.2011 um 11:59 Uhr in der dargestellten Form:
Wird MailboxExpDate nicht verwendet, so verschwindet auch das zugehörige Eingabefeld:
Wenn alles korrekt eingestellt und gewählt worden ist, wird der Export mit dem "Start"-Button gestartet. Es erscheint noch ein Datei-Auswahl-Fenster, im dem der Pfad und Name der Export-Datei gewählt wird. Danach wird die Export-CSV-Datei erzeugt, z.B. export.csv.
Falls gewählt, wird auch eine Logdatei erzeugt, die über den Menüpunkt "Bearbeiten/Log-Anzeige/für Export" eingesehen werden kann. (Der Logdateiname setzt sich aus dem gewählen Namen mit angehängtem _E zusammen, also z.B. benutzer_E.log.)
Die CSV-Datei kann nun benutzt werden, um mit dem GWIU-Programm die Benutzer nach GroupWise zu importieren. GWIU findet man bei Novell's CoolSolutions.
16 Mehrere Server im eDirectory-Baum
Haben Sie mehrere Server im eDirectory-Baum, z.B. einen Filialserver in einem Nebengebäude, auf denen die Homeverzeichnisse mancher Benutzer liegen sollen, so kann BImport auch dies handhaben, vorausgesetzt, die Templates werden korrekt für diesen Zweck eingesetzt. Wir gehen exemplarisch von folgender Situalion aus:
Es gibt einen Server filserver03 in der Ressourcen-OU der Schule LFB. Im Filesystem gibt es ein Volume DOCS in dem das Ober-Homeverzeichnis home\schueler liegt, in dem sich Klassencontainer befinden.
(Bemerkung: Die Bezeichnungen müssen nicht identisch mit denen des Default-Servers sein; im Falle der Musterlösung ist dies aber sinnvoll.)
eDirectory: |
Filesystem: GServer03 (Default-Server)  Filialserver  |
Im Beispiel liegen also Schüler der Klassen Klasse1a, Klasse4a und der Oberstufenklassen 13a und 13d auf dem Hauptserver gserver03 und die Schüler der Klassen Klasse2a, Klasse3a und der Oberstufenklassen 13b und 13c auf dem Filialserver filserver03. Wir starten BImport bzw. Schulkonsole auf einer Arbeitsstation, für die gserver03 der Defaultserver ist.
Mindestens in den OUs Klasse2a, Klasse3a, Oberstufe (alternativ in 13b und 13c) müssen nun Templates liegen, die den Filialserver-Eintrag haben, während das Standard-Template den gserver03-Eintrag haben. Für ein User_Template direkt in einer Klasse-OU sieht das etwa so aus:
(Zur Angabe Pfad in Templates, Zwischentemplates und User_Templates gelten die weiter oben gemachten Bedingungen.)
Passend zu unserem Beispiel könnte z.B. in der Datenquelldatei stehen:
"SperlingH","Klasse1a","Sperling","5","Hans","Hans Sperling"
"AmselB","Klasse2a","Amsel","6","Bettina","Bettina Amsel "
"OhlsonA","13a.Oberstufe","Ohlson","7","Albert","Albert Ohlson"
"ObermannT","13b.Oberstufe","Obermann","8","Tobias","Tobias Obermann"
BImport wird dann die Homeverzeichnisse von Sperling und Ohlson auf dem gserver03 und die Homeverzeichnisse von Amsel und Obermann auf dem filserver03 anlegen, updaten, verschieben oder löschen, je nach BImport-Funktion.
Bei der BImport-Funktion AbgleichML, die in der Regel von der Schulkonsole angestoßen wird, gibt es noch eine Besonderheit für die Schüler zu beachten, die nach "Abgang" verschoben werden sollen:
Um zu verhindern, dass Homeverzeichnisse in diesem Fall zwischen Servern verschoben werden müssen, sollte es auf dem Filialserver auch einen Ordner Abgang im Filesystem liegen. Musterlösungskonform wäre dies \DOCS\home\schueler\Abgang.
In jedem Fall sucht BImport vom aktuellen Klassen-Homeverzeichnis aus nach unten, bis es einen Ordner Abgang findet. BImport würde also \DOCS\home\schueler\Abgang finden und diesen benutzen. Sollte ein solcher Ordner nicht vorhanden sein, so wird BImport (notgedrungen) den Ordner Abgang auf dem Defaultserver gserver03 nehmen.
Der Grund dafür ist, dass ein Verschieben eines Homeverzeichnisses auf ein- und demselben Server bzw. Volume viel schneller abläuft, als ein Verschieben zwischen verschiedenen Servern bzw. Volumes, da dann nämlich ein echter Kopiervorgang nötig ist.
Achtung: Die Bearbeitung von Benutzern auf verschiedenen Servern setzt voraus, dass die Arbeitsstation, von der BImport gestartet und benutzt wird, den oder die Server auch "sieht". Um dies festzustellen, schauen Sie im Exlorer unter Netzwerkumgebung/Gesamtes Netzwerk/Netware Services nach, ob der oder die weiteren Server angezeigt werden. Wenn nicht, können Sie z.B. mit der ConsoleOne ein Volume eines solchen Servers öffnen. Danach "sieht" auch die Arbeitsstation und damit BImport diese Server.
Scheinbare Trustee-Unstimmigkeiten: Werden Homeverzeichnisse zwischen Servern oder Volumes verschoben, können manchmal scheinbare Trustee-Unstimmigkeiten auftreten. So kann es passieren, dass neben den korrekten Trustee-Einträgen des verschobenen Homeverzeichnisses auch leere Trustee-Einträge oder fehlende Trustee-Einträge auftreten. Dies sind tatsächlich nur scheinbare Unstimmigkeiten, die nach einiger Zeit, spätestens aber nach einem Server-Neustart, vom System selbst korrigiert werden.
17 Weitere Eigenschaften von BIMPORT
Environment-Variablen
Bei konsequentem Einsatz der Environment-Variablen SCHULE, SCHULSERVER in dafür geeigneten Umgebungen hat der Admin folgende Möglichkeiten des "Umschaltens" zwischen Schulen. Die Anzeige der Schule und des Schulservers rechts oben im Bild
lässt sich mit der linken Maustaste anklicken. Über das Fenster
lässt sich die Schule der Server oder beides ändern. Mit Klick auf den OK-Button wird die INI-Datei neu gelesen und neu bzgl. der Environment-Variablen interpretiert. Ins Eingabefenster kann z.B. folgendes eingegeben werden:
LFB (z.B. anderen Schulkürzel)
XServer05 (z.B. anderer Server)
LFB,GServer03 (oder beides gleichzeitig)
usw...
Ein Rechtsklick auf den Link setzt wieder alles zurück entsprechend der tatsächlich vorhanden Environment-Variablen, in dem diese neu gelesen und ausgewertet werden.
Login
Haben Sie BImport gestartet ohne sich vorher ins Netz eingeloggt zu haben, meldet BImport dies in einer Reihe von Fehlermeldungen. Entweder beenden Sie jetzt BImport, melden sich im Netz an und starten BImport erneut oder Sie wählen den Menüpunkt "Datei/Login"
und melden sich an. Hierbei wird ein vollständiges normales Novell-Login inclusive des Abarbeitens des Loginscripts ausgeführt. Lediglich das normale Novell-Login-Fenster ist dabei nicht sichtbar. Dieses ist aber alternativ auch über den Button mit dem roten N aufrufbar.
Hat das Login Erfolg, so erscheint eine entsprechende Meldung und nach wenigen Sekunden schließt sich das Login-Fenster.
In Fehlerfall erscheint auch eine Meldung, ohne dass sich das Login-Fenster schließt.
Das Login-Fenster kann auch dazu dienen, zu versuchen eine bestimmte Verbindung im Netz zur Primären zu machen. Ein Doppelklick auf das Feld "Tree" bzw. "Server" oder ein Klick auf den Tree-Button bzw. auf den Server-Button, lässt in Mehrserver/Mehrbaum-Umgebungen eine Auswahl zu, etwa so (hier mit etwas älteren Bildern):
 |
 |
Dies könnte sich in Fällen bewähren, bei denen beim Benutzer-Import eDirectory-Fehler ergeben, die mit dem Ansprechen des "falschen" Servers zusammenhängen.
Kommentare
Alle Zeilen (in der Quelldatei oder in der Containerzuweisungsdatei), die keine Feldbegrenzer aufweisen, werden von BImport nicht beachtet. (Ausnahme: der oben beschriebene Header in der Abgleich-Datenquelldatei). Darüber hinaus kann auch das Kommentarzeichen verwendet werden (z.B. auch zum auskommentieren von Datenzeilen), z.B.:
#"AKomm","Klasse1a","Komm","Aus","Aus Komm"
"SperlingH","Klasse1a","Sperling","Hans","Hans Sperling" # guter Schüler
Schreibweise von Benutzernamen und weiteren Feldern
Enthält der Benutzername in der Quelldatei Leerzeichen, Bindestriche, Punkte oder Apostrophe, so werden diese von BImport herausgefiltert.
| Zum Beispiel wird aus | der Benutzername: |
| Meier H | MeierH |
| Schneider-Brinkmann A | SchneiderBrinkmannA |
| D'Angelo A | DAngeloA |
| Müller Lüdenscheidt H | MuellerLuedenscheidtH |
| Freiherr v. d. Trenck O | FreiherrvdTrenckO |
Also:
Die gleichen Umwandlungen werden auch auf Nachnamen und Klassenbezeichnungen (Klassen dürfen Kontextpunkte haben) angewandt, nicht jedoch beim Vornamen und beim vollen Namen.
Vorgaben speichern
BImport kann die von Ihnen gemachten Vorgaben in einer INI-Datei, nämlich BImport.ini speichern.
Existiert bimport.ini (oder auch bimportstart.ini) nicht, während Sie BImport.exe starten, erscheint eine Fehlermeldung:
BImport nimmt dann einfach die im Programm voreingestellten Standardwerte. (Allerdings fehlen jetzt natürlich Lizenzdaten und BImport wird als Demo betrieben). Um aber entweder diese Fehlermeldung zu unterdrücken oder BImport mit selbstgemachten Voreinstellungen zu starten, sollten Sie die Voreinstellungen abspeichern. Dazu wählen Sie mit dem Butten "Einstellungen" oder über das Menü "Datei/Einstellungen 1" das Einstellungsfenster und klicken auf den Button "INI Speichern". Damit werden die momentan zu sehenden Vorgaben in BImport.ini gespeichert. (BImport.ini liegt immer in dem Verzeichnis, aus dem heraus BImport.exe gestartet wurde oder ist über die bimportstart.ini umgelenkt).
Sie können die Vorgaben auch in einer beliebigen anderen INI-Datei ablegen ("INI Speichern") oder holen ("INI laden" oder Menü "Datei/Öffne INI-Datei"). Mit dieser Option können Sie sich also für verschiedene Zwecke die Vorgaben in verschiedenen INI-Dateien vorhalten !
Nutzungsbestimmungen
Ebenfalls im Dateimenü (oder im Infomenü) finden Sie die Nutzungsbestimmungen. BImport ist keine Freeware. Bitte beachten Sie die Nutzungsbestimmungen!
Sie müssen die Ihnen bei der Registrierung mitgeteilten Lizenzdaten eingeben. Über den Menüpunkt "Datei/Lizenzdaten" erhalten Sie das Eingabefenster. Dort müssen Sie die Lizenzdaten exakt, wie sie Ihnen mitgeteilt wurden, unter Beachtung von Groß/Kleinschreibung, Leerzeichen, Bindestriche usw. eingeben (bei zeitlich unbegrenzter Nutzung bleibt das Ablaufdatum-Feld leer):
Ein Klick auf den OK-Button speichert die Lizenzdaten ab.
Achtung: Die Lizenzdaten werden ins BImport-Programmverzeichnis abgespeichert. Sie benötigen also dort Schreibrechte.
(Musterlösung: Der BenAdmin hat hierfür nicht genügend Rechte. Der Admin muss diese Aufgabe übernehmen.)
Auch Musterlösungsnutzer benötigen Lizenzdaten!
Gelegentlich kann es zeitlich eingeschränkte Testversionen, die als solche
erkennbar sind, geben, für die keine Lizensierung nötig ist. Auch
gibt es zeitlich begrenzte Vollversionen. Ansonsten ist BImport für nicht
lizensierte Nutzer eine zeitlich begrenzte Demoversion, die alle Funktionen
hat, aber nur 2 User bearbeiten kann.
(Die Lizenzdaten oben im Bild sind nur ungültige Beispieldaten!)
Ablaufdatum
Demo- und Testversionen haben ein Ablaufdatum. In Ausnahmefällen kann auch eine Vollversion ein Ablaufdatum haben, in der Regel sind lizensierte Versionen jedoch zeitlich unbegrenzt nutzbar. In diesem Fall bleibt das Ablaufdatum-Feld leer.
Ist ein Ablaufdatum gesetzt, so funktioniert das Programm nach Überschreiten dieses Datums nicht mehr. Im Info-Menü können Sie nachschauen, auf welches Datum das Ablaufdatum gesetzt ist.
Lizenzdaten nach abgelaufenen Ablaufdatum setzen
Um Lizenzdaten auch nach dem Ablauf des Ablaufdatums eingeben zu können, hat BImport den Kommandozeilen-Parameter /liz. Sie müssen dazu BImport mit diesem Zusatz starten.
| 1.Möglichkeit: Öffnen Sie eine DOS-Box (Eingabeauforderung) und geben dort am Prompt ein: bimport /liz einschließlich vollem Pfad ein und drücken die Enter-Taste. |  oder  |
| 2. Möglichkeit: Über Start/Ausführen und mit Hilfe des Buttons "Durchsuchen" wählen Sie K:\BImport\BImport.exe. Fügen Sie dann von Hand ein Leerzeichen und /liz an und klicken auf ok. |  |
In beiden Fällen wird BImport direkt in die Lizenzdateneingabe gestartet. Nach Eingabe der Lizenzdaten führt der Klick auf den OK-Button (oder auch Abbruch-Button) zur Beendigung von BImport. Haben Sie gültige Lizenzdaten eingegeben, wird danach BImport wie gewohnt bedient.
eDirectory, Novell Versionskontrolle
Einen Überblick über die Versionen des eDirectoty und des Serverbetriebssystems erhalten Sie mit dem Menüpunkt "Datei/Novell-Info".
Lehrer importieren
Natürlich können Sie mit BImport nicht nur Schüler in das eDirectory importieren, sondern auch Lehrer. Erstellen Sie dazu eine Datenquelldatei mit den gewünschten Feldern, jedoch entweder ohne Klassenfeld oder mit leerem Klassenfeld (""). Da die Lehrer innerhalb des eDirectory nach unserem Modell in den Container Lehrer.Benutzer... importiert werden sollen, wird in BImport der Basis-Container eben so eingestellt. Analog bekommt das BasisHomeDir den Wert Home\Lehrer bzw. das Lehrer-Template ist so eingestellt (dafür muss dann natürlich z.B. .Template_Lehrer.Lehrer... existieren).
Die Felder Datenquelle und Logdatei für eine Dateiauswahl, bzw. die Felder Basis-Container, Home-Volume, Basis-Homedirectory und Template für eine eDirectory-Objektauswahl können entweder direkt editiert oder durch einen Klick auf den jeweils rechts vom Feld stehenden Button oder ein Doppelklick direkt auf das Feld per Dialogbox mit den erforderlichen Daten versehen werden.
Für die Datenquelle und die Logdatei wird dazu die übliche Datei-Öffnen-Dialogbox verwendet:
Bei der Wahl der Logdatei ist folgendes zu berücksichtigen: Da ja BImport beim Schreiben in die Logdatei den vorgegeben Logdateinamen mit einem angehängten "_I", "_A", "_U", "_L", "_V", bzw. "_T" versieht, passiert hier bei der Auswahl per Dialogbox das Umgekehrte. Wählen Sie also z.B. bnutzer_I.log, benuter_A.log, benuter_U.log, benuter_L.log, benutzer_V.log, oder benutzer_T.log. Nach Klick auf den Öffnen-Button, steht im BImport-Logdatei-Feld der Logdateiname ohne dieses Anhängsel.
Bei den restlichen Feldern wird bei der Eingabe per Dialogbox ein eDirectory-Browser aufgerufen, der im Stil des NWAdmin-Programms arbeitet, wenn auf das Eingabefeld doppelt geklickt wird. Beim Klick auf den nebenstehenden Button erscheint der (leichter zu bedienende) Mini-eDirectory-Browser. Treffen Sie also im ersten Fall im rechten Fenster ein Vorwahl, um dann die endgültige Wahl im linken Fenster vorzunehmen. Im zweiten Fall wird alles über ein Fenster gewählt. Wenn BImport den eDirectory-Browser startet, wird bereits eine dem jeweiligen Feld entsprechende Kategorie angesteuert. Außerdem versucht BImport aus dem Inhalt des betreffenden Feldes gleich "in die Nähe" der gewünschten Daten zu gelangen.
Basis-Container
 |
 |
Home-Volume
 |
 |
Basis-Homedirectory
 |
 |
Template
 |
 |
Weitere Eigenschaften des eDirectory-Browsers (NWAdmin-Stil)
In der Regel ist also die jeweils gewünschte Objektklasse vorgewählt. In diesem Feld Objektklasse können Sie jedoch die Objektklasse durch Klick auf den nebenstehenen "Pfeil"-Button auch selber vorwählen. Im linken Fenster erscheinen dann jeweils nur Objekte dieser Klasse, wenn überhaupt welche vorhanden sind. Löschen Sie den Inhalt des Feldes Objektklasse, so sehen Sie wieder alle Objekte.
Mit den Feldern Objektmaske bzw. Contextmaske können Sie die Ausgabe filtern. Im obigen Bild würde der Filter "Klasse1a" im rechten Fenster eben nur diese Klasse anzeigen, während der Filter "K*" alle Klassen anzeigen wird. (Als Jokerzeichen ist nur ein angehängtes * möglich).
Wenn Sie immer schon einmal wissen wollten, wie die Objektklassen intern vom eDirectory bezeichnet werden, so setzen Sie das Häkchen bei "zeige Objektklassen".
Mit dem "Context"-Button, können Sie auch direkt einen Context vorgeben, ohne sich durch den eDirectory-Baum hangeln zu müssen.
Die Auswahl eines Objektes findet grundsätzlich im linkem Fenster statt! Entweder durch Doppelklick oder durch Einfach-Klick mit anschließendem OK-Button. (Wenn es nichts zu wählen gibt, ist der OK-Button inaktiv).
Für Tastaturfreunde (oder Maus-Gegner) lässt sich der eDirectory-Browser (wie das ganze BImport) natürlich auch mit den unter Windows üblichen Tasten steuern. TAB-Taste für das Wechseln zu den Fenstern, Feldern und Buttons, Pfeil auf/ab innerhalb der Fenster zum Selektieren von Objekten, usw...
Design-Einstellungen
Über das Menü "Datei/Einstellungen 2" lässt sich das Aussehen von BImport in vielfältiger Weise einstellen.
Zwei vorgefertigte Designs (paedML/LMZ und BImport) lassen sich über den Design-Radiobutton und den Button "Zurücksetzen" anzeigen. Über den Radiobutton "Sprache" und den Button "Anwenden" lässt sich BImport in deutsch oder englisch betreiben. Für viele Objekte lässt sich Farbe und Schrift wählen. Der Button "Design speichern" schreibt eine bimportdesign.ini ins BImport-Programmverzeichnis (dafür sind dort Schreibrechte nötig).
Die meisten Eigenschaften von BImport sollten damit beschrieben sein.
Viel Erfolg mit BImport !