Scripting Question

VBS is not executed in a software deployment.

07/30/2015 1901 views

I have to deplay the Cisco Webex Produktivity Tools on about 30 machines. The command line for the MSI file is no problem, but I also have to copy certain files to Lotus Notes. As Notes isn't installed on all systems in the same installation path I have to read this before from the registry and to write it into a system variable %notespath%. This happens with a VB script

On Error resume next
OSArchitecture = ""
NotesPath = ""
dim objWMI, objOSList, oShell
Set oShell = CreateObject("WScript.Shell")
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set objWMI = GetObject("winmgmts:\\.\root\CIMV2") ' get os information
Set objOSList = objWMI.InstancesOf("Win32_OperatingSystem",48)
For Each objOSDetail In objOSList ' extract os name and version
        OSArchitecture = objOSDetail.OSArchitecture
        if OSArchitecture = "64-Bit" then
           NotesPath = oShell.RegRead ("HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Lotus\Notes\8.0\Path")
           NotesPath = oShell.RegRead ("HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Notes\8.0\Path")
        end if
WSHShell.Environment("system").item("NotesPath") = Notespath

The script is started with cscript.exe  from a batch file

@echo off
cscript Set_Notespath.vbs
xcopy /y "%cd%\files\*.*" "%notespath%\*.*"
msiexec.exe /i ptoolsniclient.msi /norestart /qb-!

When I start the batch file as admin, it works properly, installs the software and copies all files to the Notes installation path. But as soon as I start the batch in a managed installation as system, it doesn't execute the VB script, %notespath% is empty and the files are getting copied to c:\.

Why the VB script doesn't run in the managed installation?

Regards - Eva
1 Comment   [ + ] Show comment


  • I've had scripts run fine locally but fail when ran from the KBox. Sometimes I've found that supplying a username and password will work. I don't know why but sometimes it works. Other times I've had to add logging (just little notes to a text file) to to the script and see how far it makes it.

All Answers

You have to remove "On Error resume next" and see why the VBScript is failing..

If the VBScript itself not called then try like this
cscript "%~dp0Set_Notespath.vbs"
Answered 07/31/2015 by: jagadeish
Red Belt

  • Thanks for the answer. The VB script itself is working correct, I tested it several times outside the managed installation with different wscript.echo outputs to check the results. It is just that the script isn't runnig in the managed installation while it is running properly when I'm starting the batch file manually on a computer to test it. So I will try your suggestion with the cscript.
    • What I am saying is, you need to ensure that whether the VBScript is called by your batch file.. If your VBScript was not called by your batch file then try with %~dp0 as I mentioned in the above post..
      • This content is currently hidden from public view.
        Reason: Removed by member request For more information, visit our FAQ's.
      • Thanks for your help. Actually the problem is in the local environment system as EdT said below.

        However, thanks for your help.
There are a couple of possibilities here. Cscript.exe is a CMD line utility (you see a DOS window pop up if you run it). Therefore, setting an environment variable in a DOS session only affects the DOS session itself and as soon as the session closes, the environment change disappears.  The other possibility is that the handling of environment variables within a localsystem account may be different to a user account because the localsystem account has no profile associated with it. The thing with environment variable settings is that existing processes load the environment when they start and do not reload them unless you send out an API call to force processes to reload the environment. Consequently, I suspect that the installation process that your distribution system uses does not reload the environment and does not see your changes. When you run the batch file as a user, the actual master program is CMD.EXE (which remains open throughout), and the different entries in your batch file then run as individual processes and can share the environment within the master CMD process.
I hope this makes sense.
What you need to do is to build all these steps into your MSI in the InstallExecute sequence as then you can use a custom action to set a public property value with the location of your Notes install, and add the files you need to install to the files table as external files with the public property value as their destination.  There are a number of ways to do this but the important thing is that it all happens in one process so you don't have issues such as you are currently experiencing.  Also, the uninstall should also remove these files.
Answered 07/31/2015 by: EdT
Red Belt

  • Sadly I cannot create a new MSI because I got the files and the MSI from our parent company as is. They use Altiris instead of Kace, so I had to create my own little script. Due to the problems with the environment variables, I decided not to transfer the Lotus Notes Path in an environment variable. That solution was a liitle bit like programming on IBM's System /36 AS/400 where the local environment always works fine for scripts and programs. Eventually I decided to copy the files in the VBS with an FSO.copyfile which works without problems.

    Thanks for your help.
    • You could also try with setting "NotesPath" variable in both environments: "PROCESS" and "SYSTEM" eg:
      WSHShell.Environment("SYSTEM").Item("NotesPath") = Notespath
      WSHShell.Environment("PROCESS").Item("NotesPath") = Notespath

      Maybe then, your distribution system would not need a reload of the environment to see the changes like EdT pointed out.
  • This content is currently hidden from public view.
    Reason: Removed by member request For more information, visit our FAQ's.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

View more:


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