Lukikum

vor 3 Minuten schrieb mikro:

Moin

Hast Du IP V6 auch aktiviert?

Was sagt das Eventlog?? Da muss was stehen.

Gruß mikro

Hi Mikro,

was genau meinst du mit Ipv6 aktiviert ? In den Adaptereinstellungen ist das Häkchen jedenfalls aktiviert.

Die Eventlogs sagen das was ich oben angegeben habe. Ich habe noch 2 edits hinzugefügt.

Moin zusammen,

ich bin gerade dabei die Exchange Server in ein neues VLAN zu setzen. Dabei ändere ich auch die IP Adressen. Einen habe ich bereits ohne Probleme umgezogen, allerdings möchte Nr2 nicht so gerne.

Es beendet sich dauernd der MSExchangeTransport Service.

------------------------------------
Im Event Viewer lässt sich dazu etwas finden. Es gibt einen Error mit der EventID 1019 und 1036 (Task Category SMTP Receive)

EventID 1019:

Failed to start listening (Error: 10049). Binding: "ALTE IP ADRESSE DES SERVER":2526.

EventID 1036:

Inbound direct trust authentication failed for certificate %1. The source IP address of the server that tried to authenticate to Microsoft Exchange is [%2]. Make sure EdgeSync is running properly.
------------------------------------

Ich habe die IP Adresse in den Adaptereinstellungen angepasst. Netzwerkseitig gibt es auch keine Firewall die Probleme macht. Der Server ist auch unter der neuen IPAdresse erreichbar.. Habt ihr eine Idee?

Umgebung ist exch 2019 on prem. Ich habe heute auch das neuste SU Update auf dem Server installiert.

LG
Lukas


EDIT:
EventID: 2937
Ich sehe gerade aber auch dass es eine Warnung für ADAccess gibt:

Process edgetransport.exe **** it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.

Edit2:

Port 2526 benutzen wir für die Rcp Verify von unserem Smarthost.

Am 13.6.2023 um 09:38 schrieb Nobbyaushb:

Welches Outlook ist im Einsatz?

Outlook 2016

Sehr schade ich habe gehofft es ist ein lösbares Problem und kein ms Bug...

Moin telber,

ich hatte einen ähnlichen Fehler und konnte es dann fixen indem ich den Pfad angepasst habe.

Unter dem Punk "Action" "Start a program" habe ich folgendes:

Program/script:
C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe

Add arguments:

-command ". '%exchangeinstallpath%\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Pfad\Skriptname.ps1

LG
Lukas

Moin zusammen,

kennt jemand das Problem, dass von einen auf den anderen Tag die Kategorien in einem Kalender zurückgesetzt wurden?

Wir haben z.B. für jeden Mitarbeiter in der Abteilung eine farbliche Markierung in einem freigegebenen Kalender. Die wird nicht mehr angezeigt. Wenn man aber auf einen alten Eintrag klickt, erkennt man, das eine Kategorie namentlich erwähnt wird, nur jetzt ohne Farbe. Wenn man einen neuen Eintrag erstellt sind die Kategorien auch weg.

Bei dem betroffenem Postfach handelt es sich um ein Userpostfach. Umgebung ist Exch 2019 on prem neuste CU.

LG
Lukas

vor 4 Minuten schrieb NorbertFe:

Theoretisch hinterlegt man die statisch nur wenn man mehrere gleichlautende Zertifikate hat, aber ein bestimmtes "benötigt". Bspw. für DANE. Ansonsten wird automatisch ein passendes auf Basis des EHLO Strings gewählt afair.

Bye

Norbert

Hi Norbert,

ich hab noch ein uraltes Zertifikat (Ich glaube es wurde Fehlerhaft angelegt und nicht aufgeräumt) von meinem Vorgänger, was tatsächlich den gleichen Namen hat und bis 2027 läuft. Das Zertifikat ist jedenfalls nicht gültig, da es self signed ist. Eventuell hat das dann die Probleme verursacht. Ich kümmere mich mal darum das Zertifikat wegzubekommen..

