GroupWise 18.3 / 18.4 Web (GWWEB) Best Practices
This is a comprehensive document that is evolving. This was written shortly after GroupWise 18.3 was released. It's accurate to the best of my knowledge and I update/correct it as needed. My goal is to offer information that goes far above and beyond what is included in the product documentation. This includes troubleshooting information as well as detail on what you should see when you have the system working correctly.
The following Operating Systems are supported for running Docker and GWWEB:
- SLES 12
- OES 2018 (Based on SLES 12)
- SLES 15
- OES 2023 (Based on SLES 15)
Note that there are many differences between SLES 12 and SLES 15. I do not reference SLES 12 at all in this document. My preference is to always use SLES 15. Also, worth noting: While it also may be possible to run GWWEB and Docker on a Windows platform, I do not cover that at all in this document. You will have a very difficult time finding support for GWWEB on Windows if you choose to go down that path.
GroupWise 18.3 was released in December 2020 as a milestone feature release of GroupWise. With this release, GroupWise introduces a completely new WebAccess experience called "GroupWise Web". This new application no longer uses Apache/Tomcat as the platform, and instead uses Docker Containers to run a self-contained WebAccess application. There are very few options and it doesn't take much to get going. However, in the normal fashion of GroupWise documentation, even if you RTFM, you'll be scratching your head a few times as you're working through things. I'm making the assumption that you've looked at the documentation that can be found here: https://support.microfocus.com/kb/doc.php?id=7022859
Although the general process of getting GroupWise Web up and running is fairly simple, there's a chance you could run into some problems or need further understanding of what's going on. I have color coordinated the different sections for clarity and split into the following general categories:
- TLDR Version - Get up and running quick
- Intro to Docker & Feature Parity
- System Prerequisite How-To's
- Firewall Requirements and How-To's
- Full Installation Process
- SSL Considerations
- Troubleshooting
The End Result / What To Expect
Below is a screenshot of the new GroupWise Web login screen. Although it does not mean everything is working perfectly, if you get this screen when connecting to GroupWise mail with an Internet browser, you can be confident that the new GroupWise Web application is running.

