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
