[THIN] Re: Home directory and Profile Script
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2005 12:59:01 +0100
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Wood
> Sent: 19 October 2005 12:41
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Home directory and Profile Script
>
> Wonderful that it is to see a recursive procedure used - is
> it truly worth the effort in this example?
Yup.
> The ADO query does a distinct lookup querying AD for a
> specific filter type.
It searches all of AD and simply uses 4GL logic to decide on whether to
return it.
> The way the filter was created you're going to have a single
> query and return a distinct set of values. So, a single
> process of lookup against your AD environment to get the
> data, then some local client work. Granted you then have to
> look for all the records that are returned, but that initial
> query was done just once.
And?
The thing is with doing this sort of scripting, is that most scripters
assume it's all built in. When I was first writing ADSI scripts, they
were for NT4 clients, that didn't necessarily have ADO support.
As a generalism, ADO maybe perfectly efficient at doing what must be
done - effectively evaluating all objects, with filters set.
However, it requires additional interfaces, more complex scripting, and
another learning hurdle.
I'm not evaluating or enumerating objects (at the client side) other
than the ones I want - ie OUs, containers, and users (and I only left
containers in, because the default users is a container).
> In you're example you're instantiating variables every time
> you enter the recursive procedure.
And destroying them when I leave the subroutine - what are you trying to
imply, here?
> And you're going through
> Ous that might never have users.
As will, ultimately, an ADO search - because until it's tried to find
matching criteria, it's got to establish whether it's there...
The one other potential answer I had for this was to search the GC for
users - as that would truly be quicker and more efficient, but that
would give you forest-wide users, and you'd *still* need to open the
user object, 'cos I'm pretty sure these attributes aren't in the GC.
But in all of this, I wasn't losing sight of the hinted level of
expertise of the OP - that being a small script directly opening an LDAP
object, and questioning how to go further. Given where he was (implied)
this is the easiest step, and even now, I don't bother with ADO stuff,
unless I definitely want a more SQL type enquiry.
> You're creating a large
> number of variables that essentially hold no useful values.
What "large number of variables"? I only saw one cited. The rest were
objects that will ultimately be destroyed. And besides, it wasn't a
fully working script, it was a working answer to the question asked.
I also went to the trouble of explaining why I was suggesting an
alternative to ADO, so what's your problem?
> You query the AD every time to get this data.
And? What exactly do you think is going on during an ADO search?
> Potentially
> your script wanders off down a whole OU structure that holds no users.
True for any search looking for all answers. The difference being that
if you code your own *simple* search that can recurse, you can clearly
establish a narrow hierarchy, or just simply search one OU - or even one
layer of OUs.
> So, in essence, you do a lot of work and create a lot of
> variables
Where?
> and have a whole stack of memory used
And destroyed.
> and query the
> ad multiple times -
So something passing it off to the server side will do. To say nothing
of having to deal with paging on larger searches.
> and you end up with the same information.
Yup
> And you think this is more efficient?
What are you *trying* to suggest is so wholly more efficient about doing
an ADO search!?
Neil
*****************************************************************************
This email and its attachments are confidential and are intended for the above
named recipient only. If this has come to you in error, please notify the
sender immediately and delete this email from your system. You must take no
action based on this, nor must you copy or disclose it or any part of its
contents to any person or organisation. Statements and opinions contained in
this email may not necessarily represent those of Littlewoods Shop Direct Group
Limited or its subsidiaries. Please note that email communications may be
monitored. The registered office of Littlewoods Shop Direct Group Limited is
100 Old Hall Street Liverpool L70 1AB registered number 5059352
*****************************************************************************
This message has been scanned for viruses by BlackSpider MailControl -
www.blackspider.com
********************************************************
This Weeks Sponsor: Cesura, Inc.
Know about Citrix end-user slowdowns before they know.
Know the probable cause, immediately.
Know it all now with this free white paper.
http://www.cesurasolutions.com/landing/WPBCForCitrix.htm?mc=WETBCC
********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
ThinWiki community - Excellent SBC Search Capabilities!
http://www.thinwiki.com
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
Other related posts:
