Lukikum

Sorry, ich meine die hier: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Connections -> Allow users to connect remotely by using remote desktop services. Mittlerweile haben wir die Vermutung dass es eventuell an Greenbone Scans liegen könnte.

Hallo zusammen, wir haben gerade ein merkwürdiges Phänomen in unserem Netzwerk. Unterschiedliche Windows Server Systeme (2012,2016,2019) scheinen willkürlich die Lokale Gruppenrichtlinie auf disabled zu setzen, welche den Zugriff auf den Server per remote steuert. Wir können uns das noch nicht ganz erklären, einen Cyber Angriff können wir auch nicht ausschließen. Es sind auch nicht alle Server betroffen. Im Eventviewer konnte ich auch kein Event finden was auf eine Änderung der Richtlinie zurückführen lässt. Hat jemand ähnliche Erfahrungen gemacht? LG Lukas

Ja ich hätte auch mit dem "Problem" einfach zum Experten gehen sollen. Es hat jedenfalls alle prima funktioniert, auch ohne DNS Einträge mit neuem Zertifikat.

Nein lieber nicht. Wir wollen ja komplett von "webmail" wegkommen. Das Zertifikat soll so schlank wie möglich sein und "webmail" soll überall durch den Standard "mail" ausgestauscht werden. Deshalb habe ich ja auch die externen URLs angepasst. Die Empfehlung haben wir so von einem Experten mitgeteilt bekommen, deshalb wundert es mich auch ein wenig, dass es durch die DNS Anpassungen zu Outlook Problemen kommen kann.

Okay hab ich wieder hinzugefügt. Neue Outlook Profile wäre wirklich ein Krampf. Morgen müssen wir auch neue Zertifikate einspielen, wo der "Webmail" Eintrag nicht mehr drin ist. Könnte es dann zu Problem führen wenn der "webmail" DNS noch exestiert?

Alles klar, danke für den Hinweis. Dann beobachte ich das morgen mal. Gibt es für den Fall eine Möglichkeit die umkonfigurierung manuell anzustoßen?

Hi Jan, danke für den Tipp. Die Einträge sind seit einer Stunde draußen und niemand scheint Probleme zu haben. Es sind ja auch nur die "webmail" Einträge. Die "Mail" Einträge sind gleich geblieben. Was für Probleme könnten denn noch evtl auftreten? Ja ich denke auch dass es das sein wird, danke für die schnellen Antworten. Ich beobachte die Lage und gedulde miche in wenig. LG Lukas

Moin zusammen, Ich habe auf Empfehlung hin heute morgen alle externen URLs mit den den Internen URLs gleichgesetzt. Allerdings ist OWA immer noch über die alte URL erreichbar. Die URLs wurden übernommen und den HTTP redirect habe ich auch angepasst. DNS Einträge sind auch weg, woran kann es also liegen dass der Exchange immer noch auf die alte Adresse reagiert ? Liegen die Infos evtl noch irgendwo gecached rum und ich muss mich einfach gedulden? Server sind Exchange on Prem 2019. LG Lukas

Das bedeutet auch 2 DNS Einträge und 2 Zertifikatseinträge, richtig? Ich weiß, ich kann es nur alleine nicht umstellen und muss leider auch andere Projekte priorisieren..

Alles klar, danke @NorbertFe und dir danke für deinen Guide Weiß jemand zufällig wie man die URLs konfiguriert wenn man noch keinen Split DNS hat?

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.