- Category: Programming Guides & Tutorials
- Published on Thursday, 14 March 2013 13:04
- Written by Vinayaga Moorthy
In other words, it’s very common for users to have CNs similar to Myer, Ken. That’s great when you’re working in Active Directory Users and Computers, but not so great when you’re trying to manage these users with ADSI scripts. For example, this script – which attempts to bind to the Myer, Ken user account – will fail with an invalid syntax error:
Set objUser = GetObject("LDAP://CN=Myer, Ken,OU=Accounting,DC=fabrikam,DC=com")
So what’s the problem here? Well, it’s not with the user’s CN; Myer, Ken is perfectly valid. The problem is that when you write a binding string in ADSI the comma is used to separate the individual values within the ADsPath. When we write CN=Myer, Ken,OU=Accounting, our script thinks CN=Myer is the first value, and Ken is the second value. That’s because of the comma between Myer and Ken. And because Ken by itself doesn’t make any sense within an ADsPath, the script blows up.
So what do you about that? As it turns out, the comma is a reserved character when it comes to Active Directory paths.
For most reserved characters, you can use them in binding strings simply by placing a backslash (\) in front of the characters. This script will successfully bind to the Myer, Ken user account and report back the user’s CN:
Set objUser = GetObject("LDAP://CN=Myer\, Ken,OU=Accounting,DC=fabrikam,DC=com")
Again, note how the user CN is specified: CN=Myer\, Ken,OU. After Myer we place a backslash and a comma, then we continue with the rest of the path (including the blank space that separates Myer, and Ken).
Basics of VBScript can be found here
blog comments powered by Disqus