NilsK

Moin, Einstellungen öffnen, nach "Wiederherstellung" suchen und den passenden Knopf drücken. Sofern das Upgrade nicht mehr als zehn Tage her ist. Gruß, Nils

Moin, beides korrekt: Der erste DC einer Domäne konvertiert seine lokalen Konten. Alle anderen nachträglich hinzugefügten DCs löschen ihre lokalen Konten. Hier ca. ab Minute 6: https://youtu.be/uQUsQqo7TVY Gruß, Nils

Moin, nein, ich meine eine einzige Instanz. So ist SQL Server entworfen und nur so läuft er optimal. Eine Aufteilung in mehrere Instanzen auf derselben Maschine ist immer eine Krücke mit teils erheblichen Nachteilen. Und wie andere schon richtig sagen - wenn Applikationshersteller auf sowas bestehen, liegt es meist daran, dass sie das System nicht verstehen. Gruß, Nils

Moin, naja, was für ein Feature würdest du nicht installiert haben? Aber ja, im Prinzip hieße es das. Du kannst die bestehende Instanz auch so lassen, ein Umzug ist technisch nicht nötig. Gruß, Nils

Moin, insgesamt ein Holzweg, denke ich. Eine organisatorische Betrachtung wäre weit sinnvoller. Wenn es der Weg sein soll: Das muss man an zwei Stellen aktivieren. Einmal per Policy auf dem betreffenden Server die Überwachung einschalten. Und dann im Dateisystem an dem betreffenden Ordner über die Berechtigungen angeben, was geloggt werden soll. Die Events stehen dann im Sicherheitsprotokoll des Servers. Aber das wird sehr viel sein und damit sehr viel Aufwand erzeugen. Gruß, Nils

Moin, mehrere Instanzen braucht man nur in Ausnahmefällen. Der Normalfall ist, dass dieselbe Instanz mehrere bzw. "alle" Datenbanken hält. Dann funktioniert auch das Memory Management am besten. Gruß, Nils

Moin, was auch immer da passiert ist - das ist natürlich nicht üblich. Rückschlüsse auf den Reifegrad des Systems sind unbegründet. Ich könnte dir seitenweise Seltsamkeiten aus vSphere-Umgebungen aufschreiben, dadurch ist das aber natürlich kein "unreifes" Produkt. Typischerweise ist der Restore von Hyper-V-VMs genauso wenig ein Problem wie in VMware. Auch über Versionsgrenzen hinweg, auch vom Server auf den Client, auch bei unterschiedlichen Prozessoren. Wenn man wollte, könnte man jetzt Forensik betreiben. Ist eine Frage der Relation von Aufwand und Nutzen. Gruß, Nils

Moin, prima, aber dann muss was anderes im Busch sein. Wenn eine VM neu gestartet wird, hat der Haken keine Auswirkung, die an dem Verhalten etwas ändern würde. [Was die Prozessorkompatibilität in Hyper-V wirklich tut | faq-o-matic.net] https://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/ Gruß, Nils

Moin, eine Auflistung dieser Art gibt es nicht. Die meisten Programme in dem Ordner nutzt man nicht manuell. Wenn es um die Kommandozeile geht, da gibt es ein Buch von O'Reilly (meine ich), Autoren u.a. Helge Klein und Olaf Engelke. Gruß, Nils

Moin, gut, aber welches Problem willst du denn vermeiden? Nur wenn du das weißt, kannst du beurteilen, ob ein Lösungsansatz taugt oder nicht. Gruß, Nils

Moin, ja, das ist korrekt. In dem Fall sollte man sich aber noch mal Gedanken machen, ob das administrative Konzept passt. Wenn die Sub-Admins so wenig Abstimmung mit den Root-Admins haben, stimmt im Grundsatz was nicht. Gruß, Nils

Moin, nö, das BSI nennt ausdrücklich https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzAbout/ITGrundschutzSchulung/WebkursITGrundschutz/Schutzbedarfsfeststellung/Schutzbedarfskategorien/Schutzziele/schutzziele_node.html Und so halten das auch sehr viele andere Quellen. Gruß, Nils

Moin, ja, wie Norbert schon sagt, geht das. Man kann dann auch den Domain Level der Sub anheben. Die Root Domain muss nicht den höchsten Modus haben. Gruß, Nils

Moin, kann es vielleicht einfach daran liegen, dass manche Anwender die Dateien noch vom alten Server öffnen, andere vom neuen? Gruß, Nils

