Doso

Sysyvol auf DFS-R umstellen, AD-Papierkorb aktivieren, Funktionslevel anheben.

Was ist eine DFS "Farm"?

Uhm. Woran erkennt man sowas und was bewirkt es? Wir haben diese Switches auch in unserem produktiven Hyper-V Cluster im Einsatz, immerhin 6 Nodes und 60 VMs.

Nicht jeder RAID-Controller kann zur Laufzeit sein RAID erweitern, ggf. braucht es auch einen Server-Neustart das er die Platten erkennt.

Hardware Das sind alles Fujitsu Primergy RX300S4 mit zwei Intel Xeon CPUs. Insgesamt jeweils 4 1GBe Netzwerkports, 2 für VM Netzwerke, 2 für Storage iSCSI Netzwerk. LSI Megaraid 5/6 Hardware Controller mit BBU. Festplatten Alle drei Server haben 6 Festplatten, davon einmal Hot-Spare, restliche 5 Platten als RAID-5. Auf dem RAID-Controller sind Einstellungen für hohe Performance gesetzt, also Write-Back, Apdative Read, Cache an. In den Hyper-V Hosts sind lokale SAS Platten, da liegt aber nur das Betriebssystem drauf. Auf dem iSCSI Target sind es 7.2K SATA Platten. Zugegeben, vermutlich nicht die schnellsten Teile, aber die sind halt recht groß. Storage Netzwerk Das Storage Netzwerk läuft über einen HP Procurve 1810G. Die beiden Storage Netze sind durch VLANs voneinander getrennt. Klar wären 2 seperate Switches besser, aber für eine Testumgebung sollte es auch so gehen. Jumbo Frames sind nirgends aktiviert da wir diese nicht verwenden. Anbindung mit MPIO Round Robin, entsprechend die Pfade auf den Hyper-V Servern definiert. Ich sehe das auch beide NICs bei Übertragungen beschäftigt werden, das Failover klappt auch wenn ich testweise Netzwerkkabel ziehe. iSCSI Target Es gibt drei Targets, eine 2.4 TB VHDx als Speicher für die VMS, eine 1GB Test-CSV damit ich die Cluster Überprüfung durchlaufen lassen kann und eine 1GB Disk für das Quorum (Disk Wirness). Ich sehe in den Eigenschaften der iSCSI Targets das beide Hyper-V Hosts verbunden sind. Cluster CSV-Cache ist angeschaltet und mit 1024MB konfiguriert. Die Cluster Überprüfung liefert keine Fehler, nur ein paar Warnungen das z.B. einige VMs ausgeschaltet sind - also nix besonderes. Cluster funktioniert soweit Einwandfrei, Live Migration etc. alles kein Problem. Ausser halt das die Reaktionszeiten der VMs teilweise unterirdisch sind. Jemand Ideen?

Backup wäre natürlich die alternative Möglichkeit.

Auch ich habe mit iSCS Boot experimentiert, mich aber dann dagegen entschieden. Zu komplex zu konfigurieren, zu viele "komische" Dinge die da passieren können. Bei Hyper-V sind dann auch die Netzwerkkarten für den iSCSI Boot nicht für andere Sachen nutzbar - d.h. man braucht mehr Netzwerkkarten. Wir haben nun bei unseren Hyper-V Hosts zwei kleine SAS Platten mit RAID1 drin - reicht vollkommen.

500 Konten lokal... the f**k. Backup, Administrierbarkeit, argh... :schreck:

Wollte das vor ein paar Monaten auch anschalten und durfte erfreut feststellen das man da nix anschalten muss und unser Exchange das sowieso schon die ganze zeit macht.

CSVs sind einfacher zu administrieren. Wenn du mal was mit Clustern machst merkt man das total. Der Schwenk bei CSVs geht ohne Downtime, bei "normalen" Disks ein paar Sekunden.

Mein Hinweis zu dem Problem steht in der Mitte, falls du das überlesen haben solltest.

Ist ja nur eine komplett andere Hardware wo du den gesicherten Server als Image drauf knallst. Das muss schief gehen,

Such dir eine andere Backup Lösung. Windows Update, 10-20% der Server haben Probleme nach dem Neustart. Entweder läuft der Agent nicht oder der VSS-Writer ist einem komischen Zustand oder der Backup Exec Media Server spinnt oder er hat mal wieder seine Kataloge zerschossen oder oder oder... Bei Backup Exec 2010 läuft der Agent afair auch auf dem Media Server - er wird halt automatisch mit installiert. Kann genau wie die normalen Agenten dann bei einem Serverneustart nicht hoch kommen. Das Ding dann entweder manuell starten oder den ganzen Server mal neu starten. Mittelfristig dann eine neue Backup Lösung suchen. Ja, ich hasse Symantec Backup Exec. Mit DPM habe ich halt einfach 4 Stunden mehr die Woche Zeit um etwas anderes zu machen als Backup Exec hinterherzulaufen.

Ich habe eine virt. DC von einem DPM Bare Metal Backup wieder virt. hergestellt in einer Testumgebung. Irgendwie passte die Netzwerkkarte dann nicht, erst nachdem ich in Hyper-V die Netzwerkkarte weggenommen und eine neue hinzugefügt hatte klappte es wieder. Glaube diese "Aufräumarbeit" nach einem Disaster Recovery ist dann noch das geringste Übel.

