RobertWi

Was ist denn daran unsauber? Du kannst mit vielen Varianten das Problem lösen: Regeln, Verteiler, Kontakte, Mailbox Konfig, Transport Regel, usw. usf. Du musst nur mal genauer definieren, was für ein Problem Du wirklich lösen willst.

Moin, definiere "deaktivieren" und "weiterleiten" genau. Im einfachsten Fall deaktivierst Du einfach das alte Postfach und trägst die beiden alten Adressen beim anderen Postfach ein.

Moin, Eigentlich sogar bis 2020. Er ist 2010 erschienen, 5 Jahre Mainstream + 5 Jahre Extended Support. Wobei die zweiten 5 Jahre vollkommen freiwillig sind. Wenn MSFT nicht mehr will, schalten sie den Support ab. 1. Der Edge macht ein anderes Protokoll -> SMTP. EAS ist HTTPS, das ging noch nie über den Edge. 2. Also ich finde den Edge in der Einrichtung deutlich einfacher, als einen TMG. Der ET macht doch alles alleine - dank gut abgestimmter Assistenten. Dritt-Anbieter. Wobei man aufpassen muss, dass die Push können. Da ist ein verbogenes HTTP-Protkoll und es gibt Reverse Proxys, die das nicht mögen. Offiziell nicht, aber inoffiziell: Gar nichts. Port 443 an Exchange und gut ist. Eine Reverse Proxy bietet realistisch betrachtet eh keinen echten Mehrwert, da er gar nicht in der Lage ist, das, was in HTTPS (oder noch schlimmer: RPC/HTTP) sinnvoll bewerten zu können. Die meisten Proxy machen daher auch nichts anderes, als den Traffic 1:1. durchzureichen. Exchange ist selbst mittlerweile so gut, dass es dort keine Angriffspunkte mehr gibt. Also davor nur eine Firewall, die Low-Level-Angriffe abfängt (auf TCP/IP-Ebene oder DoS). Und alles oberhalb durchreichen. Das ist sicherlich unpopulär, aber wenn man mal drüber nachdenkt: Technisch und realistisch durchaus nachvollziehbar.

Moin, hast Du schon mal den Kennwort-Tresor von Windows geleert. Außerdem bitte prüfen, ob alle Exchange-Dienste laufen (Test-Servicehealth). Ansonsten mal prüfen, welche URLs die Clients wirklich bekommen -> "E-Mail-Autokonfiguration testen..." in Outlook.

Moin, im Schema heißt das Attribute "msExchMessageJournalRecipient". Den falschen Eintrag mit ADSIEDIT zu finden, wäre aber auch nicht so schwer gewesen, Du hättest Dir einfach den gesetzten Wert anschauen können. Das "DEL:f909b833-0363-4adb-aae6-dd4f1e5777cd" springt einem förmlich ins Auge. In Verbindung mit einem Filter auf Attributen mit Werten, wäre die Liste auch kürzer gewesen. Hättest Du mit "Get-MailboxDatabase" gesucht, heißt das Feld "JournalRecipient", wie im Eventlog-Eintrag beschrieben. Du hättest den fehlerhaften Wert also ganz einfach mit finden können: Get-MailboxDatabase "CN=Mailbox Database 1286070522,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=local" | ft Name,JournalRecipient Und die Korrektur dann mit: Set-MailboxDatabase "CN=Mailbox Database 1286070522,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=local" -JournalRecipient NEUER_EMPFÄNGER Wahrscheinlich hat Dich das größte Problem bei den Fehlermeldungen der Exchange-Entwickler ereilt: Sie sind technisch so überkorrekt, dass sie schon wieder unverständlich sind. Dann einigen wir uns auf ein Unentschieden. :)

Moin, stell Dir vor, Du bist Programmierer, machst Dir die Mühe, eine Fehlermeldung zu programmieren und niemand liest sie. :( Steht doch eigentlich alles da: In diesem Objekt: CN=Mailbox Database 1286070522,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=local gibt es das Feld "JournalRecipient", in dem befindet sich ein fehlerhafter Eintrag "Domain.local/Deleted Objects/Postbuch DEL:f909b833-0363-4adb-aae6-dd4f1e5777cd" und der muss korrigiert werden. Die Korrektur ist via ADSIEdit möglich, bzw. bei diesem Fehler auch per EMC (Eigenschaften der Datenbank "Mailbox Database 1286070522", Reiter "Wartung" - Journalempfänger - da steht ein Empfänger drin, der nicht mehr existiert "Postbuch").

Korrekt, das sind die Sprachen. Ich persönlich installiere nur das "kleine" Paket und in der Sprache, die der Kunde will (DE oder EN).

Bereits seit Exchange 2007 ist jedes Service Pack auch eine komplette Installation.

Moin, ich habe in den vergangenen zwei Wochen 4 Exchange 2010 SP 3 auf Windows 2012 installiert - problemlos. Install gibt es hier: http://www.microsoft.com/en-us/download/details.aspx?id=36768 Vorbereitung ist wie hier: http://technet.microsoft.com/en-us/library/bb691354(v=exchg.141).aspx Da ist auch das .NET 3.5 dabei. Filterpack kann man machen, ist aber keine Pflicht.

Es muss aber auch eine Volumenlizenz sein. Ein Retail-Versio lässt sich seit 2010 nicht mehr auf einem RDS installieren und auch nicht lizenzieren: http://technet.microsoft.com/de-de/library/ff506201(v=office.14).aspx

Moin, Eigenschaften der DL -> Nachrichtenübermittlungseinstellungen -> Einschränkungen für die Nachrichtenzustellung. Der Rest dürfte selbsterklärend sein.

Moin, warum ist eine Sitebindung auf Port 8000 erforderlich? SBS braucht die nicht und andere Software sollte tunlichst nicht auf einem SBS installiert werden, da das Ding so schon sehr verbogen ist. Auf der Site, auf der OWA liegt, ist eine Änderung der Bindungen nicht supported, Outlook erwartet 443 und eventuell 80. Also musst Du dafür eine eigen Site machen. Schau Dir einfach mal die Konfig im IIS an - schon MSFT hat echte Probleme, den IIS im SBS sinnvoll zu konfigurieren, da es halt bei einem Exchange-Server immer schwierig ist, wenn andere Produkte auch den IIS nutzen wollen.

Und was ist mit: Sinnvolle Archivierung. Da gibt es ja noch mehr, als nur Speicherplatz - Stichwort: Aufbewahrungsfristen.

Das könnte man mit einer Transport-Regel lösen.

Das war sicher die beste Lösung! :)

