daabm

Ob Du den TO mit *SACLs* nicht überforderst? SCNR...

Dann ist das wohl ein Problem der Anwendung, da wirst Du mit Windows-Bordmitteln nicht viel erreichen können.

FR kannst ignorieren - ich könnte erklären warum, aber das ist mehr als eine Zeile Text Du hast ein Problem mit den FSMO-Rollen.

Dann mach das mal. Unsere Universal-GPO mit w32tm-Config für Member, DC und PDCe hat das inzwischen für alle 3 Varianten komplett (also alle Regwerte). Hatte das am Anfang nämlich auch vergessen, daher waren mir Ursache und Lösung quasi sofort präsent

Klar kann ich das - gelegentlich... Du aber auch. Die Motivation war aber nicht, diejenigen zu erreichen, die System.DirectoryServices nutzen. Sondern die, die mit den "gängigen" Standardvorgehen bei Powershell über Dinge iterieren. Und dabei zu weit rechts filtern 😂 Diesen Mal nur nicht so offensichtlich.

Stimmen die AnnounceFlags? 5 darf nur der PDCe haben, alle anderen haben 10. Wenn andere DCs auch 5 haben, halten sie sich für "always reliable" und ignorieren NT5DS... Edit: Warum ich das vermute? Weil Du schreibst, daß einer alle FSMO-Rollen außer PDCe hat - also hat da mal wer den PDCe verschoben...

Was sieht denn wie genau aus? Ein Screenshot wäre sicher hilfreich. Und welche "GPO" hast Du erzeugt und konfiguriert?

Dasissnargument Um 5 aufstehen und dann bis 10 nix zu sich nehmen klingt nach "lästig"...

Der letzten Antwort von @NilsK habe ich nichts hinzuzufügen. Wenn sichergestellt ist, daß T2 keinen Schreibzugriff auf Sysvol/Netlogon hat, ist ein Virenscanner auf einem DC eher obsolet. Gibt es keine Trennung, wird's schwierig... Und wegen "Defender aufsichtsrechtlich ausreichend" - ja.

Scope beim Suchen auf der Domäne? Da sollte dann der lokale Member Computer ausgewählt werden Oder wie @testperson schreibt.

Ja dann nimm's halt rein, was hindert Dich daran? Schwierig wird das immer nur dann, wenn irgendwer nen Dienst unter NT SERVICE\xyz laufen lassen will. Der wäre in ALL SERVICES, aber wenn die das Recht nicht haben, startet dann der Dienst nicht. Spolier: ESU und himds

Kurzer Nachtrag dazu: Wenn der LDAP-Filter zu groß wird, geht das in die Hose. Nach ein paar Tests mit sAMAccountName - sind es mehr als ~40k Einträge (der Filter ist dann etwa 1 MB groß), verweigert der Server die Antwort. Belastbare Informationen über entsprechende Limits habe ich aber keine gefunden... Wenn jemand was dazu hat, gerne her damit $LDAPFilter = "(|" + ( ( 1..50000 | Foreach { "(sAMAccountName=User$_)" } ) -join '' ) + ")" $LDAPFilter.Length ( Measure-Command { $ADobjects = Get-ADObject -LDAPFilter $LDAPFilter } ).TotalSeconds Ergebnis: 1158897 Get-ADObject : Es kann keine Verbindung mit dem Server hergestellt werden. Dies liegt möglicherweise daran, dass der Server nicht vorhanden oder derzeit ausgefallen ist oder dass darauf nicht Active Directory-Webdienste ausgeführt wird. In Zeile:3 Zeichen:34 + ... e-Command { $ADobjects = Get-ADObject -LDAPFilter $LDAPFilter } ).Tot ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (:) [Get-ADObject], ADServerDownException + FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADObject 0,319832

...aber reiß dabei nicht dem, der sie dir entgegenstreckt, den Arm aus. SCNR

Das hängt ganz sicher (hust...) nicht zusammen.

Bitte nicht zu viel durcheinander werfen NTLM bekommst Du in den Griff, wenn Du auf den DCs das NLTM Auditing einschaltest. Dann kannst Du im Eventlog NTLM/Operational nachschauen, von wo das kommt. Und damit kannst Du dann analysieren, warum Kerberos nicht funktioniert. Dazu wiederum ist es hilfreich, auf den DCs das Advanced Auditing für Kerberos-Events zu aktivieren und die dann auf Audit Failure Events zu prüfen. Das Event mit der Server-Referenz habe ich noch nie gesehen... Da bin ich also erst mal raus und stille.

Danke für die Rückmeldung. Kommt bei uns quasi quartalsweise vor (>1000 Domains....), Ursache unbekannt. Aber man gewöhnt sich dran, und es ist schnell und einfach zu beheben.

Ganz viel skripten. Also alles eigentlich. Und alles, was mehr als ein Objekt bearbeitet, auf Performance optimieren...

1. Wieso abtippen? 2. Das Kennwort, das DC04 in seiner AD-Datenbank für DC03 hat, ist nicht identisch mit dem, das DC03 hat (AD-Replikation in Ordnung?). Oder das krbtgt-Kennwort ist "out of sync". Erster Lösungsansatz: Dienst KDC auf allen DCs außer dem PDC-Emulator deaktivieren und stoppen (!!!), dann alle DCs neu starten außer dem PDC. Dann 10 Minuten warten und KDC auf allen DCs wieder aktivieren und starten. Zweiter Ansatz: DC03 SecureChannel zurücksetzen. Dritter Ansatz: DC03 neu aufbauen.

