Doso

Virenscanner auf Hyper-V Host finde ich mittlerweile recht sinnlos, da hier ja nichts weiter laufen soll. Wenn es denn aus irgendwelchen Gründen dann doch einen Virenscanner geben soll, dann sollten die entsprechenden Ausnahmen definiert werden - das hat Microsoft auch recht gut dokumentiert. Vielleicht nimmst du die langsame Geschwindigkeit einfach mal als Anlass von Server2003 wegzukommen, allzu lange ist da eh kein Support mehr drauf.

Man sollte sowas nur abschalten wenn man Probleme hat und dann ggf, wieder anschalten wenn sich dadurch nichts ändert. Ich habe da die selbe Erfahrung gemacht wie du, es ändert sich nichts.

Aktuelle Windows Server sind da sehr robust, das einzige was dadurch verloren geht ist die Netzwerkkarte. Dies bedeutet das man die Netzwerkkonfiguration neu machen muss, vorausgesetzt man hat die Einstellungen fest eingetragen. Gleiches bei Linux, wobei es da je nach Distribution etwas anders ist. Aber du hast Recht, man muss es halt mal ausprobiert haben in seiner Umgebung, sonst hilft das beste Backup nix. Bei uns ist halt eine Ausfallzeit von mehreren Tagen im Ernstfall akzeptabel, es gibt keine vorgegeben RTO und RPO.

Zu sicherende Menge in der VM, ein Verzeichnis, 100 MB. Zu sichernde VM, 40 GB. Unsere Backup Software DPM hat keine Komprimierung, da geht das dann schnell in die TB.

WSUS nutzt nur http/https, die Clients haben dann letztlich Gruppenrichtlinien/Registry Einträge die dann auf die entsprechende WSUS Quelle zeigen. Muss man halt die Gruppen irgendwie pflegen. Das geht natürlich auch im großen Maßstab: https://www.lrz.de/services/security/mwnsus/ Das LRZ betreibt einen WSUS für das ganze Münchner Wissenschaftsnetz, das sind glaube ich hunderte unabhängige Einrichtungen, Rechnerbetriebsgruppen, IT-Abteilungen etc. die sich dann halt auf den WSUS aufschalten können, wenn sie möchten.

Wir sichern nur wenige VMs auf HYPER-V Level, wir sichern mit Agenten die Daten in den VMs. Mein Chef will die kein Budget für die großen Datenmengen lokcer machen, auch wäre die Datenmenge dann ein Problem beim Offsite Backup. Die Hyper-V Hosts an sich werden bei uns gar nicht gesichert, die sind manuell so schnell wieder neu installiert, das lohnt sich nicht, vor allem wenn man sich an die Best Practice hält das ein Host nur ein Host ist, und sonst nix.

1. Ohne mich jetzt mit SOFS auszukennen, würde ich alleine wegen der Übersichtlichkeit her von abraten. Ich bin ja schon beim umziehen von 30 VMs fast durcheinander gekommen bei den ganzen Ordnern und Servern die Teilweise gleich heißen, da würde ich nun nicht auch noch Cluster auf dem Storage mischen. 2. Ja. Mit Shared Nothing Migration, also VM aus dem Cluster rausnehmen, per Hyper-V Manager verschieben und dann im neuen Cluster wieder hochverfügbar machen. Evtl. geht es auch mit Clustering an - gibt hier einen Blog zum Thema, kA ob das auch bei SOFS so klappt: http://www.danielstechblog.de/virtual-machine-manager-live-migration-fehler-smb-3-0-storage/

Und in einer Testumgebung kann man sowas nicht machen? Besser gleich richtig lernen :p

Aktuelles Outlook und vor allem Exchange 2013 Patchlevel habt ihr, ja?

Ich schließe mich einfach mal an: Pop-Connectoren sind pfui. Achja, kein Exchange auf einem DC: http://technet.microsoft.com/de-de/library/ms.exch.setupreadiness.warninginstallexchangerolesondomaincontroller(v=exchg.150).aspx

Bei uns ist es egal ob mit oder ohne Automapping, das Problem tritt nur beim Cached Modus auf. Das ist bei uns der Standard.

Das ist ein Problem mit dem ich schon seit Jahren kämpfe. Mal erwähnt MS mal wieder das sie das in Outlook gefixed haben, paar Monate später kommt es dann wieder. Im Zweifelsfalle richte ich das Outlook Profil bei dem Nutzer neu ein und wenn es gar nicht anders geht schalte ich den Cache Modus aus.

Schon passiert Dunkelmann, und während IBM mal wieder ihren Standard durchgeht, der nix hilft, haben wir die wichtigsten VM aus dem Cluster auf Standalone Host umgezogen. Live Migration auch ohne Cluster ist eine feine Sache. Das ist eine gute Idee. Unsere Hyper-V Hosts haben zwei lokale Platten je 300 GB im RAID1 für das Betriebssystem des Host, kleinere Platten gibt es scheinbar nicht mehr. Da kann man gut noch einen DC lokal ablegen.

