NilsK

Moin, in der jetzigen Situation werden wir aus der Ferne kaum noch sinnvoll etwas herausfinden bzw. sinnvolle Hinweise geben können. Der Status, den du beschreibst, klingt nach "total verbastelt". Ich fürchte, es hülfe auch nicht, Hyper-V zu entfernen und neu einzurichten, weil vermutlich das OS "drumrum" jetzt auch vergurkt ist. Wahrscheinlich ist es schneller und zielführender, Windows komplett neu zu installieren. Wenn du dann wieder nicht weiterkommst, beschreibe bitte genauer, was du probierst und was passiert. Aussagen wie sind leider nicht deutlich genug, um irgendwas daraus abzulesen. Gruß, Nils

Moin, Nein. Der DC ist sein eigener DNS-Client (oder fragt einen anderen DC). Den Server des Providers trägst du als Forwarder in der DNS-Server-Konsole ein. Gruß, Nils

Moin, naja, 2006 halt. Damals war das heißer Schei*. Das mit street (wird kopiert, ist aber nicht im GUI) und streetAddress (ist im GUI, wird aber nicht kopiert) ist eine meiner Lieblingsstories in Vorträgen. Da haben zwei Entwickler vor über 25 Jahren nicht richtig miteinander geredet, und weil das dann so ins Produkt kam, schleppen wir es seither mit. Könnte sein, dass die Story hier auch drin ist: https://www.youtube.com/watch?v=uQUsQqo7TVY Beachte dabei: dieses Attribut wird von dsa.msc (also AD-Benutzer und -Computer) ausgewertet, und dieses Admin-/Client-Programm führt dann die Duplizierung aus. Das ist kein Vorgang des Verzeichnisdienstes auf Serverebene. Insofern kannst du dir auch selbst ein Tool bauen, das einen User "kopiert" - was nichts anderes ist, als einen neuen User anzulegen und Werte aus der "Vorlage" zu übertragen. Gruß, Nils

Moin, ich würde vermuten: Einen Enterprise Admin. ;) Aber gut, dass es geht und danke für die Rückmeldung. Gruß, Nils

Moin, ja, genau. Der Prozess kann an der Stelle nicht sicher unterscheiden, ob es wirklich nur noch einen DC in dieser (Sub-)Domäne gibt (könnte ja sein, dass weitere aufgrund von Fehlern nicht erreichbar sind) und ob die Domäne wirklich entfernt werden soll. Macht man weiter, dann werden eben alle Daten dieser Domäne entfernt, unwiederbringlich. In deinem Fall willst du das ja. Würde man aber nur einen von mehreren DCs in einer noch aktiven Domäne entfernen, dann müsste diese Information ja in die AD-Konfiguration eingetragen werden, daher die Warnung. Gruß, Nils

Moin, was ist denn ein "WLAN-Switch"? Das Endgerät muss den Namen der VM auflösen können und das Routing zwischen den beteiligten Netzen muss in beide Richtungen funktionieren. Also möglicherweise etwas Gebastel und Rumtesten nötig. Gruß, Nils

Moin, na gut, das geht. Gruß, Nils

Moin, wenn es schnell, einfach und einmalig sein soll: Öffne dein CSV in Excel und lass dir dort für jeden User ein "net user"-Kommando mit Angabe des richtigen Logonskripts generieren. [Excel: Admins unbekannter Liebling | faq-o-matic.net] https://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Leider geht das mit dsa.msc nicht. Das Suchergebnisfenster kann leider viel weniger als die Hauptansicht. Gruß, Nils

Moin, ähm ... für drei Mitarbeiter? Ich glaube nicht, dass das so sinnvoll ist. Kosten und Nutzen scheinen mir da in ungünstigem Verhältnis zu stehen. Gruß, Nils

Moin, wie hast du es denn in VBA gelöst? So unterschiedlich sind die Dialekte ja nicht. Und was hast du mit welchem Ergebnis in VBS versucht? Die Methode "FolderExists" und die Collection "Folders" sind dir bekannt? Gruß, Nils

Moin, ja, nervig sowas. Leider habe ich (auch) keine Lösung dafür. Gruß, Nils

Moin, ich brauche überhaupt keine. Du brauchst sie. Ohne weitere Angaben ist "nimm einen NAS oder einen Dateiserver pro Seite" eine ausreichende Lösung. Was du da hin- oder herkopieren willst, habe ich nicht verstanden, aber das ist dann eben das, wo die einfache Lösung vielleicht nicht ausreicht. Gruß, Nils

