Toggle sidebar Toggle sidebar

3cx Kontakte Synchronisation mit Exchange

A

aquila

Bronze Partner
Basic Certified
Mitglied seit
13. Mai 2016
Beiträge
30
Hallo,

ich würde gerne die persönlichen Kontakte aus einem Postfach mit dem Exchangeserver synchronisieren.
Dafür habe ich wie beschrieben den impersonate Account am Exchange wie in dieser Anleitung beschrieben erstellt: https://www.3cx.com/docs/how-to-create-impersonated-user/
Leider findet keine Synchronisation statt - Der Kontakte Ordner am 3cx Backend bleibt leer. Gibt ein ein Logfile, wo man Ursachenforschung betreiben kann?

Meine Umgebung: Exchange Server 2016 in der selben Umgebung wie der 3cx Server
3cx Linux Instanz in der Version 15.5

Auch die Sache mit Basic Auth und Wind Auth habe ich schon geprüft und für nicht zum Ergebnis. (https://www.3cx.de/docs/adminhandbuch/telefonanlage-crm-integration/#h.6vvzd2xmeu7z)

Wäre super wenn mir jemand helfen kann.
 
Hallo Aquila,

Beachte hierfür bitte, dass die Synchronisation nur einmal am Tag gemacht wird und das um 04:00 morgens.
Ansonsten um es manuell zu pushen muss du den Dienst system server neustarten.

Setze bitte in die Management Konsole -> Aktivitätenprotokoll -> Einstellungen -> das Häkchen auf ausführlich.
Anschließend bitte starte die Dienste einmal neu.

Die logs die du überprüfen kannst ist der systemservice.log.

Gruß
Ilias
 
Ich bin auch nach der entsprechenden Beschreibung vorgegangen und habe auch eine Fehlermeldung im Protokoll gefunden (siehe unten).
Demnach findet offensichtlich die Synchronisation nicht statt, weil unser Exchange-Server kein passendes SSL-Zertifikat hat. Kann man diese Sicherheitsüberprüfung irgendwie ausstellen? Oder wie kann man das Problem umgehen? Ich habe leider nirgendwo gefundne, dass ich Vertrauenswürdige Zertifkate / Aussteller hinzufügen kann ...-.

Info|Synchronization of public folders started...
2019/03/27 09:42:55.996|590|0020|Info|Synchronization of Public Folder Kontakte started...
2019/03/27 09:42:57.952|590|0021|Erro|Error while checking contacts from Public Folder Kontakte
2019/03/27 09:42:58.093|590|0021|Excpt|Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The SSL connection could not be established, see inner exception. The remote certificate is invalid according to the validation procedure. ---> System.Net.WebException: The SSL connection could not be established, see inner exception. The remote certificate is invalid according to the validation procedure. ---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
 
Zuletzt bearbeitet:
Füge das Zertifikat dem Key Store auf der entsprechenden 3CX Maschine hinzu.
 
Und wie bekomme ich die Datei auf die Linux-Maschine? Ich habe 3cx mit dem Debian-Iso erstellt. Ich weiß also nicht, wie ich eine Datei zwischen der Linux-Maschine und dem Windows-Rechner kopieren soll. Muss ich da erst in die Tiefe gehen und entsprechende Dienste (zum Beispiel) ftp einrichten, oder gibt es da doch eine einfache Möglichkeit? Die Maschine ist mit vmware virtualisiert.
 
Datei mit "scp" kopieren. Unter Windows "WinSCP" oder putty sftp nutzen.
 
Danke,
Habe das Zertifikat (welches ich aus einem Browser exportiert habe) in das Verzeichnis:
/usr/local/share/ca-certificates/ (oder war dies das falsche Verzeichnis?)
kopiert. Habe mit:
update-ca-certificates
die Zertifikate aktualisiert (mit Bestätigung) und den Server auch noch neu gestartet. Es erscheint immer noch im Protokoll (beim Versuch mein Exchange-Konto zu synchronisieren):
The remote certificate is invalid according to the validation procedure.
 
Zuletzt bearbeitet:
So, hier noch mal ein Nachtrag:
Habe mit openssl das Zertifikat des Exchange-Servers mit openSSL überprüft und bekam als Rückmeldung:
No client certificate CA names sent
Peer signing digest: SHA 1
Server Temp Key: ECDH, P-256, 256 bits

Habe jetzt auch ein AlphaSSL-Zertifikat installiert. Im Browser wird alles richtig angezeigt, bei der openSSL-Abfrage immer noch die "No Client certificate CA names sent"

Aber das scheint ja normal zu sein (bekomme ich bei www.google.de auch als Rückmeldung
 
Zuletzt bearbeitet:
Auf welchen FQDN ist das Zertifikat ausgestellt und stimmt es mit der "Exchange-Server-URL" überein, die Du in der 3CX eingetragen hast?
 
Nach der Umstellung auf das AlphaSSL-Zertifikat noch nicht.
Damit scheint es jetzt zu funktionieren. Jetzt kommt wenigstens eine andere Fehlermeldung:

Für das Adressbuch des Benutzers:
|Error while checking contacts from personal addressbook [email protected] for extension 30
2019/03/28 14:17:12.003|590|0027|Excpt|System.ComponentModel.Win32Exception (0x80090020): GSSAPI operation failed with error - An invalid status code was supplied (Unknown error).
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.WebRequest.

Für den Kalender (aber nicht so wichtig, daher wieder deaktiviert):
Error synchronizing calendar for user [email protected] : GSSAPI operation failed with error - An invalid status code was supplied (Unknown error).

Ob es mit dem öffentlichen Ordner funktioniert, kann ich ja erst nach dem Nachtlauf feststellen.
 
Zuletzt bearbeitet:
So, habe das ganze mit der Windows-Lösung ausprobiert. Und es hat sofort funktioniert.
In einer Exchange-Umgebung dann doch die Windows-Lösung auf einen Domainen-Rechner bevorzugen. Auch wenn der Rechner wieder etwas mehr Ressourcen braucht.

Nach 10 Sekunden waren alle Kontakte eingespielt.

Gerade wenn man sich kaum mit Linux auskennt, sollte man auf jeden fall die Windows-Lösung nutzen.
 
Hallo Fisics,
klappt das auch, wenn ich statt https nur http nehme? Dann spare ich mir den Import der SSL-Zertifkatsdatei und lokal sehe ich die unverschlüsselte Übertragung nicht so kritisch. Oder setzt der 3cx-Server SSL voraus?
Gruß
Micha
 
Ist ein must-have. Leider funzen selbst signierte zertifikate nicht.
 
Hallo,

hmm, ich stehe mit V18 vor den selben Problem. Die Einbindung von Exchange 2016 funktioniert, aber bei dem sync, fragt er auch nach einem SSL Zertifikat. Ich habe zwar eins, läuft aber über die OWA nach draußen mit domain Name. Der interne Aufruf der EWS ist aber ein völlig anderer! Hat einer noch einen Tipp. Wie ich auf der Linux Kiste den Sync mit Exchange 2016 via SSL herstelle? Wie erstelle ich ein SSL Zertifikat auf den internen Server Name und wie hinterlege ich das auf der Linux Kiste?

Gruß Micha
 
Hallo,

konnte das Problem selber lösen! Leider habe ich einen falschen internen Pfad zur EWS unseres Exchange Server benutzt.

Tipp: Seht euch unbedingt auf dem Exchange die virtuellen Verzeichnisse an, dort stehen die Pfade für intern und extern!

Ich hatte Glück, unserer Sectigo Multidomain Zertifikat bildet den internen und externen Pfad ab und ist somt gültig.

Vielen Dank an dieses Forum, Gruß Micha
 
Da scheint evtl. Bedarf an einer Vereinheitlichung der Namen virtuellen Verzeichnisse zu bestehen.

Wenn ja: schau dir mal bei Franky das EMS Skript zum Setzen der virtuellen Verzeichnisse an. Mit Ex 16 CU 22 (kam diese Woche raus) und dem Lauf des akt. MS healthchecker.ps1 wirst du feststellen dass dort noch die Verzeichnisse ExternalDownloadHostName und InternalDownloadHostName festgelegt werden sollten. Das machen wir mit
Code: 
$domain= $(Get-AcceptedDomain |?{ $_.Default -eq "yes" }).Name
$externaldownloadhosthame = "autodiscover."+$domain
Set-OwaVirtualDirectory -Identity "owa (default Web site)" -ExternalDownloadHostName $externaldownloadhosthame
Set-OwaVirtualDirectory -Identity "owa (default Web site)" -InternalDownloadHostName $externaldownloadhosthame
Set-OrganizationConfig -EnableDownloadDomains $true
und setzen diese Pfade auch auf den autodiscover FQDN damit das mit dem Zertifikat abgedeckt ist - wobei man aufpassen muss wenn es mehrere accepted Domains gibt dass er nur die erste zieht.

Da es nichts kostet und gut funktioniert nutzen wir prinzipiell überall Letsencrypt mit SAN Zertifikat für alle E-Mail Domain FQDN und Autodiscover Einträge, automatischer Verlängerung mit dem Programm von win-acme.com (die aktuelle Version speichert die Zertifikate auch endlich mal ordentlich im Zertifikatspeicher des Computer unter eigene Zertifikate - als 'my' genannt - und nicht unter Webserver ab), wir lassen uns alle Arten von Zertifikaten erzeugen, legen die Dateien in einem lokalen Verzeichnis ab, wir benutzen das Feature 'Zentralisierte Zertifikate' im IIS welches auf dieses Verzeichnis mit den Zertifikaten verweist, im IIS benutzen wir für die Bindungen der Default Web Site und des Ex Back End den entspr. FQDN mit der Option SNI und der Option 'zentralen Zertifikatspeicher verwenden' und gut ist. Mit diesen Einstellungen gibt es auch keine Probleme beim Installieren der CU (sonst typ. Fehler beim Tausch der Zertifikate). Vor so einem Exchange hängt i.d.R. noch eine pfSense mit haproxy oder squid als reverse proxy mit SSL Offload (dank des Zertifkates welches mit einem anderen Skript immer mal automatisch vom Exchange auf die pfSense hochgeladen und aktualisiert wird), Einschränkungen der Zugriffspfade, ggf. der Zugriffzeiten und Standorte und die Suricata Regeln greifen beim SSL offload per reverse Proxy auch.
 
Um antworten zu können musst du eingeloggt sein.

Einstieg für Admins

Statistik des Forums

Themen
44.414
Beiträge
232.721
Mitglieder
78.331
Neuestes Mitglied
b2daniel
3CX Logo Footer Copyright © Sitemap Datenschutz Impressum
Oben Unten