LD4.0: Nacharbeiten nach erfolgreicher Server-Migration
Einführung:
Nach erfolgreichem Abschluss des Upgradeskripts ist es erforderlich, an diversen Stellen des LD-Systems Anpassungen vorzunehmen, um die Funktionalität und Stabilität der zahlreichen Module von LogoDIDACT sicherzustellen.
Zunächst ist eine Einwahl und Anmeldung im neuen LD Control Center nötig. Dieses lässt sich im Browser über die URL https://ctrl aufrufen. Anpassungen sind sowohl im Reiter "Deployment", als auch in der "Benutzerverwaltung" notwendig.
Deployment:
Beim erstmaligen Öffnen der allgemeinen Geräteübersicht fallen nun mehrere Veränderungen ins Auge:
- an oberster Stelle steht anstatt der üblichen ad.schulname.logodidact.net Domäne der Knotenpunkt "ROOT"
- der Anzeigename der Schule (LongName) ist mit einem _updateSCHULNAME gekennzeichnet
- Räume sind mit einem vorangestellten _conflictRAUMNAME dargestellt
--UMFORMULIEREN--
#Das Vorhandensein der neuen Stammdomäne "ROOT" ist auf die mit LD4.0 eingeführte Multi-Mandantenfähigkeit zurückzuführen. Es ist somit möglich, mehrere Schulen (Mandanten), z.B. ein Schulzentrum bestehend aus Grund-/Realschule und Gymnasium zentral unter ihren #eigenen Domänen abzubilden.
Aufgrund der Neustrukturierung wird allerdings auch die alte Domäne zerstört und neu aufgebaut, sodass zunächst die schuleigene Domäne und der Longname der Schule einmalig aktualisiert werden müssen. Dazu ist in den Konfigurationsoptionen des Mandanten der neue Punkt "Domänen" hinzugekommen. Über das Stiftsymbol kann man dies bearbeiten:
In der Regel ist die lokale Standarddomäne "schule.local" als Hauptdomäne für den Mandanten zuweisbar. In Sonderfällen kann die Standarddomäne von der üblichen Bezeichnung abweichen. ##Maildomäne
Im Anschluss muss man nun noch den Longname unterhalb des ROOT-Knoten korrigieren, sowie die Räume umbenennen und an den richtigen Standort (Mandanten) verschieben.
Ebenfalls empfehlenswert ist die Vollständigkeit der Objektzuweisungen im LD Control Center zu prüfen. Darunter fallen:
- AutoConf-Rollen
- Softwarekonfigurationen
- Treiberkonfigurationen
- Druckerkonfigurationen
- Betriebssystemzuweisungen
- "Schutz vor Statusänderungen" an speziellen Clients, wie z.B. die KMS
Schlussendlich muss an allen Clients, welche eine Imagekonfiguration per LD Deploy erhalten haben, ein Re-Deploy durchgeführt werden.
Benutzerverwaltung:
Wechseln Sie zunächst in die allgemeine Übersicht des LD Control Center, indem Sie auf das Haus-Symbol in der linken oberen Fensterecke klicken und das Feld "Benutzerverwaltung" auswählen. Die allgemeine Übersicht ist auch hier ähnlich aufgebaut, wie im "Deployment".
Es wird die Stammdomäne "ROOT", sowie der Mandant und die darunter liegenden Klassen/-Projekt/-und Sicherheitsgruppen, sowie Rollen (mandantenbezogen) angezeigt.
Benutzerlistenimport
Im Reiter Home/Verwaltung/Benutzerimport müssen die alten Benutzerlisten aus LD2.0 einmalig angelegt und verifiziert werden. Eine automatische Übernahme der Nutzerlisten während der Migration ist nicht möglich.
Die Benutzerlisten liegen als .list-Dateien vor und sind im Container logosrv unter folgendem Pfad gespeichert: root@logosrv: cd /etc/logodidact/userlist/
Diese Dateien können serverseitig mittels eines FTA (FileTransferAgent wie z.B. WinSCP) oder aber über einen Client an der Schule über die Logodidact Console exportiert und als CSV-Datei gespeichert werden. Wechseln Sie nun in das LD Control Center zum Benutzerimport.
Zunächst wird für jede Nutzerliste eine Konfiguration erzeugt. Wichtige Angaben sind:
- der Anzeigename der Liste
- der Separator, auch als Trennzeichen zwischen den Spalten einer CSV-Liste bekannt
- die Codierung
- "CSV-Header ignorieren" -> zumeist besitzen die CSV-Dateien bereits Spaltennamen
- Rolle (Schüler, Lehrer, etc.)
Anschließend kann über den Button "Benutzerliste hochladen" in der rechten oberen Optionsleiste eine Benutzerliste hinzufügen.
Wie bereits beim Benutzerimport über die LD Console unter LD2.0 bekannt, erhalten Benutzer zur eindeutigen Zuordnung im System eine eindeutige Kennung, der sich aus verschiedenen Benutzereigenschaften (Vorname,Nachname,Geburtsdatum,Kürzel,etc.) zusammensetzt. Notwendigerweise muss dies ebenfalls einmalig pro importierte Liste gesetzt werden und ist über die Spaltenzuordnung möglich. Ebenfalls muss das Schema unbedingt beibehalten werden.
Nachdem alle notwendigen Konfigurationen getätigt sind, verifiziert man die Benutzerliste. Dabei werden die Datensätze aus der Benutzerliste auch Vollständigkeit und Korrektheit geprüft. Die Verifizierung erfolgt in der allgemeinen Benutzerimport-Ansicht.
Mit einem Klick auf die entsprechende Benutzerliste wählt man das "Prüfen-Symbol" aus. Über den Status wird der Fortschritt der Verifizierung angezeigt.
Neben dem Status existiert auch eine Log, die bei Verifizierungsfehlern Aufschluss geben kann.
Mit erfolgreicher Verifizierung der Benutzerliste ist der Vorgang abgeschlossen.
Optional:
Die nachfolgenden Konfigurationen sind optional, werden allerdings sbe-seitig, unter anderem aus Sicherheits/-und funktionalen Gründen, empfohlen.
Benutzerrichtlinie
Eine Benutzerrichtlinie definiert diverse benutzer/-oder gruppenbezogene Eigenschaften, darunter die Passwortrichtlinien, sowie Mail/-Festplatten/-und Druckkontingente. Im Beispiel wird zunächst eine globale Benutzerkonfiguration erstellt und mit dem ROOT-Stamm verknüpft. Aufgrund des Vererbungsprinzips erhalten alle darunter liegenden Objekte dieselbe Konfiguration zugewiesen. Natürlich kann die Vererbung durch Erstellen und Verknüpfen einer weiteren Benutzerkonfiguration zu einem Objekt im Stammverzeichnis überschrieben werden.
Zunächst wird unter Home/Benutzerverwaltung/Konfigurationen/Benutzerkonfigurationen eine neue Richtlinie erstellt, indem man auf das '+'-Symbol in der rechten oberen Optionsleiste klickt.
Im darauf erscheinenden Fensterchen legt man im Reiter "Generell" zunächst einen aussagekräftigen Namen für die neue Richtlinie fest, sowie allgemeine Passworteigenschaften.
Die explizite Passwortdefinition erfolgt im nächsten Reiter "Generierungsregeln". Hier werden die minimale Kennwortlänge, die Komplexität (Kleinbuchstaben/Großbuchstaben/Sonderzeichen, Zahlen) und auch die verwendbaren Sonderzeichen definiert. Am Besten ist eine minimale Kennwortlänge von mind. 8 Zeichen. Wir empfehlen die Passwort-Vorgaben von Microsoft einzuhalten. Besonders an Schulen, welche den LD-Azure-Sync-Connector zur Benutzerkontensynchronisation vom lokalen LD-Server zu Microsoft 365 nutzen, ist dies unerlässlich.
Im letzten Reiter "Kontingent" erfolgen die Kontingentbegrenzungen zu Mail/-Festplatten/-und Druckkontingenten.
BGD-Deployment
...
Dazu ist ein Wechsel weg von der Benutzerverwaltung zum Deployment notwendig. Eine Background-Deployment-Konfiguration (BGD) wird unter Home/Deployment/Konfigurationen/Background Deployment durch Klick auf das '+'-Symbol in der rechten oberen Optionsleiste erstellt.
Standardmäßig können die bereits vordefinierten Werte beibehalten werden. Für eine nähere Erläuterung der einzelnen Auswahloptionen folgen Sie bitte dem Artikel Link-Text eingeben.
Abschließend kann man die BGD-Konfiguration in der allgemeinen Übersicht verknüpfen.
Treiberkonfiguration
In den Optionen einer Treiberkonfiguration können mit LD4.0 nun "Treiber von WinPE Konfiguration übernehmen" aktiviert und deaktiviert werden. Somit verwendet der Client schlussendlich explizit die vom Nexus während der WinPE-Phase bereitgestellten Treiber. In einigen Sonderfällen verwendet ein Client die während der Setup-Phase vom Windows Treiber Management automatisch ausgesuchten Treiber, selbst wenn die Option "Windows Treiber Management aktiviert" deaktiviert ist. Für eine nähere Erläuterung der einzelnen Auswahloptionen folgen Sie bitte dem Artikel Link-Text eingeben.
