NilsK

Moin, kannst du machen, musst du aber nicht. Der dort angegebene Pfad wird dir beim manuellen Erzeugen einer VM jeweils als Vorschlag angegeben, den du akzeptieren oder überschreiben kannst. Mehr nicht, es besteht keine weitere Abhängigkeit von diesem Wert. Gruß, Nils

Moin, nein, das würde nicht funktionieren. Der Pfad an der angegebenen Stelle ist nur ein Vorgabewert für neue VMs. Der hat mit bestehenden VMs nichts zu tun. Beim Anlegen einer neuen VM kannst du auch jeweils einen individuellen Pfad vergeben und musst die Vorgabe nicht nutzen. Als Best Practice gilt, alle Daten einer VM in einem Ordner zu sammeln, also die Config-Files nicht separat vom Rest zu halten. Technisch ist das egal, aber auf die Weise hat man alles übersichtlich zusammen. Sofern es keine harte Notwendigkeit gibt, das für bestehende VMs zu ändern, würde ich die in Ruhe lassen. Falls doch, ist der einfachste Weg vermutlich, die betreffenden VMs zu beenden, zu löschen, alles an den Zielort zu verschieben und dort per Import-Funktion neu zu registrieren. Gruß, Nils

Moin, nachgelagerte Systeme. Applikationen, Dateiserver, CMD-Codepages ... you name it. Gruß, Nils

Moin, das erste Dokument ist schon sehr alt. Das zweite ist etwas weniger alt. Windows Server 2019 ist unter Hyper-V vor 2016 überhaupt nicht supported. Lizenzrechtlich hätte es auch wenig Sinn: Um 2019 als Gast zu betreiben, muss auf dem Host eine 2019-Lizenz vorliegen. Wenn man die hat, ist es unsinnig, 2012 R2 zu installieren. Dasselbe gilt zwar auch für 2016, welches in der Kombination supported ist. Aber es liegt nun mal beim Hersteller, was er supported und was nicht. "Nicht supported" heißt auch nicht, dass es nicht läuft, es gibt nur eben keinen Support. Windows Server 2019 ist als Gast erst ab Hyper-V 2016 supported. Zu Windows 10 sind keine Einschränkungen dokumentiert. Da der Support für Client-OS aber auch geringer ist als für Server-OS, kann man daraus keine Analogien ableiten. EDIT: Ich habe gerade noch mal nachgesehen. Für Hyper-V gibt es eine "N+1"-Regel für den Gast-Support, d.h. das direkt nachfolgende Server-OS ist i.d.R. ebenfalls supported. Über zwei Generationen hinweg aber eben nicht. (Und: Es gilt nur für VMs, nicht für Container, da muss der OS-Level identisch sein.) Gruß, Nils

Moin, siehst du, genau sowas meine ich. Dir fehlen Kenntnisse der Technik (was an sich kein Problem ist), und jetzt versuchst du aufs Geratewohl herum (und da ist das Problem). Sowas macht man nicht mit einer zentralen Sicherheitskomponente. Nimm es mir nicht übel, aber solche kritischen Systeme supporte ich nicht auf dieser Ebene in einem Forum. Gruß, Nils

Moin, ja ... leider ist eine Windows-PKI auch mit aktuellen Betriebssystemen nicht leicht zu handhaben. Alles keine Technik, die undurchdringlich wäre, aber leider unnötig kompliziert gemacht. Anscheinend hast du da jetzt schon einiges rumprobiert. Da eine CA ein sicherheitskritisches System ist, rate ich davon ab, an der Stelle jetzt mit Forensupport weiter zu machen. Ein Dienstleister, der sich auskennt, sollte da mit vertretbarem Aufwand das Nötige tun können, ohne zusätzliche Risiken zu erzeugen. Eine Root-CA auf fünf Jahre zu setzen, wäre keine gute Idee. Aber vielleicht ist das jetzt auch nur ein Missverständnis. Gruß, Nils

Moin, vermutlich hast du für AIA (Speicherort für Informationen über die CA) und CRL (Zertifikatssperrliste) Werte angegeben, die ungültig sind. Jetzt gibt es keinen Pfad, an dem ein Client diese Daten abrufen kann. Was steht denn in den vorhandenen Zertifikaten und den verwendeten Zertifikatsvorlagen dazu drin? Und auf was für "5" hast du die Gültigkeit umgestellt? Jahre? Tage? ...? Wie lang ist denn das Root-Zertifikat noch gültig? Gruß, Nils

