[THIN] Re: Home directory and Profile Script
- From: "Andrew Wood" <andrew.wood@xxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2005 13:17:37 +0100
So what you're saying is - 'yes, my process was inefficient but there's more
than one way to skin a cat'. I concur.
Just think about how a recursive procedure works; write it out on a bit of
paper and tell me that any one time you only have one set of variables.
There's no need for a whitepaper - just a yes or no would do ;)
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Braebaum, Neil
Sent: 19 October 2005 12:59
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Home directory and Profile Script
> -----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=TBCC
********************************************************
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
********************************************************
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:
