Lukikum

Guter Punkt, stimmt !

Hi Jan, Danke für die Info. Da hab ich mir wohl das Update wieder mal nicht vernünftig durchgelesen.. Das wird das Problem sein, schade nur dass MS dazu nur folgendes schreibt: "The meeting body is read only. If you need to keep notes on the meeting, consider these alternate solutions:" So ein Mist. LG Lukas

Exchange 2019 on prem EN CU13 neustes SU. Outlook 2016 Moin zusammen, ich habe gerade das bizarre Phänomen, dass die User plötzlich nicht mehr die Besprechungen von anderen Personen editieren können. Oft haben die User z.B. zu Meetingeinladungen in ihren eigenen Kalender Anhänge oder Notizen reingepackt. Ich kann mir das nicht wirklich erklären, da ich diese Woche keine Änderungen vorgenommen habe. Hatte jemand von euch schon mal so einen Fall ? Im Netz habe ich leider nichts ähnliches gefunden. LG Lukas

Hi Jan, danke, gute Idee Ich schaue bei Gelegenheit mal was sich dahinter verbirgt. LG

Hi Nobby, ja wir haben einen proxy im Einsatz für den externen Zugriff. Intern haben wir einen Kemp Loadbalancer. Ich habe es eben auch mal ausprobiert, wenn ich von extern Zugreife funktioniert es bei meinem Konto auch nicht. Aus internen Netz kein Problem. Scheint wohl also irgendwie am Proxy zu liegen. Ich wüsste nur nicht woran, vermutlich fehlt da schon seit Jahren eine Einstellung und es ist niemandem aufgefallen..

Exch19 on prem latest SU/CU Moin zusammen, manche User haben das Problem, dass sie in OWA nicht die Verteilergruppen Option öffnen können. Es tritt der Fehler 403 auf "Request forbidden by administrative rules". Daraufhin habe ich mal die Nutzer Rollen überprüft. Dort ist allerdings alles richtig hinterlegt. Bei anderen, die die gleiche Rolle haben, funktioniert es auch. Hat jemand eine Idee woran es noch liegen könnte? LG Lukas

Alles klar, ich danke dir für die geteilte Erfahrung

Hi Norbert, wie oft patcht du die Server denn? Schaust du jede Woche nach neuen W Updates ?

Moin zusammen, ich wollte mal bei euch nachfragen wie ihr euer Patchmanagement beim Exchange gestaltet. Momentan ist es bei uns so, dass alle Windows Server einen Monat später mit Windows Updates gepatcht werden, sprich wir schauen ob die Updates Bugs verursachen und spielen sie dann drauf. Die Exchange sind von dieser Regelung ausgenommen worden. Die werden gepatcht sobald ein Sicherheitskritisches Updates released wird oder ein SU oder CU Update ansteht. Macht es eurer Meinung nach Sinn die mit in das verzögerte System mitaufzunhemen? Oder werden für Exchange SU/CU Updates immer die neusten Windows Updates benötigt? LG Lukas

Hi Mikro, klasse. Ich Blindfisch hab nicht genau hingeschaut. Dort war noch die alte IP Adresse eingetragen. Komisch, alle anderen Server haben dort ALL ipv4 hinterlegt. Scheint jetzt zu funktioniere. Ich danke dir !

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