NilsK

Moin, meine Idee wäre, dass du mal nachliest, wozu das Cmdlet da ist, das du da verwenden willst. Eine weitere Idee wäre, dass du, wenn du das passende Kommando nicht kennst, eine passende Anfrage an eine Suchmaschine stellst. Hier ein Beispiel: https://duckduckgo.com/?q=powershell+add+domain+group+to+local+group&ia=web Gruß, Nils

Moin, klingt auch einigermaßen widersinnig. Der Witz bei Containern ist Modularisierung und bedarfsweise Skalierung auf Basis von Microservices. Nicht eben die Welt, in der sich selbst betriebene KMU-Software findet. Gruß, Nils

Moin, "Wir haben kein Testsystem." "Doch, haben Sie. Sie haben kein Produktionssystem." Gruß, Nils

Moin, ein Reverse Proxy spielt auf einer anderen Ebene und hat mit dem Hypervisor nichts zu tun. Vereinfacht gesagt, nutzt man einen Reverse Proxy meistens, damit Anwender von "außen" auf ein System einen Dienst "im LAN" zugreifen können, das also eben nicht in einer DMZ steht. Exchange ist (bzw. war) ein typisches Beispiel für sowas. Eigene Hypervisoren für die DMZ richten Kunden leider viel zu selten ein. Aus meiner Sicht ein schwerer Fehler. Gruß, Nils

Moin, kurz gesagt: Die VMs sind auf dem Host zwar weitgehend, aber eben nicht vollständig voneinander isoliert. Aus Sicherheitssicht widerspricht es also dem Prinzip der Trennung, das man ja mit einer DMZ erreichen will, wenn man Dienste (also VMs) der verschiedenen Zonen auf demselben Host betreibt. Oder wie ich vor vielen Jahren bei Rati*pharm schrieb: [Hyper-V: Firewall virtuell betreiben? | faq-o-matic.net] https://www.faq-o-matic.net/2015/06/10/hyper-v-firewall-virtuell-betreiben/ Gruß, Nils

Moin, naja, das mit dem Servicepack galt mal, als es noch kein laufendes Update-Management gab. Gibt es heute, daher würde ich an der Stelle eine Abwägung machen. Mal grob gesagt: Das Jahr, das das OS im Namen führt, hat noch nicht angefangen. Das deutet nicht auf einen hohen Reifegrad hin. Ein VM-Host muss "rock solid" laufen. Alle Hersteller müssen ihn wirklich supporten, nicht nur auf dem E-Paper. Auf der anderen Seite sagst du, dass die neuen Features gar nicht von Interesse sind. Da man in einem Host-Cluster heutzutage sehr einfach rollierend aktualisieren kann, würde ich dem Kunden empfehlen, erst mal 2019 zu nehmen und in ein paar Monaten noch mal einen Tag in ein Upgrade zu stecken. Nur meine 0,02 Euro, Nils

