Lukikum

Hallo zusammen, wir sind gerade dabei unsere Zertifikate zu erneuern. Die Gelegenheit wollte ich benutzen um den Download Domain Check zu konfigurieren. Da wir unterschiedliche Standorte mitverwalten, haben wir für autodiscover unterschiedliche alternative names hinzugefügt: autdisocver.maildomain1 autdisocver.maildomain2 autdisocver.maildomain3 etc.. ist das für den Domain check Eintrag auch nötig? Ich würde sagen nein, da es ja nur owa betrifft. Ich wollte es aber noch mal hier absegnen lassen, bevor ich mir doppelte Arbeit mache. Danke und LG Lukas

Hallo winmadness, super, ich wusste garnicht wie flexibel man diese Templates anpassen kann :) Danke dass du dir die Zeit genommen hast, ich probiere es später aus

Schade, aber danke für die Hilfe

Hallo Winmadness, danke für die tolle Kurzanleitung :) Das Anpassen des templates hat super funktioniert, allerdings wird dort immer nur der erste "owner" angezeigt. Von den anderen leider keine Spur. Über Powershell und ECP sind die Einträge aber korrekt hinterlegt. Kleiner Edit: Ein Forumsbeitrag von 2012 sagt dass es sich dabei um eine technische Limitierung von Outlook handelt Ich Schaue mal weiter ob ich dazu noch was finde.. https://social.technet.microsoft.com/Forums/office/en-US/c167d210-d2b4-48c7-925d-0fed105ce4fc/address-book-will-only-show-one-owner-in-dl-after-added-multiple-owner-via-exchange-2010?forum=outlook

Moin zusammen, bei uns trudelt öfters mal die Anfrage ein, wer für welchen Verteiler als Besitzer eingetragen ist. Ich wollte mir die Arbeit ersparen und sie aufs Globale Adressbuch hinweisen. Wenn ich allerdings einen Verteiler öffne, wird dort immer nur ein Besitzer angezeigt. Der Besitzer Abschnitt lässt sich auch nicht vergrößern und ich kann auch nicht mit der Maus oder Tastatur scrollen. Ist das ein bekannter Bug und gibt es einen Fix dafür? Ein weiteres kleines Problem ist, dass im Online Modus das öffnen des Adressbuchs circa 30 Sekunden lang Outlook einfriert mit der Warnmeldung dass Outlook versucht eine Verbindung zu unsere Exchange aufzubauen. Nachdem er das einmal geschafft hat, scheinen die Daten gecached zu werden und es gibt für eine gewisse Zeit keine Probleme beim öffnen. Wir haben circa 3500 Einträge. Umgebung ist Exch 2019 on prem 15.2.1118.26 mit Outlook 2016 Client. Vielen Dank und LG Lukas

Okay

Das Problem ist, wie ich schon meinte, dass ich den Service nach meiner Ausbildung übernommen habe. Die Person die ursprünglich die Umgebung installiert hat, ist weg. Ich muss jetzt schauen dass die Umgebung wieder richtig läuft, bevor ich weiter optimieren kann. Also wieso wir für extern und intern unterschiedliche URLs haben.. Keine Ahnung, kann mir keiner im Unternehmen mehr sagen. Kleine Korrektur, die benutzen nicht die externe URL, sondern den DNS Eintrag mit dem Externen Namen. Das sollte ja erst einmal egal sein, da die Server ja trotzdem über den Namen erreichbar sein sollten. Unsere Umgebung besteht aus 4 Exchange on prem2019 Servern Für externe Zugriffe haben wir noch einen ReverseProxy (HAProxy) zwischen Exchange und externen client. Externe und interne URL sind leider getrennt. Wenn ich von außen die externe domain, autodiscover und interne Domain anpinge, gehen alle Pings auf unsere Firewall. Wenn ich also umstelle und die externe URL identisch zur internen habe, sollte es doch keine Probleme geben oder? ---- Für das anpassen der externen URL würde ich folgenden Guide benutzen: https://www.alitajran.com/configure-internal-external-url-exchange/

Ich meinte eher Clientseitig, aber ich habe gesehen dass man die Autodiscoverdatei selber Einstellen kann, das würde ich mal ausprobieren. Um wenigstens auszuschließen ob es wirklich an der externen URL liegt... Welche Punkte meinst du ? Hab ich etwas überlesen? Dachte eig. ich bin auf alles eingegangen.. Okay ich schaue mal, es gibt vermutlich etliche Server die die externe URL benutzen, die man dann Umstellen müsste.

