NilsK

Mon, Der Punkt ist doch einfach, dass der TO bei dieser Nebensache etwas verwechselt. Was er wahrscheinlich meint: es gab man einen Verteiler mit einer bestimmten Adresse. Diese Adresse ist dann später einer Mailbox zugewiesen worden. Da das aber mit den Regeln nichts zu tun hat und wir das wissen, können wir uns ja auch wieder auf das Problem konzentrieren. Gruß, Nils

Moin, du hast den Path-Parameter ja sogar in deinem New-ADUser-Kommando drin. Dann übergib gleich den richtigen Pfad und fertig. Gruß, Nils

Moin, ich nehme auch an, dass man da nicht viel findet. Am Ende läuft es ja darauf hinaus, dass du die Mimik nachbauen müsstest, die es damals gab. Das wird seinerzeit niemand gemacht haben, weil es ja keinen Bedarf dafür gab. Da es ja aber auch keine neuen Updates mehr gibt, gibt es für beide Systeme auch einen endgültigen Stand. Daher sähe ich den Bedarf auch heute nicht. Gruß, Nils

Moin, Was ist denn der Hintergrund deiner Frage? Was willst du erreichen? Gruß, Nils

Moin, du hast dir deine Fragen schon fast selbst beantwortet. Du wirst alles "retten" müssen, was mit Berechtigungen zu tun hat. Auch bei nur 20 Usern kann das eine Menge Arbeit sein. Fragen wir mal andersrum: Was erhoffst du dir denn als Nutzen von einem Neuaufbau? Meist gibt es da falsche Vorstellungen, daher lass uns mal drüber reden. Erfahrungsgemäß ist es oft sinnvoller, eine AD-Umgebung aufzuräumen, als sie neu zu machen. Und was soll der Nutzen eines Linux-DCs sein? Solange du weiter mit Windows-RDS arbeitest, werden die Lizenzkosten für die gesamte Umgebung nahezu dieselben sein. Da würde ich dann auch einen echten und vom Hersteller supporteten DC nehmen, keinen Nachbau. Gruß, Nils

Moin, @Stephan Betken von den zwölf Slots stand nur die Hälfte für Externe zur Verfügung. Schon etwas ... eigen. Gruß, Nils

Moin, Ich wollte, habe aber keinen Slot als Speaker bekommen. Es gab allerdings auch nur sechs Plätze ... ob man dafür einen CfP machen musste, finde ich eher fraglich. Gruß, Nils

Moin, Aber vielleicht sollte man vorher doch noch mal die Anforderungen klären. #justsayin Gruß, Nils

Moin, ach so. Valider Punkt. Gruß, Nils

Moin und wozu fährst du den alten DC dann herunter? Was ist der Erkenntnisgewinn? Ich verweise da auf Evgenijs fette Aussage. Dampfen wir es ein auf: Nachdem alles gesynct ist, gucken ob die NETLOGON-Freigaben auf dem Neuen da sind und ob das Eventlog ohne relevante Fehler ist. Wenn ja: Alten DC herunterstufen und ggf. verschrotten. Gruß, Nils

Moin, das geht los bei "du musst nichts zusätzlich beschaffen". Bei Windows 10 ist der Windows Defender an Bord, der nicht schlechter ist als andere Antivirensoftware. Der hat zwar kein zentrales Management, aber das ist in eurer Umgebung evtl. auch verzichtbar. Für das Backup kann man mit dem eingebauten Windows Server Backup starten. Für andere Empfehlungen müsste man sich genauer ansehen, was in der Umgebung läuft und welche Anforderungen es im Detail gibt. Das würde ich aber nicht per Forum machen (5 Experten, 6 Meinungen), sondern einen kompetenten Dienstleister fragen. Gruß, Nils

Moin, du machst mir Angst. Ich bin genau derselben Ansicht. Gruß, Nils

Moin, Der Hack besteht darin, das nicht mit dem Explorer zu machen, sondern mit einem anderen Werkzeug, das die Kopie so nennt, wie du sie haben willst. Konfigurierbar ist es im Explorer nicht. Gruß, Nils

Moin, oh, dass die Zertifikate Teil des Roaming Profiles sind, hatte ich gar nicht auf dem Schirm. (Für Evgenij: beides böse.) Das mit Credential Roaming musste ich nie machen, habe ich keine Erfahrung mit. Kann sicher das eine oder andere abmildern - wenn man es denn will. Aus prinzipieller Sicht ist das nicht nur eine gute Idee. Gruß, Nils

