DIS

OK, Danke - werde ich bei Gelegenheit probieren. Danke für die Hilfe, das Wichtigste ist klar. lg

wacx.exe - A simple Windows ACMEv2 client

Beim Erstellen des Zertifikates mit LetsEncrypt legt er es bequem im Windows Zertifikatspeicher unter "Eigene Zertifikate->Zertifikate" ab, da wo auch das Exchange Zertifikat drinnen ist.- Exchange zeigt es dann automatisch unter "Server->Zertifikate" an. Also ich hab hier nichts manuell importiert oder so....

Ja, klar, aber Standardmäßig eingerichtet... Ja, alles grün Sonst würde ich mir ja sorgen machen. Mir missfällt nur, dass ich mein LetsEncrypt ZErtifikat nicht für SMTP aktivieren kann. Ansonsten geht eh alles und ich frag mich eben ob ich mich dann zurücklehnen kann...

OK, danke - für SMTP enabled ist einzig und alleine das Standard "WMSVC-SHA2" Zertifikat. Wenn ich versuche mein LetsEncrypt Zetifikat (welches für IMAP, POP, IIS enabled ist) auch für SMTP zu enablen werde ich zwar gefragt: "Soll das vorhandene SMTP-Standardzertifikat überschrieben werden? Aktuelles Zertifikat: 'XXXXX' (läuft am 24.02.2028 15:32:01 ab) Ersetzen durch Zertifikat: 'YYYYY' (läuft am 06.02.2023 12:58:18 ab)" Wenn ich das mit ja beantworte ändert sich leider nichts daran. Beim LetsEncrypt bleibt "nur" IMAP, POP, IIS stehen. Von SMTP ist nichts zu sehen und beim "WMSVC-SHA2" bleibt SMTP stehen und ist auch ausgegraut, sprich kann nicht deaktiviert werden. Irgendwie seltsam. Stellt das ein Problem dar dem ich nachgehen sollte oder kann man das so belassen?

Nachdem ich mich jetzt mal ein wenig mit dem Thema Exchange 2016 und TLS 1.2 beschäftigen musste ist mir aufgefallen, dass Standardmäßig keinem meiner Receive Connectoren ein TLSCertificate zugeordnet ist. Bei Ausführung des CMDs "Get-ReceiveConnector |fl Name, TlsCertificatename, Bindings" bleibt die Spalte TlsCertificateName bei allen Konnektoren leer. Der Exchange funktioniert soweit perfekt und unterstützt nach den gängigen Tests auch TLS 1.2. Muss dann einem Connector ein Zertifikat zugeordnet werden bzw. was bringt sich das wenn es offensichtlich auch ohne geht?

Ok, danke für die Inputs. Ich kann wirklich nirgendwo ein Problem mit dem Zertifikat finden. Soweit funktioniert ja alles (bis auf RCA). Dann lasse ich das jetzt einfach mal so stehen...

