NilsK

Moin, in dem Fall wäre zu erwarten, dass du im Log des Taskplaners einen Hinweis findest, warum es nicht geht. Gruß, Nils

Moin, das kann man sich, wenn man viel Zeit hat, sicher ansehen. Aber mit welchem Ziel? Das solltest du vielleicht dazu sagen. Für den Einstieg würde ich eher das Buch von Edward Horley empfehlen - das ist auch englisch, aber praxisnah. Es geht hier ja nicht um die Anatomie möglicher Angriffe, sondern um praktische Fragen. Solange es keine Provider-Anbindung per IPv6 gibt, stellt das Protokoll keinen Einfallsweg dar. Die Tunneltechniken (6to4, ISATAP und Teredo) sollte man abschalten, was per GPO, PowerShell oder netsh geht. Gruß, Nils

Moin, nur, damit ich mit meiner eingeschränkten Sichtweise es vielleicht noch verstehe: Wenn du ohnehin der Meinung bist, dass diese Berechtigung nutzlos ist, weil du keine Apps brauchst und willst und das ja alles Teufelswerk ist - warum entfernst du nicht einfach den Eintrag dort, wo die Vererbung beginnt (%ProgramFiles% und %ProgramFiles(x86)%)? Dann bist du ihn ohne weitere Klimmzüge einfach los. Oder geht es dir gar nicht um eine sinnvolle Lösung, sondern nur um den Weg, den du einmal eingeschlagen hast? Gruß, Nils

Moin, ach je. Nicht schon wieder diese Diskussion. Wenn du wüsstest, wie oft wir hier an irgendwas rumlaborieren, nur um hinterher festzustellen, dass man mit Kenntnis der Hintergründe viel schneller zu einem besseren Ergebnis gekommen wäre. Du kannst uns glauben, dass wir auch unsere Erfahrungen haben. Gruß, Nils

Moin, wenn man rangehen will: Als Best Practice gilt, im Unternehmen die IPv6-Tunneltechniken abzuschalten, weil man die in aller Regel nicht haben will. Ausnahme ist DirectAccess. Gruß, Nils

Moin, vielleicht wird das Laufwerk durch den Task ja auch verbunden, dann aber in die Session des Accounts, der den Task ausführt. Wenn das nicht dein Account ist, siehst du das Laufwerk natürlich auch nicht. Ein anderes Konzept ließe sich sicher finden, wenn man die Umgebung und die Applikation kennt. Das ist dann aber eine Designaufgabe, die in einem Forum (noch dazu einem öffentlichen) nicht richtig platziert ist. Gruß, Nils

Moin, dagegen spricht auch nichts. Wenn man ein Produkt gut kennt, ist das ein valider Grund, es einzusetzen. Aber: Auch wenn es in Detaildiskussionen dieser Art manchmal so aussieht, als sei Hyper-V irgendwie nicht reif, dann ist das ein falscher Eindruck. Bis in den gehobenen Mittelstand hinein kommt man mit den Bordmitteln sehr gut klar, auch wenn sie vielleicht nicht so komfortabel sind wie das vCenter. Bevor man dann zum teuren und komplexen SCVMM greifen muss, gibt es auch Alternativen wie den 5Nine Manager, mit dem der Komfort dann für das Tagesgeschäft weit an vCenter heranreicht (aber für deutlich weniger Geld). Funktional spielen vSphere und Hyper-V in derselben Liga - für praktisch alle relevanten Anwendungsfälle. Gruß, Nils PS. Ich betone das deshalb, weil sich die Diskussion hier gerade in eine Pro-/Contra-Richtung entwickelt hat.

Moin, Berechtigungen würde ich nur und ausschließlich mit SetACL automatisieren. Gruß, Nils

Moin, es gilt die dringende Empfehlung, IPv6 aktiv zu belassen. Die Autokonfiguration sorgt dafür, dass es im eigenen Netzwerk (normalerweise) problemlos funktioniert. Microsoft testet schon seit vielen Jahren nicht mehr ohne IPv6, daher kann es bei Abschalten zu seltsamen Problemen kommen, die Microsoft dann auch nur eingeschränkt unterstützt. Ausnahmen sollte man nur machen, wenn es wirklich angezeigt und begründet ist. Wichtig aber: Spätestens wenn der Provider IPv6 bereitstellt, muss ein Gesamtkonzept für IPv6 her. Da das aber (bei Firmen) nicht einfach so geschieht, kann man das i.d.R. dann in Ruhe planen. Bis dahin: Don't touch, don't switch off. Gruß, Nils

