Alle Artikel über "Proffix"

Swisscom Smart Business Connect mit TAPI nutzen

Simon Pedrett - April 27, 2018 - Allgemein, IT, Tutorials

Eine Smart Business Connect Lösung inklusive virtueller Telefonanlage von Swisscom via TAPI nutzen? Unmöglich? Nicht ganz. Mit Fingerspitzengefühl, Brecheisen und genug Geduld bringt man es zum laufen.

Das Problem

Die Swisscom liefert die Geräte bei einer virtuellen Telefonanlage im „branded“ – Zustand aus. Das heisst: Die originale Firmware der Geräte wurde verändert (ähnliches passiert auch mit bei Swisscom gekauften Mobiltelefonen). Neben dem Vorladen der Konfiguration (eine gute Sache) hat die Swisscom dabei aber auch den Administrativen Benutzer des Geräts gesperrt – was entsprechend nur eine eingeschränkte Konfiguration ermöglicht.

Bei Yealink Phones ist es konkret die „Action – URL“ die so nicht bearbeitet werden kann – und damit auch kein TAPI ermöglicht.

TAPI wird aber von vielen Fremdprogrammen eingesetzt um das Telefon mit z.B. einem ERP oder CRM zu verknüpfen (Auslöser für diesen Fall war die PROFFIX Telefonintegration).

Wer nun denkt, man bekomme diese Zugangsdaten per Swisscom – Support / Partner liegt falsch. „Das ist nicht möglich“, „Diese Daten hat nur der Hersteller“, „Die gibt es nicht“ u.ä. sind nur einige der zwar kreativen aber leider falschen Antworten die man erhält.

In Wahrheit möchten Sie diese Daten wohl einfach nicht herausgeben.

Die Lösung

Die Lösung ist mehrstufig und etwas komplexer. Im Groben sind es aber zwei Schritte:

Swisscom Branded Firmware entfernen, Original Firmware von Yealink aufsetzen
Korrekte SIP – Credentials besorgen

Sollte bereits ein debranded / unbranded Gerät vorhanden sein, kann direkt zum Schritt Korrekte SIP – Credentials besorgen gesprungen werden.

Swisscom HD Phone Yealink debranden

TFTP – Server vorbereiten

Idealerweise installiert man sich den TFTP – Server tftpd64 – hier gibts die portable Version (empfohlen)

Diesen entpackt / installiert man und führt ihn aus. Anschliessend erstellt man einen Ordner (z.B. Firmware) und verweist unter Current Directory tftpd64 auf diesen Ordner (hier kommt später die Firmware hinein).

Unter Server Interfaces wählt man das korrekte Netzwerkinterface aus (das mit einer IP…)

„Current Directory“ auf Firmware-Ordner verweisen, Korrektes Netzwerk Interface auswählen

Original Firmware Yealink besorgen

Der nächste Stolperstein; Yealink stellt nur einen Teil der benötigten Firmware online zur Verfügung, welche für das Debranding nicht ausreichen.

Zum Glück findet man die passenden Files nach einigem Googlen: Hier gibts die Yealink Recovery Firmware als Mirror

Je nach Modell (Yealink T46, T41, T42 oder T48) entpackt man das entsprechende Verzeichnis nun und kopiert den Inhalt in den im vorherigen Schritt erstellten Ordner Firmware.

Original Firmware flashen

Aufgrund fehlender Berechtigungen funktioniert das Flashen der Firmware nicht über den Webclient. Entsprechend muss das Yealink in den Recovery Mode versetzt werden. Das erreicht man wie folgt:

Für die gesamte SIP-Serie:

Yealink vom Strom trennen (Ausstecken!)
Lautsprechersymbol lange drücken und halten
Wieder mit Strom verbinden

Auf dem Yealink muss anschliessend die IP – Adresse des TFTP – Servers angegeben werden. Diese entspricht in der Regel dem Server Interface aus dem ersten Schritt („TFTP – Server vorbereiten“). Anschliessend bestätigen – ist alles in Ordnung sieht das wie folgt aus:

Nach erfolgtem Update empfiehlt sich das Yealink erneut mit der aktuellsten Firmware zu flashen (für T46 z.B. hier erhältlich):

Auf dem Yealink selbst sieht das Ergebnis dann wie folgt aus:

Sobald das abgeschlossen ist hat man ein aktuelles, unbranded Yealink mit sämtlichen Berechtigungen (Standarduser / Passwort: admin / admin)

Korrekte SIP – Credentials besorgen