Hallo Norbert, was für Infos könntest du denn noch gebrauchen? Mir gehen leider die Ideen aus. Gibt es eine Möglichkeit dass ich Outlook sagen kann, welche URL es benutzen soll? Ich denke das würde das troubleshooten etwas vereinfachen. Und wie groß ist der Aufwand die beiden URLs im Nachhinein gleichzusetzen? LG Lukas

Hallo Norbert, ich bin leider genauso verwirrt wie du. Wie kann ich überprüfen wieso die interne auch von extern erreichbar ist? LG

Moin Mikro, die ist von überall erreichbar. LG Lukas Hi Jan, weil ich selber die Exchange Umgebung nicht installiert habe. Ich habe den Service nur nach meiner Ausbildung übernommen, weshalb mir noch einige Kenntnisse fehlen. LG

Moin zusammen, das hier ist ein follow up zu dem Thema: Manche Outlook Clients außerhalb unserer Netzwerks bekommen keine Verbindung zu unserem Exchange Server 2019. Die Verbindung von außerhalb sieht so aus: Client -> Firewall -> HAProxy -> Exchangeserver Was ich schon getestet habe: Exchange Extended Protection disabled, da ich die Vermutung hatte, dass der HAproxy nicht so gut mit der klarkommt (SSL Bridinng) -> Hat keinen Unterschied gemacht, also habe ich die wieder aktiviert. O365 Authentifizierungsversuche auf den Clients komplett unterbunden -> hat keinen Unterschied gemacht Was ich jetzt überprüft habe ist aber interessant und geht leider über mein Verständnis hinaus: Als ich den Outlook Verbindungsstatus überprüft habe, habe ich gesehen dass die Clients bei denen es nicht funktioniert die "Externe URL" ansprechen (In unserer Umgebung sind intern und extern unterschiedlich). Wenn der Client von außerhalb aber die Interne URL anspricht, funktioniert die Verbindung. Was ich nicht verstehe ist, wieso bei manchen Clients die interne URL im externen Netz angesprochen wird? Gibt es einen Cache dafür? Was ich noch weniger verstehe ist, wieso die externe URL nicht funktioniert. Da ich die Exchangeserver nicht selber konfiguriert habe, fällt mir das troubleshooting diesbezüglich sehr schwer. Der MS Connectivity Test zeigt das die externe URL von außen ohne Probleme erreichbar sein sollte. Bei meinem HO Rechner ist übrigens der gleiche Fehler aufgetreten, der hat sich allerdings irgendwie von "alleine" gelöst. Ich vermute dass lag daran dass ich immer wieder eine VPN Verbindung aufgebaut habe und jetzt nimmt er auch außerhalb des Netzes die interne URL... Kann mir jemand ein paar Tipps geben? LG und vielen Dank Lukas

Wir benutzen HAProxy. Ob da ein Fehler auftritt ist schwierig einzuschätzen, kann aber sein. Wie troubleshootet man so etwas denn? Intern sind mir bis jetzt keine derartigen Probleme bekannt. Jetzt habe ich den Test erneut ausgeführt und die Rückmeldung bekommen dass die Verbindung "Erfolgreich mit Warnungen" ist. Zur Info, ich habe einen Beitrag im Netz zu was ähnlichem gefunden, mit ähnlichen Voraussetzungen, den schau ich mir mal an: https://github.com/haproxy/haproxy/issues/1828 Okay also es scheint wohl etwas mit SSL Bridging und verschiedenen Zertifikatspaaren zu tun haben: What mamama1 is doing is SSL bridging but not SSL offloading. SSL bridging is supported. reference The missing piece here is that the reverse proxy must use the exact same certificate-key pair as the backend for the Extended Protection to work (explained in the refence link above). As of the latest Exchange 2016 CU, the MAPI over HTTP does not require session affiliation, so you don't need to set up any affiliation in the haproxy setting.' Ich habe tatsächlich vor kurzem erst die extended Protection aktiviert, ähnlich wie im anderen Beitrag. Ich denke da werde ich mir erstmal ein paar Basics für aneignen müssen..

