Zum Inhalt wechseln


Foto

AD-Replikation zu langsam? SID not found


  • Bitte melde dich an um zu Antworten
24 Antworten in diesem Thema

#1 magheinz

magheinz

    Newbie

  • 1.426 Beiträge

 

Geschrieben 14. Februar 2017 - 16:49

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?



#2 BOfH_666

BOfH_666

    Junior Member

  • 147 Beiträge

 

Geschrieben 14. Februar 2017 - 18:40

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:


live long and prosper!

PS:> (79,108,97,102|%{[char]$_})-join''

#3 magheinz

magheinz

    Newbie

  • 1.426 Beiträge

 

Geschrieben 14. Februar 2017 - 19:41

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...



#4 BOfH_666

BOfH_666

    Junior Member

  • 147 Beiträge

 

Geschrieben 15. Februar 2017 - 01:18

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 von BOfH_666, 15. Februar 2017 - 01:18.

live long and prosper!

PS:> (79,108,97,102|%{[char]$_})-join''

#5 PowerShellAdmin

PowerShellAdmin

    Board Veteran

  • 1.136 Beiträge

 

Geschrieben 15. Februar 2017 - 06:04

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.

Möge die Macht der PS mit Dir sein.


#6 magheinz

magheinz

    Newbie

  • 1.426 Beiträge

 

Geschrieben 15. Februar 2017 - 13:01

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...



#7 zahni

zahni

    Expert Member

  • 16.500 Beiträge

 

Geschrieben 16. Februar 2017 - 11:54

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

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


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#8 magheinz

magheinz

    Newbie

  • 1.426 Beiträge

 

Geschrieben 16. Februar 2017 - 20:52

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

#9 NilsK

NilsK

    Expert Member

  • 12.463 Beiträge

 

Geschrieben 17. Februar 2017 - 06:58

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#10 magheinz

magheinz

    Newbie

  • 1.426 Beiträge

 

Geschrieben 17. Februar 2017 - 12:50

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.



#11 NilsK

NilsK

    Expert Member

  • 12.463 Beiträge

 

Geschrieben 17. Februar 2017 - 13:03

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#12 daabm

daabm

    Expert Member

  • 2.111 Beiträge

 

Geschrieben 17. Februar 2017 - 22:33

...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.


Greetings/Grüße, Martin

Mal ein gutes Buch über GPOs lesen? Oder ein kleines, aber feines Blog darüber?

Und wenn mir die IT mal auf die Nerven geht - coke bottle design refreshment (-:


#13 magheinz

magheinz

    Newbie

  • 1.426 Beiträge

 

Geschrieben 18. Februar 2017 - 10:19

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

#14 BOfH_666

BOfH_666

    Junior Member

  • 147 Beiträge

 

Geschrieben 18. Februar 2017 - 13:29

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?


live long and prosper!

PS:> (79,108,97,102|%{[char]$_})-join''

#15 magheinz

magheinz

    Newbie

  • 1.426 Beiträge

 

Geschrieben 18. Februar 2017 - 14:01

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"?