NilsK

Moin, das ist nicht so ohne Weiteres möglich. Spätestens beim Import wird es schwierig, weil die Berechtigungen intern mit SIDs gespeichert sind, nicht mit den Namen der Konten. Da die Objekte in der Zieldomäne andere SIDs haben, lassen sich die Quellberechtigungen so nur mit höherem Aufwand übertragen. Du findest im Web eine ganze Reihe von Skripten, die die ACLs von AD-Containern ausgeben. Basierend darauf könnte man eine CSV-Logik bauen, die die Namen (nicht die SIDs) der berechtigten User oder Gruppen pro Container ausgibt. Damit könnte man dann ein Importskript bauen. Aber: Die Berechtigungen im AD können sehr komplex sein, es kann durchaus -zig Einträge für einen Container geben. Erschwerend kommt hinzu, dass die meisten ACL-Einträge vererbt sind. Noch dazu kann die Vererbung ihrerseits sehr komplex sein. Und damit nicht genug: Berechtigungen können auch für einzelne Objektklassen oder sogar für Attribute gelten. Damit müsste eine Lösung passend umgehen - das macht die Sache beliebig aufwändig. Hier wäre also zu prüfen, ob ein Import/Export wirklich eine passende Lösung ist. Gruß, Nils

Moin, den Einwand höre ich immer mal wieder, aber wie Norbert schon sagt: Das ist eine prinzipielle Frage, die auf das Funktionsprinzip einer Festplattenverschlüsselung abzielt. Die Festplattenverschlüsselung - speziell Bitlocker, aber im Prinzip auch die anderen - soll "Data at rest" schützen, also die Offline-Daten auf der Festplatte. Es soll nicht möglich sein, die Platte in einen anderen Rechner einzubauen und dort zu lesen. Ebenso soll es nicht möglich sein, den Rechner mit einem anderen Betriebssystem zu starten und die Daten damit zu lesen. Sobald der Rechner gestartet ist und das zugelassene Betriebssystem läuft, ist dieses für den Schutz der Daten verantwortlich. Die reine Verschlüsselung nützt also wenig, wenn das Betriebssystem nicht ausreichend sicher konfiguriert ist. Im Energiesparmodus läuft aus dieser Perspektive das Betriebssystem weiter. Der Zustand unterscheidet sich aus Sicht der Festplattenverschlüsselung also nicht von einem laufenden Betriebssystem - Windows muss dafür sorgen, dass nur autorisierte Zugriffe stattfinden. Oder anders gesagt; Jede (marktübliche) Festplattenverschlüsselung zielt nur auf bestimmte Szenarien, typischerweise auf Offline-Angriffe. Für alle anderen Szenarien müssen andere Schutzmechanismen ergänzt werden. Oder noch anders gesagt: Der Energeisparmodus umgeht Bitlocker nicht, und er ist auch nicht per se ein Sicherheitsproblem. Gruß, Nils

Moin, grundsätzlich ist ein RODC nicht primär für den Betrieb in einem "weniger sicheren" Netz gedacht. Man kann ihn dafür zweckentfremden, aber dann muss das Gesamtdesign dazu passen. So wäre es hier mindestens erforderlich, den Verkehr aus dem Fertigungsnetz so einzuschränken, dass kein Rechner eine Kommunikation mit den DCs im "sicheren" Netz herstellen kann, denn sonst könnte man den RODC ja auch einfach umgehen. Man kriegt so etwas hin, aber das ist nicht trivial und lässt sich nicht innerhalb eines Forums klären. Ob das Ganze dann ein sinnvolles Konstrukt ergibt, ist eine Frage des Gesamtdesigns und der Anforderungen, wie Norbert schon richtig sagt. Gruß, Nils PS. Da Norbert und ich uns zufällig gerade mit sowas befassen: Für so ein Design kann es durchaus erforderlich sein, ein umfangreiches Projekt mit Laufzeiten von mehreren Monaten und entsprechendem Aufwand aufzusetzen.

