cj_berlin

Moin, von allem anderen abgesehen, lass Exchange einfach Exchange sein, bau eine DAG über beide Standorte, bilde sie ordentlich im AD ab und stelle in jedem mindestens einen Domain Controller bereit. Für alles andere kannst Du Hyper-V Replica einsetzen, sofern für die jeweiligen Workloads supported.

Moin, das mit dem Domain Join des VPN-Konzentrators bzw. des RADIUS-Servers kann helfen, LDAP mit S nicht betreiben zu müssen, denn wenn Kerberos bereits zwischen Client (VPN-Konzentrator) und Server (Domain Controller) verwendet wird, kann auf LDAPS verzichtet werden. Aber nur, wenn es ordentlich gemacht wurde

Was auch gerne genommen wird, sind GPOs, welche das Skript nicht ausführen, sondern als geplanten Task hinterlegen. Das kannst Du auch nochmal checken.

Ja.

Wo sind die Skripte hinterlegt? Group Policy? Dann sind sie vielleicht in zwei, drei GPOs hinterlegt, die da gelten - GPRESULT ist Dein Freund.

Upgrade von 2016 auf 2019 ist doch "Version", nicht "Edition"

Wenn Du auf dem Admin-Account andere Berechtigung hast als auf dem AdminSDHolder, dann funktioniert entweder der SDHolder-Prozess nicht, oder auf dem AdminSDHolder ist die Vererbung aktiviert (auch darüber müsste Dir PurlpleKnight berichtet haben). Der Normalzustand der Admin-User ist "Vererbung deaktiviert, ACL identisch mit AdminSDHolder". Und auf dem AdminSDHolder kannst Du den Exchange Servern alle Rechte entziehen, die Du willst, im Prinzip sogar alle, wenn Du nicht vorhast, Admin-Accounts Postfächer zu verpassen.

Wenn Du in allen Sites DCs hast und die Topologie nun stimmt, ist sie nicht erforderlich. Ansonsten, Enabling Clients to Locate the Next Closest Domain Controller | Microsoft Learn

Moin, unabhängig von PurpleKnight: Solche Anpassungen, und zwar lieber ein entferntes "allow" als ein hinzugefügtes "deny", musst Du für hochprivilegierte Benutzer und Gruppen nicht am Objekt selbst, sondern am AdminSDHolder-Container vornehmen, denn sonst werden sie nach einer Stunde (default) wieder überschrieben. So wie Du es schlderst, prüft PurpleKnight hier scheinbar nicht genau genug, aber ich lasse es jetzt checken. Nichtsdestotrotz, alles, was sich zu den Default-Admin- und Operator-Gruppen zurückverfolgen lässt, bekommt die Berechtigungen vom AdminSDHolder normalerweise drübergebügelt.

Hatte noch keine Zeit gefunden reinzugucken, aber ich habe die Frage dort platziert, wo sie hingehört. Wenn ich was höre, poste ich es hier.

Moin, das würde ich machen. Eine Topologie, die automatisch die korrekten Verbindungen erzeugt, ist immer schöner, als manuell nachhelfen zu müssen. Zumal bei Dir ja keine extremen Sonderlocken vorhanden sind. Du wirst allerdings nur eine Verbindung automatisch angelegt bekommen, und das ist auch gut so.

Moin, was zeigt Dir der "Effektive Zugriff"? PK kann sich auch ab und zu irren (full disclosure: Ich arbeite bei Semperis)

Pro Forest Und wenn man keine Trusts hat, kann man den UPN auch so reindübeln, ohne den Suffix hinzuzufügen - wird auch funktionieren. Azure AD Connect mag's aber nicht so gerne.

Genauso machst Du das.

Moin, möglich ist vieles, Stichwort "Shadow Copy". Aber warum? Wenn Deine Arbeitshypothese ist, dass Dein NAS das Disaster übersteht, solltest Du prüfen, was Du am Backup-Server ändern musst, damit diese Annahme auch für diesen gilt. Ein Hyper-V-Server muss in beiden Fällen vorhanden sein, das ist also schon mal nicht der Unterscheidungsfaktor. Ich kenne das Backup-Produkt nicht, aber so schwierig wird es schon nicht sein, das neu zu installieren. Und wenn es doch zu schwierig ist, die Infrastruktur für Disaster Recovery im Disaster-Fall bereitzustellen, solltest Du eher ein anderes Backup-Produkt prüfen als Bastellösungen, die Dich am Ende mit Crash-konsistenten Backups da stehen lassen.

Wenn die Standorte nur Verbindungen zur Zentrale haben, aber nicht untereinander, musst Du wie folgt vorgehen: Unter "Inter-Site-Transports - IP" für jeden Standort einen Site Link hinzufügen, der nur den jeweiligen Standort und die Zentrale beinhaltet. Tu Dir selbst einen Gefallen und setze das "options" Attribut jedes dieser Links auf 1 (USE_NOTIFY) Wenn das fertig ist, den DEFAULTIPSITELINK löschen Wenn die Zentrale zwischen den Standorten routet, bist Du fertig Wenn die Zentrale nicht routet, klicke mit der rechten Maustaste auf den Container "IP" (wo die Site Links drin sind) und nimm den Haken raus bei "All links are bridged" Das hast Du hoffentlich in der Zentrale gemacht. Öffne die Administrator-CMD auf dem DC, gegen den Du verbunden warst, und sage repadmin /syncall /AdeP (Groß- und Kleinschreibung ist wichtig)

