DocData

Auf diesem Wege (okay, automatisiert mittels Orchestrator) in zwei Umgebungen realisiert: Einmal 3000 VMs, einmal knapp 8000 VMs. Fehlerquote (extra nachgeschaut) 0,02% bzw. 0,0375%. Also rein statistisch wäre das per Habd langsamer und fehleranfälliger gewesen... Aber, und das ist ganz klar, dein Ansatz führt genau so zum Erfolg wie meiner.

Also womit Zahni aber in jedem Fall Recht hat: Alte NIC entfernen. - CMD öffnen - set DEVMGR_SHOW_NONPRESENT_DEVICES=1 - devmgmt.msc - Ausgeblendetete Geräte anzeigen lassen - als leicht durchsichtig erscheinenden NICs löschen

@ Zahni Man kann sich das Leben halt auch kompliziert machen.

Kiste herunterfahren und dann per PowerCLI Get-VM NAME | Get-NetworkAdapter | Set-NetworkAdapter -Type Vmxnet3 Die Mac-Adresse bleibt gleich. Gibt aber trotzdem einen neuen Adapter. Die Karte vorher auf DHCP umstellen. Sonst moppert Windows das es eine weitere Karte im System gibt, welche die gleiche IP hat.

Von der NSA.

Nie erlebt. Wenn es Ärger gab, dann weil der oder die Ports keine Edge-Ports waren, also dank STP 15 bis 30 Sekunden offline waren. Da hat jemand seinen Job einfach nicht richtig gemacht.

Ist supported. Alles andere wäre sehr, sehr lächerlich.

Das ist so, als wenn man einen Drogendealer fragt ob die gerade gekauften Drogen gesundheitsschädlich sind... Tur mir leid. Aber das habe ich in all meinen Jahren bei IT-Dienstleistern gelernt: Pre-Sales bei Herstellern und Distributoren können NICHTS. Die haben keine Ahnung. Niemand von denen hat Ahnung. Die lesen dir im zweifelsfall die Specs vor. Das wird dein Problem sein.

Ein MOC Kurs reicht nicht um eine Zertifizierungsprüfung zu schaffen. Dazu werden dort einfach nicht alle Inhalte vermittelt.

Das Ding ist einfach unsupported. Ich sehe da keinen Grund das zu reparieren. Wirf das alles weg und nimm Exchange 2013 oder Exchange 2016.

Microsoft Azure.

Die Kiste hat einen Memorydump geworfen. Treiber oder defekte Hardware.

Defrag macht auf SSDs übrigens nix, außer TRIM zu starten. Da wird nix neu organisiert.

Ah, spielen wir heute mal wieder das Lied von der nicht vorhandenen Backup API und der 32 GB Grenze... Wie putzig... Soll ich jetzt mit einem lächerlichen Memory Management (Dynamic Memory ist ja wohl ein Witz...), fehlender GUI und nahezu unbrauchbarer CLI/ Fernadministrationswerkzeugen und der ziemlich wirren und unintuitiven Netzwerkunterstützung argumentieren?? Die freien Hypervisor von VMware und Microsoft sind was für zu Hause oder Umgebungen, in denen ich das oben genannte nicht brauche. Für alle anderen Fälle gibt es die kostenpflichtigen Varianten. Na ja. Und selbst wenn wir die vergleichen ist Hyper-V dann doch... irgendwie... gewollt, aber nicht gekonnt.

Round-Robin ist nur so lange toll, wie alle Systeme dahinter erreichbar sind. Ist eines down, dann landen (ausgehend von zwei Zielen), 50% deiner Anfragen im Nirvana. Bei drei Zielen immerhin 1/3, bei 4 Zielen 1/4 usw.

Ähh... ja. Da wäre Hyper-V doch eher eine merkwürdige Wahl. Vermutlich würde ich da sogar eher in Richtung KVM oder so tendieren.

Was ist eine "2 Arm Lösung"? Postfix und HA Proxy können das (wenn's halt nichts kosten darf...). Ansonsten such die einen beliebigen LB deiner Wahl. Das ist jetzt keine total abgefahrende Anforderung.

Der Core Server ist sowas von sinnlos... Ich kann Nils nur zu 100% zustimmen.

Sehen so die richtigen Voraussetzungen für eine hochverfügbare SQL Umgebung aus?? - musste eh neu gemacht werden - Cluster fand ich lustig und wollte mich mal damit beschäftigen - HW/ SW war eh vorhanden Ich weiß ja nicht...

Stellen wir die Frage mach RTO und RPO. Was ist gefordert?

Das kommt auf die Anforderungen an.

Der Serverschrank im Papierarchiv wird mit ziemlicher hoher Wahrscheinlichkeit durch jede Brandschutzprüfung fallen. In der Regel reichen schon im Serverraum/ RZ gelagerte Kartons. Am Ende ist es eine versicherungstechnische Frage. Brennt es bei euch und der Brand ging vom Serverschrank aus, dann wird die Versicherung mit hoher Wahrscheinlichkeit nicht zahlen (oder sich zumindest wehren), da euer Handeln zumindest fahrlässig war.

Da hast du natürlich uneingeschränkt Recht!

Das ist aber das was die Kunden interessiert. Ich kann in meine Produktbestimmungen viel reinschreiben, oder auch in meine AGBs. Am Ende ist es eine juristische Beurteilung. Natürlich darf man die Produktbestimmungen nicht total ignorieren. Aber wie gesagt: Am Ende kann Microsoft da viel reinschreiben.

Das ist nicht der Punkt. Der Punkt ist, ob die Produktbestimmungen juristisch einwandfrei sind.