[ADSI Extender] Error on special character in object path

[koffie]

I'm working on a tool that needs to loop through all the users in our AD.
Currently I have the following code:

Code Select Expand


; Get a list of users
; Write out user properties to a .csv file
AddExtender("wwads44i.dll")

ServerDn=dsGetProperty("LDAP://rootDSE", "serverName")
ServerName=ItemExtract(1, ServerDn, ",")
ServerName=ItemExtract(2, ServerName, "=")
ServerDn=dsGetProperty("LDAP://rootDSE", "defaultNamingContext")
ServerPath="LDAP://" : ServerName : "/" : ServerDN

handle = FileOpen("c:\temp\ADSI.txt","WRITE")

users_in_OU = dsFindPath( ServerPath, "(&(objectcategory=Person)(objectclass=user))" )
count = ItemCount( users_in_OU, @TAB )
For xx = 1 To count
   ; User container object's path
   UserPath = ItemExtract( xx, users_in_OU, @TAB )
   FileWrite( handle, UserPath)
   ; Get properties.
   sDisplayName = dsGetProperty( UserPath, "cn" )
   sFirstName = dsGetProperty( UserPath, "givenName" )
   sLastName = dsGetProperty( UserPath, "sn" )
   sAlias = dsGetProperty( UserPath, "uid" )
   sSMTPAddr = dsGetProperty( UserPath, "mail" )
   FileWrite( handle, sFirstName : "," :sLastName : "," : sAlias : "," : sSMTPAddr )
Next

FileClose(handle)
Run("c:\temp\ADSI.txt", ""))

Exit


Add some point, the loop crash with the following error:  "1063: Object does not exist".
After debugging to find the specific user it's crashing on, I found that the user has a special character in his name : EtiÃ'‘nne
The ADSI Extender gives me the following path : LDAP://xxx/CN=Eti?nne xxx,OU[..],DC=local (I have anonymised some info in this path)
So, it turns out it cannot read the 'Ã'‘' character in AD. It is not possible (wanted) to change the name.
Any idea on how to bypass this problem?

[ChuckC]

It sounds like the ADSI extender's functions are not fully aware of Unicode.  Unless there is some sort of update to the extender that resolves the issue, I would hazard to guess that the next best alternative would be to try the ADSI COM interfaces instead.  It may turn out that WinBatch's support for Unicode is more complete when it comes to working with COM objects and their interface methods.

[td]

It isn't so much a question of the extender being Unicode aware as it is the fact that the extender, like most WIL extenders, is an ANSI dll that only supports ANSI or DBCS input and output.  This works fine as long as the code page of the thread running the extender has conversions for the encountered Unicode characters.  When the current code page does not have a conversion, you get that wonderful question mark character.

As suggested you can try either the WinBatch COM or dotNet subsystems as both provide access to directory service objects.  WinBatch will preserve object or class member strings as Unicode characters for most operations. 

[stanl]

As suggested you can try either the WinBatch COM or dotNet subsystems

Question: could you have both worlds?  Use the Extender to gather the encoded string, pass it to GetEncoding() from System.Text.Encoding, read that with System.IO.File then use methods to ReadAllText() then WriteAllText(). Otherwise just use System.DirectoryServices and keep the whole thing in the CLR. 

[td]

In general, there is nothing wrong with mixing the two but in this particular case you would need to stick with System.DirectoryServices exclusively to solve the problem.