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.
Viele Grüße
Steffen
Hallo Thomas,
der Domänenname wird nicht in der image.reg gepatched, sondern nur einmal mit der global.reg
LG
Holger
Hallo Steffen,
und herzlich willkommen bei uns 
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.
LG
Holger
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
Viele Grüße
Steffen
Hallo Holger,
dann ist die Doku an der Stelle aber unklar, oder?
Sinn macht das ja (wer ändert schon die Domäne) - aber hätte ja sein können, dass das überschrieben wird…
Trotzdem bleibt die Frage: was muss da rein. Kurzname (wie in der Doku genannt) oder FQDN?
Viele Grüße
Thomas
Hallo Thomas,
dann ist die Doku an der Stelle
https://docs.linuxmuster.net/de/latest/clients/client_templates/os_installation/windows10clients/index.html#install-windows10-clients-label aber unklar, oder?
… das stimmt: da muss rein, dass der Domainname angepaßt werden muss:
also SAMBADOMAIN ersetzt werden muss (an mehreren Stellen).
Trotzdem bleibt die Frage: was muss da rein. Kurzname (wie in der Doku
genannt) oder FQDN?
das was in der /etc/samba/smb.conf unter
realm
steht: also volle Länge (hab ich zumindest genommen).
Sinngemäß steht da bei mir
SCHULKUERZEL.LAN
LG
Holger
Hallo zusammen,
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.
Viele Grüße
Thomas
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 statusmeldet 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
Viele Grüße
Thomas
Hallo zusammen,
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.
Schönen Tag!
Jens
P.S.: Linbo 4.1.34-0.
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).
VG, Thomas
Hallo zusammen,
@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.
Thomas
1 „Gefällt mir“