NilsK

Moin, ich verstehe die Frage nicht. Warum würde man einen DC im Internet veröffentlichen wollen? Mir fällt dazu kein einziges valides Szenario ein. Gruß, Nils

Moin, kann gut sein, dass das auch mit 2010 schon ging. Aber selbst wenn nicht, ist das mit String-Funktionen (FINDEN, LINKS und TEIL) auch recht leicht erledigt. Gruß, Nils

Moin, ich möchte nur noch mal eben einwerfen, dass man zumindest prüfen sollte, ob man eine CA bei der Gelegenheit nicht lieber ordentlich konzipieren und installieren will. Bei solchen "Mal-eben"-Sachen kommt sonst schnell etwas heraus, was mit Sicherheit und Zuverlässigkeit nicht viel zu tun hat. Gruß, NIls

Moin, wie wahrscheinlich ist es denn, dass du ein Zertifikat sperren willst? Wenn du nur für Exchange welche ausgestellt hast, würdest du das Zertifikat im Fall eines Falles nicht sperren, sondern ein neues von deiner neuen CA einsetzen. Das wäre in deinem Szenario ja ohnehin der Weg: Sobald die neue CA (die du ordentlich und koordiniert aufgesetzt hast) da ist, stellst du neue Zertifikate für dein Exchange und alle sonstigen Komponenten von dieser neuen CA aus. Dann kann der ganze alte Kram einfach weg. Eine Migration wäre eigentlich nur dann von Interesse, wenn du in großem Stil Zertifikate zur Verschlüsselung ruhender Daten ausgestellt hättest oder sowas. Gruß, Nils

Moin, das sollte mit simplen String-Funktionen möglich sein. VERKETTEN, wie schon empfohlen, wäre ein Weg, man kann aber auch mit einfachen &-Verknüpfungen arbeiten. Excel 2013 und 2016 sollten die Ausgangswerte direkt in zwei Spalten VORNAME und NACHNAME aufteilen können, dafür gibt es im Ribbon eine fertige Funktion. Auf der Basis baust du dann deine neue Spalte. DIe Abteilung musst du natürlich irgendwoher bekommen. Gruß, Nils

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