GW 2014R2: setup.cfg settings are not being used.

Are the setup.cfg settings only used when updating, as opposed to a new installation?

I have our email server address set in the [GroupWiseSetup] section of the setup.cfg file, but the installation process doesn't make use of it.
The client is GW 2014R2 client build 4930.

I have a copy of the cfg file in the \client\win32\w32 subfolder that I created per Brainshare 2014 recommendations.

Variations tried:
setup.ini in client\w32 folder and setup.cfg file in client\w32\w32 folder
setup.ini in client\w32 folder and setup.cfg files in both client\w32 and client\w32\w32 folders

setup.ini setting:

[Startup]
EnableLangDlg=N


setup.cfg settings:

[Startup]
EnableLandDlg=No


Settings tried in [GroupWiseSetup]:

IPAddress=<FQDN of mail server>

IPAddress=<IP address of mail server>

DefaultIPAddress=<FQDN of mail server>

DefaultIPAddress=<IP address of mail server>

I've tried this on both Windows 10 and Windows 7

Any cogent, germane thoughts are welcome.
  • In article <gathagan.7supsn@no-mx.forums.microfocus.com>, Gathagan wrote:
    > Are the setup.cfg settings only used when updating, as opposed to a new
    > installation?


    Nope, for new as well
    I think the one piece that may be missed and gets in the way is the
    second line in the setup.cfg
    Version=14.0

    what does yours say?, If =14.2, try as =14.0

    Also related, make sure you have in your DNS an A recored for
    ngwnameserver pointing to a POA (and if multiple POA, use ngwnameserver2
    to one of the others) The client will try looking for those hosts if it
    can't find what it was otherwise told about previously. In the docs,
    https://www.novell.com/documentation/groupwise2014r2/gw2014_guide_admin/d
    ata/adm_poa_config_user_access.html#hyzcgpuk
    or shortened to goo.gl/Z1xus8


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • Hi,

    Here's a brilliant article on upgrading the GroupWise client: http://ohmag.net/?p=1386

    Also, as Andy said, set the version to 14.0 - I've seen this before.

    Please let us know how it goes.

    Cheers,
  • Thanks to both of you for the replies.
    I wanted to respond earlier, but I decided to experiment with every variation of the setup.cfg lines that I could think of before doing so.

    After trying 11 different variations, I have yet to find a combination of setup.cfg variables that was successful.
    (Thank you Lord for VM's and snapshots!)
    I tried with using both Version=14.0 and Version=14.2 in setup.cfg.
    I even tried using the GW 2012 client and got the same results.

    Andy, I have had the ngwnameserver entry in my DNS servers in the past, but it ended up causing more problems.
    It might hve been my fault though.
    I didn't use an A record, but used a CNAME entry to point ngwnameserver to my mail server.
    Doing so resulted in GroupWise using the IP address instead of the name.
    Since I have people accessing GW from home and while traveling, that prevented them from contacting the server.
    I'll try it again tonight with an A record to see if it makes any difference.




    Here are some of the variations I tried:
    [Startup]
    EnableLangDlg=N

    setup.cfg

    1st try:
    [GroupWiseSetup]
    Version=14.0
    IPAddress=<FQDN of mail server>


    2nd try:
    [GroupWiseSetup]
    Version=14.0
    IPAddress=<IP address of mail server>


    3rd try:
    [GroupWiseSetup]
    Version=14.0
    DefaultIPAddress=<FQDN of mail server>

    4th try:
    [GroupWiseSetup]
    Version=14.0
    DefaultIPAddress=<IP address of mail server>


    5th try:
    [GroupWiseSetup]
    Version=14.0
    DefaultIPAddress=<FQDN of mail server>
    DefaultIPPort=1677


    5th try:
    [GroupWiseSetup]
    Version=14.0
    IPAddress=<FQDN of mail server>
    IPPort=1677

    6th try:
    [GroupWiseSetup]
    Version=14.0
    IPAddress=<IP address of mail server>
    IPPort=1677


    7th try:
    [GroupWiseSetup]
    Version=14.0
    DefaultIPAddress=<IP address of mail server>
    DefaultIPPort=1677


    8th try:
    [GroupWiseSetup]
    Version=14.0
    IPAddress=<IP address of mail server>
    IPPort=1677
    DefaultIPAddress=<IP address of mail server>
    DefaultIPPort=1677



    9th try:
    [GroupWiseSetup]
    Version=14.2
    IPAddress=<FQDN of mail server>
    ;;IPPort=xxxx
    DefaultIPAddress=<FQDN of mail server>
    ;;DefaultIPPort=xxxx
  • After thinking about it a bit, I realize that there isn't any way to parlay ngwnameserver into a FQDN; it's always going to resolve to an IP address.
    That makes it unusable in my circumstances.
  • Hi,

    If you are trying to make GroupWise connect automatically internally and externally then what I do is setup a DNS record, for example mail.company.com. That DNS record resolves to a public IP address when the client is external. The public IP is NAT'd to an internal address, and the DNS record resolves to the private IP when the client is internal on the network. Never had an issue with this before.

    Cheers,
  • Aloha, Laura
    I've had that in place for years and it works fine.

    I was under the impression that the entire point of modifying setup.cfg was to get GroupWise to look for the server name that I want to be used.
    That is not happening.

    As I stated earlier, in my past attempts, a CNAME entry for ngwnameserver pointing to my mail server in my internal DNS, wrote the HKCU\Software\Novell\GroupWise\Login Parameters\TCP/IP Address registry key as the internal IP address of the server, not its name.

    I tried it again last night.
    This time around, the HKCU\Software\Novell\GroupWise\Login Parameters\TCP/IP Address registry key is simply written as ngwnameserver, without the domain name.
    The same holds true for having an A record for ngwnameserver in the internal DNS; it writes that registry key as ngwnameserver, without the domain name.

    In both cases, that is useless outside of an institution's internal network.
  • Hi Gathagan
    You are trying several things at once, so lets first make sure that your
    setup.cfg is actually being processed before working on the addressing.
    Given you are using EnableLandDlg=No, I'm assuming you have multiple
    languages with =Yes. In that case you have a test of just setting
    EnableLandDlg=Yes in your setup.cfg confirm you are actually processing
    it. This tests the setup.cfg location and Version= setting. Once you
    have confidence that this is working as you need, you can then work on
    the IP Port settings.

    Yes, VMs and snapshots are such a luxury that makes such testing soooo
    much easier than what we had before.

    In article <gathagan.7t5u9b@no-mx.forums.microfocus.com>, Gathagan wrote:
    > ngwnameserver ...
    > It's always going to resolve to an IP address.


    That is rather the point.
    All the POAs know the IP addresses of other POAs and know where each user
    is, so as long as you can get to one POA, you will get redirected to the
    others. So as long as ngwnameserver points to an IP that a POA is
    listening on, the client should be redirected to the POA of the user if
    it is another POA.
    In the POA Agent Settings, make sure the internal IPv4 (not sure where we
    are with IPv6 for this yet) is in the TCP/IP Address, and the External IP
    Address I put the external FQDN that ultimately NATs to the
    internal/private IP address that is usually a secondary IP address for
    some ease of migration portability.
    If you make your POAs visable to the outside, ensure that you NOT have
    "Allow login without a password. (Low Security)" set (Security Tab under
    each PostOffice)

    In the setup.cfg, I use the DefaultIPAddress/DefaultIPPort, with no
    dashes after either line, leaving the other 2 lines commented out.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • Am 31.01.2017 um 06:06 schrieb laurabuckley:
    >
    > Hi,
    >
    > If you are trying to make GroupWise connect automatically internally and
    > externally then what I do is setup a DNS record, for example
    > mail.company.com. That DNS record resolves to a public IP address when
    > the client is external. The public IP is NAT'd to an internal address,
    > and the DNS record resolves to the private IP when the client is
    > internal on the network. Never had an issue with this before.


    But that means you must bring mail.company.com into the clients setting
    first.

    *However*. Groupwise *does* contain code to solve this very problem.
    This is exactly why you can set an external IP address on the POA. Doing
    so will make ngwnameserver work again, *and* outside IPs too, wihtou
    ever having to configure anything in the client.

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Hi Massimo,

    Ah, good point. I forgot about enabling the external IP at a PO level. Many thanks for pointing that out :)

    Cheers,
  • Hi,

    In case you missed it see Massimo's post here: https://forums.novell.com/showthread.php/502205-GW-2014R2-setup-cfg-settings-are-not-being-used?p=2450021#post2450021

    As he suggests enable the external IP address field on your PO.

    Cheers,