RobertWi

Spam-Versender nutzen kein Telnet und brauchen das auch nicht. Die brauchen ein offenes Relay. Und das musst Du schließen. Wenn Du daheim zu viel Werbung bekommst, kommst Du ja auch nicht auf die Idee, dem Briefträger die Tasche wegzunehmen, sondern hängst ein Verbot an Deinen Briefkasten. Also: Mach das Relay zu und halte Dich nicht mit Telnet auf.

Moin, Telnet sperren hilft Dir ja nicht wirklich, weil es nicht das Problem löst. Dein Basis-Problem ist NICHT, dass Client Spam senden - Dein Problem ist, dass sie Spam senden DÜRFEN. Und das bekommst Du nicht mit Aktionen beim Client geregelt. Lies den letzten Satz in meiner Signatur und denk nach mal darüber nach, das Problem richtig anzugehen (wobei ich immer noch nicht wirklich verstanden habe, was Du wirklich für ein Problem hast, Du aber vermutlich auch nicht).

Moin, Korrekt. Wobei Du im zweiten Fall wählen kannst, ob mit Cache oder ohne. Zeig doch den Leuten einfach, wie die Fehlermeldung aussieht, wenn Du bei Ol2007 ein weiteres Exchange-Postfach hinzufügen willst und wie die Meldung bei Ol2010 lautet. ;) Aber wenn Du es unbedingt von MSFT brauchst: Die zehn wichtigsten Gründe, Outlook 2010 zu testen - Outlook - Office.com -> gleich der erste Punkt. BTW: Du bist der bezahlte Fachmann, wenn man Dir nicht glaubt, läuft da irgendwas schief, finde ich. Wie vermutet. Aber das Programm ist ja gut geeignet, ein paar Vergleiche zwischen den Versionen anzustellen.

Moin, mit der Einstellung kann jeder einliefern, wie Günther schon schreibt, kann man das mit Remote-IP-Adresse einschränken. Nichtsdesto trotz protokolliert der SMTP-Connector aber die Verbindungen inkl. IP-Adressen.

Moin, was sagt denn "Get-RemoteDomain" aus? Gibt es die von Dir erwähnten drei Domänen da überhaupt?

Moin, das was Du meinst, nennt sich Domain Security und kann Exchange seit 2007 auch endlich mal. Du brauchst dafür natürlich pro Richtung ein Zertifikat, das gegenseitig ausgetauscht wird. Das geht natürlich auch, muss aber explizit konfiguriert werden, den im Normalfall kenne ich ja meinen Gegenüber nicht, weil es bei jeder Domain ein anderer Server ist. Das ändert aber nichts daran, dass ich nicht weiß, was Postfix braucht, damit er das Zertifikat von Exchange als vertrauenswürdig akzeptiert. Exchange wird Dir zum Beispiel jedes Mal eine Warnung generieren, wenn das Zertifikat vom Postfix für Exchange nicht vertrauenswürdig ist, wird es aber trotzdem benutzen (glaube ich zumindest, kann aber auch sein, dass Exchange das trotzdem nicht nimmt). Domain Security muss übrigens in der EMS konfiguriert werden, weil das Zertifikat dem Connector zugeordnert werden muss, das geht in der EMC nicht. Aber das steht alles in meinem Link oben.

Ach so: Und Geduld haben. Die Replikationen können problemlos mehrere Stunden dauern (obwohl eigentlich nichts in den Ordner ist).

Da du oben was von DAG schreibst, musst Du ja einen Hardware-Loadbalancer davor haben. Der könnte auch wieder was filtern.

Moin, im Prinzip liegt es daran, dass die Public Folder - Hierarchy in AD gespeichert ist. Dort steht also die Information, welche Ordner es überhaupt gibt. Wenn ein Server eine ÖO-DB hat, dann holt er sich davon eine Kopie und sobald er ein Replikat hat, hat er auch Inhalte. Mit dem ersten Befehl fragst Du Exchange "allgemein", der schaut "aus Faulheit" ins AD und sagt Dir, was dort steht. Mit dem zweiten Befehl willst Du aber die Info vom Server haben -> das knallt, weil es dort gar keine ÖO-DB gibt, also keine lokale Kopie der Hierarchy Leg eine ÖO-DB an und nach der Replikat der Hierarchy, kannst Du plötzlich auch die Ordner sehen. Und nach dem Du hinter die Ordner ein Replikat gesteckt hast, kannst Du dann auch mal Inhalte sehen. (ok, bei Dir nicht, weil es nichts zum Replizieren gibt). In Outlook könntest Du das auch nachvollziehen: - keine DB -> Fehler bei der Anzeige der ÖO - DB -> leere Ordner - Replikate -> Ordner mit Inhalt Das alles ist auch der Hauptgrund, warum es jeden Ordner innerhalb einer Exchange-Organsation nur einmal geben kann.

Moin, na ja, wichtig wäre zum Beispiel die Info, wo die Rolle Hub Transport läuft - CAS ist für SMTP unwichtig. Dann schreibst Du "taucht eben nirgends auf". Glaube ich nicht, steht mindestens im SMTP-Protokoll, wenn das Ding bei Exchange landet. Kann ich aber nicht nachvollziehen, weil ich nicht mal weiß, ob Du da überhaupt aufrufst (eine Kopie des gesamten telnet-Vorganges wäre sinnvoll). Zum Beispiel kann ein normaler Client in der Standard-Installation nicht mit Telnet (so einfach) senden. Was wurde bei Euch verändert (bzw. wie sind die Empfangs-Connectoren konfiguriert).