Bei den Angeboten Business Telefonie kann man die SIP – Credentials direkt im Swisscom Kundencenter anfordern. Bei Smart Business Connect mit virtueller Telefonanlage (bzw. wie die Lösungen sonst noch heissen) klappt das nicht so einfach.

Die Lösungsidee dafür ist, dass egal wie viele Softclients, Apps etc. die Swisscom noch „vor die Lösung“ schaltet – schlussendlich doch immer eine gewöhnliche SIP – Verbindung dahinter steht.

Swisscom Client besorgen

Grundsätzlich sollte die Lösung mit jedem Client möglich sein – der Einfachheit halber verwenden wir aber den Windows Client alias Business Communication App.

Sobald dieser installiert ist besorgt man sich die Zugangsdaten aus dem Swisscom Kundencenter (Format: ***@***.join.swisscom.ch, Passwort scheint meist 8-stellig zu sein).

Hier unbedingt ausprobieren, ob der Login funktioniert. Falls nicht, dafür sorgen, dass er funktioniert. Das ist die Grundvoraussetzung für die nächsten Schritte.

Anschliessend in der Business Communication App unter Einstellungen –> Erweitert den Haken setzen bei System-Proxy verwenden. Dann die Software schliessen (wichtig!).

Einfach einmal zuhören…

Der letzte Schritt ist das Sniffen des Netzwerktraffics – oder auf deutsch; Einfach einmal zuhören, was denn die Business Communication App so zu sagen hat…

Da die Verbindung über SSL läuft funktioniert das mit Standardtools wie Wireshark etc. nicht auf Anhieb. Einfacher gehts mit Charles Proxy.

Charles Proxy hier herunterladen und installieren (30-Tage Demo reicht)
Charles öffnen

Nun muss das Root – Zertifikat von Charles installiert werden (Wichtig: Unter Vertrauenswürdige Stammzeritfizierungsstellen installieren, sonst klappts nicht) :

Charles Proxy Root Certificate installieren. Wichtig: Unter Vertrauenswürdige Stammzertifizierungsstellen installieren

Nun muss das System noch so konfiguriert werden, dass sämtlicher Traffic über Charles Proxy läuft. Dazu Internetoptionen öffnen und folgende Einstellungen vornehmen:

Nun ist alles bereit um „zuzuhören“. Die Business Communication App sowie Charles können nun beide wieder geöffnet werden. Bei Charles startet man die Aufzeichnung des Traffics über den Record – Button in der linken oberen Ecke.

Anschliessend kann man sich an der Business Communication App anmelden – in Charles sollten zeitgleich einige Anfragen auftauchen. Konkret interessiert uns dabei das config.xml unter folgendem Endpunkt:

Nach etwas Suchen im entsprechenden XML findet man das gewünschte SIP-Passwort als Klartext (über Wireshare würde man hier nichts sehen, da SSL).

Dieses Passwort in Kombination mit dem Benutzernamen (der übrigens auch im config.xml steht) ermöglicht nun alle möglichen Geräte an die virtuelle Telefonanlage von Swisscom anzuschliessen – unabhängig von „Branded Devices“, irgendwelchen Softclients und ähnlichem.

Put it all together

Wir haben nun ein Gerät mit Originalfirmware und vollen administrativen Befugnissen sowie funktionierende SIP – Credentials. Zeit alles zusammenzuführen:

Mit der Endziffer „-01“ des Benutzernamen kann etwas gespielt werden. Wenn’s nicht funktioniert einfach 00 oder 02 daraus machen…

Anschliessend alles testen – wenn sowohl ankommende als auch abgehende Anrufe funktionieren und auch evtl. Drittgeräte noch funktionieren ist alles in Ordnung.

Damit TAPI auch tatsächlich funktioniert und man Smart Business Connect auch mit Fremdlösungen wie z.B. der PROFFIX Telefonintegration einsetzen kann braucht es nun eigentlich nur noch die Software Phonesuite welche mit dem Yealink verknüpft wird.

Die Einrichtung derselben ist aber dank der vollen Administrativen Berechtigungen nun kein Problem mehr.

PROFFIX REST-API Live Debugging

Simon Pedrett - Oktober 8, 2017 - IT, Snippets, Web

Das Debuggen von Applikationen mit der PROFFIX REST-API ist gerade für komplexere Projekte suboptimal, da die Logfiles als reine Textfiles vorliegen. Mit folgender Konfiguration sind die Logfiles der PROFFIX REST-API nicht nur sortier- und kategorisierbar sondern auch immer live verfügbar.