Ich habe aus drei alten Servern einen Hyper-V Cluster zum testen gebaut. Alle Server sind 2012R2, auf einem Server ist das Microsoft iSCSI Target konfiguriert was für den Cluster den Speicher zur Verfügung stellt. Die Hyper-V Hosts greifen dann mittels MPIO und iSCSI zu. Leider ist die ganze Sache sehr träge. VMs fahren vernünftig hoch, nur reagieren sie danach sehr zäh. Der Aufruf von z.B. Startmenü gefolgt von Aufruf der Kommandozeile dauert manchmal eine Minute. Speicher haben die Server genug, die CPU Auslastung auf den Hosts bewegt sich gegen null. Das Speicher-Netzwerk sollte mit 2x 1GBe eigenen Netzwerkkarten auch genug Power haben. Die drei Server waren vorher ein Backup System und 2 produktive Hyper-V Server. Daher kann ich eigentlich ausschließen das die Hardware zu lahm ist. Jemand eine Idee wie ich der Langsamkeit auf die Schliche kommen kann? Mir gehen irgendwie die Ideen aus. So macht das testen von neuen System leider irgendwie keinen Spaß :(

Exchange hat so schöne Funktionen um die Downtime bei solchen Migrationen gering zu halten. Da ist unsupported P2V einfach der falsche Weg.

Wir nutzen einen physischen Forefront TMG Server und bauen hierüber ein VPN mit SSTP auf. Das klappt soweit eigentlich recht gut, nur ist die Latenz überraschend hoch. Der Backbone des Forefront ist erste Glasfaser, 1GBe und sollte hier keinen Flaschenhals darstellen, es findet kein NATing statt. Die zu überbückende Strecke ist recht gering, geht innerhalb der selben Stadt. Beim Anwender haben wir (V)DSL mit guter Brandbeite, es ist meist nur ein Nutzer mit dem VPN verbunden. Sobald man das VPN aufbaut springt der Ping verzehnfacht sich der Ping, 300+ statt 30. Besonders lahm ist der Zugriff auf Netzwerkfreigaben auf Windows Server. RDP geht zwar, man merkt aber trotzdem die Verzögerung. Das übertragen von 30 MB dauert 10 Minuten und lastet die Leitung irgendwie komplett aus. Jemand eine Idee an was sowas liegen könnte und was man hier tun kann um die Performance zu verbessern?

Delegation immer über Gruppen machen und dann über den Wizard oder wenn es feiner sein soll über ADUC.

Ihn auf der anderen Seite auch löschen.

Nein, haben wir nicht im Einsatz.Ist vermutlich vernünftig die Mailboxen umzuziehen. Da kann ich bei der Gelegenheit auch die Datenbank aufteilen. Die ist mittlerweile bei 210 GB angekommen, Best Practice ist 200 GB und auch wegen Backup und Restore vermutlich vernünftiger das auf 2-4 Datenbanken aufzuteilen.

Wir haben einen Exchange 2010 mit aktuellem Patchstand. Seit rund einer Woche erhalte ich eine Warnung das etwas mit der Datenbank nicht stimmt. Ich habe bereits das Wartungsfenster verlängert, was leider nichts gebracht hat. Als Lösung wird noch ein offline defragt empfohlen. Ich könnte vermutlich auch die Mailboxen umziehen. Die Mailbox Datenbanken ist rund 210 GB groß. Jemand eine Idee wie lange es bei dieser Größe, in etwa, es dauer könnte eine Offline Defragmentierung durchzuführen? Habe ich noch andere Optionen um die Warnung wegzukriegen? Log Name: Application Source: ESE Date: 20.11.2014 00:47:33 Event ID: 629 Task Category: Performance Level: Warning Keywords: Classic User: N/A Computer: Exchange1.ub.uni-muenchen.de Description: Information Store (4136) Exchange1 MBX DB 1: Database 'F:\DB1\DB1.edb': While attempting to move to the next or previous node in a B-Tree, the database engine skipped over 10480 non-visible nodes in 41 pages. In addition, since this message was last reported 26 hours ago, 0 other incidents of excessive non-visible nodes were encountered (a total of 0 nodes in 0 pages were skipped) during navigation in this B-Tree. It is likely that these non-visible nodes are nodes which have been marked for deletion but which are yet to be purged. The database may benefit from widening the online maintenance window during off-peak hours in order to purge such nodes and reclaim their space. If this message persists, offline defragmentation may be run to remove all nodes which have been marked for deletion but have yet to be purged from the database. Name: MSysObjects Owning Table: MSysObjects ObjectId: 2 PgnoRoot: 4 Type: 2 Unversioned Deletes: 10480 Uncommitted Deletes: 0 Committed Deletes: 0 Non-Visible Inserts: 0

VLANs in den VMs konfiguriert man an den VMs: http://blogs.technet.com/b/keithmayer/archive/2012/11/20/vlan-tricks-with-nic-teaming-in-windows-server-2012.aspx

Exchange 2003 ist EOL. Was zu beschreibst ist aber vermutlich eher Zufall.

Alter Bug wieder aktuell? http://support.microsoft.com/kb/KbView/2971014

Ich nutze dafür Syncplicity.