Highlighted
Visitor.
1253 views

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!
Labels (2)
0 Likes
4 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: GroupWise Client and Webaccess sluggish slowness

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,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: GroupWise Client and Webaccess sluggish slowness

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
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: GroupWise Client and Webaccess sluggish slowness

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 & TCP port 1677 open on firewall specifically for the above NAT rule.
Internal DNS record, same name as the external record e.g gw.company.com, resolving to internal IP Address of GroupWise server
Each client setup in caching mode.
In the settings of the caching mailbox there is an entry box for the server address - here we put in the DNS name that corresponds to the records that were created.

Never had disconnects or any issues with this setup. Been running like this for years 🙂

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: GroupWise Client and Webaccess sluggish slowness

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!

___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.