none
VBS scripts no longer run

    Question

  • I have several vbs scripts that I used at a former workplace. The scripts expose hidden attributes in Active Directory where we can then tie those fields to known values in individual AD accounts. I am using the exact same scripts at my new work that I used at my old work, but they do not run. Instead, I am getting the "subscript out of range" errors. What I don't understand is that these same scripts are still running/working at my former workplace-the admins use them every day!

    Note: These scripts reside in a c:\bin directory. Each script is referenced in adsiedit>configuration>displayspecifiers>409>user-Display settings accordingly and have already been added appropriately. I can right-click any user account and I see the exposed attributes, but the scripts won't run to do the actual work in the background.

    At first I thought it was permissions, but I verified those with the other admins. When I searched these forums for the subscript error, I saw references to empty/null array stuff, much of which I don't understand. If anyone could help, it would be appreciated. The code in question:

    Dim oVar
    Dim oUsr
    Dim tmp
    Set oVar = Wscript.Arguments
    Set oUsr = GetObject(oVar(0))
    tmp = InputBox("Employee ID is currently: " & _ 
    	oUsr.employeeID & vbCRLF & vbCRLF & _
    	"If you would like enter a new number or modify " & _
    	"the existing number, enter the new number in the textbox below")
    if tmp <> "" then oUsr.Put "employeeID",tmp
    oUsr.SetInfo
    Set oUsr = Nothing
    WScript.Quit

    Wednesday, March 14, 2012 1:24 AM

Answers

  • Dear David,

                   It seems that your contex menu definition does not have a serial number, i wonder if this could be the reason for this behavior ...

                   If you have nothing else to try, see if you can modify the command adding a serial number right before the first comma, and then try again.


    Best Regards, Marianok

    Saludos, MarianoK

    Disclaimer: While I do my best to make sure everything I post is accurate and safe, I’m certainly not perfect so all this information is provided "AS IS" with no warranties or guarantees and confers no rights. Any suggested steps or code provided should be done under your own risk, I take no responsibilities if your system blows, the universe stops spinning, o nor for any other adverse consequence the information on this code might cause directly or indirectly.

    Aclaración: Aunque hago lo posible por verificar que todo lo que posteo es correcto y seguro, Yo ciertamente no soy perfecto y puedo cometer errores, por lo tanto esta informacion es provista "AS IS" / "Como Está" sin garantía alguna y no le confiere ningún derecho. Cualquier instrucción descripta o código incluido deben ser empleados bajo su propia responsabilidad y bajo su propio riesgo. No me hago responsable si sus datos se dañan, su si

    • Marked as answer by David Bolton Thursday, March 15, 2012 11:04 PM
    Thursday, March 15, 2012 11:54 AM
  • Well, wouldn't you know...your suggestion worked! By simply adding a number to the beginning of each line:

    2,&Employee ID,\\dc\bin\eid.vbs

    It makes each script run as prescribed. Thank you thank you thank you!

    Well isn't that strange.  I bet it is not the number but addin a number caused it to be rewritten which may have caused the entry to be redeployed in some way.  This may have caused it to be picked up correctly. 

    I bet you can remove the number and it will still work.


    ¯\_(ツ)_/¯

    • Marked as answer by David Bolton Friday, March 16, 2012 4:17 PM
    Thursday, March 15, 2012 11:30 PM