Das Problem

Die PROFFIX REST-API schreibt Logfiles im Textformat in einen Ordner log. Das sieht dann so aus:

2017-10-06 13:37:39.7168: INF: [PxRestApi.Authentication.PxAuthenticationMiddleware]: PROFFIX was not authenticated. Failure message: Nicht authentifiziert. 
2017-10-06 13:37:39.7939: DBG: [Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware]: The request path /pxapi/v2/ADR/Kontakttyp does not match a supported file type 
2017-10-06 13:37:39.7939: DBG: [Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware]: The request path /pxapi/v2/ADR/Kontakttyp does not match a supported file type
2017-10-06 13:37:39.7939: DBG: [Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware]: DELETE requests are not supported

Für eine einfache Verwendung oder kleine Fehler mag das ausreichen. Jeder der aber einmal etwas komplexere Applikationen (wie etwa pApp – das App für PROFFIX) mit mehreren, verschachtelten Interaktionen debuggt hat, weiss wie mühsam das wird.

Deshalb hier eine bessere und vollständig individualisierbare Alternative – die übrigens auch für andere Logfiles funktioniert.

Die Lösung

Textfile mit nxlog parsen

NXLog ist ein Tool das sowohl für die Sammlung von Logfiles als auch das Parsing von Logfiles genutzt werden kann. Und das Beste daran – in der Community Version ist es absolut kostenlos.

Diese kann man hier herunterladen, anschliessend ganz gewohnt installieren.

NXLog selbst wird über die Datei nxlog.conf konfiguriert, die man gewöhnlich im Ordner C:\Program Files (x86)\nxlog\conf findet.

Um die Logfiles der PROFFIX REST-API zu parsen kann man folgende, vorkonfigurierte Config verwenden:

define ROOT C:\Program Files (x86)\nxlog
define CERTDIR %ROOT%\cert

Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log

<Input watchfile>
   Module im_file
## Pfad zum Ordner Log der REST-API Instanz anpassen
   File 'C:\\PXREST\\PXDEMO\\logs\\*.txt'
## Verwirft uninteressante Logs
   Exec if ($raw_event =~ /(The request path) (\S+) (does not match a supported file type)/) drop(); \
## Splittet Logs mit Regex auf
   Exec if $raw_event =~ /^(\S+ \S+): (\S+)\:\s\[+(\S+)\]\:\s(.*)/\
                { \
                  $EventTime = parsedate($1); \
                  $Message = $2+' '+$4; \
                  $SourceName = $3; \
## Syslog Severity / Für Papertrail unnötig
##       if $2 =~ /DBG/  $SyslogSeverity = 7; \
##       else $SyslogSeverity = 6; \
                } \
  SavePos TRUE  
  Recursive TRUE
</Input>

<Processor filewatcher_transformer>
  Module pm_transformer
  OutputFormat syslog_rfc5424
</Processor>

<Output syslogout>
       Module om_ssl
## Papertrail Host und Port anpassen
       Host xxxx.papertrailapp.com
       Port xxxxx
       CAFile %CERTDIR%/papertrail-bundle.pem
       AllowUntrusted FALSE
</Output>
<Route 1>
	Path watchfile => filewatcher_transformer => syslogout
</Route>

Diese Konfiguration erstellt aus dem PROFFIX REST-API Log automatisch ein Syslog, der per Netzwerk an beliebige Empfänger gesendet werden kann – und zwar live. Oder anders ausgedrückt – sobald ein Log-Ereignis eintritt, versendet NXLog das geparste und aufbereitete Ereignis automatisch.

Papertrailapp für Live – Log nutzen

Grundsätzlich könnte man mit NXLog praktisch jeden Log – Empfänger nutzen (z.B. Synology NAS Protokollcenter, Windows Ereignisprotokoll…)

Der Vorteil von Papertrailapp sind aber die diversen Filter – und Syntaxtypen kombiniert mit der Möglichkeit, Log – Events auch an weitere Benutzer freizugeben.

Account erstellen unter https://papertrailapp.com
Unter Add System ein neues System hinzufügen
Den Log – Endpunkt (z.B: logs5.papertrailapp) sowie den Port (z.B. 45353) von Papertrail in die NXLog – Konfiguration übertragen (ist auskommentiert).
Das Zertifikat von Papertrail unter https://papertrailapp.com/tools/papertrail-bundle.pem herunterladen und im Ordner C:\Program Files (x86)\nxlog\cert abspeichern
Den Dienst nxlog neu starten.