Ja, das ist supported. AD ist bei DNS völlig agnostisch, nur muß jeder Computer in der Lage sein, die erforderlichen Einträge zu registrieren (oder ein irgendwie gearteter Automat übernimmt das).

Hallo zusammen. Keine Frage, nur ein Tip, wenn's mal schneller gehen soll Wenn man in Active Directory User/Gruppen/Mitgliedschaften auslesen oder bearbeiten will, findet man oft Schleifen, die über Mitglieder oder Mitgliedschaften iterieren und mit den Ergebnissen dann wieder etwas machen. Das läßt sich dramatisch beschleunigen, indem man nicht iteriert, sondern vorher einen passenden LDAP-Filter baut. Und LDAP-Filter dürfen lang sein - sehr lang. Ich hatte das Thema kürzlich, als es um Account-Dubletten im Rahmen von Domänen-Migrationen ging. Das "übliche" Vorgehen wäre wohl, auf der einen Seite alle Accounts zu holen und dann für jeden Account zu prüfen, ob es den auch auf der anderen Seite gibt. Holt man die Accounts der anderen Seite dagegen über einen LDAP-Filter auf die Accounts, die man auf der ersten Seite schon gefunden hat (nur die können ja doppelt vorhanden sein), wird das dramatisch schneller... Getestet mit bis zu 2.000 sAMAccountName im LDAP-Filter, geht problemlos. Die einzige Herausforderung dabei ist, den Input (also das Member- oder MemberOf-Array) passend zu zerlegen. Ich habe mich für die einfachste Variante entschieden, und ich setze auch voraus, daß der CN eindeutig ist. Aber egal wie aufwändig das Konstruieren des LDAP-Filter wird - es wird immer um Größenordnungen schneller gehen als die Objekte einzeln zu holen. Sample Code - $GroupName muss natürlich angepasst werden, wenn das jemand ausprobieren will: $GroupName = 'LDAPFilterGroup' $Group = Get-ADGroup $GroupName -Properties Member $NumRepetitions = 5 $ScriptBlocks = @( { $Members = @() Foreach ( $Member in $Group.member ) { $Members += Get-ADObject $Member } }, { $Members = [Collections.Arraylist]::new() Foreach ( $Member in $Group.member ) { [void] $Members.Add( ( Get-ADObject $Member ) ) } }, { $GroupMembers = $Group.Member | Foreach { ( $_ -Split ',(OU|CN)=' -Replace '^CN=', '' )[0] } $LdapFilter = '(|(sAMAccountName=' + ( $GroupMembers -join ')(sAMAccountName=' ) + '))' $Members = Get-ADObject -LDAPFilter $LdapFilter } ) Foreach ( $ScriptBlock in $ScriptBlocks ) { $Durations = For ( $i=1; $i -le $NumRepetitions; $i++ ) { Measure-Command -Expression $ScriptBlock } $Durations | Measure-Object TotalSeconds -Average | Select-Object Average } Ergebnis in einer Spielumgebung für eine Gruppe mit 1.000 Mitgliedern in Sekunden: Foreach mit @(): 6,5145044 Foreach mit ArrayList: 5,96655574 LDAP-Filter: 0,75933482 Muß man glaub nix mehr dazu sagen... [Collections.Arraylist] spart schon bei nur 1.000 Accounts eine halbe Sekunde, aber Variante 3 mit dem "extrem langen LDAP-Filter" ist um den Faktor 10 schneller (der Filter hat knapp 24 kB). Und das wird immer schlimmer für die anderen beiden Methoden, wenn es mehr Mitglieder sind und die Netzwerkverbindung langsamer. Edit: Warum ich auf so was achte? Weil manche unserer Domains 150.000 User, 30.000 OUs und 10.000 GPOs haben. Die Anzahl der Gruppen weiß ich nicht, aber auch irgendwo im 6-stelligen Bereich. Da ist Geschwindigkeit alles...

Ernsthaft? Dann stimmt was im Preisgefüge "Produktion vs. Transport" aber gar nicht mehr...

"Geh mit mir Shoppen"?

Schwafelt blödes Zeug und gibt nichtssagende Antworten. BTT: Ich bin bei @cj_berlin - ein Nicht-Admin hat in diesem Menü nichts, womit er irgendwas anstellen kann, das irgendwelche Auswirkungen auf andere User oder den Computer hat. Also wozu? Aber wenn's Dich glücklich macht - erstell den relevanten AppData-Ordner per GPP Preferences und mach ihn Readonly/Hidden, dann sind alle Einträge weg bis auf Desktop. Behaupten manche - ich probier das nicht aus, weil ich ja das "wofür" nicht nachvollziehen kann

Im Zweifel hilft regedit - HKLM\System\CurrentControlSet\Services. Da kann sich kein Service wehren, wenn Du Dinge änderst

Vergiß den Assistenten. Freigaben und NTFS-ACLs macht man nicht über Assistenten.