Moin, sagen wir es kurz: Du hast eine falsche Vorstellung von Active Directory. Insgesamt betrachtet, macht es was völlig anderes als du vermutest. Bitte lass das bleiben, auch das mit dem eigenen Exchange. Du handelst dir selbst und deiner Umgebung erhebliche Sicherheitsprobleme ein. Gruß, Nils

Moin, die Frage ist ja, ob eine technische Auswertung euch was bringt. Gerade beim IE bezweifle ich das, denn der wird auch bisweilen von anderen Programmen ferngesteuert, wenn die was anzeigen wollen. So hättest du dann u.U. viele Leute auf deiner Besuchsliste, die den IE gar nicht aktiv als Browser einsetzen. Wenn es denn technisch ausgewertet werden soll: Man könnte das über ein Skript angehen, das z.B. einmal alle fünf Minuten (sollte bei dem Szenario reichen - wenn man einen Browser einsetzt, sind das ja längere Vorgänge) in der Prozessliste nachsieht,ob "iexplore" dort auftaucht. Wenn ja, Log-Eintrag. Dann kann das Skript sogar enden, denn die erwünschte Information hat es dann erbracht. Per Scheduler das Skript beim Logon aufrufen, oder gleich als Login-Skript. Ein, zwei Wochen Einsatz sollten sicher reichen. Wenn ihr einen Betriebsrat habt: Bindet den dabei ein, sonst Ärger. Gruß, Nils

Moin, fangen wir doch mal vorne an statt hinten: Was ist das Problem, das du lösen willst? Gruß, Nils

Moin, jaja, es hat schon seinen Grund, dass ich nach Anforderungen und Hintergründen frage. Leider ist die zusätzliche Erläuterung zwar für sich genommen erhellend, aber das Wesentliche fehlt trotzdem: Was ist das Ziel? Was soll erreicht werden? Konkret: Warum soll die Abfrage überhaupt gestellt werden, was geschieht mit dem Ergebnis? Weitergehend wären Fragen nach der Datenbankstruktur zu stellen, nach dem Zugriffsmuster usw. Gruß, Nils

Moin, Bevor wir uns auf etwas stürzen, das man vielleicht besser anders löst, sag uns doch mal, was dahinter steht und was du insgesamt erreichen willst. Gruß, Nils

Moin, man darf aber dazu sagen, dass du hier von einer E- oder S-Klasse sprichst. ;) Gruß, Nils

Moin, nein, "Speichern" erzeugt einen Saved State, keinen Snapshot. Das ist was anderes. Sagt das Eventlog was zu dem Thema? Schau auch in den Hyper-V-Protokollen unter den Anwendungs- und Dienstprotokollen. Gruß, Nils

Moin, aber dann im Klartext? Wäre nicht sooo gut ... Gruß, Nils

Moin, der Cluster ermöglicht, dass der Exchange-Server den Host wechselt. Ob ihr das tut oder nicht, ist aus Microsofts Sicht egal. Also braucht ihr Lizenzmobilität und damit SA. Theoretisch könntet ihr Vorkehrungen treffen und dokumentieren, dass die betreffenden VMs nie den Host wechseln. Erfahrungsgemäß wird Microsoft das aber kaum akzeptieren, schon gar nicht, wenn es sich eben um einen Host-Cluster handelt. Gruß, Nils

Moin, der Compatibility Level betrifft vor allem die Funktion von SQL-Kommandos. Die verhalten sich dann so, wie sie es in der jeweiligen Version getan haben. Das braucht man nur, falls eine zugreifende Applikation genau dieses Verhalten braucht. Die Performance ist dabei nicht grundsätzlich betroffen. Gruß, Nils

