nach dem Update auf lmn7 sind nun die Clients dran. Ich habe alles Clients aktualisiert. Aus der alten Domain genommen, neu gestartet, die global.reg eingespielt, Beitrit zu neuen Domain.
Danach image erstellt. Es wurde eine macct-Datei für das cloop angelegt. …cloop.reg ist auch da un richtig. Danach zweten Client geimaged. Und da ist es wieder: Vertrauensstellung konnte nicht hergestellt werden.
den Lösungshaken muss ich wieder wegnehmen. Mittlerweile taucht das Problem bei allen Hardwareklassen auf, und zwar irgendwie zufällig. Bei einigen kann man sich anmelden, bei anderen nicht. Bei einigen geht es und dann wieder nicht.
Ich habe alle Lösungsvorschläge aus dem Forum versucht (umbennnen, neue Gruppen, macct gelöscht … und auch die global.reg habe ich zu richtigen Zeitpunkt eingespielt.
Alle Image neu aufsetzen schaffe ich zeitlich nicht mehr und ich brauche jetzt eine schnelle Lösung.
Ich habe jetzt Image ohne Domainbeitritt erzeugt. Eigentlich soll ein Skipt nach dem imagen den Domainbeitritt übernehmen. Ich habe parallel zu dem linuxmuster-task aus der install.bat einen Task angelegt, der ein Powershellscript aufruft, das den Domainbeitritt übernimmt.
Das Skript selbst läuft. Der Task wird aber nicht ausgeführt (es wird 0x1 als Fehler angezeigt)
Hier das Powershell-Skript (aktuell noch mit Klartextpasswort, da arbeite ich noch drann)
Die xml-Datei und alle anderen sind im Anhang DomainJoin.zip (1,8 KB)
Wenn jemand eine Lösung hat wäre ich sehr glücklich. Aktuelle hat der lokale Benutzer noch einen Shortcut auf dem Desktop liegen den ich anklicken muss. Das ist nur eine vorübergehende Lösung
jetzt habe ich es: man benötigt als Parameter für den Task noch -ExecutionPolicy
Bypass
Der Rechner wird jetzt ohne Domainbeitritt geklont, dann per Linbo verteilt. Beim ersten Hochfahren führt der Task join-domain das Skript C:\linuxmuster-win\domainjoin.ps1 aus. Das macht einen „ordentlichen“ Domainbeitritt. Der Rechner startet daraufhin selbst einmal neu.
Für uns ist das kein Problem. Da wir die grub-Dateien so verändern, dass man sofort Windows (oder Ubuntu ) durchbootet (ohne Linbo). Linbo nutzen wir „nur“ zum Verteilen neuer Images, nicht zum syncen vor jedem Start.
Wenn die Sache interessiert, die vier benötigten Dateien sind im Anhang.
Einzurichten geht so:
Die vier Dateien nach C:\linuxmuster-win\ kopieren
install.bat ausführen (richtet den Task ein)
einmalig Powershell als Adminitrator ausführen und Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
ausführen.
Windows runterfahren
Linbo starten
Image erstellen und verteilen mit reboot.
Jetzt startet Windows und tritt der Domain bei, danach automatische Neustart
Was noch unschön ist: Das Passwort steht im Klartext in der .ps1 Datei. Man kann es auch verschlüsseln, werde ich bei Zeiten probieren.
Wenn es interessiert, kann ich auch ein Artikel ins Wiki schreiben.
ich bin gerade dabei das Skript zu erweitern. Gibt es eine einfache Möglichkeit von Windows aus festzustellen, in welcher Gruppe (Linbo) sich ein Client befindet. Es sollen nicht alle Clients in die Domain.
Man könnte mit dem Registiy-Patch einen Eintrag in die Registry schreiben und den auslesen, aber vielleicht geht es auch einfacher?
Zwei Ideen dazu (wobei ich nicht versprechen kann, dass es nicht noch einfacher geht?):
Cache mounten → da steht’s ja in der start.conf. Kann Win10 nicht mittlerweile Linux-Partitionen sehen?
plink (aus den putty-Tools) verwenden? Damit könnte man einen ssh-Befehl auf dem Server absetzen und das über die Bordmittel abfragen.
Wie gesagt: Ist vielleicht beides mit Kanonen auf Spatzen geschossen?!?
man kann mit dem Activ-Directory Modul aus der Powershell Informationen zu Computern erfragen . Allerdings ist das ziemlich auffwendig (Modul installieren, Rechnern Anfragen erlauben, …)
In den Regestry-Patches stehen doch die Variable für den Hostnamen ({$HostName$}). Gibt es eine Variable für die Hardwareklasse/Gruppe/Raum?
Denkbar wäre auch eine datei mit dem Gruppennamen durch ein Postsync-Skript auf dem Client zu positionieren. Es gibt da die Variable $(hostgroup) Habe gerade nicht richtig Zeit dafür, werde es aber schnellstmöglich probieren.
das passiert normalerweise genau dann, wenn die Systemzeit der Clients nicht stimmt.
Windows bei zu bringen die Systemzeit korrekt zu führen und mit einem ntp ab zu gleichen ist leider eine Wissenschaft für sich.
Wenn man es schafft, dann klappt das mit der Domäne auch zuverlässig.
Das war in der samba3 Domäne noch kein Problem, bei samba4 ist die Zeit wichtig.
Vor allem wenn man DualBoot hat, muß man Windows so einstellen, dass es im BIOS (RTC) UTC erwartet, weil alle UTC dort reinschreiben … außer Windows, das localtime nimmt (warum auch immer …).