Eine detailliertere Anleitung in Englisch gibts auch hier: https://help.papertrailapp.com/kb/configuration/configuring-remote-syslog-from-windows/

Anschliessend kann man sich auf Papertrailapp.com einloggen und sollte bereits erste Logs sehen:

Anschliessend kann man unter Settings -> Event Viewer auch noch weitere Filter konfigurieren und auch weitere Benutzer (z.B. Entwickler) hinzufügen.

Dieser Filter macht die Logkategorien Debug, Trace und Info klick- und sortierbar.

SQL-Server: Fehler beim Warten auf das Wiederherstellungshandle des Datenbankmoduls

Simon Pedrett - Mai 15, 2016 - IT, Snippets

Nicht immer läuft die Installation des Microsoft SQL Servers problemlos ab. Wer die Meldung „Fehler beim Warten auf das Wiederherstellungshandle des Datenbankmoduls“ bzw. den Code 0x851A001A als Fehler bei der Installation erhält – so wirds einfach und schnell gelöst!

Der Fehler tritt insbesondere bei der Installation von SQL Server Express (z.B. für PROFFIX) auf – kann aber auch bei anderen SQL Server Versionen auftreten.

Lösung

Bereinigung

Zuerst einmal muss die mit dem Fehler installierte SQL – Instanz deinstalliert werden. Es ist nicht nötig, den ganzen SQL-Server zu deinstallieren(!)

Dazu wechselt man zu den Programmen, wählt den SQL – Server aus (z.B. SQL Server Express 2014) und klickt auf Deinstallieren.

(Hinweis:Die Funktion Reparieren hilft bei diesem Problem nicht).

Anschliessend klickt man sich durch den Assistenten und entfernt das Datenbankmodul (und nur das!) der entsprechenden Instanz.

Modifizierte Installation

Anschliessend ist alles bereit für eine neue, leicht modifizierte Installation des SQL-Servers. Ein Neustart ist nicht nötig aber empfohlen.

Bei der Installation der „neuen Instanz“ folgt man wiederum dem Assistenten, bis man zur Eingabemaske Serverkonfiguration kommt.

Hier ändert man den Kontonamen des SQL Server-Datenbankmoduls manuell (d.h. Eingeben oder Copy & Paste) wie folgt ab:

NT AUTHORITY\NETWORK SERVICE

Anschliessend kann die Installation abgeschlossen werden; es sollten keine weiteren Fehlermeldungen auftreten – und auch der SQL – Server Dienst sollte problemlos gestartet werden.

ODBC Driver Manager Fehlermeldung

Simon Pedrett - November 28, 2013 - IT, Snippets

Fehlermeldung

Beim Versuch eine Verbindung auf eine Datenbank herzustellen, tritt folgende Fehlermeldung auf:

[Microsoft][ODBC Driver Manager] Der angegebene DSN weist 
eine nicht übereinstimmende Architektur von Treiber und Anwendung auf

Ursache

Die Ursache des Problems findet sich bereits in der Meldung selbst („Architektur“). Eine 32bit Anwendung kann über einen 64bit ODBC Treiber keine Verbindung zur Datenbank herstellen. Wer ein 64bit Betriebssystem verwendet hat „ab Werk“ die entsprechenden 64bit Treiber vorinstalliert – ein Konflikt ist vorprogrammiert…

Lösung

Variante 1

Falls möglich einfach die 64bit Version der Anwendung verwenden. Diese befindet sich im Installationsordner, endet auf .exe und enhält meist die beiden Zahlen „64“ oder „64bit“ (z.B. Software64.exe)

Variante 2

Leider gibt es nicht immer eine entsprechende 64bit Version der Anwendung. Deshalb muss der 64bit Treiber mit einer 32bit Version ausgetauscht oder ergänzt werden.
Die entsprechende Konfiguration erfolgt über eine der folgenden .exe’s.

Falls OS = 32-Bit: C:\Windows\SysWOW64\odbcad32.exe

Falls OS = 64-Bit: C:\Windows\System32\odbcad32.exe

ODBC 32-Bit Treiber hinzufügen

Über die Schaltfläche „Hinzufügen“ können nun neue Treiber im richtigen Format aktualisiert werden.

Meist genügt das Hinzufügen eines 32-Bit Treibers – der 64-Bit Treiber kann parallel bestehen bleiben. Bei der nächsten Verbindung einfach den entsprechenden Namen verwenden (in diesem Fall „excel32“).