Moin, ein Turnus zum Kennwortwechsel ist ein komplett falscher Ansatz. Die Erkenntnis hat sich nur noch nicht überall durchgesetzt. Entweder ist ein Kennwort "sicher" bzw. stark, dann muss man es nie wechseln. Oder es ist schwach, dann bringt aber auch ein turnusmäßiger Wechsel nichts. Ein Kennwort muss man dann wechseln, wenn es kompromittiert wurde (bzw. der Verdacht besteht) - und nicht ein paar Wochen danach zum festgelegten Termin. Regelmäßige Kennwortwechsel verringern in der Praxis die Kennwortsicherheit, weil 100 Prozent der Anwender dann simple Mechanismen verwenden (hochzählen, Zahl des Monats usw.), die das Kennwort leicht vorhersagbar machen. Das krbtgt-Kennwort wird nicht vom Admin gesetzt (auch wenn das so aussieht), sondern vom System (= egal, was der Admin einträgt, das System generiert ein Kennwort, das es nirgends anzeigt). Das ist von einer Qualität, die als "sicher" gelten kann. Hier gilt das Gesagte: Es hat keinen Sinn, das regelmäßig zu wechseln. Die Kunst bestünde darin, eine mögliche Kompromittierung aufzudecken - da das faktisch unmöglich ist, muss man die verhindern. Ein Angreifer, der das Kennwort einmal kompromittiert hat, ist aber kaum aus dem System zu werfen, weil er dann eine ganze Reihe von Möglichkeiten hat, sich festzusetzen und einen erfolgreichen Angriff auf das neue Kennwort auszuführen. Wer sich näher dafür interessiert, nimmt sich ein paar Tage Zeit und sucht nach "Golden Ticket" und "Silver Ticket". Gruß, Nils

Moin, ja, das Dilemma ist richtig beschrieben. Der Umstand ist auch ein Grund dafür, dass man in sehr großen Umgebungen versucht, von Gruppen wegzukommen und mit Claims zu arbeiten. Das führt aber zu einem neuen Dilemma, weil die Komplexität dadurch noch mal ansteigt. Gruß, Nils

Moin, einen festen Turnus gibt es dafür nicht. Der ist auch obsolet. Sollte jemand das ausgespäht haben, dann muss man es sofort ändern. Das grundsätzliche Dilemma. Die Änderung muss zweimal erfolgen, weil das Vorgängerkennwort ebenfalls noch gültig ist. Das ist Absicht, damit auch in komplex replizierten Umgebungen die Kommunikation sichergestellt ist. Erster Wechsel - Warten (maximale Replikationszeit der Umgebung plus Puffer) - zweite Änderung. Gruß, Nils

Moin, Textomat von Data Becker. Gruß, Nils

Moin, richtig, im Fall von VMware gibt es das Thema gar nicht. Da lizenziert man mit einer Standard-Lizenz zwei VMs mit Windows Server. Das Thema der "dritten" Lizenz auf dem Host existiert nur bei Hyper-V. Dort auf dem Host noch andere Software zu betreiben, verbietet sich aber schon technisch: Ein Host ist ein Host und nichts anderes. Niemand würde direkt auf einem VMware-Host noch Anwendungssoftware installieren, selbst wenn es ginge. Genauso ist das auch bei Hyper-V. Gruß, Nils

Moin, Vorschlag: Entweder du definierst mal, was du eigentlich vorhast. Dann kann man dir passende Vorschläge machen. Oder (vermutlich viel besser): Du nimmst dir Zeit, dich mit Grundlagen zu befassen und in Ruhe Dinge zu probieren. Dann meldest du dich, wenn du konkrete, beschreibbare Probleme hast. Ein Board wie dieses eignet sich nicht als Lern-Chat. Gruß. Nils

Moin, die Aussage klingt nach wilden Vermutungen ohne Sachkenntnis ... sorry. Maßgebend zur Identifikation eines User-Objekts ist die Security ID (SID). Diese wird in Berechtigungslisten, bei der Zuordnung von Exchange-Mailboxen usw. verwendet. Die SID ändert sich nie und wird nach dem Löschen eines Objekts nie erneut verwendet. (Nahezu) alle anderen Attribute kann man ändern. Da beim Umbenennen eines Users (dito Gruppe, Computer) die SID gleich bleibt, bleiben Berechtigungen usw. für dieses Objekt unverändert erhalten, ebenso Gruppenmitgliedschaften. Man kann auch sämtliche Attribute eines Objekts einsehen, spätestens mit ADSI Edit. Daher gibt es auch keine "verborgenen" oder "vergrabenen" Attribute. Ändert man den Namen eines Users, so passt ADUC mehrere Felder gleich mit an. Reicht das nicht aus, dann kann man weitere Felder auch anpassen. Was nicht angepasst wird, sind separate "abhängige" Werte wie etwa der Name des Profilordners. Den kann man bei Bedarf manuell anpassen. Gruß, Nils

Moin, doch, natürlich. Der Suchbegriff "DC Locator" sollte dich weiterbringen. Gruß, Nils