Moin, dann würde ich sagen, dass die Mail nicht direkt über Exchange kam. Ansonsten ist das mit den spärlichen Informationen nur Glaskugellesen...

Moin, offensichtlich akzeptiert Postfix das Zertifikat von Exchange nicht. Dann müssen wir jetzt auf einen Fachmann für Postfix warten, der erklärt, ob man zwingend ein korrektes Zertifikat in Exchange braucht oder ob man in Postfix die Prüfung auch deaktivieren kann - und was das leichtere von beiden ist.

Moin, zwischen Bildschirm und Rückenlehne.... :p Tipp: Fehlermeldung richtig lesen:

Moin, wie lautet denn der Fehler in den Protokollen (bei Postfix und Exchange), wenn Du mit TLS senden willst?

Moin, außerdem kann man verschiedene Domains beim IIS nicht auf einer IP-Adresse unterscheiden, da der Hostheader verschlüsselt ist. Daher landet alles, was auf einer IP eingeht, immer auf eine Site - egal welche Domain benutzt wird (das ist aber per Apache erstmal nicht anders - ohne Erweiterung). Wie Norbert schon schrieb, brauchst Du entweder zwei IP-Adressen oder Du musst eine Firewall davorstellen, die SSL Offloading macht und dann nach Hostname weiterleitet. Andere Varianten funktionieren nicht, weil Du die Clients nicht dazubekommst, einen anderen Port zu nutzen. Nicht mal OWA geht dann, weil OWA den anderen Port nicht in den URLs unterbringt (dann müsste wieder eine Firewall davor die URL-Rewriting macht). Was Du beschreibst ist ein durchaus übliches Problem bei kleinen Kunden mit nur einer IP-Adresse, für das es technisch keine einfachen Lösungen gibt und exchange-seitig gar keine.

Moin, außerdem ist ein anderer Port als 443 nicht supportet und in bestimmten externen Programm auch gar nicht konfigurierbar (Active Sync, Outlook Anywhere).

Moin, ich persönlich habe bei einem Kunden eine Art "Web Service" implementiert. Er ruft aus seinem System (Linux mit Perl) eine spezielle Webseite auf, SSL-verschlüsselt und übergibt festgelegte Parameter. Über eine Mini-ASP.NET-Seite (die nur als Wrapper dient), wird dann das PowerShell-Script aufgerufen, dass die Befehle ausführt. Wie man sieht: Es gibt mehrere Lösung, um ans Ziel zu kommen. Wie gesagt: In der Theorie einfach.

Moin, in der Theorie: Ja, dass sollte gehen - mit PowerShell 2.0 und WinRM danke Remoting sogar von jedem beliebigen Windows-IIS aus. in der Praxis: Da sind einige Dinge zu beachten, vor allem im Berechtigungskonzept und damit man sich keine Sicherheitslücken auf dem Server reißt.

Moin, bei SBS hast Du dafür Assistenten, da musst Du nichts in Exchange verbasteln. Günther wird sicher bald dazukommen und sagen, welcher Assistent das ist. Allerdings kann ich Dir zumindest sagen, warum Dein Befehl oben nicht geht. Wenn Du Dir mit Get-WebServicesVirtualDirectory angeschaut hättest, wie das Verzeichnis heißt, dann wäre Dir aufgefallen, dass es sich EWS (Default Website) nennt - hier hat der Übersetzung-Teufel zugeschlagen. Und wenn Du Dich dann auch noch mit der PowerShell näher beschäftigen würdest, dann würdest Du wissen, dass es mit dem Befehl Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl https://mail.contoso.com/ews/exchange.asmx vollkommen egal wäre, wie das Verzeichnis heißt. Der funktioniert immer und mit jedem Namen. ;) Aber wie gesagt: Beim SBS gibt es dafür Assistenten, darum sind Aktionen direkt in Exchange von meiner Seite aus ohne Gewähr (sie sind aber technisch richtig, nur in SBS eventuell der falsche Weg).

Moin, dann lies Dir meine Links durch, findest Du alle Informationen musst nur nach Ex2007/2010 "filtern".

Moin, die Exchange-Server und Outlook-Version wäre schön. Speziell mit Ol2010 sind freigegebene Postfächer deutlich schöner, als öffentliche Ordner. Hier ist was zum Lesen: MSXFAQ.DE - Mailboxrechte MSXFAQ.DE - Senden als MSXFAQ.DE - Stellvertreter mit Outlook

Moin, eine PST-Datei kann nur von einem Client gleichzeitig geöffnet werden. Mehrere gehen da nur mit "Bastellösungen", z.B. Public ShareFolder: Outlook im Netzwerk ohne Exchange PST Dateien im Netzwerk gemeinsam nutzen Public ShareFolder gruppenkalender gruppenterminkalender netzwerkkalender teamkalender outlook groupware terminverwaltung gemeinsamer zugriff ffentlicher t

Moin, das könnte helfen: Download: Microsoft Exchange Server User Monitor - Microsoft Download Center - Download Details

Moin, Auch für WebDAV brauchst Du ein Programm, das ist nur die Schnittstelle. Programmierer gibt es hier IMHO nur sehr wenige, da bist Du vielleicht in einem anderen Forum besser aufgehoben. Was ist denn bei Dir ein "Archivordner"?

Hmmm.... Du nutzt nun also ein Programm, mit dem der Admin sehr komfortabel automatische Antworten einstellen kann. Und das hilft Dir jetzt wie gegen einen Benutzer, der eine falsche Outlook-Regel baut?