none
Microsoft ActiveDirectory PowerShell-Modul (Microsoft RSAT-Download) ist nicht Thread-sicher - Abhilfe? RRS feed

  • Frage

  • Das PowerShell ActiveDirectory Modul scheint nicht Thread-sicher zu sein.

    Wir verwenden innerhalb eines Dienstes, der in .NET geschrieben ist, einen PowerShell Runspace (NuGet-Paket "System.Management.Automation.dll"), der ein PowerShell-Skript ausführt, das wiederum per Active Directory Web Services (ADWS) auf Active Directory zugreift und dort LDAP-Anfragen durchführt.

    Unser Dienst hat mehrere Threads, damit Abfragen parallel abgearbeitet werden können. Wenn nun zwei Threads einen Active Directory-Aufruf machen (wie zum Beispiel mit Hilfe des Get-ADUser Cmdlets), dann bricht Active Directory Web Services (ADWS) mit einer SOAP-Ausnahme "invalid enumeration context" ab.

    Haben wir vielleicht den Windows Domänen-Controller falsch konfiguriert? Oder ist das ein Fehler, der an Microsoft gemeldet werden kann? Wo würde ich diesen Fehler melden?

    Ich habe auf GitHub ein Repository mit einem Beispiel-Konsolenprogramm angelegt, damit man den Fehler leicht nachvollziehen kann. Auch habe ich bei UserVoice einen "Vorschlag" eingereicht.


    Mittwoch, 11. September 2019 10:31

Antworten

  • Moin,

    kann das gerade nicht verifizieren, aber wenn Du mehrere Runspaces in einem Prozess ansteuern möchtest, musst Du einen Runspace Pool definieren und die Runspaces dem Pool ordnungsgemäß zuweisen. Damit geht bei mir zumindest aus PowerShell heraus ein mehrfacher ADWS-Aufruf.

    Wenn ihr aber, wie Du schreibst, wirklich LDAP-Abfragen gegen das AD absetzt, könntet ihr ggfls. auf den DirectoryServices-Namespace und seine Klassen zurückgreifen und LDAP statt ADWS verwenden. Macht mehr Arbeit, ist aber schneller ;-) Und das wäre dann natives .NET.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 11. September 2019 13:17
  • > Im Grunde möchte ich MS nur auf ihren frappanten Fehler aufmerksam machen
     
    Dafür lesen hier aber nicht die richtigen Leute mit. UserVoice ist der richtige Ort für PoSh 5.1 Bugs. Sollte der Fehler auch bei PowerShell 6.x / Core auftreten, dann Github/Issues.

    Grüße, Denniver


    Blog: http://www.bytecookie.de

    Powershell Code Manager: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.

    Freitag, 13. September 2019 14:17
    Moderator

Alle Antworten

  • Moin,

    kann das gerade nicht verifizieren, aber wenn Du mehrere Runspaces in einem Prozess ansteuern möchtest, musst Du einen Runspace Pool definieren und die Runspaces dem Pool ordnungsgemäß zuweisen. Damit geht bei mir zumindest aus PowerShell heraus ein mehrfacher ADWS-Aufruf.

    Wenn ihr aber, wie Du schreibst, wirklich LDAP-Abfragen gegen das AD absetzt, könntet ihr ggfls. auf den DirectoryServices-Namespace und seine Klassen zurückgreifen und LDAP statt ADWS verwenden. Macht mehr Arbeit, ist aber schneller ;-) Und das wäre dann natives .NET.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 11. September 2019 13:17
  • Moin, Evgenij,

    ja, wir haben tatsächlich jetzt auch den Plan gefasst, den DirectoryServices-Namespace zu verwenden. Im Grunde möchte ich MS nur auf ihren frappanten Fehler aufmerksam machen, der anscheinend auch bei anderen zu Kopfschmerzen führt.

    Da der Fehler bei uns bereits zu einer Verzögerung von mehreren Wochen geführt hat, weil wir nicht wussten, woher dieser transiente Fehler stammt, wäre ein Fix sicher sinnvoll. Das muss anderen ja nicht auch zustoßen, was uns passiert ist.

    Wenn man den die Standardversion von PowerShell::Create() verwendet, dann erzeugt er bei jedem Aufruf einen neuen Runspace. Das müsste eigentlich die gleiche Wirkung haben wie dein Vorschlag. Ich prüfe das aber nochmal nach. Denn es gibt auch den PowerShell::Create()-Aufruf, dem man explizit sagen kann, dass er einen neuen Runspace aufmacht.

    Gruß,
    Axel Dahmen


    • Bearbeitet BetterToday Mittwoch, 11. September 2019 21:19
    Mittwoch, 11. September 2019 21:16
  • Ich habe es jetzt mit PowerShell::Create(RunspaceMode.NewRunspace) probiert: Der gleiche Fehler.
    Donnerstag, 12. September 2019 11:00
  • > Im Grunde möchte ich MS nur auf ihren frappanten Fehler aufmerksam machen
     
    Dafür lesen hier aber nicht die richtigen Leute mit. UserVoice ist der richtige Ort für PoSh 5.1 Bugs. Sollte der Fehler auch bei PowerShell 6.x / Core auftreten, dann Github/Issues.

    Grüße, Denniver


    Blog: http://www.bytecookie.de

    Powershell Code Manager: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.

    Freitag, 13. September 2019 14:17
    Moderator