NilsK

Moin, zunächst sollte eine CA nicht auf einem DC installiert werden. Ich würde sogar sagen: Da gehört sie auf keinen Fall hin. Dann: Vielleicht wäre es sinnvoll, die Umstellung zum Anlass zu nehmen, die PKI noch einmal konzeptionell zu überdenken. Für kleine Unternehmen kann eine einstufige PKI zwar ausreichen, aber das sollte man durchaus noch mal prüfen, ob das (noch) zutrifft. Und schließlich: Abhängig davon, wie die PKI bislang genutzt wurde, könnte man sie auch einfach gar nicht migrieren und stattdessen eine neue aufbauen. Die vorhandenen Zertifikate ließe man dann einfach auslaufen - oft ist das ein gangbarer Weg. Für die Zeit muss man nur sicherstellen, dass das Root-Zertifikat und die CRL an mindestens einem Pfad verfügbar sind, der in den Zertifikaten angegeben ist. Dafür muss man die alte CA nicht online halten, es müssen nur die Pfade erreichbar sein, z.B. auf neuen/anderen Servern, die denselben Namen haben. Natürlich hängt das von einer Prüfung ab, ob dieser Weg möglich ist. Falls migriert werden soll, dürften die für ältere Versionen dokumentierten Verfahren auch mit Windows Server 2016 noch funktionieren. Gruß, Nils

Moin, denkbarer Ansatz: Ausgabe der AD-User in demselben Format, das auch die vorhandene CSV-Liste aufweist Vergleich der beiden Listen mit Compare-Object Gruß, Nils

Moin, hast du in der Domäne schon rodcprep ausgeführt? Das Szenario für RODCs hast du komplett durchdacht? Was willst du mit dem RODC lösen? Oft gibt es da eine Menge Missverständnisse. Tatsächlich treffe ich in der Praxis so gut wie nie RODCs an, und wenn, dann werden sie erstaunlich häufig falsch eingesetzt. Gruß, Nils

Moin, also, wie gesagt: So meinte ich das nicht. Ich habe von Einschränkungen gesprochen, die man im Blick haben sollte, nicht von Über- oder Unterlegenheiten. Und ich habe mich dabei auch weniger auf NetApp bezogen (das kam erst später ins Spiel) als auf andere Implementierungen, die meist eben längst nicht so weit sind und auch nicht die "ausgleichenden" Vorteile bieten, die NetApp unzweifelhaft hat. Mein Punkt ist: Man sollte bei solchen Planungen auf die Anforderungen schauen. Ich habe sehr viele Umgebungen auf NetApp migriert, und einige wenige haben danach die eine oder andere Einschränkung festgestellt, die sie vorher nicht auf dem Schirm hatten. Die war meist kein KO-Punkt und besteht möglicherweise auch heute nicht mehr. Aber es ist eben ein Punkt auf der Liste, den man berücksichtigen sollte. Gruß, Nils

Moin, sehr gern, danke für die Rückmeldung! Schöne Grüße, Nils

Moin, wie die Kollegen schon sagen: Der Fehler ist, einen DC direkt ans Internet anzubinden. Das tut man nicht. Active Directory ist ein rein interner Dienst. Irgendwie haben wir aber vor etwa zwei Wochen ziemlich genau diese Diskussion hier schon mal geführt - besteht da ein Zusammenhang, oder ist das Zufall? Gruß, Nils

Moin, warum genau und auf welcher Grundlage und anhand welcher Informationen willst du deinen DC als "nicht mehr offen" konfigurieren? Deine Frage betrifft einen der notwendigen Ports, auf denen das AD beruht. Mir scheinen dort Missverständnisse vorzuliegen. Windows ist ja nun beim besten Willen nicht "offen", sodass man da zwingend irgendwas machen müsste, schon gar nicht im internen Netz. Gruß, Nils

Moin, dich meinte ich auch nicht. ;) Gruß, Nils

Moin, was soll man da so pauschal zu sagen? Ich verweise auf den Konjunktiv III: "Sollte gehen". Gruß, Nils

Moin, äh, Moment - meine Aussage war nicht "Windows-Dateiserver sind in jedem Fall besser". Bitte noch mal richtig lesen. :) Ich könnte auch einfach auf meine Signatur verweisen. Gruß, Nils

Moin, ein Core ohne Domänenmitgliedschaft ist eine harte Nuss. Ich würde daher zum 5Nine Manager raten, der bietet ein GUI auch auf einem Core-Host. Die kostenpflichtige Variante dürfte erheblich günstiger sein, als noch lange rumzuprobieren. Gruß, Nils

Moin, du hast den DC gerade erst hochgestuft? Dann würde ich erst mal eine Stunde oder so warten. Möglicherweise ist das ein vorübergehender Fehler. Sonst ist ja alles grün. Zu den FSMO-Rollen: Wenn ich nicht ganz falsch liege, darfst du die erst direkt vor dem Entfernen des SBS übertragen. Gruß, Nils

