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)?
Gelöst! Gehe zu Lösung.
Hallo @stefanmuc,
wenn ich alles richtig verstanden haben bin ich der Meinung dass Ihr Szenario funktionieren muss.
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.
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
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.
Hallo Zusammen, hier haben wir das gleiche Problem:
Unser Szenario:
- 1x Datev Datenbank Server + LiMa (keine RDP Anmeldungen)
- 1x Datev Terminal Server
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:
mfg
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.