NilsK

Moin, die Fragen nach dem Szenario und dem Hintergrund der Verschlüsselungsfrage sind durchaus berechtigt. Was hier über Bitlocker gesagt wird, ist allerdings teilweise falsch oder zu stark verkürzt. Bitlocker ... verschlüsselt die Platte vollständig "merkt" nicht, wenn die Platte gestohlen wurde, sondern benötigt zum Entschlüsseln das richtige Kennwort nutzt zum Enschlüsseln standardmäßig ein Kennwort, das im TPM-Chip eines Rechners hinterlegt ist. Das ist nach heutigem Stand als "sicher" zu betrachten, daher kann man die Platte in einem anderen Rechner nur lesen, wenn man das Kennwort kennt lässt nur den Start desjenigen Betriebssystems zu, das die Verschlüsselung ausgeführt hat gilt technisch immer noch als gut gemacht und "sicher" schützt vor Offline-Angriffen, in denen das Betriebssystem nicht läuft schützt nicht vor Online-Angriffen lässt sich daher umgehen, wenn man den Rechner normal startet und sich an Windows anmeldet - wie trivial das wiederum ist, hängt vom gewählten Windows-Kennwort und der Absicherung des Betriebssystems ab lässt sich daher eben i.d.R. nicht "einfach so" umgehen, wenn man lokal an dem betreffenden Rechner sitzt - die meisten Umgehungsangriffe für lokale Kennwörter setzen voraus, dass man den Rechner mit einem anderen Medium bootet, und genau davor schützt Bitlocker zuverlässig lässt sich aber durchaus umgehen, wenn das laufende Betriebssystem andere Angriffe zulässt ersetzt keine Absicherung des physischen RZ-Zugangs, wird durch einen abgesicherten Zugang aber auch selbst nicht obsolet ersetzt auch keine anderen Maßnahmen zur Absicherung, sondern kann sie ergänzen adressiert in erster Linie Mobilgeräte ist auf Servern nur mit hohem Aufwand sinnvoll einzusetzen ist aber auf Servern eben auch nicht per se unsinnig das ist richtig (siehe oben), aber irrelevant. Wenn ich da rankomme, komme ich auch an die Daten des Systems. Warum sollte ich dann also noch den Key abgreifen? Ich kann mir die Daten doch einfach nehmen ... Bitlocker hat noch nie den Anspruch gehabt, ein laufendes System zu schützen. Daher ist es da auch nicht "unsicher", sondern unwirksam. Genau wie dein Airbag dir auch nichts nützt, wenn du ausgestiegen bist und über die Straße gehst. Gruß, Nils

Moin, man kann durchaus FC in einer VM nutzen, das geht seit Windows Server 2012. Einen Sinn muss es aber schon haben. :) Gedacht ist es vor allem für Gast-Cluster, deren Cluster-Storage direkt in einem FC-SAN liegen soll. Man muss dann die LUNs nicht auf Host-Ebene einbinden und durchreichen, und man braucht auch kein iSCSI nur für den Gast-Cluster. Zweites EInsatzgebiet wäre die Anbindung einer VM per FC an ein Backup-Device, aber ich weiß nicht, ob das wirklich schon mal jemand außerhalb des Labors gemacht hat. Das muss aber, wie Norbert oben schon erwähnte, vom ganzen FC-Stack im Netzwerk unterstützt sein, Stichwort NPIV. Gruß, Nils

Moin, in den meisten Umgebungen setzt man die Intervalle deutlich höher. Vorgegeben sind ja jeweils 7 Tage - darunter würde ich nur gehen, wenn es wirklich einen guten Grund gibt. Gruß, Nils

Moin, Dynamic DNS und Scavenging können zusammen schon eine heikle Mischung ergeben. Wie sind denn die Intervalle bei euch eingestellt? Du gibst an, dass "nicht aktualisierte Einträge nach 4 Tagen gelöscht" werden. Das verstehe ich jetzt mal als das Lösch-Intervall. Dazu gibt es ja noch das No-Update-Intervall, in dem DNS die Aktualisierungsversuche des Clients verwirft. Wenn ich das richtig verstehe, bleibt bei euch also nur ein Zeitraum von 4 Tagen, in dem der Server seine Einträge aktualisieren darf. Das klingt für mich nach einer Fehlerquelle, denn wenn in diesen 4 Tagen die Aktualisierung - aus welchem Grund auch immer - unterbleibt, löscht DNS den bestehenden Eintrag. Gruß, Nils

Moin, nein, du hast natürlich Recht. Das sollte der RODC dann schon regeln. [Häufig gestellte Fragen zu RODCs] http://technet.microsoft.com/de-de/library/cc754956%28v=ws.10%29.aspx Ich hatte das verwechselt. Gruß, Nils