Ich habe es jetzt nach einer halben Stunde erneut probiert und dieses mal zeigt der Test mir auch tatsächlich an, dass die Verbindung nicht möglich. Es scheint so als wenn er die Methoden des AutoDsicovers durchgeht und dann gelingt. Also ist das wohl doch nicht das Problem. Wo er dann einen terminierenden Fehler bekommt, ist bei MAPI over HTTP, bei dem Punkt wo er das Adressbuch testet: Die MAPI-über-HTTP-Verbindung mit Server "XX.XX.de" wird getestet. Fehler bei der MAPI-über-HTTP-Verbindung. Testschritte Es wird versucht, den Hostnamen XX.XX.de im DNS aufzulösen. Der Hostname wurde erfolgreich aufgelöst. Weitere Details Es wird getestet, ob TCP-Port 443 auf Host XX.XX.de überwacht wird/geöffnet ist. Der Port wurde erfolgreich geöffnet. Die Gültigkeit des SSL-Zertifikats wird überprüft. Das Zertifikat hat alle Überprüfungsanforderungen bestanden. Testschritte HTTP-Authentifizierungsmethoden für URL XXXX werden getestet Die HTTP-Authentifizierungsmethoden sind richtig. Weitere Details Der MAPI-Adressbuch-Endpunkt auf dem Exchange-Server wird getestet. Fehler beim Test des Adressbuch-Endpunkts. Testschritte Der Vorgang "Namen überprüfen" des Adressbuchs wird für Benutzer XXX anhand von Server "XX.XX.de" getestet. Beim Versuch, den Namen aufzulösen, ist ein Fehler aufgetreten. Weitere Details Fehler in der Protokollschicht. HttpStatusCode: 401 Fehler-LID: 47372 Fehlerinformationen: ###### REQUEST [2023-02-13T10:46:22.3468449Z] [ResolvedIPs: XXXXXXXXX] ###### POST /XXXXXXXXXXXXXXXXXX HTTP/1.1 Content-Type: application/octet-stream User-Agent: MapiHttpClient X-RequestId: df305a3f-04fd-4a3d-8ac7-c2836f248a63:1 X-ClientInfo: 5a63d204-0c30-4c2d-a85c-fabe47b53422:1 client-request-id: 2e988979-5ef2-4cc7-8651-642ed73a804d X-ClientApplication: MapiHttpClient/15.20.5791.1 X-RequestType: Bind Authorization: Negotiate [truncated] Host: XX.XX.de Content-Length: 45 --- REQUEST BODY [+0.246] --- ..[BODY SIZE: 45] --- REQUEST SENT [+0.247] --- ###### RESPONSE [+0.499] ###### HTTP/1.1 401 Unauthorized request-id: 49326cee-aad3-4a14-86d4-d87874eac02d x-owa-version: 15.2.1118.21 x-failurecontext: FrontEnd;401;VW5hdXRob3JpemVk;;;; Server: Microsoft-IIS/10.0 WWW-Authenticate: Negotiate,NTLM x-powered-by: ASP.NET x-feserver: XX-MAIL date: Mon, 13 Feb 2023 10:46:22 GMT content-length: 0 --- RESPONSE BODY [+0.500] --- --- RESPONSE DONE [+0.500] --- ###### EXCEPTION THROWN [+0.500] ###### HTTP-Antwortkopfzeilen: request-id: 49326cee-aad3-4a14-86d4-d87874eac02d x-owa-version: 15.2.1118.21 x-failurecontext: FrontEnd;401;VW5hdXRob3JpemVk;;;; Server: Microsoft-IIS/10.0 WWW-Authenticate: Negotiate,NTLM x-powered-by: ASP.NET x-feserver: XX-MAIL date: Mon, 13 Feb 2023 10:46:22 GMT content-length: 0 HTTP-Statuscode: 401 Unauthorized Zwischen Exchange und Client haben wir einen Smarthost und einen ReverseProxy, welche die Anfragen an die Exchange weiterleiten. Ich kann mir vorstellen dass es ein Serverspezifisches Problem ist, da der Fehler nicht immer bei den Tests Auftritt. Ich überprüfe das mal weiter in den nächsten Stunden.

AzureAD benutzen wir noch nicht. Die Umgebung läuft komplett on prem.

Was genau macht der Pfad denn, bzw woher hast du Infos dass das meinem Problem helfen könnte. Würde gerne den Prozess dahinter verstehen

Der Pfad ist mir nicht bekannt, auf meinen Geräten auch nicht Existent. Ich versuche das mal bei den Anwendern zu überprüfen.

Sorry, ganz vergessen zu erwähnen. Wir benutzen bei Windows Clients Outlook 2016 und bei Mac 2016/2019. Ich würde mich aber erstmal auf 2016 konzentrieren, da ich noch keine Zeit hatte den Mac genauer anzuschauen.

