Es ist ein Fehler während der letzten Teamwork-Operation aufgetreten

[jamesMorris]

Wir haben im Büro ein seltsames Problem. 

Bei genau einem User kommt manchmal in einigen Teamwork Projekte die Fehlermeldung siehe Bild, wenn sie "Senden & empfangen" klickt. Der Server ist verfügbar, die Lizenz auch.

Sie muss dann ein lokales PLN speichern, das PLN in eine neues Teamwork Projekt speichern und der Fehler verschwindet wieder. Manchmal hat sie 3 Monate lang kein Problem, manchmal tritt es 3 mal täglich auf. 

Seltsamerweise hatten wir das Problem bis anhin nur bei diesem User. Darum haben wir schon so ziemlich alles Versucht um den Fehler auszuschliessen.

- Neuer PC

- Neues Netzwerkkabel

- andere Netzwerkbuchse

- Neuer Teamwork User

- Neuer Windows User

- 3x versucht mit Graphisoft Support den Fehler zu lösen

Bis anhin war kein Drama, da der User alleine in den Projekten gearbeitet hat. Darum waren unseren bisherigen Supportversuche nicht besonders hartnäckig. Mit dem 4ten Versuch wollen wir dem Problem aber endlich auf die Schliche kommen. 

Ist das Problem sonst irgendjemandem hier bekannt?

Hatte schon mal jemand von Euch die gleiche Fehlermeldung?

[torben_wadlinger]

Der Graphisoft-Support im Bereich BIMcloud ist echt schwach. Wobei ich sagen muss: bei einem anderen Problem mit einer LDAP-Authentifizierung gab es ziemlich gute Unterstützung - die aber am Ende leider zu nichts führte, da der Support in Budapest keine Lösungen lieferte. Am Ende löste sich das Problem von selbst durch Updates.

wir hatten auch mal das Problem, dass die Bimcloud-Lizenzen für einzelne Benutzer sporadisch nicht verfügbar waren. Dann musste man diesem Benutzer die Lizenz fest zuweisen. Hat sich inzwischen aber auch wieder von selbst durch Updates gelöst. Vielleicht hilft das?

[jamesMorris]

Sehe ich leider ähnlich. IDC ist ein typischer first level support, viel mehr als Checklisten und "haben Sie XY probiert" ist da nicht. Was ja auch ok ist, allerdings werden die Fälle nicht nach Budapest eskaliert. Ich habe auch angeboten mit Budapest direkt Kontakt aufzunehmen, damit sie nicht Zwischenhändler und Übersetzer spielen müssen. Bin dazu übergegangen, die Mails direkt in Englisch zu verfassen, wenn die eh weitergeleitet werden. 

"Dann musste man diesem Benutzer die Lizenz fest zuweisen. Hat sich inzwischen aber auch wieder von selbst durch Updates gelöst. Vielleicht hilft das?"

Das ist praktisch nicht umsetzbar für uns, wir haben uns für 15 Netzwerklizenzen entschieden, genau weil wir einen tiefen Gleichzeitigkeitsfaktor haben. 

Aber der Witz ist halt auch, liegt es denn überhaupt an der Lizenz? 

Das habe ich den Support halt auch schon mehrmals gefragt! Die Fehlermeldung ist so nixsagend, es könnte halt alles sein. Der first level Support sagt dazu nur "Es müsste die Mittlere sein, alles andere haben wir ausgeschlossen" und nicht "wir sehen X in den Logs, es muss also  die Mittlere sein". Mir sagt dies eigentlich nur, die haben keinen blassen Schimmer was das Problem ist.

Und Budapest schein kein Bock oder nicht fähig zu sein, die Fehlerquelle zu finden. Sehr schade 😞

[torben_wadlinger]

Das deckt sich mit meinen Erfahrungen mit Budapest. Direkter Kontakt wird vermieden. Was ich allerdings festgestellt habe, ist, dass die BIMCloud auf echter Hardware besser funktioniert als auf virtueller.

Die weite Rahmen, den die Fehlermeldung abdeckt, scheint für mich ein Indiz zu sein, dass GS dort eine Funktion einer zugekauften Software-Bibliothek benutzt, die dann einen Fehlercode ausspuckt. Daher weiß GS wahrscheinlich selbst nicht, was die Fehlerursache ist.

Wir haben aktuell ein Projekt, wo wir als externe Planer über VPN mit einer externen BIMCloud arbeiten. Da bekommen wir auch regelmäßig diese Fehlermeldung. Manchmal muss man es dann mehrfach versuchen oder AC ohne versendete Änderungen und ohne Freigaben beenden und wieder starten und dann klappts in der Regel.

Auch 'ne Methode die Leute zu SaaS zu bekommen ...

[jamesMorris]

dass die BIMCloud auf echter Hardware besser funktioniert als auf virtueller.

Sehe ich auch so. Nur schon wegen dem Netzwerklizenzdongle wollte ich mir dies nicht antun. Gewisse Dinge wie ZFS, Firewall und BIMCloud sind einfach besser bare metal. Den Rest haben wir in VMs und Containern. 

[SchSt]

Hierbei handelt es sich um einen sehr speziellen Einzel-Fall und benötigt für die weitere Klärung weitere Informationen für den Support. 

Der Kunde wurde am 5.4.24 beauftragt LOG Dateien vom Benutzer und vom Server zu schreiben, sowie genau zu protokollieren wann und bei welchen Arbeitsschritten das Problem Auftritt. Erst dann können weitere Schritte zur Lösungsfindung geschehen.