Moin, mir ist jetzt noch nicht klar, was überhaupt das Problem ist, das du lösen möchtest. Gruß, Nils

Moin, jein, aber prüfe das selbst anhand dieses Artikels: https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/ Gruß, Nils

Moin, das ist ein bekannter Fehler in gpresult, der erst in Windows 10 behoben wurde. Gruß, Nils

Moin, der Win-10-Rechner hat das Recht, die Policy zu lesen? Gruß, Nils

Moin, ich hab grad noch mal selbst auf Seite 24 gesehen ... meine obige Darstellung war nur vom Prinzip her richtig, im Detail aber leider nicht. Entscheidend ist nicht Bit 9 (Dezimalwert 512, "NORMAL_ACCOUNT"), sondern Bit 1. Wenn dieses NICHT gesetzt ist, ist der Account aktiv. In der Praxis kann aber eben durchaus auch 66048 dort stehen, was auch ein aktiver Account ist. Gruß, Nils

Moin, der Fehler ist der numerische Wert für userAccountControl. Es handelt sich dabei um ein Bitmap-Feld. Das zehnte Bit mit dem Dezimalwert 512 gibt an, dass ein Konto aktiviert ist. Der numerische Wert 512 steht aber nur dann in dem Feld, wenn kein anderes Flag gesetzt ist. Der (fiktive) Wert 513 etwa könnte auch angeben, dass das Konto aktiviert ist, weil die 512 ja gesetzt ist. Dein Filter auf 512 enthielte diesen Datensatz aber nicht. Du müsstest hier also mit einem Bitfilter arbeiten. [Whitepaper: LDAP-Filter für Active Directory | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/24/whitepaper-ldap-filter-fr-active-directory/ In dem PDF auf Seite 24 erklärt. Gruß, Nils

Moin, sowas ähnliches hat ein Member neulich auf die Schnelle hier gebaut: Gruß, Nils

Moin, wie magheinz schon richtig sagt: Sowas macht man normalerweise beim Anlegen des Users. Das kann man aus dem AD-Verwaltungsprogramm gleich direkt tun über die Registerkarte "Profil", dort "Basisordner". Da gehört ein UNC-Pfad rein à la \\NAS\Homeshare\%username% - so legt Windows dann in dem Share den passenden Ordner an und setzt auch gleich die Berechtigungen. Man könnte sowas auch beim Anmelden über ein Logonskript tun, aber das wäre a) unüblich, b) abhängig von Berechtigungen auf der Share-Ebene, die man so eigentlich nicht setzen will und c) mit unnötig aufwändiger Logik im Skript verbunden. Gruß, Nils

Moin, wenn die User kein Adminkonto bzw. -kennwort haben, kann ja nichts passieren. Die Funktion abzuschalten, hieße, dass auch ein berechtigter Admin keine Möglichkeit hätte, einen Task mit erhöhten Rechten innerhalb einer bestehenden Usersession auszuführen. Mir wäre auch keine Möglichkeit bekannt, das abzuschalten (was nicht automatisch heißt, dass es nicht geht). Möglicherweise reicht es, den Dienst "Sekundäre Anmeldung" zu deaktivieren, ist aber ungetestet. Gruß, Nils

Moin, das geht nicht. Entweder man ist Admin oder nicht. Und einen Admin kann man nicht wirksam einschränken. Gruß, Nils

Moin, du suchst den SQL-Befehl "RESTORE DATABASE" mit der "AS"-Klausel, die einen neuen Namen für die wiederhergestellte Datenbank vergibt. Den Datumsstring kannst du dir mit SQL-Mitteln zusammenbauen oder, falls du das Restore von außen triggerst, mit den Mitteln der dort verwendeten Skriptsprache. Um die nicht mehr benötigten Datenbankkopien zu entfernen, nutzt du "DROP DATABASE". Die Logik drumrum ist nicht ganz trivial, aber durchaus zu handhaben. Du solltest dir überlegen, wie du den Task automatisieren willst - mit dem SQL Server Agent oder z.B. von außen über den Taskplaner. Im ersten Fall solltest du die Logik mit SQL-Anweisungen aufbauen, im zweiten käme PowerShell in Frage. Beides hat seine Vor- und Nachteile, am Ende entscheidet, mit welcher Technik du dich wohler fühlst. Gruß, Nils