VBS Script Question RRS feed

  • Question

  • Hello,

    We just recently setup our WDS and MDT server and everything seems to be working great. The one issue I am having is with an installed application (VBS script). The script creates a few folders and run an .exe which all works great. The issue I am having is with the script calling a .reg file that is in our DeploymentShare directory. The script will run fine after the imaging process and does exactly what it needs to. However, it always skips this step during imaging. Any suggestions?

    This is the command that is having issues:

    sRegFile = "\\SERVER\DeploymentShare$\Scripts\Custom\PROGRAM.reg"

    oShell.Run "regedit.exe /s " & Chr(34) & sRegFile & Chr(34), 0, True

    I had originally had this in a separate batch file to call the registry setting, but I had troubles with it working. So I thought I would just add it to the current VBS script since it installs the program first, then this is the configuration.

    Tuesday, July 1, 2014 3:13 PM

All replies

  • yes, trying to debug command line actions is a pain, since you dont see the screen output. If I have something with complicated output, or error codes I need to catch, I'll use Exec instead of Run

    If you use a WSF file and link it to ZTIUtility, you can log output to the BDD.log, or you can display it on screen, or create a text file somewhere if you'd rather.

    I'm assuming from your post that you have a decint grasp of vbscript, I've only included a fragment of code for example. The oLogging lines are only valid if you use a WSF linked to ZTIUtility.vbs:

    oLogging.CreateEntry "===Beginning reg import=== ", LogTypeInfo
    sRegFile = "\\SERVER\DeploymentShare$\Scripts\Custom\PROGRAM.reg"
    strCMD = "regedit.exe /s " & Chr(34) & sRegFile & Chr(34)
    oLogging.CreateEntry "Running " & strCMD, LogTypeInfo
    Set ObjExec = oShell.Exec(strCMD)
    	strFromProcess = ObjExec.StdOut.ReadLine()
    Loop While Not ObjExec.Stdout.atEndOfStream
    strExitCode = ObjExec.ExitCode
    'oShell.Popup strFromProcess, 10, "Status", 64 'uncomment for 10 second onscreen display popup
    oLogging.CreateEntry "Output text = " & strFromProcess, LogTypeInfo
    oLogging.CreateEntry "Exit code = " & strExitCode, LogTypeInfo
    oLogging.CreateEntry "===Ending reg import=== ", LogTypeInfo

    • Edited by JoeZeppy Tuesday, July 1, 2014 7:47 PM
    Tuesday, July 1, 2014 7:44 PM
  • I actually know VERY little about VBS scripting. I'm in the learning process. Some of this was what I edited from a previous script. The script that I pasted was what I found from "Googling" how to import a .reg file with VBS script. I actually do not need to log anything, if that's possible. All I need the script to do is run the .reg file which will create the registry settings I need for WinSCP. I'm assuming I'm making this far more difficult than I needs to be. Sorry for the rookie request.
    Tuesday, July 1, 2014 7:53 PM
  • Well, you kinda do, since something is happening to your regedit command, but you don't know what. :)

    a simpler way to determine what's going on would be to put "cmd /k " in front of your regedit command. That will open it in a separate command window, and everything will stop until you close it. If regedit is throwing an error, it should be readable there.

    I guess misread your post. It sounded like you said you had a script that was performing an app install and you added these lines to it, but they weren't working. Its possible that the task itself isnt running because of some syntax error. Is there any indication in the bdd.log what is happening at this point?  What did you use for a command line when you call the script?

    • Edited by JoeZeppy Tuesday, July 1, 2014 8:35 PM
    Tuesday, July 1, 2014 8:34 PM
  • I will try the cmd /k command to see if it is throwing any errors. The beginning of the script does install a program. Well, technically it creates folders, and calls another vbs script that installs the program:

    Set objFSO = CreateObject("Scripting.FileSystemObject")
    Set oShell = CreateObject("Wscript.Shell")
    On Error Resume Next

    If Not objFSO.FolderExists("c:\Lansweeper\") Then
        objFSO.CreateFolder ("c:\Lansweeper\")
        objFSO.CreateFolder ("c:\Lansweeper\depot\")
        objFSO.CopyFile "lspush.exe", "C:\Lansweeper\"
        If objFSO.FolderExists("C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\") then
            objFSO.CopyFile "LansweeperWinSCP.vbs", "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\"
        ElseIf objFSO.FolderExists("C:\Documents and Settings\All Users\Start Menu\Programs\Startup\") then
            objFSO.CopyFile "LansweeperWinSCP.vbs", "C:\Documents and Settings\All Users\Start Menu\Programs\Startup\"
        End If    
    End If

    Tuesday, July 1, 2014 8:41 PM
  • The plot thickens. the good old On Error Resume Next command. Good for keeping the trains running on time, bad if you actually want to get where you're going.

    On error Resume Next tells the script to ignore any errors and keep plowing through. So if something is causing an issue that would halt the script, no errors will be displayed.  've had people ask me to look at a script they've been pounding away at for hours. I rem out On Error Resume Next, and the answer is immediately obvious.

    In addition to running "cmd /k regedit" try temporarily commenting out On error Resume Next. You may just have a typo somewhere.

    • Proposed as answer by Vik Singh Wednesday, July 2, 2014 8:34 AM
    Tuesday, July 1, 2014 8:51 PM
  • I commented out the "On Error Resume Next" and added cmd /k:

    cmd /k oShell.Run "regedit.exe /s " & Chr(34) & sRegFile & Chr(34), 0, True

    The script ran in it's entirety with no errors. However the reg file still didn't take.

    Thanks again for all your help.

    Tuesday, July 1, 2014 9:24 PM
  • thats incorrect, should have been:

    oShell.Run "cmd /k regedit.exe /s " & Chr(34) & sRegFile & Chr(34), 0, True

    You're telling me the script didn't crash when you added cmd /k in front of oShell.Run? Because it should have.

    How are you calling the script in the task sequence? Do you have it as an application? a Run command Line step? You never said if you were able to find the step in the bdd.log to see if it listed any errors there.

    Wednesday, July 2, 2014 5:40 PM
  • No, it didn't crash. It ran in it's entirety with no errors. Did the same thing when I edited the cmd /k command. I have it setup as an application.

    Where would I find the bdd.log? I checked in %WINDIR%\Temp, but it wasn't there.

    I'm sure it's likely something I have setup wrong. I am also having an issue with the following command in MDT as well. I tried to set this up as an application.

    cmd.exe /c "RightfaxInstall.bat"

    Wednesday, July 2, 2014 8:52 PM
  • I'm sorry, I replied the other day, but apparently it was never posted.

    Read the below link to learn about logs. You really cant progress until you learn how to evaluate what your deployment is doing, and for that you need the logs.


    Monday, July 7, 2014 6:04 PM
  • My first thought when viewing this sample is to warn about calling scripts with hard coded network paths, How do we know for sure that the MDT scripts have access to these *.reg files over the network.

    The recommended solution is to keep these files on your MDT deployment share so the files are available relative to %DeployRoot%, or better yet, make an application package with the *.reg files and make the command line: "regedit.exe /s Program.reg".

    If you must call over the network,  use the ValidateConnection function:

    oUtility.ValidateConnection "\\Server\Share\Path\File.reg"

    that will force MDT to to use your cached credentials to connect to the share.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, July 8, 2014 3:50 PM
  • Well he is calling it from the deployment share:

    sRegFile = "\\SERVER\DeploymentShare$\Scripts\Custom\PROGRAM.reg"

    Using "%SCRIPTROOT%\Custom\PROGRAM.reg" probably would be better, but there seems to be something more basic going wrong. Hard to say what given the information at hand, but it seems as if the task isn't even running.

    Could also as you say be a problem with authentication, or path access, or a typo in the command. That was my initial comment, that running command lines with no way to capture the output can be an exercise in frustration.

    • Edited by JoeZeppy Tuesday, July 8, 2014 8:31 PM
    Tuesday, July 8, 2014 8:31 PM