Moin, nein, das ist mit Bordmitteln nicht möglich. Hier müsste vermutlich ein Transport-Agent von Euch programmiert werden. BTW auch von mir: POP-Connectoren sind Mist und schaffen mehr Probleme, als sie lösen.

Moin, gerade WENN es der Chef ist, ist um so wichtiger, dass er Dich als Fachmann eingestellt hat und Deinem Rat glauben sollte. Wenn die erste PST-Datei mal defekt ist, ist das Geschrei groß und dann steht er ja auch bei Dir. Zum Topic: Geht das manuell Archivieren denn.

Das gibt es leider nicht für den User. Der Admin könnte sowas mit der EMS scripten. Oder Drittanbeiter-Tools einsetzen, wobei ich nicht weiß, ob irgendeines genau diese Anforderung abdeckt.

Moin, nein, möchte er nicht - bzw. nur, wenn ihm die Daten nicht wichtig sind und der Admin das Mehr an Speicherplatz verschenken will. Aber unwichtige Daten kann man auch gleich löschen. PST-Dateien sind eine große Fehlerquelle und auf Netzlaufwerken technisch aufwendig, kostenintensiv und unsupported. Macht Euch entweder Gedanken darum, im Exchange mehr Speicherplatz zu haben oder geht ein gescheites Archvierungsmodell an. PST-Dateien hab in einer vernüftigen IT genau eine Einstellung: Per GPO komplett deaktiviert. ;)

Moin, ein leerer Envelop (der sog. <> oder Null-Sender) ist RFC-konform und korrekt und daher gibt es auch keine Möglichkeit, das in Exchange zu ändern - siehe hier: http://robertwilleswelt.wordpress.com/2008/09/11/ex-2007-abwesenheitsnachrichten-haben-keinen-absender/ Die einzige Lösung ist daher, den Spamfilter entsprechend anzupassen.

Ja, hier: Received: from server.newvasuki.net (server.newvasuki.net [182.18.11.149]) bymix2.naverex.net (8.Who.Cares/8.Who.Cares) with ESMTP id r3NEvMGP001781 for <asieinhumansh@naverex.kiev.ua>; Tue, 23 Apr 2013 17:57:25 +0300 (EEST) (envelope-from h.mustermann@firma.com) Die Mail kam von server.newvasuki.net und ging an Server mix2.naverex.net. Wenn das keiner von Euch ist, ist der Absender gefälscht.

Moin, der Server, der hier die Mails empfängt ist kein Exchange, sondern der hier: 250-mi022.mc1.hosteurope.de Hello smtp.testexchangeconnectivity.com [207.46.14.62] Hat da eventuell jemand an den MX-Einträgen rumgespielt?

"Meine" Scripte sind die ganz normalen DAG-Scripte im $exscripts-Ordner. Ich habe sie nur mit einer PowerShell-Verknüpfung nach auf dem Desktop liegen. Die einzige Ergänzung eine Prüfung, ob die DB wirklich verschoben wurden: function wait-key {Write-Host "Taste drücken zum Beenden..." $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown") | out-null }$source = $args[0]if ($source -eq $null -or $source -eq '') { write-host "Quell-Server fehlt!" -ForegroundColor red wait-key return }write-host "" write-host "Verschiebe Datenbanken von Server '$source'"cd $exscripts .\StartDagServerMaintenance.ps1 -serverName $sourceif ( (Get-MailboxDatabase | where-object { $_.Server.tostring().toupper() -eq $source.toupper() }) ) { write-host "NICHT alle Datenbank verschoben:" -ForegroundColor red } else { write-host "Alle Datenbank verschoben" -ForegroundColor green } wait-key return Mehr ist das nicht.

Klick mal Entfernen an und lies Dir die Warnung genau durch, dass dürfte die Frage beantworten. ;)

Moin, das wird so nicht gehen, weil Du OWA nicht dazubekommst, in seinen Links den Port 8080 zu nehmen. Die OWA-Links gehen immer auf Standard-SSL, weil sie keinen Port angeben. Du musst entweder einen Proxy mit URL Rewriting haben, oder von außen Port 443 auf den Exchange durchschieben.