Habe beim Zertifikat nun auch SMTP aktiviert - leider keine Änderung. Aktuell nur eine Cisco RV345. Hab die Firewall dort mal kurz deaktiviert, leider auch keine Änderung :(

Hi, mein Exchange 2016 verwendet ein LetsEncrypt Zertifikat. Dem Zertifikat sind im AdminCenter die Dienste "IMAP, POP, IIS" hinterlegt. Alle Outlook und Smartphone Clients funktionieren sowohl von intern als auch extern problemlos. OWA funktioniert problemlos und der Browser zeigt beim Verwenden von OWA das korrekte Zertifikat an. Wenn ich mit dem Microsoft Remote Connectivity Analyzer einen Outlook Connectivity Test mache schlägt er an der folgenden Stelle fehl: The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server xxx.tld on port 443.The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate. Additional Details: The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation. Ich habe keine Ahnung warum bzw. seit wann das so ist. Kann wer helfen?

Ok - dann kenn ich mich jetzt aus.

Keine Ahnung. Mir stellt sich nur die Frage, dass wenn RPC/HTTP ohnehin besser ist warum dann Exchange/Outlook nicht ohnehin standardmäßig RPC/HTTP verwendet.

​Ich habe die Einstellung ServerExclusiveConnect für EXPR jetzt wie du gesagt hast aktiviert. Es wird jetzt auch unter <Type>EXPR</Type> <ServerExclusiveConnect>on​</ServerExclusiveConnect> angezeigt. Die Folge ist jetzt, dass alle Clients, also egal ob sie sich in der Domäne befinden oder sich nicht in der Domäne befinden und per hosted Exchange zugreifen von Anfang an ausschließlich RPC/HTTP verwenden. Wäre es nicht besser bzw. möglich dass die internen Clients weiterhin RPC/TCP nutzen?

Da interne Domains immer öfter nichtmehr in ein Zertifikat aufgenommen werden können habe ich an einem Exchange Server 2010 Split-DNS eingerichtet und: - Alle Dienste (ECP, EAS, OABD, OWA, Autodiscover, WebServicesVirtualDirectory) - Den Service Connection Point (SCP) im Active Directory - Den RPCClientAccessServer Parameter der Datenbank so umkonfiguriert, dass sowohl intern als auch extern nur mehr die von extern erreichbare Clientzugriffsdomäne mail.sss.at verwendet wird. Folglich muss der interne FQDN "Server01.sss.local" nichtmehr im Zertifikat stehen. Diese Konfiguration funktioniert mittlerweile auch und alle neu eingerichteten Clients werden per Autodiscover richtig konfiguriert und können auf ihre Exchangekonten zugreifen. Mir ist allerdings aufgefallen, dass der Clientzugriff von Extern dadurch wesentlich langsamer geworden ist. Der Grund dafür ist, dass vorher die Verbindung über RPC/TCP aufgebaut wurde. Jetzt probiert Outlook beim Start immer zuerst RPC/TCP bekommt aber keine Verbindung und dann nach ca. 30 Sekunden wird RPC/HTTPS versucht, was auch funktioniert. Wenn ich den Server jetzt in die DMZ stelle ist das Problem weg und der externe Zugriff funktioniert ohne Verzögerung und Wartezeiten wieder über RPC/TCP. In der Verbindungsübersicht tauchen immer die Ports 6010 sowie 10872 auf. Wenn der Server jedoch nicht in der DMZ steht und man Portweiterleitungen für die beiden Ports anlegt ist das Problem jedoch wieder da. Folglich müssen hier noch andere Ports im Spiel sein. Bei diversen Recherchen habe ich jedoch nichts gefunden und ich möchte den Server nicht unbedingt in der DMZ stehen haben..... Vielleicht hat hier jemand eine Lösung - ansonsten muss ich mir mal eine Nacht mit Wireshark um die Ohren schlagen....

Vielen Dank für die professionelle Hilfe. Jetzt funktioniert es so wie ich mir das vorgestellt habe!

Ok, aber um es mal zu testen: Müsste ich dann "autodiscover.uuu.at" als SRV-Record anlegen mit dem Zielhost sss.at und einem Port z.B. 999. Und im IIS dann eine https-Bindung mit ebenfalls dem Port 999?

Also du meinst eine eigene offizielle IP. Und wenn ich keine zweite habe?

Dafür bräuchte ich doch eine eigene Bindung für https://autodiscover.uuu.at? Der Server läuft unter IIS 7.5 (Windows Server 2008 R2) was kein SNI unterstützt. Oder hab ich da was übersehen?

Ich habe ein gültiges Zertifikat für sss.at. Bei allen E-Mail Adressen @sss.at funktioniert Autodiscover etc. bestens. Nun werden jedoch auch mails von uuu.at vom Exchange 2010 Server angenommen. Ich möchte jedoch kein neues Zertifikat. Folglich habe ich einen CNAME Record für "autodiscover.uuu.at" auf "sss.at" eingerichtet. Hier schlägt Autodiscover logischerweise fehl, weil beim Verbindungsaufbau mit "https://sss.at"kein Zertifikat hinterlegt ist in dem "autodiscover.uuu.at" vorkommt. Folglich habe ich zusätzlich am Host "sss.at" ein HTTP-Redirect von "autodiscover.uuu.at" auf "https://sss.at"eingerichtet. In dem Fall muss das Zertifikat nur mehr für "sss.at" und nicht mehr für "uuu.at" gültig sein. Soweit funktioniert alles bestens. Das was mich allerdings stört ist, dass Outlook beim Einrichten eines Kontos immer zuerst einen Verbindungsaufbau mit "https://autodiscover.uuu.at"versucht -> Hier kommt dann die Zertifikatswarnung. Erst wenn man dort auf "NEIN" klickt probiert Outlook die HTTP-Adresse "http://autodiscover.uuu.at" wird dann ordnungsgemäß weitergeleitet und verbindet sich dann richtigerweise ohne Zertifikatswarnung. Outlook merkt sich das auch denn bei weiteren Starts von Outlook wird sofort die richtige Verbindung (Redirect) verwendet. Ist es jedoch irgendwie möglich bzw. irgendwas zu machen, dass die Zertifikatswarnung auch beim ersten Verbindungsaufbau von Outlook bzw. dem Einrichten des Kontos nicht kommt?

Hallo zusammen, ich bin auf der Suche nach geeigneten Access Points für ein größeres Wohngebäude für eine Großfamilie mit Garten. Da ich bisher noch nie mehr als eine Standalone-WLAN-Lösung gebraucht habe wollte ich mich ein wenig mit erfahrenen Usern austauschen. Das gesamte Gelände sollte erfahrungsgemäß mit 5 Access-Points abgedeckt sein. Im Netz bewegen sich max. 10 Geräte gleichzeitig, allerdings sollten hier Mehrere DVB-S streams auf mobilen Endgeräten, Music -Streaming, sowie normales Internet surfen problemlos parallel nebeneinander ablaufen. Am besten wäre, wenn die Verbindung beim Wechsel zwischen 2 Zellen nicht abreißt. Zusätzlich sollte noch sowas wie ein Gäste WLAN parallel dazu zur Verfügung stehen. Welchen Cisco AccessPoint würdet ihr dazu empfehlen? Geht das ganze nur üb reinen WLAN Controller oder lassen sich die genannten Anforderungen auch durch mehrere Ap's m Autonomous Mode erfüllen? Besten Dank!

Hallo, der Versand erfolgt über einen Smarthost - hab jetzt aber trotzdem deinen Rat befolgt und die Sache mit den MX-Records richtiggestellt. Dabei ist mir dann auch schon die Lösung eingefallen ;-) Ich verwende jetzt für alle Adressen ausschließlich "mail.xxx.de" als Servernamen. Nach Ausführen des Befehles "Set-OutlookProvider EXPR -CertPrincipalName:msstd:mail.xxx.de" war die die Automatische Konfiguration wieder auf meiner Seite und jetzt funktioniert es wieder. Vielen Dank für deine Gedanken - haben mich zielsicher zur Lösung geführt!

