Lukikum

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.

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

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

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

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.

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

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

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.

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

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?