So langsam wird es ernst mit dem Upgrade der 3CX-Telefonanlage auf Version 20. Partner haben noch bis zum 01. August 2024, der Rest bis Ende 2024 Zeit.
Zugegeben, wir haben lange beobachtet wie sich die neue Version entwickelt und waren dankbar über immer mal wieder geänderte Fristen. Nun führt kein Weg mehr am Wechsel vorbei. Natürlich erstmal mal bei uns mit unserer NFR, später dann bei den Kunden in der Reihenfolge von der einfachsten bis zur komplexesten Installation mit Puffer für Überraschungen dazwischen.
Die Ausgangsituation ist bei uns und allen Kunden die folgende:
Alle Telefonanlagen laufen auf dem letzten Stand von V18, d.h. Update 9A (Build 31), das “A” wird allerdings nicht angezeigt und unter Linux (installiert mit der 3CX-ISO). Zudem haben alle Anlagen eine aktuelle gültige Lizenz. Es kommen nur OnPrem (keine Cloud-PBX) zum Einsatz, ferner verwenden wir keine SBC oder Router-Telefone.
Bei manchen läuft die Anlage auf einem PC Engines APU-Board, bei anderen auf Intel NUC oder Gigabyte Brix und der Rest ist virtualisiert unter Hyper-V.
Weiter gilt zu klären:
- Läuft 3CX 20 auf PC Engines APU1– und APU2-Boards (nenne wir’s altes “Askozia-Blech”). Die Hardware soll zwar abgelöst werden, da alt und EoL, aber zur Sicherheit sollte die Frage beantwortet für den Fall, das der eine oder andere Kunde die Hardware dennoch weiter betreiben möchte.
- Funktionieren EoL/EoS-Telefone wie das snom 720 weiterhin.
- Welche Desktop-App-Versionen (V16/V18) funktionieren weiterhin.
Grundsätzlich gilt: Jeder muss für seine Anforderungen und Umgebung(en) eigene Tests durchführen!
Vorbereitungen
Es gibt einiges zu beachten und vorab zu erledigen. Zum Einlesen gibt es entsprechende Unterlagen bei 3CX selbst:
3CX – Configuration guides and docs – How to Upgrade to V20
3CX – V20 Upgrade Checkliste & FAQ
3CX – Konfigurationsanleitungen & Hilfestellung
3CX – Konfigurationsanleitungen & Hilfestellung – Adminhandbuch V20
und vorab an den entsprechenden Webinaren teilnehmen.
Hier ein paar wichtige Eckpunkte:
- Systemvoraussetzungen prüfen, d.h. min. 2 CPU Kerne bzw. 2 vCPU, min. 2 GB RAM. Unter Linux kann man dies mit “lscpu” und “free -m” bzw. “free –mega” abfragen.
- Split-DNS für den 3CX-FQDN einrichten.
- Systemeigentümer festlegen, i.d.R. ist das der bei der Installation angelegte Benutzer, zur Sicherheit auf jeden Fall prüfen.
- Prüfen ob der Systemeigentümer sich am Webclient anmelden kann.
- Eindeutige E-Mail-Adresse pro User, mindestens für den Systemeigentümer, vorsichtshalber ggf. alle doppelten Adressen raus nehmen.
- Die Firmware aller verwendeten Geräte sollte auf dem neuesten von 3CX-freigegebenen Stand sein.
Für den Tag X sollte zudem klar sein, das wegen des Upgrades und der Nacharbeiten einige Zeit vergehen kann, in dem die Telefonie nicht wie gewohnt zur Verfügung steht. Daher ggf. beim Provider eine Rufumleitung auf ein Smartphone einrichten.
Nebenbei bemerkt: Bei wem die Provisionierung noch auf IP-Adresse statt FQDN steht braucht sich scheinbar keine Gedanken zu machen, da dies im Laufe des Upgrade offenbar automatisch geändert wird.
Datensicherung
Es sollte mindestens eine aktuelle Datensicherung der 3CX vorliegen. Unbedingt auch den FQDN, die IP-Adresse, die Ports und die Lizenz notieren! Sofern nicht vorhanden die Anrufabläufe zu dokumentieren ist zudem nicht die schlechteste Idee.
Wer seine Anlage virtualisiert hat sollte zudem mindestens einen Snapshot, besser eine Kopie der VM anlegen um im Falle eines Falles wieder zurück gehen zu können.
Bei uns mit alten Blech haben wir die SSD ausgebaut und an einem Windows 11 Pro-Computer mit dem HDD Raw Copy Tool eine zusätzliche Sicherungskopie erstellt. Hierzu wird ein Adapter von mSATA zu SATA bzw. mSATA zu USB benötigt. Von mSATA auf SATA und dann mit einem SATA-USB-Adapter geht natürlich auch.
Tipp: Unbedingt beim USB-Adapter einen mit eigenem Netzteil verwenden. Mit USB-powered Adaptern hatten wir, unabhängig von 3CX bzw. PC Engines, schon so manche Probleme, wie z.B. Abbrüche während des Lesens.
Upgrade
Das Upgrade an sich kann auf verschiedenen Wegen erfolgen:
- Über die Verwaltungskonsole oder
- die Anlage mit der aktuellen V20-ISO neu installieren und während dessen die Datensicherung von der V18 einspielen.
Während des Upgrades wird automatisch eine lokale 3CX-Datensicherung erzeugt. Die Info hierzu erhält man per Mail:
Ein Backup Ihrer 3CX-Telefonanlage auf <FQDN> wurde ohne Fehler abgeschlossen. Es ist keine weitere Aktion erforderlich. Backup-Name: rescueBackupUpgrade.zip Backup-Speicherort: /var/lib/3cxpbx/Instance1/Data/Backups/rescueBackupUpgrade.zip
Dennoch sollte man vorher eine eigene Sicherung erstellt haben, die nicht lokal abgespeichert ist!
Die Dauer des Upgrades ist unterschiedlich, dies abhängt von der verwendeten PBX-Hardware (oder VM) ab. In unserem NFR-Fall auf einem PC Engines APU1-Board dauerte es 49 Minuten. Auf neuerer und schnellerer Hardware sollten es im Schnitt wohl 20 – 30 Minuten sein. Bei zwei virtualisierten 3CX-Systemen dauerte es zwischen 12 – 20 Minuten.
Den Fortschritt kann man mehr oder weniger via ssh wie folgt beobachten:
cd /var/lib/3cxpbx tail -f debian10to12.log
An dieser Stellen haben wir mehrere Meldungen wie diese beobachtet:
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125b-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
Nach dem Neustart war allerdings die Netzwerkverbindung wie gehabt vorhanden, daher haben wir dies erstmal ignoriert.
Troubleshooting
Von Kollegen mit virtualisierten Anlagen bekam ich öfters zu hören, das ein Upgrade erst dann möglich war, wenn virtuelle Diskettenlaufwerke entfernt waren und die VMs als UEFI-Maschinen liefen. Vorher startete mitunter das Upgrade überhaupt nicht oder der obligatorische Neustart nach dem OS-Upgrade schlug fehl. Das klingt entweder nach Hyper-V Generation 1, VMware ESXi und ggf. KVM-basierten VMs.
Zumindest mit unserem PC Engines-Board kann ich die UEFI-Thematik nicht nachvollziehen, da dieses coreboot (also nur BIOS, kein UEFI) unterstützt, das mag allerdings bei anderer Hardware oder je nach Hypervisor anders aussehen.
Nacharbeiten
Wie eingangs erwähnt muss man sich auf verschiedene Neuerungen einstellen. Da wäre beispielsweise der Wegfall der Verwaltungskonsole, administriert wird ab jetzt über den Webclient und das auch nur, wenn die IP-Adresse(n) entsprechend freigegeben sind (ist für’s LAN i.d.R. der Fall, für VPN ggf. nachtragen), andernfalls sieht man den “Admin”-Menüpunkt überhaupt nicht.
Wichtig zu Wissen ist an diesem Punkt, das der Webclient nur in Google Chrome und Microsoft Edge richtig funktioniert. Wer bislang die Administration mit einem anderem Browser durchgeführt hat, stößt nun möglicherweise über solche Probleme wie das man sich erst gar nicht anmelden kann oder Dialoge gleich wieder geschlossen werden oder ungefragt Seiten-Reloads stattfinden, einfach auf eine andere Seite gewechselt wird, usw.
Nach dem Upgrade ist vor dem Update, soll heißen: Direkt nachdem man sich angemeldet hat gleich prüfen ob weitere Aktualisierungen zur Verfügung stehen. Aber Achtung: Mitunter wird bereits etwas im Hintergrund automatisch aktualisiert. Sprachpakete sind so ein Beispiel. Während man als Admin noch verfügbare Aktualisierungen angezeigt bekommt und nach einem Klick auf “Herunterladen” eine Fehlermeldung erhält, ist das eigentliche Update bereits erfolgt.
Unschön ist, das so manches einfach nicht übernommen wird. So waren bei uns die Abläufe hinsichtlich Geschäftszeiten und wo was klingelt bzw. Mailbox oder IVR annehmen soll durcheinander und teilweise die Einstellungen schlicht weg. Wohlgemerkt: Wir haben keine besonders komplexen Abläufe.
Wer im Vorfeld gut dokumentiert hat dürfte relativ schnell alles relevante wieder am Laufen haben. Zwischen Upgrade-Abschluss und bis das die wichtigsten Punkte erledigt waren dauerte es bei uns gut 2 Stunden. Allerdings ist noch einiges zu tun, daher wird es wohl noch den einen oder anderen Blog-Beitrag hierzu geben.
Schlusswort
Auch wenn das Upgrade auf der oben genannten Hardware funktioniert hat und die 3CX darauf gut läuft, so wird dies gleich an mehreren Stellen nicht (mehr) supported. Ein Upgrade wie auf Version 20 ist eine gute Gelegenheit nicht nur die Software zu aktualisieren, sondern ggf. auch die Hardware bzw. VM zu tauschen.
Das Upgrade auf 3CX V20 ist keine einfache Sache. Wie in früheren Versionen einfach draufspielen und weitgehend gut ist’s funktioniert diesmal so nicht. Man muss sich neu orientieren, manches ist an anderer Stelle, manches ist neu und leider ist so manches auch einfach weg oder funktioniert noch nicht richtig. Zu diesem Zeitpunkt ist man bei Update 2 angekommen, Update 3 steht schon vor der Tür, weitere werden sicherlich folgen. Die eine oder andere vermisste Funktion wurde in der Zwischenzeit nachgepflegt.
Für’s erste bin ich nach anfänglichem Stress zufrieden, das ein paar wichtige Tests geklappt haben, auch wenn es dabei mitunter um alte Hardware geht. Die eingangs erwähnten snom 720 Laufen bis jetzt einfach weiter und die V18-Desktop-App tut’s ebenfalls noch. Weiteres wird sich im Laufe der Zeit zeigen, ich werde berichten.
Quellen
3CX – Forum – V18>V20 Upgrade – How long before I give up
Update 01.08.2024
Kleinere Ergänzungen.
Update 07.10.2024
Kleinere Ergänzungen.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Was uns etwas stört, ist die Tatsache das man nur Benutzer bearbeiten kann die im Rechtemanagement unter einem sind. Ich als Rolle “Systemadministrator” sehe meinen Kollegen mit der gleichen Rolle nicht, und kann ihn enstprechend nicht bearbeiten und visa versa, das können nur unsere Vorgesetzten mit der Rolle “Systemeigentümer” – diese sehen wir folglich auch nicht, da über uns im Rechtemanagement .
Dieses ganze neue “Rechtesystem” ist zum teil etwas… nicht nachvollziehbar.
Beispiel
Die Kollegen (Rolle “Benutzer”) aus den anderen Teams konnten ihre eigenen Teamkollegen im Manager Panel nicht sehen, wenn diese Telefonieren, aber dafür die aus den anderen Teams… erst mit der Rolle “Rezeptionist” konnten alle Kollegen auch ihre Teammitglieder sehen… man sollte meinen das wäre umgedreht sinnvoller….
Aber soweit läuft es, wenn man ein paar Dinge in einer RDS Umgebung noch beachtet.