Wie miteinander verbunden? Der MX Record beider Domains zeigt auf die IP unseres Servers und sie sind beide in Exchange als Akzeptierte Domäne eingetragen. also mail.xxx.de und mail.yyy.de zeigen auf die gleiche IP. Im SAN-Zertifikat sind auch beide hinterlegt. Soweit dürfte ja alles passen, denn wenn ich sie parallel einrichte dann läuft alles bestens. Aber wehe ich gebe dem einen User Vollzugriff auf ein anderes Konto - dann meckert er....

Hallo, unser Exchange server akzeptiert mails an mehrere domains. Heute wollte ich für einen bestehenden User X unserer Stammdomäne xxx.de den vollzugriff auf ein Konto eines users Y einer domäne yyy.de einrichten. Unter "Berechtigung Vollzugriff" habe ich in Exchange 2010 für das Konto des Users Y den user X eingetragen. Beim öffnen von Outlook (Verbindung erfolgt über Outlook Anywhere) kommt seitdem immer eine Zertifikatwarnung, und Passwortabfrage. Das richtige Passwort für den user X will Outlook plötzlich nichtmehr akzeptieren - somit ist kein Zugriff auf ein Konto möglich. Die vollständige Fehlermeldung lautet: "Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. Der Name des Sicherheitszertifikats ist ungültig oder entspricht nicht dem Namen der Zielwebseite "mail.xxx.de". Von Outlook kann keine Verbindung mit dem Proxyserver hergestellt werden. (Fehlercode: 0)." Wenn ich nur das Konto für User X oder nur das Konto für User Y einrichte funktioniert alles bestens. Auch wenn ich beide als vollwertige Exchange Konten parallel einrichte funktioniert alles. Nur, eben nicht wenn ich ein Konto anlege und für das andere einen Vollzugriff erteile?! Das Problem hab ich sowohl bei Clients unter Windows Vista und Windows XP mit Outlook 2010. Hat wer eine Idee woran das liegen könnte??

Mhm, Ok. Wusste ich nicht Aber mich haut das so auf, dass es anders nicht geht. Am alten Server hat es immer perfekt funktioniert. Hat niemand eine Idee es doch so hinzubekommen??

Ich will es zunächst mal probieren ohne eine Domänenmitgliedschaft hinzubekommen. Die Kassen starten manchmal neu und so müsste man sich ja immer mit Strg, Alt + Entf. anmelden, was aber schwierig ist da an den Kassen keine Tastatur angeschlossen ist. Die werden rein über ein Touch Panel bedient. Ic hhabe mittlerweile noch ein paar Kuriositäten über den Fehler gesammelt. Wenn ich einen Client PC mit Domänenmitgliedschaft neustarte dann ist die Kasse immer erreichbar - Namensauflösung und Ping funktionieren! Nach einer gewissen Zeit funktioniert dann die Namensauflösung nichtmehr wenn ich den Namen anpinge, bzw. wenn ich direkt die IP anpinge kommt eine Zeitüberschreitung. Nach dem Neustart des Clients ist alles wieder in Butter... Wie soll ich genau den DNS Suffix konfigurieren brauch ich da in den Einstellungen die Option "Diese DNS Suffixe anhängen (in Reihenfolge)" oder die Option "DNS Suffix für diese Verbindung" Danke und Grüße

Mhm, das hab ich vergessen zu sagen. Die beiden Kassen haben eine statische IP Konfiguriert und unser Server ist dort auch als primärer DNS eingetragen. An dem kann es nicht liegen. Meist du ich sollte auf dem SBS im DNS für die Kassen jeweils einen "A - Eintrag" anlegen?