Dukel

Dann eben viel größer (macht es nicht besser). Auf jeden Fall kann man sich nicht darauf verlassen, dass die virtuellen Maschinen nur den Platz verbrauchen, der konfiguriert wurde (mit festen Größen), wenn man Snapshots nutzt.

Zwei (unabhängige) DHCP Server im selben Netz sind immer schlecht. Was hast du denn vor? Möchtest du AD lernen? Hast du einen Testclient? In einer AD Umgebung solltest du als DNS Server nur den oder die DCs bzw. DNS Server für die Domäne nutzen und nicht die Fritz Box. Daher wird es so oder so zu Konflikten kommen, wenn der Server nicht dauerhaft läuft. Funktioniert alles bei manueller IP Konfiguration (egal ob beim Server oder Client)? Achtung! Vergib dabei nur den Server als DNS Server und nicht die Fritz Box.

Und zu Platz Problemen auf der Storage. Angenommen man hat eine Storage mit 100GB und eine vhdx Datei mit 70GB. Die Snapshot Datei kann genauso groß wie die vhdx Datei werden (= 70GB) und dies kann zu groß für die Storage sein. Dies ist auf jeden Fall bei VMware so und vermutlich auch bei Hyper-V.

Läuft der DHCP Server auf der Fritz Box noch? Hast du Forwarder für DNS Konfiguriert? Hast du DNS und Gateway im DHCP Server konfiguriert? Bekommen die Clients diese Informationen? Hast du DNS und Gateway im Windows Server konfiguriert?

Bisher war das Verhalten bei Hyper-V und ESX gleich. Bei einem Snapshot werden Änderungen nicht mehr in die Disk-Datei sondern in den Snapshot geschrieben. Beim zurückfahren eines Snapshots wird die Snapshot Datei einfach gelöscht, bei löschen des Snapshots die Inhalte in die Disk-Datei zusammengeführt. Seit der aktuellen oder in der kommenden Version von ESX wird das verhalten gedreht, da idR öfters ein Snapshot gelöscht wird als auf einen älteren Stand zurückgegangen wird. Dabei wird immer in die Disk-Datei geschrieben und die Änderungen werden mit Protokolliert. Beim Zurückfahren müssen dann auf der Disk-Datei die Änderungen Rückgängig gemacht werden. Dafür geht das löschen eines Snapshots schneller (und mit weniger Last), da dabei nur die Snapshotdatei gelöscht werden muss.

Mit den Installierten Programmen, Ordnern und Freigaben passiert nichts. Evtl. muss man den Besitz von den Ordnern übernehmen, wenn man im nach hinein bestimmte Dinge ändern möchte und vorher nicht entsprechende Rechte vergeben hat oder diese weggenommen hat. Aber per Default haben alle Administratoren Vollzugriff auf diese Ordner. Aber übernehmen von Rechten (bzw. vom Besitz) geht auch im Nachhinein.

Den Parameter sollst du beim normalen Outlook Start anhängen.

Ihr braucht keine CAL für einen Benutzeraccount. Es zählen nur die (Menschlichen) Benutzer (bzw. Geräte). Es ist eh sinnvoller die Administration nicht mit "dem Administrator" zu machen.

Hast du schon mal den Parameter /recycle bei outlook.exe getestet?

Wieso will man Mails über Outlook verschicken? Wieso keine direkten Mails per SMTP oder anderen APIs?

Hat der Controller keine BBU?

Der Schreibcache ist das was man will. Wieso sollte man den abschalten?

In diesem Fall wird die Applikation nicht auf dem Server sondern Lokal ausgeführt. Das ist gar nicht mit einem Terminal Server (heißt mittlerweile Remote Desktop Services) vergleichbar.

Wenn du Benutzer sperren willst sperrst du das Zertifikat. Wenn z.B. dieses Zertifikat in anderen Diensten genutzt wird musst du das dann in allen Diensten sperren.

Ist der Server schon produktiv? Laufen die Dienste schon? Kannst du testweise beide VMs auf 1vCPU und 4 GB Ram konfigurieren und das Testtool nochmal laufen lassen? Kannst du mit z.B. sqlio die Disk Performance testen?

Kann der Hardware Hersteller helfen? Kannst du bei diesem ein Ticket aufmachen?

Du weisst einem Dienst ein Zertifikat zu und dieses wird dann genutzt. Das kannst du auch in der IIS Konfiguration überprüfen (Nur überprüfen, nicht ändern!).

Haben die Standorte eine Netzwerkverbindung (VPN oder direkt)? Wie lang ist der Umzug geplant?

Fast richtig. Es werden alle benötigten Updates genehmigt außer Language Packs.

K.a. Ich würde dir empfehlen dich über Zertifikat zu informieren und dies einmal in einer Testumgebung mit eigener eigenen PKI testen (entweder eine Windows CA oder mit der Anleitung von Testperson). Alternativ kannst du dich sicher an den Support von Comodo wenden. Ich kann dir nicht sagen ob dieses Zertifikat wirklich funktioniert, das wäre aber das Naheliegende.

So wie es aussieht ist das bei Comodo https://ssl.comodo.com/personal-authentication.php Die Clientzertifikate haben nichts mit dem Serverzertifikat zu tun. Wichtig ist das Root Zertifikat bzw. intermediate Zertifikat.

Sieht das kompliziert aus. Nutze Robocopy mit dem Parameter für "only Newer". Dann reicht eine Zeile.

Du solltest dich mal über die Grundlagen informieren. Das ganze soll die Sicherheit erhöhen und nicht, durch Fehlkonfiguration, herunter setzen. Es gibt bei Zertifikaten unterschiedliche Typen. Es gibt Serverzertifikate. Dabei weist sich der Server aus, dass er der ist, der er vorgibt zu sein (dein Wildcardzertifikat). Dann gibt es Client Zertifikate. Dabei weist sich der Client (Rechner oder User) aus, das er derjenige ist (durch den Besitz des Zertifikats). Du musst deinen Clients Zertifikate ausstellen. Dies geht mit einer Windows PKI Automatisch (wenn so konfiguriert) mit anderen PKIs geht das evtl. manuell oder es gibt andere Mechanismen. Am einfachsten ist es, wenn es hoffentlich keine produktive Implementierung sondern ein Test / POC ist, wenn du dir eine Windows PKI aufsetzt (hier reicht eine Einstufige) und das ganze damit testet. Ich würde auch keine Wildcard Zertifikate einsetzen (brauchst du auch gar nicht) sondern höchstens SAN Zertifikate, wenn der Webserver mit mehreren Namen erreichbar sein soll.

Wie die anderen schon geschrieben haben ist eine Migration des Media Agenten kein Problem. Dabei kannst du gleich die Simpana Umgebung auch aktualisieren. Des weiteren würde ich die anderen Programme und Rollen von diesem Server nehmen.

Wieso ein Inplace Upgrade und keine saubere Migration (ggf. auf ein aktuelles OS)?