Netphone Client im AD

[Guido]

Hallo..

wir haben aktuell von der Telekom eine Swyx installiert bekommen.

Server OS W2K8 Std R2

Wir haben nun an einigen Win7 Prof 64bit Clients das Problem, dass der Netphone Client

sich einfach nicht mit dem Swyx Server verbindet. Nach Eingabe des Users

erfolgt ein kurzer Verbindungsversuch. Dieser scheitert ohne Angabe von Gründen.

Das seltsame ist, melde ich mich lokal an der Maschine an, die die Verbindungsprobleme

hat, klappt die Verbindung zur Swyx. Nur nicht, wenn man ein Domänen Login gemacht

hat. Hierbei ist es auch egal, ob man den Benutzer zum lokalen Admin macht oder nicht.

An anderen Maschinen, bei denen man sich an der Domäne anmeldet, gibt es keine

Verbindungsprobleme. Hier sind die User keine lokalen Admins. Am AD Konto sollte es

also nicht liegen. Die Installation der Netphone Software erfolgte überall als Dom-Admin.

Virenscanner und Firewall kann auch ausgeschlossen werden, da es ja bei 90% der

Clients ganz normal funktioniert

Hat jemand eine Idee, wonach ich noch schauen könnte ? Bin für alle Tipps dankbar,

auch wenn sie noch so lächerlich klingen mögen.

[srom]

Wie sieht es mit der Uhrzeit zwischen Client und Server aus ?

 

[Guido]

Uhrzeit im Netz passt. Clients und Server sind synchron.

[jodost]

ist der Swyx-User mit dem Domänenaccount verknüpft (für SSO) oder loggst Du Dich auch beim Domänenkonto mit Swyx-Username/Swyx-Passwort ein?

 

Wenn ersteres, dann deaktivere das probehalber mal und versuch mal Login mit sep. Zugangsdaten (so, wie Du es bei Deiner lokalen Anmeldung ja auch gemacht hast). Vielleicht kannst Du so die Ursache etwas weiter einkreisen..

 

Und wo wir beim weiter einkreisen sind: Ist das ein User-spezifisches Problem oder ein Geräte-spezifisches Problem? Sprich: Betroffenes Gerät, AD-Konto samt Swyx-Konto eines völlig anderen Mitarbeiters (der an an deren Geräten funktioniert), klappt es damit?

[Guido]

- Ja, der Swyx-User ist mit dem Domänenaccount verknüpft.

 

- wenn ich Domänenanmeldung mache, klappt Netphoneanmeldung weder mit SSO noch mit manueller Eingabe des Benutzers

- wenn ich lokale Anmeldung mache, klappt manuelle Anmeldung. SSO nicht. Ist ja klar.

- mit diesem Benutzer kann ich mich aber problemlos an anderen Stationen erfolgreich an Netphone anmelden

- andere Benutzerdaten an der gleichen Maschine klappen auch nicht, wenn ich Domänenanmeldung mache

 

- von daher tippe ich mal eher auf ein Maschinenproblem, das aber nur auftaucht, wenn ich AD Login mache

- egal, mit welchem Benutzer. Wobei die Benutzer an anderen Maschinen einwandfrei funktionieren. Egal, ob AD oder lokale Anmeldung

- GPOs sind auf allen Maschinen gleich und ziehen erfolgreich

- die Feuerwand ists auch nicht, weils ja auf fast allen anderen Maschinen ohne Veränderung der Einstellungen ohne Probleme klappt

- hab trotzdem mit ausgeschalteter Feuerwand versucht. Ohne Erfolg

 

[jodost]

sofern Dir die Logfiles nicht weiterhelfen, würde ich spontan mal gucken, ob Client und Server ÜBERHAUPT miteinander kommunizieren,

- vielleicht scheitert es einfach am Swyx-Servernamen (trag mal die IP ein)

- ggf. mal Wireshark anwerfen und gucken, ob die beiden überhaupt miteinander reden

[Guido]

- egal ob DNS Name oder IP vom Swyx Server, Anmeldung fällt auf den Bauch

- Client und Server reden miteinander, das kann man am Server sehen

- Habe den "fehlerhaften" Benutzer manuell abgemeldet. Damit bekam er am Server das rote X, ist also abgemeldet

- ich starte den Client, Anmeldung erfolgt offenbar nicht, denn Skin und Daten werden nicht am Client geladen

- aber am Server sieht man, dass der Benutzer aktiv ist. Das rote X ist weg

- Anmeldung mit anderem Benutzer geht auch nicht, wenn die Maschine an AD angemeldet wurde

- bei lokaler Anmeldung an der Maschine keine Probleme mit Netphone Anmeldung

[jodost]

Erster Gedanke: Firewall- oder NAT-Problem. Die REGISTER-Nachrichten klappt noch, aber der Datenverkehr SwyxServer->Client (z.B. Skin übertragen) hakt. Darum glaubt der Server, dass der User jetzt angemeldet ist (weil das REGISTER durchging), aber dem Client fehlt noch der Rest, darum wartet der bis zum Timeout.

 

