RobertWi

Moin, das kannst Du bei Exchange nur so lösen, wie es VW auch gelöst hat: Die entsprechenden Server zu dieser Zeit runterfahren. Ok, je nach Exchange-Server und Netzwerkinfrastruktur gibt es noch Alternativen (per PowerShell die Funktionen aus- und einschalten, die Firewall zeitgesteuert umkonfigurieren, usw.), aber alles sind nur Bastellösung. Da gibt es nichts eingebautes.

Außerdem wiederhole ich noch mal einen Satz von oben: "Im Innneren ist es doch ein normaler DNS-Server. "Hidden" ist er doch nur beim Zugriff von außen und Deine AD-Zone wirst Du ja hoffentlich so oder so nicht ins Internet replizieren."

Moin, hier ist die web.config auf einem meiner Server: <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <httpErrors> <remove statusCode="403" subStatusCode="-1" /> <error statusCode="403" prefixLanguageFilePath="" path="https://exchange.xxxx.de/owa" responseMode="Redirect" /> </httpErrors> </system.webServer> </configuration> Am IIS7.5 kann es nicht liegen, der ist hier auch. Merkwürdig...

Ich habe es eben nochmal bei mir gecheckt, ist genau so konfiguriert, wir in meinem Blog-Eintrag. Poste doch mal die web.config.

Moin, was genau hast Du eingerichtet und welche Fehlermeldung kommt?

Moin, dann sorge dafür, dass Windows dem Zertifikat fehlerfrei vertraut. Entweder importierst Du das Self-Signed auf den Client und hoffst darauf, dass es funktioniert und sich mit dem nächsten Sicherheitsupdate nicht verändert (Self-signed ist nämlich unsupportet von MSFT). Oder Du installierst Dir eine interne CA und signierst das Zertifikat intern (das wäre supportet).

+1 +1 +1 -1: Das ist sogar kontraproduktiv, dann lieber den Server als Domänen-Mitglied in die DMZ. Der entscheidende Punkt eines Proxys ist der Conten Layer Filter, also das reinschauen in die Pakete aus Ausfiltern BEVOR es den betreffenden Server erreicht. Wenn in diesem Fall des Portforwarding der Server angegriffen wird, befinde ich mich im INTERNEN Netz, hinter der Firewall. Steht der Server in der DMZ gibt es zwischen dem Server und dem internen Netz eine weitere Hemmschwelle. Ganz allgemein müssen wir uns aber immer vor Augen halten, was wir hier wirklich verhindern: Gelegenheitshacker und Script-Kiddies, die bei Aufwand sich lieber ein neues Ziel suchen. Wäre ich Hacker und wollte unbedingt an die Daten der Firma, würde ich nicht hacken. Dann würde ich einen Admin "kaufen". Das ist aber Ende viel einfacher und billiger. ;)

Dann gibt mal bescheid. Ich habe schon viele gute Backup-Programme erlebt, nur bei Recovery scheiterten die dann grandios.

Moin, wenn Du die Autodiscover-Seite im Browser aufrufst, geht das ohne Zertifikatsfehler? Da ihr dort offensicht keine externe URL verwendet, habt ihr das Zertifikat intern signiert oder ist es ein self-signed?

In diesem Fall wird Dir aber jeder mit ein wenig Erfahrung sagen: Das hat nur Nachteile.

Nein, aus dem Log geht leider nichts erquicklich hervor. Du hast nun einen inkonsitenten Zustand auf dem Server, bei dem eigentlich nichts anders, als eine Neuinstallation richtig sauber ist. Du kannst noch probieren, die sog. "Watermarks" zu löschen und dann das Setup mit Upgrade nochmal anwerfen. MSXFAQ.DE - E2007 SP1 -> nach Watermark suchen. Wenn es dann aber auch nicht weitergeht, ist die Installation kaputt und alle Reparaturen führen höchstens dazu, dass Du die Probleme auf die Zukunft verlagerst. Wenn Du nur am WE Zeit für so wichtig Dinge hast, solltet ihr in der Firma dringend Euer Verfügbarkeitskonzept überdenken. Entweder sind Systeme so wichtig, dass sie nicht ausfallen dürfen, dann muss das Konzept solche Installationsfehler beinhalten. Oder man muss den Ausfall einplanen, dann kann man diese Installation auch am Montag Abend machen und Dienstag notfalls korrigieren mit Fachleuten.

Dann würde ich an Deine Stelle den Microsoft-Support anschreiben. In der Log-Datei steht nicht wirklich was verwertbares und Alternativ kannst Du auch die Datenbank sichern, den Server neuinstallieren und Exchange mit "RecoverServer" neuinstallieren. Und für das nächste Mal merken: Wichtige Installation am Wochenende haben den Nachteil, dass bei Fehlern niemand da ist, der helfen kann. ;)

