Kapitel 10. ADSI und die Windows PowerShell

Streng genommen müsste die Überschrift zu diesem Kapitel »ADSI und die Windows PowerShell 1.0« lauten, denn die Version 1.0 bietet leider keine direkte Unterstützung für ADSI (etwa in Gestalt eines Providers) und es liegt daher die Vermutung nahe, dass sich dies mit einer »Version 2.0« ändern könnte (irgendein Anzeichen gab es, bis dieses Buch in den Druck ging, allerdings nicht). Das bedeutet jedoch nicht, dass die WPS 1.0 keine Active Directory-Objekte ansprechen kann (dann wäre dies ein sehr kurzes Kapitel). Es geht und es geht sogar relativ gut, es sind leider nur keine offiziellen Cmdlets vorhanden, welche diese Aufgabe noch etwas eleganter erledigen könnten. Es gibt insgesamt drei Varianten, um z. B. neue Benutzer und Gruppen anzulegen und Abfragen in Active Directory durchzuführen. Zunächst sind die .NET-Basisklassen im Namespace System. DirectoryServices zu nennen. Dank des [ADSI]-Aliases ist deren Einsatz sogar erstaunlich unkompliziert. Als weitere Möglichkeit kann auf die bereits in Kapitel 9 kurz vorgestellten PowerShell Community Extensions (PSCX) zurückgegriffen werden, die in der Version 1.1 auch einen ADSI-Provider enthalten. Last, but not least, hat der Netzwerktoolspezialist Quest nicht nur eine Reihe einfacher Active Directory-Cmdlets entwickelt, sondern stellt diese dankenswerterweise auch noch kostenlos zur Verfügung (die Downloadadresse lautet, allerdings ohne Gewähr, http://www.quest.com/2_0/registration.aspx?requestdefid=1325 – es ist eine einmalige Registrierung erforderlich). Diese Variante wird in diesem Kapitel aber nur am Ende kurz vorgestellt. Es gibt sogar noch eine Variante. Diese besteht darin, weiterhin VBScript einzusetzen und auf die WPS beim Active Directory-Zugriff zu verzichten. Ein »Portieren« von ADSI-VBScript-Skripts wird durch den Umstand erschwert, dass kein direktes Pendant zur GetObject(»LDAP://«)-Funktion existiert, die für den Zugriff auf den ADSI-Provider verwendet wird. Daher lassen sich diese Skripts nicht eins zu eins übertragen. In diesem kurzen Kapitel geht es in erster Linie um den Einsatz der .NET-Basisklassen und des [ADSI]-Aliases, mit denen sich bereits einiges anfangen lässt.

Wer experimentierfreudig ist, kann es mit der BindToMoniker-Methode der Klasse System.RunTime.Interopservices.Marshal probieren. Damit lassen sich laufende COM-Anwendungen über ihren Kurznamen (Moniker genannt) ansprechen. Der folgende Befehl funktioniert zumindest: Code View: Scroll / Show All $AD = [System.RunTime.InteropServices.Marshal]::BindToMoniker("LDAP://westendserver/DC=weste ndserver,DC=de") Nur scheint das resultierende COM-Objekt $AD danach auf keinerlei Aktivitäten mehr zu reagieren.