NilsK

Moin, wenn du per PowerShell arbeiten willst, ist vielleicht Desired State Configuration eher was für dich. Gruß, Nils

Moin, ach so. Meines Wissens gibt es auch weiterhin keine Möglichkeit, die Inhalte von Gruppenrichtlinien programmatisch zu steuern. Gruß, Nils

Moin, möglicherweise liegt da ein Missverständnis vor. Nur ein Teil der Gruppenrichtlinien manipuliert Registry-Einträge. Viele andere Teile haben eigene Funktionen, so auch die Dienstesteuerung. Zu den Hintergründen siehe: https://www.gruppenrichtlinien.de/artikel/client-side-extensions-cses/ Gruß, Nils

Moin, ich stimme Norbert zu. Es gibt so gut wie kein AD-Problem, das man nicht beheben könnte, meist mit sehr überschaubarem Aufwand. Und alles "Aufräumen" würde ohnehin anfallen, selbst wenn du eine neue Domäne aufsetzt. Man kann Clients und Server durchaus migrieren, aber das bedeutet in aller Regel erheblichen Aufwand. Wenn es also keinen zwingenden Grund gibt, dann migriere nicht, sondern behalte die Domäne bei und räume dort auf. Gruß, Nils

Moin, wenn es grafisch sein soll und dein Unternehmen bereit ist, eine geringe Summe für nützliche Tools auszugeben, empfehle ich ISESteroids von Tobias Weltner. Das ist eine Erweiterung, mit der aus der PowerShell ISE eine vollwertige Entwicklungsumgebung wird. Nicht nur, aber eben auch für "echte" grafische PowerShell-Oberflächen. Gruß, Nils

Moin, also, wenn dir der Server plötzlich sagt, dass er jetzt herunterfährt, klingt das ganz dringend nach der USV. Gruß, Nils

Moin, das ist eher unwahrscheinlich. Der Absturz deutet eher auf Treiber- oder Hardwareprobleme auf Hostebene hin. Ausgeschlossen ist es zwar nicht, dass irgendein Vorgang in der VM etwas Fatales auf dem Host auslöst, aber eben nicht wahrscheinlich. Nun ist Windows Server 2008 ja eher antik, und das trifft besonders auf Hyper-V in dieser Version zu. Sind die nötigen Updates und passenden Hotfixes dort installiert? Ich meine mich zu erinnern, dass es für Hyper-V 2008 so einiges gab. Bei der Version könnten sogar noch die Sleepstates der CPU ein Problem sein. Wobei ich gerade sehe, dass es da um 2008 R2 ging, aber voelleicht ist das ja auch die Version, um die es in Wirklichkeit geht: [bluescreen in Hyper-V 2.0: Hotfix einspielen | faq-o-matic.net] https://www.faq-o-matic.net/2010/08/04/bluescreen-in-hyper-v-2-0-hotfix-einspielen/ Gruß, Nils

Moin, also - ich bin der Ansicht, um LAPS sinnvoll einzusetzen, braucht es passende Prozesse. Da müssen die Berechtigungen passen - OK, in den meisten Netzwerken ein einmaliger Vorgang, was die Attributberechtigungen betrifft. Da müssen die Gruppenmitgliedschaften passen, wenn das System überhaupt einen Sinn haben soll. Und da muss es eine regelmäßige Kontrolle geben, ob das alles so läuft, wie es soll. Es sind ja eine ganze Reihe von Komponenten beteiligt. Mindestens bei den letzten beiden Punkten sehe ich in den meisten Umgebungen ein Problem prozessualer Art. Und dann ist ja noch die Frage, ob die Kennwörter im AD wirklich richtig und sinnvoll aufgehoben sind. Sie mögen dort geschützt sein, wenn man obige Voraussetzungen einhält. Aber warum müssen diese sensiblen Daten auf alle DCs repliziert werden? Und warum soll das weniger ein "large security hole" sein als eine Excel-Kennwortliste, wie ein Microsoft-Mitarbeiter in einem Blog-Beitrag zu LAPS behauptet? Ich rede natürlich nicht der sattsam bekannten Technik das Wort, auf jedem PC dasselbe Lulli-Kennwort einzurichten und das nie zu ändern. Aber angesichts der Voraussetzungen, die LAPS an die Umgebung und die Prozesse stellt, bin ich absolut nicht der Meinung, dass es per se besser geeignet sei als andere Methoden. Und genau das sollte man sich dann schon in Ruhe ansehen - wenn man dann die Entscheidung für LAPS begründet und passend vorbereitet trifft, mag es ja OK sein. Das ist dann das, was ich oben in meinem PS meinte. Wer allen Ernstes Lulli-Kennwörter per Deployment ausrollt, wird ja auch LAPS nicht implementieren, weil ganz offensichtlich das Bewusstsein für Prozesse fehlt. Da haben wir also schon eine unpassende Annahme. Gruß, Nils

Moin, Aber nur, wenn es nur Schwarz und Weiß gibt. ;) Gruß, Nils

Moin, ja, interessant vielleicht, aber doch eher als Geek-Smalltalk. Wozu würde man die Netzwerkumgebung nutzen wollen, die schon immer kaputt war und auch mit Ausweichprotokollen nicht zuverlässiger geworden ist? Gruß, Nils

