RobertWi

Moin, und da Norbert hier den Hinweis auf das Multi-Posting hingewiesen hat, mach ich das mal: Verschiedene SMTPs und Newbie-Fragen [Forum - SBS 2003] - msxforum Bitte auf Multi-Postings hinweisen, ersparten den in Ihrer Freizeit helfenden Mitgliedern in den verschiedenen Foren doppelte Arbeit!

Moin, das dürfte schwer sein für uns zu raten. Warum registrierst Du Dich nicht bei VEDA und probierst aus, ob Du so an den Artikel kommst: VEDA GmbH: Registrierung Danach anmelden und Lesen edit: Und prima wäre, wenn Du danach hier zumindest eine Zusammenfassung posten würdest.

Das Computer-Konto selbst bleibt noch übrig. Diese wird dann erst recht nicht funktionieren. Du musst danach Exchange manuell von der Maschine löschen (Anleitung - viel Spaß damit) oder bessere den Rechner neuinstallieren.

Moin, nein, es reicht weiterhin ein Zertifikat, das alle Namen, die Du oben aufgezählt hast, beinhaltet. Frank meinte in seinem FAQ-Eintrag, dass man eben nicht vergessen darf, neben den Name der Server auch den Namen des logischen CAS-Arrays mit einzubauen.

Sicher die wenigsten. Und dass es ihn gibt, erfahren die Meisten erst bei einer Migration nach 2007/2010, wenn man erklärt, warum man Postfächer nicht mehr im ADUC anlegt. Das gleiche Aha-Erlebnis habe ich immer, wenn ich den langen Weg zum OAB auf dem Client erkläre. MBERN wusste immerhin schon, dass er für das Stempeln der E-Mail-Adressen zuständig ist. Und bei einer so wichtigen Sache finde ich es ok, nachzufragen.

Das hört Norbert bestimmt gerne. Z.B. auch über einen Öffentlichen Ordner, den Du beim Anlegen den Typ "Kontakte" zugewiesen hast.

Die von Dukel genannte Funktion findet sich unter "Datei -> Kontoeinstellungen -> Ordnerwechsel". Nach abschließende Warnung sind die Mails auf dem Server weg. Ich weiß jetzt nicht, ob ich Dir wünschen soll, dass das Notebook mal abhanden kommt oder die Festplatte ausfällt und dann alle Mails weg sind. Bei so einem "vertrauensvollen" GF ist das vermutlich das Ende der Firma. :(

Moin, dann würde ich lieber das SP3+RU1 empfehlen... ;)

Moin, IMHO gibt es keine zahlenmäßige Begrenzung, nur an oder aus. Siehe auch Technet. ConflictPercentageAllowed wirkt sich nur auf Serientermine aus.

Moin, nach dem Fehler ist der Ex2003 meistens irreparabel kaputt und kann nur noch manuell mit ADSIEDIT entfernt werden.

Dem kann man nichts hinzufügen und (leider) nichts korrigieren... :D

Das wäre mir neu. Bei mir ging das bisher auch wunderbar auf anderen Servern mit anderen Orten.

Alternativ bleibe dann nur der Export mit EXMERGE und in der neuen Domäne das ganze wieder mit EXMERG/PST zu importieren.

Ich glaube, ich habe 80% der Ex2003-Server "manuell" deinstallieren müssen. :mad: ÖO bringen eine andere Fehlermeldung ("es fehlen noch Replikate für ÖO"). Eventuell hast Du nicht richtig gesucht? Klick mich - Abschnitt Mailboxen Das bestätigt dann, dass Du keine Replikate hast. Dann wäre ADSIedit das Mittel der Wahl, um die alte Datenbank zu entfernen. Allerdings kann man mit dem Werkzeug viel kaputt machen...

Es soll Kunden geben, die legen Wert auf eine möglichst einheitliche Umgebung mit möglichst wenig Ausnahmen. Und wenn alle Maschinen als "geclusterter Guest" laufen, nur die DAG-Server nicht, dann wird dieser schwarze Peter regelmäßig MS zugeschoben. Und keine Diskussion ob der Kunde damit recht hat, oder nicht, denn erstens ging es mir nur um die Technik, nicht die Philosophie und zweiten suche ich sonst Postings raus, wo Du selbst zugibst, dass Kunden manchmal nicht beratbar sind (Stichwort: HTML-Mails, Bilder in Disclaimern, etc.). ;) Damit ist das Thema für mich beendet und ich danke Dir und Nils für den Input.

