Active directory search

Hi,

without specifying the complete DN of an object and using [ADSI]"LDAP:// "
provider can i serach an object? assuming my AD has many OU and users are
spread across many OU?

Hello Swamy,
$username = "swamy"
$searcher = new-object DirectoryServices.DirectorySearcher([ADSI]"")
$searcher.filter = "(&(objectClass=user)(sAMAccountName= $UserName))"
$searcher.findall()

not in v1 without modifying the type extensions.

This will do what your wanting

function Get-MyADUser($user="*"){
$filter = "(&(objectcategory=user)(sAMAccountName=$user)"
$ds = new-object
system.directoryservices.directorysearcher([adsi]"",$filter)
$ds.pagesize = 1000
$ds.findall() | %{$_.GetDirectoryEntry()}
}

"Swamy Channaveera" <SwamyChannaveera@xxxxxx> wrote in
message news3315E43-B209-4895-9422-E4381049492D@xxxxxx

Karl... just remember that findall() doesnt return DirectoryEntry and it
acts different. To get a DirectoryEntry you need to call the
GetDirectoryEntry() method on the returned object.

p.s. dont use objectclass

"Karl Mitschke" <kmitschke@xxxxxx> wrote in message
news:7063857f344588ca693ce0bc2465@xxxxxx

You are right There is no findall() and getdirectoryentry() method may be
with V2 it is available.


"Brandon Shell [MVP]" wrote:

It seems using quest's get-qaduser is a best bet, the following scripts
getting more complex as i'm not a scripting guy, i'm a support person on
Exchange and AD. Hope fully MS would simplify the scripts in PS for support
guys.

"Brandon Shell [MVP]" wrote:

You DO have those methods on a DirectorySearcher, but not on a
DirectoryEntry. What I was referring to is the [ADIS] type accelerator. In
v2 they add [ADSISearcher].

$user = [ADIS]"LDAP://USERDN"
is the same as
$user = New-Object System.DirectoryServices.DirectoryEntry("LDAP://USERDN")

To create a Searcher that WILL have findall() and getdirectoryentry().
$de = [ADSI]"LDAP://<Root of Search>" # DirectoryEntry for the root of the
search MUST HAVE
$filter = "(&()())" # LDAP Filter MUST Have
$props = @("prop1","prop2") # An array with the properties you want
returned (optional)
$searcher = New-Object System.DirectoryServices.DirectorySearcher
($de,$filter,$props)

Type Extensions
http://blogs.msdn.com/powershell/arc...24/644987.aspx

[ADSI] Accelerator
http://powershelllive.com/blogs/lunc...o-objects.aspx

Custom Type Accelerators
http://www.nivot.org/2008/03/27/Crea...owerShell.aspx

"Swamy Channaveera" <SwamyChannaveera@xxxxxx> wrote in
message news:7786CB3C-7E61-4DCE-93D1-5590878372BC@xxxxxx

I agree, if you use the get-qaduser it is more direct approach.

There was nothing wrong with using Get-QADUser, I think Karl was just trying
to narrow the scope of potential performance issues that you were
experiencing (I already address that in that post.)

Keep using Quest CMDLets. They are free, simple, and powerful.

"Swamy Channaveera" <SwamyChannaveera@xxxxxx> wrote in
message news:CB89FAF5-71EA-48ED-AE18-57065CC73C88@xxxxxx

The exchange cmdlets get-user is also capable getting the same result, but
Exchagne managment console can't installed as an application, if no Exch 2007
in installed on the network.



"Brandon Shell [MVP]" wrote:

Hello Brandon Shell [MVP],
That's exactly right - I wanted to see if the performance issues were related
to MS or Get-QADUser

I saw that you provided a much quicker version of the Get_QADUser script,
which looks like it will fix the OP's performance issue.

I don't use the Quest CMDLets much, as most of my work is directly against
our Exchange 2007 servers, and we don't install any non standard software
on them

Karl