Moin, für mich kommt hier als erstes die VM in den Kreis der Verdächtigen. Dort im Betriebssystem dürfte sich das Problem finden. Laufen noch weitere VMs auf dem Host? Wie verhalten die sich? Wie viele Netzwerkkarten hat der Host, und wie sind die konfiguriert? Welche virtuellen Switches (in 2008 R2 heißen die noch "virtuelle Netzwerke") sind in Hyper-V an welche Karte gebunden? Gruß, Nils

Moin, willkommen an Board - schön, dass du uns gefunden hast! was genau meinst du denn damit? Welches Betriebssystem hat der Server? Der Fehler deutet auf ein Authentisierungsproblem hin. Gibt es weitere Auffälligkeiten im Eventlog? Und zur Grundsatzfrage: Warum willst du das Kommando ausführen, und warum soll das wichtig sein? Die AD-Replikation manuell anzustoßen, ist nur in wenigen Ausnahmefällen nötig. Gruß, Nils

Moin, wenn ich die Angaben richtig interpretiere, hat die fragliche VM den RODC als ersten DNS-Server eingetragen. Der kann aber natürlich keine DNS-Registrierung vornehmen. Du solltest also einen schreibbaren DC als ersten DNS eintragen. Gruß, Nils

Moin, und die DNS-Informationen müssen natürlich auch auf den RODC repliziert werden. Je nach Aufbau muss man das noch einzeln einrichten. Gruß, Nils

Moin, hier steht, dass man Microsoft-Produkte verkaufen muss: http://support.microsoft.com/kb/312310/en-us Und im "Action Pack Program Guide" heißt es dazu auf Seite 12: Link: https://partner.microsoft.com/download/40196872 Gruß, Nils

Moin, doch, das geht mit irgendeiner Option im Backup-Kommando. Ich glaube mit WITH NO_LOG oder so. Kannst ja mal nachsehen. Gruß, Nils

Moin, das kann man machen, aber warum sollen die Daten doppelt gepflegt werden? Wie du ja selbst merkst, führt das nur zu Problemen, weil du dann zwei nicht synchrone Instanzen derselben Daten hast - sprich die Logon-Daten können unterschiedlich sein, obwohl sie das ja nicht sollen. Rein technisch musst du hier ein Update über einen Tabellen-Join machen. Bitte vorher auf einer Testkopie ausprobieren. UPDATE tps_user_network_login SET nl.tps_network_login = tu.tps_network_login FROM tps_user_network_login nl JOIN tps_user tu ON nl.tps_user_guid = tl.tps_user_guid Siehe auch [Grundbefehle von SQL | faq-o-matic.net] http://www.faq-o-matic.net/2002/03/17/grundbefehle-von-sql-2/ Gruß, Nils

Moin, nicht ganz. Beim Backupvorgang sichert der SQL Server alle Datenbankseiten direkt aus der DB-Datei. Sollte eine Transaktion eine Seite anfordern, die noch nicht gesichert wurde, so hält SQL Server die Transaktion zurück und sichert diese Seite als nächste. So ist die Konsistenz der Datenbank über das Backup hinweg gewährleistet. Dieser Vorgang ist natürlich nur schematisch zu verstehen und bezieht sich auf das "herkömmliche" Sicherungsverfahren ohne VSS. Im Fall eines VSS-Backups erzeugt SQL Server einen VSS-Snapshot für die Datenbankdatei, der dann gesichert wird. Das Vorgehen kann man sich dann genauso vorstellen, nur dass VSS dann das "Copy on Write" vornimmt - ein Block, der geändert werden soll, wird zunächst in den Shadow-Bereich kopiert, damit der usprüngliche Stand konsistent erhalten bleibt. Wichtig: Bei einem Full Backup werden die Transaktionsprotokolle nicht mit gesichert. Ebenso wenig bei einem Differential Backup. Dafür benötigt man separate Sicherungsjobs. Gruß, Nils

Moin, sehr gern, danke für die Rückmeldung! OT: Übrigens scheint deine Signatur schon etwas älter zu sein. ;) Gruß, Nils

Moin, schau mit LIZA nach, dann solltest du die betreffenden Berechtigungen schnell identifizieren können. Der Assistent setzt i.d.R. eine Kombination von Einzelberechtigungen, so wird das hier auch sein. Gruß, Nils