Moin, ich nehme an, dass das eher ein lokales Problem ist als irgendwas, was "aktuell" von Teams kommen würde. Leider ist Teams manchmal tatsächlich etwas hakelig, wenn es um das Ansprechen von Geräten geht. Das hängt nach meiner Einschätzung/Erfahrung aber eher mit dem konkreten Gerät bzw. Treiber zusammen. Gruß, Nils

Moin, mpf. Nee. ESAE ist so dermaßen viel mehr als "eine weitere Domäne mit Trusts", dass ich es in diesem Kontext fast abwegig finde. Der TO ist noch viel weiter "vorne" und möchte erst mal Basics bereitstellen. Da sollten wir ihm nicht als erstes mit einem der komplexesten Entwürfe kommen, die es gibt. Gruß, Nils PS. Die beste Security ist die, die man auch umsetzt. ESAE-Konzepte tendieren leider dazu, in der Schublade zu bleiben.

Moin, @djmaker und @Nobbyaushb, ihr seid auf dem falschen Dampfer. @SaschaVolk man kann das sicher alles machen, aber dazu können wir gar nichts sagen, ohne die Anforderungen zu kennen. Ob man nun einen Windows Server oder ein Appliance-NAS nimmt, hat für die Sicherheit nur sehr indirekt eine Auswirkung. Und wie du den Dateiaustausch organisierst, ist eben eine Frage der Anforderungen. Gruß, Nils

Moin, Okay, dann hatte ich das missverstanden. Es geht also darum, eine komplett neue Domäne in einem neuen Forest einzurichten. Das könnte man tun, aber ... ... es würde ja keins der Ziele des TO erreichen. Es geht ihm nicht um eine Admin-Domäne, sondern er will, dass die User sich überall anmelden können. Dafür braucht man Vertrauensstellungen zwischen allen Domänen, und dafür wiederum wäre eine zusätzliche Domäne keine Hilfe, sondern würde die Sache nur noch komplexer machen. Statt vier einzelner Domänen gäbe es dann fünf. Gruß, Nils

Moin, Nö, genau das geht ja nicht. Wenn man möglichst wenig Arbeit will, richtet man erst mal Vertrauensstellungen zwischen allen Domänen ein. Und wenn man es dann später richtig machen will, macht man genau eine Domäne für alles und migriert alles da rein. Gruß Nils

Moin, Naja ... Es ordentlich zu machen, hätte vielleicht 30 Minuten länger gedauert. Dafür würde ich nicht mag drüber nachdenken, etwas möglicherweise nicht Supportetes zu machen. Gruß, Nils

Moin, Aber warum überhaupt? Warum es nicht richtig machen und einen zweiten DC dazu installieren? Dann den Eval runterstufen und weg damit. Und überhaupt: eine Eval ist nicht für Produktion zugelassen. Also kann es ja kaum sein, das da eine produktive Installation drauf ist. Oder wie siehst du das? Gruß, Nils

Moin, nehmen wir den, da ist kein Disclaimer dabei: https://docs.microsoft.com/en-us/windows/win32/adschema/a-telephonenumber Es lebe die redundante Inhaltsablage. Gruß, Nils

Moin, kurz: nein. Es kann aber sein, dass künftig Anwendungen mit dem alten Modus nicht klarkommen. Neben Exchange gibt es da aber nur wenige. Allerdings: Wenn ihr keine alten DCs mehr habt, dann spricht auch nichts (= null) dagegen, den Modus hochzustellen. Dauert in den meisten Umgebungen fünf Minuten und hat, kurz gesagt, keine Risiken. Gruß, Nils

Moin, wenn ihr Exchange habt, bieten sich immer dessen Extended Attributes an. Es gibt auch ein Pendant dazu, das sind die Cloud Extension Attributes. Sonst gib es noch hunderte weitere - ob die geeignet sind, legt man am ehesten selbst organisatorisch fest. Dass nach über 20 Jahren noch kommerzielle Produkte ankommen, die so ein Attribut ihrerseits verwenden und davon abhängig sind, ist doch eher unwahrscheinlich. Gruß, Nils

Moin, das, was Martin sagt. Plus den Hinweis: Eine technische Absenderangabe dient zur Identifikation. Titel und sonstiges (Selbst-) Marketing sind in einer Signatur richtig aufgehoben. Da darf man auch mal eine politische Entscheidung treffen. Gruß, Nils ... der diese Sorte Diskussion zuletzt in mit einem Kirchenkunden führte ... beeindruckend, welche Vielfalt an Titeln es da gibt.

Moin, möglich ist vieles. Für mich lag der Gednke jetzt nahe, weil es mit PDF ja anscheinend die Verzögerungen nicht gab. In Zips und Office-Dokumente gucken viele Scanner halt genauer rein. Gruß, Nils

Moin, ich tippe mal: Da ist ein Virenscanner im Spiel. Gruß, Nils