Leider kam bis Dato noch keine Rückmeldung an IDC. Wir bitten Sie daher alle neuen Erkenntnisse, sowie die gewünschten Daten IDC zukommen zu lassen. Damit die Lösungsfindung schneller voranschreiten kann. 

Vielen Dank für Ihre Mithilfe. 

[k_bauschert]

Wurde das Thema "Lokale Daten" ausreichend geprüft?

Bei uns im Büro sind bei Teamwork Problemen zu 95% die lokalen Daten der Auslöser.
Lokale Daten löschen stellt meist wieder die Arbeitsfähigkeit des Nutzers her.

Längerfristig hat es sich ausgezahlt, den Speicherort für die lokalen Daten aus dem Benutzerverzeichnis (C:\user\xxx) herauszunehmen da dieses in einer Netzwerkumgebung auch noch einmal separat mit dem Windows Server sysnchronisiert wird und somit die Gefahr von Timeouts / korrumpierten lokalen Daten steigt.

[jamesMorris]

Hierbei handelt es sich um einen sehr speziellen Einzel-Fall und benötigt für die weitere Klärung weitere Informationen für den Support. 

Diese Informationen hat IDC und Graphisoft alle von mir bekommen. Mehrfach. 

Der Kunde wurde am 5.4.24 beauftragt LOG Dateien vom Benutzer und vom Server zu schreiben, sowie genau zu protokollieren wann und bei welchen Arbeitsschritten das Problem Auftritt. Erst dann können weitere Schritte zur Lösungsfindung geschehen.

Das stimmt so nicht ganz.

Der Kunde (oder besser gesagt ich) hat bereits 2 oder 3 mal sämtlich Logs von Server und Client geschickt. Beim letzten Supportversuch, habe ich ungefragt eine WireShark Aufnahme mitgeschickt, um einen DoS oder Netzwerkproblem ausschließen zu können. So wie ich nie nach Server logs gefragt wurde aber diese ungefragt mitgeschickt habe. 

Am 5.4.24 wurde ich telefonisch kontaktiert.

Das Telefonat dauerte ca. eine Stunde.

Der Supportleiter versicherte mir, ich hätte alles menschenmöglich getan, sie hätten alle Logs und Graphisoft seit ratlos. 

Darum schlug er mir vor, ein Tagebuch in einer Excel Liste zu führen. 

Mein Standpunkt war stets, es muss doch irgendwo in den Logs dokumentiert sein, was genau zur Fehlermeldung geführt hat. 
Wir wissen ja nicht mal, ob es ein Lizenzproblem oder Serverproblem ist. Was genau triggert die Fehlermeldung?

Leider wusste er auch nicht weiter. 

Da mir nicht genau gesagt wurde, was genau in dieses "Tagebuch" rein soll, habe ich mir diese Excel erstellt:

https://cloud.salzmann.solutions/s/3pogeWz7GNWfyPs

Für Ergänzungen wäre ich natürlich sehr dankbar.

Leider kam bis Dato noch keine Rückmeldung an IDC. Wir bitten Sie daher alle neuen Erkenntnisse, sowie die gewünschten Daten IDC zukommen zu lassen. Damit die Lösungsfindung schneller voranschreiten kann. 

Der betroffene User war noch im Urlaub und ist erst seit einer Woche zurück. In dieser Woche ist das Problem noch nicht aufgetreten. 

Wurde das Thema "Lokale Daten" ausreichend geprüft?

Bei uns im Büro sind bei Teamwork Problemen zu 95% die lokalen Daten der Auslöser.
Lokale Daten löschen stellt meist wieder die Arbeitsfähigkeit des Nutzers her.

Längerfristig hat es sich ausgezahlt, den Speicherort für die lokalen Daten aus dem Benutzerverzeichnis (C:\user\xxx) herauszunehmen da dieses in einer Netzwerkumgebung auch noch einmal separat mit dem Windows Server sysnchronisiert wird und somit die Gefahr von Timeouts / korrumpierten lokalen Daten steigt.

Haben wir angeschaut. Von serversynchronisierten User Profilen haben wir uns schon vor Jahren gelöst 🙂

[torben_wadlinger]

Also, ich kann in dem Spiel auch mitspielen. Der Zugriff erfolgt über eine VPN-Verbindung zum AG-BIMCloud-Server. Im Ergebnis sind nicht alle Elemente reserviert. Wenn ich aber eine Gruppe von Elementen reservieren möchte, klappt es. Wir haben uns dran gewöhnt. Weil irgendwie geht's dann zum Schluß doch.

[jamesMorris]

Das Problem tritt bei uns lokal auf.

Ob VPN oder lokal, sollte in einem sauber konfigurierten VPN eigentlich keine Rolle spielen (bei einer stabilen Verbindung).

Was machst Du genau um den Fehler zu provozieren?

Und Du kannst es verhindern, indem Du eine Gruppe von Elementen reservierst?

Du kannst nach dem Fehler, den Stand noch retten?

[torben_wadlinger]

Das VPN ist vom AG auf 5 MBit beschränkt. Daher kommt es hier mit Sicherheit zu time-outs, wenn alles reserviert wird. Beim Speichern haben wir das übrigens auch manchmal. Der Fehler tritt eigentlich immer auf, ich muss da garnix machen. Allerdings kommt es zu keinem Datenverlust, da wir das dann einfach eine halbe Stunde später nochmal versuchen (in der Regel nach 17 Uhr wenn beim Kunden(Baufirma) alle im Feierabend sind ;-).