Dukel

Wie hast du denn OWA umgesetzt?

Selbst nachbauen. Einfach mein Script erweitern. Sieht zwar nicht so hübsch wie tree.exe aus aber versuch mal folgendes: $root = 'E:\Daten' "$root" foreach($rootfolder in (get-childitem $root | ? { $_.PsIsContainer } )){ "├───$($rootfolder.Name)" foreach($folder in (get-childitem $rootfolder.FullName | ? { $_.PsIsContainer } )){ "│ ├───$($folder.Name)" foreach($folder2 in (get-childitem $folder.FullName | ? { $_.PsIsContainer } )){ "│ │ ├───$($folder2.Name)" } } } Und wenn das in eine Datei soll "| out-file inhalt.txt -append" hinter jede Zeit, die mit einem Anführungszeichen beginnt schreiben

Der Teil "$folder2.FullName | out-file inhalt.txt -append" ist die Ausgabe in eine Datei. Dort wird aber nur der Pfad ausgegeben. Wenn du Mehr als nur die Pfade haben willst musst du dieses in der Ausgabe anpassen.

Das weiß ich jetzt nicht, ob das Gateway und der Webaccess in die DMZ muss. Aber wenn keine DMZ vorhanden ist braucht man das nicht unbedingt. Ich persönlich würde eine Rolle die in die DMZ gehört immer trennen.

-tree gibt es nicht, dass musst du manuell Scripten.

Vielleicht gibt es auch ein Problem mit der Datanbank. Geht die Seite im Firefox oder einem anderen Browser?

Ich würde ggf. das TS Gateway auf eine 3. Maschine auslagern, da diese in die DMZ gehört.

Ja. Wieso?

Es wird nicht bei allen Clusterservices eine Shared Storage benötigt. SQL Server 2012 Always On basiert auch auf einem Failovercluster und braucht auch keine Shared Storage.

Welches meinst du? Das von mir? Einfach eine weitere Ebene einfügen und die Datei kannst du mit "? { $_.PsIsContainer }" ausblenden: foreach($rootfolder in (get-childitem E:\Daten | ? { $_.PsIsContainer } )){ foreach($folder in (get-childitem $rootfolder.FullName | ? { $_.PsIsContainer } )){ foreach($folder2 in (get-childitem $folder.FullName | ? { $_.PsIsContainer } )){ $folder2.FullName | out-file inhalt.txt -append } } } Wenn du eine andere Ausgabe haben möchtest musst du in jeder Ebene diese ausgeben und entsprechende Zeichen (z.B. - oder |- oder ähnliches) davor setzen.

Wieso sollte nur ein DC Zeitgeber sein? Eigentlich musst du nur einen DC konfigurieren (z.B. den mit der PDC Emulator Rolle) und die anderen DC's holen sich die Zeit von diesem und die Clients von allen DC's.

Wieso so kompliziert? foreach($rootfolder in (get-childitem E:\Daten)){ foreach($folder in (get-childitem $rootfolder.FullName)){ $folder.FullName | out-file inhalt.txt -append } }

Am besten Powershell. Schau dir get-childitem und out-file an.

Versuch mal "Get-WinEvent $_.FullName" oder "Get-WinEvent -Path $_.FullName"

Benutze und Konfiguriere die Automatische Ermittlung der Konfiguration per PAC Datei. Wenn du dieses per DNS oder DHCP konfigurierst, haben Notebooks außerhalb des LAN's auch keine Probleme.

Du musst diesem User wohl die DB Owner Rechte für diese DB entziehen.

Was nun? Hyper-V Cluster oder kein Hyper-V Cluster? Mit einem Hyper-V Cluster sind alle VM's automatisch vor Hardwareausfällen geschützt. Da würden dann ein virtueller DC und ein Physikalischer Reichen. Vergiss die Idee einen Failovercluster IN einem Virtuellen Cluster aufzubauen. Das macht man nur bei speziellen Anforderungen und verkompliziert das ganze sehr. Ja das mit dem VM Failover hast du jetzt begriffen. Und bei einer DAG (Unter Exchange 2007 ist es ein CCR Cluster) brauchst du keine Shared Storage. Schau dir die Clustergrundlagen am besten nochmal an.

Du kannst die DB's zurückspielen (NUR die Sharepoint Datenbanken ohne master, msdb) und Sharepoint installieren und an der vorhanden Farm anhängen (da müssen so viel ich weiß die Daten (Servername) übereinstimmen). Alternativ: Nur die Content DB's zurückspielen, Sharepoint neu installieren und die Content DB's einhängen.

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.