GWC 14.2.2.126868 install.ini & dotnetfx45 param's

Hi!
Just tried latest GroupWise 14.2.2 Windows Client unattended setup and seems to me dotnetfx45_full_x86_x64.exe parameters is wrongly set in install.ini.
is: /q:a /c:"install /l <log>"
should be: /q /log <log> /norestart
At least in original way our setup get stuck in end of .NET Framework 4.5 setup and log wasn't set into correct place.
Well, "/norestart" I'd add just in case.
Terv, Alar.

Tags:

  • NovAlf;2454661 wrote:
    Hi!
    Just tried latest GroupWise 14.2.2 Windows Client unattended setup and seems to me dotnetfx45_full_x86_x64.exe parameters is wrongly set in install.ini.
    is: /q:a /c:"install /l <log>"
    should be: /q /log <log> /norestart
    At least in original way our setup get stuck in end of .NET Framework 4.5 setup and log wasn't set into correct place.
    Well, "/norestart" I'd add just in case.
    Terv, Alar.


    confirmed. just tried to install on a fresh win 7 x64. but still confused about your install.ini.
  • Hi,

    the provided install.bat was also in earlier versions not well tested by
    Novell or MF.

    I wrote my own script - check for VisualC-versions and installed
    ..NET-components. Together with a custom transform file no I have a
    install script working both for install and update. But only one
    question? Why delivers MF vc-runtimes for 64bit and uses the 2013_x64 only?

    Gotthard

    Am 10.04.2017 um 13:56 schrieb NovAlf:
    >
    > Hi!
    > Just tried latest GroupWise 14.2.2 Windows Client unattended setup and
    > seems to me dotnetfx45_full_x86_x64.exe parameters is wrongly set in
    > install.ini.
    > is: /q:a /c:"install /l <log>"
    > should be: /q /log <log> /norestart
    > At least in original way our setup get stuck in end of .NET Framework
    > 4.5 setup and log wasn't set into correct place.
    > Well, "/norestart" I'd add just in case.
    > Terv, Alar.
    >
    >



    --
    Gotthard Anger
    Anwenderbetreuung Netzwerkadministration
    Landeskirchenamt der EKM
    gotthardanger@no-mx.forums.novell.com
    https://forums.novell.com/member.php/35038-gotthardanger

    Mails an diese Adresse werden nur nach vorheriger Ansage gelesen!
    Mails for this address will only be read if you trigger me before.
  • Am 11.04.2017 um 13:49 schrieb Gotthard Anger:
    > Hi,
    >
    > the provided install.bat was also in earlier versions not well tested by
    > Novell or MF.
    >
    > I wrote my own script - check for VisualC-versions and installed
    > .NET-components. Together with a custom transform file no I have a
    > install script working both for install and update. But only one
    > question? Why delivers MF vc-runtimes for 64bit and uses the 2013_x64 only?


    I agree. Also, I think it's generally a very bad idea to install
    software with batch files.

    As for the VC runtimes it doesn't use: I've asked that before and got no
    answer. Seems like they just bundle whatever they find, no matter if
    it's used or not.


    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Hi and thanks!
    Well, don't know why I instead of bat wrote ini.
    Terv, Alar.
  • Hi!
    Well, as using this install.ini, sorry, install.bat, is meant for (full) unattended setup then, sure, it must be tested thoroughly. (Shouldn't be everything put into a public?!) Yeah, anyway, I had under consideration to take this bat into pieces and put it step by step into ZENworks (we using ZEN for publishing anyway), but thought it will be better to use old fashion way (not skipping something important to be installed!), but, sure, every time I must check and customize bat a bit for our needs. (This was my first time to get setup stuck in that way.) In most cases I think running just msi will do the trick on (managed) Windows computers, not sure though.
    Terv, Alar.
  • Hi again!
    Must say I would prefer for GWC setup in one wrapping, not bat nor customized other script. (Not an idea, must admit!) But, as said, bat does the trick.
    In our case(s) log's (including one reg) ...
    [INDENT]GWCsetup_12_wmic_after.log
    GWCsetup_10_groupwise.msi.log
    GWCsetup_10_wmic_uninstall.log
    GWCsetup_groupwise_client_addressbook.reg
    GWCsetup_09_appwiz_before.log
    GWCsetup_08_wmic_before.log
    GWCsetup_07_mapi.log
    GWCsetup_00_env.log
    GWCsetup_04_wse3.msi.log
    GWCsetup_05_vc_redist_2015.x86.exe.log
    GWCsetup_03_dotnetfx45_full_x86_x64.exe.log.html
    GWCsetup_03_vcredist2013_x64.exe.log
    GWCsetup_03_vcredist2013_x86.exe.log
    GWCsetup_03_vcredist2013_x86.exe_1_vcRuntimeAdditional_x86.log
    GWCsetup_03_vcredist2013_x86.exe_0_vcRuntimeMinimum_x86.log
    GWCsetup_02_vcredist_2012update3_x86.exe.log
    gwcsetup_01_vcredist_2008sp1_x86.exe.log
    [/INDENT]
    (I'd add GWCsetup_ for gathering into zip after setup is done.)
    Alar.
  • NovAlf;2454741 wrote:
    Hi!
    Well, as using this install.ini, sorry, install.bat, is meant for (full) unattended setup then, sure, it must be tested thoroughly. (Shouldn't be everything put into a public?!) Yeah, anyway, I had under consideration to take this bat into pieces and put it step by step into ZENworks (we using ZEN for publishing anyway), but thought it will be better to use old fashion way (not skipping something important to be installed!), but, sure, every time I must check and customize bat a bit for our needs. (This was my first time to get setup stuck in that way.) In most cases I think running just msi will do the trick on (managed) Windows computers, not sure though.
    Terv, Alar.


    this is not a problem with install.bat itself. the unattended setup also hangs when using the /s switch with setup.exe. i tested a complete manual install without issue. using the silent switch works only, if dotnet4.5 has been installed before.
  • Hi and thanks!
    When You install .NET Framework 4.5 with command line options described in install.bat (in question) then ... You may ran into ... stuck-situation. (Keep in mind – totally unattended setup, using Windows system account.) May! I'm not sure about all possibilities and not willing to test, either. Anyway, when You have .NET Framework 4.5 or higher already installed (as in our situation and, I believe, in most, as .NET Framework 4.5 is quite old already and probably installed or renewed on most of computers) then using command line options from batch /q:a /c:"install /l %LOG_DIR%\03_%GW_PKG_DOTNETFX45%.log /q" lead You surely to stuck install as exe does not recognize it should do install quietly and dialog pops up which You can't see when using system account for installation, can You! You see also log in wrong place (default temp dir) and some setup dir's and files left in root dir. Only option You have is to kill this setup and, sure, then You can proceed with setup. When You use command line options "from book" for .Net 4.5 setup a'la /q /norestart /log "%LOG_DIR%\03_%GW_PKG_DOTNETFX45%.log" You not run into stuck-situation (because of situation described here, at least) as – even with error/warning in question where same or newer version is installed (as error states) – all is done quietly, no box whatsoever appear. Proceed as should. Also log file appear in correct place, as bonus! So, definitely I would suggest something wrong with bat! Don't You think! =) Running exe with option /? (etc.) gives usually right options to have at hand. ... Anyway, in our case this (described above change in bat) solved issue.
    Yes, bad or not, good idea or not, but we do rely on this bat file. Luckily we test setup's etc. before we publish it and .... well, forums kind of this is place to share ... findings and experiences ... thanks to everyone! =)
    Terv, Alar.