[ADSI] & [ADSISearcher] PowerShell adapters - Primer Request RRS feed

  • Question

  • Throughout the course of administration in a Windows domain; everybody knows (or will one day) that administration tasks in ActiveDirectory or any directory service objects (e.g. LDAP & WinNT too) will be necessary.

    I recently was troubleshooting some SYSVOL replication issues and part of the recommended troubleshooting steps recommended gathering some details via the ADSIedit snap-in, which is all fine and dandy when your primary choice of administration is through the GUI.

    I prefer to always learn the command-line way and once a tenable mastery of whatever Microsoft technology is achieved via command-line (I prefer PowerShell), then I can rest easy and take the GUI route.  Learning the command-line for a given Windows role or feature exposes the inner workings of said technology and forces the enterprising administrator to learn how it really works in order to achieve a functional deployment of said role/feature via command-line.

    With all of that being said...I really wanna exploit the advantages of using the [ADSI] & [ADSISearcher] adapter types.

    There is a litany of information for ADSI apis using visual basic but how do those class constructors, methods, and properties translate to use via the PowerShell interface?

    I would love to either be pointed in the right direction or even graciously handed some details on how to expose the objects accessible via these ADSI adapters.

    e.g., how would one enumerate child objects in the root container of a domain?  I understand there are some basic concepts such as binding (which the searcher adapter type kind of streamlines) but I don't even know where to begin.

    I have tried some hands-on stuff to see what I can glean from the LDAP & WinNT providers using the root of my Active Directory domain and a local domain controller's computer object, respectively.

    A couple screenshots illustrating the limited extent of my knowledge and foray into learning how to use these adapters in PowerShell.

    I'm not really sure what to make of the information from the WinNT-provider example but the point is that I'm trying to learn and am at my wit's end finding information on how to even begin using what I intuited are very powerful methods to gain access to the innermost parts of ActiveDirectory and related directory-service objects.

    Who knows where to start?

    thanks in-advance!



    Wednesday, February 7, 2018 2:24 AM


All replies

  • Copy and paste these two lines to see what happens. (WMF 5)


    For an type "accelerator" (not adapter).

    [adsi]|gm -static

    [adsisearcher]|gm -static

    [environment] | gm -static




    Wednesday, February 7, 2018 3:07 AM
  • thank you, JRV!

    I had seen a technet blog post which had referred to them as "adapter types" as well, probably some confusion with the vernacular...since even the PS Best Practices book discusses how the accelerators are "adapters" in the context of how they are implementations of .NET classes and what not.  But I am glad you put me on to the appropriate terms, this has proven a lot more fruitful in my further research.

    So essentially these assembly modules (for want of a better term) have to be manually loaded (constructed), at least they do in order to reference the "[accelerators]" type?

    Curious that it was once natively supported but then pulled.

    In any case, thanks for getting me squared away with that literature--it was very helpful in getting me started on what I should start reading.



    Friday, February 9, 2018 4:49 AM
  • Type accelerators have been part of PowerShell since the beginning.  Nothing has been changed.  Perhaps you could take some time to take a course in PowerShell then you could also learn something about the Net Framework which is what PowerShell and modern Windows are based on.

    Learn PowerShell  


    Friday, February 9, 2018 4:54 AM
  • Example:

    add-type -AssemblyName System.Windows.Forms
    $myform = [frm]::new()


    Friday, February 9, 2018 8:35 AM