Ist das wirklich der letzte Stand? Der ist von 08:04 und keine "Upgrade"-Installation gewesen. Wie oft hast Du das Setup gestern ausprobiert? Ich zähle mindestens 13 Versuche. :( Fehlgeschlagen gestern ist übrigens der Start des 'MSExchangeADTopology'-Dienstes, was auf ein DNS- oder AD-Problem hindeuten könnte.

Normalerweise unter C:\ExchangeSetupLogs

Bitte mal das komplett ExchangeSetuplog.txt gezippt irgendwo hochladen und hier verlinken.

Moin, bitte mal das Setup über die CMD starten (auf die richtigen Berechtigungen achten!): setup.com /mode:upgrade

Moin, die einfachen URL-überprüften Zertifikate bieten die schon seit langer Zeit an. 1 Jahr kostenlos.

Er holt per POP3 ab, schreibt er in #10. Und das wird ja hoffentlich hinter der Firewall sein.

Gehen wir mal davon aus, dass Hidden DNS Master von Deinem Registrar und Deinem ISP supported sind (bei DENIC IMHO nicht), dann stelle ich mir trotzdem die Frage, wo das Problem ist. Im Innneren ist es doch ein normaler DNS-Server. "Hidden" ist er doch nur beim Zugriff von außen und Deine AD-Zone wirst Du ja hoffentlich so oder so nicht ins Internet replizieren.

Moin, wenn Du mit Zertifikaten mit einem Jahr Laufzeit leben kannst, gibt es hier kostenlose: StartSSL Ansonsten nutze ich persönlich immer PSW: PSW GROUP - SSL-Zertifikate ab 15 € pro Jahr mit bis zu 90 Tagen zusätzlicher Laufzeit | Qualifizierte Signatur | Shoplösungen | PDFlib | Parallels-Lizenzen | Secure CDN | Hosting & Housing

Moin, ich wüsste keine Möglichkeit, wie man das wirkungsvoll mit Ex2003 verhindern könnte. Bei Ex2007 könnte man ein wenig mit den Transport-Regel spielen, aber ob das da richtig geht, glaube ich auch nicht. Wie soll zwischen manuellen und automatischen Weiterleitungen wirkungsvoll entschieden werden. Schon die Remote Domänen Einstellung "keine automatischen Antworten" oder "keine automatischen Weiterleitungen" funktioniert nicht zu 100%. Eben weil man zwischen manuelle und auto nicht wirklich unterscheiden kann. Proxy davor, Mail-Traffic beobachten und darin Regeln bauen. Aber immer schön mit Fehlermeldungen arbeiten, denn die Gefahr ist hoch, dass man doch die falschen Mails aussortiert.

Moin, nach dem ich zu viele erlebt habe, die sich mit der Alternative 1 ihren ganzen Server lahmgelegt haben (die vergessen nämlich, dass sich die Einstellungen automatisch auf alle Unterseiten vererben und bauen sich dann ganz tolle Schleifen), nehme ich nur noch Variante 2. Das ist relativ DAA freundlich und im Notfall schnell und problemlos wieder zur beheben. Habe ich auch hier beschrieben: OWA – Verkürzung der URL auf anderem Weg « Robert Willes Welt

Moin, ich verstehe Deine Frage zwar nicht richtig, aber internes Mailen kannst DU nicht verhindern - nur, wenn Du den Zugriff auf die Postfächer sperrst, aber dann kommt auch keine an die Mails ran.

Er verbindet sich zur IP-Adresse 213.216.23.81 auf Port 25 (da lauscht Euer Exchange, habe ich gerade getestet) und verschickt als authentifzierter Benutzer Mails. Du kannst ja mal das SMTP-Logging aktivieren und beobachten, ob meine Vermutung richtig ist.

Moin, eigentlich ist der Ablauf von unten nach oben (technisch gesehen wir der neue Header einfach vorangestellt, das ist einfacher, als ihn irgendwo mittendrin einzufügen), siehe auch hier die Header-Auswertung: Email Header Analyzer, RFC822 Parser - MxToolbox Über die genauen Einträge im Header können wir Dir wenig sagen, weil wir die Geräte auf dem Weg nicht beurteilen können. 192.168.1.107 ist der Empfänger der Mail gewesen, ist ja auch kein Exchange-Server, er hat sie von "QMQP" bekommen. Von außen kann er eigentlich nur über einen gehackten Account kommen.