Moin, Wenn du die Autorisierung wieder​ weg nimmst, müsste sich der Server weiter einrichten lassen, ohne dass er antwortet. Oder eben die Firewall. Möglichkeiten gibt es genug. Gruß, Nils

Moin, nein, die Bordmittel zur Verwaltung sind da leider sehr beschränkt. Das kritisieren wir aus der Community schon seit langem gegenüber Microsoft. Die offizielle Antwort ist: Wer Management braucht, soll den SCVMM nehmen. Allerdings ist das in dem Fall in der Praxis auch kein ernsthaftes Thema. Das muss man ja nicht dauernd machen, sondern nur in dem Fall, wo neue* (oder eben ältere) Host-CPUs hinzukommen, und dann ist es einmalig. Wer da auf der sicheren Seite sein will, setzt das Flag von vornherein und muss sich dann später nicht mehr kümmern - was dem Zustand unter vSphere entspricht. In der Praxis reicht auch die Granularität "ein oder aus" völlig hin, ich habe noch keinen Kunden getroffen, der wirklich einzelne Features nach CPU-Modell ein- oder abschalten musste (was bei vSphere ja auch eher vorgegaukelt ist). Gruß, Nils * um das noch zu ergänzen: Wenn eine neuere CPU hinzukommt, muss man das Flag nicht zwingend setzen. Man muss es nur dann setzen, wenn man VMs von einem "neuen" auf einen "älteren" Host live migrieren können möchte. Daher kann es durchaus auch Sinn ergeben, das nur selektiv pro VM zu setzen und nicht global. Im Fall von HA (Failover nach Host-Ausfall) braucht es den Haken gar nicht, weil dann die VM ja auf der jeweiligen CPU neu bootet.

Moin, im Wesentlichen schon. Ist ja kein besonders aufwändiger Vorgang. Prinzipiell würde ich alles, was auf Host-Ebene anliegt, vor der Installation von Hyper-V und dem Cluster tun, auch wenn das seit Windows 2012 nicht mehr ganz so wild ist. Also: alten HyperV entfernen vom Cluster neuen Host installieren (OS) inkl. Treibern und Updates Netzwerkkarten vorkonfigurieren MPIO Treiber installieren Storage-Verbindung herstellen Hyper-V-Rolle aktivieren Hyper-V-Grundkonfiguration inkl- vSwitch(es) vornehmen Failovercluster-Feature installieren HyperV zum Cluster hinzufügen ... was im Wesentlichen ja dieselben technischen Einschränkungen wie unter Hyper-V sind. Eine laufende VM kann nicht den Prozessor runterstufen, das ist der springende Punkt. Der Unterschied ist nur, dass vSphere das auf anderer Ebene setzt. Das hat sowohl Vor- als auch Nachteile. Gruß, Nils

Moin, wenn du den Namen aus dem DNS usw. entfernst, kannst du ihn wiederverwenden. Darin sehe ich allerdings auch keinen Sinn. Wozu würde man einen identischen Hostnamen benötigen? Sofern man die CPU-Kompatibilität umschalten muss, geht das in Hyper-V nur bei abgeschalteter VM. Es gibt dort keine Host-übergreifende Einstellung. Wenn man dies in vSphere nachträglich ändern würde, müsste man dort aber die VMs auch herunterfahren, weil sie sonst ja von der "falschen" CPU ausgehen. Ob das tatsächlich nötig ist, kann man aber auch einfach testen: Live Migration beginnen. Wenn die CPU nicht kompatibel ist, warnt Hyper-V und verweigert den Vorgang. In dem Fall muss man dann eben umschalten. Das ist in Hyper-V auch so, denn die VM sieht ja immer die reale CPU. [Was die Prozessorkompatibilität in Hyper-V wirklich tut | faq-o-matic.net] https://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/ Gruß, Nils

