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
ROOT bezeichnet an dieser Stelle den obersten Eintrag in der Abbildungshierarchie von Mandanten. Unterhalb eines ROOT-Verzeichnisses können unter LD4.0 auf lange Sicht mehrere Mandanten (Haussymbol) strukturell abgebildet werden. So lässt sich beispielsweise ein Schulzentrum, bestehend aus Grund-/Realschule und Gymnasium darstellen.
Aufgrund dieser eingeführten Neustrukturierung wird allerdings die von LD2.0 bekannte Struktur (ad.schulname.logodidact.net) während der Migration zerstört und neu aufgebaut. Von LD Deploy verwaltete Rechner verlieren in diesem Prozess ebenfalls ihre Vertrauensstellung zur Domäne.
Zunächst einmal müssen die schuleigene E-Mail-Domäne und der LongName der Schule einmalig aktualisiert werden. 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 Standardmaildomäne "schule.local" als Hauptmaildomäne für den Mandanten zuweisbar. In Sonderfällen kann die Standardmaildomäne von der üblichen Bezeichnung abweichen.
Erst im Anschluss - also nach der Festlegung einer Maildomain - kann der LongName unterhalb des ROOT-Knoten umbenannt und sinnvoll vergeben werden. Hier empfiehlt es sich, mindestens das vorangestellte Schlüsselwort "_update" im Namen zu entfernen. Für die Räume gilt dies genauso, diese sollten umbenannt und wieder in die richtige Struktur gebracht werden. Das Verschachteln der Räume ist über den Menüpunkt "Standort" pro Raum oder auch per Drag-and-Drop möglich.
Ebenfalls empfehlenswert ist die Vollständigkeit der Objektzuweisungen im LD Control Center zu prüfen und die Elementverlinkungen, z.B. kann es vorkommen, dass eine AutoConf-Rolle gar nicht oder dem falschen Raum zugewiesen ist. Gegebenenfalls diese per Drag&Drop oder aber über den Reiter "Standort" im jeweiligen Raum / Mandanten zuweisen. Eine Kontrolle der Konfigurationen muss zwingendermaßen für jeden einzelnen Raum bzw. jedes einzelne Gerät stattfinden! Die Richtigkeit sollte man mittels Screenshots, welche man vor dem LD4.0 Upgrade erstellt, nachweisen.
Zu Objekt-und Elementverlinkungen fallen:
- AutoConf-Rollen
- Softwarekonfigurationen
- Treiberkonfigurationen
- Druckerkonfigurationen
- Betriebssystemzuweisungen
- "Schutz vor Statusänderungen" an speziellen Clients, wie z.B. die KMS
ZU KNAPP... mit Screenshots erklären.... pro Listenobjekt rechts im Fenster die "Zuweisungen" aufklappen und kontrollieren, ob hier Verlinkungen zu Räumen/Geräten oder übergeordnet existieren. Falls gar keine Zuweisungen vorhanden sind, in den früheren Screenshots (vor dem LD4.0 Upgrade) überprüfen, ob das so seine Richtigkeit hat.
Schlussendlich muss an allen Clients, welche eine Imagekonfiguration per LD Deploy erhalten haben, ein Re-Setup durchgeführt werden. Primär dient der Re-Setup dazu, die von LD Deploy verwalteten Rechner wieder in die Schul-Domäne aufzunehmen und somit unter anderem die Anmeldung der Schüler und Lehrer an den Arbeitsstationen nach dem Upgrade sicherzustellen.
Neben einem Re-Setup kann die Wiederaufnahme eines Rechners ebenfalls per Re-Deploy sichergestellt werden. Sinnvoll ist dies jedoch nur, wenn ein/mehrere Client/s Problem haben sollten, der Domäne bei einem Re-Setup beizutreten oder aber ausreichend Zeit für den Vorgang vorhanden ist.
WARUM? -> auch erklären. Es wird dadurch erreicht, dass die Rechner in der neuen Domäne wieder ihr Rechnerkonto erhalten. An PCs, die Standalone ohne Domäne betrieben werden, kann man sich das Re-Deploy auch sparen.
Ebenfalls erklären, dass es neben Re-Deploy auch andere Aktionen gibt, die den gewünschten Zustand erzielen. Die Aktion "Re-Setup" reicht aus, um den Rechner wieder in die Domain joinen zu lassen. Das wäre der empfohlene Weg, Re-Deploy dann erst bei Problemen oder wenn zeit keine Rolle spielt.
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 der Knoten "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 nachfolgenden Schritte unbedingt mit Sorgfalt durchführen und vor dem Import nochmals auf Korrektheit und Vollständigkeit prüfen!
Serverseitig liegen die Benutzerlisten als .list-Dateien vor und sind im Container logosrv unter folgendem Pfad gespeichert: root@logosrv: cd /etc/logodidact/userlist/
Mittels eines FTA (FileTransferAgent) wie z.B. WinSCP ist ein Export aller Benutzerlisten aus dem serverseitigen Pfad im logosrv möglich.
Alternativ kann man die Benutzerlisten über die LD Console exportieren. Dazu die LD Console öffnen, beispielweise an einem internen Rechner im Schulnetz und in den Optionen den Reiter "Benutzerverwaltung" auswählen.
Hier findet sich im oberen Bereich eine tabellenartige Aufzählung aller auf dem Server momentan in Verwendung befindlichen Benutzerlisten. In der Regel sind dies standardmäßig Schüler und Lehrerlisten, sowie "Sonstige Benutzer".
Aus Sicht eines Endkunden denken, der ggf. keinen root-Zugriff auf den Server hat! Daher auch noch den alternativen Weg dokumentieren/erklären, die früheren Benutzerlisten CSV-Files per LogoDIDACT Console abzuholen. Diese Schritte müssen sehr genau erklärt werden, damit später keine Konten ungewollt im System entfernt werden, weil die Listen nicht passen.
Diese Dateien können serverseitig im genannten Pfad oder aber über einen Client an der Schule via LogoDIDACT Console exportiert und als CSV-Datei gespeichert werden. Achten Sie darauf, die CSV-Dateien für alle Benutzerlisten zu speichern, die in Verwendung sind. In der Regel gibt es mindestens eine Lehrer-Liste und eine Schüler-Liste. Wechseln Sie danach in das LD Control Center zum Benutzerimport, um die Listen samt Einstellungen wieder anzulegen.
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. Vergleichen Sie bei Unklarheiten die Einstellungen mit der früheren Listenkonfiguration aus der LogoDIDACT Console. Dort sind alle Spalten mit einem * markiert, die für die Benutzerkennung verwendet wurden. 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. Das zu erwartende Ergebnis in der Verifizierung ist, dass keine Benutzerkonten gelöscht oder neu erstellt werden. Dies ist der entscheidende Hinweis, dass die Benutzerlisten-Einstellungen mit den früheren Einstellungen übereinstimmen und somit die richtigen Optionen festgelegt wurden.
Erläutern: Ebenfalls an Beutzer denken, welche manuell dem System hinzugefügt wurden.
Optional:
Die nachfolgenden Konfigurationen sind optional, die Festlegung dieser Einstellungen wird allerdings aus Sicherheitsgrü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.
Bitte die Gültigkeitsdauer des Kennworts hier im Beispiel-Screenshot entfernen und unausgefüllt belassen. Erzeugt nur Chaos an Schulen.
Im darauf erscheinenden Fenster 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.
Bitte ein sinnvolles Beispiel aufführen. Sinnvoll bedeutet, es werden NICHT 2 Kleinbuchstaben + Großbuchstaben + Zahlen + Sonderzeichen gefordert, sondern jeweils 1 Zeichen von allen Typen.
Im letzten Reiter "Kontingent" erfolgen die Kontingentbegrenzungen zu Mail/-Festplatten/-und Druckkontingenten.
Hier muss erklärt werden, was diese Einstellung bewirkt. Denn in den einzelnen Benutzer-Einstellungen der Konten kann man ebenfalls Quotas festlegen. Wann wird welche Einstellung angewandt?
BGD-Deployment
Warum wird speziell das Anlegen einer BGD-Deployment Option hier klärt und die anderen Einstellungen nicht? Wo genau liegt hier der Bezug zum LD4.0 Upgrade?
...
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 zu ungenau - der Mehrwert liegt in den systemkritischen Treibern, die zwingend für den ersten Bootvorgang eines neuen Clients benötigt werden. Durch dieses Häkchen stehen die Treiber bereits in der Initialisierungsphase von Windows ("Geräte werden betriebsbereit gemacht") zur Verfügung, was insbesondere bei Festplattentreibern und Grafiktreibern sehr hilfreich ist und Bluescreens vermeiden kann https://www.ubackup.com/screenshot/de/others/windows-10-inaccessible-boot-device-after-clone.png.
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.