@Norbert: Ich weiß, dass Du manchmal sehr spitzfindig auf einzelne Worte achtest. Lies meinen Beitrag davor nochmal, das steht absichtlich nichts von "geclusterten Umgebung". ;)

Das habe ich nie geschrieben. Ich habe geschrieben (ganz am Anfang), dass die Einschränkung, keine DAG in einer geclusterten Maschine zu betreiben, für den Kunden nicht verständlich ist ("dass diese Einschränkung technisch eigentlich unnötig ist."). Die technischen Hintergründe werden wir hier auch nicht klären können, mal sehen, ob MS da mehr zu sagt.

Diese Option wird noch diskutiert. Das nutzen auch die meisten der Kunden, die ich bisher bei Virtualisierung gesehen habe. Ob es performancetechnisch besser oder schlechter ist, spielte nie wirklich eine Rolle, als Hauptargument wurde immer die höhere Flexibilität angeführt.

(Warum zitiert die Software eigentlich immer nur eine Ebene, das ist Mist....) Nein, eben nicht. Virtualisierung wird i.d.R. auch betrieben, weil man damit Hardware konsolidieren kann. Es ist also nicht nur Nebeneffekt, sondern die Regel, dass noch weitere virtuelle Maschinen mit anderen BS, Software, etc. laufen. Die Ansprüche sind klar und in der Aufgabenstellung definiert. Exchange erlaubt das Gewünschte zur Zeit noch nicht. Ok, ich habe oben eine wichtige Information unterlassen, die für mich selbstverständlich war - in dem VM-Cluster läuft natürlich noch mehr, als nur Exchange. Tut mir leid, für Deine eventuell doppelte Mühe. Ich formuliere neu: - HA-Cluster mit drei Knoten und einem Storage (Platz genug vorhanden) - drei virtuelle Windows-Server mit Exchange (nur Mailbox-Rolle) - außerdem laufen folgende virtuelle Maschinen: -- 1x DC (hier gibt es noch Diskussionen und eventuell Änderungen wegen Exchange) -- 1x Print Server -- 1x Fileserver -- 1x Linux Server (Systemüberwachung mit Nagios) Angeplant sind: - Datenbank-Server (BS und DB-System noch nicht definiert) - Webserver auf Linux/Apache-Basis für Intranet - Terminalservice (verm. in eigener Virtualisierung) Kunde will: - wenn ein physischer Knoten ausfällt möglichst hohe Verfügbarkeit und schnelle Wiederherstellung (aller Rollen!) - beim geplanten oder ungeplanten Ausfall eines virtuellen Exchange-Server möglichst hohe Verfügbarkeit und schnelle Wiederherstellung der Datenbank Kunde will von der jetzigen Lösung weg (Fremdprodukt) und stuft Mail als "kritisch" ein. Er ist von DAGs sehr angetan, weil er genau dieser Funktion bei seinem jetzigen System vermisst. Die vorhandene und ausreichend dimensionierte VM-Landschaft soll weiter benutzt werden. Wie löschen wir das?

Es gibt keinen manuellen Failover. Es liegt in der Natur der Sache, dass ein Failover ungeplant und damit automatisch erfolgt. Ein manuelle Failover wäre ein Switchover, und dieser Fall ist ausdrücklich nicht gemeint. Weil ein HA-Cluster ohne automatischen Failover ungefähr genauso eine Verschwendung ist, wie mit einem 400 PS Auto durch eine Tempo 30-Zone zu fahren. Natürlich kann er den HA für 1000 andere Sache einsetzen. Er *will* es aber für *Exchange* machen. Und natürlich für die Datenbank, denn für CAS und HT gibt es andere Methoden der Hochverfügbarkeit. Sorry, für die Spitzfindigkeit, aber entscheidend ist nicht, was ist implementieren kann. Entscheidend ist, was am Ende dabei rauskommt. Was für einen Sinn hat dieser Cluster dann noch? Wegen Failover und LM betreibe ich den. Und nicht, weil ich zu viel Geld habe. ;) Ok, mache wir mal eine einfache Aufgabe daraus: - HA-Cluster mit drei Knoten und einem Storage (Platz genug vorhanden) - drei virtuelle Windows-Server mit Exchange (nur Mailbox-Rolle) Kunde will: - wenn ein physischer Knoten ausfällt möglichst hohe Verfügbarkeit und schnelle Wiederherstellung - beim geplanten oder ungeplanten Ausfall eines virtuellen Exchange-Server möglichst hohe Verfügbarkeit und schnelle Wiederherstellung der Datenbank Wie macht er das?