Moin, das ist "works as expected". Ein Zertifikat bestätigt, dass der Inhaber eines Public-Key-Paares derjenige ist, für den er sich ausgibt. Die Logik dahinter ist, dass nur dieser Inhaber Zugriff auf seinen Private Key hat. Der Private Key wird standardmäßig lokal in einem geschützten Bereich des Benutzerprofils gespeichert (vereinfacht gesagt). Auf einem "neuen" Rechner hat der User keine Kopie seines Private Keys (der soll ja schließlich privat sein und nicht wild durch die Gegend kopiert werden, schon gar nicht irgendwie automatisch). Also erzeugt Windows bei der Aufforderung, für den User ein Zertifikat zu erzeugen, ein neues Schlüsselpaar. Ja, das wirft organisatorische Probleme auf, wenn Anwender an unterschiedlichen Rechnern arbeiten. Denn natürlich handelt es sich hierbei um unterschiedliche Zertifikate. Was der User in diesem Szenario also etwa mit seinem Private Key auf Rechner A verschlüsselt, kann er mit dem Public Key auf Rechner B nicht entschlüsseln. Gruß, Nils

Moin, abgesehen von den organisatorischen und rechtlichen Belangen, sollte auch aus technischer Sicht das Zurücksetzen des Kennworts nur ein "letztes" Mittel sein. Es hängen Dinge unwiderbringlich an dem Kennwort, z.B. der Zugriff auf EFS-verschlüsselte Daten. Das wird zwar kaum "absichtlich" genutzt, kann sich aber trotzdem als gravierendes Problem auswirken (weil es umgekehrt auch fast nirgends abgeschaltet wird). Gruß, Nils

Moin, schon klar, aber vielleicht können wir es andersrum machen: Er könnte angeben, dass man ihn per PN kontaktieren kann, wenn Interesse besteht. Gruß, Nils

Moin, sowas sollten wir per PN klären, nicht im Forum. Hier ist Community, nicht Kommerz. Gruß, Nils

Moin, es muss halt jemand organisieren. Und bei aller Professionalität, die die cim hatte, war die Vorbereitung immer der Punkt, der am schlechtesten geklappt hat. Das hat zu erheblichen Belastungen einzelner Personen geführt, und es war auch finanziell immer, sagen wir, ein Thema. Sowas unterschätzt man leicht, wenn man sich als Besucher denkt "wär schon schön". Auch wenn der cim-Mythos besagt, dass es ja schließlich mit Bratwurst und Planschbecken im Garten angefangen hat, ist das schon ab dem zweiten Mal eben kein akzeptables Niveau mehr. Gruß, Nils

Moin, der Anfang vom Ende war 2019. All good things come to an end. Man muss es dann auch irgendwann akzeptieren. Gruß, Nils

Moin, Dann ist die Sache entweder deutlich komplizierter oder viel einfacher - je nachdem, wie man sie angeht. Ein Holzweg ist es in so einer Umgebung jedenfalls, Anwender irgendwas selbst installieren zu lassen. So eine Umgebung lädt eigentlich dazu ein, den Anwendern einen genau auf sie zugeschnitten Satz an Software zu geben. Das dürfte aber den Rahmen dessen sprengen, was man in einem Forum erläutern kann. Ich empfehle, das gemeinsam mit jemandem zu entwerfen, der sich mit solchen Umgebungen (RDS oder VDI) auskennt. Gruß, Nils

Moin, Ich habe jetzt das Problem nicht verstanden. Wer arbeitet denn noch an den Entwickler-Rechnern? Und warum dürfen diese Leute die Software nicht benutzen? Es geht nicht darum, dich infrage zu stellen, sondern das Szenario zu verstehen. Ohne solche Einblicke kann es sein, dass wir dir etwas empfehlen, was überhaupt nicht passt oder es anders besser oder leichter geht. Gruß, Nils

Moin, Fangen wir doch mal von der richtigen Seite an: was ist denn die Anforderung, die du erfüllen musst? Wenn wir dazu mehr wissen, können wir dir vielleicht bessere Hinweise geben. Gruß, Nils

Moin, Womit wir wieder bei dem Punkt sind, vom Recovery herr zu planen. Es ergibt durchaus Sinn, das AD parallel mit mehreren Methoden zu sichern. Auf ein normales System State Backup würde ich nie verzichten, schon weil es das einzige ist, das der Hersteller des AD wirklich unterstützt. Gruß, Nils

Moin, Vor allem sollte man berücksichtigen, dass es nicht auf das Backup ankommt, sondern auf das Recovery. Mir wäre jetzt nicht klar, was du in welcher Situation aus deinen Exporten wiederherstellen willst. Und wozu du diese dann auf mehreren DCs bräuchtest. Vielleicht hast du da eine konkrete Idee, aber zumindest mir ist so eine Anforderung noch nie über den Weg gelaufen. Gruß, Nils