#INR00006 - Aktuelle Probleme beim RZ-Abruf

[#1]

Derzeit kann es zu Problemen beim RZ-Abruf über den Installations-Manager kommen.

Der Abruf bricht mit der Fehlermeldung #INR00006 ab.

Die Kollegen konnten die Fehlerursache bereits eingrenzen und nach derzeitigem Stand ist mit einer Fehlerbehebung für den morgigen Tag, 16.07.2019 zu rechnen.

Sobald alles wieder läuft, werden wir entsprechend informieren

Viele Grüße

Mario Engel

[#2]

Derzeit kann es zu Problemen beim RZ-Abruf über den Installations-Manager kommen.

Der Abruf bricht mit der Fehlermeldung inr00006 ab.

Kann ich bestätigen.

[#3]

Bei mir auch kein KAREWE 7.26 angekommen. Logsamm- zip an DATEV gesendet.

[#4]

Schön das diese Info jetzt auch schon kommt. Wir versuchen seit Freitag die SRs zu ziehen und haben bereits unzählige Stunden in unsere Firewallanalyse gesteckt.

[#5]

Schön das diese Info jetzt auch schon kommt. Wir versuchen seit Freitag die SRs zu ziehen und haben bereits unzählige Stunden in unsere Firewallanalyse gesteckt.

Wie zieht Datev sich hierbei eigentlich aus der Affäre? Die unnütz aufgewendete Arbeitszeit für durch Datev verursachte Probleme ist bei uns mitterweile ein durchaus quantifizierbarer finanzieller Schaden.

[#6]

Ich vermisse hier die Möglichkeit von Funktionstests (so ähnlich wie beim DFÜ-Funktionstest oder wie beim ELSTER-Verbindungs- und -Übermittlungstest).

Inzwischen 'verdächtige' ich eher den Server der Gegenstelle als die eigene Netzwerk-Umgebung, wenn eine Routine-Aktion plötzlich und unerwartet 'zickt'.

Am informativsten wäre eine RZ-Status-App mit RZ-Statistiken und RZ-Zugriffs-Tachos.

Bei einer roten Anzeige braucht man nicht weiter zu probieren.

VG

Michael Vogtsburger

[#7]

Da wird nichts kommen. Wenn ich alleine an die vielen Tage denke, die bei der Umstellung auf das neue Auswertungssystem ins Land gegangen sind...

[#8]

Inzwischen 'verdächtige' ich eher den Server der Gegenstelle als die eigene Netzwerk-Umgebung, wenn eine Routine-Aktion plötzlich und unerwartet 'zickt'.

Ich normalerweise auch. Aber der DATEV Hinweis der seit Freitag kam, hat explizit auf ein Problem mit der lokalen Firewall hingewiesen. Eine so deutliche Aussage ist man von der DATEV eigentlich nicht gewohnt, daher schaut man automatisch erst einmal bei sich selbst, ob da irgendetwas geblockt wird. In dem Fehler wurde dann ja auch noch auf ein bestehendes Info-Dokument hingewiesen, was man dann abarbeitet. Lief alles suboptimal, auch bei der Kommunikation.

Auf mein DATEV Ticket gab es soeben auch eine Antwort, mit einem Link auf diesen Beitrag in der Community 🙂

[#9]

Auf mein DATEV Ticket gab es soeben auch eine Antwort, mit einem Link auf diesen Beitrag in der Community 🙂

Für 9 Euro?

[#10]

Wow !  ... eine Win-Win-Situation

[#11]

Bei mir dasselbe Problem. Ich hatte Donnerstag die MS Updates eingespielt. Freitag morgen kam der Hinweis per Mail Probleme mit dem RZ-Abruf der SW. Freitag Servicekontakt aufgemacht, am Wochenende Firewall, VIWAS Einstellungen und GPO kontrolliert. Heute kam Entwarnung. Ich rege an, solche Probleme bei RZ-Störungen mit aufzunehmen.

VG

Arno Haumann

[#12]

Wir waren auch betroffen. Nur echt komisch, dass 1. nicht alle SR davon betroffen waren und 2. auch nicht alle Kunden? Hatte extra bei einem anderen geschaut und dort wurden alle anstandslos geladen - deshalb bin ich von einem kundenspezifischen Problem ausgegangen, wenn es anderswo geht.

Echt toll .

[#13]

Liebe Community-Teilnehmer,

das Wichtigste vorweg:

Die Fehlerursache wurde ermittelt und wird innerhalb der nächsten 24 Stunden vollständig behoben sein.

Wie kam es zu diesen Problemen beim RZ-Abruf?

Am späten Freitagabend erreichten uns erste gehäufte Servicekontakte mit dem Fehlerbild des #INR00006.

Dieser Fehler trat bisher nur dann auf, wenn es zu Problemen mit Virenscannern oder Firewalls auf Kundensystemen kommt (daher ist der Hinweis auch explizit im Dokument zu dieser Fehlerursache enthalten) – dies wurde unsererseits auch zunächst vermutet.

Nachdem immer mehr Anfragen mit dem gleichen Fehler auftraten, haben wir noch am Freitag Abend unsere Entwicklungskollegen informiert und um Analyse gebeten, ob diesmal ein anderes Fehlerbild dahintersteckt.

Diese haben sowohl Samstag als auch Sonntag nach der Fehlerursache geforscht, jedoch konnte erst am Montag nach Einholung weiterer Logfiles das Problem eingegrenzt werden.

Zeitgleich haben wir Montag vormittags über die Community informiert. Natürlich kann man darüber diskutieren, ob wir 1, 2 Stunden früher hätten informieren können – es mussten aber auch unsererseits erweiterte Logbücher zur Analyse eingeholt werden.

Auch eine Anzeige im RZ-Status wäre denkbar gewesen, jedoch mussten wir auch bedenken, dass eine Vielzahl von Kunden problemlos abrufen konnten und diese wollten wir nicht verunsichern. Dieses Vorgehen müssen wir tatsächlich zukünftig hinterfragen.

Inzwischen hat sich herausgestellt, dass die Ursache für die fehlerhaften Abrufe auf inkonsistente Stände auf den Downloadservern zurückzuführen ist. Davon waren jedoch nicht alle Server betroffen, so dass viele Kunden fehlerfrei abrufen konnten, während andere Kunden leider auf die inkonsistenten Server zugriffen. Die Server werden nun sukzessive neu upgedatet, so dass (bis alle Updates durchgelaufen sind) nur noch mit minimalen Ausfällen zu rechnen ist, die bis morgen vollständig behoben sind.

Wir möchten uns an dieser Stelle ausdrücklich bei allen Betroffenen für die entstandenen Unannehmlichkeiten entschuldigen.

Viele Grüße

Mario Engel

[#14]

Inzwischen hat sich herausgestellt, dass die Ursache für die fehlerhaften Abrufe auf inkonsistente Stände auf den Downloadservern zurückzuführen ist. Davon waren jedoch nicht alle Server betroffen, so dass viele Kunden fehlerfrei abrufen konnten, während andere Kunden leider auf die inkonsistenten Server zugriffen.

Hallo Herr Engel,

wir kennen seit Monaten das Problem, dass einzelne Programme nicht abgerufen werden können und wenn ich es dann mehrfach versuche, habe ich irgendwann alle. Der DATEV Support meinte seinerzeit das liegt an unserer Sophos Firewall. Irgendwie habe ich grade das Gefühl, dass Ihr Problem der inkostistenten Datenbestände auf den Download Servern schon länger existiert. Kann das sein?

[#15]

Hallo Herr Dombrowski,

das Problem mit inkonsistenten Datenbeständen auf den Downloadservern trat am Freitag definitiv zum ersten Mal auf.

In der Tat macht uns gerade die Sophos Firewall häufig Schwierigkeiten beim Download, doch auch an dieser Stelle sind wir dran, um das künftig besser in den Griff zu bekommen und auch entsprechend supporten zu können.

Sie können mir aber ruhig glauben, dass der jetzige Fehler vorher noch nicht aufgetreten ist, denn ansonsten wäre uns auch die Fehleranalyse auch etwas leichter gefallen 🙂

Viele Grüße

Mario Engel

[#16]

Gute Tag Herr Engel,

wir sind als Systempartner der DATEV gerade arg von diesem Problem betroffen. Wir haben Kunden in allen möglichen Konstellationen, on premise mit spez. Firewalls, DATEVnet, in unserem RZ hinter Proxy oder aber auch im DATEV Partner ASP.

Jedoch keiner der Partner-ASP Kunden oder DATEVnet Kunden war betroffen. Ist dies Zufall?

Die Störungen hatten wir jedoch flächendeckend bei anderen Kunden, ja sogar bei Kunden die hinter der gleichen Firewalltechnik gearbeitet haben - einer konnte abrufen, beim anderen fehlen teils wenige Kilobyte für Kanzlei-Rechnungswesen - keine Chance.

Unsere Technik glüht aus, zig Firewall Analysen, Proxy Ausnahmen definieren, Virenscanner abschalten, Bereitstellungen löschen, Eilservice beauftragen, alles half nicht - daher Kundentermine absagen - das ist bitte kein Spaß. Vor allem nicht, wenn die Kanzleien am Freitag schon wegen uns früher Schluss machen und unsere Technik ergebnislos Jugend forscht betreibt.

Da fällt mir nun diese Info von Ihnen auf, die mir den Puls etwas höher schlagen lässt:

"Auch eine Anzeige im RZ-Status wäre denkbar gewesen, jedoch mussten wir auch bedenken, dass eine Vielzahl von Kunden problemlos abrufen konnten und diese wollten wir nicht verunsichern. Dieses Vorgehen müssen wir tatsächlich zukünftig hinterfragen."

Ich sage mal es wäre seit Freitagabend das absolute Minimum im Sinne einer kundenorientierten und proaktiven Kommunikation gewesen, dies im RZ Status kund zu tun, statt es heute -also vier Tage danach wo das Problem immer noch existent -  ist als eine 'denkbare Kommunikation' zu titulieren.

Was spricht denn gegen eine Sprachregelung wie "Vereinzelt kann es beim Abruf der aktuellen Programme per DFÜ zu Fehlern wie #INR0006 kommen, die auf unserer Seite liegen und daher keiner weiteren Maßnahmen bei Ihnen bedürfen. Wir arbeiten mit Hochdruck an einer Lösung." Das habe ich gerade neben dem ganzen Ärger mit Kunden und Technikern mal in einer Minute formuliert, das sollte Ihrem Team sicher auch gelingen und künftig sicherstellen, dass bundesweit niemand sinnlose Maßnahmen  ergreift und damit sich, dem Unternehmen und dem Kunden die Zeit stiehlt.

Die Kunden, bei denen es geht, werden sich sicher schon soweit einig sein oder bemerken, dass sie nicht betroffen sind. Ich sage es deutlicher - deren mögliche Verunsicherung wiegt viel weniger schwer als die Probleme und Ungewissheiten im Rest der Gemeinschaft. Ein Beitrag in der Community ist für mich alles andere als geeignet um solch massive RZ DFÜ Probleme zeitnah mitgeteilt zu bekommen.

Also ich sehne nun nach Ihrer Ankündigung den 17.7. 12:45 Uhr herbei, dass alles wieder zur Normalität zurückkehrt, das wäre hilfreich.

Mit freundlichen Grüßen

Thomas Gruß

[#17]

Sehr geehrter Herr Engel,

vielen Dank für Ihre Rückmeldungen.

Allerdings ist es für die Zukunft sehr hilfreich, wenn Sie die Informationen nicht nur

in der Datev Community veröffentlichen, sondern wie bereits von den weiteren Diskussionsteilnehmern erwähnt, diese RZ-Abruf-Störung auch bei den Datev-Störungen melden. So kann ich mir und meinen Kollegen aus der Datev-Support-Hotline Anrufe ersparen. Die Störung ist bei Ihnen seit Freitag 12:35 Uhr aktiv und ich hoffe, das wir morgen Mittag zumindestens die wichtigsten Service-Releases installieren können. In diesem Zusammenhang gibt es noch eine erkannte Problemstellung mit der VIWAS 10.71 Serverversion, die die eMail-Versendung blockiert. Hierzu soll es eine Mitteilung der Datev unter DANUS erfolgen (bin mal gespannt). Wir haben die Fehlersituation eingrenzen können und die notwendigen Einstellungen vornehmen können.

Mit freundlichen Grüßen

Frank Hilverkus

[#18]

Sehr geehrter Herr Gruß,

Ihre Argumentation kann ich sehr gut nachvollziehen und gebe Ihnen auch ein Stück weit Recht.

Was ich dazu jedoch noch ausführen möchte:

Uns lagen erst im Laufe des Montags gesicherte Informationen vor, dass es sich bei der Fehlerkonstellation um ein Problem mit den Downloadservern handelt. Am Freitag gingen wir noch von Problemen mit Virenscannern bzw. Firewalls auf Kundensystemen aus.

Erst nachdem gehäuft Meldungen kamen, haben wir die Tickets zur Analyse an unsere E-Kollegen gegeben.

Somit war es für uns schlicht nicht möglich, vor Montag eine RZ-Störung zu melden, da wir keine Indizien hierfür hatten.

Wir haben uns dann am Montag für eine Information über die Community und begleitend über die Informations-Datenbank entschieden.

Im Nachgang betrachtet stimme ich Ihnen zu, dass wir parallel dazu eine RZ-Störung hätten melden können/sollen, dies werden wir intern auch besprechen und bei künftigen Problemen (die hoffentlich nicht auftreten werden) auch so handhaben.

Viele Grüße

Mario Engel

[#19]

Guten Morgen Herr marioengel​,

viel schlimmer finde ich es aktuell, dass das Problem noch immer nicht gelöst ist, obwohl Sie MO von einer Problemlösung am DI ausgingen. Leider kommt das bei Ihnen / der DATEV viel zu oft vor, dass Problemlösungen zu angedachten Zeiten nicht eingehalten werden. Aber auch das Thema hatten wir schon ausgiebig diskutiert .

Ich bekomme bei einem Kunden noch immer #INR00006.

[#20]

Hallo Herr Bohle,

wir waren uns am Montag sicher, dass Problem bis Dienstag lokalisiert zu haben.

Die Behebung der inkonsistenten Stände nimmt nun mal leider etwas Zeit in Anspruch, die wir nicht beschleunigen können.

Wir haben versucht, Sie mit unserer Kommunikation stets auf dem Laufenden zu halten und dabei auch "Wasserstandsmeldungen" abgegeben.

Wie gestern bereits geschrieben, sollte im Laufe des heutigen Tages wieder alles reibungslos funktionieren.

Viele Grüße

Mario Engel

[#21]

Hallo Herr Engel,

sorry, aber mit der Bezeichnung "inkonsistente Stände" kann man bzw. kann ich nichts anfangen. Es ist (für mich) ein Aussage ohne Wert.

Sind die erforderlichen Dateien auf den Downloadservern unvollständig, defekt, mit falschen Versionsständen oder mit sonstigen Problemen 'behaftet' oder gibt es direkt mit den Downloadservern technische Probleme (Provider, Bandbreite, Zugriff, Protokolle Hardware etc.) ?

Inzwischen tut man sich anscheinend selbst einen Gefallen, wenn man bei Aktualisierungen nicht bei den ersten ist, die gegen eine Datev-Phalanx laufen.

VG

Michael Vogtsburger

[#22]

Hallo Herr Hilverkus,

bezüglich der VIWAS-Thematik - VIWAS V. 10.71 blockiert den E-Mailversand - gibt es bereits einen Thread.

VIWAS - SR vom 12.7. Ver. 10.71 macht Ärger beim Zugferd-Rechnungsversand

Dort werden wir alle relevanten Informationen veröffentlichen.

[#23]

Liebe Community-Teilnehmer,

leider haben wir soeben erfahren, dass die Probleme wider Erwarten noch nicht behoben werden konnten und nun zusätzliche Tests erforderlich sind.

Sobald es neue Informationen gibt, werden wir umgehend hier wieder informieren.

Viele Grüße

Mario Engel

[#24]

Blöde Laien Frage : Warum schalten Sie die betroffenen Downloadserver nicht einfach ab, oder leiten die Anfragen an einen der anderen Downloadserver um?

Immerhin ist ja so das der RZ Abruf bei einem Berater anscheinend immer fest auf einen bestimmten Server geht, statt einfach aus dem Pool den nächsten zu nehmen.

[#25]

Hallo Herr Rother,

es gibt keine blöden Fragen 🙂

Diese Umgehungsmöglichkeit fließt auch in unsere Tests mit ein, jedoch müssen wir dabei verifizieren, dass es nicht zu ungewünschten Komplikationen mit den vor ort eingesetzten Firewalls und Virenscannern kommt.

Wenn ein Kunde bisher über den bestehenden Downloadserver abgerufen und seine Konfiguration vor ort dementsprechend eingerichtet hat, kann es unter Umständen zu dem ursprünglichen Fehler #INR00006 führen.

Unsere Kollegen testen dieses Szenario aber aktuell, sobald wir Erkenntnisse darüber haben, werden wir die nächsten Schritte einleiten.

Viele Grüße

Mario Engel

[#26]

Bei mir klappt der Abruf wieder!

[#27]

Hallo Community,

als gebranntes Kind gebe ich nun eine "zaghafte" Entwarnung 🙂

Wir haben die betroffenen Downloadserver vom Netz genommen, so dass jetzt alle Kunden auf funktionsfähige und fehlerfreie Server zugreifen.

Der Zugriff wurde bei mehreren Kunden verprobt, auch hier hat der Abruf wie bei Herrn Bohle nun geklappt.

Daher sollte ab sofort wieder ein fehlerfreier Abruf möglich sein!

[#28]

Hallo Herr Engel,

wir wollten gerade per statischem DNS Eintrag bei unseren Kunden erwirken, dass diese auf Server der DATEV zwangsweise gelenkt werden, bei denen es geht nach eingehender Proxy Analyse.

Aber offenbar werden nun die bisher betroffenen Kunden über die gleichen Download-Server der DATEV versorgt, wie die Kunden die keine Probleme hatten. Sicher ein Schritt in die richtige Richtung - bevor nichts geht ist es besser es geht, dauert aber aufgrund der User ggfs. länger. Wir hätten Zeit gehabt, am Freitag, Freitagabend, Samstag, Sonntag, Montag, Dienstag, .... kein Thema!

Die funktionierenden Server

sdownload2.datev.de

sdownload-limelight.datev.de

sdownload-extswbkp.datev.de

sind jedenfalls bei beiden Kundentypen "ok/nicht ok"j etzt gleich und die Downloads laufen wieder !!!

Mit "Limelight" scheint zumindest eine im Gaming Bereich erprobte Massendownload Software verwendet zu werden!

Der "extswbkp" Hosts soll eigentlich DATEVnet Usern dienen laut Info-DB 1002903

Nun - das hatte ich angemerkt, diese Kunden waren auch nicht betroffen

In unseren bisherigen Analysen waren die "defekten" Server mit Akamai Technologie versehen, u.a.

swdownload-akamai.datev.de

Dieser ist jetzt in den Downloads nicht mehr zu sehen und scheint dann Quell des Übels gewesen zu sein

Die Verwendung dieser Servertechnologien von Akamai und Limelight ist bei der DATEV unter Info DB 1080715 referenziert

[#29]

Wir hätten Zeit gehabt, am Freitag, Freitagabend, Samstag, Sonntag, Montag, Dienstag, .... kein Thema!

Am Wochenende arbeitet die DATEV (offiziell) nicht .

[#30]

..Zeit gehabt, wenn die Downloads wegen hoher Last von Freitag bis Samstag gebraucht hätten ....