LG und danke
Lukas

Umgebung: Exchange on prem 2019 neuste CU

Moin zusammen,

vor eine Weile habe ich neue Zertfikate für die Exchange eingepflegt, das hat auch wunderbar funktioniert.

Gestern habe ich die die alten Zertifikate entfernt. Dabei ist aufgefallen, dass alle Verbindungen über Port 587 fehlgeschlagen sind. Nach ein bisschen googlen bin ich darauf gestoßen, dass die receive connectoren das neue TLS Zertifikat nicht automatisch hinterlegt bekommen haben.

Das habe ich dann beim "Client Frontend" receive connector nachgepflegt und es funktioniert wieder.

Nun die eigentliche Frage:

TLS wird ja auch bei anderen Connectoren benutzt, bei welchen muss nun auch das neue Zertifikat hinterlegt werden? Alle die ich nicht manuell gepflegt habe, haben garnichts hinterlegt.


Zur Info: Das Default SMTP Zertifikat habe ich nicht überschrieben.

LG
Lukas
 

Am 12.5.2023 um 15:01 schrieb Sunny61:

Ist die Mail in OWA auch nicht beim Empfänger im Postfach vorhanden? Nein, nicht dem User glauben, das klappt nicht immer. ;) Überzeuge dich selbst.

Tja wer hätte es nur denken können, die Mail war in einem Unterordner und es wurde nicht die richtige Suche vom User benutzt. :P

Nur komisch dass ich das nicht in der Nachverfolgung gesehen habe. Normalerweise wird einem dort angezeigt, dass die Mails in einen Ordner durch eine Regel verschoben werden.

Moin zusammen,

ein User hat 3 mal versucht intern eine Mail an einen anderen internen User zuzustellen. Dabei soll die Mail wohl nicht ankommen.

Im Message Tracking Tool sieht es so aus als wenn die Mail ohne Problem zugestellt wird. Das einzig auffällige ist der "recipient-status". Der Steht nämlich auf {BB} und einen Eintrag sptäter dann auf "Recipient OK". Das habe ich bei keiner anderen Mail gesehen und ich finde auch nichts in den Microsoft docs (https://learn.microsoft.com/en-us/exchange/mail-flow/transport-logs/message-tracking?view=exchserver-2019) dazu. Kennt den Status jemand?

Ich konnte den User leider noch nicht erreichen um selber mal im Postfach zu schauen. Da die Mail aber von keiner Regelung betroffen war, sollte sie auffällig im Posteingang rumliegen, deshalb habe ich dem User erstmal geglaubt.

Die Mail hat zusätzlich noch 2 Anhänge, eine .tif Datei und .xlsx. Eventuell mag der Exchange das ja nicht? Aber einen NDR gibt es jedenfall nicht.

Umgebung ist EX19 on prem.

LG
Lukas

vor 4 Minuten schrieb Sunny61:

Gruppenrichtlinien greifen nicht auf Gruppen. Gruppen können maximal als Sicherheitsfilter verwendet werden. Detailierter kannst Du es nicht benennen/beschreiben?

Nein ich bin leider kein AD Admin, aber ich merke ich brauche wohl noch dringend Nachhilfe in dem Bereich
Ich dachte immer, dass GPOs auch auf Sicherheitsgruppen angwendet werden können, so dass Mitglieder dieser Gruppe die GPOs bekommen.

Ich frage bei Gelegenheit noch mal genauer nach. Ich gehe dann aber jetzt davon aus, dass eine bestimmte GPO für die Server gelöscht wurde, die eine RDP Regelung beinhaltet hat, was dann bei der erstmaligen Überprüfung übersehen wurde.
 

vor 2 Minuten schrieb Sunny61:

In welcher Gruppe ist was genau konfiguriert gewesen? Oder meinst Du eine Gruppenrichtlinie?

Ich schätze mal eine selbsterstellte GG mit konfigurierter RDP Gruppenrichtlinie.

Moin zusammen,

das Problem ist durch das entfernen einer Gruppe aufgetreten. In der Gruppe gab es eine RDP Richtlinie für die Server (wurde beim ersten Check übersehen, deshalb hat das Troubleshooten etwas gedauert).
Anschließend kam wohl MECM um die Ecke und hat nach und nach die lokalen Einstellungen auf die Maschinen gepuscht (vermutlich eine vergessene Einstellungen die früher durch die Gruppenrichtlinie blockiert wurde).

Ist etwas unglücklich gelaufen, aber man lernt ja aus jeden Fehlern ;)

