NilsK

Moin, Kopieren, dann das Original löschen. Gruß, Nils

Moin, ihr seid in verschiedenen Tenants, oder? Dann geht es nur per Konferenz-Einladung, nicht als direkter Anruf. Sonst braucht es die externe Telefonie. Gruß, Nils

Moin, Dann zeigt der Server auch nur ein englisches Fragezeichen. Gruß, Nils

Moin, ich habe leider keinen heißen Tipp, kann aber beitragen, dass ich schon mit mehreren Rechnern Bluescreen-Probleme im Zusammenhang mit dem Modern Standby hatte. Das Bild war ähnlich wie bei dir: anhand der Eventlog-Einträge und von Bluescreen-Auswertungen ließ sich ein Zusammenhang mit dem Modern Standby erkennen, allerdings bei den Rechnern an verschiedenen Stellen im Detail. Bei einem der Rechner ließ sich deutlich sehen, dass ein konkreter Treiber (oder die damit gesteuerte Komponente) das Problem machte. Immer wenn der beim Standby an der Reihe war, das Gerät schlafen zu legen, war, kam der Bluescreen. Leider sind die Probleme in meinem Fall nie gelöst worden. Im ersten Fall hat der Hersteller so lange an den Tickets rumlaboriert, bis das Gerät aus dem Support raus war ... in den anderen Fällen wurde das Gerät durch ein anderes ersetzt. Ich würde allerdings die Hardware nicht als Ursache ausschließen. Durchaus vorstellbar, dass sich ein vorhandenes Problem verschärft oder dass eine neue Kernel- oder Treiberversion es nicht mehr umschifft, wie es die vorherige Version getan hat. Wenn das Gerät noch Support hat, würde ich den einschalten. Gruß, Nils

Moin, hm ... nun ja. Ich würde auf sowas keine Zeit verwenden. Ungefähr sowas meine ich damit, dass das eigentliche Problem gar nicht gelöst wird. Mit dem Zertifikat weist der Computer seine Identität nach, mehr nicht. Wenn du einen Zugriff auf eine andere Stelle verhindern willst, musst du das an der Stelle tun. Soll also der Computer nicht auf den Webserver zugreifen, dann verhindere das dort. Gruß, Nils

Moin, ah, my bad. Ich hatte übersehen, dass du Hex-Schreibweise verwendet hattest. Gruß, Nils

Moin, das wird sofort verständlich, wenn man sich ansieht, was da passiert: Beim Verschieben im selben Volume bleibt die Datei unverändert, es ändert sich nur der Zeiger im Verzeichnis. In allen anderen Fällen (neue Datei, Datei kopiert, Datei von einem anderen Volume verschoben) werden neue Daten geschrieben, und die erhalten die Berechtigungen, die der Ordner vorgibt. Das ist übrigens schon seit über 32 Jahren so, nicht seit 20. Gruß, Nils

Moin, die Zertifikatsvorlage zu löschen, verhindert ja nur, das neue Zertifikate ausgestellt werden. Damit wäre diese Anforderung ja erfüllt: Ich nehme mal an, damit meinst du nicht "ein" Zertifikat, sondern "keine Zertifikate auf Basis dieser Vorlage"? Die ausgestellten Zertifikate von den Endpunkten zu entfernen, ist ja eine ganz andere Aufgabe. Erster Schritt wäre, diese Zertifikate zu sperren und die CRL neu auszustellen. Danach käme der Prozess zur Entfernung, was per Skript oder mit anspruchsvollen Client-Management-Lösungen ginge. Aber bevor du da tiefer einsteigst: Was ist denn der Use Case, also warum willst du die Zertifikate entfernen? Je nach Nutzung kann es sein, dass dieser Schritt das eigentliche Problem gar nicht löst. Gruß, Nils

Moin, nein, so geht das nicht. Das Snap-in kennt keinen Nur-Lese-Modus. Generell dürfen AD-Benutzer fast alles im AD lesen. Und sie dürfen auch ein paar Dinge ändern, darunter einige Attribute ihrer eigenen Benutzerkonten. Alles, was der User von den Berechtigungen her darf, kann er mit dsa.msc tun. (Er könnte das auch mit einem beliebigen anderen Werkzeug tun, denn er hat ja die Berechtigungen dazu.) Wenn das zu deinem Use Case passt, kannst du den Usern Zugriff auf dsa.msc geben. Wenn nicht, dann definiere deine Anforderungen und wähle ein anderes Werkzeug dafür aus, falls es eines gibt. Gruß, Nils

Moin, baust du das testweise oder soll es einem produktiven Zweck dienen? Falls letzteres, was ist das Ziel? Gruß, Nils

Moin, nein, da war keine 15. Vermutlich hat im Handbuch auch nur ...,8 gestanden, die ...,1 dahinter war dann schon so ein Insidertipp, den man erst später auf dem Schulhof bekam. Ich weiß nicht mehr, was die 1 bewirkte. Vermutlich nichts. Gruß, Nils

