Dukel

Ich würde in dem Fall gar keinen Failovercluster nutzen. AD Redundant installieren (auf jedem Host ein DC + Physikalischer DC). Exchange per Log Shipping (k.a. wie das unter 2007 genau hieß, Vorgänger von den DAG's) absichern. Bei Exchange noch zwischen den Rollen trennen und die Hub/Cas per Loadbalancer aufteilen. Dabei braucht man kein Cluster für die Hosts und keine Shared Storage.

Aber wenn man sich am Rechner anmeldet will man nicht unbedingt gleich sein Startmenü sehen sondern eher den Desktop.

In Wenigen Punkten ist gut. Es gibt mehrere hundert Neuerungen. Nimm einfach an, alles ist besser im Gegensatz zum Server 2008R2. ;) Wozu willst du das wissen? Gibt es ein Projekt, bei dem ein OS gesucht wird? Interessiert dich ein bestimmtes Thema (z.B. Hyper-V) oder hast du ein Problem und willst wissen, ob dieses mit dem Server 2012 gelöst wird?

Die VM läuft auf dem Node (nutzt dessen CPU und RAM und Netzwerkkarte) und die Disks liegen auf der Shared Storage. Die Shared Storage sind "nur Platten", auf diesen kann ja keine VM alleine laufen.

Kannst du in Zukunft Quoten? Kann man dann besser lesen. Bei einem Failovercluster gibt es x Nodes und normalerweise eine Shared Storage. Auf einem Der Nodes läuft eine Applikation, die Daten der Applikation werden auf der Shared Storage gespeichert. Bei einem Ausfall oder manuell kann der Dienst auf einem anderen Knoten gestartet werden. Dieser Failover Cluster gilt z.B. für VM's (dabei ist jede VM eine Applikation, d.H. diese kann auf einem Knoten laufen, eine andere VM dafür auf einem anderen Knoten), SQL Server, Exchange (dabei ist eine Applikation (oder besser gesagt eine Ressource) eine Exchange Datenbank, wobei man hier auch mehrere DB's haben kann, die verteilt sind),... Bei einem Ausfall eines Knoten müssen alle verbleibenden die restliche Last tragen können (z.B. bei 2 Knoten sollten beide zu max 50% ausgelastet sein). Zusammengefasst: Shared Storage benötigt, Bei Ausfall gibt es eine kurze Downtime, da die Dienste (VM's) hochfahren müssen Eine andere Technik ist die Replikation. Dabei laufen mehrere Instanzen einer Applikation auf unterschiedlichen Knoten. Jede hat ihre eigenen Daten und die Applikationen replizieren ihre Daten zwischen den Instanzen. Ein Beispiel ist das AD oder auch SQL und Exchange in einem bestimmten Modus. Zusammenfassung: Es wird keine Shared Storage benötigt, es gibt keine Downtime bei einem Ausfall. Evtl. ist die Latenz der Applikation höher. Exchange ist Clusterfähig. Bei VM HA kann man beliebige Applikationen vor Hardware Ausfall schützen, da die komplette VM verschoben werden kann und das OS / Applikationen das nicht merken.

Du kannst per Backup/Restore oder per Replikation die Datenbank synchronisieren.

Alles was kein 19" Switch ist (mit VLAN's) wird unsauber sein.

So viel ich weiß ja, aber frag mich nicht wo.

Off-Topic: Ein NAS mit iSCSI nenne ich trotzdem SAN (oder Unified Storage, wenn es beides kann). Ich unterscheide da zwischen Block und File Zugriff.

In der Netzwerkkonfiguration. Windows 7 Client - Registierung in DNS Reverse-Lookupzonen nur durch Setzen von Du brauchst die Option "DNS-Suffix dieser Verbindung in DNS-Registrierung verwenden"

Es gibt Bodenbleche für 19" Schränke. Dort kannst du 3 kleinere Switche draufstellen. Diese dürfen dann aber nicht breiter als 19" sein. Ich würde trotzdem einen großen Switch mit VLAN empfehlen.

ipconfig /registerdns Evtl. fehlt in der Netzwerkkonfiguration, dass sich der Rechner auch in der Reverse Lookupzone einträgt.

Du meinst 3 Switche in einer HE?

Das ist aber sehr sportlich für ein Abschlussprojekt, vor allem, wenn du die Grundlagen noch lernen musst. AD hat von sich aus "Failover". Man kann beliebig viele DC's hinstellen und jeder kann (bis auf die FSMO Rollen) die Funktion der anderen bei einem Ausfall übernehmen. Bei Virtuellen Umgebungen kannst du auch die VM von einer Hardwarekiste auf eine andere Schwenken. Aber dazu komme ich dann noch. Nein. 1. Eine Shared Storage kann bei einem Failovercluster in diesem Sinne kein NAS sein, dafür benötigst du ein SAN (ich zähle iSCSI hier zu SAN). 2. Bei mehreren DC's brauchst du keine Shared Storage, da jeder DC seine eigene DB hat. Diese ist unabhängig davon. MS Failover Cluster nutzt man für Shared Nothing Dienste wie Fileservices, SQL Server,... Bei der Kostenfreien Variante fehlt HA (siehe oben), dürfte für das Projekt aber reichen. Wenn HA gewünscht wird kannst du dir Hyper-V anschauen. Dort ist es im Hyper-V Server kostenfrei oder beim Server 2012 relativ günstig (da du sowieso Lizenzen brauchst) dabei. Dabei benötigst du aber eine Shared Storage, kannst aber Applikationen "Clustern", welche nicht Clusterfähig sind (für Hardwareausfälle). Da beim AD das kein Failover sondern eine Replikation ist wird das unterstützt. Bei Exchange Failover benötigst du eine Shared Strorage. Exchange kann aber auch eine replikationetechnik, bei der du diese nicht benötigst. Viel Erfolg und ich würde das Projekt kleiner angehen (z.B.: nur den AD Teil).

Dann hast du Dr. Google falsch befragt: LDAP://Yusufs.Directory.Blog/ - Kerberos - Das Authentifizierungsprotokoll unter Windows Server 2003

What's New in Windows Server 2012 Was sind für dich die wichtigsten Vorteile?

Reicht es nicht, dass wenn alles i.O. ist die LUN normal überwacht wird und im Fehlerfall schlägt der Test dann fehl. Entweder weil der Server ein Problem hat (dann gibt es sicher andere Tests, die das bestätigen) oder weil die Storage ein Problem hat (dann gibt es sicher andere Tests, die das bestätigen).

Ich würde mir ggf. den Windows Server 2012 anschauen. Dort sollte das ganze beim normalen und nicht nur beim Storage Server dabei sein und auf die Technik Deduplication basieren.

Wieso ist die LUN nicht sichtbar?

Sollte ein Full Backup nicht auch helfen?

Solange der Anonyme User nur an User des Exchanges Mails senden darf und nicht an die ganze Welt ist das kein Problem (muss ja auch, sonst kann man keine Mails empfangen).

Git-Integration und Kanban-Unterstützung in Microsofts Team Foundation Server | heise Developer

Und wo ist das Problem? Kannst du ein Beispiel machen? Irgendwie verstehe ich das Problem nicht.

(Transaktionslog-)Backup machen und dann Shrinken.

Wenn es wirklich nicht anders geht kann man evtl. alle gesendeten Mails per BCC an sich selbst nochmal schicken.