NilsK

Moin, deine Rekursion ist nicht richtig. Die Funktion muss per Parameter eine Start-OU als DN bekommen. Sie liest dann alle Unter-OUs aus. In einer Schleife ruft sie für jede Unter-OU sich selbst auf und übergibt den DN der jeweilogen Unter-OU als Parameter. Das Hauptskript ruft nur einmal die Start-OU auf. Den Rest macht die Funktion per Rekursion. Gruß, Nils

Moin, ich kann dazu nur beitragen, dass ich seit Windows 8 die Zuordnung von Standarddruckern als sehr instabil und unvorhersagbar erlebe. Das ist leider mit Windows 10 auch noch so. Möglich, dass das auch im Server so ist, ist ja derselbe Code. Gruß, Nils

Moin, vielen Dank. Anmerkungen zu deinen technischen Annahmen: 4-CPU-Maschinen sind sehr rar. Der Normalfall sind 2-CPU-Maschinen mit hoher Core-Zahl. Eine Ausstattung mit 4 CPUs à 4 Cores wird man praktisch nie antreffen. Selbst dann wäre aber zu berücksichtigen, dass pro CPU mindestens 8 Cores lizenziert werden müssen (siehe FAQ), da dürfte deine Berechnung also nicht hinhauen. Und: Im FAQ steht ausdrücklich: Das Kumulieren wird also weiter möglich sein. Gruß, Nils

Moin, so war es seit Jahren kommuniziert worden, ja. Es hatte da kurz nach dem Erscheinen von Hyper-V im Jahr 2008 Unklarheiten und, soweit ich mich erinnere, auch eine Korrektur der PURs gegeben, die dann das oben skizzierte Ergebnis hatte. Hintergrund ist im Wesentlichen, dass in genau dem Szenario, das du beschreibst, Hyper-V sonst auf dem Markt keine Chance gehabt hätte. Gruß, Nils

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