Moin, gute Literatur war damals schon schwierig. Meine erste Stunde mit dem C64-Handbuch habe ich im Oktober 1983 damit verbracht, LOAD "PROGRAMMNAME",8,1 auszuführen und mich zu wundern, warum es nur Fehlermeldungen gibt. Gruß, Nils

Moin, also, für mich liegt auf der Hand, dass das komplette Storage von dem Host korrupt ist. Dass die VMs noch starten, wird daran liegen, dass in den dafür notwendigen Bereichen noch keine Lesefehler vorliegen. Vermutlich werden aber die Eventlogs der VMs viele Fehler melden. Ich würde an deiner Stelle auf anderer Hardware retten, was noch zu retten ist, und mich um einen Neuaufbau der wichtigen Applikationssysteme kümmern. Irgendwelche Reparaturversuche kosten wertvolle Zeit und machen es erfahrungsgemäß nur schlimmer, wenn man nicht exakt weiß, was man da tut. Gruß, Nils

Moin, zwischen "noch nie mit AD in Berührung" und deinem Buch ist schon noch einiges an Wegstrecke zurückzulegen ... Aus Erfahrung ist mein Tipp, dass man die ganz grundlegenden Basics erst mal direkt vermittelt: Warum meldet man sich eigentlich im Netzwerk an, warum verwaltet man Geräte zentral? Was sind die wesentlichen Ansätze und Metaphern, die ein System wie AD verwendet? Und so Sachen. Das steht in den Büchern meist nicht drin und findet auch in den meisten Kursen nicht statt, daher finden "richtige" Neulinge oft nur sehr schwer den Einstieg. Gruß, Nils

Moin, Für viele ist diese Trennung immer noch der heilige Gral. Ich finde das immer putzig, wenn gleichzeitig die Windows-Umgebung selbst bestenfalls grundlegend abgesichert ist. Den Angreifer möchte ich sehen, der überhaupt nur darüber nachdenkt, in solchen Netzwerken umständlich die Management-Interfaces anzugreifen. Gruß, Nils

Moin, eine vernünftige technische Lösung sehe ich dafür nicht. Auch die Idee mit den Labels wäre ja eher ein missbräuchlicher Workaround, wenn er denn überhaupt funktionieren würde. Das Problem ist das Konzept der Weiterleitungen an sich. Das ist nur in seltenen Situationen sinnvoll. Urlaub und Krankheit gehören regelmäßig nicht dazu. Mir ist bewusst, dass man das nicht mal eben abschaffen kann, wenn es in einem Unternehmen üblich ist, aber das ändert nix dran. Gruß, Nils

Moin, hm, danke sehr, aber bist du dir sicher, dass du das jeweils ins richtige Gefäß geschüttet hast? Gruß, Nils

Moin, Es gibt Leute, für die ist VS Code quasi Industriestandard. Gruß, Nils

Moin, also, zumindest in der Konsole von VS Code kommt die Melodie doch etwas unsortiert raus. Gruß, Nils

Moin, Backup aus der VM und Restore in eine neue VM. Ist etwas Aufwand und erfordert ggf. auch mehrere Versuche, sollte das Problem aber lösen. Gruß, Nils

Moin, ja, es geht aber um zwei. Gruß, Ni"du kannst mir schon widersprechen, aber die Konsequenzen trägst' dann halt selbst"ls

Moin, Warum sollte er? Gruß, Nils

Moin, Wird vermutlich nicht helfen, aber du könntest es mal mit der Super-Kompatibilität "CompatibilityForOlderOperatingSystemsEnabled" versuchen: https://learn.microsoft.com/en-us/powershell/module/hyper-v/set-vmprocessor?view=windowsserver2025-ps EDIT: Um das kurz einzuordnen: Der beschriebene Fehler wird genau das sein, nämlich ein Fehler. Das mit der erweiterten Kompatibilität wäre jetzt eher als Test zu verstehen, wie weit sich der Fehler auswirkt. Und falls es mit der Einstellung dann doch ginge, wäre das ja auch was. Gruß, Nils

Moin, Am Ende würde es mit Internet Connection Sharing gehen, was ja nichts anderes als Routing ist. Dass es nicht geht, liegt an "eurer IT". Bevor das jetzt als Empfehlung verstanden wird: so ein Konstrukt (ICS im Host-OS) wäre eine Notlösung und ist für eine professionelle Server-Umgebung nicht zu empfehlen. Ihr werdet mit eurer IT zusammenarbeiten müssen, um eine funktionierende Lösung zu finden. Gruß, Nils

Moin, Alle VMs sollen über das VPN nach außen kommunizieren, ohne dass sie das VPN selbst aufbauen müssen? Dann brauchen sie einen Router, der dafür sorgt. Die Netzwerkverbindung des Hosts hat mit den Netzwerken der VMs nichts zu tun. Auch wenn Hyper-V scheinbar "unterhalb" von Windows Server läuft, ist das Gegenteil der Fall: die Verwaltungsinstanz von Hyper-V ist technisch betrachtet nur eine VM wie alle anderen auch. Deren Netzwerktraffic ist also von den Netzwerken der anderen VMs getrennt. Ein VPN im Host-OS steht nur diesem Host-OS zur Verfügung. Gruß, Nils