Too Long Didn't Read Version
This is the process from start to finish that is required to get the new GroupWise Web installed and configured. If everything works perfectly, this is all you need. If you're logged in as root, you do not need the sudo command.
Preparation
- Create the folder /opt/novell/gw/certs
- Copy your 3rd Party commercial certificates into /opt/novell/gw/certs
- Rename your 3rd party certificate files to server.crt and server.key
Command Line Syntax
sudo zypper install docker
sudo systemctl enable docker
sudo systemctl start docker
sudo docker run -it -v /opt/novell/gw:/config -e GWADMIN_SERVICE=admin@192.168.1.1:9710 -e GWSOAP_HOST_DEFAULT=192.168.1.2 mfgroupwise/web-config
sudo docker run -d --restart always -v /opt/novell/gw:/etc/nginx/gw --name gwweb -e FQDN=webmail.redjuju.com -e DNS_SERVER=192.168.1.5 -p 80:80 -p 443:443 -v /opt/novell/gw/certs:/certs -v /opt/novell/gw/logs/:/var/log/nginx/ -e GWSOAP_SSL_VERIFY=off mfgroupwise/web:latest
Notes
Note the following items that must be customized to your specific environment:
- "admin" refers to your GroupWise Administrator user credential. It is not necessarily "admin".
- The IP Address referenced with the GWADMIN_SERVICE directive should be the IP address of your GroupWise Administration service.
- 9710 Is the default GroupWise Admin port but could vary.
- The GWSOAP_HOST_DEFAULT should reference the IP address of one of your GroupWise Post Office Agents. This may or may not be the same as your GroupWise Administration IP Address depending on your environment.
- FQDN should be the full DNS name that users enter to connect to GroupWise Web from the Internet.
- DNS_SERVER IP Address that docker will use for DNS Lookups.
- -e GWSOAP_SSL_VERIFY=off directive added for GroupWise 18.4. The new certificate and security requirements always tend to fail if this is not included even if the certificates are working perfectly.
Working with Docker for GroupWise Web
I won't go into a ton of detail on Docker in general, but I will cover the basics for use in the GroupWise environment. Instead of installing an RPM module and configuring Apache and tomcat, Docker provides a prebuilt "image" that just runs. It works with a simple configuration file and minimal command-line options. Many applications are now being developed in this manner.
Helpful Docker commands:
Command | Purpose |
---|---|
zypper install docker | Installs the current Docker modules from the SUSE repositories |
systemctl enable docker | Enables the Docker service to launch on system startup |
systemctl disable docker | Prevents the Docker service from launching on system startup |
systemctl start docker | Starts the Docker service |
systemctl stop docker | Stops the Docker service |
systemctl status docker | Shows the running status of the Docker service |
docker image list | Lists the current Docker images |
docker stop gwweb | Stops the GroupWise Web application within Docker. Docker remains running. |
docker rm gwweb | Cleans up the GroupWise Web application from within Docker. |
docker stop gwweb docker rm gwweb docker start gwweb |
Generally used to stop, remove, and then start GroupWise Web. Use this if you need to stop GroupWise Web, make changes or troubleshoot, then start it again. If you have made changes to the "docker run" command line, you will need to follow this sequence. |
docker restart gwweb | Restarts the GroupWise Web application container. |
docker pull mfgroupwise/web | Downloads the latest version of GroupWise Web from the Micro Focus Docker repository |
docker pull mfgroupwise/web-config | Downloads the web-config utility from the Micro Focus Docker repository |
"Docker Run" command line switches for GroupWise Web
The command line required to launch GWWEB via Docker is quite complex. I have provided two tables. The first one explains the generic use of each relevant command line option. The second table outlines each of the options that are relevant/required for running GWWEB.
General "Docker Run" Command Line Options
A good reference for better understanding Docker Commands can be found on the Docker documentation that can be found here: https://docs.docker.com/engine/reference/commandline/run/
Syntax
docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Command | Purpose |
---|---|
-d (or --detach) | Run container in background and print container ID. This is a no brainer, it wouldn't make sense to not run it in the background. |
-rm | Automatically remove the container when it exits. |
--restart | Restart policy to apply to a container.
Restart Always: Restart the container regardless of the exit status. When you specify always, the Docker daemon will try to restart the container indefinitely. The container will also always start on daemon startup, regardless of the current state of the container. (This is my preferred option) Examples: --restart always (preferred) |
--name | Assign a name to the container. Example: --name gwweb |
-e (or --env) | Set environment variables Example: -e DNS_SERVER=192.168.0.1 |
-v | Bind mount a volume. When you use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its absolute path on the host machine. The file or directory does not need to exist on the Docker host already. It is created on demand if it does not yet exist. Reference this link to understand this directive a little better: https://docs.docker.com/storage/bind-mounts/
In the case of GWWEB, many bind mounts are used that help define locations of log files, certificates, and custom images. Example: -v /opt/novell/gw/certs:/certs |
-p | Publish a container's port(s) to the host. Example: -p 443:443 |
--add-host | Add a custom host-to-IP mapping (host:ip). Use this if you do not have accessible DNS for name resolution. This is similar to using a hosts file on a server. Example: --add-host gwpo.redjuju.com:192.168.185.13 |
"Docker Run" command line switches for GroupWise Web
The directives below are each of the actual directives needed to launch GWWEB via the Docker Run command.
Command | Purpose |
---|---|
-d | Run the GWWEB application container in the background and displays the container ID on the screen when launched. |
-rm (Use either -rm or --restart always, you cannot use both) |
This directive will run the GWWEB app but remove the container when docker is stopped. It's more tedious, and I do not prefer it in most cases. When docker restarts, you will have to manually run the Docker Run command to get GWWEB working again. |
--restart always (Use either -rm or --restart always, you cannot use both) |
I prefer this directive because it will cause the GWWEB app to always run even after the docker service is restarted or if the server itself is restarted. |
-v /opt/novell/gw:/etc/nginx/gw | There are several configuration files in the /opt/novell/gw folder that define connectivity to your Post Offices and DVA's. This directive does a "bind mount" and puts the files into the GWWEB container, giving GWWEB the ability to read these configuration files needed to connect to GroupWise. |
--name gwweb | This names the docker container. When starting, stopping, or removing the app, you reference this name.
docker stop gwweb (stops the gwweb container) |
-e FQDN=webmail.yourserver.com | Specifies the FQDN name of your server. The name in this directive should generally be resolvable from the public Internet (unless you only allow GWWEB from inside your organization. In that case you would still assign a FQDN that is resolvable from inside your organization). |
-e DNS_SERVER=192.168.0.1 | Docker does not have the ability to use your system defined DNS resolvers. Therefore you must define the DNS server that Docker will use when performing DNS lookups. Note that the DNS server you select needs to be able to resolve the FQDN of your GroupWise Post Offices and DVAs. This doesn't matter as much if you use IP Addresses for them, however the best practice from a security and certificate standpoint is to use FQDN ever since GroupWise 18.4.0. |
-p 443:443 | This command tells the GWWEB container to publish/map port 443 in the container to the hosts secure https port 443. |
-p 80:80 | This command tells the GWWEB container to publish/map port 80 in the container to the hosts non secure http port 80. |
-v /opt/novell/gw/certs:/certs | This tells Docker to use certificates when loading the application. It loads them from the folder listed, which is /opt/novell/gw/certs. I always use this directive, even though the documentation makes it sound more optional. It doesn't even seem practical to try to run GWWEB in a non-secure mode without certificates. |
-e GWSOAP_SSL_VERIFY=off | I have found that I generally need this statement with any GW 18.4.x version. Without it, Docker can fail to connect to your Post Office(s) due to various problems it detects with the certificates. I struggle with this even if the certificates are perfectly valid. I do not know what triggers a failure, so using this has become a standard directive in most instances of GWWEB that I deploy. |
-v /opt/novell/gw/logs/:/var/log/nginx/ | This tells Docker to log the GWWEB application in the /opt/novell/gw/logs/ folder. |
-v /opt/gwweb/gwlogo.svg:/app/assets/img/app-logo.svg
|
This instructs Docker to load a custom SVG file in place of the default one. The default image is the Blue Square with the white envelope above and to the left of the login prompt. Reference the section about customizing the login screen for more details on this option. |
-v /opt/gwweb/graphic.jpg:/app/assets/img/login_image.jpg
|
This instructs Docker to load a custom Graphic image in the background in place of the default one. The default image is the image of 5 people putting their fists together at a table. It is placed in roughly the right 55% of the screen. Reference the section about customizing the login screen for more details on this option. |
mfgroupwise/web:latest | This should ALWAYS be the last item on the line. It instructs docker what image you are actually running. This "image" is the GWWEB program code that runs inside the Docker Container. In most cases, "mfgroupwise/web:latest" is the correct version. This could vary for a couple reasons:
If you're using something other than the latest, you would replace "latest" with the build number that you installed. |
Feature Parity GroupWise WebAccess vs GroupWise Web
It is important to understand that full feature parity does not exist between GroupWise WebAccess 18.2.1 and GroupWise Web. The initial 18.3 was severely lacking, but it has improved dramatically. Reference the "What's New" section of the GroupWise 18 release notes for details on improvements that have been made with each subsequent release. https://www.novell.com/documentation/groupwise18/gw18_readme/data/gw18_readme.html#whats_new
As a point of reference, it would seem pertinent to note that the GroupWise developers promised feature parity between the GroupWise Client and GroupWise WebAccess for years, but never fully achieved this even with GroupWise 18.2.1. Now with GroupWise Web replacing GroupWise WebAccess, it could be argued that feature parity has gone backward.
Suggestions for how you might handle concerns about missing features:
- Install the latest available GroupWise WEB version. There are generally no reasons to run older versions, and it has improved dramatically. Continue to update it as new versions are released.
- Continue running GroupWise WebAccess and do not upgrade until more features have been built into GroupWise Web. The older GroupWise WebAccess will continue to function, it is not mandatory to upgrade it to continue to use it. Note that you may get pushback from Micro Focus support if you open a support ticket, and it's unlikely any bug fixes will be provided.
- Run the GroupWise 18.2.1 WebAccess simultaneously alongside GroupWise Web (using different servers)
My personal opinion of GWWEB:
I was not a fan of GWWEB when it was first released. It was very buggy, and severely lacking in features. However, as the product has matured, it has come a long way. I find that GWWEB is now much easier to use than the old WebAccess, and in fact, I don't even like to use the old version anymore. It's too clunky and hard to navigate. I generally recommend that customers start using GWWEB rather than try to continue with the old WebAccess version. While it is drastically different and takes some getting used to, the streamlined simplistic design and improved functionality is a tremendous improvement.
Prerequisites and System Requirements
It's easy to skim over the system requirements and assume everything is set correctly in your existing GroupWise environment. If you do this with GroupWise Web, you will be in for some challenges. Please review the system requirements and confirm that you meet each requirement.
In summary, the requirements are as follows:
-
Docker 19.03.5 or later on any Docker supported platform.
-
GroupWise 18.3 or later system.
-
GroupWise POA with SOAP enabled. SOAP must have SSL enabled.
-
GroupWise DVA with SSL enabled. ** This is likely going to be where you have issues **
-
(Optional) TLS certificates for GroupWise Web.
I have provided detailed notes on how to ensure that your system is configured to meet these requirements below.
Docker 19.03.5 or later on any Docker supported platform.
Note about Multi-Server environments: In a multi-server GroupWise environment, the Docker requirement is only necessary for the actual server running the GroupWise Web application. Docker does not need to be installed on any other server.
To identify the Docker version, use this command at the Linux command line:
rpm -qa|grep docker
This should produce a list of all RPM's that contain the text "docker", and one of them will show the version number. In the results below from my fully patched SLES15 SP2 system, the version of Docker is 19.03.11.
mhcfs02:/ # rpm -qa|grep docker
docker-runc-1.0.0rc10+gitr3981_dc9208a3303f-6.38.2.x86_64
docker-bash-completion-19.03.11_ce-6.34.2.noarch
docker-19.03.11_ce-6.34.2.x86_64
docker-libnetwork-0.7.0.1+gitr2902_153d0769a118-4.21.2.x86_64
NOTE: If no results are returned, Docker is not installed at all. This is normal if it's a new install. The instructions for installing and enabling Docker are further below in this same document.
GroupWise 18.3 or later system.
To ensure your system is running GroupWise 18.3 or later, use this command at the Linux command line on all servers that are running GroupWise Agents (Post Offices and/or Domains):
rpm -qa|grep groupwise-server
This should produce the rpm module that is installed for the GroupWise software. The resulting output should show you the GroupWise version you are running as shown below:
mhcfs02:/ # rpm -qa|grep groupwise-server
groupwise-server-18.3.0-137352.x86_64
A couple points of clarification for this requirement.
- There's an entire best practice process for a GroupWise 18.3 or GroupWise 18.4 system upgrade and it's not included in this document. However, the general recommendation is that the GroupWise WebAccess or GroupWise Web application should be upgraded/installed after all domains and all post offices have been upgraded.
- In a multi-server GroupWise system, if GroupWise Web will be running on it's own separate and/or dedicated server, you likely do not and will not have the "groupwise-server" modules installed on that server. Check the versions on the servers that are actually running GroupWise agents.
GroupWise POA with SOAP enabled. SOAP must have SSL enabled.
It's very likely you meet this requirement already. But you should confirm the configuration anyway. Points to consider:
- SOAP needs to be enabled on ALL Post Office Agents.
- Enabling SSL on the SOAP protocol on your Post Offices is all or nothing. Meaning it's either enabled for ALL applications that use it or it's not enabled. You cannot mix and match between enabled and not enabled. For example, you cannot have SSL enabled on SOAP for use by GroupWise Web if GroupWise Mobility is set to use SOAP via non-SSL.
- To my previous point, If you do not use SSL for soap, you MUST configure and enable it in order for GroupWise Web to function. You must ALSO consider all other applications that may use SOAP. For any application in your organization that connects to GroupWise via SOAP, you MUST enable SSL on the SOAP protocol. Some applications that use SOAP: Legacy GroupWise WebAccess, GroupWise Mobility Service, and the new GroupWise Web application.
Generally speaking, you can confirm that SOAP is configured to use SSL by looking at the running configuration on each Post Office agent. You do this in the POA Web Console that can be launched from the GroupWise Administration page.

