How would I use winbatch to search LDAP with a scope of OneLevel(versus Subtree)

[galaara98]

I have a certain use case where i need to search an LDAP service, but need to use a Search Scope of onelevel
I know how to do it in PowerShell, and most LDAP GUIs, but the Winbatch AD extender seems to default to subtree, without a way to control that
(admittedly, in 15 years of LDAP/AD administration.. i probably have needed to NOT use subtree only a handful of times.. so i can see why)

Aaron

[td]

You can use an ADO search.  Here is an untested code snippet I found on my workstation

Code (winbatch) Select Expand


; Use ADO to QUERY Active Directory
ADS_SCOPE_SUBTREE = 2  ; or use ADS_SCOPE_ONELEVEL  = 1
objConnection = CreateObject("ADODB.Connection")
objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open("Active Directory Provider")
objCommand.ActiveConnection = objConnection
objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

; Domuserpath is the full ADSI path to searches start point in the directory.
objCommand.CommandText = "SELECT Name FROM '": domusrpath :"' WHERE objectCategory='group'"
objRecordSet = objCommand.Execute()
grouplist = ""
If objRecordSet.RecordCount
   objRecordSet.MoveFirst
   While !objRecordSet.EOF
       groupname = objRecordSet.Fields("Name").Value
       grouplist = grouplist : @TAB: groupname
       objRecordSet.MoveNext
   EndWhile
   AskItemlist(userid: ' Group list', StrTrim( grouplist ), @TAB, @UNSORTED, @SINGLE )
Else
   Pause(userid: ' Group list', 'No records found')
EndIf


There are more examples in the Tech Database. You can mix and match COM based and extender based access to Active directory so that is not a worry.

IIRC, we have never has a request to add one level search capabilities to dsFindPath before.  Will have to add it the feature request list. 

[galaara98]

Thanks!

So, i did this solution with ADO, but decided i didn't like that technology. 
I started to write this in Winbatch + .NET, but decided maybe that was over doing what you had already written

I stumbled upon this Winbatch tech support article http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+Tutorials+ADSI.txt
which appears to be a Extra info, more explanation, and some of the "why" behind the official Winbatch ADSI Extender.

In this article there is a paragraph (Emphasis Added by ME):

=== BEGIN SNIP OF ARTICLE ===
ADSI and COM

When the ADSI extender was written we really didn't have a feel for how people would use it. We opted to make it easy to use with as few steps as possible. We felt that it was the only way to give it some advantage over VBS or VB and COM. One way we did this was to remove the need save cached object changes to the Directory Service. The extender does this in the background every time you make a change to a property. While this makes ADSI a little less error prone and easier to use, it also adds a lot of network traffic. (With straight COM objects you have to tell ADSI to update the DS with your cached changes or they are lost.)

The problem is that the extender is prone to timing issues because of all the extra network traffic it generates. We may be making changes to the extender to work around this problem.
But right now I recommend using COM whenever possible.

Sample code to get and set a user full name:

newname = "Fred Flintstone"
objUser = ObjectGet("WinNT://yourdomain/UserID")
origname  = objUser.FullName
ret = AskYesNo('Change Users Full Name', StrCat('Are you sure you want to change the users full name from ',origname,' to ',newname,'?'))
If ret == @YES
   objUser.FullName = "Users Name"
   objUser.SetInfo()
EndIf
objUser = ""
Message('Changed Users Full Name', StrCat('Changed ',origname,' to ',newname))
Exit

Microsoft offers a tool called ADSI Scriptomatic. It is designed to help you write ADSI COM scripts; that is, scripts that can be used to manage Active Directory. The ADSI Scriptomatic also teaches you an important point about ADSI scripting: like WMI, there are consistent patterns to ADSI scripts.

http://www.microsoft.com/downloads/details.aspx?FamilyId=39044E17-2490-487D-9A92-CE5DCD311228&displaylang=en
=== END OF SNIP FROM ARTICLE ===

So is it still true that if time/skills/cost aside, using Winbatch + COM to call ADSI is preferred over Winbatch + Extender, unless simple is one of the primary goals of the code?

Aaron

[td]

The article probably overstates the case a bit and the ADSI extender has evolved some since that article was written.  If you like using the extender and it is providing you with the functionality you need then by all means use it.  It is still supported and we do add new features on occasion.

As previously mentioned you can mix the technologies, including dotNet, to fill in a gap in the functionality in one technology with another technology.