All replies

  • Are you looking to port this to PowerShell?  Also, are you looking to keep a visual popup or would a console work?
    Wednesday, March 14, 2012 2:14 AM
  • Documentation I found indicates the *.vbs file should be saved in the Windows System folder (c:\Windows\System32). However, that doesn't account for your error. It seems the script is running since you got an error message (if the right script is running). Does the error message refer to line 5? The only statement that could raise a subscript out of range error is on line 5:

    Set oUsr = GetObject(oVar(0))

    oVar(0) is the first argument passed to the script. Documentation indicates the first argument should be the ADsPath of the user object. The second argument, oVar(1), should be the class of the object (user), but that is not used here. The error means the script ran, but no arguments got passed to the script. At that point in the script, no permissions are required, except to run the script. I'm referring to this documentation:

    http://technet.microsoft.com/en-us/library/bb727064.aspx

    When you specify the vbscript, do you also specify the path, or is c:\bin on your path? I suspect the documentation uses the system32 folder because it is on the path. I guess I'm worried that the script that runs isn't the one you think it is.

    Minor point, but I would revise the script to only invoke the SetInfo method if the variable tmp is not blank. For example:

    if tmp <> "" then
        oUsr.Put "employeeID", tmp
        oUsr.SetInfo
    End If

    -----


    Richard Mueller - MVP Directory Services

    Wednesday, March 14, 2012 2:31 AM
    Moderator
  • Dear David,

                      Looks like the script should be invoked with the user's LDAP path as a parameter.

                      Make sure you are doing so and that you are enclosing the string in quotes, something like:

    cscript setEmployeeID.vbs "LDAP://cn=DBOLTON,ou=IT Department,dc=mydomain,dc=com"

                      Also, make sure that you have the correct AD Path.


    -----------------

    Best Regards, Marianok

    Disclaimer: While I do my best to make sure everything I post is accurate and safe, I’m certainly not perfect so all this information is provided "AS IS" with no warranties or guarantees and confers no rights. Any suggested steps or code provided should be done under your own risk, I take no responsibilities if your system blows, the universe stops spinning, o nor for any other adverse consequence the information on this code might cause directly or indirectly.

    Wednesday, March 14, 2012 1:12 PM
  • It is likely that the script is being called with no parameter as input.  If there are no parameters in wscript.arguments then you get a subscript out of range when you try to access the array as you do in line 5 of your script.

    Check to see how the script is being called.

    hth,

    jrussell97

    Wednesday, March 14, 2012 6:16 PM
  • I have several vbs scripts that I used at a former workplace. The scripts expose hidden attributes in Active Directory where we can then tie those fields to known values in individual AD accounts. I am using the exact same scripts at my new work that I used at my old work, but they do not run. Instead, I am getting the "subscript out of range" errors. What I don't understand is that these same scripts are still running/working at my former workplace-the admins use them every day!

    You must post the exact and complete error mesage.  Just posting part of the error with a long explanation is of no help.

    YOu shoiul also post teh exact commandlineyou are using when you get the error such as:
    cscript myscript.vbs "LDAP://cn=user01,ou=somou,dc=doman,dc=com"


    ¯\_(ツ)_/¯

    Wednesday, March 14, 2012 6:51 PM
  • I get this error if I run >cscript employeeid.vbs without sending it any parameters, or if I send it "LDAP://cn=user01,ou=somou,dc=doman,dc=com"

    I have already done the work to expose these attributes so they show up on a right-click context menu when working with user accounts. All that's left is to get the script to work in the background so the VBScript Window pops up so I can enter the data to populate those fields. I never needed to run this (or the other scripts) from the command line.

    edit: the c:\bin is in my path variable too.

    I will work on this more tomorrow. Thanks everyone for posting as I have several things to look into given the responses.



    Wednesday, March 14, 2012 11:18 PM
  • I get this error if I run >cscript employeeid.vbs without sending it any parameters, or if I send it "LDAP://cn=user01,ou=somou,dc=doman,dc=com"

    I have already done the work to expose these attributes so they show up on a right-click context menu when working with user accounts. All that's left is to get the script to work in the background so the VBScript Window pops up so I can enter the data to populate those fields. I never needed to run this (or the other scripts) from the command line.

    edit: the c:\bin is in my path variable too.

    I will work on this more tomorrow. Thanks everyone for posting as I have several things to look into given the responses.



    It is now clear that you are not telling =us everything.  YOu are not executing a script at teh commandline but are using some third party tool that you have not told us about.

    What tool is it teh right clicking brings up a list of user accounts. 

    It sounds like you are trying to run this in PowerGUI.

    Please give us all of teh information including the exact error message,  Yu also MUST post the exact scritp you are rtunning and not some pseudo verion of teh script. Yuo camlim ot have run cscript employeeid.vbs  but the erro shows you have run ands errored in a completely different script. - eid.vbs. This looks like the end of the employeeid.vbs.


    ¯\_(ツ)_/¯

    Wednesday, March 14, 2012 11:50 PM
  • I believe he runs the script by right clicking the user object in ADUC. I'm not sure exactly what he does then. He specified the script in displaySpecifiers for User-Display. I haven't done this, so I don't know how it works, but supposedly when you do this two parameters are passed to the script. The first is the ADsPath of the user object you select, and the second is the class of the object. I gathered this from this link:

    http://technet.microsoft.com/en-us/library/bb727064.aspx

    Obviously, if this is the way it's supposed to work, it is not working now for David. I think we need to know the exact steps he uses to run the script.


    Richard Mueller - MVP Directory Services

    Thursday, March 15, 2012 1:35 AM
    Moderator
  • I believe he runs the script by right clicking the user object in ADUC. I'm not sure exactly what he does then. He specified the script in displaySpecifiers for User-Display. I haven't done this, so I don't know how it works, but supposedly when you do this two parameters are passed to the script. The first is the ADsPath of the user object you select, and the second is the class of the object. I gathered this from this link:

    http://technet.microsoft.com/en-us/library/bb727064.aspx

    Obviously, if this is the way it's supposed to work, it is not working now for David. I think we need to know the exact steps he uses to run the script.


    Richard Mueller - MVP Directory Services

    My guess to but how dows employeeid.vbs equate to eid.vbs?

    We are missing crucail information.  f this is the case the aDSPath is what the script needs. AdsPath is 'LDAP://" + dn.


    ¯\_(ツ)_/¯

    Thursday, March 15, 2012 1:44 AM
  • Richard - by the way - I agree with your post.

    ¯\_(ツ)_/¯

    Thursday, March 15, 2012 1:59 AM
  • Richard,

    You are correct, this is exactly how I execute the script. I have edited the adminContextMenu attribute under the user-Display setting. For each added right-click context menu addition, there exists a script-one per line, which in this case reads:

    ",&Employee ID,\\dcserver\bin\eid.vbs"

    Normally, when you right-click the user account and select "Employee ID",  it pops up the vbscript window where I can then enter or alter the data. I see all of my added context menu entries, however they do nothing when I click on them. By running the script from the command line, it gives the error aforementioned. 

    I can't help but think this is leading back to a permissions issue and/or something else I've missed.

    @jrv, my apologies for the confusion. eid.vbs and employeeid.vbs are one in the same.

    Thanks to all for the assistance. I will dig into this further at work tomorrow.

    Thursday, March 15, 2012 3:14 AM
  • There is an awful lot of misdirection at worrk here.  Remember that we are at the mercy of whatever text you decide to post.  If your statements are incomplete or misleading then we are all at a complete disadvantage.

    Any attempt on your part to be accurate and complete will be helpful. Any attemp to be terse and limited will make it impossible to understand your issue.

    Please start by telling us what to tool you are using and what, if any, modifications you have made to the tool, its environment or the scripts you may have made.


    ¯\_(ツ)_/¯

    Thursday, March 15, 2012 3:33 AM
  • Dear David,

                   It seems that your contex menu definition does not have a serial number, i wonder if this could be the reason for this behavior ...

                   If you have nothing else to try, see if you can modify the command adding a serial number right before the first comma, and then try again.


    Best Regards, Marianok

    Saludos, MarianoK

    Disclaimer: While I do my best to make sure everything I post is accurate and safe, I’m certainly not perfect so all this information is provided "AS IS" with no warranties or guarantees and confers no rights. Any suggested steps or code provided should be done under your own risk, I take no responsibilities if your system blows, the universe stops spinning, o nor for any other adverse consequence the information on this code might cause directly or indirectly.

    Aclaración: Aunque hago lo posible por verificar que todo lo que posteo es correcto y seguro, Yo ciertamente no soy perfecto y puedo cometer errores, por lo tanto esta informacion es provista "AS IS" / "Como Está" sin garantía alguna y no le confiere ningún derecho. Cualquier instrucción descripta o código incluido deben ser empleados bajo su propia responsabilidad y bajo su propio riesgo. No me hago responsable si sus datos se dañan, su si

    • Marked as answer by David Bolton Thursday, March 15, 2012 11:04 PM
    Thursday, March 15, 2012 11:54 AM
  • you might need to close and reopend the dsa.msc in order to refresh the changes to the serial number. 

    Best Regards, Marianok

    Saludos, MarianoK

    Disclaimer: While I do my best to make sure everything I post is accurate and safe, I’m certainly not perfect so all this information is provided "AS IS" with no warranties or guarantees and confers no rights. Any suggested steps or code provided should be done under your own risk, I take no responsibilities if your system blows, the universe stops spinning, o nor for any other adverse consequence the information on this code might cause directly or indirectly.

    Aclaración: Aunque hago lo posible por verificar que todo lo que posteo es correcto y seguro, Yo ciertamente no soy perfecto y puedo cometer errores, por lo tanto esta informacion es provista "AS IS" / "Como Está" sin garantía alguna y no le confiere ningún derecho. Cualquier instrucción descripta o código incluido deben ser empleados bajo su propia responsabilidad y bajo su propio riesgo. No me hago responsable si sus datos se dañan, su si

    Thursday, March 15, 2012 12:02 PM
  • JRV...not sure what you are missing here bud, but I've outlined the scenario pretty clearly. Up to this point, there has been no misdirection/confusion or terseness, except what you are obviously perceiving.

    I stated that I am interacting with Active Directory. No third party tools involved. I used adsiedit.msc to edit my user-Display settings to avail some context menus that would expose not-normally-seen attributes in AD while using ADUC. These are not new classifications and attributes, they already exist, I am just exposing them.

    These scripts execute properly at my old work domain running server 2008 R2, and the prior domain that was running server 2003. These scripts do not work on my current work domain which is running a mix of server 2003 and server 2008, soon to be all 2008.

    If you read the page that Richard posted, it outlines what should happen when you right-click a user account in ADUC.  Richard points out that the right-click should send the adspath and user object info, but it is not doing so. 

    As a test, I ran this script from the command line and received the error posted. I also tried sending parameters to the script, but that also does nothing as I believe the script is designed to work the way it is posted on that page Richard posted.

    So it's back to trying to figure out why the script is not running. I have the right-click options tied to these scripts, but the right-click does nothing. I will try to get back on this later today and report back.


    Thursday, March 15, 2012 7:30 PM
  • There are at least a hlf dozen tools that you could be talkig about.  This is the first time you have mentioned ADUC.

    For ADUC to wqork you need to have the appropriate extensoi software installed.  Have you verified that the extension DLL is loaded.  Ther are numerous of these too.  QUest, Microft and many others.

    All of these work in slightly different ways.

    You also failed to tell us why the emplyeeid script that you say you are runing shows up in the error message as eid.vbs.


    ¯\_(ツ)_/¯

    Thursday, March 15, 2012 7:37 PM
  • I managed to get this to work, but only on Windows Server 2008 R2. I created the following VBScript program:

    Option Explicit

    Dim objUser, strResponse

    Set objUser = GetObject(Wscript.Arguments(0))

    strResponse = InputBox("Employee ID currently: " & objUser.employeeID _
        & vbCrLf & "Enter a new value or cancel")

    If (strResponse <> "") Then
        objUser.Put "employeeID", strResponse
        objUser.SetInfo
    End If

    -----

    I saved this as \\MyServer\MyShare\EmployeeID.vbs. All users have read access to this share.

    Then using ADSI Edit I navigated to the object cn=User-Display,cn=409,cn=DisplaySpecifiers,cn=Configuration,dc=MyDomain,dc=com. In properties I viewed the contextMenu attribute of this object, then added the new entry:

    ,&EmployeeID,\\MyServer\MyShare\EmployeeID.vbs

    Now when I right click on any user in ADUC the menu includes the new entry "EmployeeID". On my Windows Server 2008 R2 DC when I select "EmployeeID" the script runs, but in a command console (no GUI). It displays the existing value of the employeeID attribute of the user. If I enter a new value, the attribute is updated. However, when I select the "EmployeeID" menu option on a Windows Server 2003 DC, an error message flashes by so quickly that I cannot read it.

    There needs to be better documentation on how this works.


    Richard Mueller - MVP Directory Services

    Thursday, March 15, 2012 10:04 PM
    Moderator
  • Under ADUC I set up a call on the menu.

    I created a vbs that has one line:

    MsgBox WScript.Arguments(0)

    The result is this:


    ¯\_(ツ)_/¯

    Thursday, March 15, 2012 10:33 PM
  • Original setup that works is this: ,&Employee-Number, C:\employee-number.vbs

    Using a local drive works correctly.

    Changing to this:

    ,&Employee-Number, \\server\share\employee-number.vbs

    fails.

    It appears that you cannot put your script on a share beceuse, most likely, it will violate delegation rules.  Store the script locally and it works as expected.

    Of course I could still be missing something.

    My original assumption was that you were trying to execute an ADUC extension.  FromRichards post I see you are just running the optional menu additions which will call almost any program you want to put on teh context menu.  It is interesting that it will no call anything on a share even if the share is on the local machine.  I never expected a local share to be caught up in teh 'delegation' restriction.  What is even more interesting is that all DCs are 'trusted' for delegation.

    Maybe the issue is that the accessing account also needs to be 'trusted'...


    ¯\_(ツ)_/¯


    • Edited by jrv Thursday, March 15, 2012 10:46 PM
    Thursday, March 15, 2012 10:42 PM
  • Further testing shows that the trust is not required.

    For some reason, after defining the menu item I needed to logoff and logon to get it to work correctly when the script was on a share.  The initial pointing aat the root of 'C' did not seem to require this,

    Here are the Microsft  rules on how to make this work: http://technet.microsoft.com/en-us/library/bb727064.aspx

    The above is an extensive explanation of how this works with numerous examples.  The whole bugaboo is very subtle and quite extensible. 

    Someone at MS stayed up nights to build this.


    ¯\_(ツ)_/¯

    Thursday, March 15, 2012 10:59 PM
  • @Mariano

    Well, wouldn't you know...your suggestion worked! By simply adding a number to the beginning of each line:

    2,&Employee ID,\\dc\bin\eid.vbs

    It makes each script run as prescribed. Thank you thank you thank you!


    Thursday, March 15, 2012 11:05 PM
  • Well, wouldn't you know...your suggestion worked! By simply adding a number to the beginning of each line:

    2,&Employee ID,\\dc\bin\eid.vbs

    It makes each script run as prescribed. Thank you thank you thank you!

    Well isn't that strange.  I bet it is not the number but addin a number caused it to be rewritten which may have caused the entry to be redeployed in some way.  This may have caused it to be picked up correctly. 

    I bet you can remove the number and it will still work.


    ¯\_(ツ)_/¯

    • Marked as answer by David Bolton Friday, March 16, 2012 4:17 PM
    Thursday, March 15, 2012 11:30 PM
  • I wondered why when I selected "Employee-ID" from my menu, the wording was slightly different from my script. Dug further and found I did this a year ago, except I called a *.cmd that ran a PowerShell script. This works fine on the Windows Server 2008 R2 DC. On the Windows Server 2003 DC it fails because I used the -File parameter when I called PowerShell, and this must not be supported in PowerShell V1. I didn't check before I tested, but the "Employee-ID" selection was there before I even started. I do not see it in the contextMenu attribute. There was just one entry, referring to a GUID, which I assumed was the default. I think the entry I added had no affect. I don't remember how I did this a year ago, or why it shows up as a GUID.

    In any case, my problem. The VBScript is probably fine. Adding the order-number makes some sense. I had tried it before I realized what was going on.


    Richard Mueller - MVP Directory Services

    Thursday, March 15, 2012 11:30 PM
    Moderator
  • Dear David,

                   It seems that your contex menu definition does not have a serial number, i wonder if this could be the reason for this behavior ...

                   If you have nothing else to try, see if you can modify the command adding a serial number right before the first comma, and then try again.


    Best Regards, Marianok

    Saludos, MarianoK

    Disclaimer: While I do my best to make sure everything I post is accurate and safe, I’m certainly not perfect so all this information is provided "AS IS" with no warranties or guarantees and confers no rights. Any suggested steps or code provided should be done under your own risk, I take no responsibilities if your system blows, the universe stops spinning, o nor for any other adverse consequence the information on this code might cause directly or indirectly.

    Aclaración: Aunque hago lo posible por verificar que todo lo que posteo es correcto y seguro, Yo ciertamente no soy perfecto y puedo cometer errores, por lo tanto esta informacion es provista "AS IS" / "Como Está" sin garantía alguna y no le confiere ningún derecho. Cualquier instrucción descripta o código incluido deben ser empleados bajo su propia responsabilidad y bajo su propio riesgo. No me hago responsable si sus datos se dañan, su si

    Maraina. The MS documentauion implies that a serial number is not required.  The number is also not a serial number but is the GUId orf an automation object for some entries. IN otheres it is an number that enforces an order on the menu. 

    I suspect that rewritng the entry may be what is fixing this as I have no issues with deploying scripts without a number.  I did notice that changes to the line may take a bit of time to actaully work.  Updating the schema is quick. (refresh) but the updates are slow to take even when there is only one DC.


    ¯\_(ツ)_/¯

    Thursday, March 15, 2012 11:35 PM
  • Dear David,

                      I'm glad it worked !!!

                      My guess is that the number is used as some kind of index or key (the documentation does state that, if used, it must be unique) to link the information to the action.


    Best Regards / Saludos, Marianok

    Disclaimer: This post, and all included code and information is provided "AS IS" with no warranties or guarantees and confers no rights. Try it at your own risk, I take no responsibilities.

    Aclaración: Esta publicación, y todo en código e información en la misma, es provista "AS IS" / "Como Está" sin garantía alguna y no le confiere ningún derecho. Pruebelo su propio riesgo. No asumo responsabilidad alguna.

    Friday, March 16, 2012 10:42 AM
  • @JRV,

    In previous deployments of these scripts, I did not have to enter a number in the user-Display attribute editor. So, I was curious as to why the numbering made the scripts works. As a test, I removed the numbering (total of four scripts I use) as you suggested, and they now still work as originally designed.

    I am a bit baffled as to why the numbering all of a sudden made these scripts work, and why now without the numbering, they still work. Odd goings on!

    Thanks again to everyone who posted!

    Friday, March 16, 2012 4:16 PM
  • @JRV,

    In previous deployments of these scripts, I did not have to enter a number in the user-Display attribute editor. So, I was curious as to why the numbering made the scripts works. As a test, I removed the numbering (total of four scripts I use) as you suggested, and they now still work as originally designed.

    I am a bit baffled as to why the numbering all of a sudden made these scripts work, and why now without the numbering, they still work. Odd goings on!

    Thanks again to everyone who posted!

    That is waht I suspected was happening.  SOmetimes values don't get written correctly for some reason.  By editing the value and changing anything the value gets fixed.


    ¯\_(ツ)_/¯

    Friday, March 16, 2012 4:28 PM