GroupWise POA Configuration Settings |
Internet Protocol Agent Settings: | |
IMAP Agent: | Enabled |
IMAP Port for Incoming IMAP requests: | 143 (Default) |
IMAP over SSL: | Enabled |
IMAP SSL Agent: | Enabled |
IMAP SSL Port for Incoming IMAP requests: | 993 (Default) |
IMAP Read Limit: | 4000 |
IMAP Read New: | Enabled |
SOAP Agent: | Enabled |
SOAP Port for Incoming SOAP requests: | 7191 |
SOAP Proxy Port: | 7191 |
SOAP over SSL: | Enabled |
SOAP Redirection Table: | Show |
If you find that SSL is not enabled on the SOAP protocol, you will need to install a certificate/key pair on each Post Office agent and enable SSL for SOAP on the agent configuration. SSL configuration is out of the scope of this document.
GroupWise DVA with SSL enabled
When SSL is not enabled on the DVA, GroupWise Web will function but you won't be able to view PDF or other docs from within the GroupWise Web application.
Things to understand about the GroupWise DVA:
- The GroupWise DVA is what allows you to view PDF, DOC, and Image files from within GroupWise.
- Each Post Office generally has its own DVA. (This is not absolutely always true)
- The GroupWise DVA is not enabled for SSL by default.
- All DVA's in your entire GroupWise system need to have SSL enabled.
- The GroupWise Administration Console makes you think you're enabling SSL on the DVA but it's not actually doing what you think. More on this below in step 1 of the DVA required configuration.
If this requirement is not met, you'll experience the two things below.
When SSL is not enabled on the GroupWise DVA, you will receive an error that states "Unable to view attachment" as shown below.