Moin, kurz gefasst: LAPS erfordert ein Maß an Prozesstreue, das kaum ein Kunde wirklich aufbringt. Ich behaupte, dass von allen AD-Umgebungen, die ich in den letzten 18 Jahren gesehen habe, keine fünf Prozent die nötige Sorgfalt aufweisen, um LAPS sinnvoll zu betreiben. Daher halte ich den Ansatz, administrative Kennwörter im Klartext im AD zu speichern, für nahezu unvertretbar. Wenn ich dann noch solche Fragen lese, wie sie hier diskutiert werden - und die dann auch noch von "Sicherheitsbeauftragten" gestellt werden bzw. auf deren Forderungen beruhen - dann zeigt mir das, dass das Konzept von LAPS praktisch vollständig missverstanden wird. Das ist durchaus ein Fehler des Konzepts selbst, das einfach nicht als Standardlösung taugt, aber als solche positioniert wird. Gruß, Nils

Moin, das ist keine gute Idee. Der Zugriff auf das Attribut, in dem das Kennwort im Klartext liegt, wird nur über AD-Attributberechtigungen gesteuert. Wer die hat oder ändern kann, hat damit Zugriff auf das Kennwort. Aus naheliegenden Gründen ist das für jegliche Domänen-Accounts ein No-Go. Dafür ist LAPS auch nicht entworfen worden. Gruß, Nils PS. Aus diversen Gründen bin ich kein Freund von LAPS und würde es auf keinen Fall ohne exakte Prüfung der Gegebenheiten und Anforderungen empfehlen oder einführen.

Moin, also redest du nicht von Formatierungen, sondern von Zeilenumbrüchen. OK, schön, dass es jetzt klappt. Gruß, Nils

Moin, Formatierungen bei einer Textdatei? Wovon redest du? Wenn du Formatierungen möchtest, dann gib den Text als HTML aus und nutze dafür den Parameter -BodyAsHtml. Gruß, Nils

Moin, für sowas würde ich DFS-R nicht einspannen, weil es dafür gar nicht gedacht ist. Gerade so eine Migration lässt sich erfahrungsgemäß mit robocopy hervorragend machen. Da kann man im Hintergrund die Daten bandbreitenschonend vorsynchronisieren, bis man irgendwann umstellt. Gruß, Nils

Moin, das hängt vollständig davon ab, was die Anforderungen sind. Gruß, Nils

Moin, aber selbstverständlich. Kein SMBv1, keine Uraltprotokolle, die darauf aufsetzen. Man betreibe kein Troubleshooting für den veralteten Schrott, sondern verzichte darauf. Und nein, das ist kein Grund, SMBv1 wieder einzuschalten. :D Gruß, Nils

Moin, beziehungsweise, da wir hier qua Grundregel das Hacken eines Servers nicht unterstützen: Daten sichern, soweit möglich, und neu installieren. Gruß, Nils

Moin, dieses "Sehen" im Netzwerk beruht auf dem Browserdienst, einer uralten LAN-Manager-Komponente. Wie Jan schon richtig sagt: Hat noch nie richtig funktioniert. Nicht zuletzt deshalb versucht Microsoft auch schon seit über fünfzehn Jahren, diese Ansicht in Windows zu verstecken. Das "Sehen" oder "Nicht-sehen" ist vereinfacht gesagt zufällig und hat nichts damit zu tun, ob man auf die betreffende Ressource zugreifen kann. Ignorieren bzw. genauer: nicht mehr nutzen. Gruß, Nils

Moin, dass ein Update ein Konto deaktiviert, ist ausgesprochen unwahrscheinlich. Melde dich mit einem anderen Administratorkonto an. Welche es gibt, kannst du als User in einem CMD-Fenster herausfinden: net localgroup Administratoren Gruß, Nils

Moin, DFS-N ist ein virtueller Namensraum. DFS-R ist eine dateiweise Replikation. Geeignet ist DFS-R für Dateien, die nicht gemeinsam bearbeitet werden bzw. bei denen man ausschließen kann, dass mehrere Replikate gleichzeitig bearbeitet werden. Das ist schon eine gravierende Einschränkung, aber Szenarien gibt es durchaus - nur eben nicht so viele, wie manche Admins annehmen. Manche setzen es auch zur Konsolidierung von Standortdaten fürs Backup ein, d.h. nur eines der Replikate ist beschreibbar. Was DFS-R eben nicht hat, ist ein Distributed Locking. Sowas gibt es auch, aber prinzipbedingt ist das nicht ohne. Und meines Wissens gibt es sowas nur mit Enterprise-Tools zu Enterprise-Preisen. Gruß, Nils

Moin, das Phänomen nennt sich "Last Writer Wins" und ist der Grund, warum man DFS-R nur für sehr wenige Szenarien wirklich einsetzen kann. Alle Vorhaben, die mit gemeinsamer Arbeit an Dateien - auch zeitlich oder räumlich versetzt - zu tun haben, scheiden i.d.R. für DFS-R aus. Gruß, Nils

Moin, korrekt. Nebenbei bemerkt, zeigt José den Zustand des Papierkorbs (und auch des anderen zuschaltbaren Features PAM) in den Domänen-Metadaten an. https://www.faq-o-matic.net/jose/ Gruß, Nils

Moin, OK, interessant ... also jetzt tatsächlich ein "harter" Grund, WINS loszuwerden. EDIT: Wobei die zitierte Microsoft-Aussage, DNS würde WINS "vollständig" ersetzen, ja schlicht nicht zutrifft. Genau das ist ja der Grund, warum dieser Uraltdienst noch so viel genutzt wird. Gruß, Nils

Moin, ich tute mal in dasselbe Horn wie Norbert: Warum baust du eine neue Domäne, wenn du die vorhandene einfach beibehalten und den SBS direkt dort ersetzen kannst? Damit würdest du dir wahrscheinlich eine Menge Aufwand und Fehlerquellen sparen. Gruß, Nils