AD Search.findall() and the pipeline

When doing an AD search such as the following from the command line you can
see the individaul pages (of AD objects) returned from AD (on a slow network
at least)
$dom = [System.DirectoryServices.ActiveDirectory.Domain]::getcurrentdomain()
$root = $dom.forest.rootdomain.getdirectoryentry()
$search = [System.DirectoryServices.DirectorySearcher]$root
$search.filter = “(&(objectcategory=person)(objectclass=user))�
$search.CacheResults = $false
$search.PageSize = 10
$search.findall()

so why when I do similar but use a pipeline:
$search.findall() | format-table path
or
$search.findall() | where {$_.properties.<attribute> -match "*bla*"}

Does powershell insist on the $search.findall() completing first before
feeding the AD objects into the pipeline?

Is there anything I can do with the $search object to provoke powershell
into feeding the pipeline as results arrive back from AD?

(Also is it me or is the $search.ServerTimeLimit attribute not honored when
I search from powershell?)

:J

My suspicion is that its a function of the pipeline processing. if you think
of putting the contents of a file onto the pipeline it reads the whole file
rather than one line at a time. In this case I suspect that the interaction
of findall() and the pipeline is overriding the pagesize in that the pipeline
is in effect prompting for the next set of data
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Jeremy Pack" wrote:

> When doing an AD search such as the following from the command line you can
> see the individaul pages (of AD objects) returned from AD (on a slow network
> at least)
> $dom = [System.DirectoryServices.ActiveDirectory.Domain]::getcurrentdomain()
> $root = $dom.forest.rootdomain.getdirectoryentry()
> $search = [System.DirectoryServices.DirectorySearcher]$root
> $search.filter = “(&(objectcategory=person)(objectclass=user))�
> $search.CacheResults = $false
> $search.PageSize = 10
> $search.findall()
>
> so why when I do similar but use a pipeline:
> $search.findall() | format-table path
> or
> $search.findall() | where {$_.properties.<attribute> -match "*bla*"}
>
> Does powershell insist on the $search.findall() completing first before
> feeding the AD objects into the pipeline?
>
> Is there anything I can do with the $search object to provoke powershell
> into feeding the pipeline as results arrive back from AD?
>
> (Also is it me or is the $search.ServerTimeLimit attribute not honored when
> I search from powershell?)
>
> :J
>

Just out of curiosity have you tried Get-QADUser (from the Quest cmdlet set)
for simple searches like this?
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"RichS" wrote:

> My suspicion is that its a function of the pipeline processing. if you think
> of putting the contents of a file onto the pipeline it reads the whole file
> rather than one line at a time. In this case I suspect that the interaction
> of findall() and the pipeline is overriding the pagesize in that the pipeline
> is in effect prompting for the next set of data
> --
> Richard Siddaway
> Please note that all scripts are supplied "as is" and with no warranty
> Blog: http://richardsiddaway.spaces.live.com/
> PowerShell User Group: http://www.get-psuguk.org.uk
>
>
> "Jeremy Pack" wrote:
>
> > When doing an AD search such as the following from the command line you can
> > see the individaul pages (of AD objects) returned from AD (on a slow network
> > at least)
> > $dom = [System.DirectoryServices.ActiveDirectory.Domain]::getcurrentdomain()
> > $root = $dom.forest.rootdomain.getdirectoryentry()
> > $search = [System.DirectoryServices.DirectorySearcher]$root
> > $search.filter = “(&(objectcategory=person)(objectclass=user))�
> > $search.CacheResults = $false
> > $search.PageSize = 10
> > $search.findall()
> >
> > so why when I do similar but use a pipeline:
> > $search.findall() | format-table path
> > or
> > $search.findall() | where {$_.properties.<attribute> -match "*bla*"}
> >
> > Does powershell insist on the $search.findall() completing first before
> > feeding the AD objects into the pipeline?
> >
> > Is there anything I can do with the $search object to provoke powershell
> > into feeding the pipeline as results arrive back from AD?
> >
> > (Also is it me or is the $search.ServerTimeLimit attribute not honored when
> > I search from powershell?)
> >
> > :J
> >

>if you think of putting the contents of a file onto the pipeline
> it reads the whole file rather than one line at a time.
Agreed but my example would be get-childitem which does put objects into the
pipeline one at a time:
gci c:\ -r | ? {$_.extension -eq ".docx"}
(I know that is a poor way to search for file types and that I should use
-filter its was just a quick example)

In your example of a file you could (would) use
Get-content -readcount
or
Get-content -delimiter
to feed the pipeline in small chunks (which is what I want)

> Just out of curiosity have you tried Get-QADUser (from the Quest cmdlet set)
> for simple searches like this?
No. I live in an enterprise world where what software one can use is
controlled. I could put quest on my own personal machine but it would not be
on any production machine. So I have to write querys I can use elsewhere.

Thanks for the help Richard and see you Thursday

:J

format-table is a cmdlet, not a filter. If it were a filter, it would
receive the first object piped to it while the originating cmdlet, function,
or method was still working away.

But a practical reason exists for this in the case of format-table. The
spacing of elements in the first record output by format-table (and in the
column headers too) might depend on the content of the last record. It
therefore needs to have all records before it can display the first.

One could argue that this is not the case when only a single field is being
displayed, but it would seem inconsistent and unnecessary for a cmdlet to
operate like a filter in such cases where that could technically be done.

If you want the output to appear sooner, you could write your own filter to
do what "format-table name" does:

filter listpath {$_.path}

then use it like this:

$search.findall() | listpath

/Al

"RichS" <RichS@discussions.microsoft.com> wrote in message
news:B200811C-174C-4F8D-92EA-4BF099A297A1@microsoft.com...
> My suspicion is that its a function of the pipeline processing. if you
> think
> of putting the contents of a file onto the pipeline it reads the whole
> file
> rather than one line at a time. In this case I suspect that the
> interaction
> of findall() and the pipeline is overriding the pagesize in that the
> pipeline
> is in effect prompting for the next set of data
> --
> Richard Siddaway
> Please note that all scripts are supplied "as is" and with no warranty
> Blog: http://richardsiddaway.spaces.live.com/
> PowerShell User Group: http://www.get-psuguk.org.uk
>
>
> "Jeremy Pack" wrote:
>
>> When doing an AD search such as the following from the command line you
>> can
>> see the individaul pages (of AD objects) returned from AD (on a slow
>> network
>> at least)
>> $dom =
>> [System.DirectoryServices.ActiveDirectory.Domain]::getcurrentdomain()
>> $root = $dom.forest.rootdomain.getdirectoryentry()
>> $search = [System.DirectoryServices.DirectorySearcher]$root
>> $search.filter = "(&(objectcategory=person)(objectclass=user))"
>> $search.CacheResults = $false
>> $search.PageSize = 10
>> $search.findall()
>>
>> so why when I do similar but use a pipeline:
>> $search.findall() | format-table path
>> or
>> $search.findall() | where {$_.properties.<attribute> -match "*bla*"}
>>
>> Does powershell insist on the $search.findall() completing first before
>> feeding the AD objects into the pipeline?
>>
>> Is there anything I can do with the $search object to provoke powershell
>> into feeding the pipeline as results arrive back from AD?
>>
>> (Also is it me or is the $search.ServerTimeLimit attribute not honored
>> when
>> I search from powershell?)
>>
>> :J
>>