forum.opsi.org

Da ich den Fehler immer noch nicht behoben konnte und auch nicht ganz weiß wie ich winexe kompilieren muss, würde es mir helfen, wenn ich wüsste welche Tools ich unter CentOS dafür bräuchte und was evt. noch zu beachten wären?

Gruß

Hallo,

die README von Winexe liefert dazu einiges.


Gruß

Niko

Hallo,

kam es nun hier zu einer wirklichen Lösung des Problems?
Ich habe ähnliche Probleme mit 2 Clients. Alle anderen funktionieren prima und ohne Fehler.

Die beiden jedoch starten den Client nicht. Was sie von allen anderen Unterscheidet ist die Office Version sonst ist alles gleich.
Nach einem "fresh" install von Windows passt alles. aber nach kurzer Zeit fängt das Phänomen an einzusetzen.

Habe schon alles mögliche versucht. Leider Ohne Erfolg.

Reinstall vom Client mit und ohne Admin, vom Server aus ... oder auch mit und ohne Mcafee und Defender... Leider immer das selbe Ergebnis.
der Prozess startet einfach nicht.

Was sind noch möglichkeiten zum Debuggen auf einem WIndows 7 Pro Rechner?

LG
mstiem

Ich konnte es nach weiteren Debuggen mit Eventlogs (Windows Ereinnisanzeige) den fehlenden Dienst herausfinden.
DNS-Client.

Dieser stand bei den betroffenen Systemen auf "deaktiviert" ein auf "Automatisch" brachte den gewünschten Erfolg! UND... ein Zufriedenes Gesicht meinerseits

mstiem hat geschrieben:Ich konnte es nach weiteren Debuggen mit Eventlogs (Windows Ereinnisanzeige) den fehlenden Dienst herausfinden.

I think this is documented somewhere.

Hallo zusammen,

ich würde das Thema gerne noch mal aufgreifen.

Der angesprochene "DNS-Client Dienst" muss bei unseren aussenstellen deaktiviert sein.

(Hintergrund ist der, das die Clients in den aussenstellen über VPN angebunden sind und DNS-Anfragen nur über "unseren" DNS-Server laufen!)

Ist es möglich den Opsi-Client auch ohne den DNS-Client Dienst zu starten?

Der DNS-Client hängt mit im Netzwerkstack von Windows, momentan habe ich keine Ahnung, ob man das auch ohne zum laufen bekommt, aber eins steht fest, das geht nicht auf Zuruf und nicht über das freie Forum, dass müsst Ihr Einkaufen.


Aber mal davon abgesehen:

cschmitz hat geschrieben:(Hintergrund ist der, das die Clients in den aussenstellen über VPN angebunden sind und DNS-Anfragen nur über "unseren" DNS-Server laufen!)

Verstehe ich nicht. Habt Ihr in eurem VPN kein DNS-Server? Machen alle Clients selber ein VPN Tunnel auf, oder macht Ihr Site-To-Site? Je nachdem sollte es doch auch möglich sein, dass man dafür zu sorgen, dass die richtigen DNS-Server gefragt werden. Wenn du mit deiner Anfrage auf den DNS-Cache anspielst, den kann man auch Flushen, ich würde mir überlegen, ob man das auch ohne stoppen des Dienstes hinbekommt, weil es aus meiner Sicht nicht sicher ist, dass dieser Dienst nicht mehr startet. Wenn er von einem anderen Dienst getriggert wird, sucht man sich wahrscheinlich einen Wolf bei einem Problem.

Hallo,

selten, dass ich zweimal hintereinander auf den selben antworte, aber da diese Meldung jetzt von mehreren kamen habe ich mir das noch mal angeschaut. Ich lag mit meiner Vermutung gar nicht so falsch:

ueluekmen hat geschrieben:weil es aus meiner Sicht nicht sicher ist, dass dieser Dienst nicht mehr startet. Wenn er von einem anderen Dienst getriggert wird

Der dnscache-Dienst wird tatsächlich getriggert und zwar vom opsi-client-agent , weil es als Abhängigkeit im Dienst gesetzt ist. Das heißt, wenn die Group-Policy diesen Dienst deaktiviert und opsi-client-agent gestartet werden soll, fährt er erst den dnscache hoch, und wird dann erst gestartet. In der Zwischenzeit ist aber der Loginblocker schon da und blockt.

Da dieser Dienst erst mal von Microsoft selbst nicht verteufelt wird, aber anders als der Name DNS-Client vermuten lässt nur der dnscache-Service ist und mit der Funktionalität von DNS-Abfragen nicht wirklich viel zu tun hat, haben wir ein internes Ticket aufgemacht, um diese Anfrage mal in einer Entwicklersitzung zu besprechen.

Wenn man das jetzt gelöst haben will, kann man folgende Datei bearbeiten:

/var/lib/opsi/depot/opsi-client-agent/files/opsi/setup.ins

Zeile 1270 im aktuellen Paket:

Registry_opsiclientd_Service_depend_dhcp_dns

auskommentieren. Danach sollten die Abhängigkeiten beim installieren des opsi-client-agent nicht mehr gesetzt sein und das was du haben wolltest sollte dann gehen.

Drei Dinge noch:
1.) Sollte diese Änderung nicht umgesetzt werden oder nicht in der nächsten Version vom opsi-client-agent mit released werden, ist bei einem Upgrade des opsi-client-agent Pakets auf dem Depot diese Änderung wieder weg.
2.) Bitte Testen, wir haben es noch nicht wirklich getestet, auch wenn diese Ecke nicht kritisch aussieht, aber man weiß erst das es läuft, wenn es getestet ist.
3.) Feedback hilft bei der Entscheidung ob das Upstream geht oder nicht.

Hallo,

das hört sich doch gut an

Habe es auch schon testen können - funktioniert! Danke dafür

Ein Problem oder vielleicht ein denkfehler meinerseits bleibt noch:

Um den Client für die Aussenstellen zu separieren, hab ich eine Kopie des aktuellen Opsi-Client-Agent "opsi-client-agent-ohne-dns" im Workbench erstellt, dann die ID in der Control-Datei angepasst "opsi-client-agent-ohne-dns", gepackt und implementiert. Nach dem der Client-Agent installiert ist sieht man im Configed aber nicht bei "opsi-client-agent-ohne-dns" das dieser installiert ist sondern bei "opsi-client-agent".

Muss hier noch etwas in der Control-Datei oder der Setup.ins angepasst werden?

Gruß
Christian Schmitz

Hi,

das Client-Agent-Paket zu clonen ist etwas schwieriger als normale Pakete zu klonen, da die Installationslogik etwas kompliziert ist.

Ich würde vorschlagen, dass Paket über so ein zu setzen, wenn es keine Probleme macht, ansonsten müsste man das Deploy und die Installationroutine mit anpassen, dass ist sehr umständlich.