- Beitrag abonnieren
- Beitrag stummschalten
- Beitrag als ungelesen kennzeichnen
- Beitrag als gelesen kennzeichnen
CloudPBX Desktop-Client (Windows): "Netwerk nicht verfügbar"
Auf einer VM-Installation (Hyper-V) von Windows 7 habe ich den Desktop-Client der CloudPBX installiert. Direkt nach dem Start sind die Eingabefelder der Anmeldung deaktiviert und es wird die Meldung "Netzwerk nicht verfügbar" angezeigt. Die Internetverbindung besteht jedoch. Auch die Windows-Firewall scheint nicht Schuld zu sein, denn die Meldung kommt auch, wenn diese vollständig deaktiviert ist. Was könnte diese Meldung noch verursachen? Gibt es evtl. einen bekannten Bug? (Windows 7 Pro, Build 7601, Updates aktuell).
Gelöst! Gehe zu Lösung.
05.05.2022 09:57
Hallo @henniee#1,
vielen Dank für das nette Gespräch und Ihre Anfrage.
Ich habe gerade mit dem zuständigen Bereich darüber gesprochen.
Leider ist es immer noch so, dass dies von der Cloud PBX nicht unterstützt wird und wir hier auch weiterhin keinen Support in dieser Richtung leisten.
Auf die speziellen Fragen kann ich also leider keine Antwort geben.
Viele Grüße Martina Ha.
25.04.2019 16:03
herzlich Willkommen in unserer Community.
Die Kollegen der Technik haben mir Folgendes mitgeteilt: auch wenn der Kunde den Client in einer virtuellen Maschine installiert müssen die Systemvoraussetzungen erfüllt sein.
https://cpbx-hilfe.deutschland-lan.de/de/grundlagen/systemvoraussetzungen#_25226
Wenn er in seinem Fall die Firewall des virtuellen Win7 Arbeitsplatz ausschließen kann, wird die Ursache an einer anderen Stelle liegen.
Viele Grüße Heike Ha.
27.02.2019 08:06
herzlich willkommen in unserer Community. Schön, dass Sie mit Ihrem Anliegen den Weg zu uns gefunden haben.
Vielen Dank für Ihren Beitrag.
Haben Sie Ihrem Arbeitsplatz einen Desktop-Client als Endgerät zugewiesen?
Lieben Gruß Melanie B.
27.02.2019 11:24 Zuletzt bearbeitet: 27.02.2019 11:25 durch den Autor
Hallo Melanie,
ja, die Zuweisung ist erfolgt. Jedoch wird die Meldung ja auch bereits vor der Anmeldung angezeigt, also unabhängig von einem Benutzerkonto.
01.03.2019 10:11
da die Meldung bereits vor der Zuweisung erfolgt, unabhängig vom Benutzerkonto, schlage ich hier einmal vor auf die Kollegen zuzuhegen, die sich das auch aus der ferne ansehen können. Ich habe hier mal einen Link für Sie mitgebracht. https://bit.ly/2H9AqFW, somit können sich die Kollegen eventl. direkt auf Ihren PC schalten, um schnell zu helfen.
Man kann diesen Service direkt nutzen nach Zeit und zahlt dann für das eine Gespräch, ohne einen Techniker kommen zu lassen, oder als Monats ABO mit den hinterlegten Leistungen für den aktuellen Monat.
Ansonsten kann ich Ihnen noch anbieten, dass Sie Ihre Daten einmal im Profil http://bit.ly/Kundeninfos hinterlegen, und wir hier erst mal eine Messung gemeinsam durchführen!
Ich bin hier, Sie entscheiden ob Sie direkt mit einem Techniker sprechen möchten der sich aufschaltet, oder wir hier zusammen auf Lösungsversuche gehen.
Liebe Grüße
Sandra Ha.
01.03.2019 12:25
Hallo Sandra,
vielen Dank für den Link. Allerdings sehe ich dort nur Abo-Modelle (zwar mit kostenlosem Probe-Monat), aber keine Möglichkeit zur Einzelnutzung.
01.03.2019 12:33
auf der Seite selbst ganz unten steht auch eine Telefonnummer. Da sind die Zeiten auch hinterlegt. Viel Erfolg.
Liebe Grüße
Sandra Ha.
01.03.2019 12:40
01.04.2019 21:11
Hallo - gab es zu diesem Post eine Lösung - habe nämlich das gleiche Problem
02.04.2019 00:01 Zuletzt bearbeitet: 02.04.2019 00:02 durch den Autor
@andreas.scheidle Leider bin ich nicht dahinter gekommen, woran es lag. Irgendwann ging es dann einfach. Schwer zu sagen, ob es nun am Client, an anderer Software oder Windows oder einer Kombination daraus lag. Auf einer zweiten VM hatte ich das Problem von vorneherein nicht.
03.04.2019 11:51
herzlich willkommen in unserer Community und vielen Dank für die Nachfrage.
Ich habe diese gerade an unseren technischen Fachsupport abgegeben und schaue, ob ich so eine Antwort bekomme.
Ist es denn dringend? Es gibt noch die Möglichkeit, dass unser Remote-Service sich das per Fernwartung einmal anschaut. Dies wäre allerdings kostenpflichtig.
Wenn Sie das wünschen, dann geben Sie mir bitte Bescheid und hinterlegen Sie bitte Ihre Kundendaten in Ihrem Profil.
Viele Grüße Martina Ha.
03.04.2019 14:57
Hallo - grundsätzlich wäre es dringend - aber ich warte mal ab, ob es im technischen Support eine Antwort gibt. Das komische ist, dass die Windows10-Clients (FatClients) alle funktionieren; nur die mit Hyper-V virtualisierten PCs bringen diese Meldung (obwohl ich mit dem Browser ins WWW komme) ... welche Ports müssen denn für die Software am Client freigeschaltet werden?!? Bzw. reicht eine Regel auf die Commuincator.exe (TCP/UDP)?
03.04.2019 16:05
dazu kann ich leider nicht weiterhelfen, die Anfrage von Martina läuft noch.
Das Angebot mit der Unterstützung über die Experten steht. Falls Sie davon Gebrauch machen wollen, melden Sie sich bitte hier.
Lieben Gruß, Melanie B.
25.04.2019 12:54
Hallo,
ich habe hier das gleiche Problem.
CloudPBX eingerichtet, Desktop Client installiert auf virtuellem Win7-PC in Parallels auf MacOS. Der virtuelle PC ist in der Domäne und es funktionieren ALLE Netzwerkzugriffe.
Nur der Desktop-Client behauptet, dass das "Netzwerk nicht verfügbar" sei.
Installiert man den Client probelweise auf der Mac-Seite, geht alles. Das soll so bei uns aber nicht sein, deswegen scheiidet das als Lösung aus.
Gibt es zu dem Thema Neuigkeiten?
25.04.2019 16:03
herzlich Willkommen in unserer Community.
Die Kollegen der Technik haben mir Folgendes mitgeteilt: auch wenn der Kunde den Client in einer virtuellen Maschine installiert müssen die Systemvoraussetzungen erfüllt sein.
https://cpbx-hilfe.deutschland-lan.de/de/grundlagen/systemvoraussetzungen#_25226
Wenn er in seinem Fall die Firewall des virtuellen Win7 Arbeitsplatz ausschließen kann, wird die Ursache an einer anderen Stelle liegen.
Viele Grüße Heike Ha.
30.04.2019 14:48
Wenn er in seinem Fall die Firewall des virtuellen Win7 Arbeitsplatz ausschließen kann, wird die Ursache an einer anderen Stelle liegen.
Wo könnte denn die Ursache noch liegen?
02.05.2019 07:10
bitte entschuldigen sie die späte Rückantwort.
Es könnte vielleicht ein ein Port sein, der nicht freigeschaltet ist.
Jedoch kann es auch andere Ursachen haben.
Falls Sie nicht weiterkommen, füllen Sie bitte in Ihren Benutzerdaten die Felder „Kundennummer“ und/oder „Telefonnummer“ aus. Über folgenden Link gelangen Sie sofort zur richtigen Stelle in Ihrem Profil http://bit.ly/Kundeninfos
Im Anschluss freue ich mich über eine kurze Rückmeldung. Wir würden dann gemeinsam auf die Kollegen vom Remoteservice zugehen.
Lieben Gruß, Melanie B.
09.05.2019 13:32
Hallo,
jetzt muss ich ob meiner verspäteten Antwort um Entschuldigung bitten.
Ich habe die notwendigen Daten in den Benutzerdaten hinterlegt. Was folgt nun?
11.05.2019 13:44
vielen Dank.
Ich würde dazu gern am Montag Vormittag kurz mit Ihnen telefonieren. Passt das?
Lieben Gruß, Melanie B.
13.05.2019 08:40
13.05.2019 09:12
vielen Dank für das freundliche Gespräch und Ihr Verständnis.
Die Kollegen von der Störungsannahme helfen Ihnen als Großkunde in diesem Fall gern weiter.
Lieben Gruß, Melanie B.
16.05.2019 21:15
Guten Abend,
Fehler kann ich bestätigen, virtuelle Umgebungen werden nicht supportet. Was mir im Zug dessen aber aufgefallen ist, als ich dieses Verhalten mit Wireshark aufzeichnen wollte. Sobald npcap (enthalten in der Wireshark Installation) installiert ist, ist die Verbindung wieder möglich. Fragen Sie mich nicht warum, wäre aber ein möglicher Workaround.
VG
17.05.2019 07:09
Hallo - also das Problem ist, dass die Software wohl eine Loopback-Netzwerkkarte braucht (oder eben diese Funktion). Die Software funktioniert unter anderem mit VMWare und mit VirtualBox. Nur unter MS-Hyper-V bringt die Software den Fehler; die Lösung ist hier aber ganz einfach - man muss nur in der Virtuellen Maschine zusätzlich diese MS-Loopback-Netzwerkkarte nachinstallieren. Direkt danach geht die Software ohne Probleme ... und ich kann das Thema "wird nicht supported" nicht mehr hören. Liebe Telekom - in vielen Firmen wird nur noch in virtuellen Umgebungen gearbeitet - also überdenkt endlich mal die Ausrichtung und bringt diese Software in den Support zumindest für die drei gängigen Virtualisierungssysteme ... ach ja - Terminalserver wird ja auch nicht supported - die Software läuft aber auch stressfrei in einer MS-Terminalserverumgebung (zumindest mal in der Funktion als Verwaltungssoftware, dh. Kontakte, EInbindung Outlook, etc. - direkte Telefonie habe ich noch nicht im RDS-Umfeld getestet).
In diesem Sinne ... Loopback-NIC ist hier das Zauberwort.
17.07.2019 09:23
Vielen Dank schon mal für den Tipp. Ich stehe genau vor dem selben Problem, habe nun auch Loopback-NIC in Verbindung mit Hyper-V gegoogelt. Desweitern habe ich ein neues Switch in Hyperv mit dem Loopback Adapter eingerichtet, allerdings bekomme ich einfach keine Internetverbindung mit diesem Adapter aufgebaut. Hat jemand dafür noch ein Tipp. Oder eventuell eine vorgehensweise die zur Lösung geführt hat. Bin für alles Tipps dankbar.
28.04.2020 19:29
Vielen Danke für diese Information.
Soeben Nachgestellt und funktioniert tadellos.
07.10.2020 23:09
Ich habe dasselbe Problem, dass der Cloud PBX Client die Meldung "Netzwerk nicht verfügbar" anzeigt. Der Support sagte, dass ein virtualisiertes Windows unter HyperV nicht supported wird.
Installation des Microsoft Loopback Adapters oder des npcap Pakets hat keine Abhilfe geschaffen.
Im Logfile des Cloud PBX Client ist folgendes zu sehen:
2020-10-07 23:01:36,554 QtLogger [0x00000700] DEBUG 0xb29c8c8 all interfaces:
(QNetworkInterface(name = "ethernet_32769", hardware address = "00:15:5D:02:B1:06", flags = IsUp IsRunning CanBroadcast CanMulticast , entries = ((address = QHostAddress("fe80::11a7:f2c2:e3b6:621c%ethernet_32769"), netmask = QHostAddress("ffff:ffff:ffff:ffff::")), (address = QHostAddress("192.168.0.84"), netmask = QHostAddress("255.255.255.0"), broadcast = QHostAddress("192.168.0.255"))))
, QNetworkInterface(name = "loopback_3", hardware address = "", flags = IsUp IsRunning CanBroadcast IsLoopBack CanMulticast , entries = ((address = QHostAddress("::1"), netmask = QHostAddress("ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff")), (address = QHostAddress("127.0.0.1"), netmask = QHostAddress("255.0.0.0"), broadcast = QHostAddress("127.255.255.255"))))
) were found invalid
2020-10-07 23:01:36,554 NetworkLogger [0x00000700] DEBUG C:\jenkins\workspace\btbc_22.9.10_win_branded\scp\Utils\Network\network_interface_monitor.cpp(129): SCP::Utils::NetworkInterfaceMonitor::checkNetworkAvailability: 0x0b29c8c8 Network interface state changes, old available: false, new available: false
Es wird sowohl das "normale" Netzwerkinterface als auch ein "loopback" Interface erkannt, aber von der Software als ungültig befunden.
Hat hierzu noch jemand eine Idee?