Moin zusammen, bei manchen Leuten funktioniert Outlook von außerhalb des internen Netzes nicht mehr. Manche können keine Verbindung zum Exchange herstellen wenn Sie ihr Notebook mit bereits eingerichtetem Outlook ins HO nehmen. Manche können in anderen Netzwerken keine neuen Postfächer einbinden, ebenfalls keine Verbindung zum Exchange möglich. Ich konnte das Problem noch nicht reproduzieren und bin leider auch recht unerfahren mit Outlook Troubleshooting außerhalb des Netzwerkes. Was ich mal gemacht habe ist einen Test bei: https://testconnectivity.microsoft.com Dabei kam das raus: Es wird versucht, dem AutoErmittlungsdienst eine POST-Anforderung zu senden, damit er URLs ggf. automatisch erkennen kann. Beim Senden der POST-Anforderungen für die AutoErmittlung konnten keine AutoErmittlungseinstellungen abgerufen werden. Testschritte Die Microsoft-Verbindungsuntersuchung versucht, eine XML-Antwort des AutoErmittlungsdiensts von URL https://XXXXX:443/Autodiscover/Autodiscover.xml für Benutzer XXXXX@XXXXX abzurufen. Die Microsoft-Verbindungsuntersuchung konnte keine XML-Antwort von der AutoErmittlung abrufen. Weitere Details Ausnahmedetails: Nachricht: The request was aborted: The connection was closed unexpectedly. Typ: System.Net.WebException Stapelüberwachung: at System.Net.HttpWebRequest.GetResponse() at Microsoft.M365.RCA.Services.RcaHttpRequest.GetResponse() Woran kann es liegen dass die AutoErmittlung problem bekommt? Kleine Ergänzung von dem Test: Es wird versucht, die mögliche AutoErmittlungs-URL https://autodiscover.XXXX.de:443/Autodiscover/Autodiscover.xml zu testen. URL der AutoErmittlung erfolgreich getestet. Testschritte Es wird versucht, den Hostnamen autodiscover.XXXX.de im DNS aufzulösen. Der Hostname wurde erfolgreich aufgelöst. Weitere Details Es wird getestet, ob TCP-Port 443 auf Host autodiscover.XXXX.de überwacht wird/geöffnet ist. Der Port wurde erfolgreich geöffnet. Die Gültigkeit des SSL-Zertifikats wird überprüft. Das Zertifikat hat alle Überprüfungsanforderungen bestanden. Testschritte Die IIS-Konfiguration wird im Hinblick auf die Clientzertifikatsauthentifizierung überprüft. Keine Clientzertifikatsauthentifizierung erkannt. Weitere Details Es wird versucht, dem AutoErmittlungsdienst eine POST-Anforderung zu senden, damit er URLs ggf. automatisch erkennen kann. Die Microsoft-Verbindungsuntersuchung hat die AutoErmittlung-Einstellungen erfolgreich durch das Senden von AutoErmittlung-POST-Daten abgerufen. LG und vielen Dank Lukas

Hallo Nils, danke für die schnelle Hilfe. Das ist genau der Punkt den ich gesucht habe Funktioniert jetzt wie erhofft. Danke und LG Lukas

Moin zusammen, ich wollte für ein Personalpostfach eine automatisch Antwort über den Server laufen lassen: Nach erhalt einer Nachricht die an "Universelle Gruppe" gesendet wurde diese vom Server mit "***" beantworten und diese in den Ordner "XYZ" verschieben. Das ganze habe ich mit Exchange on premises 2019 und Outlook 2016 probiert. Die Nachricht wird auch in den richtigen Ordner verschoben, nur der Server verschickt keine Nachricht. Im Netz habe ich leider nur outdated Infos gefunden: "For others that may be looking for a solution to this I have a solution. The problem is the Auto Reply function has been tied to the out-of-office notifications When setting up the distribution group on Exchange you must go to the properties window and select the advanced tab. On the advanced tab, there is a box you can check to "Send out-of-office message to originator". Even though the Reply using a specific message function and the out-of-office notification are separate functions they are treated as the same by the exchange server." Diese Option habe ich bei meinen Verteilereinstellungen nicht gefunden. Hat jemand eine Idee ? LG und danke Lukas

Super, danke für die Infos. Dann werd ich das mal so schnell wie möglich nachholen.

Ahh danke für die info, das probier ich mal aus (Bei mir war noch deine alte Antwort geöffnet) Scheint leider nicht ganz optimal gecoded zu sein. Sieht so aus als wenn er nur einen der beiden Werte nehmen kann. Also Signed oder Encrypted. Sollte aber in der Regel kein Problem sein, da die Encrypted Mails ja eh signiert werden. LG Lukas

Oh schade, habe gehofft das Exchange die Möglichkeit hat signierte Mails zu erkennen.. Wir haben zwischen eingehenden Mails von extern noch ein SMTP relay, das kann signierte Mails erkennen. Ich habe es so konfiguriert, dass es einen ganz bestimmten Header bei den Mails setzen soll, wodurch eine Ausnahme in Exchange Regeln angewendet werden kann. Vlt. hilft dir das ja für eine automatisierte Erkennung. LG Lukas

Hallo Mikro, wie sieht deine Ausnahme für signierte Mails aus? Ich habe da auch mal nach gesucht aber nichts gefunden. LG Lukas