... vielleicht noch als Ergänzung:
Mit Erscheinen der ganz neuen Handsets funktionierten die seinerzeit mit der von Starface mitgelieferten Firmware tatsächlich zunächst nicht. Ich hatte damals dann auch die von Gegaste selbst angebotene aktuellere Firmware verwendet und alles war im Lot. Nachteile zu der von Starface angebotenen Firmwareversion hatte ich zu keinen Zeitpunkt feststellen können (im Gegenteil ...).
Das S700H Pro setzt für volle Kompatibilität mit der N510 laut Gegaste Wiki eine Firmware 257 (oder höher) voraus. Ein Update wird zumindest im Zusammenspiel zwischen dem Handset S700H und der N510 die volle Funktionalität herstellen. Was ich leider nicht verbindlich sagen kann, wie sich die auf mind. o.g. Firmware angehobene N510 mit der Starface Version 6.4.x verhält. Vermutlich wird das funktionieren, ganz sicher bin ich aber nicht - kommt tatsächlich auf einen Versuch an.
Ich vermute, dass für die Starface 6.4.3.34 kein Updatevertrag vorliegt? Wenn doch, sollte man die eigentlich schon aus Sicherheitsgründen und künftige Versorgung mit Updates aktualisieren. Bei der SF 6.7.x ist die Funktionalität des N510 auch mit aktuellster Firmware 263 z.B. gegeben ... diese Version wäre aber auch schon EOL.
Ich kann diesen Effekt bestätigen - das trat nach dem Wechsel von 6.7.x auf 7.x bzw. 8.x auf und ist wie benannt nur zu beheben, wenn man das Browser-Cache leert. Vor Jahren gab es sowas schon mal - leider habe ich nicht mehr parat, was damals Abhilfe geschaffen hat - Fakt ist aber, dass man etwas dagegen tun konnte ... und eben auch, dass es nicht so ist, dass es sowas noch nie gab (vielleicht nur nicht mit allen Browsern).
Tatsächlich ist das halbwegs nervig, wenngleich aber zumindest temp. "reparierbar".
Nachvollziehen lässt sich das bei allen Installationen, die von 6.7.x auf 7.x oder neuer gewechselt sind - es tritt nicht absolut immer auf, aber meist bzw. mind. extrem häufig. Betroffen sind hier auch virtualisierte Installationen
Ohnehin kann ich unzählige SIP-Einwahlversuche auf der Starface beobachten. Genauso wie gescheiterte Login-Versuche.
Das beobachte ich allerdings seit Bestehen der Anlage. Ich nehme an, das ist das Übel eine festen IP-Adresse und gehe davon aus, dass dieses Verhalten normal ist.
Ja, das ist leider "normal" und wird nach einer Anzahl X von der Starface abgefangen und macht eigentlich keine Probleme. Wir halten es hier allerdings so, dass diese Fehllogins und andere Auffälligkeiten in einer vorgeschalteten Firewall Beachtung finden und solche "Versuche" zumindest nach dem ersten Auftreten weitestgehend schon im Vorfeld abgefangen und geblockt werden. In der Regel gibt es erkennbare Muster immer gleicher Ausgangs-IPs dafür - ich muss aber vorwarnen - pauschal / automatisch in eine Sperre übernehmen funktioniert eher nur leidlich, da man so auch schnell mal etwas aussperrt, was man nicht sperren wollte oder sollte. Hier ist tatsächlich Handarbeit und manuelle Einzelprüfung angesagt ... lohnt sich aber - es wird dann deutlich ruhiger auf der Starface ...
Punkt 1 und 2 habe ich schon letzte Woche dem Kunden auch vorgeschlagen, um das ganze einkreisen zu können. Jetzt muss das zunächst nur auch mal umgesetzt werden ... 
Den Hinweis zum Thema Outlook Terminplanung werde ich nochmal etwas genauer betrachten lassen.
Nachtrag:
Das Problem trat unvermittelt auf - funktionierte vorher monatelang völlig problemlos. Das Einzige, was wohl passiert ist: der Benutzerclient wurde dort in der Firma mehrfach neu installiert, als das Ursprungsproblem (aus diesem Beitrag) aufgetreten war.
Hallo Fabian,
nein - von Deinen diesbezüglichen Modulen ist dort nichts installiert - hier wird ein eigenes Modul dafür verwendet (was es auch schon etwas länger als Deine diesbezüglichen Module gibt und auch etwas anders ausgerichtet ist 
). Allerdings ist jenes Modul für den betroffenen Benutzer gar nicht aktiv und das Problem tritt auch dann auf, wenn das Modul bzw. dessen Instanzen komplett deaktiviert ist - in diese Richtung hatte ich auch schon gedacht.
Nachdem Fabians Hinweis goldrichtig war und die Openfire-Anpassung sofort eindeutig nachvollziehbare Besserung gebracht hat, gibt es bei jener Instalation jetzt noch eine andere Auffälligkeit, die vermutlich eine andere Ursache hat:
Einer der Benutzer loggt sich mit seinem Windows-Client auf der Starface ein und dann beginnt nach einiger Zeit die sichtbare Chatverfügbarkeit in relativ schnellem Wechsel an und aus zu gehen. So ist das dann auf der Starface z.B. in BLFs sichtbar. Der Client bleibt auch selbst stabil angemeldet und zeigt sonst auf Seiten der Starface vermeintlich kein sonstig sichtbares Fehlverhalten.
Der Nutzer selbst beschreibt es so, dass er den Client teils gar nicht nutzen kann - sich das bei Ihm als "unverbunden" darstellt (was es aber definitiv nicht ist) - im Client wird beim genutzten Softphone ein ! angezeigt - der Chat witzigerweise als verfügbar.
Client-Alzheimer? 
Auf Seiten der Starface kann man auch sehen, dass selbst Anrufe dorthin geleitet werden - also von Seiten der Anlage auch technisch von einem vorhandenen Client ausgegangen wird. Mit Blick auf den auswertbaren Chatstatus des Benutzers sieht es so aus, als gäbe es "mehrere Anmeldungen des gleichen Accounts" mit uneindeutigem - unterschiedlichem Ergebnis der Auswertung des Chatstatus.
Betroffen ist nur eben jener eine Nutzer (von über 350). Der Nutzer ist nicht neu - den gibt es so schon lange, funktioniert hat der bisher problemlos bis eben auch der sich zunächst nicht mehr anmelden konnte (siehe gelöstes Problem). Bei anderen Nutzern, die jenes erste Anmeldeproblem hatten, tritt das defitiv nicht auf.
Wo kann man ansetzen?
... den Client hat der benutzer wohl schon mehrfach neu auf seinem PC installiert (nach vorherig, vollständiger Entfernung).
In dem Fall handelt es sich aus rein organisatorischen Gründen (aktuell noch) um einen 6.7.x-Installation mit dem dafür passenden Client.
Hallo Fabian,
super - besten Dank ... damit passt es jetzt! Super und DANKE!
Hallo Fabian,
ich bin mir jetzt nicht sicher, ob ich an den richtigen Stellen dafür gesucht habe - in der mit bekannten Openfire-Konfiguration kann ich dazu nichts finden, aber vielleicht suche ich nach etwas Falschem oder an der falschen Stelle.
Sicherheitshalber: Die betreffende Angabe wäre exakt wo zu finden?
Hallo Fabian,
danke für die Info - dann haben wir die Erklärung - da wird teils deutlich mehr transportiert (punktuell wohl über das Doppelte). Der Zusammenhang zum Umfang der UCI-Requests liegt dann sicher noch in Kombination an einer anderen Stelle, die ich hier gar nicht weiter erwähnen und beschreiben mag und die ich zum Glück nach längerer Überzeugungsarbeit dem Kunden ausreden konnte. Offenkundig wurde dann jetzt definitiv eine Schmerzgrenze überschritten - Dein Hinweis erklärt das jedenfalls.
Das heißt aber auch, dass diese Limitierung auch bei Folgeversionen der SF gilt, oder?
Hallo in die Runde,
ich bin im Zusammenhang mit der Verwendung verketteter Gruppen bei einer Kundenanlage auf ein merkwürdiges Problem gestossen:
Der Kunde wollte den eigentlichen simplen Lösungsweg für ein banales Anrufhandling haben, bei dem Anrufe zunächst bei einem Benutzer für einige Sekunden klingeln, danach für weitere Sekunden an eine erste Gruppe von anderen Benutzern signalisiert werden und, falls diese nicht annehmen in einer zweiten Runde an weitere, andere Benutzer weitergegeben + wenn auch diese nicht abnehmen nach weiterer Klingelzeit auf der Mailboch landen.
Gelöst wurde das dann tatsächlich durch eine Weitergabe an zwei Gruppen, die Ihrerseits jeweils über separate mehrstellige Rufnummern angewählt werden. So weit - so gut - funktionierte lange Zeit für verschiedene Szenarien bei genau diesem Kunden auch so.
Mittlerweile ist der Kunde sehr stark gewachsen, hat ein zigfaches an Mitarbeitern und eben auch zusätzliche Anforderungen. Beim Anlegen zweier weiterer in dieser Form verketteter Gruppen gab es nunmehr für die letzte neu angelegte Gruppenkombination plötzlich den Effekt, dass alle, in der zweiten Gruppe befindlichen Gruppenmitglieder, sich nicht mehr via PrepiumApp an der Starface anmelden können. Es ist eindeutig so, dass es sich um benannte Gruppenmitglieder handelt und auch nur diese - kein anderer Benutzer ist betroffen. Bei Entfernen eines Benutzers aus jener zweiten Gruppenstufe kann der sich auch sofort wieder anmelden.
Gibt es für solche Gruppenkonstellationen mit Blick auf die Anzahl von Gruppen und Gesamtgruppenmitgliedern eine Limitierung?
Die bisher genutzten Gruppen sind bezüglich der Gruppenmitglieder sehr umfangreich, wobei es eine untere zweistellige Anzahl von Gruppen gibt. Die betreffende Starface-Installation ist bis an die Grenzen des vom genutzten Linuxunterbau überhaupt verarbeitbaren RAM und CPU bestückt, hat also von dieser Seite technisch eher gar keine Mühe damit und verhält sich mit Blick auf genutzte Ressourcen auch komplett unauffällig und ruhiger als so manche Standardinstallation ...
Gibt es dazu irgendwelche Hinweise?
@Starface?
Hallo Fabian,
super - so macht es Spaß!
Das Ganze hat punktgenau geklappt und sofort für Abhilfe geschaffen / der Logbereich funktioniert wieder und ich kann mich beruhigt an den nächsten Schwung Starfaces zur Umstellung auf die Version 7 machen
Besten Dank auch an Daniel Mauritz!
Euer beider Hinweis hat das Problem natürlich bestens erklärt ...
Danke für den Hinweis - ich sende Dir mal den Logauszug per PN ...
Die betreffende Installation läuft mit 4 GB RAM
Nachtrag zum Thema:
Zwischenzeitlich wird beim Aufruf der LOGs wenigstens noch eine Fehlermeldung angezeigt: "Es ist ein Fehler in der Anwendung aufgetreten!".
Kontrolliert hatte ich zwischnezitlich mal auch die Log-Files auf Vorhandensein und korrekte Rechte + Besitzer - das passt wohl alles (im Vergleich zu anderen Installationen.
@Starface???
Hallo in die Runde,
nach Update einer Starface auf Version 7.3.1.3 ist in einem Fall der Aufruf der Logs im Administrationsbereich nicht mehr möglich - das betreffende Fenster bleibt leer / das offene Adminfenster hängt sich auf, kann danach nur noch geschlossen werden und funktioniert erst nach einem Neustart wieder (der Log-Bereich ist allerdings nie nutzbar - alles Andere schon).
Browsercaches wurden bereits geleert und auch verschiedenen Browsern (allesamt aktuell) getestet. Betroffen ist auch nur eben diese eine Starface - andere verwaltete Kundenanlagen haben unter gleichen Bedingungen dieses Problem nicht.
Aufgefallen war allerdings auch in einem anderen Fal direkt nach dem Updatel, dass dieser Effekt auch auftrat, wenn eine virtualisierte Starface nur eben über die empfohlenen 2 GB RAM verfügt (exakt im Bereich der Logs wird dann eben auch nichts angezeigt und das Fenster hängt sich auf). Hatte man bei jener SF das RAM auf 4 GB angehoben, lief es problemlos auch im Bereich der Logs ...
Wie kann man hier Abhilfe schaffen?
Hallo in die Runde,
gibt es eine Option, bei Gesprächsmitschnitten den Mailversand zu dektivieren/unterdrücken? Im vorliegenden Fall würde die Speicherung und optionale tgl. Archivierung völlig ausreichen - der Mailversand ist in dem Fall völlig überflüssig und gar nicht gewünscht.
Aktuell noch im Einsatz SF 6.7.3.22
Hallo in die Runde,
wir haben bei einen Kunden mit aktuell deutlich mehr als 300 Usern das Problem, dass bei einigen Benutzern bei der Anmeldung des Clients sporadisch das Passwort falsch zu sein scheint. Sobald der Nutzer das (gleiche / bekannte) Passwort (im Client) neu einträgt, kann sich der Client auch wieder anmelden.
Leider geht mit dem Auftreten dieses Problemes offenbar ein zweites Problem einher:
... ab und an werden in o.g. Situation während des Anmeldeversuches der Clients mit plötzlich vermeintlich falschem Passwort, andere bereits angemeldete User rausgeworfen + die Systemlast der SF steigt deutlich an.
Im Einsatz ist in diesem Fall Anwendungsbedingt aktuell noch eine SF 6.7.3.22 mit dazu passenden Client 6.7.3.322
Kennt jemand diesen Effekt und gibt es dazu einen Lösungsansatz?
