cj_berlin

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.

Moin wieso Daten preisgeben? Du installierst das System, das höhere Grafik- oder Sicherheitsanforderungen hat, auf dem Blech, und virtualisierst das jeweils andere darauf. Dann kannst Du sogar beide gleichzeitig nutzen.

Moin, die drei Komponenten, die man checken muss, sind 1. Ist ein Lizenzserver und der richtige Lizenztyp (User oder Device) im Terminalserver eingestellt? 2. Sind freie Lizenzen diesen Typs auf diesem Server vorhanden? 3. Alles andere (Konnektivität, Rechte im AD usw.)

Snapshots haben in Produktion nichts verloren, die würde ich auf gar keinen Fall zu Vorteilen zählen Wenn ich 10 Euro für jede VM kriegen würde, die durch Snapshots den Datastore vollgeschrieben hat, könnte ich ein sehr langes Sabbatical machen. HA braucht Shared Storage, und da ist man bei der nächsten Ebene von Single Point of Failure. Wenn hochverfügbares Storage nicht ohenhin ein Teil des Gesamtkonzeptes ist, brauchst Du HA keine Träne nachzuweinen. Der Preis für vMotion ist der Betrieb von vCenter. (Für HA wird es zwar auch benötigt, aber nur zum Konfigurieren, funktionieren tut's dann auch ohne). Könnte ein Overkill sein, wenn keiner an Bord ist, der sich dafür zuständig fühlt.

Finde mal zu Hause ein elektronisches Gerät, mit dem Du super zufrieden bist, und schau Dir die Amazon-Reviews dazu an. Es gibt immer *auch* Probleme und 1-Sterne-Bewertungen. Wenn die Switche nicht "zu intelligent" sind und versuchen, Spoofing bereits anhand des ersten Frames zu erkennen, funktioniert SET gut. In meiner Erfahrung gibt es drei Klassen von Fällen, wo man Probleme mit dem switch-independent Teaming hat, egal ob SET oder LBFO: 1. man hat vergessen, den LACP-Trunk aufzulösen 2. man hat nicht begriffen, dass switch-independent Teaming die Bandbreite nicht aggregiert, sondern verteilt. Es funktioniert also alles wie beschrieben, aber nicht wie erwartet 3. man baut kruden sc***, der so nicht vorgesehen ist, wie 1GB/s mit 10GB/s Karten teamen oder MAC-Adressen auf der Hardware-Ebene manipulieren

Das sollte funktionieren. Ich habe es in der Regel mit einem Context Switch machen dürfen, weil man dann doch Security-by-Obscurity-mäßig Skype for Business-Clients an EWS lassen wollte, aber mit einem SubVS funktioniert es auch.

Moin, was steht denn im Attribut in Rohform, ohne Umwandlung in datetime? Wenn da sowas wie 9223372036854775807 steht, ist es "nie" und übersteigt den höchsten validen Wert für Filetime. Versuch mal den Ablauf auf 43 zu setzen, oder bei einem betroffenen User "Password never expires" zu setzen und dann zu entfernen und schau, ob der berechnete Wert sich ändert.

Damit ist doch das Problem gelöst, oder?

Moin, was ich mich die ganze Zeit frage: hast Du denn wirklich ein Problem? Die Verbindungen zu Namespace-Servern haben doch erst einmal mit Referrals auf Ordner-Ziele nichts zu tun. Wenn letztere auf B ausgeschaltet sind, Zugriffe aber trotzdem stattfinden, finden sie über den Servernamen statt und nicht über DFS-N. Falls doch, hat das jemand gecached und nicht aktualisiert, da wäre der Blick auf den jeweiligen Client vermutlich zielführend. Was das Thema kaputtes DFS-R angeht, müsstest Du das Verhalten noch einmal im Detail erläutern, Mit "an die Wand fahren" kenne ich mich nicht aus.

Moin, eure Tests lügen nicht. Es hat schon seinen Grund, dass das standardmäßige Load Balancing-Verfahren sowohl in SET als auch in LBFO "switch-independent" heißt. Stacking ist dafür nicht erforderlich.

Authentifizierungseinstellungen auf dem Autodiscover-vDir. Oder doch Proxy.

Das ist doch das einzige, was interessant ist. Ich würde vermuten, sofern mehr als ein DC im Spiel ist, dass DFS-Replikation gestört ist und der DC, von dem die Server ihre GPOs ziehen, noch die alte Fassung hat,