tesso 375 Geschrieben 4. Mai 2022 Melden Teilen Geschrieben 4. Mai 2022 Dein Skript SENDET die Mail an den Exchange. Der Exchange EMPFÄNGT die Mail mit einem Empfangsconnector. 1 Zitieren Link zu diesem Kommentar
vonAbisZ 2 Geschrieben 4. Mai 2022 Autor Melden Teilen Geschrieben 4. Mai 2022 vor 14 Minuten schrieb tesso: Dein Skript SENDET die Mail an den Exchange. Der Exchange EMPFÄNGT die Mail mit einem Empfangsconnector. Stimmt, soweit dachte ich gar nicht? Sachen gibt's. Also werde ich nun kurz einen Empfangsconnector einrichten und testen, NEWS folgen ;) Zitieren Link zu diesem Kommentar
vonAbisZ 2 Geschrieben 6. Mai 2022 Autor Melden Teilen Geschrieben 6. Mai 2022 (bearbeitet) NEWS 1. Wenn ich auf dem Exchange selber die Aufgabenplanung unter dem lokalen System User laufen lasse, erfolgt KEIN Mailversand. 2. Wenn ich auf dem Fileserver die Aufgabenplanung analog Exchange einrichte, auch den lokalen System User für das Ausführen der Aufgabe verwende, funktioniert der Mailversand! 3. Ich wurde aufgefordert, einen Empfangsconnector auf dem Exchange einzurichten, welcher anonymes senden von Mails erlaubt. Nun, auf dem Exchange Server stellte ich fest, dass bereits ein Empfangsconnector eingerichtet ist (FrontendTransport). Bei diesem sind unter dem Punkt "Bereichsdefinition" / Remotenetzwerkeinstellungen zig IPv4 Adressen vom internen LAN plus 1 externe, öffentliche IPv4 Adresse aufgeführt. Interessanterweise konnte ich wie im Punkt 2 geschildert, vom Fileserver aus erfolgreich die Aufgabe, ausgeführt unter dem lokalen System User, erfolgreich laufen lassen Und: Der Mailversand klappte so, dies, obwohl bei diesem Empfangsconnector (siehe auch anbei den Screenshot) die IPv4 Adresse des Fileservers, welchen ich soeben als Test verwendet habe, unter den Remoteadressen NICHT aufgeführt ist?! Und spannend ist auch, warum der Mailversand direkt vom Mailserver aus mit dem lokalen System User NICHT funktioniert/ funktionieren will?! Übrigens: Ich habe nun auf Grund dieser Problematik auch ein weiteres Problem: Denn ich müsste auf dem Exchange selber in der Antivirenlösung für den Exchange eine Benachrichtigung hinterlegen, welche auch nicht funktioniert. Drücke ich in dieser Antivirenlösung den Knopf: Maliversand testen, so erhalte ich auch eine Fehlermeldung, jedoch hilft mir diese auch nicht weiter. Dies einfach auch noch so am Rande erwähnt. bearbeitet 6. Mai 2022 von vonAbisZ Schreibfehler korrigiert Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 6. Mai 2022 Melden Teilen Geschrieben 6. Mai 2022 Hol dir jemanden der sich mit Exchange auskennt. Probleme wie du sie hast habe ich auf keinem Exchange. Per Forum ist die Fehlversuche echt mühsam. Hat der neue Connector auch das Recht anonymes senden? Welche Einschränkungen sind gesetzt? 1 Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 6. Mai 2022 Melden Teilen Geschrieben 6. Mai 2022 Einen anonymous relay mit Authentifizierung zu konfigurieren ist auch irgendwie unsinnig. ;) Zitieren Link zu diesem Kommentar
vonAbisZ 2 Geschrieben 9. Mai 2022 Autor Melden Teilen Geschrieben 9. Mai 2022 Am 6.5.2022 um 17:58 schrieb tesso: Hol dir jemanden der sich mit Exchange auskennt. Oha, jetzt aber. Am 6.5.2022 um 17:58 schrieb tesso: Probleme wie du sie hast habe ich auf keinem Exchange. Das freut mich für Dich. Am 6.5.2022 um 17:58 schrieb tesso: Per Forum ist die Fehlversuche echt mühsam. Wie kommst Du denn jetzt plötzlich zu diesem Schluss? Dann bist Du wohl hier nicht ganz am richtigen Ort? Am 6.5.2022 um 17:58 schrieb tesso: Hat der neue Connector auch das Recht anonymes senden? Welche Einschränkungen sind gesetzt? Das heisst, Dir reicht der Screenshot mit den aufgeführten Berechtigungen nicht aus? Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 9. Mai 2022 Melden Teilen Geschrieben 9. Mai 2022 vor 16 Minuten schrieb vonAbisZ: Oha, jetzt aber. Was willst du mir damit sagen? vor 17 Minuten schrieb vonAbisZ: Wie kommst Du denn jetzt plötzlich zu diesem Schluss? Dann bist Du wohl hier nicht ganz am richtigen Ort? Wie lange suchst du nun schon? vor 18 Minuten schrieb vonAbisZ: Das heisst, Dir reicht der Screenshot mit den aufgeführten Berechtigungen nicht aus? Du hast jetzt ein Neuen Connector gebaut mit den gleichen Eigenschaften wie der Standard. Was erhoffst du dir davon? Wir der überhaupt genutzt? Gib es Einschränkungen? Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. Mai 2022 Melden Teilen Geschrieben 9. Mai 2022 vor 45 Minuten schrieb tesso: Du hast jetzt ein Neuen Connector gebaut mit den gleichen Eigenschaften wie der Standard. Nein, es ist zusätzlich Authentifizierung von Nutzern erlaubt. Was total überflüssig wäre, wenn man einfach den Default Client Frontend nutzen würde. Der ist nämlich genauso konfiguriert (nur ohne Anonyme Nutzer). Aber er sucht halt gern ;) Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 9. Mai 2022 Melden Teilen Geschrieben 9. Mai 2022 vor 1 Minute schrieb NorbertFe: Nein, es ist zusätzlich Authentifizierung von Nutzern erlaubt. Was total überflüssig wäre, wenn man einfach den Default Client Frontend nutzen würde. Der ist nämlich genauso konfiguriert (nur ohne Anonyme Nutzer). Aber er sucht halt gern ;) Irgendetwas scheint dort verbogen zu sein. Der DefaultFrontend würde im Standard doch Anfragen von allen IPv4 und IPv6 Adressen annehmen. Hier scheint das ja anders zu sein. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. Mai 2022 Melden Teilen Geschrieben 9. Mai 2022 Am 6.5.2022 um 17:22 schrieb vonAbisZ: welchen ich soeben als Test verwendet habe, unter den Remoteadressen NICHT aufgeführt ist?! Du machst es einem echt schwer, dir zu helfen. 1. Wie wärs, wenn du statt unnötiger Screenshots, auf denen dann auch nur die Hälfte der Infos erkennbar ist, einfach per Powershell mal alle Connectoren und die RELEVANTEN Infos hier listest. 2. Offenbar wurde schon viel an den Connectoren geschraubt, denn deine Beschreibungen lassen eigentlich keine andere Schlussfolgerung zu, dass da jemand den Überblick verloren hat. 3. Ist das Logging auf den Frontend Connectoren aktiv, dann würde man nämlich sehen, über welchen Connector dein Fileserver einliefert. Lösung könnte auch sein, dein Skript einfach auf dem Fileserver laufen zu lassen. 4. Der Hinweis auf externe Hilfe dient im Allgemeinen dazu, dir ewiges Suchen und nen Haufen Fehlkonfigurationen zu ersparen. Ich denke, dass das für jemanden der sich auskennt eine Sache von ca. ner halben STunde ist. vor 2 Minuten schrieb tesso: Der DefaultFrontend würde im Standard doch Anfragen von allen IPv4 und IPv6 Adressen annehmen. Hier scheint das ja anders zu sein. Es fehlen mit Sicherheit die IPv6 Adressen, weil jemand meinte er weiß besser, was er tut. ;) Und wenn man dann weiß, dass sich Exchange per Default mit IPv6 unterhält, erklärt das auch, warum es lokal nicht funktioniert. Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 9. Mai 2022 Melden Teilen Geschrieben 9. Mai 2022 vor 22 Minuten schrieb NorbertFe: Es fehlen mit Sicherheit die IPv6 Adressen, weil jemand meinte er weiß besser, was er tut. ;) Und wenn man dann weiß, dass sich Exchange per Default mit IPv6 unterhält, erklärt das auch, warum es lokal nicht funktioniert. Die Vermutung habe ich auch. Ich fürchte nur das dort noch mehr verstellt wurde. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. Mai 2022 Melden Teilen Geschrieben 9. Mai 2022 Siehe 2. im Post über dir. Zitieren Link zu diesem Kommentar
vonAbisZ 2 Geschrieben 9. Mai 2022 Autor Melden Teilen Geschrieben 9. Mai 2022 Lieber Tesso Du hast mir einerseits geschrieben: "Hol dir jemanden der sich mit Exchange auskennt. " Meine Antwort war dann: Oha, jetzt aber. Danach hast Du mir diese Frage gestellt: "Hat der neue Connector auch das Recht anonymes senden? Welche Einschränkungen sind gesetzt?" Diese Frage erweckt bei mir den Eindruck, dass es Dich doch irgendwie interessiert, wo das Problem liegen könnte, sonst hättest Du mir wohl im Anschluss an deine, vorherige Aussage nicht mit dieser Frage konfrontiert? Für das Interesse bedanke ich mich natürlich sehr und hoffe, dass wir doch noch den Grund herausfinden Einer, deiner Aussagen war auch: "Per Forum ist die Fehlversuche echt mühsam." Meine Antworten darauf waren: Wie kommst Du denn jetzt plötzlich zu diesem Schluss? Dann bist Du wohl hier nicht ganz am richtigen Ort? Du hast mich soeben gefragt: "Wie lange suchst du nun schon?" Meine Antwort darauf: Ach so, Du beziehst deine Aussage demnach auf mich, von wegen: "per Forum sei die Fehlersuche echt mühsam". Wie willst Du wissen, ob für mich hier im Board die Fehlersuche echt mühsam ist? Vielleicht mag die Suche für dich in solchen echt mühsam sein? Du musst/ solltest aber nicht automatisch von Dir auf andere schliessen, ok? Wäre es für mich mühsam, warum tue ich mir denn diese Sache an? Keine Sorge, ich bin gross und alt genug und weiss selber, wann es mühsam wird oder nicht *grins* Des Weiteren sind solche Diskussionen, wie Du Sie gerade angezettelt hast, nicht Lösungsorientiert und sorgen schlussendlich unnötig dafür, dass sich ein Blog wie dieser unnötig, wie ein Kaugummi in die Länge zieht. Für Lösungsorientierte Hilfestellungen bin ich willkommen, danke euch allen schon jetzt für euren Einsatz, das schätze ich extrem. Ich bin natürlich auch daran interessiert, auf eure Fragen die Antworten zu liefern, welche Ihr braucht. vor einer Stunde schrieb tesso: Du hast jetzt ein Neuen Connector gebaut mit den gleichen Eigenschaften wie der Standard. Was erhoffst du dir davon? Nein, ich habe keinen neuen Empfangsconnector gebaut. Lieber Tesso, den Screenshot, welche ich vom bestehenden Empfangsconnector hier abgebildet hatte, sollte für euch alle als Hilfestellung dienen. Mein Ziel ist nach wie vor und war auch nie ein anderes, dass Ihr ALLE, welche mir netterweise Hilfestellung anbietet, möglichst viel Infomaterial von mir erhält und somit wisst, was auf unserem Exchange wie eingestellt ist Und: Somit hoffentlich, im Gegensatz zu mir, wisst, warum ich direkt vom Exchange aus und anscheinend nur direkt, lokal vom Exchange aus, keine Mails versenden kann. Darum habe ich ja nun als Umgehungslösung auf dem Fileserver eine Aufgabenplanung erstellt und dort lasse ich die Aufgabenplanung mit dem lokalen System User ausführen und voilà, die Aufgabe wird ausgeführt und dadurch wird auch erfolgreich ein PS Skript angestossen, welches die User*innen darüber informiert, wann ihr AD Passwort abläuft. Der User winmadness hatte letzten Mittwoch, um 13:42 mich folgendes gefragt: "Hast Du auch einen extra Empfangsconnector angelegt und mit diesem getestet?" - siehe mein Beitrag. Auf Grund dieser Aussage wollte ich dann eben einen neuen, separaten Empfangsconnector erstellen und nur den anonymen Zugang erlauben. Da aber anscheinend auf unserem Exchange Server eben wie oben im Screenshot schon ein benutzerdefinierter Empfangsconnector irgendwann erstellt wurde (auch bereits so konfiguriert, dass unteranderem der anonyme Zugriff geregelt ist), motzte natürlich dann unser Exchange Server und sagte, es existiere schon ein Empfangsconnector mit dieser Einstellung. Dieser benutzerdefinierte Empfangsconnector ist schon längere Zeit im Einsatz, ob der benutzt wird? Gute Frage, wie teste ich das am schnellsten und einfachsten? LOG Funktion aktivieren und prüfen, ob ich dann im Pfad (welcher Pfad wäre es?) dann mehr Hinweise finde oder? Und noch als Ergänzung: Da ich quasi nun für meine Aufgabenplanung einen Workaround gefunden habe und der PS Skript erfolgreich Mails versendet (wie ein paar Zeilen weiter oben geschildert), wäre eigentlich für mich die Situation soweit erledigt. Jedoch verfolgt mich dieses Problem/ die Tatsache, dass man anscheinend auf unserem Exchange Server direkt, lokal von diesem Server aus keine Mails versenden kann erneut. Denn wenn ich auf dem Exchange Server die Antivirenlösung aufrufe, welche als Antivirenschutz für den Exchange Server 2016 dient und die Benachrichtigung einstelle, damit unser Exchange Server z.B. an unser ICT-Team Info Mails sendet, klappt dies auch nicht. Das heisst nun zusammengefasst: - Konfiguriere ich eine Aufgabenplanung lokal auf dem Exchange und sage der Aufgabenplanung, hey, verwende für das Ausführen der Aufgabe den lokalen Exchange System User (NT-Autorität\System), kann der PS Skript, welcher durch die Aufgabe ausgeführt wird, KEIN Mail versenden. wie erwähnt, hierfür habe ich zurzeit einen Workaround, habe auf dem Fileserver das gleiche Vorgehen gewählt, eine Aufgabe erstellt, wieder den lokalen System User NT-Autorität\System verwendet und siehe da, das PS Skript wird ausgeführt, der Mailversand funktioniert. - Aber ich habe nun auch das Problem, dass eben in der Antivirenlösung, direkt auf dem Exchange in den Benachrichtigungseinstellungen der Mailversand (es gibt einen Test Knopf, wo man den Mailversand testen kann), nicht funktioniert. Hier habe ich einen AD User Hinterlegt (hat keine speziellen Rechte) und das Passwort, aber eben, klicke ich den Test Buton, kommt die Fehlermeldung: "Die Testnachricht konnte nicht gesendet werden. Details finden Sie im Ereignisprotokoll des Programms". Die Frage ist nun, macht es Sinn, wenn ich euch hierzu weitere Infos liefere, da es sich ja um ein anderes Problem handelt, als das Problem, für welches ich ursprünglich hier den Post eröffnet hatte oder wie? Im Ursprung habe aus meiner Sicht beide Probleme eine Gemeinsamkeit Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 9. Mai 2022 Melden Teilen Geschrieben 9. Mai 2022 Ich bin raus. Zitieren Link zu diesem Kommentar
vonAbisZ 2 Geschrieben 9. Mai 2022 Autor Melden Teilen Geschrieben 9. Mai 2022 vor 2 Stunden schrieb NorbertFe: Du machst es einem echt schwer, dir zu helfen. 1. Wie wärs, wenn du statt unnötiger Screenshots, auf denen dann auch nur die Hälfte der Infos erkennbar ist, einfach per Powershell mal alle Connectoren und die RELEVANTEN Infos hier listest. Aber hier fängt es doch schon an? Ich bin zurzeit in der Rolle des Kunden, des Users, welcher Hilfe anfordert. Du schreibst mir, ich solle die RELEVANTEN Daten liefern via Powershell. Wie soll ich nun bitte sehr wissen, was für dich relevant ist? Schreib doch einfach, was Du brauchst. Was für dich relevant ist, ist für mich vielleicht nicht relevant, verstehst Du? [PS] C:\>Get-ReceiveConnector Identity Bindings Enabled -------- -------- ------- UnserExchangeServer\Default UnserExchangeServer {0.0.0.0:2525, [::]:2525} True UnserExchangeServer\Client Proxy UnserExchangeServer {[::]:465, 0.0.0.0:465} True UnserExchangeServer\Default Frontend UnserExchangeServer {[::]:25, 0.0.0.0:25} True UnserExchangeServer\Outbound Proxy Frontend UnserExchangeServer {[::]:717, 0.0.0.0:717} True UnserExchangeServer\Client Frontend UnserExchangeServer {[::]:587, 0.0.0.0:587} True UnserExchangeServer\Anonymous Relay UnserExchangeServer {192.168.x.y:25} True Soll ich nun für jeden Connector die Details auflisten? Das wird dann viel Material geben, nur so zur Warnung vor 2 Stunden schrieb NorbertFe: 3. Ist das Logging auf den Frontend Connectoren aktiv, dann würde man nämlich sehen, über welchen Connector dein Fileserver einliefert. Lösung könnte auch sein, dein Skript einfach auf dem Fileserver laufen zu lassen. Genau, ich habe schon mehrmals erwähnt, dass ich zurzeit hierfür eine Umgehungslösung umgesetzt habe, nämlich den Skript einfach auf dem Fileserver laufen zu lassen. Das funktioniert so. Bei welchem Empfangsconnector das Login aktiv ist, müsste ich erst prüfen und in einem zweiten Schritt dann natürlich die Logfiles des entsprechenden Empfangsconnector auslesen. vor 2 Stunden schrieb NorbertFe: 4. Der Hinweis auf externe Hilfe dient im Allgemeinen dazu, dir ewiges Suchen und nen Haufen Fehlkonfigurationen zu ersparen. Ich denke, dass das für jemanden der sich auskennt eine Sache von ca. ner halben STunde ist. Kann sein, ich weiss es nicht. Für mich ist das Problem nicht dringend, ansonsten hätte ich längstens zu dieser Massnahme gegriffen. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.