AD-Replikation zu langsam? SID not found

[magheinz 111]

Hallo,

 

eventuell gibts ja einen Trick.

Wir haben 3 Domaincontroller.

Lege ich mit New-ADGroup eine neue Gruppe an und möchte diese dann direkt mit Add-ADGroupmember bearbeiten schaffe ich das wenn ich per Parameter (-Server) sicherstelle das beide Befehle auf den gleichen Domaincontroller gehen.

Wenn ich jetzt aber ein Commandlet habe welches den Server-Parameter nicht kennt, z.B. von einem Drittanbieter, wie stelle ich dann sicher das ich in keinen Fehler laufe?

[BOfH_666 586]

Du könntest per Invoke-Command sicherstellen, dass all cmdlets auf dem Server ausgeführt werden, den Du möchtest. Oder Du bittest den Drittanbieter die Standardfunktion nachzuliefern.   ;)  :thumb1:  :cool:

[magheinz 111]

Ist das wirklich eine Standardfunktion?

es geht um so commandelt wie Set-ACL. Also commandlets die auf AD-Objekte zugreifen aber nicht direkt die AD manipulieren.

Wenn ich jetzt folgendes mache, achtung Pseudocode, keine korrekte syntax:

1. new-adgroup -server dc01 -identity gruppe

2. add-addgroupmember -server dc01 -identiy gruppe -members foo

3. Set-ACL gruppe folder permission

Dann findet Set-ACL die Gruppe nicht. Packe ich ein Sleep 120 davor funktioniert es.

Das kann aber doch nicht die Lösung sein...

[BOfH_666 586]

Ist das wirklich eine Standardfunktion?

 

.... hmmm ... jein ...  aber wenn ich schon eine Funktion oder ein Tool anbiete, die/das für die AD-Administration gedacht ist, sollte ich wenigstens die Möglichkeit vorsehen, es auch auf einen spezifischen Domain-Controller zu schicken.  .... denke ich.   ;)

 

es geht um so commandelt wie Set-ACL. Also commandlets die auf AD-Objekte zugreifen aber nicht direkt die AD manipulieren.

 

Naja, Set-ACL ist ja nicht explizit für's AD gemacht - es kann eben auch dafür genutzt werden, weil im AD auch ACLs gibt, die man manipulieren kann.

 

 

Wenn ich jetzt folgendes mache, achtung Pseudocode, keine korrekte syntax:

1. new-adgroup -server dc01 -identity gruppe

2. add-addgroupmember -server dc01 -identiy gruppe -members foo

3. Set-ACL gruppe folder permission

Dann findet Set-ACL die Gruppe nicht. Packe ich ein Sleep 120 davor funktioniert es.

Das kann aber doch nicht die Lösung sein...

 

Dann könntest Du eben den letzten Befehl so umstellen:

Invoke-Command -ComputerName dc01 -ScriptBlock {Set-ACL gruppe folder permission}

...  Packe ich ein Sleep 120 davor funktioniert es.

Das kann aber doch nicht die Lösung sein...

 

Manchmal ist es aber eben doch einfacher, mit dem "Status Quo" zu leben. Ist es wirklich so dringend, dass es nicht 2 Minuten warten kann? Du musst ja nicht zwingend vorm Monitor darauf warten, dass die 2 Minuten vergehen - das Script läuft auch ohne Deine "Aufsicht" bis zum Schluss durch, denke ich.   :D  ;)  :cool:  :thumb1:  :wink2:

bearbeitet 15. Februar 2017 von BOfH_666

[PowerShellAdmin 169]

Im Regelfall müssen solche Abläufe nicht in 2Sek abgegolten sein.

Du könntest auch ein Try Catch Konstrukt aufbauen und so nur bei Bedarf 2Min warten.

 

Sehe hier auch nicht das Problem.

[magheinz 111]

Problem würde ich es auch nicht nennen. Ich hab einfach nur das best-practise gesucht.

Ich werde ein try-catch drumherumbauen und gut ist.

An sich sind die 2 Minuten auch kein Problem. Das script läuft über den Aufgabenplaner...

[zahni 587]

Ich würde einfach bei den anderen Befehlen auch  den Server-Parameter  weglassen.

Der Client  sucht sich nicht ständig  einen neuen DC.

[magheinz 111]

der sucht aber oft schneller als die Replikation ist. direkt hintereinander new-adgroup umd add-adgroupmember bringt oft SID not found.

ich packs im eine schleife mit try and catch bis es klappt.nicht

 

 

[NilsK 3.046]

Moin,

 

da wir gerade dieselbe Situation haben, haben wir es so gelöst:

While ((!(Get-ADGroup -Filter "name -eq '$GroupRead'")) -or (!(Get-ADGroup -Filter "name -eq '$GroupModify'"))){
   Start-Sleep -s 1
}

Gruß, Nils

[magheinz 111]

So hab ich das auch gemacht und das ganze in eine Funktion WaitForGroup() gepackt.

Ich bin aber schon mal froh das ich nicht der einzige bin der darüber gestolpert ist.

[NilsK 3.046]

Moin,

 

nein, das Problem hat man in solchen Fällen oft. Das erste Mal bin ich vor über fünfzehn Jahren darüber gestolpert. Lästig dabei ist, dass man es in Testumgebungen mit nur einem DC meist nicht bemerkt, sondern erst, wenn es mehrere DCs gibt.

 

Gruß, Nils

[daabm 1.431]

...und manchmal erst dann, wenn man tatsächlich einen DC "vor Ort" hat :) Ja, da hilft nur "explizit mit dem PDC reden", dafür ist der dann immer noch gut.

[magheinz 111]

das explizit reden ist ja das problem.. das kann nicht jedes commandlet.

[BOfH_666 586]

Stimmt. Aber genau für solche Fälle bietet sich ja das "Verpacken" des eigentlichen Befehls in ein "Invoke-Command" an. Dem kannst Du explizit mitgeben, auf welchem Rechner/Server es ausgeführt werden soll. Hattest Du das schon mal probiert?

[magheinz 111]

Stimmt. Aber genau für solche Fälle bietet sich ja das "Verpacken" des eigentlichen Befehls in ein "Invoke-Command" an. Dem kannst Du explizit mitgeben, auf welchem Rechner/Server es ausgeführt werden soll. Hattest Du das schon mal probiert?

Nein, dafür noch nicht.

greift get-.adgroup wenn es auf einem DC läuft immer auf diesen zu?

Durch deinen Vorschlag sorge ich ja nur dafür "wo das script läuft"tttt. Ist das gleichbedeutend mit "wen das script fragt"?