When SSL is not enabled on the GroupWise DVA, you will see the following in the Docker log files when you experience this error.
2021/01/05 08:43:41 [error] 16#16: *43 SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL handshaking to upstream, client: 172.17.0.1, server: webmail.redjuju.com, request: "POST /dva HTTP/1.1", upstream: "https://192.168.0.147:8301/dva", host: "webmail.redjuju.com", referrer: "https://webmail.redjuju.com/gw/mailbox/default"
Refer to the Troubleshooting/Log Files section below for information on how to configure and view the log files.
How to configure the GroupWise DVA with SSL Enabled
This four-step process enables the GroupWise DVA with SSL using a self-signed certificate:
1) Tell the POA's to connect to the DVA's via SSL
On the DVA configuration in the GroupWise Administration console, check the box that says "Enable SSL". This tells the Post Office to use SSL when connecting to the DVA. It does not actually configure the DVA with SSL.
Note: It's very confusing, and I don't like the behavior. The dialog makes you believe that you are enabling SSL on the DVA, when in fact you are not. You're only telling the Post Office to use SSL when connecting to the DVA. The checkbox does nothing to actually configure SSL on the DVA. You will need to follow the remaining steps to actually enable SSL on the DVA.
2) Creating the Certificate
Creating the certificates can be accomplished entirely from a SLES 15 Linux command line. The filenames I use are dva.crt, dva.key, and dva.crt. The dva.nopass.key in the first step named "dva.nopass.key" for clarity that it does not have a password at that step.
I like to ensure that I'm in a folder that I have created just for certificates so that I do not get them confused with any other files or certificates.
Create CSR File and Private Key
This command will create the necessary Certificate Signing Request (CSR) and also generate the necessary Private Key file. Note that in this step, the private key file does not contain a password.
openssl req -newkey rsa:2048 -nodes -keyout dva.nopass.key -out dva.csr