Moin, die Computerrichtlinien gelten immer nur für die lokalen Konten des jeweiligen Rechners. Möchte man die Einstellungen für die Konten des AD vornehmen, dann geht das nur in einem GPO, das auf der Domänenebene definiert ist - und nur dort. GPOs auf OU-Ebene wirken nicht auf die Kennworteinstellungen von AD-Konten, sondern würden sich nur auf die lokalen Konten der Computer auswirken, deren Konten in der betreffenden OU gespeichert sind. Aufgrund diverser Effekte sollten die Kennworteinstellungen für das AD ausschließlich in der Default Domain Policy definiert werden, nicht in einem eigenen GPO auf Domänenebene. Die Einstellung "Kennwort läuft nie ab" bei einem Useraccount übersteuert für diesen einen Account das maximale Kennwortalter, das per Policy gesetzt ist. Gedacht ist das vor allem für Dienstkonten, damit nicht urplötzlich der SQL Server wegen eines Anmeldefehlers stehenbleibt. Alle anderen Einstellungen der Policy gelten dann aber weiter. Dies betrifft sowohl lokale als auch AD-Konten. Gruß, Nils

Moin, zunächst einmal würde in dem Status, in dem sich die Anfrage befindet, zunächst eine Beratung erfolgen. Das geht zwar grundsätzlich auch telefonisch, aber erfahrungsgemäß ist man da sehr eingeschränkt. Dann kann es durchaus sein, dass man im Zuge dieser Beratung feststellt, dass es auf mehr als ein wenig Detailkonfiguration hinausläuft. In sofern wäre es natürlich schon relevant, ob wir von Flensburg oder Oberammergau reden, denn wenn der eine oder andere Termin vor Ort sinnvoll ist, entscheidet die Entfernung über die Kosten mit. Auch wenn es nicht der Sinn dieses Forums ist, Dienstleistungsangebote zu unterbreiten: Das Unternehmen, bei dem ich arbeite, ist in Hannover. Wenn das von Interesse ist, schreib mir gern eine PM. Gruß, Nils

Moin, was hast du da vor? Ist das eine Testumgebung? Zu welchem Zweck? Was meinst du mit ? Gruß, Nils

Moin, auf keinen Fall mit dem Delegations-Assistenten arbeiten! Das Ding ist unbrauchbar. Man kann fast nichts damit festlegen - und vor allem: Man sieht nur das, was man jetzt gerade neu einrichtet, aber nicht den vorhandenen Zustand. Damit kann man sich z.B. dann auch nicht korrigieren. Auch wenn es zunächst aufwändiger ist: AD-Berechtigungen nur per dsacls mit einem Skript setzen und immer in einem Testlab detailliert durchspielen. Das so entwickelte Skript kann man dann auf die Produktion anwenden, gleichzeitig bildet es die Dokumentation. Siehe Schritte 1 und 2 aus: [AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net] https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/ Zur Kontrolle vorhandener AD-Berechtigungen eignet sich LIZA: [Liza: Berechtigungen in Active Directory analysieren | faq-o-matic.net] https://www.faq-o-matic.net/2010/04/06/liza-berechtigungen-in-active-directory-analysieren/ Abgesehen davon, klingt die beschriebene OU- und Berechtigungsstruktur, als sollte man da dringend das Design überarbeiten. Gruß, Nils

Moin, ... weil? Gruß, Nils

Moin, dann würde ich den Anwendern gar keinen Desktop bereitstellen, sondern nur die Applikationen. Gruß, Nils

Moin, Mandatory Profiles sind eine Technik aus NT-Zeiten - über 20 Jahre alt und damals schon alles andere als zuverlässig. Zudem sorgen solche Profile vorhersagbar für Datenverluste. Anforderungen definieren und passende Lösungen finden. Also: Was soll genau erreicht und was genau verhindert werden? Und warum? Gruß, Nils

Moin, das war dann aber auch keine Storage Live Migration. Mir sind keine Probleme bei der Storage Live Migration bekannt, die vom Gast-OS abhängen. Das sollte davon, genau wie bei einer "normalen" Live Migration, gar nichts mitbekommen. Höhere Sicherheit erzeugt ein Test unter realistischen Bedingungen. Gruß, Nils

