NilsK

Moin, naja, was erwartest du denn? Es gibt in großem Stil kostenlose Testsoftware und kostenlose Azure-Nutzung. Wenn man sowas dauerhaft braucht, dann steckt wohl ein kommerzielles Interesse dahinter. Rein von der Logik her finde ich es absolut legitim, dass der Hersteller damit dann Geld verdienen will. Edit: Und was den "Trick" mit dem Action Pack angeht: Wie XP-Fan schon richtig anmerkt, ist das ein Programm, das sich an Unternehmen wendet. Microsoft gewährt die Vorteile, weil es die Gegenleistung erwartet, dass der Partner Geschäft mit Microsoft-Produkten macht. Es ist keine billige Möglichkeit für "daheim" - faktisch wäre das ein Verstoß gegen die Grundbedingungen, also i.W. dasselbe wie eine Raubkopie. Gruß, Nils

Moin, warum Admins bei sowas immer mit "paranoid" kommen, wird sich mir nicht mehr erschließen ... Ergänzend empfehle ich, ein regelmäßiges AD-Backup mit Bordmitteln herzustellen, also den Systemstate täglich mit Windows Server Backup zu sichern. Beim AD sollte man immer einen doppelten Boden haben (zwei Sicherungsmethoden parallel). Das Systemstate-Backup mit WSB ist die einzige Sicherung, die von Microsoft komplett unterstützt wird. Diese Option sollte man nutzen, zumal sie kaum Aufwand erzeugt. Gruß, Nils

Moin, aber ihr sichert euer AD doch hoffentlich täglich? Gruß, Nils

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