LG

vor 11 Minuten schrieb Sunny61:

Frag ihn doch einfach.

Zeit ist knapp. Ich denke es wird dazu noch ein Meeting geben. Ich melde mich wenn ich was neues weiß

Am 5.5.2023 um 17:42 schrieb daabm:

Wenn Du's per Domain Policy verteilst (und nach Möglichkeit noch die Verarbeitung der lokalen Policy deaktivierst), wäre das nicht passiert Aber ok.

Würde mich freuen, wenn Du ne Ursache findest und postest.

Das Rätsel hat ich sich gelöst. Unser Domainadmin hat wohl ein paar Konfigurationen angepasst die zu diesem merkwürdigem Verhalten geführt haben. Was genau er gemacht hat kann ich leider nicht sagen.

vor 3 Minuten schrieb daabm:

Das war mir schon fast klar, aber macht Ihr das echt per lokaler GPO? Greenbone sagt mir grad nichts.

Edit: "Lokale GPO" ist ein Widerspruch in sich - muß "lokale Policy" heißen Auch wenn man's per gpedit.msc bearbeitet.

Ja stimmt, die Lokale Policy. Wir machen es eigentlich nichts über diese Policy. Deswegen sind wir ja so verwundert wieso die sich plötzlich bei mehreren Systemen verstellen.

Greenbone is ein Tool um Schwachstellen im Netzwerk zu finden.

Wir haben nun erweitertes Logging eingerichtet um zu schauen wer oder was diese Policy ändert..

vor 7 Minuten schrieb daabm:

Zu wenig Info - was genau meinst Du mit "die lokale Gruppenrichtlinie" und mit "Zugriff per remote steuert"?

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

vor 6 Minuten schrieb NorbertFe:

Da wir die Empfehlung so nicht gehört haben und kennen, kann man schlecht sagen, ob dein Vorgehen korrekt so abgestimmt war. :)

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.

vor 1 Minute schrieb testperson:

Dann lass den "Webmail" doch einfach im 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.

vor 11 Minuten schrieb testperson:

Veröffentliche doch einfach vorerst wieder die alten DNS Records. Normalerweise sollte Autodiscover die Konfiguration anpassen im Worst-Case musst du den Usern neue Outlook-Profile verpassen.

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?

vor einer Stunde schrieb testperson:

Niemand der Anwesenden. ;) Wenn morgen / in den nächsten Tagen jemand ins Büro kommt und das Outlook Profil noch die alten Konfig hat, dann _sollte_ sich das automatisch umkonfigurieren. Es _kann_ da aber durchaus auch Haken. 

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?

vor 42 Minuten schrieb testperson:

evtl. Probleme zu vermeiden

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?

vor 42 Minuten schrieb NorbertFe:

DNS caching?

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

vor 14 Minuten schrieb NorbertFe:

Genauso, nur intern und extern eben anders. ;)

Das bedeutet auch 2 DNS Einträge und 2 Zertifikatseinträge, richtig?

vor 59 Minuten schrieb Nobbyaushb:

Split DNS korrekt einrichten ist eh ein muss 

Ich weiß, ich kann es nur alleine nicht umstellen und muss leider auch andere Projekte priorisieren..

vor 35 Minuten schrieb cj_berlin:

Einen SAN für die Domain selbst hingegen schon

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?