| | |
|---|
| | | automatisch selbst eingetragen (`Add-MpPreference`) |
|---|
| | | - Firewall-Freigabe-Skript ergänzt, nachdem der Test im echten |
|---|
| | | Firmennetzwerk anstand (Port 5000 war durch die Windows-Firewall blockiert) |
|---|
| | | - **Installer-Dateien werden direkt ins Paket gebündelt statt zur Laufzeit |
|---|
| | | nachzuladen.** Auslöser: beim ersten Test im Firmennetz enthielt der |
|---|
| | | Download nur die Skript-Dateien, die eigentlichen Installer wurden erst |
|---|
| | | beim Ausführen auf dem Zielrechner per Netzwerk nachgeladen – das setzt |
|---|
| | | Netzwerkzugriff des Zielrechners auf den Server in genau dem Moment |
|---|
| | | voraus. Jetzt werden die Dateien beim Erzeugen des Pakets direkt mit |
|---|
| | | eingepackt, der Zielrechner braucht für die Installation selbst kein |
|---|
| | | Netzwerk mehr (nur die abschließende, optionale Protokoll-Meldung). |
|---|
| | | |
|---|
| | | ## Offene Design-Frage: Skript-Ansatz vs. automatische Verteilung |
|---|
| | | Nach dem ersten Test im Firmennetz wurde nochmal grundsätzlich hinterfragt, |
|---|
| | | ob der Skript-Ansatz (manueller Download + Ausführen auf dem Zielrechner) |
|---|
| | | der richtige Weg ist, oder ob Daten "automatisch" auf dem Zielrechner landen |
|---|
| | | sollten. Eine echte automatische Verteilung ohne manuellen Schritt am |
|---|
| | | Zielrechner würde entweder eine dauerhaft laufende Helfer-Software auf jedem |
|---|
| | | Zielrechner oder Windows-Remoting (PowerShell Remoting) voraussetzen – beide |
|---|
| | | Wege brauchen im Kern eine Domänen-Infrastruktur bzw. zentrale |
|---|
| | | Zugangsdaten-Verwaltung, die aktuell nicht vorhanden ist. Diese Frage wurde |
|---|
| | | bewusst nicht in diesem Prototyp entschieden, sondern als offener Punkt für |
|---|
| | | die Übernahme festgehalten (siehe README.md). |
|---|
| | | |
|---|
| | | ## Testmethodik (durchgehend) |
|---|
| | | Da die Zielumgebung Windows ist, die Entwicklung aber in einer Linux-Umgebung |
|---|
