none
Visio and Project 2013 silent install returns immediately (before install is finished) RRS feed

  • Question

  • Hi,

    I am building a task sequence that will include Office 2010 ProPlus (volume license), a bunch of other products (like SQL Server and Visual Studio) and also Visio 2013 and Project 2013.

    For Visio 2013 and Project 2013, I have to use the retail media (this is for use in academic computer labs and we have a single retail key through DreamSpark Premium that allows unlimited activations - I don't know why DreamSpark doesn't just give a volume license key).

    I managed to get Visio 2013 and Project 2013 to install silently by modifying the config.xml file and using the /config parameter. However, when running my install script (the usual VBScript wrapper) or just from the command line, the command returns before setup finishes (literally within less than a second). Setup continues to run and finishes successfully, but as you can imagine, MDT considers that application install finished and tries to move on to the next application which fails because another installation is still in progress.

    I've included below the relevant portion of the VBScript wrapper. Any help in figuring out how to get the wrapper to wait for the installer to finish is appreciated.

    sSetupFile = oUtility.ScriptDir & "\Source\setup.exe"
    sArguments = "/config vispror.ww\config.xml"
    
    oLogging.CreateEntry oUtility.ScriptName & ": Starting installation", LogTypeInfo
    
    // Check for existence of setup file omitted
    // ...
    
    iRetVal = oUtility.RunWithHeartbeat("""" & sSetupFile & """ " & sArguments)

    Coincidentally, iRetVal = 0 indicating success.

    Thanks,

    SA

    Thursday, December 12, 2013 2:11 PM

Answers

  • Hi SA,

    Obviously you use the VBS wrapper for some reason. To my understanding this behaviour needs to be captured and translated to "script is till busy, when installation completes script is finished, proceed to next step".

    I can only advise you to either try the command line directly in MDT, instead of using the VBS wrapper, and/or try to create an MSP and try this in your VBS wrapper, command line directly in MDT.

    MSP files are easily created by going into command prompt to the sources folder of Visio / Project and execute the following command: setup.exe /admin this will start the Office Customization Tool which enables you to create an MSP file.

    When you are ready, execute the following command to install the application with the settings in the MSP: setup.exe /adminfile custom.msp

    Again I can imagine the purpose of the VBS just as I can imagine the purpose of using the config.xml above a custom.msp. But for starters this should get you going to try to find an resolve where the issue lies. In the VBS or somewhere else.

    Cheers!


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Thursday, December 12, 2013 3:47 PM
  • in my Situation the error was caused by starting the Setup.exe from the root Folder.

    Starting the Setup.exe from the X86 Folder resolved the Issus, and my Script runs as expected !

    Reiner

    • Marked as answer by Speedbird186 Tuesday, April 28, 2015 7:29 PM
    Thursday, November 20, 2014 12:16 PM

All replies

  • Hi SA,

    Obviously you use the VBS wrapper for some reason. To my understanding this behaviour needs to be captured and translated to "script is till busy, when installation completes script is finished, proceed to next step".

    I can only advise you to either try the command line directly in MDT, instead of using the VBS wrapper, and/or try to create an MSP and try this in your VBS wrapper, command line directly in MDT.

    MSP files are easily created by going into command prompt to the sources folder of Visio / Project and execute the following command: setup.exe /admin this will start the Office Customization Tool which enables you to create an MSP file.

    When you are ready, execute the following command to install the application with the settings in the MSP: setup.exe /adminfile custom.msp

    Again I can imagine the purpose of the VBS just as I can imagine the purpose of using the config.xml above a custom.msp. But for starters this should get you going to try to find an resolve where the issue lies. In the VBS or somewhere else.

    Cheers!


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Thursday, December 12, 2013 3:47 PM
  • Rens,

    thanks for the reply. Unfortunately, the Retail versions do no include the OCT... running /admin results in an error.

    (It's not the script that returns immediately, it's the call to the Visio and Project setup files that returns immediately. The script would wait until the process it launches is completed, but apparently, the process it launches is not the process that stays alive...)

    SA.

    Friday, December 13, 2013 7:01 PM
  • My first guess is that the reason your install is returning is not because it's returning before setup has finished as you mention above, I would find it more likely that the setup program has *FAILED*.  The Office Setup program will typically block until it's finished.

    HOw do you know that setup is still working in the background, have you positively verified that setup eventually finished in the background? What does the %temp%\setup <blah> .log file say? You are doing some weird things with the paths in your script that are a red flag to me, For example you specify the *full* path to the setup.exe, but you keep the config.xml as a *relative* path.


    Keith Garner - keithga.wordpress.com

    Friday, December 13, 2013 11:05 PM
    Moderator
  • setup.exe for Office is a chaining bootstrapper. It spawns multiple other things (mainly sequentially), including a version-checked instance of osesetup0000.exe and multiple instances of msiexec (because Office is composed of multiple MSIfiles, and often, multiple MSPfiles.

    your script needs to spawn setup.exe with the relevant "wait for process/thread and all child threads completion".In shell-scripting methods, this is similar to "start /wait setup.exe"
    I don't know what methods your "oUtility.RunWithHeartbeatBlahBlah" is doing, but at a guess, it isn't watching the thread created.

    as Keith says, the Office setup logfile will outline or confirm your observations (i.e. that setup is running to completion but your script is only watching for the initially spawned thread to terminate)


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Saturday, December 14, 2013 12:06 AM
  • If speedbird was using the script above, oUtility.RunWithHeartBeat() would correctly block execution.

    This is a built in MDT Blah Blah function.  :^)


    Keith Garner - keithga.wordpress.com

    Monday, December 16, 2013 4:42 AM
    Moderator
  • Keith,

    Thanks for the answer; and I am sorry for my late reply, I was on vacation.

    The product installs successfully indeed. I can also monitor several install processes that are ongoing.

    When I execute the VBS wrapper as part of an MDT task sequence, the second one fails. I haven't checked the log files, but I presume it would be because the first one is still in progress. When I get back to this, I will check the log files to make sure.

    I see your point about the relative and absolute path issue, but again, that part seems to work just fine, as what I put in the config.xml is actually executed (i.e. product key, the fact that the install is silent, etc.)

    SA.

    Saturday, December 28, 2013 9:27 PM
  • Don,

    Thanks for the reply. Exactly what Keith already indicated, MDT includes several script files, one of which contains a function RunWithHeartbeat that indeed waits until the launched process is finished (and then also examines the return code).

    The return code is 0, indicating success.

    I will try instead of hiding the Office setup shell to show it and see if it waits then.

    SA.

    Saturday, December 28, 2013 9:29 PM
  • in my Situation the error was caused by starting the Setup.exe from the root Folder.

    Starting the Setup.exe from the X86 Folder resolved the Issus, and my Script runs as expected !

    Reiner

    • Marked as answer by Speedbird186 Tuesday, April 28, 2015 7:29 PM
    Thursday, November 20, 2014 12:16 PM
  • Reiner,

    That was the solution for me as well. So simple once you realize that the root setup.exe is a wrapper that simply passes on the same parameters.

    SA.

    Tuesday, April 28, 2015 7:29 PM