Cloud Upgrade von 6.7.3.22 auf 7.3 - Was ist zu beachten?

  • Hallo,


    Wegen der Abkündigung von Version 6.7.3.2s (März 2023), sollte ich sämtliche unsere Cloud Anlagen (zurzeit auf 6.7.2.33, ca. 25 Stück) upgraden.

    Das kann über das Cloud Management im Starface Partnerportal mit einem Wunschtermin angemeldet werden.

    Soweit ich weiss wird dann zur gewünschten Zeit Backup gemacht, die 6.x Anlage gestoppt, 7.3 neu aufgesetzt, Backup wieder hergestellt.

    Dazu habe ich diverse Fragen und bitte auch um Erfahrungswerte.


    • Was sind die zu erwartenden Nachkonfigurationsaufwände? Z.B. Modulupdates. Konfiguration neu erstellen (?), etc.
    • Werden alle Starface Module (auch die gekauften) auf die neuste Version gebracht oder muss das von mir nachträglich gemacht werden?
    • Wird die Konfiguration eines 3rd Party Moduls übernommen oder muss ich dieses selbstständig neu installieren und auch konfigurieren?
      • Wir haben bei fast allen 3rd Party modulen die entsprechenden 7.x Versionen bereit. Wo das Modul noch nicht auf 7.3 läuft, warten wir noch mit dem Upgrade.
      • Ich habe ein paar wenige, selbstgeschriebene Module. Alle Module sollten auf 7.3 laufen. Zumindsest habe ich sie euf einer Testanlage ausprobiert.
      • Einige Module habe ich aus dem Forum und auch hier die Version für 7.3 bereit, wenn vorhanden.
    • Ich gehe davon aus dass die Starface WAN IP Adresse ändern wird. Eine Fixe IP ist ja eine Zusatzoption in der Cloud. Ist das korrekt?
      • Kann es Probleme mit den Endgeräten geben?
      • DNS TTL ist auf 10 Minuten. Hier sollte es also recht schnell gehen und wenig Probleme verursachen.
      • Bei einigen Endgeräten (z.B. Gigaset 510) ist deer Provisionierungsserver mit IP Adresse und nicht mit Domänenname angegeben. Wird das angepasst oder muss ich vorgängig überall die Domänenadresse manuell eintragen?
    • Welche Art von (Starface) Support kann ich nach einem Upgrade erwarten? Wird Starface Support hier zur Verfügung stehen oder muss ich am +Morgen danach" mühselig einen Supportfall eröffnen und warten bis sich jemand meldet?
    • Natürlich werde ich vorher einen Backup machen. Da ich aber nicht genau weiss wie der detaillierte Ablauf ist, weiss ich nicht genau wie brauchbar dieser Backup nach dem Upgrades ein wird.
    • Unsere Anlagen sind grösstenteils einfach gehalten und verwenden keine speziellen Module. Natürlich gibt es Ausnahmen.
    • Gibt es Dinge die ich sonst noch beachten muss?
      • Vielleicht hat jemand eine Checkliszte die er mir (uns) zur Verfügung stellen würde?


    Wie ist eigentlich eure Erfahrung mit diesem Upgrade?

    Ganz am Anfang der 7.x Serie, gab es etliches das nicht funktioniert hat und zu Problemen führte. Wir haben aus diesem Grund mit dem Upgrade zugewartet.


    Vielen Dank


    Daniel

  • Wie schon in einem anderen Beitrag geschrieben gibt es hier teilweise Probleme. Meine eigene Anlage war nach dem Upgrade komplett leer. Danach mit Rollback zerschossen und mittlerweile musste ich mir ne neue anlegen. Auch das Backup ist nicht kompatibel und kann nicht verwendet werden. Würde stark empfehlen noch die nächste Version abzuwarten bis das Problem gelöst ist.


    Grüße


    Andi


    support.starface.de/forum/thread/10741/
  • Errare humanum est, in errore perseverare stultum.

  • Wie schon in einem anderen Beitrag geschrieben gibt es hier teilweise Probleme. Meine eigene Anlage war nach dem Upgrade komplett leer. Danach mit Rollback zerschossen und mittlerweile musste ich mir ne neue anlegen. Auch das Backup ist nicht kompatibel und kann nicht verwendet werden. Würde stark empfehlen noch die nächste Version abzuwarten bis das Problem gelöst ist.

    Autsch, das tönt aber gar nicht gut.

    Ich dachte die Probleme seien seit den Anfängen alle behoben.


    Frage:

    Ist es WIRKLICH so dass ein Backup einer Anlage unter 6.7.2.33 NICHT kompatibel ist mit einer Anlage unter 7.3?

  • Autsch, das tönt aber gar nicht gut.

    Ich dachte die Probleme seien seit den Anfängen alle behoben.


    Frage:

    Ist es WIRKLICH so dass ein Backup einer Anlage unter 6.7.2.33 NICHT kompatibel ist mit einer Anlage unter 7.3?

    Ne das Backup war nur bei mir nicht kompatibel.


    Scheinbar ein Datenbankfehler...

  • Dann scheint zum Vorbereiten eines Upgrades sicher mal der folgende Schritt nötig:

    • Backup/Restore testen
      • Backup auf Anlage 6.7.2.33 erstellen, herunterladen
      • 6.7.3.22 Anlage temporär abschalten
      • Testkunde im Coud Portal erstellen
      • Test 7.3 Anlage erstellen, starten
      • Backup zurückladen
      • Konfiguration überprüfen
      • Wenn alles ok zu sein scheint
        • Test 7.3 Anlage wieder stoppen, ev. löschen
        • 6.7.2.33 Anlage wieder starten
        • Weiter in der Updateplanung...

    Abgesehen davon dass einiges nicht funktionieren kann weil meine Testanlage einen anderen DNS Namen hat, sind mir ein paar Dinge aufgefallen.

    Grundsätzlich wurde der Backup anstandslos eingelesen.


    • Da der DNS Name anders ist, funktioniert HTTPS nicht ohne Zertifikatsfehlermeldung. Aus irgendeinem Grund scheine ich bei der getesteten 6.7.2.33 Anlage ein Zertifikat auf CN=anlagenname.starface-cloud.com statt CN=*.starface-cloud.com eingestellt zu haben... Das ist aber ein Problem vor dem Upgrade.
    • Die Lizenzen von Starface Premium App wurden nicht übernommen. Das ist Nachvollziehbar, denn die Serverlizenz hat auch geändert. Ich würd annehmen dass beim richtigen Upgrade entweder die Serverlizenz gleich bleibt oder die Lizenzen anders automatisch (?) übertragen werden. Das sollte meiner Meinung nach auch für alle anderen Arten von Starface Lizenzen passieren. 3rd Party Lizenzen werden wohl etwas anders gehandhabt?
    • Der Anlagenverbund scheint auch korrekt übernommen worden zu sein. Allerdings habe ich diesen Teil, da weniger wichtig, nicht bis ins Detail getestet


    Fragen:

    • Die Telefonprovisionierungsdaten (Passwärter, etc.) müssen wohl neu übermittelt werden (Warndreieck bei den Telefonen). Das heisst dass dieser Schritt nach dem Upgrade einen neuen reboot der Telefone benötigt. Stimmt ihr mir da zu?


    Ich denke ich werde den Upgrade bei dieser Anlage mal wagen...


    Daniel

  • Hallo Daniel

    • Was sind die zu erwartenden Nachkonfigurationsaufwände? Z.B. Modulupdates. Konfiguration neu erstellen (?), etc.
    • Werden alle Starface Module (auch die gekauften) auf die neuste Version gebracht oder muss das von mir nachträglich gemacht werden?
    • Wird die Konfiguration eines 3rd Party Moduls übernommen oder muss ich dieses selbstständig neu installieren und auch konfigurieren?
      • Wir haben bei fast allen 3rd Party modulen die entsprechenden 7.x Versionen bereit. Wo das Modul noch nicht auf 7.3 läuft, warten wir noch mit dem Upgrade.
      • Ich habe ein paar wenige, selbstgeschriebene Module. Alle Module sollten auf 7.3 laufen. Zumindsest habe ich sie euf einer Testanlage ausprobiert.
      • Einige Module habe ich aus dem Forum und auch hier die Version für 7.3 bereit, wenn vorhanden.

    Die STARFACE integrierten Module kannst du nach dem Anlagenupdate via dem normalen Updateprozess Updaten.

    Was Drittanbietermodule angeht, diese musst zum grossen teil von Hand upgraden:

    Aus dem Thema: RE: STARFACE 7.3.0.5 (Major Release) - Beta online

    • Ich gehe davon aus dass die Starface WAN IP Adresse ändern wird. Eine Fixe IP ist ja eine Zusatzoption in der Cloud. Ist das korrekt?
      • Kann es Probleme mit den Endgeräten geben?
      • DNS TTL ist auf 10 Minuten. Hier sollte es also recht schnell gehen und wenig Probleme verursachen.
      • Bei einigen Endgeräten (z.B. Gigaset 510) ist deer Provisionierungsserver mit IP Adresse und nicht mit Domänenname angegeben. Wird das angepasst oder muss ich vorgängig überall die Domänenadresse manuell eintragen?

    Unsere alten Clouds haben die IP von 6.7 auf 7.0/7.1 behalten, und es sind auch keine Zusatzkosten entstanden.

    Diese Zusatzkosten für eine statische IP entstehen nur bei einer neuen Anlage.

    Sie können dir vermutlich schon rein aus Vertraglichen Gründen deine öffentliche IP nicht einfach so wegnemen.


    • Welche Art von (Starface) Support kann ich nach einem Upgrade erwarten? Wird Starface Support hier zur Verfügung stehen oder muss ich am +Morgen danach" mühselig einen Supportfall eröffnen und warten bis sich jemand meldet?
    • Natürlich werde ich vorher einen Backup machen. Da ich aber nicht genau weiss wie der detaillierte Ablauf ist, weiss ich nicht genau wie brauchbar dieser Backup nach dem Upgrades ein wird.


    Wir ziehen jeweils ein Backup der 6.7.3, und ich habe ein virt. 7.X Maschine mit einem prüfpunkt, dort spielen wir das Backup dann testweise, ohne Lizenzen ein, um zu schauen, ob der Recovery vorgang abschliesst.


    Wenn das passt, wir die VM wieder auf den Prüfpunkt zurückgesetzt.

    Somit kannst du die gleiche VM für wiederholte Backuprecovieries verwenden, und musst nicht dauernd Clouds erzeugen/löschen nur um es zu testen.


    Was den STARFACE Support angeht, erhälst du den ÜBLICHEN Support.


    MfG


    Fabian

    • Offizieller Beitrag

    Autsch, das tönt aber gar nicht gut.

    Ich dachte die Probleme seien seit den Anfängen alle behoben.


    Frage:

    Ist es WIRKLICH so dass ein Backup einer Anlage unter 6.7.2.33 NICHT kompatibel ist mit einer Anlage unter 7.3?


    Bisher wurden über 2.500 Updates auf die 7.3. durchgeführt und über 99% aller Updates sind dabei fehlerlos abgeschlossen worden.

    Bei den wenigen Fällen, bei denen das Update nicht funktioniert hat, handelte es sich um Backups mit fehlerhaften Datenbankeinträgen.

    Alle Partner, die auf ein Problem beim Update stoßen, können sich gern an den Support wenden. Der Support kümmert sich mit hoher Priorität um diese Fälle.


    Beste Grüße

    Daniel

  • Bei den wenigen Fällen, bei denen das Update nicht funktioniert hat, handelte es sich um Backups mit fehlerhaften Datenbankeinträgen.

    Ist bekannt wie diese fehlerhaften Datenbankeinträge zustande gekommen sind?

    Unsere Konfiguration ist übrigens vom Januar 2008 (!) ;)

  • Hallo Daniel,


    der Support hatte sich bei uns bisher schnell darum gekümmert und auf Wunsch die Instanzen mit einem 7.2 Image wiederhergestellt, unter dem sich auch das Backup wiederherstellen ließ. Den "üblichen" Support, den Fabian angedeutet hat, hat die Thematik also nicht ;)


    Aber das mit den 99% muss schon fair sein: Bezieht sich das auf 2.500 Cloud Updates oder insgesamt alle Updates (Cloud + Lokal)? Wenn solche Angaben gemacht werden, sollte zwischen Cloud und Lokal differenziert werden, da das Problem - nach unserem Stand - nur Clouds betrifft.



    Viele Grüße

    Peter

    • Offizieller Beitrag

    Ist bekannt wie diese fehlerhaften Datenbankeinträge zustande gekommen sind?

    Unsere Konfiguration ist übrigens vom Januar 2008 (!) ;)

    Die Ursache ist eine inkorrekte Modifikation der Datenbank. Module können mit vollem Zugriff auf die Datenbank z.B. Contraints löschen und damit für unerwünschte Nebeneffekte wie die hier angeführten herbeiführen.

    Eine genauere Aussage könnten wir nur durch eine Analyse aller betroffenen Systeme führen, im Kontext der zu dem Zeitpunkt des erstellten Backups installierten Module und der jeweils ausgeführten Operationen, d.h. wir bräuchten dafür die entsprechend (alten) Log Files aller betroffenen Installationen - rückwirkend.

    Da wir diese Möglichkeit des direkten DB-Zugriffs aktuell nicht einschränken wollen, sehen wir hier vor allem eine Absicherung im Backend über eine entsprechende Validierung als zielführend.

    • Offizieller Beitrag

    Hallo Peter,


    die Updates verteilen sich ca. 50/50 auf Clouds und lokale Installationen. Auch nach der differenzierten Betrachtung liegen die gemeldeten Fälle unter 1% und verteilen sich ca. 50/50 auf Clouds und lokale Installationen.


    Viele Grüße

    Daniel

  • Danke an alle.


    Ich hatte folgendes vorbereitet aufgrund der Rückmeldungen von euch und den anderen Forumsbeiträgen die ich gefunden habe.

    Es wäre in der Tat toll wenn es irgendwo eine Checkliste oder dergleichen gäbe, welche die "Best Practices" für den Upgrade von Cloud Anlagen von 6.7.x auf 7.3 auflisten würde.

    Mir scheint dass es doch einige unter uns gibt welche entweder mit Problemen konfrontiert wurden, oder einfach sehr vorsichtig und zurückhaltend sind.

    Eine "beruhigende" Anleitung würde schon helfen.. Mir jedenfalls schon.


    OK:


    • Ich habe sämtliche nicht-Starface Module deaktiviert und deinstalliert (gemäss FabianZ, sicherheitshalber mit deinstallation)
      • Wahrscheinlich Overkill, aber ich wollte einfach sicher gehen
    • Backup vorher auf einer Testanlage getestet (Recovery).
      • In Zukunft werde ich das mit einer lokalen VM machen wie es FabianZ vorgeschlagen hat.


    Ich habe den Upgrade vorgenommen. Fazit:

    • Mit der entsprechenden Vorbereitung gut durchgelaufen.
    • Die Module mussten manuell ge-updatet werden
    • Ich muss nun die gelöschten Module wieder installieren und konfigurieren. Keine grosse Sache da eine einfache Anlage.
    • Der Upgrade wurde auf 17:33 bestätiigt. Tatsächlich wurde die alte Anlage erst um 17:52 heruntergefahren. Die neue Anlage war um ca. 18:15 wieder da. Allerdings nur teilweise brasuchbar. Ich denke im Hintergrund wurde noch das eine oder andere fertig gemacht.
    • Telefone müssen das Passwort erneut zugesendet bekommen. War zu erwarten.
    • Ich habe noch ein Problem mit dem SSL Zertifikat. Aber das ist wahrscheinlich mein eigenes Versehen.
      • (Weiss jemand zufällig wie man das Standard CN=*.starface-cloud.com wieder aktiviert oder muss das Starface tun?)


    Noch sind einige Tests nötig, aber es sieht eher gut aus :)


    Danke an alle!!


    Daniel

    • Ich habe noch ein Problem mit dem SSL Zertifikat. Aber das ist wahrscheinlich mein eigenes Versehen.
      • (Weiss jemand zufällig wie man das Standard CN=*.starface-cloud.com wieder aktiviert oder muss das Starface tun?)

    Ticket aufmachen bei Starface.

    Philipp Sander


    3NET GmbH

    Microsoft Solutions Partner | DATEV Solution Partner

    Tel: +49 40 254045-25

    www.3net.de

    STARFACE Excellence Partner

  • Die Ursache ist eine inkorrekte Modifikation der Datenbank. Module können mit vollem Zugriff auf die Datenbank z.B. Contraints löschen und damit für unerwünschte Nebeneffekte wie die hier angeführten herbeiführen.

    Das ist so ein Beispiel, warum setzt ihr diesen einfachen Datenbankaufruf nicht mal endlich um?

    Ja OT ich weiß...

    • Offizieller Beitrag

    Das ist so ein Beispiel, warum setzt ihr diesen einfachen Datenbankaufruf nicht mal endlich um?

    Ja OT ich weiß...

    Hallo Slu,

    Daran arbeiten wir auch gerade. Im letzten Satz gab es einen Hinweis meinerseits dazu "... sehen wir hier vor allem eine Absicherung im Backend über eine entsprechende Validierung als zielführend."


    Eine automatische Korrektur werden wir allerdings aus verschiedenen Gründen nicht einbauen.


    Viele Grüße

  • Die STARFACE-DB hat nach mir keine Constraints die eine Löschung Verhindern könnten..

    Man kann in der DB z.b. direkt einen Account löschen, obwohl dieser noch Funktionstasten, Rufnummern, Telefone ect. besitzt.


    Somit erzeug man dann Verwaiste DB-Einträge.

    Die account Tabelle hat 5 eigene Foreign Key Constraints und wird von weiteren 21 Tabellen als Foreign Key referenziert :)


    Die genannte Aktion "account löschen" würde über Cascade-Verknüpfungen auf die Funktionstasten, Rufnummern und Telefonzuordnungen diese Entfernen :)


    Die korrekte löschung findet also mit reinem Code, ohne Absicherung von seitens DB statt, dass würde heissen, wenn sich da ein Bug einschleichen würde und die STARFACE bei der löschung von einem Benutzer irgendwo die anderen Tabellen nicht leert, so auch verwaiste Einträge entstehen könnten, anstatt dass die DB sagt "Hey! Du kannst den Benutzer nicht löschen, bevor du nicht seine Funktionstasten, Rufnummernzuweisung, Telefonzuweisungen ect. entfernt hast"


    Es könnte gut sein, dass eines meiner Module wie z.b. der Adressbuch Importer, oder das Funktionstaten Klonmodul, welche einwandfrei Funktionieren irgendwelche Probleme in der DB erzeugt haben, welche mir nicht Ersichtlich sind, und sich im alltag auch nicht aufzeigen..


    Wohlgemerkt, dass diese nicht die REST-API verwenden, sondern die STARFACE internen Funktonen, da es die REST-Schnittstellen zu der zeit, als diese Module entwickelt wurden noch nicht gab, und es keine Dokumentation zu diesen Schnittstellen gibt, welche ich, und auch viele andere Drittanbieter von STARFACE Modulen verwenden.


    Z.b.

    Von der 7.1 zur 7.2 wurden jetzt aber Constraints beim Adressbuch hinzugefügt.

    Felder, welche keine Werte enthielten, durften plötzlich nicht mehr "null" sein, sondern mussten entweder "leer" sein, oder nicht erwähnt werden.

    Es kann also gut sein, dass wenn jemand von der 7.1 auf die 7.3 hüpft, alte Adressbucheinträge mit "null" werten ein Problem darstellen könnten.


    Ich wäre froh, wenn die STARFACE eventuell Details zu den beschädigten DB-Einträgen freigeben könnte, eventuell könnten so die Modulentwickler ermitteln, ob sie zukünftig etwas korrigieren müssen.

    MfG


    Fabian

  • Die account Tabelle hat 5 eigene Foreign Key Constraints und wird von weiteren 21 Tabellen als Foreign Key referenziert :)


    Die genannte Aktion "account löschen" würde über Cascade-Verknüpfungen auf die Funktionstasten, Rufnummern und Telefonzuordnungen diese Entfernen :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!