Assign a password to the private key
This command will assign a password to the key file you just created. You will be prompted to enter the password.
openssl rsa -in dva.nopass.key -des -out dva.key

Sign the CSR and creates the certificate file
This command will sign the certificate and write it to file. When completed, you should find a "dva.crt" file in the same folder.
openssl x509 -in dva.csr -out dva.crt -req -signkey dva.key -days 3650

3) Configure the DVA Startup File
The DVA Startup file now must be configured to load the certificate and key file. The DVA Startup file is called "gwdva.dva" and is located in the /opt/novell/groupwise/agents/share folder.

Use your favorite text editor to modify the gwdva.dva file. Locate the section titled "Enable SSL for Https" and add the following four (4) lines to it:
−-httpssl
−-sslCert /opt/iso/certificates/dva.crt
−-sslKey /opt/iso/certificates/dva.key
−-sslKeyPassword $q~Nk:_@@cSxk{3ptCALhlHfc
- Ensure that you put your own Key File password, not the one shown above.
- The Password is in clear text. I am unaware of a way to change this.
- Ensure that the path/filenames specify the correct location of the certificate and key file.

Syntax and Location of the DVA Startup File varies on Windows Server. Additionally, openssl is a Linux command line tool. In order the create the certificates as outlined above, it is perfectly acceptable to create them on the Linux server and then copy them to your Windows server.
Windows |
C:\Program Files\Micro Focus\GroupWise Server\Agents\gwdva.dva /httpssl- /sslcert- /sslkey- /sslkeypassword- |
4) Test and Confirm SSL Status on the DVA
Once the configuration changes have been made, log in to the DVA Web interface and confirm that the DVA shows that SSL is enabled and active. The default port is 8301. Assuming you have not changed the default port, you access the Web Agent at the following URL:
https://xx.xx.xx.xx:8301 (Enter the IP address of your Post Office Server here)
If the URL connects securely (and/or asks you to confirm the validity of the certificate), this alone would suggest it is working. However, you can also confirm the status of SSL in the two different places as shown below:
The DVA Log Files will show if HTTPS is inactive.
The verbiage of the logs is a bit vague, but if it shows "https" in the WebConsole URL, then it should be working correctly. I say that it's vague because all traffic, including incoming traffic from the POA, GroupWise Web, and the Web Console page all seem to use this same port, port 8301. This is different in that all other agents use different ports for different functions.
01-11-21 17:53:46 Client/Server Settings: 01-11-21 17:53:46 IP Address: 192.168.2.24 01-11-21 17:53:46 HTTP Port for Incoming Connections: 8301 01-11-21 17:53:46 WebConsole Url: https://192.168.2.24:8301 ----- 01-11-21 17:53:46 WebConsole Url: https://:8301 (Also Possible)
** Also to note, if you have not explicitly configured the DVA with an IP address in the "gwdva.dva" startup file, the log file may omit the IP address from the WebConsole URL. The important thing is that it shows HTTPS.
The DVA Web Console will also show status of SSL on the “Configuration” tab. From this page you should see the necessary information about the certificate and status of SSL. Note that HTTP over SSL shows Enabled, and it shows the path to the SSL Certificate and Key File.
GroupWise Document Viewer Agent Configuration Settings | |
Configuration Settings | |
Agent Version | 18.3.0 -137352 (11/15/2020) |
IP Address | xxx.xxx.xxx.xxx |
DNS Name | xxx.xxx.xxx.xxx |
HTTP | Enabled |
HTTP over SSL | Enabled |
HTTP Port | 8301 (Default) |
HTTP Admin Password Required | No |
Startup File | /opt/novell/groupwise/agents/share/gwdva.dva |
SSL Certificate | opt/iso/certificate/dva.crt |
SSL Key File | opt/iso/certificate/dva.key |
(Optional) TLS certificates for GroupWise Web.
This requirement is extremely confusing because it says that TLS certificates for GroupWise Web are optional. Technically speaking, for the end user interface (From the user's mail in a web browser), this is technically correct. However, there are other areas where TLS is absolutely required.
A best practice for security and confidentiality is to use end to end encryption on your GroupWise system. Not using HTTPS for your Web Mail defeats much of the security that the developers of GroupWise have always taken very seriously.
Be aware that this item does not need to be done beforehand. This requirement can be satisfied after everything else is completed. I have provided detailed information on how to accomplish this with a 3rd party commercial certificate further in this document.
Firewall Requirements
Not much is mentioned in the documentation about the Firewall and required settings in the GroupWise Web portion of the documentation. You will have problems if you don't open the right ports.
It is a best practice to ALWAYS ensure the firewall on the server is active and blocking all unnecessary ports. Disabling the firewall can be useful for testing but it should be enabled before you put the system into production.
GroupWise Web Application access to GroupWise Services
The GroupWise Web Docker app needs to be able to connect to various GroupWise Components:
- The GroupWise DVA, generally port 8301
- The GroupWise Post Office via SOAP, generally port 7191
- The GroupWise Administration Service, generally port 9710.
Connecting to GroupWise Web from a Browser or Device
- In order to access GroupWise web, port 443 (HTTPS) needs to be allowed to the GroupWise Web server.
Helpful Firewall Commands
It's difficult to tell you exactly what you need to do with your firewall. Below are some good reference commands that should help you figure it out.
Enable various ports and services on the firewall.
firewall-cmd --permanent --zone=public --add-service=ssh
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-port=9710/tcp (GroupWise Administration Port)
firewall-cmd --permanent --zone=public --add-port=8301/tcp (Post Office DVA Port)
firewall-cmd --permanent --zone=public --add-port=7191/tcp (Post Office Soap Port)
Put Firewall Changes Into Effect Immediately
Run this command after you've added/deleted a service or port to your firewall list.
firewall-cmd --reload
Start and Stop Firewall Service
systemctl stop firewalld
systemctl start firewalld
Disable and Enable Firewall Service
systemctl disable firewalld
systemctl enable firewalld
Show open services and ports on the firewall
firewall-cmd --list-services
firewall-cmd --list-ports
It should go without saying that the required ports could vary depending on how you have your system setup.
- If you're setting GroupWise Web up on a server that is running all of the GroupWise components (Single Server environment), ports for all the services will need to be opened on the firewall.
- Alternatively, If GroupWise Web is on a dedicated server, or on a server with limited functionality, you'll only open the necessary ports for GroupWise Web to function on that server. However, you will also need to ensure the servers that are running your post offices and admin service have their firewalls configured to allow GroupWise Web to connect.
Adjust your life accordingly.
Installing and Configuring Docker and GroupWise Web
The documentation presents two options for installing the GroupWise Web components without making it abundantly clear that there in fact two entirely different options. Furthermore, the terminology can be confusing and you may not understand exactly what is happening.
The two options are listed below:
- Using the Docker Image (Preferred): This downloads the necessary files from the Micro Focus docker repository on the Internet.
- Using the Micro Focus Download: This uses a downloadable tar.gz file to install docker. The file is obtained as a separate file download from the customer care portal. It is not necessary to download or use this method unless you do not have Internet access on your GroupWise Web server (This would be an extremely rare scenario such as a dark network, or an installation where GroupWise Web is only available to internal systems).
Installation Using the Docker Image (Preferred)
Using the Docker Image is my preferred option, and this is the only method I discuss in this document. This process is an easy three (3) step process that I will outline in detail below. This will follow these steps:
- Install, enable, and start the Docker service
- Download and Run the "web-config" utility
- Download and Run the "GroupWise Web" image
STEP 1: Install, Enable, and Start the Docker Service
In a nutshell, here are the quick and easy steps to get the docker service running:
sudo zypper install docker
sudo systemctl enable docker
sudo systemctl start docker
STEP 1 PART A: Installing Docker
Below is what you should see when you run the “zypper install docker” command. Once it has completed successfully, repeat the “rpm -qa|grep docker” command to confirm that results are returned and the minimum version required is installed.
linux-nd2d:~ # sudo zypper install docker
Refreshing service 'Basesystem_Module_15_SP2_x86_64'.
Refreshing service 'Containers_Module_15_SP2_x86_64'.
Refreshing service 'Desktop_Applications_Module_15_SP2_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP2_x86_64'.
Refreshing service 'Server_Applications_Module_15_SP2_x86_64'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 9 NEW packages are going to be installed:
catatonit containerd docker docker-bash-completion docker-libnetwork
docker-runc git-core libsha1detectcoll1 perl-Error
The following recommended package was automatically selected:
git-core
9 new packages to install.
Overall download size: 50.3 MiB. Already cached: 0 B. After the operation,
additional 235.3 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving package libsha1detectcoll1-1.0.3-2.18.x86_64 (1/9), 23.2 KiB ( 45.8 KiB unpacked)
Retrieving: libsha1detectcoll1-1.0.3-2.18.x86_64.rpm .................................................[done]
Retrieving package perl-Error-0.17025-1.20.noarch (2/9), 40.5 KiB ( 70.5 KiB unpacked)
Retrieving: perl-Error-0.17025-1.20.noarch.rpm .......................................................[done]
Retrieving package catatonit-0.1.5-3.3.2.x86_64 (3/9), 257.2 KiB (696.5 KiB unpacked)
Retrieving: catatonit-0.1.5-3.3.2.x86_64.rpm .........................................................[done]
Retrieving package docker-libnetwork-0.7.0.1+gitr2902_153d0769a118-4.21.2.x86_64 (4/9), 615.0 KiB ( 1.9 MiB unpacked)
Retrieving: docker-libnetwork-0.7.0.1+gitr2902_153d0769a118-4.21.2.x86_64.[done]
Retrieving package docker-runc-1.0.0rc10+gitr3981_dc9208a3303f-6.38.2.x86_64 (5/9), 2.2 MiB ( 9.2 MiB unpacked)
Retrieving: docker-runc-1.0.0rc10+gitr3981_dc9208a3303f-6.38.2[done (1.2 MiB/s)]
Retrieving package containerd-1.2.13-5.22.2.x86_64 (6/9), 10.8 MiB ( 49.7 MiB unpacked)
Retrieving: containerd-1.2.13-5.22.2.x86_64.rpm ..........................................[done (3.5 MiB/s)]
Retrieving package git-core-2.26.2-3.28.2.x86_64 (7/9), 4.9 MiB ( 30.4 MiB unpacked)
Retrieving: git-core-2.26.2-3.28.2.x86_64.rpm ............................................[done (1.7 MiB/s)]
Retrieving package docker-19.03.11_ce-6.34.2.x86_64 (8/9), 31.4 MiB (143.2 MiB unpacked)
Retrieving: docker-19.03.11_ce-6.34.2.x86_64.rpm .........................................[done (3.2 MiB/s)]
Retrieving package docker-bash-completion-19.03.11_ce-6.34.2.noarch (9/9), 112.1 KiB (113.6 KiB unpacked)
Retrieving: docker-bash-completion-19.03.11_ce-6.34.2.noarch.rpm .....................................[done]
Checking for file conflicts: .........................................................................[done]
(1/9) Installing: libsha1detectcoll1-1.0.3-2.18.x86_64 ...............................................[done]
(2/9) Installing: perl-Error-0.17025-1.20.noarch .....................................................[done]
(3/9) Installing: catatonit-0.1.5-3.3.2.x86_64 .......................................................[done]
(4/9) Installing: docker-libnetwork-0.7.0.1+gitr2902_153d0769a118-4.21.2.x86_64 ......................[done]
(5/9) Installing: docker-runc-1.0.0rc10+gitr3981_dc9208a3303f-6.38.2.x86_64 ..........................[done]
(6/9) Installing: containerd-1.2.13-5.22.2.x86_64 ....................................................[done]
(7/9) Installing: git-core-2.26.2-3.28.2.x86_64 ......................................................[done]
(8/9) Installing: docker-19.03.11_ce-6.34.2.x86_64 ...................................................[done]
Additional rpm output:
Updating /etc/sysconfig/docker ...
(9/9) Installing: docker-bash-completion-19.03.11_ce-6.34.2.noarch ...................................[done]
linux-nd2d:~ #
What if Docker is Not Installed / Won't Install
It's possible that Docker will not install because the server does not have the correct container modules configured from the SUSE repository. Here is output from a failed install attempt.
linux-nd2d:~ # sudo zypper install docker
Refreshing service 'Basesystem_Module_15_SP2_x86_64'.
Refreshing service 'Desktop_Applications_Module_15_SP2_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP2_x86_64'.
Refreshing service 'Server_Applications_Module_15_SP2_x86_64'.
Loading repository data...
Reading installed packages...
'docker' not found in package names. Trying capabilities.
No provider of 'docker' found.
Resolving package dependencies...
Nothing to do.
linux-nd2d:~ #
If this happens, you need to enable the "Containers Module" in Yast. To correct this issue, do the following:
- Run the "yast" or "yast2" (Graphical) utility --> Software --> Add System Extensions or Modules.
- Select the "Containers Module 15 x86_64" option --> Next.
- On the Installation Summary screen, click Accept --> Finish.
- Once you have completed this task, retry the Docker installation from the above instructions.
The images below are from the graphical YAST utility and show you what you need to choose.

