Thema "DATEV-Programme 16.0: Probleme bei mIDentity-Stick + Remotedesktop, Umstieg auf USB-Softwareschutzmodul" in Installation DATEV-Programme

DATEV-Programme 16.0: Probleme bei mIDentity-Stick + Remotedesktop, Umstieg auf USB-Softwareschutzmodul

stefanmuc — Fri, 03 Jun 2022 23:52:48 GMT

Hallo,

ich nutze die DATEV-Umgebung auf einen mit HyperV virtualisierten Windows 10 Pro-Rechner. USB-Dongles und Sticks werden per SEH-USB-Server bereitgestellt. Vor DATEV-Programme 14.0 war es ganz easy, seit dem Release muss der persönliche mIDentity-Stick im Client stecken, der virtualisierte Windows-Rechner mit der DATEV-Installation hat einen Betriebsstätten-mIDentity-Stick. Das hat jetzt ca. 3 Jahre lang funktioniert.

Aktuell bin ich im Betatester für die Pilotversion "DATEV Programme 16.0", die im Sommer erscheinen soll. Seit der Installation der 16er-Version funktioniert obige Vorgehensweise leider nicht mehr, da die beiden Sticks (für Client und Installationshost/"Server") nicht mehr gleichzeitig arbeiten. Sobald der Client samt persönlichem mIDentity-Stick sich per RDP mit dem vServer verbindet, verliert der vServer den Betriebsstätten mIDentity-Stick.

Die Pilot-Hotline will mir die bisher praktizierte RDP-Lösung ausreden und supportet diese auch nicht mehr ("Das sind Windows-spezifische Smardcard-Probleme unabhängig von DATEV"). Die normale Installationshotline empfiehlt als einzige Lösung, wenn man RDP beibehalten will, den Umstieg von einem Betriebsstätten-mIDentity-Stick zum USB-Softwareschutzmodul am vServer. Das hätte keine Chipkarte und wäre somit nicht von den neuen, verschärft umgesetzten Windows-Sicherheitsregeln betroffen. Das werde ich kommende Woche umsetzen.

Ich habe DATEV auf einem virtualisierten Win10-Pro-Rechner installiert, damit ich abwechselnd von zwei verschiedenen Arbeitsplätzen auf die Umgebung zugreifen kann.

Hat hier jemand ähnliche Erfahrungen gemacht oder einen Vorschlag, wie man das noch anders lösen kann (außer in die DATEV Smart IT Cloud zu gehen)?

DATEV-Programme 16.0: Probleme bei mIDentity-Stick + Remotedesktop, Umstieg auf USB-Softwareschutzmodul

Andreas_Bär — Sat, 04 Jun 2022 05:58:51 GMT

Hallo @stefanmuc,

wenn ich alles richtig verstanden haben bin ich der Meinung dass Ihr Szenario funktionieren muss.

Der Betriebsstätten-mIDentity wird nur für den Lizenz-Manager-Server genutzt?
Der Lizenz-Manager-Server läuft als Dienst?
Die SEH-Software läuft als Dienst?
Bitte keine noch angemeldeten/getrennten Sessions übernehmen. Also wenn Sie als Admin an der Konsole angemeldet sind/waren, dann darf diese Sitzung nicht per RDP übernommen werden. Wobei das nur Probleme in der Session machen sollte und einen Dienst nicht beeinflussen sollte.
Was passiert im Fehlerfall genau? Lizenz-Manager-Server inkonsistent? SiPa rot? Bitte im Fehlerfall an der Konsole prüfen (unbedingt anderen User als in RDP-Sitzung verwenden). Bei Hyper-V muss der erweiterte Sitzungsmodus deaktiviert sein, siehe Kapitel 3.2 und 3.3: Kein Zugriff auf eine am Remotecomputer gesteckte SmartCard in einer Remotedesktopsitzung
Wenn das SiPa an der Konsole rot ist, PCSC-Test ausführen: PCSC-Test des DATEV Sicherheitspakets ausführen

