[ADSI] Syntax

11 views
Skip to first unread message

Chris Warwick

unread,
Sep 27, 2006, 3:44:37 AM9/27/06
to
Now RC2 is here (yippee!) I wanted to start using the [adsi] types,
but I see no documentation in any of the references supplied.

I've seen this syntax in a couple of blog entries:

$objOU = [ADSI]"LDAP://localhost:389/OU=HR,dc=NA,dc=fabrikam,dc=com"

So [adsi] obviously takes an LDAP uri... But where do I find the
complete spec? Do I have to specifiy a hostname? What happens if I'm
in a domain and I don't know/dont care which LDAP server provides the
answer? Will the LDAP port default to 389? Do I have to use the
OU=,dc=,dc= syntax or can I use other LDAP schemes?

Thanks for any additional info!

Chris

Nick Howell

unread,
Sep 27, 2006, 9:22:50 AM9/27/06
to
ADSI is just a .NET type like any other; it's actually
System.DirectoryServices.DirectoryEntry. When PS does a cast like that,
it typically guesses that it should call the constructor with that
argument, so [adsi]$someString is the same as new
System.DirectoryServices.DirectoryEntry $someString .

So, for documentation on what that string would be, I would reference
the DirectoryEntry constructor documentation [1], or the
DirectoryEntry.Path property [2] (probably more what you're looking for).

[1] http://msdn2.microsoft.com/en-us/library/87tye19w.aspx
[2]
http://msdn2.microsoft.com/en-us/library/system.directoryservices.directoryentry.path.aspx

HTH,
Nick

Chris Warwick

unread,
Sep 27, 2006, 3:21:08 PM9/27/06
to
On Wed, 27 Sep 2006 08:22:50 -0500, Nick Howell
<msnews-0....@spamgourmet.com> wrote:

>ADSI is just a .NET type like any other; it's actually
>System.DirectoryServices.DirectoryEntry. When PS does a cast like that,
>it typically guesses that it should call the constructor with that
>argument, so [adsi]$someString is the same as new
>System.DirectoryServices.DirectoryEntry $someString .

<snip>

Thanks Nick, that answers the question completely :-)

Chris

/\/\o\/\/ [MVP]

unread,
Sep 27, 2006, 5:40:02 PM9/27/06
to
I really think the wrapper makes it harder to work with and discover AD, also
will render all old examples and code useless (OK its beta but RC2 and for
what ?)
for WMI I see the plusses.

I did a completer explaination (and more complaining) here :
http://mow001.blogspot.com/2006/09/powershell-rc2-and-active-directory.html

I really hope, this does not stay like this in RTM

Greetings /\/\o\/\/

Arul Kumaravel[MSFT]

unread,
Sep 28, 2006, 8:36:10 PM9/28/06
to
There is no plan to change this MOW. I replied to another thread on this
issue. I understand that it breaks existing scripts written using
DirectoryEntry object but the new adapter will make it easier to write ADSI
scripts once you understand the usage.

--
--
Aruk Kumaravel [MSFT]
Windows PowerShell Development Manager
Microsoft Corporation
My PowerShell Blog: http://blogs.msdn.com/arulk
This posting is provided "AS IS" with no warranties, and confers no rights.

"/\/\o\/\/ [MVP]" <oM...@discussions.microsoft.com> wrote in message
news:DA091249-E0A3-4F96...@microsoft.com...

/\/\o\/\/ [MVP]

unread,
Sep 29, 2006, 7:34:01 AM9/29/06
to
Arul,

My problem is not updating the scripts, (I understand this is betacode so
this still can happen) and to change that is a one-time task

but my problem is more that it is getting much harder to do and discover
things on the fly, interactively in the Console. (what I do a lot)
and I do not see ANY improvement in the way this is changed.

As for my work I use PoSH mostly for interactive work in AD SMS and MOM.
so this bites me a lot, in my dayly work.

and I realy think its the wrong way to go, the GlidePath should be heading
to .NET ,
not back to the VbScript way's (and looking up again ) I was so glad to
leave behind.

Also what is wrong with InvokeGet InvokeSet etc. these give you allready a
way to use the COM methods.

also the improvements / glidepath are in the .NET space in the future.
and we loose one of the big advantages of PowerShell ... discoverability.

so still I think this is a Step back not forward, as this goes agains the
consistency of PowerShell, as it works different from the rest, only to make
it look like the Old VbScript way again, and hide all cool improvements.


Greetings /\/\o\/\/

Dan Metzler

unread,
Sep 29, 2006, 9:05:45 AM9/29/06
to
Mow,

So perhaps the issue is that the hidden methods are hidden?

Create
Put
Set
PutEx
SetEx
GetInfo
SetInfo

Arul,

Any plans to expose these to gm? Are there any other hidden methods? (And
I'm still wondering about how to access child objects without psbase as even
with the vbscript interface this was possible.)

Thanks,

- Dan

"/\/\o\/\/ [MVP]" <oM...@discussions.microsoft.com> wrote in message

news:8AB87924-9D79-4ECF...@microsoft.com...

/\/\o\/\/ [MVP]

unread,
Sep 29, 2006, 10:16:01 AM9/29/06
to
you can do

$de.psbase | gm

but that psbase typing is killing (no TabCompletion)
I need to type 3 times as much as in old situation.

and that fake VbScript methods I do not find usefull (as its was implemented
before by InvokeGet / InvokeSet.) as Addition next to the DirectoryEntry
Methods OK, but the DirectoryEntry Methods you need much more as those
"Hidden" Methods.

think also about more advanced task as ACL's etc.

as there are no plans to fix this, I guess it will be IronPython for my AD
management from now on.

Greetings /\/\o\/\/

klu...@xtra.co.nz

unread,
Sep 30, 2006, 1:13:55 AM9/30/06
to
maybe we need to use the type extensibility to make it work out we
want?

Karl

Reply all
Reply to author
Forward
0 new messages