NilsK

Moin, oh, das ist eine lange Geschichte ... [Die AD-DNS-Zone sicher konfigurieren | faq-o-matic.net] http://www.faq-o-matic.net/2015/04/08/die-ad-dns-zone-sicher-konfigurieren/ Gruß, Nils

Moin, alles, was du aufzählst, belegt, dass USB-Medien für Backups nicht geeignet sind. Wenn die Anforderung besteht, verschlüsselte Backups zu erzeugen, dann geht in einem Unternehmensnetzwerk aus meiner Sicht kein Weg um eine professionelle Lösung herum. Basteleien mit Techniken, die für etwas anderes gedacht sind, führen in die Irre. Gruß, Nils

Moin, du suchst Rekursion. Kapsele das Auslesen der OUs in eine Funktion. In der Funktion liest du dann die Unter-OUs aus, und für jede Unter-OU rufst du dann die Funktion selbst wieder auf. Gruß, Nils

Moin, najaaaa ... für viele Szenarien ist DFS eben nicht geeignet. Vor allem deshalb, weil es nach dem "Last Writer Wins"-Prinzip arbeitet. Sobald also Daten von mehr als einem Benutzer verwendet werden, wird es schwierig. Oft ist die bessere Variante, die Anwender zu den Daten zu holen, mit anderen Worten: Terminalserver. Gruß, Nils

Moin, es kann dort keinen Performancevorteil geben, sogar eher einen Nachteil. Der virtuelle SCSI-Controller wird ja in jedem Fall vom Hypervisor bereitgestellt und läuft immer über den (einzigen) Virtual Bus. Gruß, Nils EDIT: Korrektur siehe weiter unten.

Moin, nein, das ist nicht so. Du hast zwei Forests. Durch den Trust bleiben es immer noch zwei getrennte Forests. Die Forestgrenze ist unverrückbar. Gruß, Nils

Moin, hm, dann klingt das Design aber etwas komisch. Ihr habt nur ein PSO, und es gibt gar keine Anforderungen dafür? Dann würde ich kein PSO einsetzen. Gruß, Nils

Moin, für mich klingt das nach einem Designfehler in deinem Cluster. Ein Dateiserver mit CSV ist nur als Scale-out Fileserver gedacht. Dort sind nur Applikationen vorgesehen (konkret Hyper-V und SQL Server), aber keine Userdaten. Auf einem SoFS brauchst du also keine Shadow Copies, das Szenario passt nicht. Oder missverstehe ich dich da? Gruß, Nils

Moin, auch wenn du die Platte zum automatischen Entsperren eingerichtet hast, braucht sie im Hintergrund ein Kennwort, also einen Eingriff, bevor sie ansprechbar ist. Für einen Backupvorgang halte ich das für nicht sinnvoll. Der muss ohne solche Besonderheiten laufen, sonst fällt er zu schnell auf die Nase. Bei einem Recovery kann man sowas auch nicht brauchen. Von der allgemeinen Eignung von USB-Laufwerken für die Datensicherung will ich gar nicht erst anfangen. Gruß, Nils

Moin, wenn du inkrementell sichern willst, musst du die Platte exklusiv dem Backup zuweisen, mit Formatierung. Da ist Bitlocker dann also nicht das Mittel der Wahl. Wie hast du Bitlocker da überhaupt eingerichtet? Mit Bitlocker to go? Das wäre für das Szenario sowieso nicht geeignet. Gruß, Nils

Moin, nein. Wie wäre es, wenn du dir das mal ansiehst? Gruß, Nils

Moin, sollte sich auch auf den Beitrag darüber beziehen. Du bist mir sozusagen dazwischengekommen. ;) Gruß, Nils

Moin, am einfachsten per Gruppenrichtlinie: Lokal anmelden verweigern. Gruß, Nils