Moin, faktisch ist Branch Cache ein Read-only-System. Sobald es Schreibzugriffe gibt, gehen die am Cache vorbei über die "langsame" Leitung - und sie lösen dann einen Resync aus, sodass die Leitung temporär noch langsamer wird. Prinzipbedingt gibt es dann immer noch eine Latenz, weil die gecachten Daten ja veraltet sein können - also sorgen nicht nur Schreibzugriffe aus derselben Lokation für Verzögerungen, sondern alle Änderungen an den Daten. Die Latenz kann natürlich auch Inkonsistenzen und Datenverluste erzeugen wie jedes asynchrone Replikationssystem. Aufgrund dieser Einschränkung gibt es eigentlich so gut wie kein Problem, das Branch Cache sinnvoll lösen würde. Gäbe es wirklich einen so großen Anteil an unveränderlichen Daten, dass Branch Cache seinen Vorteil ausspielt, dann wäre es fast immer einfacher, diese Daten mit einem simplen Copy-Job in die Filiale zu übertragen. Gibt es aber ohnehin so gut wie nie, sodass schon das Kernszenario für die Technik entfällt. Ähnlich wie bei zahlreichen anderen Branch-Techniken habe ich auch Branch Cache in der Praxis noch nie angetroffen bzw. Kunden, die danach fragten, in wenigen Minuten davon wegberaten. Wenn Bandbreite ein Thema ist, ist es fast immer besser, die User zu den Daten zu holen (Remote Desktop, Citrix) als die Daten irgendwie zu den Usern zu bringen. EDIT: ich ergänze noch mal - okay, ich korrigiere dich: Es gibt kein Delta-Writeback. Sowas kann SMB nicht. (https://docs.microsoft.com/en-us/windows-server/networking/branchcache/branchcache#bkmk_handles), Hervorhebung von mir Gruß, Nils

Moin, Seid ihr euch sicher, dass ihr das wollt? Was ist denn das Szenario? Ich frage deshalb, weil Branch Cache für die meisten Unternehmen ausgesprochen uninteressant ist. Gruß, Nils

Moin, also ... was immer euer Retrospect da macht, aber zumindest der SQL Server Express, der für eure Wawi in Betrieb ist, sollte ja auch auf VSS reagieren und ein einfaches Backup nicht verhindern. Unabhängig davon, sollte man Datenbanken aber auch nicht per Dateisicherung "sichern", sondern über deren Backupschnittstelle. SQL Server Express hat eine, SQL Anywhere auch. Bei so einem "ordentlichen" Backup führen die meisten Datenbanksysteme zumindest einfache Prüfungen der Datenbank aus, sodass mögliche Fehler auffallen würden. In Umgebungen, wo die Dienste für das Backup einfach gestoppt werden, fallen Fehler in den Datenbanken oft nicht auf und machen sich erst dann bemerkbar, wenn man nicht mehr reagieren kann. Und in solchen Fällen sind dann die "Backups", die ja reine Dateikopien sind, auch nicht mehr brauchbar, weil der Fehler ja schon drinsteckt. Gruß, Nils

Moin, oh, ich hol schon mal das Popcorn raus. (Spoiler: WINS ist ein bekanntes konkretes Sicherheitsrisiko, das auch nicht mehr gefixt wird.) Rein technisch ist das recht simpel: Neuen WINS-Server einrichten, dessen IP-Adresse bei allen Clients eintragen (das ist der relevante Punkt). Ein paar Tage später den alten WINS abschalten. Keine Replikation für den Umzug. Gruß, Nils

Moin, Umsteigen auf Microsoft 365. Gruß, Nils

Moin, außer Microsoft wird dir das niemand sagen können. Und die sagen es nicht. Gruß, Nils

Moin, eigene Erfahrung habe ich damit nicht, aber da dieses Dokument Bitlocker auf physischen DCs empfiehlt, scheint es mir zumindest keinen generellen Ausschluss zu geben. (Oder anders gesagt: ein bedauerlicher Einzelfall - oder noch anders: vermutlich lohnt es, weiter nach dem Problem auf der Maschine zu forschen.) [Securing Domain Controllers Against Attack | Microsoft Docs] https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack Gruß, Nils

Moin, ceterum censeo: das heißt im Zweifel gar nichts. nslookup macht eine Datenbankabfrage, keine Namensauflösung. Das ist was anderes. Wenn das eine funktioniert, kann das andere immer noch fehlschlagen. Gruß, Nils

Moin, hui, du probierst gern wild rum oder? Wo stehen denn die Verzeichnisse, in die das Skript speichern soll? Falls die noch in keiner Variablen stehen, musst du die eben definieren. Irgendeine Logik wird es ja geben, nach der der Speicherort zu bilden ist. Hier versuchst du, die Datei an dem Ort zu speichern, der durch $files angegeben wird. Wenn du jetzt aber mal oben in deinem Skript guckst, was in $files steht - dann siehst du, dass das ein Array ist, das sämtliche Dateiobjekte aus dem Suchpfad enthält. Ist also eher unwahrscheinlich, dass das klappt. Dein Skript hat keine Variable, die den Dateinamen enthält. Und ganz nebenbei: Es enthält auch keine Schleife, die alle Dateien wirksam durchgehen würde. Die betreffende Schleife (wenn man von den Syntaxfehlern absieht) weist nacheinander den Inhalt jeder Datei derselben Einzelvariable zu, sodass diese vermutlich am Ende nur den Inhalt der letzten Datei im Ordner enthält. Gruß, Nils

Moin, nein. In $NewRawXML steht der Inhalt der Datei, den du geändert hast. In der Save-Methode brauchst du aber den Dateinamen, unter dem die Datei gespeichert werden soll. Das ist in Olafs Beispiel ja auch gut zu sehen. Gruß, Nils

Moin, ja, der fehlt dir ja auch. Er kann aber sehr simpel sein, so in der Art: $NewRawXML | Out-File 'c:\Pfad\Dateiname.xml' Statt des festen Pfads dann eben eine passend zusammengebaute Variable. Gruß, Nils

Moin, das Objekt $NewRawXML enthält die Daten, die du verändert hast. Also musst du dieses Objekt in eine Datei schreiben. Zumindest ist das die Methode, die zum Rest deines Skripts passt. Gruß, Nils

Moin, ich habe keine Ahnung. Es ist wahrscheinlich, dass der Cluster nichts damit zu tun hat, sondern die Kommunikation mit dem SAN an der Stelle nicht richtig läuft. Da ich vor über zehn Jahren das letzte Mal mit Pass-through-Disks zu tun hatte, kann ich beim Troubleshooting nicht unterstützen. Gruß, Nils

Moin, vermutlich "sorgt" niemand ausdrücklich dafür, sondern da funktioniert halt was nicht. Wie du es jetzt konkret anstellst, kann ich dir mangels Detailkenntnissen der Umgebung nicht sagen. Ich würde jedenfalls den Weg verfolgen, das Storage komplett per VHDX an die VMs anzubinden. Gruß, Nils

Moin, da ist der Fehler. Pass-through macht man nicht. Hat praktisch nie Vorteile, und einen Teil der Nachteile siehst du ja jetzt. Denke schon. Bevor wir über Rechnungen sprechen - Fragen kannst du hier gern stellen. Wenn es in einem Forum nicht mehr gut zu machen ist, werden wir dich drauf hinweisen. Gruß, Nils

Moin, er schrob doch: Gruß, Nils

Moin, hm, ja, wenn man es so liest ... da bin ich wohl nach 22 Jahren Active Directory etwas vorgeprägt. Gruß, Nils

Moin, Da spricht so viel dagegen, dass man gar nicht weiß, wo man anfangen soll. Erstens: ein DC ist niemals ein Host, und ein Host ist niemals ein DC. Zweitens: es gibt keinen Grund, jetzt schon einen DC mit Windows Server 2022 zu betreiben, daher muss man da auch nichts übers Knie brechen. Drittens: es gibt keine gemischte Lizenzierung, du müsstest also alle VMs auf dem Host mit 2022 lizenzieren. Das jetzt erst mal nur die ersten Punkte. Gruß, Nils

Moin, ja, siehst du ... genau das meinten wir mit "nicht einfach irgendwas probieren". Du machst es gerade aktiv schlimmer. Vermutlich war der erste Fehler ein leicht korrigierbares DNS-Problem. Indem du jetzt den alten DC wieder eingeschaltet hast (ein No-go, wenn man dessen Namen schon anderweitig vergeben hat!), hat dessen DNS anscheinend wie erwartet geantwortet. Da der DC aber nicht mehr "er selbst" ist, kannst du dich natürlich dort nicht anmelden. Bei dem neuen wird das möglicherweise jetzt auch nicht mehr gehen. Und wenn du jetzt noch mehr Leichen aus dem Keller holst und aufs Geratewohl irgendwas ausprobierst, wird es mit Sicherheit nur eins: Schlimmer. Gruß, Nils