NilsK

Moin, und jenseits der Medienfrage ist die Antwort natürlich: Das hängt von den Anforderungen ab. Gruß, Nils

Moin, ich behaupte: Wird nicht gehen. Wenn doch, dann Gebastel übelster Kategorie. Und wie groß ist jetzt der Preisunterschied zu einer Festplatte? Wie teuer ist die Arbeitszeit der 10 User? Gruß, Nils

Moin, wenn die SD-Karte über das Board wie eine normale Platte angesprochen wird, geht das. Wenn nicht, dann ist es nicht supported und dürfte mit 2016 auch nicht gehen. (Aus gutem Grund.) Selbst wenn es ginge, würde ich aber nie ein produktiv genutztes System auf einer SD-Karte installieren. Das ist ein Speichergerät, das für Digitalkameras entworfen wurde. Gruß, Nils

Moin, ich empfehle da auch die ISESteroids. Das mit den Variablen geht da natürlich auch, und es gibt -zig weitere Features, mit denen aus der PowerShell ISE eine echte Entwicklungsumgebung wird. Gruß, Nils

Moin, du bist deiner Zeit voraus - 2016 R2 gibt es noch nicht. ;) Beim Downgrade gelten die Lizenzrechte der aktuellen Version, nicht der installierten. Du musst also die 2016-Core-Lizenzierung zugrundelegen. Geht es um Hardware oder um eine VM? Gruß, Nils

Moin, Und du meinst, den Rechnern kann man vertrauen? Mutig. Gruß, Nils

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