NAT schließe ich mal aus, Dein Routing wird sich ja kaum ändern, je nach dem, ob AD oder nicht. Bleibt also: Firewall. Auch wenn Du das ausgeschlossen hast, ich würde da nochmal ansetzen. Müsste man mit Wireshark eigentlich auch sehen können, wenn man mal einen Wireshark-Mitschnitt auf-dem-Client und auf-dem-Server miteinander vergleicht.

 

 

Ändert es was, ob Du SwyxIt im CTI-Modus oder nicht startest? Wenn ja, und es tritt nur im Softphone-Modus auf: Kann es sein, dass es irgend einen USB-Konflikt gibt (weshalb das SwyxIt, wenn im AD angemeldet, nicht auf den Hörer zugreifen kann)? Das wäre das einzige, was mir noch einfällt außerhalb der Firewall.

 

Und letzter Versuch: Hilft es, probehalber den RemoteConnection-Service (auf die gleiche IP, aber Einstellung "immer") zu aktivieren. Wenn das geht (und die nicht-RCS-Variante weiterhin nicht), bleibe ich bei Firewall :-)

 

 

 

 

[Guido]

Habe Firewall Dienst mal komplett beendet, aber das hatte leider auch keinen Einfluss auf den Start des Clients.

Nach wie vor sieht der Client die Anlage nicht, wenn ich ein Domänen-Login mache.

Und nur an ein paar wenigen Win7 Clients. Bei lokaler Anmeldung an Win7 sieht der Client die Anlage.

Es greifen an den betroffenen Maschinen absolut keine anderen GPOs als bei den Clients, wo es funktioniert.

Und es ist auch egal, ob Domänenanmeldung als Domänen-Benutzer oder Domänen-Admin.

Es ist wirklich zum Mäuse melken. 

Bis zum Softphone-Modus komme ich ja gar nicht erst.

Server meldet zwar, dass der Benutzer verbunden wäre, aber der Netphone Client spricht eine andere Sprache.

Alles grau hinterlegt, keine Funktion im Client freigeschaltet.

Es hat auch nichts gebracht, die Software den Server automatisch im Netz erkennen zu lassen.

 

[Virikas]

Die Ursache wird im Client Log zu finden sein (siehe auch Handbuch zur Aktivierung).
Jeder(!) Swyx Distri sollte in der Lage sein ein solches Log zu lesen und zu verstehen. Der Spielball liegt hier also -nach Übermittlung der Logs- klar beim Support der Telekom.

[Guido]

Schön, dass wir hier einer Meinung sind ... Ich habe tagelang Telekom Leute im Haus gehabt, aber keiner wusste sich (oder uns) zu helfen.

Das sei ganz klar unser Problem. Die taten grad so, als seien wir die erste Firma, bei der ÜBERHAUPT mal irgendein Fehler ausgetreten sei.

Ich habe schon feststellen können, dass scheinbar ein Portlistener auf dem Client aktiv sein sollte, der über Port 50.000 - 55.000 auf den

Port 9094 des Swyxservers lauscht. Das ist auch der Fall, wenn ich eine lokale Anmeldung mache. Mache ich AD Anmeldung läuft dieser

Listener nicht. Weiss jemand, ob das ein Dienst ist, oder ein SVC Hostprozess?? Hab Dienste mit einer Maschine verglichen, die keine Probleme

macht. Dienste waren aber alle gleich.

[Virikas]

Das Problem mit dem Clientsupport ist, dass in der Tat die Clients prinzipiell Hoheitsbereich des Endkunden sind.

Allerdings sollte das nicht dazu führen, dass man eine solche Verweigerungshaltung einnimmt.

bevor du dich nun mit den Prozessen slebst auseinander setzt: Aktiviere das erweiterte Clienttracing (Beschreibung entweder im Handbuch oder einfach die passen Trace_On.reg/Trace_Onx64.reg im Installationsverzeichnis ausführen und das Log unter %temp%\Swyx\SwyxIt!-<Datum>-<Uhrzeit>.log finden) und vergleiche mal stumpf zwischen einem "geht" und einem "geht nicht" Client.

Die Logs sind reeeeeelativ sprechend und man kann auch ohne größere Ahnung grobe Fehler recht fix erkennen.

[Guido]

Wir haben es gefunden. Wird sich verdammt seltsam lesen, ist aber wirklich so gewesen :

- das Problem war .NET Framework

- seltsamerweise hat .NET bei der lokalen Anmeldung keine Mucken gemacht

- aber bei AD Anmeldung lief wohl irgendwas ins leere

- .NET Framework deinstalliert und neu installiert

- anschließend lief der NetPhone Client auch bei AD Anmeldung absolut problemlos