ich habe die Installation eines Win10-Muster-PC in einer UEFI VM (KVM) mit der v7.2 getestet.
Haben den global-reg vor dem Domänenbeitritt hinzugefügt, Domänenbeitritt ausgeführt, Image erstellt, image-reg auf dem Server angewendet.
Starte ich den Client synchronisiert, dann erhalte ich Fehler mit dem Hinweis auf IO-Fehler. Anbei die LOG-Datei.
Starte ich das Image aus dem Cache funktioniert dies.
Ich sehe Anmelden an: SAMBADOMAIN
Gebe ich dort aber gshoenningen.linuxmuster.lan\global-admin an, kann ich mich anmelden !
Ideen, warum der Sync nicht funktioniert?
Ideen, warum dennoch SAMBADOMAIN angezeigt wird und nicht die von mir in der image-reg eingetragene Domain ?
meine Domäne habe ich in der img-reg Datei eingetragen. In der Patch.log sehe ich aber nur, dass der Hostname angepasst wird. In der Datei wird aber beides gepatcht …
meine Domäne habe ich in der img-reg Datei eingetragen. In der Patch.log
sehe ich aber nur, dass der Hostname angepasst wird. In der Datei wird
aber beides gepatcht …
die Sache ist anders vorgesehen:
eintragen der eigenen SAMBADOMAIN in der global.reg
diese im Client einspielen
Image erstellen
image.reg als IMAGENAME.reg bereitstellen unter /srv/linbo/images/HWK/
Das war mal anders.
Vor allem hieß die imagereg früher mal IMAGENAME.cloop.reg und jetzt
„ohne .cloop“
Wenn bei dir das Kind schon in den Brunnen gefallen ist, dann nimm mal
die global.reg aus /srv/linbo/examples/ , pass die SAMBADOMAIN an und
lösch alle Zeilen außer der mit der Sambadomain raus (der Pfad muss auch
drin sein) und spiel das Ding nochmal am Client ein.
Danach Image erstellen und schauen was passiert.
Du bist mein Held Ich habe gerade die Doku für die v7.2 für die Win10-Clients überarbeitet und das Vorgehen so angewendet, wie wir es „früher“ beschrieben hatten. Es ist genauso wie Du es beschrieben hast. Die Anpassungen sind nunmehr in der global.reg durchzuführen.
Dann klappt das auch!
Die IO - Fehler treten immer beim Sync auf. Nutze ich den roten Button, um Windows neu installieren, klappt auch dies - hatte @Steffen66 angemerkt.
Welche Einstellungen habt Ihr bei Euch in der start.conf im Produktivbetrieb, um Windows nach jedem Start sauber / zurückgesetzt wieder starten zu lassen?
Danke. Ich habe nun die überarbeitete Doku für v7.2 für Windows-Clients entsprechend korrigiert. @baumhof : Holger könntest Du Dir die v7.2 Doku nochmals ansehen, um zu prüfen, ob das so nun korrekt beschrieben ist ? Klappt meine Beschreibung von Defprof so auch im Rollout oder muss da noch mehr gemacht werden ? In meiner VM Umgebung läuft das so.
Dann klappt das auch!
Die IO - Fehler treten immer beim Sync auf. Nutze ich den roten Button,
um Windows neu installieren, klappt auch dies - hatte @Steffen66 angemerkt.
Welche Einstellungen habt Ihr bei Euch in der start.conf im
Produktivbetrieb, um Windows nach jedem Start sauber / zurückgesetzt
wieder starten zu lassen?
ich hab meine synceinstellungen nicht in der start.conf sondern in der
/srv/linbo/boot/grub/HWK.cfg
Dort setze ich den Timeout auf 3 Sekunden und die Default Aktion auf
Windows neu+start
Das ist nach der Zählung in der Datei die 4
0 = linbo
1 = win direktboot
2 = win ungesynct booten über linbo
3 = win syncstart
4 = win neu+start
@baumhofhttps://ask.linuxmuster.net/u/baumhof : Holger könntest Du
Dir die v7.2 Doku nochmals ansehen, um zu prüfen, ob das so nun korrekt
beschrieben ist ? Klappt meine Beschreibung von Defprof so auch im
Rollout oder muss da noch mehr gemacht werden ? In meiner VM Umgebung
läuft das so.
der erste Teil ist bedenklich:
"die Global Registry liegt als Vorlage auf dem Server in
\server\srv\linbo\examples und heißt win10.global.reg und muss nach
\srv\samba\global\management\global-admin kopiert werden, um Sie dann
auf dem PC anwenden zu können. Das geht z.B. über die Konsole des
Servers selbst:
Wir nennen das „im sambaverzeichnis rumfroschen“…
Du kopierst dann auf linuxebene eine Datei in das vom samba verwaltete
Verzeichnis.
Ich kenne mich da nicht so aus, aber: damit weiß linux, dass die Datei
da ist und welche Rechte sie hat: aber wie soll samba das mitbekommen?
Und welche ACLs soll es für die Datei setzen?
Generell wurde mir mal gesagt: du darfst unterhalb von /srv/samba/
Dateien löschen: aber nicht hinkopieren, verschieben, umbenennen,
erschaffen.
Der puttyweg ist besser: würde aber bei mir nirgend wo gehen, wegen der
obligatorischen ssh-keys: den müßte ich mitbringen.
Früher war das Verzeichnis /var/linbo/ auch ein sambashare, dass man als
(damals) administrator einbinden konnte am Client (vorübergehend) mit
dem linbo user und dessen Passwort… vielleicht geht das noch.
Das würde ich empfehlen (wenn es noch geht).
Hallo Holger,
danke, dass Du die überarbeitete Doku hier für 7.2 Windows - Client kontrolliert hast.
Ja, das ist soweit klar. Hier in diesem Fall geht es „nur“ darum, dass die Vorlagendatei am Client überhaupt für den global-admin zur Verfügung steht, damit diese auf den Client heruntergeladen werden kann. Die Alternative wäre ein anderes Verzeichnis (wie z.B. /var/linbo/) zu nehmen, das auf dem Client verbunden werden kann. Ein anderes geeignetes Share, das die genannte Problematik umgeht, ist in der smb.conf allerdings nicht als Standard eingerichtet.
Ich denke, es ist daher für die Installation des Muster-Windows-Clients vertretbar, dass nur für diesen Zweck die Vorlage win10.global.reg nach …\management\global kopiert wird, um diese auf den Client herunterzuladen, an die eigene Domain anzupassen und auf dem Client einzuspielen.
Ja, das ist soweit klar. Hier in diesem Fall geht es „nur“ darum, dass
die Vorlagendatei am Client überhaupt für den global-admin zur Verfügung
steht, damit diese auf den Client heruntergeladen werden kann. Die
Alternative wäre ein anderes Verzeichnis (wie z.B. /var/linbo/) zu
nehmen, das auf dem Client verbunden werden kann. Ein anderes geeignetes
Share, das die genannte Problematik umgeht, ist in der smb.conf
allerdings nicht als Standard eingerichtet.
Ich denke, es ist daher für die Installation des Muster-Windows-Clients
vertretbar, dass nur für diesen Zweck die Vorlage win10.global.reg nach
…\management\global kopiert wird, um diese auf den Client
herunterzuladen, an die eigene Domain anzupassen und auf dem Client
einzuspielen.
auch bei „nur einmal“ kann was kaputt gehen.
Außerdem „trainiert“ man dem Admin an, dass sowas geht … ich würde das
so echt nicht da rein schreiben.
Teste doch mal ob man das Verzeichnis von linbo noch mounten kann vom
Cleint aus mit dem user linbo … das ging doch mal…
Hallo Holger,
damit die Share gar nicht benötigen, teste ich mal, ob am Client das Putty SCP Tool funktioniert, um die Vorlagendatei einfach auf den Client herunterzuladen.
Die früheren Shares, auf die Du Dich beziehst, sind so bislang nicht mehr in verfügbar.
LG
Christian
ich habe das Ganze mit WinSCP nun umgesetzt und die Doku entsprechend angepasst. So ist das Einspielen der win10.global.reg auch schneller / einfacher erledigt. Neue Doku dazu ist online: Windows 10 Clients — linuxmuster.net 7.2 Dokumentation
Hallo Chris,
nach einem Start von Windows über Linbo mit Grün gibt es einen Ordner C:/linuxmuster-win mit der win10.global.reg darin. Der lokale Administrator muss nur einmal den Ordner übernehmen (auf Fortsetzen klicken, wenn die Frage nach der Berechtigung kommt). Dann kann man sich die Aktion mit cp auf dem Server oder WinScp sparen.
Der Teil mit der SAMBADOMAIN / Linuxmuster gehört aus der win10.global.reg-Datei raus. Windows macht das alleine richtig, der Eintrag kann eher Probleme verursachen.
Auf der Seite Windows 10 Clients — linuxmuster.net 7.2 Dokumentation ist Nr. 31 „Rechner nicht herunterfahren, sondern unbedingt im nächsten Schritt den Global Registry-Patch einspielen, ansonsten funktioniert Windows nicht mehr und muss neu installiert werden!!“ unnötig.
Nach einem Neustrat funktioniert Windows weiter ohne Probleme. Der Global Registry-Patch sollte nur vor Aufnahme des Rechners in die Domain eingespielt werden, da es ansonsten zu einer Änderung des Kennworts für das Computerkonto kommen kann.
Nur nach der Aufnahme des Rechners in die Domain muss ein Image erstellt werden, damit Linbo das Kennworts für das Computerkonto (neu) speichert.
Ansonsten kann die Vertrauenstellung verloren gehen. In dem Fall mit einem lokalen Administrator anmelden, eine Powershell als Admin starten und Reset-ComputerMachinePassword -Credential global-admin eingeben. Anschließend ein Image neu erstellen.
sehr guter Hinweis, das kannte ich noch gar nicht. Ich habe es jetzt als Variante A beschrieben und WinSCP als Variante B noch drin gelassen, falls unverhoffter Weise mal der o.g. Ordner nicht zur Verfügung stehen sollte.
Ok, ist, das so mehrfach getestet und als commit in linuxmuster-base? Dort müsste die Vorlagendatei ja in angepasster Form bereitstehen. Danach kann ich den Passus rausnehmen.
das mit der SAMBADOMAIN kam ohne Erklärung/Issue in die win10.global.reg hinein. Den entsprechenden Eintrag macht Windows bei der Aufnahme in die Domain aber eigentlich selbst. Macht für mich hier keinen Sinn.
Bei der Variante A mit in C:/linuxmuster-win wird der Eintrag SAMBADOMAIN automatisch seit unix2dos & sambadomain fix for windows regfiles in cache. · linuxmuster/linuxmuster-linbo7@f803a14 · GitHub richtig angepasst. Eine manuelle Änderung ist in dem Fall nicht mehr nötig.
Ein Commit oder so hab ich nicht erstellt.
Das mit Reset-ComputerMachinePassword -Credential global-admin würde ich am Ende der Seite als allgemeiner Hinweis Vertrauenstellung machen.
Auch wenn bereits beim Start über LINBO die Systemzeit synchonisiert wird, sollte auch Windows statt der standardmäßigen Microsoft-Server im Internet den linuxmuster.net Server als NTP-Zeitserver benutzen.
Wenn ich das richtig im Kopf habe, dann aktualisiert Linbo nur für sich die Zeit, nimmt aber keine Änderungen an der Uhr des Computers mehr vor. Wegen der Sache mit UTC vs. Localtime
Ein in der Domain befindliches Windows benutzt keine Microsoft-Server im Internet als Zeitserver! Zeitserver ist dann der Domaincontroller.
Wenn aber Linuxmuster vor dem 20.09.2022 installiert wurde, dann hat der Linuxmuster-Server eine fehlerhafte Konfiguration von Samba, die den Zeitabgleich für Windows verhindert. Das wird nicht (!) automatisch mit einem Update repariert.
Führe in diesem Fall am Server folgenden Befehl aus:
sudo /usr/share/linuxmuster/fix-ntp_signd-dir.sh
Das ist ein Linuxmuster Problem und kein Windows Problem.
Bitte keine neuen GPOs für NTP erstellen. NTP wird von Windows in der Domain nicht verwendet.
mall dumm in die Runde gefragt, was macht sudo /usr/share/linuxmuster/fix-ntp_signd-dir.sh was unumkehrbar etwas kaputt machen würde, so dass man das nicht bei jeder Installation einer neuen Version genau dieses deb-Pakets automatisch ausführen könnte?
Andersherum: Wieso werden Admins genötigt, das per Hand auszuführen, wo doch der Paketersteller das Skript einfach bei jedem Paketupdate problemfrei durchlaufen lassen könnte?
Hallo Buster,
ich habe mal nach der sh-Datei im aktuellen v7.2 gesucht. Dort gibt es diese nicht mehr. In den commits linuxmuster-base ist dies gefixed, so dass das Skript nicht mehr benötigt wird.
Die Doku habe ich entsprechend angepasst.
VG
Chris
Ich habe gerade die Doku für die v7.2 für die Win10-Clients überarbeitet und das Vorgehen so angewendet, wie wir es „früher“ beschrieben hatten. Es ist genauso wie Du es beschrieben hast. Die Anpassungen sind nunmehr in der global.reg durchzuführen.