Moin, in der Vergangenheit hat es beispielsweise immer wieder Dinge gegeben, die auch eine NetApp (deren SMB-Implementierung nach meiner Kenntnis zu den besten am Markt gehört) erst einige Zeit später konnte als Windows selbst. Dann gibt es ja aber auch nicht nur NetApp da draußen - viele SMB-Aufsätze in Storage-Geräten basieren auf teils alten Samba-Versionen. Und die SMB-3-Implementierung ist meines Wissens auch bei NetApp nicht da, wo sie bei Windows ist. Schließlich ist dann da noch die Domänen-Einbindung, ein Storage lässt sich etwa weder über GPOs noch über DSC konfigurieren, die Berechtigungen sind im Detail anders usw. Ob das im konkreten Fall eine relevante Einschränkung für den Kunden ist, muss man anhand der Anforderungen bewerten. Ich warne nur davor, pauschal die SMB-Funktionen von Storage-Systemen als vollwertigen oder gar besseren Ersatz für Windows-Dateiserver anzusehen. Gruß, Nils

Moin, es gibt in Windows 10 keinen XP-Mode. Den gab es ausschließlich in Windows 7. Selbst da hätte er nach meiner Einschätzung des Szenarios nicht geholfen, weil er für ganz andere Zwecke da war. Da es hier vermutlich um Maschinensteuerung geht, wird auch Virtualisierung allgemein wahrscheinlich keine Lösung sein bzw. sogar nicht funktionieren (Hardware-Schnittstellen). Der Punkt ist, dass die XP-Rechner eng abgeschottet sein müssen, ob virtuell oder physisch macht da wenig Unterschied. Gruß, Nils

Moin, du meinst den, den es zuletzt in Windows 7 gab? ;) Virtualisierung würde das Problem auch nicht lösen, selbst wenn es ginge. Gruß, Nils

Moin, hm ... wenn du einen Sync machst, brauchst du aber eigentlich keinen Trust. Ganz im Gegenteil könnte der in dem Zusammenhang eher problematisch sein für den Betrieb. Gruß, Nils

Moin, der Schalter hat mit einer "Synchronisierung" nichts zu tun. Bei einem Trust wird nichts synchronisiert. Es ist ja ein Trust, keine Replikation. Ansonsten, wie gesagt: Da der Aufbau selten ist, kann ich nichts Konkretes dazu beitragen. Gruß, Nils

Moin, OK, für ein Azubiprojekt vielleicht als Recherche machbar. Ansonsten würde ich jetzt mal zu Beratung raten. Man kann ein zentrales Storage durchaus auf Windows-Basis selbst bauen. Man muss sich dabei aber im Klaren sein, dass man dafür sehr viel Know-how braucht und hinterher alles selbst supporten muss. Zudem ist fraglich, ob man mit so einer Lösung günstiger liegt als mit einem fertigen kommerziellen System. Dabei spielt auch die Lizenzierung eine Rolle, denn die Storage-Server müssten mit der Datacenter Edition laufen. Storage Replica arbeitet auf Blockebene, es ist ihm "egal", was für Daten darauf liegen. Das können auch LUNs sein, wenn der Server als iSCSI-Target eingerichtet wird. Ob man so ein Storage über iSCSI anbinden will, ist dann auch noch eine Frage. Und man mache sich nichts vor: Zwischen den beiden Servern einer Replikation muss ein Hochgeschwindigkeitsnetzwerk arbeiten, typischerweise 10 GbE redundant oder mehr. Gruß, Nils

Moin, lass den Schalter mal weg. Wenn ich es richtig verstehe, dürfte der bei Kerberos-Realms überflüssig sein. Gruß, Nils

Moin, ähem. Die Info ist nicht ganz unwichtig, gell? In dem Artikel, den ich verlinkt habe, stehen dazu Beispiele. Spontan würde ich sagen, dass der Schalter /realm fehlt. Konkrete Erfahrungen habe ich mit so einem Aufbau nicht. Gruß, Nils

Moin, wie Daniel schon sagt: Storage Replica und S2D sind zwei unterschiedliche Features, die einander ausschließen. Um einen zentralen Speicher für eine VM-Umgebung bereitzustellen, brauchst du keins von beiden. Bitte beschreib doch mal, welcher Aufbau dir vorschwebt und was die Anforderungen an die Umgebung sind. Gruß, Nils

Moin, PasswordT ist zwar richtig, scheint aber nur für Nicht-Windows-Realms zu gelten. Ebenso wird für transitive (mit e) dieselbe Einschränkung angegeben. https://technet.microsoft.com/de-de/library/cc835085(v=ws.10).aspx Gruß, Nils

Moin, gerade wenn es solche Zwänge gibt, sollte man den Einsatz von XP aber einschränken - und nicht die Produktionsumgebung durch XP einschränken lassen. Sprich: Die XP-Clients haben in einer 2016-Domäne nichts zu suchen. Sie müssen in einer abgeschottete Insel-Umgebung. Gruß, Nils

Moin, abgesehen davon, sollte man immer prüfen, ob man sein Storage wirklich direkt als Dateiserver arbeiten lassen möchte. Prinzipiell können viele davon das zwar gut, aber im Detail gibt es immer wieder Einschränkungen, die es bei einem "echten" Windows-Dateiserver nicht gibt. Und nebenbei: SMB, nicht CIFS. ;) http://stealthpuppy.com/smb-not-cifs/ Gruß, NIls

Moin, jupp, das ist UAC. Den Explorer kann man allerdings nicht als Admin starten, jedenfalls nicht ohne heftige Klimmzüge. Daher rate ich entweder zu einem anderen Dateimanager oder (besser) zu einem anderen Konzept: Admin-Berechtigungen nicht für die vordefinierten Admingruppen vergeben, sondern für selbst erzeugte. Dann funkt UAC nämlich nicht dazwischen. [Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/ Gruß, Nils