NilsK

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

Moin, wenn man es wirklich will, kriegt man das sicher auch per Batch hin. Da die "Sprache" aber eigentlich keine ist und auch für sowas nie entworfen wurde, wird das aber sehr umständlich. Die PowerShell hingegen ist ausdrücklich auch für komplexere Aufgaben gemacht und hat ein gutes Handling von Variablen, Schleifen, Strings usw. Auf jeden Fall müsstest du für dich erst mal die Logik genauer definieren. Unter welchen exakten Umständen soll exakt was passieren? Mit so einer Definition ist man dann oft schon nah an der Lösung. Gruß, Nils

Moin, Schulaufgabe? Gruß, Nils

Moin, interessante Behauptung - was hat denn die Person genau gesagt? Gruß, Nils

Moin, nein, das sind unterschiedliche Dinge. Das krbtgt-Kennwort ändert man nur manuell, die Computerkennwörter handeln die Rechner regelmäßig mit dem AD aus. Gruß, Nils

Moin, ein DC darf maximal so lange offline sein, bis die Tombstone Lifetime erreicht wird. Das sind entweder 60 oder 180 Tage. Ich weiß nicht, von was für einem Kerberos-Passwort du sprichst. Vielleicht ein Missverständnis? Kerberos akzeptiert keine Zeitabweichung zwischen DC und Client von mehr als 5 Minuten. Das hat mit deinem Problem aber nichts zu tun. Bei dem Phänomen, das anscheinend bei dir vorlag, geht es um das Computerkennwort des DCs. Wie es zu der Versionsabweichung kommt, kann ich grad nicht aus dem Kopf sagen, aber es ist ein eher unübliches Phänomen. Kann es sein, dass die Verbindung zwischen den Standorten nicht ausreichend zuverlässig ist? Gruß, Nils

Moin, Lass die Replikation in Ruhe. Die berechnet das AD selbst. Wenn es die nötigen Informationen dazu hat, klappt zuverlässig. Dass ab vier DCs nicht jeder mit jedem repliziert, ist normal. Gruß, Nils

Moin, erstens würde ich mit 2019 noch warten. Das macht noch einen ziemlich unausgegorenen Eindruck. Und zweitens würde ich immer was vom Hersteller unterstütztes nehmen, also entweder Hyperconverged von einem "Komplettanbieter" oder ein herkömmliches Server-und-SAN-System mit definiertem Support. S2D ist von der Idee her nett, aber in der Praxis hat man eben selbst die Support-Sorgen damit, weil es am Ende meist ein Eigenbau ist. Uns haben in den letzten Monaten mehrere Kunden angerufen, denen ein in der Community bekannter S2D-Verfechter sowas gebaut hat, der es jetzt aber nicht mehr supporten kann, weil er die Leute (besser: den Leut) nicht mehr hat. Wir fassen so ein System aber nicht an - und dann stehen die Kunden halt da ... da mag man von Hersteller-Support halten, was man will, aber damit hat man wenigstens eine definierte Grundlage, wenn mal was ist. Gruß, Nils

Moin, hier sollte man sich genau ansehen, was man braucht und was technisch passiert. In dem VPN-Szenario wird das Zertifikat für die Traffic-Verschlüsselung verwendet, also sozusagen "nur ad-hoc". Es ist daher grundsätzlich unproblematisch, wenn auf verschiedenen Rechnern unterschiedliche Zertifikate für denselben User vorliegen. Da die verschlüsselten Daten nicht gespeichert werden, müssen sie nicht zu einem späteren Zeitpunkt entschlüsselt werden. Daher kann man den derzeitigen Zustand, den du beschreibst, für dieses Szenario durchaus akzeptieren. Anders sieht es aus, wenn die verschlüsselten Daten gespeichert werden, etwa bei der Mail- oder Dateiverschlüsselung. In dem Fall ist es unabdingbar, dass derselbe User immer dasselbe Zertifikat verwendet. Hier kann Credential Roaming eine Lösung sein. Andere Ansätze verzichten in solchen Situationen darauf, dass derselbe User verschiedene Rechner verwendet. Noch eine Variante wäre, den Private Key gar nicht auf dem Rechner zu halten, sondern auf einer Smartcard - das setzt aber drumrum natürlich einiges an Infrastruktur voraus. Was nicht hilft, ist das Speichern des Private Keys in der CA-Datenbank. Zwar bietet die Windows-CA so eine Option (Key Archival), die ist aber nur für Recovery-Zwecke vorgesehen und würde in dem Roaming-Szenario gar nicht helfen (weil der Client nicht auf die Idee käme, dort zu suchen). Daher in der Regel Finger weg davon - Key Recovery benötigt man nur, wenn verschlüsselte Daten aufbewahrt werden und auch dann nur für den Recovery-Prozess, der dann genau definiert und speziell abgesichert sein muss. Gruß, Nils