One of the first things I learnt to do in powershell was to search AD. I could search in VB but there were a few quirks and limitations that gave me the incentive to take the leap in to PS. That and I had just started a new job supporting a large financial AD environment where we had to do a lot of data capture across multiple domains!
As anyone would, I looked at the way VB works and tried to convert it. Here is a direct translation of VB to PS in terms of searching AD ...
VB Script :
And there we have it, how to write VB in powershell! Actually there is more to powershell than using the same tools that you would use in VB. Here is where one of my resource links comes in handy ... let’s explore .net.
Where we would use the ADODB commands of old, they can be replaced with the .net object :
System.DirectoryServices.DirectorySearcher()
Which can be used in the following way (note this is a one line command, it may have wrapped on to multiple lines in this blog) :
You may see a similarity to the commandtext line in the ADODB way of connecting. I have specifically used the “constructor” in the .net class that accepts 4 arguments to match ADODB as closely as possible. You can create an empty object and populate the options later. See this link for all available constructors.
The LDAPdomain needs to be a DirectoryEntry object, and the other 3 need to be strings. The strings are pretty easy, but how do I get a DirectoryEntry object? The answer is there are many ways, it all depends where you are in your script and what objects you have. When you only have an LDAP path to the entry you want to retrieve, the most standard way is to call the .net class as we did with the $Searcher (again, one line command) :
There is, however, a neat little shortcut in powershell which you can use :
Obviously, you have to define this prior to creating the searcher so at the moment, using the same options as our VB example our script looks like this :
We have set up the searching mechanism, now let’s run the search...
... and loop through the results using a foreach cmdlet :
Note, the use of $object.properties.name rather than $object.name. I have fallen foul a few times to this and then was very confused to why I was not getting any values back.
So, the complete script :
Quite neat and tidy! That’s it for part 1, Part 2 will take things a bit further by looking into pulling information from AD rather than hard coding variables, other options you can specify and how to deal with certain types of values returned.
As anyone would, I looked at the way VB works and tried to convert it. Here is a direct translation of VB to PS in terms of searching AD ...
VB Script :
Set objConnection = CreateObject("ADODB.Connection")which converts to :
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand = CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.CommandText = "<LDAP://dc=other,dc=com>;(objectclass=user);name;subtree"
Set objRecordSet = objCommand.Execute
If objRecordset.RecordCount > 0 Then
objRecordSet.MoveFirst
Do Until objRecordSet.EOF
wscript.echo objRecordSet.Fields("name")
objRecordSet.MoveNext
Loop
End If
objConnection.Close
$objConnection = New-Object -comObject "ADODB.Connection"
$objCommand = New-Object -comObject "ADODB.Command"
$objConnection.Open("Provider=ADsDSOObject;")
$objCommand.ActiveConnection = $objConnection
$objCommand.CommandText = "<LDAP://dc=other,dc=com>;(objectclass=user);name;subtree"
$objRecordSet = $objCommand.Execute()
if ($objRecordSet.pagesize -gt 0){
Do {
$objRecordSet.Fields.item("name") | Select-Object Value
$objRecordSet.MoveNext()
}
Until ($objRecordSet.eof)
}
$objConnection.Close()
And there we have it, how to write VB in powershell! Actually there is more to powershell than using the same tools that you would use in VB. Here is where one of my resource links comes in handy ... let’s explore .net.
Where we would use the ADODB commands of old, they can be replaced with the .net object :
System.DirectoryServices.DirectorySearcher()
Which can be used in the following way (note this is a one line command, it may have wrapped on to multiple lines in this blog) :
$Searcher = New-Object System.DirectoryServices.DirectorySearcher("LDAPdomain", "LdapQuery","properties","searchscope")
You may see a similarity to the commandtext line in the ADODB way of connecting. I have specifically used the “constructor” in the .net class that accepts 4 arguments to match ADODB as closely as possible. You can create an empty object and populate the options later. See this link for all available constructors.
The LDAPdomain needs to be a DirectoryEntry object, and the other 3 need to be strings. The strings are pretty easy, but how do I get a DirectoryEntry object? The answer is there are many ways, it all depends where you are in your script and what objects you have. When you only have an LDAP path to the entry you want to retrieve, the most standard way is to call the .net class as we did with the $Searcher (again, one line command) :
$LDAPdomain = New-Object System.DirectoryServices.DirectoryEntry('LDAP://dc=other,dc=com')
There is, however, a neat little shortcut in powershell which you can use :
$LDAPdomain = [ADSI]('LDAP://dc=other,dc=com')
Obviously, you have to define this prior to creating the searcher so at the moment, using the same options as our VB example our script looks like this :
$LDAPdomain = [ADSI]('LDAP://dc=other,dc=com')
$Searcher = New-Object System.DirectoryServices.DirectorySearcher($LDAPdomain,"(objectclass=user)","name","subtree")
We have set up the searching mechanism, now let’s run the search...
$Results = $Searcher.FindAll()
... and loop through the results using a foreach cmdlet :
foreach ($Object in $Results){
$Object.Properties.name
}
Note, the use of $object.properties.name rather than $object.name. I have fallen foul a few times to this and then was very confused to why I was not getting any values back.
So, the complete script :
$LDAPdomain = [ADSI]('LDAP://dc=other,dc=com')
$Searcher = New-Object System.DirectoryServices.DirectorySearcher($LDAPdomain,"(objectclass=user)","name","subtree")
$Results = $Searcher.FindAll()
foreach ($Object in $Results){
$Object.Properties.name
}
Quite neat and tidy! That’s it for part 1, Part 2 will take things a bit further by looking into pulling information from AD rather than hard coding variables, other options you can specify and how to deal with certain types of values returned.
Comments
Post a Comment