seit ein paar Tagen haben wir auf einigen Rechnern (andere im selben Raum funktionieren) das Problem mit der fehlenden Vertrauensstellung („Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.“)
Start über „rot“ bringt keine Lösung.
Habt Ihr eine Idee, woran das liegen / wonach ich suchen könnte?
Uhrzeit stimmt.
Image hat sich nicht geändert.
Was in den letzten Tagen gemacht wurde:
Serverupdates (7.2, u.a. linuxmuster-base, webui)
Firmware für eine NIC (andere HW-Klasse) in /etc/linuxmuster/linbo/firmware eingetragen, anschließend ein update-linbofs
Kann es damit zusammen hängen?
Was mir noch aufgefallen ist: unter /srv/linbo/images/imagename hat die Datei imagename.reg einen aktuellen Zeitstempel, mutmaßlich den Zeitpunkt, wann zuletzt ein Rechner davon mit "neu+start bzw. „rot“ gestartet wurde. Ist das normal / bei Euch auch so? Wer toucht warum diese Datei?
bei mir hat die reg Datei auf dem Server auch ein neuere Datum als ich erwartet hätte. Meine letzte Bearbeitung lag bestimmt länger zurück.
Das Datum ist aber Heute 9:02 was komisch ist, weil 62 Rechner die dieses Image verwenden um 7:20 Uhr gestartet wurden (eigentlich alle dazugehörigen). Kann aber sein, dass ein Rechner um 9 Uhr rebootet wurde … dann paßt das wieder.
Wegen der Vertrauensstellung: boote mal einen und warte 2 Minuten, bevor du dich einloggst: geht es dann? Windows ist mit dem Booten nicht fertig, wenn der Loginbildschirm da ist!
Überprüf Rechnernamen und IP im Client.
Im Notfall: zeile in der devices.csv auskommentieren, import, auskommentierung wieder wegnehmen, import, sync.
2 min warten und aus- und wiedereinkommentieren in der devices mit jeweiligem import bringen auch in Kombination nichts. Hab die Kiste anschließend sogar komplett platt gemacht.
OK, ich bin einen Schritt weiter:
PCs, die funktionieren, haben ihren korrekten Hostnamen gepatcht bekommen. Die mit fehlender Vertrauensstellung nicht. Das erklärt die fehlende Vertrauensstellung, aber nicht, wie es (plötzlich) dazu kam.
Und was dagegen zu machen ist!?
… na also: wußte doch, dass da der Hase im Pfeffer liegt.
Da sind nur 5 von einer HWK betroffen?
Was sagen den die linbologs der betroffenen? Wurde patchen versucht?
Liegt die reg Datei im Cache?
Was meinst du den mit „nicht korrekter Namen“? Die haben den Hostnamen, den der VorlagenPC hatte bei der Imageerstelung?
Besonderheiten im Hostnamen?
Hostnamen in devices.csv vollständig klein geschrieben?
reged version 0.1 140201, (c) Petter N Hagen
--- Import KEY <\ControlSet001\Services\Tcpip\Parameters>
END OF IMPORT, file </tmp/reg.3066.03>, operation SUCCEEDED!
1 keys
0 new keys added
2 values total
Hives that have changed:
# Name
0 </mnt/Windows/System32/config/SYSTEM> - OK
## Log session end: Do 29. Feb 10:29:07 CET 2024 ##
## Log session begin: Do 29. Feb 10:58:16 CET 2024 ##
### linbo_patch_registry
reged version 0.1 140201, (c) Petter N Hagen
--- Import KEY <\ControlSet001\Control\ComputerName\ActiveComputerName\>
END OF IMPORT, file </tmp/reg.3077.00>, operation SUCCEEDED!
1 keys
0 new keys added
1 values total
Hives that have changed:
# Name
0 </mnt/Windows/System32/config/SYSTEM> - OK
reged version 0.1 140201, (c) Petter N Hagen
--- Import KEY <\ControlSet001\Control\ComputerName\ComputerName\>
END OF IMPORT, file </tmp/reg.3077.01>, operation SUCCEEDED!
1 keys
0 new keys added
1 values total
Hives that have changed:
# Name
0 </mnt/Windows/System32/config/SYSTEM> - OK
reged version 0.1 140201, (c) Petter N Hagen
--- Import KEY <\ControlSet001\services\Tcpip\Parameters\> add_key: key services already exists!
trav_path: Error: Not a 'nk' node!
add_key: current ptr not 'nk'
trav_path: Error: Not a 'nk' node!
add_key: current ptr not 'nk'
END OF IMPORT, file </tmp/reg.3077.02>, operation FAILED!
1 keys
0 new keys added
0 values total
Hives that have changed:
# Name
None!
reged version 0.1 140201, (c) Petter N Hagen
--- Import KEY <\ControlSet001\Services\Tcpip\Parameters>
END OF IMPORT, file </tmp/reg.3077.03>, operation SUCCEEDED!
1 keys
0 new keys added
2 values total
Hives that have changed:
# Name
0 </mnt/Windows/System32/config/SYSTEM> - OK
## Log session end: Do 29. Feb 10:58:16 CET 2024 ##
Da gibt’s bei TCP/IP einen Fehler…
Du meinst, wenn ich mit linbo-ssh auf den Client gehe und dann in den Cache-Ordner schaue? Der ist leer!??? Genauso aber auf einem der PCs, die funktionieren. Kann aber nicht sein, dass der leer ist, muss ich den erst irgendwie mounten?
[Edit]: hab jetzt mal vom Server aus per linbo-remote ein initcache auf den PC gemacht und nach nem Neustart ist der Cache voll. Aber wie kann es sein, dass da vorher nichts drin war? Aus dem Cache heraus hab ich doch mein Windows gesynct!???
Und ja: da ist der imagename.reg
hm… mit .\ zeigt es auch den richtigen Hostname an?
Hast schon ein Blick in die Ereignisanzeige geworfen? Manchmal steht dort auch was nützliches drin.
Bei einem Kunden hatten wir mal, dass etwas falsches im DNS-Server eingetragen war.
root@server:~# samba-tool dns query server domain.lan @ ALL
Name=server, Records=2, Children=0
A: 10.0.0.1 (flags=f0, serial=110, ttl=900) A: 192.168.0.1 (flags=f0, serial=110, ttl=900)
hat sich auch so ausgewirkt. War seinerzeit etwas seltsam für mein Empfinden. Hier waren auch erst nur einige Clients betroffen - dort war es dann so, dass ein flushdns die Probleme ausgelöst hat. Wir haben dann den Eintrag raus geworfen, und es ging wieder alles wie erwartet.
Vielleicht ist es ja einen kurzen Blick wert…
Vielleicht hilft das:
Ich hatte das früher mal, als ich PCs von einem Raum in einen anderen „verschoben“ hatte.
Nachdem ich im Active Directory das Computerkonto (im falschen Raum) gelöscht habe, hat es funktioniert.
Es lag wohl am Regpatch.
Wir haben auf dem Server den Regpatch (win10.image.reg) aus den Examples kopiert (/srv/linbo/examples) und in den Ordner mit der Gruppe kopiert. Dort den Namen angepasst (imagename.reg)
Dann einfach an den Clients den Windows full-restore (roter Button) durchgeführt.
Die SuS und Lehrer können sich wieder anmelden.
Grüße Ralf
In der jüngsten Vergangenheit hatten wir von verschiedenen Schulen, die wir betreuen, die Fehlermeldung bzgl. der fehlenden Vertrauensstellung zwischen Computer und der Domäne bei der Anmeldung. Alle betroffenen Geräte hatten sich davor schon mehrmals erfolgreich an der Domäne angemeldet. Unsere Untersuchung ergab, daß sowohl die Computerkonten im AD existierten und die Geräte auch noch weiterhin Mitglied ihrer Domäne waren. Allen betroffenen Clients wurde in der Registry der gesetzte Computername mit dem Wert „(none)“ überschrieben:
D.h. allein nach der Korrektur der obigen 4 Werte im „ControlSet001“ durch den Eintrag des „alten“ Computernamens funktionierte nach dem Reboot auch die Domänenanmeldung wieder fehlerfrei.
Damit ergeben sich für uns die Fragen:
Wann wird der Registrypatch vom Image Sync auf dem Client ausgeführt ? => Bei jeden Start/Anmeldung des Clients // nur bei der Neuinstallation des Clients // nur beim Sync ?
Und warum wird die Variable „{$HostName$}“ dabei gelegentlich als „(none)“ aufgelöst und so in die Registry eingetragen ?
die Datei
/srv/linbo/images/IMAGENAME/IMAGENAME.reg
wird nach jedem sync durch linbo auf dem Client ausgeführt: egal ob „rot“ oder „gelb“. Das muss ja sein, damit das Windows dann seinen richtigen Namen hat.
Dunkel erinnere ich mich, dass wir früher mal das Problem mit „none“ als Computernamen hatten, wenn der Client ohne Verbindung zum Server gesynct wird.
Das ist aber schon richtig lange her.
Auf dem Client im Cache muss eine Datei liegen, in der der Computername steht: aus dieser wird er herausgelesen, wenn linbo bootet ohne Verbindung zum Server.
Das kann man erkennen, wenn man in der linbo GUI nach dem Booten einmal
F1
drückt: dann erscheinen die Einzelheiten zum Client von unten: unter anderem der Rechnernname.
Was steht da bei den betroffenen Clients?
Welche linbo Version habt ihr?
Kannst du die Datei im Cache finden? Was steht da drin?
herzlichen Dank für Deine Hinweise.
Wir arbeiten mit der Linbo Version 4.1.36-0 .
Die Datei, die den Hostnamen enthält ist die /etc/hostname.
Wir haben 2 Clients miteineander verglichen. Beim „Problem-PC“ stand iun der /etc/hostname „(none)“, beim funktionierenden PC war der korrekte Hostname eingetragen.
Auf welcher Partition „lebt“ die Linbo Umgebung eigentlich - im RAM-Cache ? oder auf einer temporären Plattenopartition ?
