Install grommunio 2026.06.1: from ISO to usable groupware
This guide was reproduced with grommunio 2026.06.1 on an isolated KVM installation. It takes you from an empty VM to a usable baseline system with Admin UI, grommunio Web, organization, domain, user, mailbox, alias, TLS baseline and local test mail. It is based on the official grommunio release notes, the quickstart guide and the guided installation.
The example values are synthetic: server FQDN mail.example.test, mail domain example.test and user alex@example.test. For production, replace them with real names, public DNS zones and a reachable IP address.
What is grommunio 2026.06.1?
grommunio 2026.06.1 is a major release of the groupware platform. For the appliance, the important points are: the guided installation is based on openSUSE Leap 16.0 or the SLES 16 platform family, and the appliance uses systemd-networkd for network configuration. This makes the base feel more modern and closer to current Enterprise Linux components.
What we are building
We build a grommunio Core installation on the new openSUSE Leap 16 based appliance. Core covers mail and groupware, Admin API, Admin Web, grommunio Web, Postfix, gromox services, MariaDB, Redis and the antispam baseline. Keycloak, Meet, Chat, Files, Archive, backup/DR and monitoring are only positioned here and belong in separate follow-up articles.
Download the appliance and verify the ISO.
Prepare a VM with system disk and optional data disk.
Boot the installer, select the target disk, confirm installation and boot from disk.
Use the CUI, set the root password, verify hostname, network, DNS and time.
Complete grommunio-setup.
Understand organization, domain, user, mailbox, alias and quota basics.
Check Admin UI, grommunio Web, local delivery, queue, logs, TLS and DNS basics.
Architecture, names and DNS concept
Define names and DNS before installation. This avoids later certificate, autodiscover and delivery problems.
Server-FQDN: mail.example.comMaildomain: example.comUser: alice@example.com
`mail.example.com` is the server hostname/FQDN.
`example.com` is the mail domain used for mailboxes.
`alice@example.com` is a concrete user address.
The server FQDN belongs in certificates, PTR, HELO/EHLO and host configuration.
The mail domain belongs in MX, SPF, DKIM, DMARC, domains and user addresses.
Download and verify the appliance
Download the installation ISO from the official grommunio source and verify the provided checksum before booting it. A damaged or wrong image can later cause installer and repository errors that are hard to diagnose.
sha256sum grommunio.x86_64-2026.06.1-Build5.7.install.iso# Expected: the calculated checksum matches the published SHA256 checksum.# If it does not match: delete the ISO, download it again and do not install it.
Screenshot: The boot menu of the verified grommunio 2026.06.1 installation ISO.
Prerequisites and sizing
The vendor minimum for the appliance is 4 CPU cores, 6 GB RAM and a 32 GB system disk. The practical test used 4 vCPU, 8 GB RAM, a 64 GB system disk and an additional 128 GB data disk. The data disk was not mounted for production use in the baseline installation; it only shows how mailbox data can be planned separately later.
CPU/RAM: enough for setup, web access and first tests; production sizing depends on user count, mail volume, search, retention and optional roles.
System disk: operating system, packages, base configuration and logs.
Growing data areas: mailbox data, MariaDB, search/index data, logs, later Archive/Files.
Network: static IP for production, working gateway, DNS resolver and reachable package repositories.
DNS: plan FQDN, MX, PTR, autodiscover, SPF, DKIM and DMARC before go-live.
Create the VM
The following example shows a cleaned-up KVM/QEMU baseline without internal paths. For libvirt or Proxmox, apply the same principles: virtio disks, virtio networking, enough RAM, CPU host passthrough where appropriate and boot from the ISO.
qemu-img create -f qcow2 grommunio-system.qcow2 64Gqemu-img create -f qcow2 grommunio-data.qcow2 128Gqemu-system-x86_64 \-machine q35 \-m 8192 \-smp 4 \-enable-kvm \-cpu host \-drive file=grommunio-system.qcow2,if=virtio,format=qcow2 \-drive file=grommunio-data.qcow2,if=virtio,format=qcow2 \-cdrom grommunio.x86_64-2026.06.1-Build5.7.install.iso \-boot d \-device virtio-net-pci,netdev=net0 \-netdev user,id=net0,hostfwd=tcp:127.0.0.1:8443-:8443,hostfwd=tcp:127.0.0.1:443-:443
For a publicly reachable installation, do not use QEMU user NAT. Use a real bridge, VLAN attachment or hypervisor network interface with a routable address.
Understand storage and data paths
The checked grommunio 2026.06.1 appliance creates a small EFI partition and an XFS root filesystem. This is an appliance observation, not inferred from a generic SLES default. An additional data disk remains unused unless you mount it deliberately. Check where the system actually writes right after first boot.
lsblk -ffindmnt -R / /boot /boot/efidf -hTdu -sh /var/lib/gromox /var/lib/mysql /var/log 2>/dev/null
Beobachtetes Basisschema:/dev/vda2 vfat /boot/efi/dev/vda3 xfs //dev/vdb zusätzliche Disk, nicht automatisch eingebunden
Small installation: one sufficiently large system disk can be enough for an initial production-like single server when user count, mail volume, retention and backup design are manageable.
Production installation: plan mail store, database, logs, search/index data and later Archive/Files separately when growth, backup windows, restore time or I/O load matter.
Do not move mount points blindly afterwards. Check grommunio data paths, service dependencies, backup/restore and maintenance windows first.
Install the appliance
Boot the VM from the ISO, choose the installation option and then the target disk. Installation deletes the selected disk completely. Check disk size and device name before confirming.
Screenshot: Select the target disk for the appliance installation.
Screenshot: The destructive disk operation must be confirmed deliberately.
Screenshot: The appliance image is written to the system disk.
After the write process, finish the installer, remove the ISO from the virtual drive and boot from the installed system disk. If the ISO remains attached, the VM may boot back into the installer.
First boot in the CUI
The first boot opens the grommunio console user interface. Set the root password first. Then verify hostname, network, gateway, DNS and time before starting the setup wizard.
Screenshot: First CUI start: setup has not been run yet.
Screenshot: Set the root password in the CUI.
Screenshot: CUI overview with host, network and setup status.
hostnamectl hostname mail.example.testhostname -fip address showip routedig A download.grommunio.comtimedatectl
Configure networking completely
The 2026.06.1 appliance uses systemd-networkd. First identify the real interface, check whether DHCP is active, then switch to a persistent static address and test the state before and after a reboot.
systemctl status systemd-networkdnetworkctl listip -br linkip -br addrip route
You identify the interface by `UP`, type `ether`, the expected MAC address and the address from your network. Names such as `enp0s2`, `ens3` or `eth0` are environment-specific. Use your own interface name for the rest of the guide.
networkctl status enp0s2ip addr show enp0s2ip route
If the route shows `proto dhcp` and `networkctl status` reports DHCP addresses, the appliance is running dynamically. That is useful for tests; for a public mail server you need a predictable address, consistent firewall rules and PTR matching the sending IP.
A verified persistent path is a dedicated systemd-networkd file in `/etc/systemd/network/`. Replace interface, address, prefix, gateway and DNS servers with your own values. On remote systems, change this only with console or out-of-band access because a wrong address can immediately break SSH.
[Match]Name=enp0s2[Network]Address=203.0.113.10/24Gateway=203.0.113.1DNS=1.1.1.1DNS=9.9.9.9Domains=example.com
install -m 0644 10-enp0s2.network /etc/systemd/network/10-enp0s2.networksystemctl restart systemd-networkdip -br addr show enp0s2ip routeping -c 3 203.0.113.1networkctl status enp0s2
Configure and test DNS resolvers
`resolvectl` and `systemd-resolve` were not present on the checked appliance. `/etc/resolv.conf` was a regular file. Do not blindly use generic systemd-resolved instructions; check the real state of your appliance.
ls -l /etc/resolv.confcat /etc/resolv.confnetworkctl status enp0s2grep -R "^DNS=" /etc/systemd/network /etc/sysconfig/network 2>/dev/null || true
If you set DNS servers in the `.network` file, they must be visible afterwards in `networkctl status` and `/etc/resolv.conf`. In enterprise networks, internal resolvers may be more appropriate than public resolvers. The important point is that repository domains, your mail domain and external recipient domains resolve correctly.
cat /etc/resolv.confgetent hosts download.grommunio.comdig download.grommunio.comzypper refresh
Expected result: resolvers are listed, `getent` and `dig` return addresses, and `zypper refresh` reaches the grommunio and openSUSE repositories. If IP traffic works but hostnames do not, the problem is usually resolver, DNS firewall or proxy.
reboot# Nach dem Reboot erneut prüfen:ip -br addr show enp0s2ip routecat /etc/resolv.confdig download.grommunio.comnetworkctl status enp0s2zypper refresh
No IP: check interface name, match rule and link status.
No default route: check gateway, prefix and network.
IP and route work, DNS does not: check `/etc/resolv.conf`, DNS servers, firewall or proxy.
DNS works, repository does not: check repository URL, HTTPS inspection, proxy, firewall or update channel.
Check hostname, FQDN and time
Set the server FQDN deliberately. It must match DNS, certificate, HELO/EHLO and PTR.
hostnamectl set-hostname mail.example.comhostnamectlhostname -fgetent hosts mail.example.comtimedatectl
Time matters for TLS, authentication and mail delivery. Expected are the correct time zone and a synchronized clock. If `timedatectl` shows no synchronization, configure the intended NTP/chrony path for your environment before using the instance in production.
Prepare the public DNS baseline
The server FQDN and the mail domain are two different things. The FQDN names the host, for example mail.example.com. The mail domain is the part after @, for example example.com.
mail.example.com. A 203.0.113.10example.com. MX 10 mail.example.com.203.0.113.10 -> mail.example.com
dig A mail.example.comdig MX example.comdig -x 203.0.113.10
Forward DNS: the hostname points to the correct IP.
PTR: the IP points back to the sending hostname.
MX: the mail domain points to the mail host.
HELO/EHLO: the mail server announces itself with a consistent name.
Reputation: new or poorly configured IPs are treated carefully by receivers.
grommunio-setup step by step
Start `grommunio-setup` from the CUI. Each dialog affects later operation.
Screenshot: Start of the guided setup wizard.
Role Selection: Core is mandatory. Enable additional roles such as Chat, Meet, Files, Office or Archive only after resources and operations are planned.
Screenshot: Select roles and optional components.
Repository configuration: empty credentials are possible for community repositories in a lab. For production, clarify subscription, support and update channel first.
Screenshot: Repository configuration in setup.
Database selection: the local database is the default for a single baseline instance. An external database is an architecture topic for larger or highly available environments.
Screenshot: Select the local database.
FQDN: enter the server name, not the mail domain. Example: mail.example.test.
Screenshot: Enter the server FQDN.
Primary mail domain: enter the mailbox domain. Example: example.test for alex@example.test.
Screenshot: Enter the primary mail domain.
Relay host: leave empty when the server should deliver directly. Configure a smart host when outbound mail must go through a gateway, security appliance or provider relay.
Screenshot: Relay host dialog in setup.
TLS mode: self-signed is suitable only for labs and tests. In production, use Let’s Encrypt or a trusted enterprise PKI with the correct chain and SANs.
Screenshot: Select TLS mode.
Screenshot: Setup installs and configures the selected components.
Check status, version and ports
After setup, check version, services, ports, repositories and firewall. A successful login alone is not enough.
grommunio-admin versionrpm -qa | grep -Ei 'grommunio-release|grommunio-admin-api|grommunio-web|gromox' | sortsystemctl --failedsystemctl status nginx postfix mariadb redis@grommunio grommunio-admin-api grommunio-antispamsystemctl status gromox-http gromox-imap gromox-delivery gromox-delivery-queuess -tulpnzypper lr -uzypper refreshfirewall-cmd --list-all
In the tested installation, nginx, Postfix, MariaDB, Redis, grommunio-admin-api, grommunio-antispam and the core gromox services were running. Admin Web is on 8443, grommunio Web on 443, SMTP on 25 and Submission on 587.
Screenshot: Admin dashboard with service and system status.
Configure TLS for production
Self-signed TLS is fine for the first bring-up, but it is not a production end state. In production you need a certificate for the server FQDN, the matching private key, a complete chain and a predictable renewal process.
Public CA/ACME: useful when the instance has public names and ACME reachability.
Enterprise PKI: useful when clients use centrally managed enterprise trust stores.
Verification: check hostname, SAN, chain, expiry and protocol negotiation.
Operations: document certificate replacement and reloads before a certificate expires.
openssl s_client -connect mail.example.com:443 -servername mail.example.comopenssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com
Expected result: the certificate matches the server FQDN, the chain is complete, and STARTTLS on submission negotiates TLS without certificate warnings. If the browser or mail client warns, check SAN, chain and stale old certificates first.
Firewall and ports
Open only the ports required for the selected role. The baseline installation does not need a publicly reachable database or Redis.
Dienst Port Protokoll Öffentlich? ZweckSMTP 25 TCP ja, falls direkte Annahme eingehende MailSubmission 587 TCP ja, für Clients authentifiziertes SendenHTTPS 443 TCP ja Web, EAS, EWS, MAPI/HTTPIMAPS 993 TCP optional IMAP-ClientsPOP3S 995 TCP optional POP3-ClientsAdmin Web 8443 TCP Management/VPN AdministrationSSH 22 TCP Management/VPN BetriebMariaDB 3306 TCP nein lokal/internRedis 6379 TCP nein lokal/internRspamd UI 11334 TCP nein lokal/intern
firewall-cmd --list-allss -tulpn
Expected result: SMTP/HTTPS/submission are open only when really needed. Admin and SSH are behind a management network, VPN or IP restriction. Database, Redis and the Rspamd backend remain internal.
Use grommunio Admin
Open the admin interface at `https://mail.example.com:8443/`. After login, global administration is available under Admin on the left, while domain administration is under Domains.
Dashboard: services, system state and mail filter statistics.
Organizations: tenants/organizations.
Domains: mail domains, DNS health, defaults and domain objects.
Users: users, mailboxes, quotas, features and aliases.
Mail queue and logs: first diagnostic points for delivery problems.
Understand and create organizations
An organization groups domains into a tenant. Each domain can belong to at most one organization. Roles such as OrgAdmin can then grant access to multiple domains inside that organization.
Organisation+-- Domain example.com| +-- User / Mailbox alice@example.com| +-- Alias info@example.com+-- Domain example.org
In the Admin UI, open Admin -> Organizations, choose NEW ORGANIZATION, enter name and description, assign domains if needed and save. The test organization was created with this CLI command:
grommunio-admin org create "Example Organization" \--description "Synthetic lab tenant" \--domain 1grommunio-admin org listgrommunio-admin org show 1
Screenshot: Organizations in the Admin UI.
Understand and create domains
The domain is the mail domain, not the server FQDN. `mail.example.com` is the server, `example.com` is the mail domain, and `alice@example.com` is the user address.
In the Admin UI, open Domains, click NEW DOMAIN and set domain name, organization, maximum users, title and optional contact details. The detail view also shows DNS health and default values for new users.
grommunio-admin domain create example.test \-u 25 \--title "Example Test" \--orgID 1grommunio-admin domain listgrommunio-admin domain show example.testgrommunio-admin domain modify example.test -u 50 --title "Example Test Production"
Screenshot: Domain detail view with DNS health and default user parameters.
DNS Health in grommunio Admin
You find DNS Health in the Admin UI under Domains, select a domain, Domain overview. There grommunio shows which records already match and which records are still missing for reliable delivery, autodiscover and client access.
Indicator Meaning ActionGreen / OK check successful keep record and verify externallyRed / Required required check missing or wrong fix before production useOrange / Recommended recommended record missing/unclear configure when the feature is usedBlue / Optional optional record/function configure only when needed
In the visible 2026.06.1 state, Reachability was green, MX was red, Autodiscover, Autodiscover SRV, Autoconfig, SPF, DKIM and DMARC were orange, and DAV/CalDAV/CardDAV/IMAP/POP3/Submission were blue. The UI legend explains these classes directly as OK, Required, Recommended and Optional.
Visible check Status class Meaning ActionReachability OK domain/server is reachable keep itMX Records Required MX is missing or does not match configure MX at DNS providerAutodiscover Recommended autodiscover missing/unclear configure for clientsAutodiscover SRV Recommended SRV autodiscover missing/unclear configure when clients use itAutoconfig Recommended autoconfig missing/unclear consider Thunderbird/clientsSPF Records Recommended SPF missing/unclear define legitimate sendersDKIM Recommended DKIM missing/unclear publish public keyDMARC Recommended DMARC missing/unclear start monitoring policyDAV/CalDAV/CardDAV Optional optional client records configure by client needIMAP/POP3/Submission Optional optional protocol records configure by client need
Configure DNS records at the provider
Work record by record: open the expected value in grommunio, configure it at the DNS provider, verify externally with `dig`, wait for DNS propagation and then refresh DNS Health.
Record Type: AName: mailValue: 203.0.113.10TTL: 300-3600Record Type: MXName: @Priority: 10Value: mail.example.com.TTL: 300-3600PTR:Setzt normalerweise der Server-/IP-Provider:203.0.113.10 -> mail.example.com
dig A mail.example.comdig AAAA mail.example.comdig MX example.comdig -x 203.0.113.10
Publish AAAA only when IPv6 is truly routed, filtered and reputation-ready for inbound and outbound mailflow. Half-configured IPv6 is often worse for mail than no IPv6.
User, mailbox, alias and quota
A grommunio user is the login identity and usually owns a private mailbox directly. Unless you set `--no-maildir`, the mail store is created when the user is created. Quotas are managed on the user/mailbox level in the user detail view; domain `maxUser` limits the number of users in that domain.
In the Admin UI, open the domain, then Users, then NEW USER. Enter username, password, display name, storage quota limit and the desired features. Afterwards, check the detail view.
grommunio-admin user create alex@example.test \--domain example.test \--lang de_DE \--pop3-imap true \--privWeb true \--smtp true \--alias support@example.testgrommunio-admin passwd alex@example.testgrommunio-admin user query username aliases maildir pop3_imap smtp privWeb statusgrommunio-admin user show alex@example.testdu -sh /var/lib/gromox/user/example.test/alex
In the tested CLI, an alias could be set during user creation. Later alias changes through the CLI were not reliable enough in this lab version to publish as a copy/paste path; use the Admin UI for that or check the subcommand help of your installed version.
Screenshot: User list inside the domain.
Screenshot: User detail view with mailbox quota, used space and feature privileges.
grommunio Web and local test mail
grommunio Web is available at `https://mail.example.com/web/`. Log in with the test user. Then send a local test mail on the server and verify it in the inbox.
Screenshot: grommunio Web login.
printf "From: admin@example.test\nTo: alex@example.test\nSubject: grommunio lab test mail\n\nThis test mail was generated locally.\n" \| sendmail -v alex@example.testgromox-mailq
Screenshot: The locally delivered test mail is visible in the inbox.
Check SMTP, TLS, queue and logs
Local delivery checks only the internal path. For SMTP submission, test later from a client against port 587 with authentication and STARTTLS. `swaks` was not preinstalled in the tested appliance; install it deliberately or use an external test system.
swaks --server mail.example.com \--port 587 \--auth LOGIN \--auth-user alex@example.com \--from alex@example.com \--to alice@example.net \--tls
openssl s_client -starttls smtp \-connect mail.example.com:587 \-servername mail.example.com
gromox-mailqjournalctl -u postfix -u gromox-delivery -u gromox-delivery-queue --since "30 minutes ago"journalctl -u nginx -u grommunio-admin-api --since "30 minutes ago"journalctl -u gromox-http -u gromox-imap --since "30 minutes ago"
An empty queue is normal after a delivered test mail. If mail gets stuck, check recipient, DNS, TLS, authentication, queue and the journals listed above first.
SPF, DKIM and DMARC basics
SPF, DKIM and DMARC belong to the production baseline. The Admin UI shows DNS health and DKIM in the domain detail view. DKIM private keys must never appear in screenshots, tickets or documentation.
DKIM: open the domain in the Admin UI, go to the DKIM/DNS area, create or open the public key, note selector, name and TXT value, publish only the public TXT record and verify it with `dig`. Never copy the private key into documents, tickets or screenshots.
dig MX example.comdig TXT example.comdig TXT selector._domainkey.example.comdig TXT _dmarc.example.com
SPF: identify all legitimate senders first. Then build the TXT record, publish it and check mail headers.
DKIM: generate the key in domain administration, publish only the public TXT record, wait for DNS propagation and check again.
DMARC: start with monitoring, for example `p=none`, and move to quarantine or reject only after sender analysis is complete.
Autodiscover/autoconfig: configure only records that match your clients and then refresh DNS Health.
External mailflow and open relay check
A local test mail proves the internal path, but not production mail operations. For go-live, additionally test from outside: inbound SMTP delivery, submission with authentication, TLS, DKIM/SPF/DMARC evaluation and that the server is not an open relay.
# From an external test system:dig MX example.comopenssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.comopenssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com# Defensive check: third-party senders/recipients must not be freely relayed# through your server without authentication.
Expected result: inbound mail for your own domains is accepted, submission requires authentication, third-party relay attempts are rejected without authentication, and sent mail shows valid DNS/authentication headers.
Hardening for production systems
DEFAULT: do not expose database, Redis or internal backend ports publicly.
DEFAULT: operate submission only with authentication and TLS.
RECOMMENDED: restrict SSH to management networks or VPN and prefer keys.
RECOMMENDED: restrict Admin UI to management networks, VPN or IP allowlists.
RECOMMENDED: monitor certificates, DKIM, SPF, DMARC, PTR and MX.
RECOMMENDED: include updates, backups and restore tests in an operating model.
ENVIRONMENT-SPECIFIC: define root login, password login, fail2ban/SIEM integration and central identity integration according to the organization.
Updates, backup and monitoring
Updates are part of operations, not the end of installation. Check repositories, patch list, maintenance window, backup and rollback plan. The vendor describes the cadence in the update cycle documentation.
zypper refreshzypper list-patcheszypper patchsystemctl --failedgromox-mailq
Backup: back up configuration, certificates, database and mail data consistently.
A snapshot is not a backup; restore must be tested in practice.
Monitoring: monitor HTTPS, SMTP, queue, certificates, disk/inodes, MariaDB, Redis, Rspamd, gromox, CPU/RAM, backup age, DNS and available updates.
Final checklist
[ ] FQDN correct[ ] static IP persistent[ ] gateway reachable[ ] DNS resolvers work[ ] reboot test passed[ ] time/NTP checked[ ] A/AAAA configured deliberately[ ] MX configured[ ] PTR configured by provider[ ] TLS certificate matches[ ] firewall checked[ ] organization created[ ] domain created[ ] user created[ ] mailbox exists[ ] alias checked[ ] quota checked[ ] web login successful[ ] local delivery successful[ ] SMTP submission tested[ ] external delivery tested[ ] not an open relay[ ] DKIM published and checked[ ] SPF published and checked[ ] DMARC published and checked[ ] queue empty or understood[ ] logs checked[ ] updates planned/tested[ ] backup planned[ ] restore test planned[ ] monitoring planned
What gets separate follow-up articles
Keycloak / SSO: LDAP, FreeIPA, AD, MFA, OIDC/SAML and break-glass access.
grommunio Antispam 2026: Rspamd, SPF, DKIM, DMARC, DNSBL, Bayes, quarantine and tuning.
grommunio Meet: STUN/TURN, NAT, firewall and SSO.
grommunio Chat: setup, SSO, permissions and operations.
Backup/DR and monitoring: restore tests, RPO/RTO, alerting and runbooks.
Licensing and evaluation
If you are evaluating grommunio or need licenses for a production deployment, ForgeOne can also assist with licensing. As a grommunio Gold Partner, we help select the appropriate licensing model and clarify evaluation or trial-license options for planned environments.
Plan and operate grommunio properly
ForgeOne supports architecture, migration, DNS, security, backup, operations and integration into existing collaboration environments.
