NilsK

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

Moin, OK. Dann siehe meine Handlungsempfehlung. Wenn es um eine spezielle Software geht, die Windows 2003 braucht, könnten die DCs ja trotzdem mit einem supporteten Betriebssystem laufen. Würde die Fehlerbehebung - gerade bei einer wichtigen Applikation - dann doch erleichtern. Gruß, Nils

Moin, "ungleiche" Verteilung der Anmeldungen auf mehrere DCs ist i.d.R. kein Problem. Es gibt keine "Normalverteilung". Ebenso gibt es auch kein "Failover", wie der TO das vermutet. Gruß, Nils

Moin, der ganze Aufbau hört sich überhaupt nicht gut an. Man will keinen DMZ-Server, der eine Verbindung ins LAN hat. Schon gar nicht will man da mit Kennwörtern arbeiten, die in einem Skipt hinterlegt sind. Und einem Skript-User lokale Adminrechte zu geben, ist ein No-go, vor allem in der DMZ. Also, wie Sunny61 schon sagt: Klären, was denn wirklich erreicht werden muss. Und dafür eine Lösung finden, die mit dem DMZ-Konstrukt kompatibel ist. Gruß, Nils

Moin, sind die DCs nur DC oder führen sie noch andere Software aus? Was ist nach dem Hardwareausfall passiert? Wurden die Server nur wieder eingeschaltet? Oder habt ihr was anderes gemacht, z.B. ein Image zurückgespielt? Sofern die DCs nur DC sind, ist es normalerweise am besten, den defekten DC abzuschalten und aus dem AD zu löschen. Da es sich um Windows 2003 handelt, muss man dazu ntdsutil nutzen, der Vorgang ist aber dokumentiert. Könnte allerdings sein, dass man die zugehörigen KB-Artikel nicht mehr ohne Weiteres findet. Die FSMO-Rollen kann man auf einen der anderen DCs übertragen, dabei im GUI bestätigen, dass der alte Server nicht mehr erreichbar ist. Oder mit ntdsutil und seize arbeiten. Der alte Rolleninhaber darf dann nicht mehr online gehen (Netzwerkkabel entfernen und nicht wieder anstecken). Gruß, Nils

Moin, mir scheint, ihr solltet eure Prozesse noch mal prüfen. Es sollte schon Einigkeit und Überblick herrschen, wie eure Infrastruktur aufgebaut ist. Dann: nslookup ist nicht geeignet, um die Namensauflösung von Clients zu prüfen! nslookup arbeitet völlig anders als der Client-Resolver. Die erste Prüfung sollte immer mit ping erfolgen. In praktisch allen Fällen dieser Art, die ich in den letzten 20 Jahren unterstützt habe, lag das Problem an falscher DNS-Konfiguration auf Clientseite. Dem würde ich an deiner Stelle also noch mal mit einer genauen Detailprüfung (und nicht nur Vermutungen) nachgehen. Gruß, Nils PS. und nein, entferne nicht den GC. Der hat, wie DocData richtig sagt, mit dem Problem nichts zu tun. Und jeder DC hat GC zu sein, in praktisch jeder Umgebung.