Ich habe nach dem erneuten Windows-Domänenbeitritt ein Win-10-Image geschrieben und mit regpatch synchronisiert gestartet. Anmeldung geht, alle Laufwerke sind da. So weit so gut.
Jetzt synchronisiere ich dieses Image auf den zweiten Rechner und schaue mal, ob das da genau so ist. Dann wäre zumindest die Windows-Welt in Ordnung.
Linux werde ich im Anschluss noch einmal genau so Handhaben (und mal genau nach Dateiresten schauen).
Für heute genügt das aber - Danke fürs Mitdenken!
Liebe Grüße
Thomas
PS: wir hatten noch ein Problem bei einem BIOS/SATA-Rechner beim Linbo-Update. Der bootete zunächst (noch altes Linbo), nach dem Aktualisieren von Linbo kam dann aber eine Schleife („<irgendwas/linbo?> is up to date“ und ein paar Zeilen mehr). Sollte sich das auf anderen Clients wiederholen, mache ich mal einen Screenshot.
Wir haben aber insgesamt immer Mal Probleme, wenn wir unbedacht mit Clients die Linbo-Version wechseln. Z.B. bei einem 6.2er-Image muss man aufpassen, das nicht einfach am 7er-Netz zu starten. Dann war es das nämlich: ich kann mich weder mit dem alten noch mit dem neuen Passwort anmelden, damit auch nicht partitionieren. linbo-remote hilft dann (oder wenn ein OS noch bootet das Löschen der Cache-Partition).
Habe ich schon einmal irgendwo gepostet - es wäre gut, wenn beim PXE-Boot von Linbo auch das dazu passende Passwort in jedem Fall funktionieren würde, aber da scheint irgendwas schief zu gehen.
PS: wir hatten noch ein Problem bei einem BIOS/SATA-Rechner beim
Linbo-Update. Der bootete zunächst (noch altes Linbo), nach dem
Aktualisieren von Linbo kam dann aber eine Schleife („<irgendwas/linbo?>
is up to date“ und ein paar Zeilen mehr). Sollte sich das auf anderen
Clients wiederholen, mache ich mal einen Screenshot.
das aktualisieren von linbo während des ersten boots dauert immer mal
ein wenig: dann geht der boot weiter: wenn da aber nach 2 Minuten noch
nichts passiert ist, dann gibt es ein Problem.
Für solche Fälle gibt es den Startparameter
warmstart=no
der dafür sorgt, dass linbo nicht nach dem update versucht das neue
linbo direkt zu laden, sondern dass das linbo dann den Rechner neu startet.
Allerdings wird dann auch beim booten von linux aus linbo heraus wieder
ein reboot gemacht.
Unter Windows war das Problem wohl der Regpatch. Ich habe die Einträge einzeln nachgeschaut und regedit meldete, dass einige Einträge ungültig seien. Dazu habe ich auch etwas hier in einem anderen Beitrag gefunden.
Daher stimmte unter Windows der Hostname nicht - nachdem ich die Dateien nachbearbeitet habe, funktioniert die Anmeldung unter Windows jetzt.
Dazu zwei Anmerkungen:
ist es egal, ob als SAMBADOMAIN in den REG-Dateien der kurze oder volle Name ersetzt wird? In der Anleitung finde ich beides (hier z.B. nur das VOR linuxmuster.lan, bei uns wäre das corvi)
in meiner Beispiel-Reg-Datei hatte ich mehrmals Einträge wie "Hostname"="{$HostName$}"
Das führte bei mir zu zwei Einträgen in der Registry: HostName und Hostname. Ist das noch ein Typo in den Vorlagen oder was davon nimmt Windows?
Bei Linux bin ich noch nicht weiter gekommen - später
in meiner Beispiel-Reg-Datei hatte ich mehrmals Einträge wie
„Hostname“=„{$HostName$}“|
Das führte bei mir zu zwei Einträgen in der Registry: |HostName| und
Hostname>. Ist das noch ein Typo in den Vorlagen oder was davon
nimmt Windows?
mein regpatch unter Windows:
Windows Registry Editor Version 5.00
; linuxmuster.net 7
; patches hostname, to be applied after every image sync
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
noch ein Hinweis: Image und regpatch liegen ja unter
/srv/linbo/images/IMAGENAME/
und heißen
IMAGENAME.qcow2
und
IMAGENAME.reg
also NICHT! IMAGENAME.qcow2.reg
… ich gleich früher hießen die regpatches IMAGENAME.cloop.reg … schau
das mal genau nach.
Bei Linux bin ich noch nicht weiter gekommen - später
auch hier: der postsync heißt inzwischen anders, ähnlich wie der
regpatch, nicht mehr IMAGENAME.cloopp.postsync sondern
IMAGENAME.postsync.
Der Grund ist das differentielle Image: er wird ja nach dem sync beider
Images ausgeführt und nicht nur nach dm qcow2: daher die Namensverschiebung.
Bitte kontrollier bei linux noch die /etc/hostname und die /etc/hosts ob
die den korrekten Inhalt haben.
Du hast in Deinem Regpatch gar keine Infos zur Domäne - offenbar funktioniert es dennoch (oder es ist tatsächlich nur der „präfix“ zu linuxmuster.lan nötig und Du hast keinen?
Die Dateinamen habe ich beachtet - der Patch wurde ja auch angewandt, aber offenbar ging dabei etwas schief - so eine Warnmeldung in regedit hatte ich jedenfalls noch nicht.
Was steht denn bei Dir in hostname/hosts? Und was gibt „domainname“ bei Dir aus? Die Hosts-Datei habe ich nicht angerührt (und es lief ja unter der 7.1). Aber da vergleiche ich auch gern noch einmal.
@dorian Zu allem ja. Die Netzwerkverbindung hatte ich auch anfangs im Verdacht, weil der Domänenbeitritt erst ging, nachdem ich dhclient manuell aufgerufen habe. Und ich beobachte ja immer mal seltsame Timing-Probleme mit Netzwerkverbindungen (z.B. dass ein Rechner offline ist, weil Linbo nicht lange genug wartet - hab ich schon mal gepostet - hat nichts mit dhcpretry zu tun).
Aber die Rechner bekommen IP, haben inzwischen auch den richtigen Hostnamen - funktionieren tut es dennoch (bisher) nicht. Aber morgen probiere ich es noch einmal vor Ort.
Aber bist du sicher, dass das hier nicht der Fall ist? Denn damit die Domänenanmeldung beim Dualboot und bei neuen Rechnern richtig funktioniert, muss Linbo beim Start online sein.
Hallo Dorian
Wenn da nicht irgendetwas „unsichtbares“ schief geht… Linbo hat eine IP. Ich komme vom Server auf Linbo. Insofern gehe ich davon aus, dass Linbo online ist.
Viele Grüße
Thomas
Hallo Holger,
wir haben bei uns das gleiche Problem, dass immer mal wieder die Domänenanmeldung der Win10 Clients wegen der Vertrauensstellung nicht klappt. Ich habe den Fehler auch schon bei den Registry Einträgen vermutet, da wir auch doppelte Hostname Einträge hatten/haben. (Also einmal Hostname mit kleinem n und großem N). Was mich dann verwundert hatte war, dass die Registration von Windows eigentlich nicht Case sensitive ist aber trotzdem gewisse Schreibweisen quasi vorgibt. Ein Test um das zu überprüfen indem man manuell über den Registrationseditor einen Wert einträgt mit „Hostname“ und einen mit „HostName“ schlägt fehl mit der Meldung, dass der Eintrag schon existiert. Über eine *.reg Datei scheint es aber doch zu gehen, was natürlich fatal ist.
Auf Knowlegdebase Seiten von Microsoft habe ich (hoffe ich ) heraus gefunden, dass …
ComputerName tatsächlich mit großem N geschrieben wird
Hostname und NV Hostname aber mit kleinem n
Die Variable $HostName$ wiederum mit großem N, wobei das ja vermutlich eher von der LMN vorgegeben ist. Liege ich mit diesen Annahmen richtig?
Zum Registry Patch habe ich aber noch eine Frage: unter /srv/linbo/examples steht in der win10.image.reg der Registry Schlüssel "HKEY_LOCAL_MACHINE\System\ControlSet001\ … " und in Deinem Registry Patch nimmst Du den Registry Schlüssel "HKEY_LOCAL_MACHINE\System\CurrentControlSet\ … "
Ich persönlich würde „ControlSet001“ nehmen, weil ich denke, dass beim ersten Starten von Windows 10 dann diese Einträge in den „CurrentControlSet“ kopiert werden. Das ist aber nur eine Vermutung. Kennst Du den Mechanismus dahinter? Weil ich mir diesbezüglich unsicher bin sieht mein Registry Patch folgendermaßen aus:
Windows Registry Editor Version 5.00
; setzt den Computernamen richtig
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\ControlSet001\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
; setzt den Computernamen richtig
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\ControlSet001\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
; setzt den Computernamen richtig
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\ControlSet001\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
; setzt den Domainnamen richtig
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters]
"Domain"="ELEKTRONIK"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\]
"DefaultLogonDomain"="ELEKTRONIK"
Ich bin mir aber nicht sicher, ob ich mir dadurch andere Probleme erzeuge.
der regpatch, den du in dienem Beitrag hast, ist veraltet: wir haben früher (vor der lmn7) die Domin bei jedem Imagen gepatched: das ist inzwischen anders.
Du solltest den aktuellen regpatch aus /srv/linbo/examplex/ verwenden: also den win10.image.reg
Dort steht alles richtig drin (der ist auch ein wenig anders als meiner, den ich in einem Beitrag weiter oben gepostet hatte).
$HostName$ ist natürlich eien linbo Variable und sollte nie in die registry rein kommen.
Hallo Holger,
danke für die Info. Habe jetzt den Regpatch für alle unsere Images eingetragen. Jetzt muss ich nur noch die fehlerhaften Registry Einträge in den Image PCs korrigieren und das daraus erstellte Image wieder verteilen. Sonst zieht sich das Problem mit der Vertrauensstellung weiter durch… oder ich baue gleich ganz neue Images
ich habe mich jetzt mal wieder dran gesetzt. Das erste Problem, das ich identifizieren konnte, war/ist die Erstellung der .macct-Datei.
Vermutlich, da es bereits eine (veraltete) gab, wurde diese nie neu erstellt. das würde zumindest die Anmeldeprobleme erklären.
Unter Windows konnte ich das Problem inzwischen lösen - nach dem Löschen aller Dateien auf dem Server und dem Client wurde sie neu erstellt.
Unter Ubuntu hat das nicht funktionert - selbst nach Umbenennen des Image-Namens wird hier keine macct-Datei erstellt. Soll das so sein?
Wenn es sie geben müsste - wo kann ich da weiter suchen? Wann wird die Datei von wem erstellt?
Der Domänenbeitritt gelingt übrigens angeblich (die Meldungen habe ich notfalls parat). Aber ohne macct-Datei kann das Verteilen ja vermutlich gar nicht gelingen.
So… jetzt bin ich doch ein paar Schritte weiter - und es ist schon seltsam.
Ich habe zwei identische virtuelle Maschinen virt-alephsata1 und virt-alephsata2. 1 hieß vorher anders, wurde aber in der devices umbenannt, hat in der Folge auch den richtigen Hostnamen…
Auf 1 wird sowohl unter Windows wie unter Linux KEINE macct-Datei erzeugt. Auf 2 schon.
Aber seis drum - nun habe ich für beide Images eine hoffentlich „passende“ macct-Datei. Tatsächlich gelingt es mir nun unter Windows und Linux, mich auf unterschiedlichen Rechnern, NICHT aber auf virt-alephsata1 in der Domäne anzumelden.
Nächstes Problem: Unter Windows sind die Netzwerk-Laufwerke korrekt gemountet, unter Linux wird derzeit nur sysvol gemountet, keine anderen Laufwerke. Ich teste das heute noch bei anderen (physischen) Clients, aber vielleicht hat hier jemand eine Idee.
GPOs neu erstellen habe ich schon versucht
Zeit stimmt
linuxmuster-linuxclient7 status meldet keinen Fehler
in den Log-Dateien gibt es die irgendwo im Ask schon einmal erwähnten Fehlermeldung (z.B. ist kein AD Nutzer) - die Anmeldung funktioniert aber und unter /srv/samba/... ist sysvol auch gemountet
hier meine 2ct zum Thema, da ich auch gerad einen Linuxclient (Linux Mint) erstelle:
Ich hatte drei Images über das LINBO GUI erstellt. Die sind als Backup auch noch nachvollziehbar. Alle hatten keine macct-Datei. Entsprechend hatte ich Probleme, dass neu gesyncte/gestarte Clients nicht in der Domäne waren (s. auch dieser Thread).
Seit ich vorgestern erstmals ein Image über linbo-remote erstellt und hochgeladen habe, gibt es eine macct-Datei und der Domain Join von neu gesyncten/gestarteten Clients funktioniert.
Nein, die macct-Datei wird immer wenn ein Image hochgeladen wird auf dem Server von /usr/share/linuxmuster/linbo/rsync-post-upload.sh erstellt (s. rsync-post-upload.log).
@thomas - die Log-Datei hatte ich gefunden, es gab nur eine zu dem „funktionierenden“ Client, zu dem problematischen keine, darum war ich mir nicht sicher. Jetzt verstehe ich den Ablauf - danke! Spannend, warum sie dann gelegentlich nicht angelegt wird. Aber so lange es jetzt läuft
Ansonsten war ich heute laaange in der Schule und kann bisher nur Erfreuliches berichten:
alle Geräte mit der neuen macct-Datei sind in der Domäne, die Anmeldung funktioniert unter beiden Betriebssystemen bisher auf allen Clients. Yey!!
die Shares, die unter Ubuntu in der VM nicht angezeigt werden, sind auf realen Clients vorhanden. Ich kann mir vorstellen, dass es da in der Proxmox-VM Probleme mit Samba-Shares gibt (unter unprivilegiert LXC-Containern geht das ohne weiteres glaube gar nicht). Vielleicht gut für den Hinterkopf, falls das bei anderen in VMs passiert. Hat das sonst schon jemand beobachtet und vielleicht eine Idee?
auch die Bootschleife ist wohl durch eins der Updates behoben - ich komme jetzt überall zu Linbo (und das PW funktioniert auch bei Geräten, die vorher ein altes Linbo hatten)
durch die update-linbofs-Skripte und unsere eingefügte Pause (siehe hier) ist Linbo bei einigen USB2LAN-Adpatern nicht mehr offline
Insofern derzeit Ende gut, alles gut. Danke allen, die mitgedacht haben.
) heraus gefunden, dass …