Moin, nein, der ESM ist die Abkürzung für "Exchange System Manager". Das ist das Werkzeug, mit dem Du Exchange verwaltest. Ab 2007 heißt das Ding dann "Exchange Management Console" und ist der Nachfolger de EMS. Das ist alles.

Du hast es doch selbst aus dem Technet zitiert: DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn't employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server. Anders gesagt: entweder: DAG nur, wenn kein Root-Cluster oder: wenn Root-Cluster, dann kein automatischer Failover für Mailbox-Server Einen Cluster ohne automatischer Failover dürften die meisten als witzlos empfinden. Genau darum geht es. Wenn ich einen HA-Cluster betreibe, darf ich keine DAGs einsetzen. Und ohne DAGs habe ich eine Downtime. Der Kunde kann nun entweder seinen teuren HA-Cluster nicht mehr nutzen, oder muss auf DAGs verzichten. Und dabei ergänzen sich beide aus meiner Sicht eigentlich eher, als dass sie sich ausschließen. Nein, sie sind nicht das gleiche. Bei VM-HA habe ich zwar mehrere Geräte, aber nur einen Datenbestand (shared Storage oder Ressorucen Pool). Fällt ein HA-Knoten aus, nimmt ein anderer den Betrieb auf und nutzt die bisherigen Daten weiter. Bei DAG sind aber auch die Daten redundant, d.h. jeder Server hat seine eigene Kopie der Daten und ist damit nicht mehr auf einen Shared Storage angewiesen.

Es passiert genau das gleiche, das passiert, wenn ich einen DAG-Knoten, der nicht im HA ist, ausschalte und fünf Minuten später wieder einschaltet. Der AM stellt fest, dass der alte Knoten wieder läuft, wird entweder zurück schwenken oder sich eventuell fehlende Log-Dateien nachholen. Nichts anderes passiert in den VMs, nur automatisch. Das denke ich auch. Was durchaus bestätigen würde, dass die Exchange-Entwicklung das nicht ausreichend getestet haben - oder das JET-DB-Konzept hat wirklich technische Einschränkungen. Allerdings schenkt VM nicht "sofort" (definiere "sofort"). Die Ersatz-Maschine wird gebootet, was je nach Performance einige Minuten dauern kann. Die Entwickler der DAG haben durchaus vorgesehen, dass ein ausgefallener DAG-Knoten wieder online geht und ich habe keine Einschränkung gefunden, dass er das erst nach x Minuten darf. ;) Wenn ich in Verbindung mit VM-HA keine DAGs einsetzten darf, dann fällt bei einem geplanten Reboot (z.B. am Patchday) die Datenbank aus.

Moin, bei MS ist es oft so, dass die theoretische Chance aus ein bestimmtes Ereignis besteht und auch dieses ausgeschlossen werden soll. Das theoretische Problem schriebt Nils im gleichen Absatz im Satz davor: Meine Erfahrung mit dem Active Manager ist, dass er auch solche Fälle extrem gut löst. In einem Workshop habe ich mal einen DAG aufgebaut und einen Knoten aus versehen auf einen Snapshot *vor* dem DAG zurückgesetzt. Der AM wollte dann wenige Sekunden später den DAG wieder einrichten und scheiterte nur an der fehlenden Cluster-Rolle. Manchmal ändert sich eine Support Policy auch, wenn die Programmierer und der Support genügend Erfahrungen mit den Besonderheiten gesammelt haben und feststellen, dass das theoretische Problem doch keines ist. Zu Deiner Frage: Das kommt darauf an. ;) Technisch kannst Du DAG und HT auf eine Maschine installieren. Ab einer gewissen Größe wird es aber sinnvoller, DAG und andere Rollen zu trennen. Das schöne ist, dass das bei 2010 auch im nach hinein geht. Man kann also klein anfangen und dann wachsen.

Moin, ja, er wird funktionieren, aber in einigen Dingen langsam. Bei IIS und OWA sieht man es am deutlichsten. Bei der Ausstattung und dem, was darauf läuft, würde ich die Langsamkeit des OWA als normal bezeichnen. Das erlebe ich jeden Tag in Test- und Schulungsumgebungen genau so, wie Du.