user action scripts

[googoo]

I'm sure there is an easy fix for this, but I'm no scriptor and can't find the answer...when running either the unlock.vbs or changepassword.vbs, we get the attached error. Help?

[mdotadmin]

Is the updated it-userdetail.aspx available for download?

[Hemoco]

mdotadmin wrote:
Is the updated it-userdetail.aspx available for download?

Please contact us by e-mail.

[googoo]

Lansweeper admins provided me with a new "it-userdetail.aspx" file, which correctly processes our user names.

[mdotadmin]

If it is any help, you can use a dsquery command to return a correctly formatted user dn.
"dsquery user domainroot -o dn -samid UserLogonName -limit 0"
Where UserLogonName is the account logon id.
If the returned user dn can be piped into the unlock.vbs script, it should work. Too bad I don't know how to do that.
dsquery ships with Server 2003 and above. I think it is also part of the Server Resource Kit. It will run from a Windows XP and above workstation. It works correctly from my Windows 7 workstation.

[Hemoco]

I know, but please send me your specific details.
You can use lansweeper@hemoco.com

[googoo]

See post
#7 Posted : Tuesday, April 27, 2010 7:13:21 AM, I included the "message from webpage" which states what LS is attempting to do. It is finding the correct CN, it's just that the CN includes a comma that the script is not addressing correctly.

Here is an example of the problem (I don't know how to fix the script to do what they describe here) pulled from http://blogs.technet.com/heyscriptingguy/archive/2004/11/05/how-can-i-work-with-a-cn-that-has-a-comma-in-it.aspx :

Hey, Scripting Guy! My user accounts have commas in their CN attributes; for example, Myer, Ken. How do I bind to those user accounts using a script? I always get the error message “An invalid dn syntax has been specified.”

-- GT
SpacerHey, Scripting Guy! AnswerScript Center

Hey, GT. For those of you who don’t know, the CN attribute is the attribute that uniquely identifies a user account within an OU or other Active Directory container. (You can have more than one Myer, Ken in your domain, but you can have only a single Myer, Ken in, say, the Accounting OU.) The CN attribute is also the attribute used to display user names in Active Directory Users and Computers. When you add a user from within Active Directory Users and Computers, one of the fields you typically fill out is labeled Full Name (and then, for some reason, when you later view the user account properties, this same field gets re-labeled Display Name). Administrators like to specify CNs (full names) using the last name, first name syntax; that way, when they look at an OU all the users are arranged in alphabetical order by last name. (If you specified Ken Myer as the full name, users will be arranged in alphabetical order by first name.)

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")Wscript.Echo objUser.CN

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. (Other reserved characters include the semicolon, the plus sign, the backslash, and the left and right angle brackets. For a complete list, see the Lightweight Access Directory Protocol documentation on MSDN.)

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")Wscript.Echo objUser.CN

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).

[Hemoco]

Could you post or mail me the complete CN please.
And what is shown on the webpage.

[googoo]

Upgraded to latest version this am (ver 4.0.0.24), ran unlock.vbs to unlock user account, still get same error-->"An invalid dn syntax has been specified". The script it is trying to run still doesn't account for the comma in the CN.

[Hemoco]

Yes, the latest update fixes this.