Wenn die Voraussetzungen gegeben sind, melden Sie sich am besten mit den Ergebnissen und Verweis auf diesen Beitrag nochmal per Servicekontakt an den Programmservice SmartCard. Wir wollen keinen Fehler in der Pilotphase übersehen.

DATEV-Programme 16.0: Probleme bei mIDentity-Stick + Remotedesktop, Umstieg auf USB-Softwareschutzmodul

DVTECH69 — Sat, 04 Jun 2022 17:32:51 GMT

Kann ich bestätigen,

unter hyper V und Server 22 keine Probleme mit BS mIDentity.

dvd 16 keine Probleme

Microsoft RDP Regeln beachten ist halt Pflicht

DATEV-Programme 16.0: Probleme bei mIDentity-Stick + Remotedesktop, Umstieg auf USB-Softwareschutzmodul

stefanmuc — Sun, 05 Jun 2022 22:24:58 GMT

Hallo,

nachdem ich beim Sicherheitspaket eine Reparaturinstallation durchlaufen hatte, werden die beiden mIDentity-Sticks am Client und Installationshost/"Server" wieder parallel erkannt. Problem somit gelöst.

DATEV-Programme 16.0: Probleme bei mIDentity-Stick + Remotedesktop, Umstieg auf USB-Softwareschutzmodul

ITDB — Mon, 13 Jun 2022 08:27:37 GMT

Hallo Zusammen, hier haben wir das gleiche Problem:

Unser Szenario:

1x ESXI Server

- 1x Datev Datenbank Server + LiMa (keine RDP Anmeldungen)

- 1x Datev Terminal Server

SEH USB Server (für den Betriebsstätte Stick)
13x Normale Windows WKS Datev Clients

Der Betriebsstätten-mIDentity wird nur für den Lizenz-Manager-Server genutzt? JA
Der Lizenz-Manager-Server läuft als Dienst? JA
Die SEH-Software läuft als Dienst? JA
Bitte keine noch angemeldeten/getrennten Sessions übernehmen. Also wenn Sie als Admin an der Konsole angemeldet sind/waren, dann darf diese Sitzung nicht per RDP übernommen werden. Wobei das nur Probleme in der Session machen sollte und einen Dienst nicht beeinflussen sollte. JA

Sobald sich ein Mitarbeiter mit angestecktem persönlichen Datev Stick seinen Rechner Hochfährt und das Lokale SIPA startet, wird der persönliche Datev Stick an den LiMa des Servers übergeben (Dabei ist es unerheblich ob der User mit der Lokalen Installation arbeiten möchte, oder ob er die Sitzung per RDP Startet)

Abhilfe schafte bis jetzt meist nur: das alle User Ihre Sticks abziehen, und der Betriebsstätte Stick vom SEH-USB Server deaktiviert und wieder Aktiviert wird.

Symptome:

SiPa auf dem Server hängt und läst sich nicht starten (Symbol ist aber grün) er erkennt ja auch schließlich eine Karte (wenn auch offensichlich die Falsche)
LiMa Rotes Ausrufezeichen inkonsistent

mfg

DATEV-Programme 16.0: Probleme bei mIDentity-Stick + Remotedesktop, Umstieg auf USB-Softwareschutzmodul

Andreas_Bär — Mon, 13 Jun 2022 09:39:40 GMT

Hallo @ITDB,

Ihre Situation passt nach meiner Einschätzung eigentlich nicht in diesen Beitrag. Hier ging es um ein einziges System und den Verdacht dass es mit dem dort gesteckten mIDentity ein Problem gibt wenn jemand per RDP darauf zugreift und lokal ebenfalls einen mIDentity stecken hat. Das aber nur für nachfolgende Leser und damit wir nicht aneinander vorbei reden 🙂

Bei Ihnen arbeiten die User ja auf dem Terminal-Server völlig unabhängig vom Datenbank-Server mit Lima. Das kann eigentlich gar nichts mit der RDP-Verbindung zu tun haben. Ich denke die beiden Dokumente könnten zutreffen:

Also ggf. USB-Server aktualisieren und insbesondere Mal mit einem anderen mIDentity (unter Beibehaltung der SIM) testen.