GroupWise Client and Webaccess sluggish slowness

We are experiencing a strange problem that we just cannot track down and I just want to see if someone here has any insight. A few months ago we began experiencing slowness and complete shutdown of the GroupWise client from remote users. We basically have always used a named server to connect to GroupWise - whether inside the network or out - just makes it easier for laptop users etc so the client uses /ipa-ourservername.com and does a loopback to the lan when you are inside and still works outside.

Our clients started having problems - locking up and saying they lost connection to the server. Inside our network we changed them to use a local address (192.x) and the issues went away. Users outside the network using the ourservername.com still have the same problem. It makes no sense why using the name (or the public ip address) inside the network have the issue because our firewall just routes them to stay on the lan - they do not go outside the network and come back inside, but they have the same problem as someone running GroupWise outside the network.

Things we have done to troubleshoot and rule things out

Moved GW to new hardware (faster disk, faster and more processors, more ram)
Updated GW to the latest patch (2012)
Moved from SUSE Linux Enterprise Server 11 SP2 to SUSE Linux Enterprise Server 11 SP4.

Changed out our Firewall

We are now in the process of getting more bandwidth from our internet provider although we do not think that is a problem as we can experience these issues no matter the current bandwidth load.

I have a support ticket open with Novell - they do not think it is a problem with GW and I tend to agree. We see no issues (in the logs) with errors or database problems at all - and this is not isolated to just a few users - it only matters if you are connecting to the public address, or internal address.

Thanks for reading!
  • Hi,

    Firstly, I am no expert at networking, but am going to make a suggestion here.

    Install LAN trace software on a machine - I use Wireshark. Do a LAN trace and see where the packets are being dropped and/or dying. That would be the first place that I would look. Work with the folk who have your Service Request open and they should be able to make sense of the LAN trace if it looks like greek to you - I am assuming that NTS should know this stuff, I mean how to make sense of the LAN packet capture.

    Please let us know how it goes.

    Cheers,
  • Melanie,

    Here are a few ideas:

    Of course, it really shouldn't make a difference if using DNS or
    straight IP (assuming that DNS resolves to that very same IP, and not
    something else). If it does make a difference although it shouldn't,
    then without much room for doubt there is a reliability issue with your
    DNS infrastructure, especially when it happens internal.

    Just to mention it, Groupwise has built in method for solving the issue
    of different IP Addresses internal and external, that's why you can
    specify a dedicated external IP address:

    https://www.novell.com/documentation/groupwise2014r2/gw2014_guide_admin/data/adm_poa_config_basic.html

    Note that your Issue might even come from the fact that the IP addresses
    the POA knows of itself don't match those used to access it. The POA
    "tells" the client how it is accessible on what IP addresses, and
    depenging on how they connect, the client may switch over to that
    information. So it is vital for the POA to be properly configured in
    that regard.

    Next, IMHO it is really no good idea to let users acess Groupwise
    straight over the internet *without* using caching mode. The internet is
    occasionally unreliable, even if it's only for a fraction of a second,
    and Groupwise in online mode is just not coded to cope with that. It
    loses conection to the PO and closes on the slightest communication
    problem in online mode. That is where Caching Mode comes into play,
    along with the many other advantages it has, like being able to fully
    work with GW even without any connection whatsoever.

    Last but not least, to diagnose the issue, follow Lauras advice. We
    really need to see a Lan Trace at a time where the problem occurs. It
    should be relatively easy to spot.

    CU,
    Massimo

    Am 28.04.2016 um 23:36 schrieb melaniee:
    >
    > We are experiencing a strange problem that we just cannot track down and
    > I just want to see if someone here has any insight. A few months ago we
    > began experiencing slowness and complete shutdown of the GroupWise
    > client from remote users. We basically have always used a named server
    > to connect to GroupWise - whether inside the network or out - just makes
    > it easier for laptop users etc so the client uses /ipa-ourservername.com
    > and does a loopback to the lan when you are inside and still works
    > outside.
    >
    > Our clients started having problems - locking up and saying they lost
    > connection to the server. Inside our network we changed them to use a
    > local address (192.x) and the issues went away. Users outside the
    > network using the ourservername.com still have the same problem. It
    > makes no sense why using the name (or the public ip address) inside the
    > network have the issue because our firewall just routes them to stay on
    > the lan - they do not go outside the network and come back inside, but
    > they have the same problem as someone running GroupWise outside the
    > network.
    >
    > Things we have done to troubleshoot and rule things out
    >
    > Moved GW to new hardware (faster disk, faster and more processors, more
    > ram)
    > Updated GW to the latest patch (2012)
    > Moved from SUSE Linux Enterprise Server 11 SP2 to SUSE Linux Enterprise
    > Server 11 SP4.
    >
    > Changed out our Firewall
    >
    > We are now in the process of getting more bandwidth from our internet
    > provider although we do not think that is a problem as we can experience
    > these issues no matter the current bandwidth load.
    >
    > I have a support ticket open with Novell - they do not think it is a
    > problem with GW and I tend to agree. We see no issues (in the logs)
    > with errors or database problems at all - and this is not isolated to
    > just a few users - it only matters if you are connecting to the public
    > address, or internal address.
    >
    > Thanks for reading!
    >
    >



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

    Hi,

    To add to what Massimo has said about using caching mode, this is how I have it setup:

    External DNS record resolving to public IP address allocated to the GroupWise servers e.g gw.company.com
    Public IP address NAT'd through to private IP of GroupWise server.
    UDP
  • In article <laurabuckley.7exorb@no-mx.forums.microfocus.com>,
    Laurabuckley wrote:
    > External DNS record resolving to public IP address allocated to the
    > GroupWise servers e.g gw.company.com


    a great tool for testing this is
    http://www.nirsoft.net/utils/dns_records_viewer.html
    you get to point it to the DNS server you are using (or think you are
    using) This combined with running wireshark to see the actual DNS
    packets is great for troubleshooting DNS issues like it sounds is part
    of your issue.

    Firewall NAT loop problems do happen, and having your POAs know both
    inside and outside IPs to tell the clients does help resolve those
    issues which can come and go as the firewall software is updated.


    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!