Moin, dann viel Spaß. Wenn du das fertig hast, kannst du reich damit werden. Da wären technisch doch eine ganze Reihe von Herausforderungen zu meistern. Denke nur an Applikationen, die lokale Daten (zwischen-) speichern. Die müsstest du auch alle übertragen. Dann hättest du eine Anmeldesession, die von der lokalen Autorität verwaltet wird, die dann irgendwie in die LSA des Zielservers übergehen müsste. Die Prozesse, deren IDs sich nicht ändern dürften, die Handles dazu. Von Netzwerkverbindungen ganz zu schweigen (wobei die grundsätzlich verglichen mit den anderen Themen sogar eher "einfach" wären). Gruß, Nils

Moin, Globale Gruppen sind immer domänenintern, es kann dort nur Mitglieder aus derselben Domäne geben. Es muss ja einen Gruppentyp geben, bei dem man sich darauf verlassen kann, dass er nur die eigene Domäne betrifft. Daher wird bei einer Globalen Gruppe nur die eigene Domäne angezeigt, wenn man Mitglieder verwaltet. Sie können in jeder Domäne, auch in vertrauten Domänen anderer Forests, Berechtigungen erhalten. Domänenlokale Gruppen können Mitglieder aus allen vertrauten (!) Domänen enthalten. Sie können aber nur in der eigenen Domäne Berechtigungen bekommen. Universalgruppen können Mitglieder aus allen Domänen des eigenen Forests (!) enthalten. Sie können in jeder Domäne, auch in vertrauten Domänen anderer Forests, Berechtigungen erhalten. Da deine Domänen nicht demselben Forest angehören, kannst du keine Universalgruppen nutzen, um Mitglieder aus beiden Domänen zusammenzufassen. [Group scope: Active Directory] https://technet.microsoft.com/en-us/library/cc755692%28v=ws.10%29.aspx [Windows-Gruppen richtig nutzen | faq-o-matic.net] http://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ Für Exchange ist das ohnehin nicht geeignet, weil die Exchange-Grenze der Forest ist. Gruß, Nils

Moin, ja, in dem Fall passt die Logik der Applikation nicht zur Infrastruktur. Das könnte daran liegen, dass PSOs allgemein nur selten eingesetzt werden. Und das wiederum liegt meist daran, dass sie eben so lieblos implementiert sind ... Gruß, Nis

Moin, ich denke nicht, dass man die Funktion eines Archivsystems sinnvoll mit Robocopy nachebaut bekommt. Es hat schon seinen Grund, warum solche Software komplex und teuer ist. Gruß, Nils

Moin, noch mal langsam. Was genau möchtest du in was für Gruppen aufnehmen? In deinem Szenario dürften für die Zuweisung von Berechtigungen nur Domänenlokale Gruppen geeignet sein, wenn Berechtigungen an Mitglieder beider Domänen erteilt werden sollen. Gruß, Nils

Moin, gern. PSOs musst du separat abfragen, dafür gibt es keine zentrale Funktion. Die Technik gehört leider zu denen, die Microsoft nur sehr lieblos implementiert hat. Mein Doku-Tool José kann PSOs auf allen Ebenen berücksichtigen. http://www.faq-o-matic.net/jose/ Gruß, Nils

Moin, das ist die Arbeitsweise eigentlich jeder (Verdrängungs-) Archivierung. Dafür gibt es einen recht breiten Markt. Gruß, Nils

Moin, eigentlich nicht so schwer zu finden. http://lmbtfy.com/?q=active+directory+get+effective+password+expiry+date Gruß, Nils

Moin, wobei das mit den Logs doch eher eine theoretische Möglichkeit ist ... Gruß, Nils

Moin, korrekt. Keine Spezialberechtigungen. Man kann auch die lokale Anmeldung überall verweigern, um das Konto abzusichern. Gruß, Nils

Moin, in welcher Sprache? Gruß, Nils

Moin, du hast deshalb keinen vSwitch, weil bei dir die Einrichtung fehlgeschlagen ist, eben vermutlich wegen der Treiber- oder Hardwareprobleme. Eigentlich müsste einer in deinem System sein. Daher ja die Empfehlung, das Problem zu beseitigen und dann neu zu installieren. Und, wie jetzt schon mehrfach gesagt: Nein, du machst dort nichts manuell. Alles, was man konfiguriert, geschieht über den Hyper-V-Manager. Gruß, Nils