Moin, ein solches Recht gibt es auf Objektebene nicht. Es handelt sich dabei um ein Recht auf Domänenebene, das in der Default Domain Policy gesetzt werden kann. Auf OU-Ebene kannst du die Berechtigung zum Erzeugen und Verwalten von Computerkonten vergeben. Vermutlich ist das gemeint. Dabei musst du beachten, dass du mit dem Assistenten zur Objektverwaltung nur neue Berechtigungen hinzufügen, aber keine bestehenden verwalten kannst. Um das zu tun, musst du in die Sicherheitseinstellungen der betreffenden OU, z.B. über AD-Benutzer und -Computer. Zudem ist aber zu berücksichtigen, dass standardmäßig jeder AD-Benutzer bis zu 10 Computer in die Domäne aufnehmen kann. Um das zu ändern, musst du den Eintrag ms-DS-MachineAccountQuota mit ADSI Edit bearbeiten. Um bestehende AD-Berechtigungen zu analysieren, empfehle ich LIZA: [Liza: Berechtigungen in Active Directory analysieren | faq-o-matic.net] http://www.faq-o-matic.net/2010/04/06/liza-berechtigungen-in-active-directory-analysieren/ Gruß, Nils

Moin, naja - am Ende wirst du die Clients fragen müssen, weil die die Policies ja anwenden. Da das im laufenden Betrieb sowie beim Systemstart und der Anmeldung erfolgt, kann jeder Report immer nur eine Momentaufnahme sein. Auch wenn es nicht fuktionieren sollte, wird es die wichtigsten Hinweise auf dem Client geben. Daher wäre gpresult durchaus ein adäquates Mittel, beispielsweise im Anmeldeskript und mit einer anschließenden Kopie des Reports auf eine zentrale Freigabe. Ein kommerzielles Tool, das das macht, ist mir zumindest nicht bekannt. Heißt aber nicht, dass es keins gibt. Gruß, Nils

Moin, wie sehen die Berechtigungen für das fragliche GPO aus? Damit meine ich in der GPMC nicht "vorne" unter Bereich/Sicherheitsfilterung, sondern "hinten" unter Delegierung. Wenn du dort unten auf den Button Erweitert klickst, siehst du die Berechtigungen im Detail. Dort was Auffälliges? Damit ein GPO angewendet wird, müssen sowohl das Recht "Lesen" als auch das Recht "Gruppenrichtlinie übernehmen" gewährt sein. Gruß, Nils

Moin, was gibt dir gpresult /r aus, wenn du als Benutzer aus der Benutzer-OU angemeldet bist? Was genau meinst du mit "Befindet sich die GPO in der PC-OU, so wird sie angewandt."? Wenn in der PC-OU nur Rechner sind und das GPO nur Benutzereinstelllungen sind, kann das ja nicht sein. Gruß, Nils

Moin, prima, danke für die Rückmeldung! :) Gruß, Nils

Moin, naja, sieht aus, als sei blat.exe dort nicht erreichbar. Gruß, Nils

Moin, und das auch zu Recht. Denn bei allen Optimierungen können natürlich auch VHDX-Dateien zwei grundlegende Probleme nicht eliminieren: 1) Overhead und Latenz beim Vergrößern der Dateien und 2) Fragmentierung des unterliegenden Dateisystems. Man kann durchaus zu Recht argumentieren, dass dies in vielen Umgebungen keine entscheidende Rolle spielt. Daher ist es auch sinnvoll, dass Microsoft selbst von seinem Fast-immer-Erfordernis abgegangen ist, in Produktion mit "Fixed Size" zu arbeiten. Verschwunden sind die Nachteile aber eben nicht, weil sie prinzipbedingt nicht verschwinden können. Die Support-Statements für bestimmte Applikationen, wie von Norbert angemerkt, basieren dabei zusätzlich auf der Beobachtung, dass in realen Thin-Provisioning-Umgebungen das Monitoring oft eben nicht in ausreichender Qualität betrieben wird. Als Applikationshersteller hat man da durchaus Interesse, ein "Disk Full"-Problem außerhalb des Gastbetriebssystems (aus Sicht des Gastes ist noch viel Platz, aber plötzlich ist kein Zugriff mehr auf die Disk möglich ...) für den Applikationssuport auszuschließen. Gruß, Nils

Moin, es ist völlig korrekt: Das geht nicht, Ist nicht vorgesehen, weil technisch nicht sinnvoll. Alle denkbaren Workarounds werden da auch nicht ernsthaft etwas bringen. Wenn ein User Zugriffsrechte auf das AD hat, dann kann er die von einem beliebigen Domänen-Rechner aus wahrnehmen. Genau das ist die Idee des AD. Gruß, Nils

Moin, OK, das bestätigt meine Vermutung. Konnte ich mangels Subdomain nicht testen. :) Danke für die Rückmeldung! Gruß, Nils

Moin, José liest die Domäne aus, in der man sich angemeldet hat. Das sollte auch mit Subdomains funktionieren. Gruß, Nils