Jump to content

Markus Butz

Members
  • Gesamte Inhalte

    248
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Markus Butz

  1. Hallo Götz, Jo, geht einwandfrei mit einem Connector. :-) Jetzt noch den AUTD so zum Laufen bekommen, dass der auch noch nach 5 Minuten abgleicht.... vermute mal, dass da eine TCP Verbindung geschlossen wird... das werde ich aber auch noch finden... Danke nochmal... Bis bald! Markus
  2. Hallo Götz, ich habe jetzt auf Smarthost umgestellt, mal alle Richtlinien rausgeschmissen etc. und alles neu gemacht dort. Dann genau nach KB eine zweite Richtlinie angelegt mit der nicht authoritativen Domain (Hauptdomain) drin sowie einem zweiten Connector, der nur für diese nicht authoritative Domain zuständig ist und unter "Adressraum" entsprechend "Weitergabe von Nachrichten an diese Domänen per Relay erlauben" aktiviert hat. Der andere Connector hat unter "Adressraum" ein * aber das "Weitergabe von..." ist nicht aktiviert. IST DAS SO ALLES RICHTIG? Laut KB sollte es danach gehen. Ich musste aber erst noch in den Empfängerrichtlinien "Diese Richtlinie jetzt anwenden" und unter "Empfängeraktualisierungsdienste" den Punkt "Neu erstellen" auswählen (ich weiß nicht, welches davon jetzt ausschlaggebend war...). Erst dann wurden die Richtlinien richtig auf die AD Benutzer angewendet und auch die Adresse der Hauptdomain aus der zweiten Richtlinie erschien bei den AD-Benutzern. Ab dann funktionierte es. Wobei ich es etwas seltsam fand, dass nach meinem Kontroll-Neustart Nachrichten zunächst einige Minuten in den Warteschlangen im Ordner "Nachrichten warten auf Routing" lagen, bevor diese geroutet werden - sei es ein- oder auch ausgehend. Ist das normal, dass das nach einem Start einige Minuten dauert? Sehe keine Fehler in den Protokollen... Ich hoffe, dass es das jetzt war... das Hauptproblem dürfte bisher immer gewesen sein, dass sich die Richtlinien nicht richtig auf die AD-Benutzer übertragen haben weil ich nicht "Neu erstellen" etc. ausgewählt hatte... die Einstellungen hatte ich sicher auch vorher schonmal richtig... Wann muss man denn "Neu erstellen" oder "Jetzt anwenden?". Das steht nirgends in einer KB oder sonst wo. Wie auch immer... ich beobachte das jetzt die nächsten Tage, bedanke mich SEHR für Deine Hilfe (melde Dich, wenn Du mal in Fulda bist, hast was gut!)... Wäre nett, wenn Du mir noch kurz antworten könntest... Danke... Markus
  3. OK, das stelle ich dann morgen mal um. Trotzdem nochmal zum Hintergrund... was passiert theoretisch, wenn ich es so lassen würde? Ist es ja, gibt aber trotzdem NDRs. Ändert sich das Verhalten beim Senden über Smarthost? Danke... Gruß Markus
  4. Hi... Super, danke an Euch beide... mehr wollte ich gar nicht wissen... Gruß Markus
  5. Hallo zusammen! Nur eine ganz kurze Frage: Mal angenommen, ich richte einen öffentlichen Ordner mit Mail-Adresse ein und habe nun verschiedene Benutzer, die dort Mails lesen dürfen. Kann ich dann erkennen, wer die Mail wann bearbeitet oder eingesehen hat? Wäre ganz praktisch, wenn sich mehrere Benutzer einem zentralen Mail-Eingang bedienen... oder sollte der Benutzer sich die Mail einfach zu sich verschieben? Gruß Markus
  6. Hallo zusammen, @weg5st0: :-) Gut, die Problematik war mir an sich schon klar... aber ich hatte wohl noch einen Verständnisfehler drin. Also ist es so, dass wie Du meintest z.B. T-Online eine Mail von mir mit meiner statischen Sender-IP entgegennimmt, er ein Reverse-DNS macht und sieht, dass das nur der (MX)-Server für die Hilfsdomain ist und dies nicht mit dem für die Absende-Adresse der Hauptdomain zuständigen MX-Server übereinstimmt? Oder wie ist der Ablauf? Und was sind die Konsequenzen? Dass T-Online das als Spam filtert? Im Moment läuft das jetzt noch so und eigentlich ohne Probleme... wobei ich T-Online jetzt nicht explizit geprüft habe...?! Also das geht bei Schlund, habe ich schon des öfteren genutzt und tue es an einigen Stellen noch immer. Anmelden mit beliebigem Konto, danach darf ich - so meine ich - für alle bei Schlund registrierten Domains relayen... auf jeden Fall aber für alle Adressen der Domain, für die ich mich anmelde. Das entfällt ja dann... @PanFloete: Ja, das frage ich mich mittlerweile auch. Ich hatte es nur gut gemeint und wollte auf der einen Seite POP-Connectoren umgehen und auf der anderen Seite konnte ich nicht alle Adressen auf direkte Einlieferung umstellen. Deshalb dachte ich, ich leite einige Adressen an die Hilfsdomain und diese wird dann direkt eingeliefert. Das oben angesprochene Problem war mir da noch nicht so ganz klar. Jetzt aber die Frage an Euch beide, wie ich am besten weiter vorgehe... Ich sehe ein: Der Direkt-Versand sollte wohl auf Versand über den Schlund Smarthost umgestellt werden. Hilfsdomain abstellen und mit POP-Connector doch direkt von der Hauptdomain holen? Das löst mein Problem mit dem geteilten Adressraum (teils im Exchange, teils nicht) ja aber auch nicht wirklich, da sich die Richtlinien ja auch nicht anders verhalten... oder bleibt es als Lösung bei: ?? Danke schonmal... Gruß Markus
  7. Hallo Götz, Nochmal kurz zur Strukur, wie ich diese aktuell habe. Es gibt @hauptdomain.de. An diese Domain schreiben Kunden. Hier gibt es 30 POP-Boxen sowie 5 Weiterleitungen zu @hilfsdomain.de. Der MX für die Hauptdomain ist also der Schlund Server. Der MX für die Hilfsdomain ist der Exchange Server. Unterm Strich hat das den Effekt, dass der Kunde an @hauptdomain.de schreibt, der Großteil der Postfächer direkt in die POP-Boxen bei Schlund sortiert wird und 5 Adressen durch die Umleitung auf die Hilfsdomain direkt auf dem Exchange landen. (Hintergrund ist eine Umstellung Schritt für Schritt, die POP-Boxen werden immer mehr wegfallen und durch den Exchange ersetzt werden.) Nochmal kurz zum Verständnis der Richtlinien: Ich brauche jetzt eine Empfänger-Richtlinie @hilfsdomain.de, denn ohne diese funktioniert die eingehende Zuordnung nicht, richtig? Ich brauche eine Empfänger-Richtlinie @haupdomain.de, NICHT "zuständig" aber als Hauptadresse, denn sonst sende ich unter der falschen Adresse. Die Hilfsdomain soll ja nirgends auftauchen. Fazit: Wenn also jetzt der Exchange eine firmeninterne Mail an einen Benutzer @hauptdomain.de schreibt, der KEIN Exchange-Benutzer ist, muss dies im POP-Postfach der Hauptdomain landen. Bist Du nach dieser Erklärung noch immer er Meinung, dass ich einen 2. Connector anlegen muss? Was ich nicht verstehe: Warum muss das ausgehend unbedingt über einen Smarthost laufen? Ich meine, das könnte doch auch per DNS direkt zugestellt werden... Verstehst Du, wie ich das meine? Gruß Markus
  8. Hallo weg5st0, danke für Deine Antwort. Nun: Ich habe im Moment nur einen Connector, der direkt ohne Smarthost versendet. Läuft auch einwandfrei. Der MX für meine Domain zeigt direkt auf den Exchange Server, nicht auf den Schlund Server! Mein Gedanke, einen Smarthost zu verwenden, bezieht sich nur auf diverse Tips hier im Board, im Falle einer Mail-Adressraum-Aufteilung (eine Domain an mehreren Standorten mit dem Effekt, dass ich nicht untereinander verschicken kann, da der Empfänger lokal im Exchange ja nicht existiert und es einen NDR gibt) im "Virtuellen Standardserver für SMTP" (NICHT im Connector) unter "Nachrichten", "Alle E-Mails nicht mit ausgewerteten Empfängern weiterleiten an Host" einen Smarthost einzutragen. Und hier funktioniert nunmal die Auth. nicht (ja, ich habe es im Reiter Übermittlung korrekt eingetragen), weil Exchange es gar nicht erst probiert! Generell ist dies ja aber laut Board-Tips und GuentherH die schlechtere der vorhandenen Möglichkeiten. Empfohlen wird ja, es über die Richtlinien zu machen, so wie im erwähnten MS KB Artikel beschrieben. Dort ist standardmäßig eine Richtlinie. Die .local ist "zuständig". Im Moment ist noch die "richtige" Domain zusätzlich in der Richtlinie mit drin. So funktioniert der Empfang und das Senden unter der richtigen Adresse. Aber es funktioniert eben nicht, einem NICHT IM LOKALEN EXCHANGE vorhandenen Benutzer der selben Domain eine E-Mail zu senden (NDR). Laut KB-Artikel soll nun zur Teilung des Adressreums eine zweite Richtlinie angelegt werden. Dies habe ich genau so getan wie vor 5 Postings beschrieben. Aber das kann doch nicht funktionieren, da die Einträge einer zweiten Richtlinie nicht bei meinen AD-Benutztern landen und diese dementsprechend weder senden noch empfangen können? Ich verstehe das einfach nicht. Was ist denn an meinem beschriebenen Vorgehen soo falsch? Ich mache es doch zu 100% wie in der KB beschrieben?! Gruß Markus
  9. Hallo weg5st0, im Prinzip stimmt das mit den zwei Problemen, wobei sich diese ja auf zwei verschiedene Ansätze beziehen. Punkt 2 von Dir betrifft mein Problem bzw. meinen Ansatz, nicht bekannte Empfänger über "Übermittlung" / "Ausgehende Sicherheit" an einen SMTP-Server von Schlund zu verschicken. Hier findet aber keine Authentifizierung statt, auch wenn ich die Anmeldedaten für den Schlund-Server entsprechend hinterlege. Also klappt das Senden an Schlund nicht, da kann ich logischerweise machen, was ich will. Und ich stelle jetzt einfach die Frage, warum die Auth. nicht stattfindet. Mehr als die Daten eintragen kann ich ja nicht. (Wie gesagt, ich habe nachvollzogen, dass Exchange es wirklich nicht probiert, es handelt sich also nicht um falsche Daten oder ähnliches). Punkt 1 von Dir bezieht sich auf Ansatz B von GuentherH, welcher sich ja wiederrum auf einen KB-Artikel bezieht. Dieser besagt, eine neue Richtlinie anzulegen. So, wie ich das im vorletzen Posting beschrieben habe. Und das verstehe ich nicht: Die Adressen aus der zweiten Richtlinie werden doch gar nicht in das AD übernommen, können also auch nicht als Absender benutzt werden?!? Aber das ist doch das Ziel: Einen Adressraum zu teilen, von dem aus ich auch sende?? Die Adressen aus der 2. Richtlinie laut KB müssten doch erscheinen, oder? Mache ich bei meinem Vorgehen einen Fehler? Danke!! Markus
  10. Hallo noch einmal, mein Problem besteht noch immer... ist meine Frage einfach zu ****? Wäre nett, wenn Ihr mir nochmal einen Tip geben könntet. Danke! Markus
  11. Hmmm.... wo könnte mein Denkfehler denn sein? Wäre nett, wenn Ihr nochmal einen Tip hättet. Danke...
  12. Hallo, habe hier ein sehr ernstes Problem mit einem Produktivserver auf Windows 2003 R1 SP0: Beim Hochfahren erscheint: lsass.exe - Systemfehler "Das Endpunktformat ist unzulässig". OK wird angeboten, danach startet der Server neu. Was ich bisher gemacht habe: - Letzte bekannte Konfiguration: ohne Erfolg - Austausch der Datei msvcrt.dll: ohne Erfolg Der abgesicherte Modus läuft einwandfrei. Hat jemand eine Idee, was hier passiert ist und wie ich das in den Griff bekomme, ohne die Nacht durchzumachen? Danke... Markus
  13. Hallo, also fangen wir noch einmal von vorne an, irgendwie bin ich wohl schwer vom KP. Wie die Konstruktion mit Haupt- (offizielle) und Hilfs (für die Einlieferung) Domain ist, habe ich ja beschrieben. Bessere Ideen? Dann habe ich mir wirklich ausführlichst die KB-Artikel angesehen... die sind an sich ja nicht schwer zu verstehen und einzustellen aber da tritt bei mir doch schon das erste Problem auf: - In der KB wird beschrieben, dass immer mindestens eine authoritative Domain vorhanden sein muss. Richtig? - Diese kann / sollte bei geteilten Adresseräumen natürlich eine interne Domain sein, z.B. @local o.ä. Richtig? - Diese authoritative Domain soll in die Default Policy eingetragen werden. Richtig? - Und jetzt soll die zu teilende Domain in eine höherpriorisierte eigene Richtlinie. Richtig? Und da beginnt doch das Problem. Jetzt trage ich meine offizielle Domain in eine eigene Richtlinie ein. Bei den Benutzern im AD tauchten doch aber nur die Adressen aus der Default Policy (@local) auf - d.h., dass ich weder unter meiner Hauptdomain senden noch unter meiner Hilfsdomain empfangen kann. Wo ist hier mein Denkfehler? Danke... Markus
  14. Hi, @reinersw: Ja, tu das mal, sehr nett...! @GuentherH: Habe ich getan, geht einwandfrei... habe es aber wieder auf direkt über DNS umgestellt... oder spricht da etwas gegen? Das hatte ich eigentlich auch vor und da bastle ich jetzt schon seit mehreren Stunden rum... habe alles nach KB eingerichtet... irgendwas ist aber trotzdem krumm... Im Moment z.B. sieht es laut Diagnoseprotokoll so aus, dass auch eingehende Nachrichten an @hauptdomain.de über den zweiten neu angelegten SMTP Connector raus verschickt werden sollen und da in der Warteschlange liegen. Eigentlich ja auch logisch, denn der zweite SMTP-Connector ist ja genau für diesen (zu teilenden) Adressraum angelegt... scheinbar schaut er nicht, ob die Adresse im lokalen AD existiert... Irgendwas ist da mit meinen Richtlinien falsch, habe das vorhin beschrieben... wirf bitte mal einen Blick drauf, ob ich da einen Fehler drin habe... Und: Muss ich eigentlich im 2. Connector für den geteilten SMTP-Adressraum unbedingt über einen Smarthost raus? Der andere (Haupt-Connector) geht ja auch direkt über DNS... Danke.. Markus
  15. Ja, das ist mir ja auch alles ganz klar, wirklich. Und da ist ja das Problem. Der externe Server möchte, dass Exchange sich authentifiziert, er tut es aber nicht, obwohl unter "Übermittlung" / "Ausgehende Sicherheit" die Daten von Schlund eingetragen sind. Denn DORT will ich mich ja anmelden, oder? Warum findet keine Authentifizierung statt? Wenn ich unter "Nachrichten" einen Mailserver eintrage, der KEINE Authentifizierung verlangt, läuft es einwandfrei... Markus
  16. Generell stelle ich mich wohl etwas ungeschickt an, auch auf die in How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003 beschriebene Art klappt das alles nicht. Das liegt aber auch irgendwie daran, dass mir irgendwo noch so ein wenig der Zusammenhang fehlt... Vielleicht ist ja auch mein Grundgedanke ganz falsch: - bisher haben die Benutzer Ihre Mail direkt abgeholt per POP für die Adresse username@hauptdomain.de - das soll bei einem Großteil so bleiben, deshalb hier keine Änderung am MX-Eintrag für hauptdomain.de - 5 Adressen weitergeleitet auf neue Domain username@hilfsdomain.de - für hilfsdomain.de die MX-Einträge geändert auf den Ex2003SP2 - es holen jetzt also die meisten Nutzer Ihre Mail noch per POP3, außer den 5, die werden eingeliefert - im Exchange in den Empfängerrichtlinien ergänzt als hauptadresse %1g%s@hauptdomain.de ohne Authoritative Haken -> damit sendet der Nutzer als richtiger Absender - weiterhin ergänzt: %1g%s@hilfsdomain.de MIT Autoritative Haken -> sonst kommen die Mails von draußen, die ja über die Hilfsdomain geleitet werden nicht an - funktioniert soweit fein oder wie würdet ihr das machen? - das Problem ist eben nur, dass ich es ums .... nicht hinbekomme, dass die Exchange User den normalen Unsern, die noch über POP arbeiten, etwas schicken können... ??? Markus
  17. Hmmm, Also da bin ich jetzt gerade zu **** für. Abgerufen wird bei Schlund nichts, es wird direkt eingeliefert. Die Schlund Daten sind also sonst nirgends hinterlegt... Wo stehe ich auf dem Schlauch? Danke... Markus
  18. Hey... @weg5st0: Verstehe die Frage nicht ganz, habe nur den einen Connector und habe den SMTP-Server entsprechend im "Virtueller Standardserver..." eingetragen. @reinersw Nein, bei ausgehender Sicherheit habe ich eigentlich die Anmeldedaten für den SMTP-Server bei Schlund hinterlegt... der kann ja sonst mit nem lokalen Domänenkonto auch nichts anfangen... oder sehe ich irgendwo was falsch? Markus
  19. Ja, auth.smtp.kundenserver.de ist der offizielle SMTP-Server von Schlund, der eben auch Auth. will. Der Server ist aber nicht das Problem sondern das Problem ist, dass Exchange sich einfach nicht authentifizieren will, obwohl ich es angemacht habe! Warum? Gruß Markus
  20. Hallo zusammen, ich habe hier auch die Konstellation, dass die Exchange-Org. NICHT FÜR ALLE Adressen der Domain zuständig sein soll. Genau wie hier: http://www.mcseboard.de/windows-forum-ms-backoffice-31/kein-mailversand-lokaler-domain-internetdomain-demselben-namen-55858.html Also soweit den Zuständigkeitshaken in der Empfängerrichtlinie entfernt. Soweit doch richtig, oder? Dann entsprechend im virtuellen Standardserver unter Nachrichten bei "Alle E-Mails mit nicht ausgewerteten..." den SMTP-Server von Schlund eingetragen (auth.smtp.kundenserver.de), welcher ja Auth. verlangt. So wie das im 5. Posting der anderen Diskussion auch war. Das Problem: Ich habe so wie GuentherH es im 6. Posting gesagt hat bei "Übermittlung" unter "Ausgehende Sicherheit" die Auth. eingestellt, sogar den Server neu gestartet aber ES FINDET DEFINITIV KEINE AUTHENTIFIZIERUNG STATT. Trotz Einstellung. Ich kann das definitiv so sagen, weil ich statt dem Schlund-Server mal einen SMTP-Server auf einer anderen lokalen Maschine eingetragen habe, bei dem ich auf das Protokoll komme und dort wird GAR NICHTS authentifiziert. WARUM??? Dies resultiert natürlich in einer Unzustellbarkeitsnachricht. Mehr als anstellen kann ich es doch nicht oder wo ist noch etwas zu konfigurieren? Danke! Markus
  21. Alles klar, so hatte ich mir das gedacht, danke! Gruß Markus
  22. Hallo zusammen, eine ganz einfache Frage, die sich mit ja oder nein beantworten lässt: Die bei 2003 standardmäßig mitinstallieren Terminal-Dienste "Remotedesktop für Verwaltung", die mir zwei gleichzeitige Verbindungen ermöglichen (ohne Lizenzserver etc.) gehen NUR für Mitglieder der Gruppe Administratoren? Sehe ich das richtig? Wenn nein, Anschlussfrage: In welcher Richtlinie würde ich dem 2003 beibringen, dass in diesem Modus ein normaler Benutzer sich auch anmelden darf? Danke. Gruß Markus
  23. Hallo Christian, es funktionierte noch nicht einmal von der selben Maschine aus. Wie auch immer, ich habe es jetzt mit einer Zertifikat-Anforderung über den IIS Manager gemacht, damit funktioniert es auch (hatte es auch beim testen vorher schon mal getan...) aber ich dachte, dass man es auch flexibler machen kann. Im Moment ist es jetzt so, dass wenn ich auf den Host über den im Zertifikat angegebenen Namen zugreife, es auf jeden Fall ohne Meldung geht (sofern in der Domäne), sonst außerhalb der Domäne oder über falschen Namen eben mit Meldung. So sollte es doch über diesen Weg auch sein, richtig? Aber wie ist das denn beim SBS? Wäre das da ählich oder ist da schon ein "gekauftes" Zertifikat mit bei? Oder würde der auch meckern in bestimmten Konstellationen? Danke! Gruß Markus
  24. OK, danke... Und ich dachte, ich würde es nur nicht finden... Ist ja eigentich auch doof... Gruß Markus
×
×
  • Neu erstellen...