Moin, solange die CPU dieselbe "Hersteller-Achitektur" hat (kurz: nur Intel oder nur AMD), ist eine neuere CPU kein Problem. Man muss dann nur das Häkchen für die CPU-Kompatibilität bei allen VMs setzen, die evtl. live migriert werden sollen. Dafür muss man die jeweilige VM einmal kurz runterfahren. Kann man auch automatisieren: [Hyper-V-VMs per Skript umkonfigurieren | faq-o-matic.net] https://www.faq-o-matic.net/2015/07/15/hyper-v-vms-per-skript-umkonfigurieren/ Die Reihenfolge für den Austausch ist technisch egal und ein organisatorisches Thema. Sofern drei Nodes an dein Storage passen, würde ich erst den neuen hinzufügen, dann die VMs migrieren und dann den alten entfernen. Gruß, Nils

Moin, was meinst du genau? Die Konfiguration von DHCP ist doch ohne Autorisierung möglich, wenn ich mich nicht ganz falsch erinnere. Gruß, Nils

Moin, es gibt FSMO-Rollen. Aber es gibt keinen PDC. Es gibt einen "PDC-Emulator" (bisweilen "PDCe" genannt), dessen namensgebende Funktion mit dem Tod von WIndows NT aber entfallen ist. Jetzt zentralisieren sich dort ein paar Nebenaufgaben. Aber diese Rolle hat nichts mit dem ehemaligen PDC-Konzept zu tun. Auch in die Handhabung des Kennworts ist der PDCe nur am Rande involviert. Die Durchführung liegt bei dem DC, der halt gerade angefragt wurde, also nicht zentral. Gruß, Nils

Moin, da Windows intern immer mit UTC arbeitet und die Zeit abhängig vom lokalen Schema nur anders anzeigt, ist das kein Problem. Es gibt allerdings im AD keinen PDC, schon seit gut 17 Jahren. ;) Gruß, Nils

Moin, das Problem könnte das Leerzeichen sein. Dein Skript übergibt den Namen als Text. Besser wäre es, in der PowerShell immer ein Objekt zu übergeben. Gruß, Nils

Moin, wobei der Tombstone nicht stört. Sobald der bestehende Name aus der aktiven Konfiguration und aus DNS gelöscht ist, kann man ihn wiederverwenden. Das würde ich aber nur machen, wenn es harte Gründe dafür gibt. Eigentlich sollte man ein AD lieber so bauen, dass die Namen der DCs nirgends benötigt werden. Gruß, Nils

Moin, wie gesagt: Solange ein Windows-DHCP nicht autorisiert ist, antwortet er nicht. Du könntest zusätzlich die Firewall so konfigurieren, dass DHCP weder rein- noch rausgeht. Gruß, Nils

Moin, ja, kann man machen. Man kann allerdings auch einfach den Scope oder den Dienst deaktiviert lassen, solange er nicht arbeiten soll. Bei Migrationen machen wir üblicherweise beides - deaktivieren und de-autorisiert lassen. Nur aus Vorsicht, doppelter Boden und so - ein falsch antwortender DHCP ist echt ärgerlich. Man kann einen DHCP auch per Textfile vorbereiten (netsh). Eine Freude ist das nicht, aber eben bei Migrationen usw. durchaus praktisch. Wir haben z.B. auch DHCP-Server mit aufwändiger Konfig im Lab vorbereitet und dann per netsh aufs produktive System übertragen. Gruß, Nils

Moin, es ist dieselbe Frage wie die von zahni, mit demselben Hintergrund. Viele nutzen DFS-R für Ausfallsicherheit oder Lastverteilung, und dafür ist es in den meisten Fällen gar nicht geeignet. Das ist das technische Ergebnis, aber was ist das Ziel? Warum soll der einen identischen Datenbestand haben? Gruß, Nils

Moin, warum macht ihr das? Was wollt ihr damit erreichen? Gruß, Nils

Moin, hat aber mit dem AD nichts zu tun. Gruß, Nils

Moin, mit SetACL kannst du das erledigen. https://helgeklein.com/setacl/ Gruß, Nils