Moin, der letzte Punkt in der Fehlerbeschreibung lässt an Replikationsprobleme in Deinem AD denken... Ich würde damit beginnen, die Sites & Subnets zu überprüfen, sicherstellen, dass alles der Physik entspricht und die Replikation - AD *und* DFS-R - fehlerfrei funktioniert. Parallel würde ich, auch wenn's mit Deinem Problem nicht ursächlich zu tun hat, hinterfragen, ob ich für Geräte mit dynamischen IP-Adressen *wirklich* die rückwärtige DNS-Auflösung brauche.

Moin, ja, Du kannst, aber, wie Norbert schon schrieb, die Frage wird halt sein, ob Du solltest. Ich würde prüfen lassen, mit welchem Aufwand sich eine zweite CPU nachrüsten ließe. Quorum ist meistens nicht das Problem, da Windows Cluster eh auf Shared Resources angewiesen sind. Und ein 3-Knoten-Cluster braucht auch ein Quorum - für den Tag, an dem er durch Wartung oder Fehler vorübergehend zu einem 2-Knoten-Cluster wird.

Ich sage mal so: WINS ist bereits in einer Version deprecated worden, die heute gar nicht mehr unter Support ist EDIT: Und ich habe nur noch 15 Jahre bis zur Rente, nach dem heutigen Stand der Gesetzgebung.

Moin, warum packst Du das Skript nicht in die GPO als PowerShell-Startup-Skript? Dann musst Du dich weder um UNC noch um Bypass kümmern.

AUDLP wäre aber genauso smooth zu migrieren. Das mit Token Size hängt davon ab, wieviele Ordner und Anwendungen auf der untersten RBAC-Ebene berechtigt sind und ob es gleichzeitig immer noch Applikationen gibt, wo 12K hartkodiert sind. Aber ja, die Anzahl Slots ist signifikanter - da habe ich die eine oder andere Ressourcen-Auslagerung hinter mir, weil an der Struktur nicht zu rütteln war

Moin, erlaubt mir bitte kurz akademisch zu werden und zwei Dinge gerade zu rücken. Wenn ich den MigRaven-Artikel noch richtig im Kopf habe, hat "G" dort eine andere Bedeutung als in "AGDLP" und steht einfach nur für "Gruppe", den Scope soll der geneigte Implementierer jeweils selbst ausrechnen. Und das ist auch gut so, denn: in einem einzelnen Forest mit nur einer Domain (und davon würde ich in dem vorliegenden Fall mal ausgehen wollen, obwohl es tatsächlich im OP nicht drin steht) haben globale Gruppen als Berechtigungsgruppen NULL Nachteile gegenüber den DL-Gruppen. Gleicher Anteil an Token Size, gleiche Member sind möglich, gleiche Berechtigungen sind möglich. Tatsächlich ist es in einem einzelnen Forest mit nur einer Domain vollkommen wurscht, welcher Gruppen-Scope genommen wird. Und bei 2008R2 und früher hatten die DL-Gruppen sogar einen HÖHEREN Beitrag zur Token-Größe als globale Gruppen! in einem einzelnen Forest mit mehreren Domains (und ich meine nicht die Abscheulichkeit "leere Root-Domain + eine einzige signifikante Child-Domain") ist DL als Permission-Gruppe zwar zu bevorzugen, weil die nicht in allen Tokens enthalten sein wird, aber in Bezug auf Rollengruppen kann AUDLP eine echte Alternative sein. Früher hatten wir immer Angst, ein Objekt mehr in den globalen Katalog zu drücken, aber die Zeiten sind vorbei, und gerade die Rollengruppen können im GC durchaus nützlich sein. So viele werden's normalerweise nicht werden. so richtig passend ist AGDLP also nur in einem Szenario, wo zugreifende User in mehreren Forests vorhanden sind, diese Forests aber alle aus jeweils einer Domain bestehen. Und, obwohl das tatsächlich ein besseres Design ist als die gleiche Anzahl Domains in einem Forest verklebt, ist es eher nicht der Standardfall, zumindest in meiner Erfahrung.

Moin, -contains funktioniert nicht bei Strings, aber von der Logik her kann das so gehen, mit -like, -match oder .StartsWith(). Wenn man die letzte Zeile (mit "ORC") mit ausgegeben haben möchte, müssen die zweite und die dritte Bedingung vertauscht werden.

Ich bin da bei @NilsK - die Chance is groß, dass viele dieser Gruppen identische Mitgliedschaften aufweisen werden Macht eine Tabelle, wer worauf Zugriff braucht, und vielleicht kommen am Ende nur drei Hauptordnet raus.

So isses. Es sei denn, man ist das Militär und somit genau die Zielgruppe, die das bestellt hat.