[THIN] Re: Home directory and Profile Script
- From: "Rick Mack" <Rick.Mack@xxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Fri, 21 Oct 2005 09:43:36 +1000
Hi Andrew,
Tscmd will report on the value provided the servername is one of your
domain controllers.
eg tsmd DC_name user_name terminalserverprofilepath
will return the TS profile path
regards,
Rick
Ulrich Mack
Volante Systems
Level 2, 30 Little Cribb Street
Coronation Drive Office Park
Milton Qld 4064
tel: +61 7 32431847
fax: +61 7 32431992
rmack@xxxxxxxxxxxxxx <mailto:rmack@xxxxxxxxxxxxxx>
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx
[mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Wood
Sent: Thursday, 20 October 2005 8:32 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Home directory and Profile Script
Although, looking at this again... tscmd can only set the value
- it doesn't report on it (which is what was asked for).
Still neat tho' - and it does what it does very efficiently ;)
________________________________
From: thin-bounce@xxxxxxxxxxxxx
[mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Rick Mack
Sent: 19 October 2005 12:55
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Home directory and Profile Script
Hi,
Of course at the other end of the scale, if you're new to
scripting and just want to get the job done, you can generate a domain
(or group) user list using net user /domain or net group (on a DC), eg.
for /f "tokens=1,2,3" %i in ('net user /domain') do @echo %i >>
users.txt & @echo %j >> users.txt & @echo %k >> users.txt.
Edit the unwanted accounts out of users.txt and you've got a
user list for further scripting.
eg using tscmd
for /f %i in (users.txt) do tscmd %your_DC% %i
terminalserverhomepath \\server\users\%i <file://\\server\users\%i> &
tscmd %your_DC% %i terminalserverprofilepath \\server\profiles\%i
<file://\\server\profiles\%i>
That's 2 lines of script ;-)
Sorry guys, couldn't resist.
regards,
Rick
Ulrich Mack
Volante Systems
Level 2, 30 Little Cribb Street
Coronation Drive Office Park
Milton Qld 4064
tel: +61 7 32431847
fax: +61 7 32431992
rick.mack@xxxxxxxxxxxxxx
________________________________
From: thin-bounce@xxxxxxxxxxxxx on behalf of Andrew Wood
Sent: Wed 19/10/2005 9:41 PM
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?
The ADO query does a distinct lookup querying AD for a specific
filter type.
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.
In you're example you're instantiating variables every time you
enter the
recursive procedure. And you're going through Ous that might
never have
users. You're creating a large number of variables that
essentially hold no
useful values. You query the AD every time to get this data.
Potentially
your script wanders off down a whole OU structure that holds no
users.
So, in essence, you do a lot of work and create a lot of
variables and have
a whole stack of memory used and query the ad multiple times -
and you end
up with the same information.
And you think this is more efficient?
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx
[mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Braebaum, Neil
Sent: 19 October 2005 09:42
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Home directory and Profile Script
I suspect access
I've never been inclined to go down the ADO route for searching
in AD. I
know it's the most documented way, but it's so easy to write
functions to
descend the structure, I find it more efficient.
So the OP started off with a fully qualified DN to a user. But
clearly
that's largely irrelevant when evaluating all users in AD. Most
people when
writing ADSI scripts, do the whole objRootDSE and
getdefaultnamingcontext
thing.
Once you've got that, you've got LDAP parlance for the root of
your AD.
To evaluate all users in a container, you'd simply set a filter
on 'user'
objects and loop around them - hence:-
set objOU=getobject("LDAP://ou=Terminal Server Users, dc=fred,
dc=com")
objOU.filter=array("user")
for each objOUUser in objOU
' do whatever with each user - ie check paths, check group
membership...
next
But say you just wanted to descend all AD, opening all OUs and
containers,
only evaluate users, perhaps do some other conditional logic on
each user,
and do something, it's very easy to write a recursive sub to do
the
descending and processing.
So you've established the DN for the root of your AD, and you've
got your
defaultnamingcontext in a string:-
set objRootDSE=getobject("LDAP://rootdse";)
strdefaultnamingcontext=objRootDSE.get("defaultnamingcontext")
After that, you could just have a recursive sub that accepted an
ADsPath as
an argument (and perhaps other arguments if need be), that
descended AD, and
processed users, containers and OUs:-
sub recurseAD(ADPath)
set objContainer=getobject(ADPath)
objContainer.filter=array("user")
for each objContainerUser in objContainter ' whatever code you
want to run
against every user... perhaps including other conditions
next
objContainer.filter=array("organizationalunit")
for each objContainerSubOU in objContainer
call recurseAD(objContainerSubOU.adspath)
next
objContainter.filter=array("container")
for each ojbContainerSubContainer in objContainer
call recurseAD(objContainterSubContainer.adspath)
next
set objContainer=nothing
end sub
Then all you have to do to kick all this off, is call your
recursive
subroutine to start off with, hence:-
call recurseAD("LDAP://"&strdefaultnamingcontext)
And you've got an easy, lightweight script for evaluating all
containers
within AD, and processing each user found (assuming the security
context the
script is running under has conducive access by merit of DACLs).
Now you can use ADO searches, or you could simply evaluate the
NT provider,
then do a switcheroo using nametranslate to get the user object
via LDAP.
But the amount of times you're likely to have to process many
things within
the AD hierarchy by script, means that having a very simple,
lightweight,
recursive function that will descend all AD, will be an
axiomatic plus ;-)
Of course, you could just forget all that, do something with cmd
scripts, or
ADDUSERS, or LDIFDE, or CSVDE - but if you've already started
down the path
of writing an ADSI script, you needn't necessarily have to go
down the ADO
route to evaluate all the things you want to evaluate using the
LDAP
provider.
Neil
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Wood
> Sent: 18 October 2005 23:08
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Home directory and Profile Script
>
> But not on the TSProfilePath as its not a field you can
reference
> directly in AD is it? IIRC it's actually stored in
userparameters
> which is a binary?
>
> So, adodb to scoot through all the users, then initiate a user
object
> and use the ts extensions to interogate the ts properties..
>
> Something like this -
>
> ------------------------------
> Option Explicit
>
> Dim objCommand, objConnection, strBase, strFilter,
strAttributes,
> objUser
>
> Dim strQuery, objRecordset, strdistinguishedName, strTSPath,
strCN
>
>
> Set objCommand = CreateObject("ADODB.Command") Set
objConnection =
> CreateObject("ADODB.Connection") objConnection.Provider =
> "ADsDSOObject"
> objConnection.Open "Active Directory Provider"
> objCommand.ActiveConnection = objConnection '...change this
bit for
> your domain strBase = "<LDAP://dc=gilwood,dc=local>"
>
> strFilter = "(&(objectCategory=person)(objectClass=user))"
> strAttributes = "sAMAccountName,cn,distinguishedName"
> strQuery = strBase & ";" & strFilter & ";" & strAttributes &
> ";subtree"
> objCommand.CommandText = strQuery
> objCommand.Properties("Page Size") = 100
> objCommand.Properties("Timeout") = 30
> objCommand.Properties("Cache Results") = False Set
objRecordSet =
> objCommand.Execute
>
> Do Until objRecordSet.EOF
> strCN = objRecordSet.Fields("cn").Value
> strdistinguishedName =
> objRecordSet.Fields("distinguishedName").Value
>
> Set objUser = GetObject("LDAP://"; & strdistinguishedName)
> if Len(objUser.TerminalServicesProfilePath) > 0 Then _
> Wscript.Echo strCN & " " &
objUser.TerminalServicesProfilePath
>
> objRecordSet.MoveNext
> Loop
>
> objConnection.Close
>
> ------------------------------
>
> More than happy for someone to point out a quicker way mind.
>
> Personally - with W2k3 I've pretty much stopped using these
settings
> and simply set the ts profile and home directories as part of
the
> loopback policy.
>
>
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Ormond_Merino@xxxxxxx
> Sent: 18 October 2005 21:24
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Home directory and Profile Script
>
> You could use ADODB.Command to query AD just like a SQL
statement. A
> google search should help.
>
> Regards,
> Ormond Merino
>
>
> -----Original Message-----
> From: msemon@xxxxxxx [mailto:msemon@xxxxxxx]
> Sent: Tuesday, October 18, 2005 3:22 PM
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Home directory and Profile Script
>
> I am trying to create a script to pull from Active Directory
all
> users which have TS Home Directories and Profiles. What I have
so far
> works for a single user account, for example jones. Is there a
way to
> do this for all users in AD.
>
>
>
> Set objUser = GetObject _
>
> ("LDAP://cn=jonesBill,ou=Management,dc=NA,dc=dc1,dc=com";)
>
>
> WScript.Echo "Terminal Services Profile Path : " & _
>
> objUser.TerminalServicesProfilePath
>
> WScript.Echo "Terminal Services Home Directory: " & _
>
> objUser.TerminalServicesHomeDirectory
>
> WScript.Echo "Terminal Services Home Drive: " & _
>
> objUser.TerminalServicesHomeDrive
>
> WScript.Echo "Allow Logon: " & objUser.AllowLogon
>
#####################################################################################
This e-mail, including all attachments, may be confidential or privileged.
Confidentiality or privilege is not waived or lost because this e-mail has been
sent to you in error. If you are not the intended recipient any use,
disclosure or copying of this e-mail is prohibited. If you have received it in
error please notify the sender immediately by reply e-mail and destroy all
copies of this e-mail and any attachments. All liability for direct and
indirect loss arising from this e-mail and any attachments is hereby disclaimed
to the extent permitted by law.
#####################################################################################
Other related posts:
