Hallo ACMP-Team,
muss ich beim installieren in andere Subnetze bei der Installation etwas beachten?
Wenn ich den ACMP-Client auf einem PC im gleichen Subnetz wie den Server installiere klappt alles super.
Wenn ich jedoch den ACMP-Client auf einem PC bzw. Laptop installieren möchte der sich in einem anderen Subnetz befindet, wird der Client zwar erfolgreich installiert (Dienst installiert, Prozess im Taskmanager zu sehen), nur der Abgleich im Anschluss findet nicht statt. Möchte ich nun den Abgleich der Clients mit "Clients neu scannen" manuell anschieben, bekomme ich jedesmal eine Fehlermeldung unter "Queues". Die Fehlermeldung ist im Anhang zu sehen.
Meine Windows XP Sp3 und Win7 Sp1 Testsysteme sind mitlerweile komplett ohne Antivirus und Firewall unterwegs, da ich bei der Fehlermeldung erstmal an solche Programme gedacht hatte. Gebracht hat es leider nichts.
Der ACMP Server ist ein Win2K8R2 SP1, ohne Firewall.
Hat jemand eine Idee, wo es bei mir scheitert?
LG
Christian
ACMP-Client in andere Subnetze installieren.
Ich antworte mir schonmal selber . Der Port 2107 ist per telnet auf die Clients nicht erreichbar.
Da ping einwandfrei funktioniert und das Netzwerk ansonsten auch funktioniert, weiss ich nun an der nächsten Stelle nicht weiter.
Hat dazu jemdan ne Idee?
LG Christian
Da ping einwandfrei funktioniert und das Netzwerk ansonsten auch funktioniert, weiss ich nun an der nächsten Stelle nicht weiter.
Hat dazu jemdan ne Idee?
LG Christian
Hallo!
Die Push-Installation des CLients (Dateien vom ACMP Server auf den Client kopieren, Installation des Dienstes usw.) läuft über die "normalen" Port für die Windowsdateifreigabe/RDP
Nachdem der ClientDienst dann installiert ist, möchte der sich zum ACMP Server verbinden. Das läuft dann schon über die ACMP Ports (Client will mit dem Server auf Port 2106 sprechen, der Server will dem Client auf Port 2107 was schicken).
Kann es sein, dass bei Ihnen also was mit Routing nicht richtig klappt? Sind die ACMP Ports über den Router zwischen den beiden Netze freigegeben?
Die Push-Installation des CLients (Dateien vom ACMP Server auf den Client kopieren, Installation des Dienstes usw.) läuft über die "normalen" Port für die Windowsdateifreigabe/RDP
Nachdem der ClientDienst dann installiert ist, möchte der sich zum ACMP Server verbinden. Das läuft dann schon über die ACMP Ports (Client will mit dem Server auf Port 2106 sprechen, der Server will dem Client auf Port 2107 was schicken).
Kann es sein, dass bei Ihnen also was mit Routing nicht richtig klappt? Sind die ACMP Ports über den Router zwischen den beiden Netze freigegeben?
Mit freundlichen Grüßen,
H. Schriek
H. Schriek
Ich habe dies nochmal überprüft.
Der Client kann auf den Server über telnet auf den Port 2106 verbinden.
Der Server kann sich mit dem Client über Port 2107 nicht verbinden.
Routing müsste in Ordnung sein. Ping funktioniert und tracert zeigt den richtigen Weg an.
Gibt es außer der Firewall noch ein Tool auf einem 2K8R2 Server, dass Verbindungen in andere Subnetze unterbinden kann?
LG
Christian
Der Client kann auf den Server über telnet auf den Port 2106 verbinden.
Der Server kann sich mit dem Client über Port 2107 nicht verbinden.
Routing müsste in Ordnung sein. Ping funktioniert und tracert zeigt den richtigen Weg an.
Gibt es außer der Firewall noch ein Tool auf einem 2K8R2 Server, dass Verbindungen in andere Subnetze unterbinden kann?
LG
Christian
Hallo,
um das Problem weiter einzugrenzen bräuchten wir noch einige Infos.
Schauen Sie doch bitte einmal nach ob der Client auf dem Port 2107 etwas abhört.
(cmd -> netstat -a)
Es könnte evtl. sein das ein anderes Programm schon auf dem Port lauscht oder der Client nicht richtig installiert ist.
Ist es denn möglich per telnet "telnet %Client% 2107" im gleichen Subnetz auf den Client zuzugreifen? Kann der Server per telnet andere Clients im gleichen Subnetz erreichen? Funktioniert der Ping / Tracert in Beide Richtungen mit Namen und IP?
Ausser einer Firewall bzw. einem Routingproblem wäre mir so erstmal nichts bekannt was die Verbindung stören könnte.
um das Problem weiter einzugrenzen bräuchten wir noch einige Infos.
Schauen Sie doch bitte einmal nach ob der Client auf dem Port 2107 etwas abhört.
(cmd -> netstat -a)
Es könnte evtl. sein das ein anderes Programm schon auf dem Port lauscht oder der Client nicht richtig installiert ist.
Ist es denn möglich per telnet "telnet %Client% 2107" im gleichen Subnetz auf den Client zuzugreifen? Kann der Server per telnet andere Clients im gleichen Subnetz erreichen? Funktioniert der Ping / Tracert in Beide Richtungen mit Namen und IP?
Ausser einer Firewall bzw. einem Routingproblem wäre mir so erstmal nichts bekannt was die Verbindung stören könnte.
Mit freundlichen Grüßen,
Thomas Hahn
Aagon GmbH
Thomas Hahn
Aagon GmbH
Hallo,
tracert und ping funktionieren hin und zurück über IP und DNS-Namen.
Auf Port 2107 hört nichts. Telnet auf Port 2107 unter den Clients funktioniert noch nicht. Aber Telnet z.B. auf Port 135 funktioniert vom Server auf die Clients ohne Probleme.
Habe auch schon mehrere Konstalationen ausprobiert und den Client mehrmals neu installiert.
Es scheint mit dem Routing zusammenzuhängen, aber ich hab noch keine Idee warum.
LG
Christian
tracert und ping funktionieren hin und zurück über IP und DNS-Namen.
Auf Port 2107 hört nichts. Telnet auf Port 2107 unter den Clients funktioniert noch nicht. Aber Telnet z.B. auf Port 135 funktioniert vom Server auf die Clients ohne Probleme.
Habe auch schon mehrere Konstalationen ausprobiert und den Client mehrmals neu installiert.
Es scheint mit dem Routing zusammenzuhängen, aber ich hab noch keine Idee warum.
LG
Christian
Hallo,
ich würde an der Stelle auch nochmal einen anderen Ansatz verfolgen.
Wenn ich das richtig verstanden habe, wurde bisher nur der "Mini"-Client installiert. Das Verzeichnis müsste demnach ca. 27 MB groß sein!? Anschließend versucht der Client sich zu patchen, was ihm allerdings nicht gelingt.
Der Port 2107 des Clients ist erst geöffnet, wenn der Client sich patcht. Der Mini-Client selbst lauscht noch nicht auf diesen Port. Daher würde ich das Problem noch nicht allein auf das Routing begrenzen.
Folgende Infos sind an der Stelle daher noch interessant:
- Größe des Client-Verzeichnisses
- Existiert im Client-Verzeichnis eine "DistribFileRepos.xml"? Wenn ja, wie sieht der Inhalt dieser Datei aus?
- Verwenden Sie im ACMP Containers in Verbindung mit verteilten FileRepositorys?
Evtl. sind die Clients des anderen Subnetzes keinem Container zugewiesen und können sich nicht patchen, weil es auch kein Standard FileRepository gibt. Dies können Sie in der ACMP Console unter
"Plattform->Verteilte File Repositories-> Standard File Repositories" nachschauen. Ist dort der ACMP-Server eingetragen?
ich würde an der Stelle auch nochmal einen anderen Ansatz verfolgen.
Wenn ich das richtig verstanden habe, wurde bisher nur der "Mini"-Client installiert. Das Verzeichnis müsste demnach ca. 27 MB groß sein!? Anschließend versucht der Client sich zu patchen, was ihm allerdings nicht gelingt.
Der Port 2107 des Clients ist erst geöffnet, wenn der Client sich patcht. Der Mini-Client selbst lauscht noch nicht auf diesen Port. Daher würde ich das Problem noch nicht allein auf das Routing begrenzen.
Folgende Infos sind an der Stelle daher noch interessant:
- Größe des Client-Verzeichnisses
- Existiert im Client-Verzeichnis eine "DistribFileRepos.xml"? Wenn ja, wie sieht der Inhalt dieser Datei aus?
- Verwenden Sie im ACMP Containers in Verbindung mit verteilten FileRepositorys?
Evtl. sind die Clients des anderen Subnetzes keinem Container zugewiesen und können sich nicht patchen, weil es auch kein Standard FileRepository gibt. Dies können Sie in der ACMP Console unter
"Plattform->Verteilte File Repositories-> Standard File Repositories" nachschauen. Ist dort der ACMP-Server eingetragen?
Was war denn bitte das Problem, sieht bei uns ähnlich aus???chrme hat geschrieben:Hallo,
der ganze Fall ist erledigt.
Vielen vielen Dank für die Unterstützung.
LG Christian
Den Port 2107 an der Firewall des Clients hab ich manuell hinzugefügt, Ping und Tracert (IP und Name) gehen in beide Richtungen, Telnet auf 2107 geht gar nicht....auch nicht im gleichen Subnet.