RobertWi

Guckst Du hier: http://www.mcseboard.de/ms-exchange-forum-80/exchange-2010-outlook2010-staendige-authentifizierung-noetig-188227.html#post1162517

Moin, gehst Du davon aus, oder hast Du es geprüft und verifiziert? Was findest Du mit "Get-AgentLog" zu diesen Mails heraus` Get-AgentLog ja, siehe den Link von Günther. Siehe hier: Grundlegendes zur Antispam- und Antivirusfunktionalität: Hilfe zu Exchange*2010 Jein. Die IP-Blacklist ist ein Verbindungsfilter, der zuerst angewendet wird und die Verbindung unterbricht. Die einzige Lösung wäre, die IP-Adresse des sendenden Servers auf die IP-Whitelist zu setzen. Ausnahmen sollen aber möglich sein: http://technet.microsoft.com/de-de/library/bb124320.aspx

Hallo Rakli, machen es den Leuten leicht, Dir helfen zu wollen. "event 26" ist ohne Angabe einer Quelle nicht eindeutig und bedeutet außerdem, dass die Leute, die Dir helfen wollen, selbst suchen müssen, wofür das steht. Na ja, und in der Zeit habe ich schon andere Fragen beantwortet. ;) Also: Wie lautet der genaue Text des Events - mit Nummer und Quelle?!

Moin, da hierbei ein fremder Server im Spiel, gibt es keine klare Antwort. Es gibt Header, die erhalten bleiben, und andere nicht (z.B. die Spam-Header). Aber im Allgemeinen würde ich davon ausgehen, dass ein Header nicht erhalten bleibt.

Tja, dass man mit Umlaufprotokollierung im Crash-Fall einen Datenverlust riskiert, erlebst Du nun leider schmerzhaft am eigenen Unternehmen. :(

Moin, so, wie es aussieht, scheint die Datenbank irreparabel geschädigt zu sein. Da wird nichts anderes übrig bleiben, auf ein funktionierendes Backup zurückzugehen. Eventuell lässt sich dann mit einem "Rollforward" und alle notwendigen Log-Dateien ein halbwegs aktueller Stand wiederherstellen, diese Anleitung überschreitet aber die Möglichkeiten eines Forums.

Moin, wenn das wirklich eine Domäne und damit eine Exchange-Organisation ist, dann haben die immer die gleiche Adresslisten. Es gibt Adresslisten (bis auf wenige Einschränkungen) grundsätzlich nur organisationsweit.

Oder einfach "Tresor" ins Suchfeld eintippen. Die Langform heißt "Verwalten Sie Ihre Windows-Anmeldeinformationen".

Moin, die von Dir beschriebenen Änderungen am IIS sind wirkungslos, wenn Du sie nicht mit Exchange machst. Dann werden sie nach wenigen Minuten wieder auf die Exchange-Einstellungen zurückgesetzt. Außerdem betreffen Sie alle Benutzer, auch die die jetzt (noch) funktionieren. Als erstes würde ich mal den Kennworttresor des lokalen Windows leeren. Dann wird beim nächsten Start einmalig nach dem Passwort gefragt.

Wenn Du Dir mal die Hilfe von eseutil /d anschaust, findest Du dort Optionen, die Temp-Dateien an einem anderen Ort zu erzeugen.

Moin, die Policy greift IMHO sofort (im Gegensatz zu manch anderen Einstellungen). Sollte das nicht so sein, wäre die normale Cache-Zeit 2 Stunden. Auf dem Client könnte dann z.B. ein Virenscanner oder ein anderes Dritt-Programm dafür verantwortlich sein. Hast Du noch mehr 2003 im Einsatz? Sonst sperr ihn doch einfach aus, und wenn dann das Problem weg ist, weiß Du das es an dem Client gelegen hat. Nicht nett, aber was bringt es, wenn der eine Client warum auch immer alle Benutzer beeinträchtigt.

Moin, das ist aus der Ferne vermutlich sehr schwer zu lösen, weil da neben Software auch Hardware-Probleme in Frage kommen. Dann ist das noch virtualisiert, mit externen SAN -> wieder zwei mögliche Fehlerquellen. Grundsätzlich klingen Deine Daten gut (d.h. die VM sind leistungsmäßig angemessen). Nun heißt es, vermutlich mit Try&Error andere Komponenten auszuschließen. Als erstes solltest Du Dich mal mit ExMon (MSXFAQ.DE - ExMon) auf die Suche machen, ob Du eventuell Glück hast, und nur ein Client die Probleme verursacht (unwahrscheinlich, dank ThrottelingPolicy).

Allerdings würde ich dafür Ol 2010 nehmen, wobei auch das eigentlich nur für 100.000 Elemente pro Ordner designet ist. Das kann also auch dafür zu viel sein. MFCMapi im Online-Modus wäre noch eine Alternative für den Blick in den Kalender-Ordner: MSXFAQ.DE - MFCMAPI

Und wozu soll das Ding eine Weboberfläche habe?

Die fremden IPs sind doch nur Versuche, Euren Server als Open Relay zu missbrauchen. Funktioniert aber nicht. Wenn der Server per SMTP von außen erreichbar ist, ist es weitgehend normal. Die Versuche habe ich auch regelmäßig im Log.

Moin, wenn Du selbst nicht weiß, in welchem Verzeichnis Du Exchange installiert hast, woher sollen wir das wissen? ;) Mach die EMS auf -> cd $exinstall Dann stehst Du im "Stamm"-Verzeichnis. Dann von da geht es dann weiter nach "bin\CmdletExtensionAgents".

Die, die Langweile haben, können hier noch mal antworten. Der Rest liest dann hier mit: primäre STMP Adresse - Fehler im Autodiscover

Sogar mein Hosting-Provider benutzt für die Maillingllisten dedizierte Server. Das verteilt die Last besser und führt bei Sperrungen nicht zum Totalausfall. Sehr praktisch, wenn man nicht genau kontrollieren kann, wer da alles Newsletter verschickt.

Komplexe Sachen sollte man aber erst machen, wenn die einfachen funktionieren. ;) Mir kommt da gerade eine Idee. Ist die neue Mailbox für einen neuen Benutzer oder für ein bereits bestehendes AD-Konto gewesen?

Ich würde so etwas über separate Server, mit eigener IP-Adresse und eigenem FQDN machen. Das müssen dann auch keine zusätzlichen Exchange-Server sein. Da die eh nur "Smart Host" spielen, reicht da auch ein einfacher QMAIL, o.ä.

Hmmmm.... In meinem (und tessos) Link steht: "Save the file as ScriptingAgentConfig.xml in the \bin\CmdletExtensionAgents folder" Nix mit "Imap-disable.ps1" oder so. Und so, wie in den Links, funktioniert es ja auch. Also muss bei Dir was anders sein. Wie genau sehen Deine Dateien und Einstellungen denn aus?

Gibt es eigentlich einen Grund, warum Du die Anleitungen von mir und tesso ignorierst und selbst "rumspielst"?

Wie Norbert schon schreibt, ist das einfach. Ich persönlich würde Newsletter aber nicht über die normale Infrastruktur machen. Die Gefahr ist zu groß, dass das jemand übel nimmt, den Server auf eine Blacklist setzt und ich dann auch keine normalen Mails mehr durchbekomme. Newsletter sind per Definition hochgradig Spam-verdächtig und sollten daher sauber getrennt werden.

Es würde uns übrigens die Arbeit sehr erleichtern, wenn Du auf die Dir gestellten Fragen und Posts eingehen würdest. Nicht vergessen: Du hast das Problem und möchtest, dass wir Dir helfen. Also mach uns die Hilfe einfach. ;)

Probier das mal über die Shell mit "New-Mailbox" und setze dabei den Schalter "-verbose". Dann müsstest Du die Ausführung sehen können.