bea-Karten-Registrierung

[#1]

Ok, Herr Zelder.

Es liegt also nicht am Kartenleser (Sie haben einen anderen als ich).

Aber wir schauen beide auf den blauen Bildschirm....(völlig unabhängig voneinander..)

Ok, ich habe das ganze natürlich auch noch an die Hotline der BRAK gemailt...

Mal sehen, wie das endet....

Danke Ihnen aber trotzdem!

[#2]

Hallo Herr Hofmeister,

ich verzage nicht; mein Blutdruck nähert sich nur langsam dauerhaft einer Region die ungesund ist.

Ich liebe es unheimlich wenn Leistungen an Dritte vergeben werden ohne dass die technischen Spezifikationen verbindlich festgelegt werden.  Meine Mandanten erhalten in diesen Fällen eine schöne Belehrung, dass sie einen (Großteil) ihrer Forderung höchst wahrscheinlich unter "Lehrgeld" verbuchen bzw. ausbuchen dürfen. Im Fall des beA tragen die Kosten die (zwangsverpflichteten) Nutzer, d.h. wir.

Einstweilen habe ich unter Hinweis auf die Mindestanforderungen der BRAK den Schwarzen Peter der BNotK zugeschoben.  Die sollen sich um eine technische Lösung kümmern. Bin gespannt wie die BNotK reagiert.

colorandi causa:  habe Sie mal versucht den Vorgang mit dem Edge-Explorer von MS durchzuführen?  Ich bin mir nicht sicher, ob die BRAK / ATOS trotz der Ankündigung, dass jeder gängige Browser genügen soll, in der Lage ist, eine Anmeldung hierüber zu gewährleisten.

Es bleibt spannend.

Nachtrag:  Die Erklärung der BNotK : "Der Grund dafür, dass für die SAK ein Chipkartenlesegerät der Klasse 3 benötigt wird, liegt im Signaturrecht. Technische Komponenten, die für die qualifizierte elektronische Signatur verwendet werden dürfen, müssen gem. § 15 Abs. 7 S. 1 Hs. 1 SigG vorab durch eine bestätigende Stelle geprüft werden. Diese Komponenten werden zum Prüfzeitpunkt nach dem Stand der Technik und den Vorgaben des Signaturrechts evaluiert und bestätigt. Die Konformität der von der Zertifizierungsstelle der Bundesnotarkammer angebotenen Signaturanwendungskomponente (SAK) mit diesen Anforderungen wurde 2016 bestätigt. Beim Design der Anwendung wurden nach Stand der Technik nur aktuelle Chipkartenlesegeräte mit einem Display (Klasse 3 – Chipkartenlesegeräte), die seit ca. 15 Jahren erhältlich sind und deutliche Sicherheitsvorteile gegenüber Chipkartenlesegeräten ohne Display (Klasse 2 – Chipkartenlesegeräte) bieten, berücksichtigt. Die Signaturanwendungskomponente der Bundesnotarkammer ist damit nur mit Klasse 3 – Chipkartenlesegeräten nutzbar.

Sie müssen Ihren PIN nicht ändern (wir empfehlen es aber) und damit auch nicht die Anwendung zur PIN-Verwaltung nutzen. Wenn das für Sie annehmbar ist, könnten Sie mit der PIN aus dem PIN-Brief Ihre tägliche Anmeldung am beA ab dem 29.09.2016 vornehmen und Ihr bisheriges Kartenlesegerät behalten. "

[#3]

Hi @all bea-Karten-Registrierungs​​gequälten DATEV Admins 😕 ,

Da ich Herausfoderungen liebe (denn man kann an Ihnen nur wachsen) habe ich mir wegen diesem Thema schon so manchen Abend um die Ohren geschlagen... ob- notwenig oder nicht, es hat mich gepackt... bei dem einen gehts beim anderen nicht  hmmmmm aber endlich gewonnen!

Ich möchte Ihnen diese Lösung die in userem Fall funktioniert hat nicht vorhenthalten, evtl hilft das jemandem hier weiter, auch aufgrund von diversen Aussagen seitens der DATEV habe ich mich nun registriert....

Wir hatten seit Wochen das Problem das die bekannte Webseite nach der Ausführung des Java Applets ewig lud und dann " Die Verbindung zur Server-Komponente ist fehlgeschlagen " meldete.

Für uns fand ich aber schlussendlich die Lösung:

- Standardwert des internen Ports im aktiven DATEV DFÜ Profil über Internet von Port 10000 auf 10001 ändern...

Situation:

- Es wurde  der Anleitung des Herstellers entsprechend die Ports 443 (i.d.R eh schon offen) und 10000 freigeschalten

- Es ist das Programm DATEV RZ-Kommunikation(PRO) installiert.

- Es ist ein DATEV DFÜ Profil "...über Internet" aktiviert

- Es ist die aktuelle Version von Java installiert und im Browser aktiviert.

- Es sind die dem Kartenleser beigelegten/verwiesen Treiber vor* dem einstecken des Gerätes installiert worden.

- Es ist der Kartenleser mit Karte gesteckt und meldet auch keine Probleme

   (so, augenscheinlich alles an Anforderungen erfüllt... leider hat das die Webseite erstmal gar nicht gejuckt... :/)

Problem:

Webseite meldet:

Abhilfe die für uns funktioniert hat:

Da der Port 10000, laut der Anleitung des Herstellers des Programmes, ja ...wie sag ich das...nicht unrelevant ist habe ich mal geschaut was am 10000er lokal los ist und folgendes gefunden/ausprobiert:

RZ-KOMM>DFÜ Profilverwaltung>Das aktive Profil markieren>R.Klick>Ändern>Startwert des internen Ports von 10000 (scheint tatsächlich der Standardwert zu sein) auf 10001 geändert>OK

Wenig hoffnungsvoll erneut die bekannte Webseite versucht, heruntergeladene JAVA Anwendung ausgeführt und siehe da - es klappte nach "kurzer" Ladezeit , es kam kein Fehler mehr (Java Konsole- wenn aktiviert zeigt lediglich diverse "INFORMATION" Einträge an)  und der Prozess konnte ohne weitere Probleme zu Ende geführt werden.

Auf die vermutliche Ursache in unserem Fall muss ich hier, glaube ich nicht weiter eingehen.

Wenn nicht, wie in diesem Fall vermutlich das DATEV DFÜ-System den Port belegt, ist es evtl. ein anderes (z.b. Anti-Vir) Prog.,eine Fehlerhafte Firewallregel oder eine Serveranwendung auf localhost und dem Port 10000 lauft. usw..

der Grund.

                                                         Done till here

*Möglicher Fehler mit dem "eigentlich richtigen (geforderter Typ)Leser" der mir in einem anderen Zusammenhang schon mal untergekommen ist:

- Der Leser wurde vor dem Installieren der "mitgelieferten" Treiber eingesteckt und Windows hat sich irgendwas(falsches) gezogen und damit den Leser (scheinbar fehlerfrei) installiert. Stellt daruch aber evtl. nicht den vollen funktionsumfang bereit.

>neuen Leser stecken >Deinstallation des neuen Lesers aus dem Gerätemanager(bitte mit Vorsicht walten und den Datev Smartcard Leser, falls parallel gesteckt besser vorher ziehen)>neuen Leser ausstecken>Installation des Herstellertreibers>neuen  Leser einstecken>evtl. Kartentest laufen lassen und entsprechend des Ergebnisses weitermachen...

- Virtuelle Maschine mit " Smartcard" aber ohne USB Controller im Gerätemanager> USB Controller virtualisieren

- Am WTS: es fehlt lokal in der RDP Verbindung der Haken bei den Lokalen Ressourcen "Smartcards"

> Haken setzten>neu verbinden.

In userem Fall hat der Hersteller ein kleines Testtool mit den Treibern Installiert. Mit diesem kann man die Funktionsfähigkeit des Lesers/der Karte testen und als Fehlerquelle ausschließen oder eben erkennen.

- Mögliche unverträglichkeit/IRQ verletzung mit vorhandenen Treibern> hatte ich noch nicht aber möglich.

In meinen meisten Fällen der VErgangenheit konnte der neue Leser meiner Erfahrung nach auch den "alten" DATEV Smartcard Leser ersetzen da er auch mit einer DATEV Smartcard "sprechen" konnte(weiß aber nicht sicher ob das noch so ist).

Hoffe das alles hilft dem Einen oder Anderen etwas weiter Falls ja könnt Sie es mich gerne wissen lassen

Gruß

Olaf Moser

Ps: Die Rechtschreibprüfung is ja zum totlachen wenigstens etwas Spaß nach der ganzen ärgerei

[#4]

Herr Moser, vielen Dank für Ihre Hilfe.

Mittlerweile verweist auch der beA-Service  schon auf Ihren Post hier. Von daher hatte das ganze ja schon seine Wirkung.

Nur leider gehen wir von Clients ins Netz (via DATEVnet) die keine RZ-Kommunikation haben.

Also "kleine Fallabwandlung"....

Ich harre der Dinge, die da kommen....

Aber toll, dass Sie das hier erörtert haben. Man sieht sich zumindest bestätigt, das das ganze nicht auf Anhieb zu klappen scheint....

MfG

A. Hofmeister

[#5]

Hallo Herr Hofmeister,

Hmm ich will ja nicht die Schuld bei der Datev suchen aber.... (wer auch immer zuerst am Port 10000 war oder welcher Hersteller glaubt das dieser erste frei verfügbare Port noch frei wäre )

....versuchen Sie doch mal ein Endgerät ohne Datev (Laptop oder so..) direkt mit dem Internet zu verbinden (Hotspot übers Handy oder ähnlichen) und diesen Prozess" an DATEV-NET vorbei" durchzuführen...

Wäre mal auf das Ergebnis gespannt.

MfG

Olaf Moser

[#6]

Zumindest stimme ich Ihnen bzgl. Ihrer Vermutung zu...

Das mit dem Laptop hatte ich schon....da war aber auch DATEV drauf.....aber  anderer DSL  Zugang dann ohne DATEVnet....auch nicht erfolgreich..

Aber ich geht jetzt mal an einen völlig autarken Rechner, der noch nie eine DATEV-DVD gesehen hat.....

Schaun´n wir mal....

Danke!

A. H.

[#7]

War evtl eine RZ- Komm drauf?

Beachten Sie bitte auch die anderen "Fallstricke" vorher zu beseitigen, aber man merkt schon das Ding will spielen !

Da fällt mir noch ein das es glaube ich nicht gut wäre eine lokale Firewallregel für den Port 10000 einzurichten die besagt das hierüber keine Authentifizierung erfolgen soll, da sich hier evtl. an der Gegenseite Authtfiziert werden muss..

Und natülich muss JAVA auch entspechend "mutig" konfiguriert werden...*etwas bauchweh..

In der operations.xml in SecureFramework/SecureFramwork wird auch die Adresse angegeben:

"https://local-service.bnotk.de:10000"

- evtl die Ausnahmen anpassen wenn ein Proxy Konfiguriert ist... Oder den Client Temporär direkt über NAT rauslassen.

[#8]

Sehr geehrter Herr Moser,

Ihr Tipp hat mir geholfen, auch beim Herunterladen der qualifizierten Signatur. Bin nur mal gespannt, ob beim nächsten DATEV-Update der Port wieder überschrieben wird.

[#9]

Auf dem Rechner, den ich jetzt habe, gibt's nichts mit DATEV. Autarker DSL-Zugang.

Nur Betriebssystem und Java....und ST2000u. Und natürlich eine beA-Karte.

Ich berichte dann...

[#10]

So, das hat auf jeden Fall geklappt.

-Kein DATEV-Rechner

-kein DATEVnet

-Klasse 2 Leser (Cherry ST2000U), Treiber aus Internet und nicht Version 3.2 oder 3.3 von Cherry

-Fehlermeldung bei "Windows 7 sucht erfolglos einen Smartcard-Treiber" durch entsprechende Anpassung im Richtlinieneditor "ignoriert"

-beA-Identifizierungsroutine ließ sich aufrufen

Entsprechende Porteinstellungen etc. mussten nicht vorgenommen werden.

Wie gesagt, kein DATEVnet. Ob es daran lag, vermag ich nicht zu beurteilen.

[#11]

Juhuu und schönes WE

[#12]

Ja die Spannung kenne ich mal sehen...

[#13]

Danke. Ich denke mal, man hört und liest hier noch voneinander. Zumindest lesen andere ja schon mit....Und das ist gut so....

Ebenfalls schönes WE!

[#14]

Hallo miteinander,

ich habe den beA-Signaturprozess in unserer WTS-Umgebung unter DATEVnet auch angestoßen und war zunächst so weit wie Kollege Zedler. Zwischenzeitlich haben die Kollegen von DATEVnet eine Lösung eingebaut, sodass (theoretisch) auch über DATEVnet der Zugang jetzt funktionieren müsste.

Zwischenzeitlich habe ich außerhalb von DATEVnet mit WIN 10 Bulid 1607 und einem Reiner SCT comfort rfid das Signaturzertifikat beantragt und die Authentifizierungsanträge etc. downloaden können und beim Notar alles nötige veranlasst.

Warte nun auf die Mitteilung dass mein Signatur-Zertifikat zum Download bereit seht und will dann den Auflageprozess starten.

Ich habe aber immer das Problem, dass (egal in welcher Umgebung ich die beA-Komponenten starte = cardtool) am Ende des Programmablaufs (z.B. nach PIN-Änderungen etc.) die Meldung erscheint, " Das Secure-Framework sei nicht geladen" - Hat einer der Teilnehmer hier auch dieses Problem???

[#15]

Hallo Michael,

wie sich bei mir herausgestellt hat, gab es einen Konflikt beim Port-Binding: beA nutzt den Port 10000, die RZ-Kommunikation (DFÜ-Profil) ebenfalls, siehe Artikel Kollege Moser oben. Jetzt gehe ich davon aus, dass Du den Kommunikationsserver im Einsatz hast. Vielleicht gibt es ja auch dort den Konflikt. Auf jeden Fall klappt bei mir cardtool jetzt einwandfrei. Habe auch die Signatur herunterladen können und auf die beA-Karte gebracht. Soweit alles schick. Kann jetzt auch Dateien mit Governikus Signer signieren. Beim Überprüfen jedoch kommt die Fehlermeldung, dass die Signatur nicht bis zum Wurzelverzeichnis zurückverfolgt werden kann. Dann war ich mutig und habe im EGVP-Client und im Governikus Communicator (Justiz-Client) eine Nachricht signiert bzw. versucht zu signieren. Das ging komplett schief. Jetzt verlässt mich der Mut und ich harre weiter der Dinge.

[#16]

Hallo Josef, ich hab bei mir den Kommserver im Einsatz, aber der dürfte in diesem Fall nicht dazwischen funken, weil das Problem auftritt egal ob ich über

-WTS-Session und Datevnet

-Netzarbeitsplatz und Datevnet

oder

-komplett ausserhalb des Netzes (Einzelarbeitsplatz mit nur rudimentären DATEV Softwareteilen SicherheitsPaket, NCP-Client, VIWAS)

das beA cardtool aufrufe. Ich könnte mir jetzt noch vorstellen, dass evtl der VIWAS den Port blockiert und teste mal den Port 10001.

ich hatte auch Port 9000 probiert - da ging bei mir absolut gar nichts.

Da ich von meinem Signatur-Zertifikat auch noch nichts gehört hab ( keine Nachricht von BNotK oder sonst wem) bin ich im Moment sowieso zum Warten verurteilt.

So richtig Spass macht das alles noch nicht.

[#17]

So richtig Spass macht das alles noch nicht.

Guten Morgen,  vor allem gibt es scheinbar keine richtig einheitliche Lösung.

Ich habe fast den Eindruck, das es fast einem Glückspiel ähnelt. Nun ja, zumindest ist es noch rechtzeitig und die entsprechenden Stellen versuchen hoffentlich, das Problem bis Ende September zu bereinigen?

Viele Anwender scheinen wohl auch noch zu warten.

[#18]

Guten Morgen,

ich habe zwischenzeitlich über eine Rechner ohne Proxyserver und ohne DATEvnet, unter Berücksichtigung der Anweisungen auf der Homepage der BNotK, alles durchlaufen können. Da ging alles glatt. Im ersten Versuch, als die Proxyproblematik noch nicht bekannt war, ging nichts, trotz Lesegerät Klasse 3. Nun war ich beim Notar. Bin gespannt, wie es weiter geht.

Viele Grüße, Sabine Ecker

[#19]

Dann mal Glückwunsch! Bin gespannt, wie sich das weitere Arbeiten mit den legitimierten Karten dann gestaltet..

Scheinbar liegen dazu noch keine Erkenntnisse in der HIER aufgezeigten Umgebung vor (DATEVnet, Proxy, evtl. noch SIPA)...

[#20]

Guten Morgen!

Das mit beA ist eine unendliche Geschichte. Ich hab keine Ahnung mehr, wieviele Stellen da mit beschäftigt sind. Da rufen immer wieder Leute aus irgendwelchen Firmen an, wenn die direkte Hotline nicht mehr weiter weiß. Und die direkte Hotline gibt immer nur die selben Sätze maschinenartig wieder! 😞

Zuletzt hatte ich einen netten Anruf von einem Herr, der mich anrufen wollte, wegen der Probleme in Zusammenhang mit DATEVnet. Nur wir haben gar kein DATEVnet. 🙂 Da war der Rückrufwunsch auf das falsche Ticket gebucht worden. Trotzdem war das ein sehr interessantes Gespräch, da wir in unserer Infrastruktur die selben Probleme haben.

Das Problem mit Port 10.000 durch die RZ-Kommunikation hatten wir zwar nicht, da die Anwälte kein DATEV auf den Rechnern haben. Aber laut dem Herren (ich hab Name und E-Mail bei mir abgelegt), kann man in beA den Port ändern. Ich kopiere mal direkt aus seiner Mail:

im Verzeichniss: "C:\Users\mustermann\.secureframework\SecureFramework"  die Operations.xml öffnen und die Zeile: "<bindAddress>https://local-service.bnotk.de:10000</bindAddress>" auf einen anderen Freien Port ändern, z.b." <bindAddress>https://local-service.bnotk.de:9000</bindAddress> ".

Ich habe das nicht ausprobiert, aber wenn das stimmt, würde es das Ändern des Ports in der RZKom sparen.

Interessanter Weiße meinter auch, man sollte bei der Verwendung eines Proxys diesen auch in der selben Datei eintragen, zusätzlich zu all den anderen Stellen, an denen wir das schon tun:

Wenn proxy im einsatz bitte diesen eintrag hinzufügen zwichen binAddresse und ssl:

<!-- PROXY -->

<proxy>  

<host></host>

<port></port>

<!-- optional -->

<username></username>

<password></password>

</proxy>

Auch das habe ich nicht getestet... Ich wäre gespannt, ob das hilft! Bei uns hat inzwischen unser Netzwerker gezaubert.

Übrigens sind angeblich die IP-Adressen, auf denen die Server laufen, zur Zeit nur Testadressen, und können sich nochmal ändern. Auch eine Auskunft der Hotline. Kann also sein, dass Ausnahmen auf den Firewalls nochmal angefasst werden müssen.

Da mein "Testanwalt" aber zur Zeit im Urlaub ist, kann ich noch nicht sagen, wie weit wir insgesamt kommen. Auf alle Fälle startet die Anwendung! 🙂

Tschüss

[#21]

Sehr geehrter Herr Kollege Ertl,

die Änderung des Ports in C:\Users\mustermann\.secureframework\SecureFramework"  die Operations.xml von 10000 auf 9000 zu ändern kann ich nicht empfehlen, weil es später beim Herunterladen der qualifizierten Signatur wieder Probleme gibt.

Bei mir hat die Änderung des Ports für die lokale DFÜ über Internet (RZ-Kommunikation, DFÜ-Profile) geholfen.

Bei mir läufts.

Viele Grüße

Josef Kellermeier

[#22]

Übrigens sind angeblich die IP-Adressen, auf denen die Server laufen, zur Zeit nur Testadressen, und können sich nochmal ändern. Auch eine Auskunft der Hotline. Kann also sein, dass Ausnahmen auf den Firewalls nochmal angefasst werden müssen.

Das ist gut!

Aber die Hotline des Anbieters liest  ja hier mit !

Zumindest erwähne ich dann schonmal jetzt die eventuelle Notwendigkeit, die dann geänderte IP-Adressenänderung der DATEV (Abteilung DATEVnet?) mitzuteilen! Denn damit fing das ganze ja (zumindest was DATEVnet angeht) an.

[#23]

Hallo Community,

zwischenzeitlich verschickt die Hotline die Community-Beiträge als Empfehlung zur Abhilfe.

Entgegen meinem Vorsatz habe ich doch in eine empfohlenes Lesegerät investiert.  Mit dem Ergebnis, dass die Änderung der Transport-PIN noch immer nicht zuverlässig funktioniert; soll heißen: für eine der Karten habe ich es geschafft; bei der scheint die Transport-PIN geändert.  Allerdings ist unmittelbar danach das System wieder im Nirvana verschwunden und die Meldung "Bitte prüfen Sie, ob die lokale proNEXT Secure Framework Komponente gestartet ist".  Ich kann die Meldung nicht mehr sehen.  Wie kann ich die Komponente starten?

[#24]

Hallo Herr Kollege Müller,

das mit dem "Secure Framework" ist genau auch meine Fehlermeldung. Die PIN-Änderung läuft durch, aber im Anschluss daran bricht offensichtlich die Kommunikation zwischen Lesegerät und PC ab. das führt zu dieser Fehlermeldung -> behauptet zumindest der Support von BNotK.

Auf meine diesbezügliche Fehlermeldung hin (das war Anfang 6/2016) wurde mir vor ca. 14 Tagen mitgeteilt, dass die Fehlermeldung ja keine weiteren nachteiligen Folgen hätte, die PIN-Änderung sei schließlich vollzogen.

Mit meinen Worten

"Hab dich nicht so, auch wenn´s nicht so aussieht - es funktioniert ja alles".

Auch ein Standpunkt. Mal sehen, ob wir so bei evtl. nicht (rechtzeitig) bei Gericht eingereichten Schriftsätzen auch weiter kommen.

[#25]

Hallo Herr Kollege Renz,

Das Programmverhalten ist für mich deshalb weder besonders vertrauenserweckend noch nachvollziehbar, weil ich nicht wissen möchte was passiert, wenn der Fehler während des Nachladens der Qualifizierten Signatur ausgelöst wird.  Und ich habe ehrlich gesagt keine Lust für jede weitere beA-Karte nochmals 4 Tage zu experimentieren, bis das System läuft.  In Anlehnung an einen alten Klassiker: 1000 mal versucht, 1000 mal ist nix passiert ...

Lassen Sie mich das Ergebnis des ersten Widereinsetzungsantrag wissen.  Muss direkt mal mit meiner Berufshaftpflicht sprechen, wegen der Risikoerhöhung und so

[#26]

Herr Müller, Herr Renz,

alles in allem kann man wohl festhalten, das es mehr oder weniger ein Gemurkse ist, oder?

Die Nummer mit dem Kartenleser war der erste Versuch, der BRAK-Hotline. Damit kommen Sie aber nicht weit.

Was immer wieder zu beobachten ist, sind die Umstände, das man zwar die PIN ändern kann, aber dann bricht das gesamte Konstrukt wieder in sich zusammen. Habe heute für alle unsere Karten endlich dann die Anträge zum "Notarverfahren" erstellen können. Bin wie Sie , Herr Müller,  dann auch gespannt, was danach im Alltag passiert. Aber ich denke, da wird noch einiges nachgebessert werden (müssen). Zumal ja viele Anwender noch warten bis zum 23.9.16 (da soll dann wohl eine erneute Entscheidung über den Beginn von beA fallen)?

[#27]

Hallo Herr Kollege Müller,

haben Sie denn auch einen Reiner SCT comfort rfid - Leser im Einsatz???

Das Problem mit dem "Secure Framework" hängt evtl. mit dem Leser zusammen.

Ich habe bei mir die Konfiguration:
- Win 10 Build 1607

- Reiner SCT comfort rfid, Firmware und Softwarekomp. sind 7.2.5 und 2.0.11

Andere Kollegen hatten "unser" Problem nicht aber auch andere Kartenleser im Einsatz.

@community

Hat jemand den Reiner SCT comfort rfid im Einsatz und den "Secure Framework" Fehler NICHT???

[#28]

Passt nur zum Thema, nicht aber zum Leser:

wir nutzen den Cherry ST2000U. Klasse 2 Gerät.

Zumindest haben wir die o.a. Missstände nicht (mehr)..

[#29]

Hallo Herr Hofmeister,

Danke für die aufmunternden Worte.

Zwischenzeitlich habe ich es geschafft bei allen Karten der Kanzlei die Transport-PIN zu ändern.  STRIKE

Allerdings verabschiedet sich das nette kleine Tool der BNotK jedes mal im Anschluss daran mit dem Hinweis, dass die Secure Framework Komponente nicht geladen sei.

Denn Shitstorm der sich über die DATEV ergießen würde, wenn derart miserable Programme bereit gestellt würden würde das gesamte Internet lahm legen

Aber Scherz beiseite:

hat jemand eine Idee, wie man diesen Framework dauerhaft zu laufen bringen kann; oder muss ich für den Schw.... wirklich einen alten Rechner ausmotten, die Patches nachinstallieren und dann dort die Qualifizierte Signatur nachladen.  Kann ja wohl nicht sein.

schöne Grüße

Andreas G. Müller

[#30]

Sehr geehrter Herr Müller,

ich glaube, ich bin hier anscheinend der einzige, der alles zum Laufen gebracht hat - sogar das Signieren von Mahndateien im EGVP-Client klappt. Ich hab den obigen Tipp beherzigt und den Port der lokalen DFÜ von 10000 auf 10001 geändert. Selbst die Schlussfehlermeldung "die Secure Framework Komponente sei nicht geladen" kommt nicht mehr. Der Tipp scheint aber nur zu funktionieren bei lokaler DFÜ über Internet. Von Kollegen weiß ich, dass es beim Einsatz des Kommunikationsserver, bei Einsatz von DATEVnet u.a. weiterhin Probleme gibt.

Schöne Grüße

Josef Kellermeier