#207086 - 2013-04-09 07:31 PM
ADO query does not work in Win7 (though does in XP)
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
Hi,
I'm running the following KIX code snippet:
break on
$AttrName = "memberof"
$ObjName = "TestUser"
$objCommand = CreateObject("ADODB.Command")
$objConnection = CreateObject("ADODB.Connection")
$objConnection.Provider = "ADsDSOObject"
$objConnection.Open("Active Directory Provider")
$objCommand.ActiveConnection = $objConnection
; define initial vars for items to be read
$objRootDSE = GetObject("LDAP://rootDSE")
$defaultNamingContext = $objRootDSE.Get("defaultNamingContext")
; define the query statement
$objCommand.CommandText = "Select $AttrName from 'LDAP://$defaultNamingContext' WHERE sAMAccountName='" + $ObjName + "'"
; and execute it
$Recordset = $objCommand.Execute
$strURL = $Recordset.Fields("$AttrName").Value
for $x = 0 to ubound($strURL)
$arrGROUP = split($strURL[$x],",")
$GROUP = SUBSTR($arrGROUP[0],4,len($arrGROUP[0])-3)
$UserIsMemberOf = $UserIsMemberOf + $GROUP + ";"
Next
? $UserIsMemberOf
$objConnection.close
The purpose is to query a individual user's specific AD attribute via LDAP (memberOf is just an example to retrieve a list). The query is in this SQL statement:
"Select MemberOf from 'LDAP://DC=my,DC=domain,DC=com' WHERE sAMAccountName='TestUser'"
(sent via LDAP to the AD)
Running this code in WinXP gives me the attribute content, running it on Win7-64 fails entirely ! (both Kix32 V4.62)
The first failing line in Win7 is this:
$defaultNamingContext = $objRootDSE.Get("defaultNamingContext")
It seems to choke on the ("defaultNamingContext") - in debug mode, this part appears as screen output ! Is there something wrong with .GET, or passing/appending a parameter ?
Replacing this by the NamingContext literal string for a test, it runs until here:
$strURL = $Recordset.Fields("$AttrName").Value
Here, it trips over ("$AttrName").Value, and drops out with "ERROR: Unexpected command!".
Do I miss something, or what's wrong here ? I thought this kind of stuff is just passed tru to the OS ? At least it works fine if the same things are coded in VBS ... no problems there with the ADO queries. Still, I need to keep this in KIX, as it is part of a login script which is supposed to run on WinXP and Win7 - nope, I don't want/intend to replace it by something else ...
This is driving me mad ... could anybody be so kind and help me out of this ?
Thanks a bundle !
Andy
|
|
Top
|
|
|
|
|
#207088 - 2013-04-09 08:40 PM
Re: ADO query does not work in Win7 (though does in XP)
[Re: Allen]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4557
Loc: USA
|
Also... this line has vars inside stings... never a good idea...
$objCommand.CommandText = "Select $AttrName from 'LDAP://$defaultNamingContext' WHERE sAMAccountName='" + $ObjName + "'"
change to
$objCommand.CommandText = "Select " + $AttrName + " from 'LDAP://" + $defaultNamingContext + "' WHERE sAMAccountName='" + $ObjName + "'"
|
|
Top
|
|
|
|
|
#207090 - 2013-04-10 12:08 PM
Re: ADO query does not work in Win7 (though does in XP)
[Re: Allen]
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
Hi,
Also... this line has vars inside stings... never a good idea...
actually, you're right - it's a "bad styled" mixture, the first var being inside, the 2nd correctly added to the string :-)
Thanks for that hint, I'll update it in the final code.
Andy
|
|
Top
|
|
|
|
|
#207091 - 2013-04-10 01:07 PM
Re: ADO query does not work in Win7 (though does in XP)
[Re: Allen]
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
Hi,
Curious... are you just checking group memberships?
well ... no, not only :-)
As stated in my original post, I need to retrieve specific attributes for the user currently running the login script, as most relevant things, e.g. drive/printer mappings and branching into specific script sections, are done based on AD attribute content.
The actual login script has no hard-coded elements inside - it only does what it sees in several external sources.
For example, users can manage their individual persistent drive/printer mappings in an AD attribute (instead of their local profile, if they would map it locally) via a web interface, and get all mappings at each login. Still, those individual mappings can be managed centrally, if a share needs to be moved or renamed, by simply running a search/replace against the AD. No coding involved, no need to update local drive mappings !
The group membership check (using the memberOF attribute) is something we came up with some years ago, partly because of the hazzle of determining group memberships (of computers) and the execution time of such checks - memberOf is retrieved only once and cached in KIX, while individual group membership checks would require to access the AD for each check. But, mainly, because of the following: The name of the group the user or computer is member of contains the parameters used by the script.
Therefore, I don't know the full name of the group in advance, only the indicator (root) component. The rest of the name varies, depending on the usage.
For example:
A drive mapping group is named like
ADLogin_Map_Drv_Description_Q_server_share_dir
The script code only needs to know the "ADLogin_" part, plus "Map_Drv_" to indicate a drive mapping (this is the root component). If this string is found in the memberOF data, it gets extracted, split up and passed to the drive mapping UDF, resulting in a drive mapped as Q: = \\server\share\dir
This is what I called Dynamic Mapping Groups - makes the script more flexible, and avoiding any code changes at all, if some mappings need to be changed.
We even put this into self service: A delegated group owner has the right to manage the group members (as for other regular groups), plus: The teams managing the servers and shares don't need to fiddle around with error-prone script updates anymore ! They just create the share and the matching group, assign the access rights and group members, and the people get the new share mapped. Moving or renaming a share - nothing easier: Update the share, rename the group, done.
There's groups and code provided for Drive mapping, printer mapping, script branching, individual script execution. Need to run something (e.g. pick up a local log file) for a bunch of users: Create the script plus matching group, assign it to one or more users, and it runs at the next login.
Cool, eh ?
Only now, all this is broken for the Win7-64 users ... :-(
Andy
|
|
Top
|
|
|
|
|
#207093 - 2013-04-10 11:12 PM
Re: ADO query does not work in Win7 (though does in XP)
[Re: Allen]
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
Yup, that smells already ...
I made a UDF in the past that I know was created while on Windows 7 and it used DefaultNamingContext. You might give it a shot and see if you get the same results.
Tried the UDF - same result, fails at the ".get" statement.
But ... to make things more confusing: After lots of testing with different KIX versions, I found out that the source location of KIX32.EXE makes the difference !
As you can imagine, the test code was not called in a login script, but interactively.
So, whenever kix32.exe is stored on the local HDD, it works fine !
Also, calling KIX32 from the netlogon share works. Only when calling it from my development (which I did all the time) share, it fails with the explained symptoms.
Btw, all this testing and the issues explained only refers to the code pasted above !
For this tests, I have no other KIX script around this, and always called it manually from the command prompt (aka dos-box) like this:
\\server1\share$\dir\kix32.exe c:\temp\ADOquery.kix
or
c:\temp\kix32.exe c:\temp\ADOquery.kix
or
\\domain\netlogon\kix32.exe c:\temp\ADOquery.kix
The first two calls work fine, the last executes the KIX, but drops out when reaching the .GET statement.
Do you have _any_ idea what difference the location of KIX32.EXE makes for running a KIX script ??
Andy
Edited by AndreasBucher (2013-04-10 11:21 PM)
|
|
Top
|
|
|
|
|
#207094 - 2013-04-10 11:31 PM
Re: ADO query does not work in Win7 (though does in XP)
[Re: Glenn Barnas]
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
Glenn,
thanks for the reply !
Look at the WOW3264 SetOption parameters in the Kix manual and README file.. some of your code might be looking and file or registry locations on x64 platforms that aren't where you think they are. Just a thought because you just now pointed out it is the x64 users and that's a common "gotcha".
Glenn
Yes, I know about the hassle of this "nice" Win7 features (file and reg redirection) ... but I don't assume it might he me here, as the above code doesn't touch files or registry entries. It's supposed to query the AD via LDAP, nothing else. See my previous post about narrowing down the potential cause ... which still might mean that the Win7 users actually complaining might have another issue, which is to be determined.
Regards,
Andy
|
|
Top
|
|
|
|
|
#207095 - 2013-04-11 12:15 AM
Re: ADO query does not work in Win7 (though does in XP)
[Re: AndreasBucher]
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
Well ... some (much) tests later:
Other $ (hidden) shares work - KIX has no problem when called from such a share.
But: My development share was set up like this:
\\server\share$\netlogon\adlogin\adlogin_kix\kix32.exe
with no (list) access to share$, but read to netlogon and below.
I granted read for one user to share$ (like on the other $ share had I created before for testing), and the ADO query runs for this user !
So, the result seems to be as follows:
On Win7-64 (didn't test any other Win7 systems), when the user has no (list) access to the root directory of a share where the KI32.EXE is hosted in a directory below, some ADO query components - namely $objRootDSE.Get("defaultNamingContext"), fails.
Huh ?
Andy
|
|
Top
|
|
|
|
|
#207111 - 2013-04-17 02:20 PM
Re: ADO query does not work in Win7 (though does in XP)
[Re: Glenn Barnas]
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
yep, same here: On the regular client PCs, nothing is installed, everything is run from the netlogon share (no, not really - due to network access, data transfer and execution speed issues, the login.bat caches the KIX32.exe (plus everything else) in a local directory via robocopy, and then runs everything from there if caching was successful. But this cache verification is done every time before the kix-stuff is called, so it's always identical to the items on the netlogon share.
As in your case, the admin/developer's PCs do have access to all versions of KIX32, but usually, everything is done using the production version named just KIX32.exe.
If you or anybody likes, please give it a try, to see if you get the same bahaviour as me:
On any PC, create a directory which contains a directory (like this: D:\data\kixtest) which contains the KIX32.exe and the KIX script that does the ADO AD access.
Then, share the D:\data directory as \data. From a remote PC, call the kix32.exe adotest.kix, to verify that everything works and you get the content of the AD attribute.
Then, revoke as much rights as possible from D:\data only, leaving at least read access (break ACL inheritance here) on D:\data\kixtest. Now, when running a
dir \\computer\data
you should see no files or dirs at all.
When running a
dir \\computer\data\kixtest
you should see the files, and be able to access them. If you can't, grant just enough rights to achive the above situation (but the \data diretory content itself must be without rights)
Then, run the kix script again, using a Win7 client, and it should refuse to list the AD attribute content. From a WinXP client, everything should work in both cases.
I know that this is perhaps not a regular case of a netlogon share, but you never know ... and it's strange anyway (or might have other side-effects) !
Regards,
Andy
|
|
Top
|
|
|
|
Moderator: Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 323 anonymous users online.
|
|
|