Moin, ja, davon kannst du auch ausgehen. Seit Windows Server 2016 gibt es keine separaten Updates mehr für die Integrationsdienste, die sind Teil der "allgemeinen" Updates und innerhalb dieser auch leider nicht zu identifizieren. Dein Checkpoint-Problem kann eine ganze Reihe von Ursachen haben. Generell sollte man in Produktionsumgebungen nicht mit Checkpoints arbeiten, sondern eine sinnvolle Backup-Restore-Strategie aufbauen. Da alle Versuche, an dem Problem etwas zu ändern, ein hohes Risiko erzeugen, empfehle ich einen Supportcall bei Microsoft. Kannst du den Checkpoint exportieren, der das Problem hat? Oder schlägt das ebenfalls fehl? Gruß, Nils

Moin, wobei es mich schon wundern würde, wenn während einer Flugzeuglandung oder einer OP Online-Wetten gespielt werden. In solchen Applikationsfällen gibt es andere Verfügbarkeitsmechanismen. Und nebenbei ist Shared-Nothing Live Migration kein Verfügbarkeitsmechanismus, sondern eine Management-Technik. Beim Ausfall eines VM-Hosts ist die Wiederanlaufzeit i.d.R. im Bereich zwischen 30 Sekunden und 10 Minuten. Wenn das nicht OK ist, dann ist der Aufbau eben nicht passend und man braucht einen anderen. Gruß, Nils

Moin, ja und, dann ist der Artikel eben 12 Jahre alt. Auf meinem IT-Blog habe ich Artikel, die sind an die 20 Jahre alt und treffen immer noch zu. Nicht alles, was alt ist, ist überholt. Genau wie nicht alles, was neu ist, zutrifft. Zahni hat dir einen Artikel verlinkt, der den technischem Umstand erläutert, auf den er hinzuweisen versucht. Du musst das nicht annehmen, aber es arrogant abzutun, bringt dich ganz sicher nicht weiter. Gruß, Nils

Moin, naja, in dem Fall leg doch die VMs gleich auf der Systemplatte an, sofern da übergangsweise genug Zeit Platz ist. Wenn dann das RAID fertig ist, verschiebst du die VHDX-Dateien lokal auf das RAID, das geht ohne Downtime. So sparst du einen Verschiebevorgang. Oder du erzeugst die VMs auf einem ganz separaten System und verschiebst sie auf den Zielhost, wenn der fertig ist. Möglichkeiten über Möglichkeiten. ;) Gruß, Nils

Moin, im Wesentlichen kann man so vorgehen, wie Norbert beschreibt. Das erzeugt dann eine Downtime für die VMs. Da du den Host aber wohl ohnehin abschalten würdest, um die Platten einzubauen, gäbe es die Downtime ja sowieso. Falls ein zweiter Host zu Hand ist, könntest du die VMs auch im laufenden Betrieb dorthin verschieben ("Shared-Nothing Live Migration"), dann gibt es keine Downtime für die Anwender. Wenn der eigentliche Host dann fertig ist, verschiebst du die VMs auf demselben Weg zurück. Gruß, Nils

Moin, was hat die DSGVO mit einem AD zu tun? Und wie kommt man auf die Idee, dass die DSGVO mit irgendwas aus der Kategorie "kurzerhand" oder "mal eben" kompatibel wäre? Was dort schief läuft, lässt sich aus der Ferne nicht sagen. Wenn du allerdings mit nativen AD-Funktionen arbeiten willst, warum dann einen AD-Nachbau nutzen und kein echtes AD? Ihr werdet ja kaum eine Umgebung völlig ohne Windows-Server haben, sodass Lizenzkosten nicht das Argument sein können. Ein echtes AD ist supportfähig, ein unechtes nicht. Gruß, Nils

Moin, in deinen ursprünglichen Anforderungen steht nichts von einer Pre-boot Authentication. Du könntest, sofern das zutrifft, also schlicht auf den PIN verzichten. Bevor jetzt alle an die Decke gehen: Das ist ein typischer Fall, in dem man die Anforderungen genau klären muss. Bitlocker (oder eine andere Lösung) ohne PIN (aber mit TPM) sichert "Data at rest", also die Daten auf der abgeschalteten Platte. Bleibt die Platte im selben Gerät, kann jeder sie starten, dann geht der Schutzbedarf auf das laufende Windows über. Das kann ausreichen und es kann nicht ausreichen - das muss der TO klären. Eine Methode, die Pre-Boot-Auth erfordert und gleichzeitig für wechselnde Anwender geeignet ist, wäre mir zumindest nicht bekannt. Mag sein, dass es welche gibt, aber ich vermute mal, dass es dann teuer wird. Gruß, Nils

