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

vor 18 Stunden schrieb winmadness:

Hier ist die Lösung!

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

vor 3 Stunden schrieb winmadness:

Du hast Recht, ist ein Bug von MS - das Attribut "Managed-by" ist im Template Editor nicht korrekt implementiert. Zwei Möglichkeiten: Ticket bei MS Support aufmachen oder ein Outlook Makro erstellen.

Schade, aber danke für die Hilfe

vor 38 Minuten schrieb winmadness:

Die Anzeige der Gruppen-Besitzer ist tatsächlich ein "Bug". Du kannst das Formular auf dem Exchange Server mit der "Exchange ToolBox -> Details Templates Editor" ändern. Im Editor den Vorlagentyp "Group" für die gewünschte Sprache auswählen. Im Formular das Listenfeld für die "Besitzer" auswählen und rechts in den Eigenschaften "ScrollBars" auf "Both" festlegen. Des weiteren die Höhe der Box anpassen.

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
 

vor 12 Minuten schrieb NorbertFe:

Holt euch jemanden, anstatt da jetzt selbst zu experimentieren!

Okay

vor 27 Minuten schrieb NorbertFe:

wäre jetzt die Frage, wie das bei dir aussieht und wenn beide von extern erreichbar sein sollten, gibts eben einen Grund weniger, das unterschiedlich zu konfigurieren

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.

vor 32 Minuten schrieb NorbertFe:

Welche denn?

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.
 

vor 50 Minuten schrieb Lukikum:

Das kann man dir ohne Infos zu deiner Umgebung nicht sinnvoll beantworten.

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/

vor 19 Minuten schrieb NorbertFe:

Stell dir vor, warum es internal/external gibt. ;)

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...

vor 19 Minuten schrieb NorbertFe:

Da würde schon helfen, wenn du die oben erwähnten Punkte eben mal hinterfragst und ggf. hier beantworten kannst.

Welche Punkte meinst du ? Hab ich etwas überlesen? Dachte eig. ich bin auf alles eingegangen..

vor 20 Minuten schrieb NorbertFe:

Das kann man dir ohne Infos zu deiner Umgebung nicht sinnvoll beantworten.

Okay ich schaue mal, es gibt vermutlich etliche Server die die externe URL benutzen, die man dann Umstellen müsste.

Am 3.3.2023 um 13:48 schrieb NorbertFe:

wieso? Naja man geht in sich und überlegt, wieso die von extern erreichbar ist/sein sollte. ;) Wie gesagt, mit den paar Infos wirst du entweder noch nachlegen müssen, oder selbst überlegen.

Da man, wie oben erwähnt, meist internalURL und externalURL gleich setzt, wäre jetzt die Frage, wie das bei dir aussieht und wenn beide von extern erreichbar sein sollten, gibts eben einen Grund weniger, das unterschiedlich zu konfigurieren. ;)

 

Bye

Norbert

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

vor einer Stunde schrieb NorbertFe:

Aber wenn die interne url von extern erreichbar ist, wieso gibts dann eine externe url? So richtig schlau wird man aus der Beschreibung noch nicht.

Hallo Norbert,

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

LG

vor 16 Minuten schrieb mikro:

Moin, was sagt deine Outlook Anywhere URL? Ist die erreichbar? 

Mikro

Moin Mikro,

die ist von überall erreichbar.

LG
Lukas

vor 7 Minuten schrieb testperson:

Hi,

 

warum hast du interne / externe URLs nicht identisch. In recht vielen Fällen ist es Best Practice beide URLs identisch konfiguriert zu haben.

 

Gruß

Jan

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
 

vor 42 Minuten schrieb Nobbyaushb:

Was für ein Reverse-Proxy ist das?

Intern gibt es keine Probleme?

Wenn nein, kein Exchange-Problem, ich tippe auf den Reverse

Der Smarthost macht ja nur Port 25 Mailtraffic - eigentlich…

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..

vor 22 Minuten schrieb Nobbyaushb:

Du kannst es ja mal selber testen

https://testconnectivity.microsoft.com/tests/exchange

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:
 

vor 5 Minuten schrieb teletubbieland:

Es unterbindet den Versuch, dass die Outlook mit O365 verbinden will.

Das passiert vor Allem wenn ein connect mit AzureAD statt gefunden hat.

Da Du in der Fehlerbeschreibung relativ wenig von Eurer Umgebung preisgegeben hast, was das ein guess.

 

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

vor 9 Minuten schrieb teletubbieland:

Den musst Du erzeugen.

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

vor 18 Minuten schrieb teletubbieland:

Hast Du es mal hiermit versucht? :

 

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

 

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.

vor 1 Minute schrieb teletubbieland:

Moin,

 

hast Du O365 im Einsatz?

Bzw. welches Outlook verwenden die User bei denen es nicht funktioniert?

 

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:

 

Am 3.2.2023 um 16:06 schrieb NilsK:

Moin,

 

bestimmt wolltest du uns den Link zu der Quelle noch nennen, aus der das Zitat stammt?

 

Und sonst würde ich jetzt mal vermuten, dass der Schalter -SendOofMessageToOriginatorEnabled im PowerShell-Kommando Set-DistributionGroup dafür zuständig ist.

https://learn.microsoft.com/en-us/powershell/module/exchange/set-distributiongroup?view=exchange-ps

 

Gruß, Nils

 

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

vor 23 Minuten schrieb NorbertFe:

Nein.

Ja. :)

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

vor 16 Minuten schrieb mikro:

Das sollte aber auch funktionieren:

Set-TransportRule "Name" -ExceptIfMessageTypeMatches Encrypted,Signed

Ahh danke für die info, das probier ich mal aus (Bei mir war noch deine alte Antwort geöffnet)

vor 7 Minuten schrieb mikro:

Den hast Du probiert?

Set-TransportRule "Signatur" -ExceptIfMessageTypeMatches Encrypted,Signed

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

vor 3 Minuten schrieb mikro:

Du testest as aber schon bei neu ankommenden Antworten oder ?

Ich nehme da die Domain und / oder die IP aus die alles signiert verschickt.

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

vor 3 Stunden schrieb mikro:

Moin,

im Punkt 2 gebe ich dir Recht. die Ausnahme habe ich auch definiert. Das solltest Du auch machen "Windows10"

Gruß Mikro

Hallo Mikro,

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

LG
Lukas