Da hast du auch schon den Grund warum wir DCs machen wollen. Unser ach so tolles IBM SAN das ja so schön für die Virtualisierung beworben wird ist nun zum zweiten mal in 3 Monaten kurz vor dem Komplettausfall. Von 6 Servern kommt nur noch einer drauf, und der auch nur noch mit einer von zwei Netzwerkverbindungen. Schöne Redundanz mit 2 Controllern und Hyper-V Cluster, Multipath und alles - und dann hängt sich das SAN auf und lässt sich nicht mehr verwalten und akzeptiert keine neuen Verbinden. Da ist man dann froh das zumindest das anmelden noch über eigenes Bleck funktioniert. Mal sehen ob ich durch diesen fast-Ausfall doch noch einen physischen DC für die anderen Domäne rausschlagen kann.

ÖO Replikation war mit Abstand das ekeligste womit ich mich bei 2003 auf 2010 Migration abgeben musste. Ist einfach Technik von vorgestern. Wenn du das umgehst, tust du dir einen großen Gefallen.

Der Cluster hängt in der Domäne, in der auch der physische DC sein wird, selbiges für das Backup System. Wie gesagt, einen physischen DC habe ich schon rausgehandelt. Geht mir nur um die zweite Domäne, hier bin ich mir nicht sicher das es da einen braucht - und mir fallen auch keine Argumente ein mit denen ich argumentieren könnte.

Das gute alte WINS :]

Bei uns steht das Thema Virtualisierung von Domain Controllern an. Mir ist klar das ich dafür Windows 2012 Hyper-V und Domain Controller oder höher brauche. Weiterhin habe ich nun nach etwas Überzeugungsarbeit meinen Chef so weit das er uns einen physischen DC übrig lässt. Was mir aber nicht klar ist, ist wie viele physische DCs man haben sollte. Wir betreiben 2 Domänen, nennen wir sie mycompany.de, public.mycompany.de mit jeweils 2 DCs. Ich sehe zwei Möglichkeiten: - Ein Physischer DC in mycompany.de, mit Schema Master etc. Rollen, rest virtuell, - Zwei physische DCs, pro Domäne einer, also public.mycompany.de und mycompany.de, den jeweils anderen DC dann virtuell Ich werde dazu leider aus den Best Practices von Microsoft nicht ganz schlau daraus, kann mir hier wer weiterhelfen?

Das Format der virtuellen Festplatte (VHD oder VHDX) hat nicht direkt was mit der VM Generation zu tun. Man kann problemlos VHDX Dateien für Generation 1 VMs verwenden. Machen wir so bei Linux VMs.

Als erstes solltet ihr euch mal intern darüber klar werden was der Unterschied zwischen einer Migration und einem Update/Upgrade ist und welches davon ihr machen wollt.

Solange du genug Zugriffs-CAL hast ist es egal ob du einen physischen Windows Server betreibst, oder 200.

Wir haben bei uns beschlossen das wir Windows Updates mit einem Monat Verzögerung freigeben. Das kann man mit SCCM schön abbilden, mit WSUS muss man dann jedes Update manuell freigeben. Erscheint mir dann etwas als Overkill nur für ein paar Server einen komplett eigenen WSUS zu betreiben.

TMG hat noch Support bis 2020, allerdings wird es schwer das Produkt überhaupt noch zu kaufen. Wir haben unsere TMG Server nach Squid migriert. So bitter es ist das es unter Linux läuft, war einfach die beste Lösung.

Der "alte" SCCM konnte das wohl irgendwie. Hatte befürchtet das der alte das nicht mehr kann. Schade, ist eigentlich ein cooles Feature, werden wir hat die Server wieder mit verschiedenen Gruppen im SCCM versetzt patchen müssen.

Man kann Jahre mit Netzwerken arbeiten, und man denkt man hat alles verstanden - und dann kommt sowas. Ich kann deine Verwirrung gut verstehen, wir hatten hier vor kurzem auch zwei Fälle die mich an mir selbst zweifeln lassen. Wir haben hier den Fall das wir in einem VLAN mehrere /24 Subnetze haben. Beispiel: 192.168.1.0/24 192.168.2.0/24 Dazwischen hängt ein Router/Firewall. Man denkt nun die Clients und Server würden nur über den Router miteinander kommunzieren. Falsch gedacht. Client aus 192.168.2.0 stellt Anfrage an Server in 192.168.1.0. Pakete laufen über Firewall Linux Server antwortet (ARP Cache verbogen) DIREKT, am Router vorbei, an Client in 192.168.2.0 Firewall verwirft Rückantworten des Clients da sie die es die ursprüngliche Verbindung nicht "gesehen" hat Kommt nur hin und wieder, und nur im Zusammenspiel mit Linux Servern vor. Wir hatten einen externen Consultant da, der war darüber auch überrascht. Einzige Lösung ist ein größerer Umbau des Netzwerks, damit nur noch ein Subnet pro VLAN gilt. An Routern gibt es auch die Funktion "Proxy-Arp". Subnetz Maske richtig wäre 255.255.255.252, eingetragen war 255.255.255.0. Kommunikation hat jahrelange funktioniert, bis jemand die Funktion abgeschaltet hat, dann waren einige Teilnetze nicht mehr erreichbar.