NilsK

Moin, schon ein interessanter Stunt, Exchange 4.0 als die Erfindung darzustellen, die Kommunikation erst möglich gemacht habe ... Gruß, Nils

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