Posts by DanielH

    Ah, habs rausgefunden.
    Wenn man über die Teams App eine neue App hochlädt und dann hinzufügt, wird die Permission erst gesetzt/abgefragt wenn ich im Fall von der Starface Teams App, ein Autoprovisioning durchführe.

    Dann mit einem User einloggen der die Berechtigung/Rolle "Anwendungsadministrator". Anscheinend ist diese Berechtigung nicht im Globalen Administrator enthalten (bin hier aber nicht ganz sicher).


    Die Berechtigungen werden im Teams Admin Center (Apps verwalten) nicht sofort sichtbar.

    Allerdings taucht die Starface Teams App nach dem Schritt oben plötzlich in den Enterprise Applications in Azure auf. Hier kann dann die Berechtigung kontrolliert werden oder nötigenfalls korrigiert werden.


    Es wäre hilfreich wenn die Anleitung im Knowledge Base und/oder der Migrationsanleitung etwas mehr Details in dieser Richtung enthalten könnte :)

    Ich werden den Pfad über die Teams App mal durchspielen.

    Was passiert wenn ich die App (welche ja eine andere ist) parallel zu der bestehenden (alten App) hochlade?

    Meiner Meinung sollte das ja klappen.

    Ohne Upload via Teams App, sehe ich jetzt das hier innerhalp der Teams App:

    pasted-from-clipboard.png


    Bei den Berechtigungen sehe ich das hier:

    pasted-from-clipboard.png


    In Azure, eingeloggt als Globaler Admin, sehe ich keine der beiden Apps..


    pasted-from-clipboard.png


    Irgendwoher muss die "alte" Version 2.2.1 ja die Berechtigungen herhaben.

    Und ich muss die fehlenden Berechtigungen bei der 1.0.3 App hinzufügen können.


    Nur wo und wie?


    Daniel

    Hallo Tim,

    Das klärt einiges, vielen Dank.

    • Schritt 3: Ja es ist eine neue App: Daher auch der Versionschritt auf 1.0.3

    Der Name der App ist identisch. Ich habe sie im Teams Portal hochgeladen und sehe nun zwei Apps. Zum Verständnis und auch der besseren Dokumentation gegenüber den Benutzern wäre eine kleine Namensänderung praktischer gewesen. Aber das ist nur ein kleiner Hinweis. :)


    Schritt 4: Sind Sie Systemadministrator für das Azure Portal? Alternativ können Sie die App auch direkt in Teams Hochladen und anschließend als Admin im Azure Portal Organisationsweit bereitstellen. Den Link zum How To haben wir noch in der Knowledge Base hinterlegt. Siehe Schritt 8.

    Ja, ich bin Globaler Administrator.

    Schritt 8 in der Knowledge Base ist leider nicht sehr Aussagekräftig. Die Knowledge Base ist jetzt gerade leider nicht erreichbar, aber soweit ich es im Kopf habe, wird dort nichts von Berechtigungen erwähnt. Das ist eher in der neuen Migrationsanleitung aufgekommen.


    Ich werden den Pfad über die Teams App mal durchspielen.

    Was passiert wenn ich die App (welche ja eine andere ist) parallel zu der bestehenden (alten App) hochlade?

    Meiner Meinung sollte das ja klappen.


    Daniel

    Ich habe hier eine Teams Integration basierend auf Starface 6.7.3.22 welche ich auf Starface 7.3 upgraden muss.

    Die aktuelle Installation funktioniert, allerdings mit Ausfällen welche die neue Version dann nicht mehr haben sollte.


    Die Beschreibung für den Upgrade bzw. Migration finde ich hier: STARFACE MS Teams Integration Migrationspfad 7.3


    Allerdings sind mir ein paar Dinge nicht klar, oder funktionieren nicht so wie beschrieben.

    Insbesonderen auf der MS Teams Seite, wo Starface Support nicht helfen kann oder will.


    Ich hoffe ihr könnt mir hier Hinweise geben:


    Seite Starface:

    Aktualisierung des Moduls STARFACE MS Teams Integration auf PBX

    Die Beschreibung möchte hier dass ich das aktuelle Modul lösche und neu hochlade.

    Mir ist nicht klar ob ich das vor oder nach dem Starface Upgrade von 6.7.2.33 auf 7.3 tun sollte.

    Einerseits könnte (?) der Upgrade auf 7.3. schiefgehen weil eben dieses Modul nicht kompatibel ist, anderseits werden die Modulinformationen ansonsten nicht auf das neue System (7.3) übertragen. Insbesondere verunsichert bin ich wegen dem Modullizenzschlüssel.

    Soll ich das Modul vor dem Upgrade entfernen oder unberührt lassen?

    Wird die Lizenz korrekt übernommen?


    Seite MS Teams:

    Neue STARFACE APP für MS Teams bereitstellen

    Die Beschreibung ist hier relative vage oder scheint nicht mit der aktuellen Installation überein zu stimmen.

    Zum Beispiel ist die installierte App Version 2.3.1 (von Fluxpunkt) aber die neue von Starface hat die Version 1.03. Ist dieser "Rückschritt" der Versionsnummerierung korrekt?

    Ich habe aus Testzwecken die neue App 1.0.3 bei einer anderen Teams Installation hochgeladen.

    1. Laden Sie die neue STARFACE App für MS Teams (V 1.0.3) hier herunter. --> OK
    2. Melden Sie sich als Systemadministrator im Microsoft Teams Admin Center an. --> OK
    3. Im Reiter „Teams-Apps“ / „Apps Verwalten“ den Button „+ Neue App hochladen“ klicken und die neue ZIP Datei hochladen. --> OK (siehe unten)
    4. Anschließend im Microsoft Azure Portal anmelden und im Reiter „App-Registrierungen“ die STARFACE MS Teams Integration auswählen. --> Problem, siehe unten
    5. Im Reiter „API -Berechtigungen“ die Zustimmung „Administratorzustimmung für „Firma XY“ erteilen“ auswählen.
    6. Die Nutzer können jetzt die APP in MS Teams Apps Store herunterladen, sich mit Ihren Zugangsdaten und STARFACE Schlüssel anmelden.
    7. Löschen Sie bestmöglich die alte „STARFACE App für MS Teams“ aus ihrem Azure Portal.


    • Ist Schritt 3 korrekt? Eine NEUE App hochladen und nicht eine neue Version innerhalb der vorhandenen App?
    • Bei Schritt 4 sollte ich in Azure die App bei den App-Registrierungen sehen oder auswählen können. Aber auch nach 24 Stunden sehe ich dort nichts. Ich könnte eine eigenen App registrieren, weiss dann aber nicht was ich dort eintragen sollte. Der Tab "Berechtigungen" in der Verwaltung der Teams App im Teams Admin Center bleibt daher leer. Weil ich eben in Azure keine API-Berechtigungen zuweisen kann.

    Es kann sein dass ich hier etwas nicjht richtig verstehe. In dem Fall wäre ich um einen Hinweis dankbar.


    Daniel

    Gibt es bekannte Probleme in einem Anlagenverbund zwischen einer Starface 6.7.2.33 und einer Starface 7.3?


    Vor dem Upgrade:

    Anlage A (6.7.2.33, Präfix 8 ) und Anlage B (6.7.2.33, Präfix 9) sind im Anlagenverbund. Alles funktioniert seit einiger Zeit perfekt. Der Anlagenverbund hat mehrere Upgrades, auch mit verschiedenen Versionen im Bereich 6.x) klaglos und ohne Probleme überstanden.


    Nach dem Upgrade:

    Anlage A (nun auf 7.3) und Anlage B (immer noch 6.7.2.33) sind immer noch in einem Verbund.

    Probleme:

    • Anrufe zwischen den verbundenen Anlagen schlagen fehl
      • Von B nach A (z.B. Nummer 820):
        • ("Die von ihnen gewählte Nummer existiert nicht oder der Anschluss wurde gelöscht..."
      • Von A nach B (z.B. Nummer 914):
        • Anrufe via Button in UCC oder auf Telefon, kein Summton und keine Verbindung.
        • Anruf via eingetippte Telefonnummer, z.B. 914 am Tischtelefon funktionieren. :?:
    • Tasten /Status
      • Auf Anlage A (7.3) werden B-Benutzer (der Anlage B (6.7.2.33)) mit einem blauen Balken mit drei Punkten angezeigt. Ist der B-Benutzer besetzt wird er korrekt als besetzt angezeigt. Wie schon erwähnt kann der entfernte B-Benutzer aber nicht über die selbe Taste angerufen werden.
      • Auf Anlage B (6.7.2.33) werden die A-Benutzer (der Anlage A (7.3)) abwechselnd als nicht erreichbar (grau) und teilweise korrekt angezeigt (Rot), aber nur wenn der entfernte A-Benutzer anderweitig besetzt ist oder wenn der A-Benutzer in einer Gruppe ist die im Moment angerufen wird (Gelb). Ist der A-Benutzer frei, wird nicht (immer) wie üblich der Status Grün angezeigt.Alle A-Benutzer haben ein physisches Telefon zugewiesen und telefonieren nicht über UCC.


    Bisherige Massnahmen:

    • Verbund getrennt, neu verbunden
    • Tasten neu zugeordnet
    • Verbund komplett gelöscht, neu erstellt
    • Tasten neu zugeordnet


    Was könnte das Problem sein?


    In "federation" Log sehe ich den Aufbau der Verbundverbindung, und mit Level "Debug" auch die Statusmessages die pro Benutzer ausgetauscht werden. Diese Messages scheinen aber nicht konsequent und stabil verarbeitet zu werden.


    besetzt ist.

    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

    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

    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?

    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

    Die Seite unter aurora.sf-app.de war technisch die ganze Zeit erreichbar (wir haben ein Monitoring ;)).

    Die Webseite war erreichbar, aber die Teams Integration war nicht funktionsfähig.

    Ich denke das Ziel wäre einen Service zu monitoren und nicht nur Komponenten davon.

    Und wenn der Service nicht funktioniert, Schritte einzuleiten dass dieser Umstand behoben wird.

    Just my $.02

    Daniel

    Ich möchte nicht unbedingt bis ins Detail diskutieren wie eine solche Statusüberwachung stattfinden könnte, noch zeige ich mit dem Finger auf irgendwelche Verantwortlichen. Das ist mir am Schluss eigentlich egal.


    Fakt ist dass die Teams Integration des öfteren nicht funktioniert.

    Dann meldet sich der Kunde bei mir und ich muss erst mal rausfinden was das eigentliche Problem ist. Nicht immer ist der Service daran schuld. Oft ist es auch ein lokales Problem. Das herauszufinden, dazu sind wir als Partner ja auch da.


    Doch es wäre schön wenn sich Starface dazu entschliessen würde für Funktionen wie den von Starface zu Verfügung gestellten Teams Integrations Service ein Monitoring einzurichten und den Status dann zu publizieren, wie sie es auch auf der Seite https://support.starface.de/status/ für einen Teil der Services tun.


    Auch der Satz "uns erreichen vermehrt Meldungen über Störungen mit MS Teams" sollte meiner Meinung nach gar nicht nötig sein.


    Ich würde von Starface erwarten dass sie den Status des Service selber überwachen und handeln, BEVOR sich Kunden oder Partner vermehrt melden weil ein Service nicht funktioniert.


    Daniel

    Danke für die Erklärung, Fabian.


    Der uptimerobot.com Statusmonitor den Starface verwendet, sollte IMHO auch mit diesem Verhalten klarkommen. Beim Normalverhalten erscheint ja eine "Loginseite" mit einem bestimmten Format.


    Daniel

    GET https://aurora.sf-app.de/2.2.0…end-main/Aurora.bundle.js net::ERR_ABORTED 404

    cloud-connector-client-1.4.16.bundle.js:2 Azure auth redirect result: null

    aurora.sf-app.de/:1 The resource https://aurora.sf-app.de/2.2.0…end-main/Aurora.bundle.js was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.

    cloud-connector-client-1.4.16.bundle.js:2 GET https://cc.aurora.sf-app.de/so…ansport=polling&t=OG90j9h 504

    d.create @ cloud-connector-client-1.4.16.bundle.js:2

    d @ cloud-connector-client-1.4.16.bundle.js:2

    u.request @ cloud-connector-client-1.4.16.bundle.js:2

    u.doPoll @ cloud-connector-client-1.4.16.bundle.js:2

    u.poll @ cloud-connector-client-1.4.16.bundle.js:2

    u.doOpen @ cloud-connector-client-1.4.16.bundle.js:2

    i.open @ cloud-connector-client-1.4.16.bundle.js:2

    u.open @ cloud-connector-client-1.4.16.bundle.js:2

    u @ cloud-connector-client-1.4.16.bundle.js:2

    u @ cloud-connector-client-1.4.16.bundle.js:2

    f.open.f.connect @ cloud-connector-client-1.4.16.bundle.js:2

    f @ cloud-connector-client-1.4.16.bundle.js:2

    f @ cloud-connector-client-1.4.16.bundle.js:2

    l @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    os @ cloud-connector-client-1.4.16.bundle.js:2

    gl @ cloud-connector-client-1.4.16.bundle.js:2

    t.unstable_runWithPriority @ cloud-connector-client-1.4.16.bundle.js:2

    Wo @ cloud-connector-client-1.4.16.bundle.js:2

    ml @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    B @ cloud-connector-client-1.4.16.bundle.js:2

    w.port1.onmessage @ cloud-connector-client-1.4.16.bundle.js:2

    aurora.sf-app.de/:1 The resource https://aurora.sf-app.de/2.2.0…end-main/Aurora.bundle.js was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.

    cloud-connector-client-1.4.16.bundle.js:2 GET https://cc.aurora.sf-app.de/so…ansport=polling&t=OG90nDl 504

    d.create @ cloud-connector-client-1.4.16.bundle.js:2

    d @ cloud-connector-client-1.4.16.bundle.js:2

    u.request @ cloud-connector-client-1.4.16.bundle.js:2

    u.doPoll @ cloud-connector-client-1.4.16.bundle.js:2

    u.poll @ cloud-connector-client-1.4.16.bundle.js:2

    u.doOpen @ cloud-connector-client-1.4.16.bundle.js:2

    i.open @ cloud-connector-client-1.4.16.bundle.js:2

    u.open @ cloud-connector-client-1.4.16.bundle.js:2

    u @ cloud-connector-client-1.4.16.bundle.js:2

    u @ cloud-connector-client-1.4.16.bundle.js:2

    f.open.f.connect @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    setTimeout (async)

    f.reconnect @ cloud-connector-client-1.4.16.bundle.js:2

    f.maybeReconnectOnOpen @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    t.emit @ cloud-connector-client-1.4.16.bundle.js:2

    u.onError @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    t.emit @ cloud-connector-client-1.4.16.bundle.js:2

    i.onError @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    t.emit @ cloud-connector-client-1.4.16.bundle.js:2

    d.onError @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    setTimeout (async)

    hasXDR.t.onreadystatechange @ cloud-connector-client-1.4.16.bundle.js:2

    XMLHttpRequest.send (async)

    d.create @ cloud-connector-client-1.4.16.bundle.js:2

    d @ cloud-connector-client-1.4.16.bundle.js:2

    u.request @ cloud-connector-client-1.4.16.bundle.js:2

    u.doPoll @ cloud-connector-client-1.4.16.bundle.js:2

    u.poll @ cloud-connector-client-1.4.16.bundle.js:2

    u.doOpen @ cloud-connector-client-1.4.16.bundle.js:2

    i.open @ cloud-connector-client-1.4.16.bundle.js:2

    u.open @ cloud-connector-client-1.4.16.bundle.js:2

    u @ cloud-connector-client-1.4.16.bundle.js:2

    u @ cloud-connector-client-1.4.16.bundle.js:2

    f.open.f.connect @ cloud-connector-client-1.4.16.bundle.js:2

    f @ cloud-connector-client-1.4.16.bundle.js:2

    f @ cloud-connector-client-1.4.16.bundle.js:2

    l @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    os @ cloud-connector-client-1.4.16.bundle.js:2

    gl @ cloud-connector-client-1.4.16.bundle.js:2

    t.unstable_runWithPriority @ cloud-connector-client-1.4.16.bundle.js:2

    Wo @ cloud-connector-client-1.4.16.bundle.js:2

    ml @ cloud-connector-client-1.4.16.bundle.js:2

    (anonymous) @ cloud-connector-client-1.4.16.bundle.js:2

    B @ cloud-connector-client-1.4.16.bundle.js:2

    w.port1.onmessage @ cloud-connector-client-1.4.16.bundle.js:2

    aurora.sf-app.de/:1 The resource https://aurora.sf-app.de/2.2.0…end-main/Aurora.bundle.js was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.