Moin, aufs Geratewohl rumprobieren kann man viel. Mit systematischer Fehlersuche hat das aber wenig zu tun. Vermutlich wäre es wirklich am besten, du holst dir mal jemand ins Haus, der sich mit der Materie auskennt, und der schaut sich das in Ruhe an. Nach dem Verlauf dieses Threads glaube ich nicht, dass das auf die bisherige Weise noch viel Sinn ergibt. Gruß, Nils

Moin, schau an, wieder was gelernt. Also war mein Verständnis der Anfrage ungefähr richtig? Sehr schön übrigens mal wieder die französische Sprache, es ist ja offenbar ein französisches Projekt: Gestionnaire libre de parc informatique - "parc informatique", das hat was. Gruß, Nils

Moin, da kann ich mir ehrlich gesagt den Bedarf grad nicht so richtig vorstellen. Welches Grundproblem soll das System lösen? Dass ihr sehr viele Büros, sehr viele Mitarbeiter und viele Umzüge habt? Oder worum geht es im Kern? Gruß, Nils

Moin, ganz ehrlich: Bei so einer kleinen Umgebung kein Hyperconverged. Hyperconverged kommt aus dem Hyperscale-Bereich, also sehr große Umgebungen. Da ist das toll. In KMU-Umgebungen ist das nicht nur viel zu teuer, sondern auch viel zu komplex und viel zu unflexibel. Bezüglich "unterbrechungsfrei" ... auch da solltest du noch mal mit deinen Anbietern sprechen. "Unterbrechungsfrei" ist für eine ganze VM-Umgebung faktisch nicht machbar. Allerdings ist es in Wirklichkeit auch so, dass fast niemand das bräuchte. Ein gutes Beratungshaus diskutiert das in der Tiefe mit dir. Klärt, was ihr wirklich braucht. Ich erlebe es oft, dass Kunden erst meinen, sie bräuchten "Jeder, immer, alles", und wenn man dann gemeinsam draufschaut, tut es auch was viel Kleineres. Beispielsweise würde eine Replica-Lösung mit kürzerem Intervall auch eine bessere Wiederherstellbarkeit ergeben. Wichtig sind ja die Applikationen, nicht die Infrastruktur. Gruß, Nils

Moin, es geht hier ja um Windows Server 2016, nicht um Windows 10. Technisch wird es da nur darum gehen, ein paar optische Features ein- oder auszuschalten und ein paar Serverdienste bewusst wegzulassen. Das ist keine große Magie. Windows Server 2016 Standard und Datacenter unterscheiden sich technisch in der Hinsicht auch nicht - wäre aber auch egal, wenn auf dem Host Datacenter installiert ist (soweit ich verstanden habe, darf man dann die VMs ja auch als Standard installieren, aber selbst wenn nicht, wäre das technisch kein Unterschied). In der VDI-Szene ist das ein völlig übliches Vorgehen, um Microsofts, naja, wenig durchdachte Lizenzbestimmungen daran zu hindern, die VDI-Technik zu massakrieren. Wenn man auf die RDS-Lizenzen achtet, wüsste ich auch nicht, was daran rechtlich nicht OK wäre. Das ist nichts anderes als ein herkömmlicher Terminalserver, der von genau einem Anwender verwendet wird. EDIT 2: Habe gerade noch mal den Eröffnungspost nachgelesen - falls der Kunde meint, er brauche in seinem Szenario keine RDS-CAL, dann ist das natürlich nicht korrekt. Der Witz an VDI besteht ja gerade darin, dass er die RDS-Funktion nutzt, ohne die geht es nicht. (Dass mir der Vorteil von VDI gegenüber "klassischem" Server-RDS in fast keinem Szenario einleuchtet, steht auf einem anderen Blatt.) Gruß, Nils

Moin, [OT] hier in Hannover selbstverständlich nur der mit den Zähnen. [/OT] Gruß, Nils

Moin, ich würde eher vermuten, dass die dort die Hände über dem Kopf zusammenschlagen und das für nicht supported erklären ... Gruß, Nils