none
Specifying the Command Line to run a VBscript a Program that runs a package

    Question

  •  

    Can anyone point me to any resources on how to execute VBscripts inside programs that run application packages in SCCM?

     

    I've tried everything I can think of to get it to run properly, but it either never completes or has errors

     

    I created a custom VBscript to install Office with an msp file first, then the Outlook2007 hotfix patch, followed by the Live Meeting Add-Ins executable.  The script works as we've run it from the command line on a test machine and everything installs properly.  I copied the script to the source directory of the package and set the source directory of the package.  In the command line, I have specified.....  wscript.exe addoutlook.vbs         wscript.exe %fullUNCpath%\addoutlook.vbs    and even tried the same combo with cscript.exe....... no dice !!

     

    Any help would be greatly appreciated!

     

    Thanks!

     

     

    -Matt

    Wednesday, June 25, 2008 1:53 AM

Answers

  •  

    >Run the package with user interaction and force the vbscript in verbose now you can see what is going on.

    >It it is hung, or prompting for something. 

    Under the Package window you will see Run Mode

    Click "Allow users to interact with this program"

    Make sure the Run: Section in General is set to either maximized or Normal 

    Now when the vbscript file runs it will be seen by you.

    note:be sure to run your vbscript with cscript xxx.vbs as many have mentioned above and now wscript or just xx.vbs

    *-----

    install = "msiexec /i  x2.msi  /qb /log showme.log"

    Wshshell.run install,3,true

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

    http://www.devguru.com/technologies/wsh/QuickRef/wshshell_Run.html

     

     

     

    >The other way would be to map the drive as z: or something and refer to the drive. 

    Right before you run the vbscript package run you have another tha maps the drive (change programs)

    -------------- mapme.bat -----

    net use Q: \\myserrver\deploy
    cscript Q:\deploy\stand\AdminImage\xx.vbs

    net use q: /delete

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

     

    Make sense....

     

    Thursday, June 26, 2008 9:03 PM

All replies

  • Have you updated your DPs after having added the script to the source directory? cscript yourscript.vbs always works for me.

    Wednesday, June 25, 2008 7:30 AM
    Moderator
  • Why not download the package to the computer and then just run cscript xxx.vbs instead of across the network. 

    Also since you are chaining programs you can let SCCM do it instead of a vbscript it you like.

     

    Local System will not have access to the network drive path you are pointing to.

    Wednesday, June 25, 2008 5:09 PM
  • Downloading the entire Office 2007 package would take a day and a half with BITS throttling enabled just on one box, much less at the volume that we have to push this out for soon (1200 users a week).  We can't increase throttling either.  So, I'm hoping we can run this from the DP.

     

    I’ll further describe what I am doing – I need to install Outlook 2007 with a custom MSP file applied to the install.  The reason for my VBscript is that I need to check for different types of Office installs in the environment.  Some machines have Access, Excel, and Word, while others have all of that with Publisher, and even others with different types of installs.  The VBscript checks for these different installs and applies the corresponding MSP (I have multiple MSPs for each scenario) to install.  I’ve included all MSP files and the script in the Office 2007 source directory.  The VBscript works fine when I run it from the command line locally on a machine without pushing it out via SCCM.

     

    In SCCM, I created a package containing source files for the Office 2007 install.  Added my MSPs and VBscript to the source directory.  My command line was cscript AddOutlook.vbs

     

    The execmgr.log file shows the program has started and is running, and does not time out or give an exit code, it just sits there.  The execmgr.log file also says the command line --- blah blah cscript addoutlook.vbs – working directory ‘\\Distribution Point path to package’

     

    I’ve been waiting on this for about an hour or so and it’s still not doing anything and I have no errors in the logs and the sccm console does not show errors.  We also have an Altiris environment with a package and uses the vbscript to install and it works fine…… So, I’m a bit lost. 

     

    Do you have any recommendations?

     

    I appreciate your reply!

     

    Thursday, June 26, 2008 7:49 PM
  • Run the package with user interaction and force the vbscript in verbose now you can see what is going on.  It it is hung, or prompting for something.  The other way would be to map the drive as z: or something and refer to the drive. 

     

    Just my 2 cents...

     

    Thursday, June 26, 2008 7:59 PM
  • Thanks for the reply Matthew!

     

    I'm a bit new to this application distribution thing.  Can you explain to me how to do both of those options?

     

    Thanks man!  I really appreciate it!

     

    Thursday, June 26, 2008 8:35 PM
  •  

    >Run the package with user interaction and force the vbscript in verbose now you can see what is going on.

    >It it is hung, or prompting for something. 

    Under the Package window you will see Run Mode

    Click "Allow users to interact with this program"

    Make sure the Run: Section in General is set to either maximized or Normal 

    Now when the vbscript file runs it will be seen by you.

    note:be sure to run your vbscript with cscript xxx.vbs as many have mentioned above and now wscript or just xx.vbs

    *-----

    install = "msiexec /i  x2.msi  /qb /log showme.log"

    Wshshell.run install,3,true

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

    http://www.devguru.com/technologies/wsh/QuickRef/wshshell_Run.html

     

     

     

    >The other way would be to map the drive as z: or something and refer to the drive. 

    Right before you run the vbscript package run you have another tha maps the drive (change programs)

    -------------- mapme.bat -----

    net use Q: \\myserrver\deploy
    cscript Q:\deploy\stand\AdminImage\xx.vbs

    net use q: /delete

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

     

    Make sense....

     

    Thursday, June 26, 2008 9:03 PM
  •  

    Awesome!  I think I found my problem points.... when in normal and interactive mode.... the user is prompted twice to run setup.exe for Office ... once to uninstall the current setup and then again, to reinstall with Outlook and the custom MSP.

     

    My guess the package hung her while in silent..... Any ideas on how to get past that silently or where the user doesn't have to interact with the package?

     

     

    Thanks a ton man!

    Thursday, June 26, 2008 9:32 PM
  • I know that when we deployed 2007 we setup the program to uninstall "previous versions" silently.  I know the pain of Office 2007, we deployed it over 6 to 8 week period to our machines. 

     

    I will bring up my MSP file and let you know what I have setup ok...

     

    Thursday, June 26, 2008 9:44 PM
  • Cool thanks man !!

     

    A couple more questions if you don't mind.... I haven't set discovery up yet, but I've installed the client on some machines in my environment.  I want to be able to create some custom query based collections based on the OU they are in.  However, none of my OUs are showing when I run a query for SELECT * FROM SMS_R_System ... I just wanted to see if any data were in there about the OU containers and it was all blank.  And the same deal for machines with Outlook installed, specifically looking for Outlook installed only..... my queries are not bringing back data.....Any ideas?

     

    I appreciate all your help man!

     

    Thursday, June 26, 2008 10:57 PM
  • You need to turn on System Discovery and System Group discovery and that should pull in the info you want.  If you want to see who has outlook installed then you need to turn on HW inventory (Add/remove programs) and possible software inventory(.exe programs files)

     

     

     

    Friday, June 27, 2008 2:25 AM