NilsK

Moin, nun - auch eine späte Einsicht ist eine Einsicht. Schön. Was mich aber noch interessieren würde: Was ist "carryout"? Gruß, Nils

Moin, spontan würde ich sagen, dass die Anführungsstriche um das Pfad-Argument schon in den Aufruf müssen, damit CMD das als einen einzigen Parameter ansieht. Im Batch ist es zu spät. Wie du dir das zurechtfummeln musst, müsstest du selbst rausfinden. Gruß, Nils

Moin, ach, die VM gehörte sowieso mal wieder gestartet. Mach ich ja kaum noch, sowas, bei meinem Jobprofil. Gruß, Nils

Moin, und nur um das noch mal zu untermauern: Ich habe jetzt extra für dich meine DC-VM hochgefahren und mit dem Kommando, das hier genannt wurde, erfolgreich eine Globale Gruppe in eine Domänenlokale Gruppe aufgenommen. Ging problemlos, selbstverständlich. Gruß, Nils

Moin, und eine Fehlermeldung gab es nicht? Doch, geht es. Wenn eine Gruppe Mitglied einer anderen Gruppe ist, dann ist sie ein "Member". Ganz bestimmt. Wir veräppeln hier selten Leute. Gruß, Nils

Moin, sondern? Gruß, Nils

Moin, nun, wir sprechen von Serversoftware ... wer sowas nicht ohne komplexe Installation hinbekommt, wird als Developer wohl eher nicht auf Container umsteigen, fürchte ich ... Gruß, Nils

Moin, mir lag es schon die ganze Zeit auf der Zunge. Eine ordentliche Servermigration, auch über Versionsgrenzen hinweg, ist schon seit vielen Jahren bei Exchange nahezu ein No-brainer. Gruß, Nils

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