KOMM Server mit SmartCard remote starten.

[#1]

Da die SmartCard nun leider nicht mehr über eine rdp-Session läuft, habe ich das Problem, dass ich unseren KOMM-Server nicht mehr remote starten kann, da dann der DFUE-Server nicht läuft.

Gibt es hier eine Lösung?

Vielleicht ein automatisches Anmelden wie bei einer Datev-Installation?

[#2]

---

@clblank schrieb:

Vielleicht ein automatisches Anmelden wie bei einer Datev-Installation?

---

Das ist das geringste Problem. Das kann man in 2min via AutoLogon von Microsoft lösen. Dann muss man immer noch die SmartCard PIN eingeben.

Wenn ich mich richtig erinnere, hat sich @martinkolberg da etwas mit PIN Eingabe gebaut.

Sonst würde ich TeamViewer nutzen, VNC oder andere Remote Tools. Ist es eine VM, dann direkt via VM Player oder anderen VM Möglichkeiten.  

[#3]

---

@clblank  schrieb:

Da die SmartCard nun leider nicht mehr über eine rdp-Session läuft, habe ich das Problem, dass ich unseren KOMM-Server nicht mehr remote starten kann, da dann der DFUE-Server nicht läuft.

Gibt es hier eine Lösung?

Vielleicht ein automatisches Anmelden wie bei einer Datev-Installation?

---

Der könnte doch auch headless laufen. Ansonsten gibt es auch noch Autologon von MS, aus Sicherheitsgesichtspunkten aber nicht zu empfehlen.

[#4]

PIN speichern:
Sicherheitspaket. "Gerätebezogene Absicherung der RZ- Verbindung aktivieren"

[#5]

Das hält nur keinen Neustart durch. 

[#6]

---

@metalposaunist  schrieb:

Das hält nur keinen Neustart durch. 

---

Äähh, doch : Dafür ist es ja gedacht (Und sonst hätten WIR ein echtes Problem mit zig Kommsrv 😁 )

[#7]

Werde ich testen. Hat bei mir meiner Meinung nach nie funktioniert und nach einem Neustart kam jedes Mal das PIN Eingabefeld hoch. 

[#8]

Geht zwar ohne Pin-Eingabe, aber nicht ohne Anmeldung.

Und eine automatisierte "MS-Anmeldung" ist mir eigentlich zu unsicher.

[#9]

---

@clblank  schrieb:

Und eine automatisierte "MS-Anmeldung" ist mir eigentlich zu unsicher.

---

Und warum?

Der Benutzer muß weder (Domänen)Admin sein, noch braucht er lokale administrative Rechte.

Weiterhin kann zusätzlich der lokale Sperrbildschirm mit kurzer Zeitspanne eingetragen werden.

[#10]

Aber wenn nach einem Neustart die PIN wieder da ist, kann man den Sammler doch als Dienst laufen lassen? Dann braucht's doch gar keine Windows Anmeldung? Oder wo habe ich einen Knoten im Kopf?

[#11]

---

@metalposaunist  schrieb:

Aber wenn nach einem Neustart die PIN wieder da ist, kann man den Sammler doch als Dienst laufen lassen? Dann braucht's doch gar keine Windows Anmeldung? Oder wo habe ich einen Knoten im Kopf?

---

Kommsrv <> DFÜ Sammler 😁

Aber klar, wenn der Kommsrv die volle Programmausstattung bekommt kann der Sammler auch als Dienst laufen. Dann braucht aber der Benutzer wieder Nuko Rechte über alle Mandate wg. Folgeverarbeitung. (Ich präferiere den Sammler am ersten Terminalserver laufen zu lassen, da die Dinger in der Regel performanter sind als ein Kommsrv) 

[#12]

---

@metalposaunist  schrieb:

Aber wenn nach einem Neustart die PIN wieder da ist, kann man den Sammler doch als Dienst laufen lassen? Dann braucht's doch gar keine Windows Anmeldung? Oder wo habe ich einen Knoten im Kopf?

---

Wenn die Softwareprodukte für die Folgeverarbeitung dort installiert sind, funktioniert es genau so.

[#13]

---

@siro schrieb:

(Ich präferiere den Sammler am ersten Terminalserver laufen zu lassen, da die Dinger in der Regel performanter sind als ein Kommsrv) 

---

Ich nicht. Weil dann 1 Server der ganzen Farm angemeldet sein muss? Windows Updates und bei 1 Server muss ich dran denken? Widerstrebt mir gegen meinen Homogenitätssinn. Wenn es schon 1 zusätzlichen Server gibt, dann tanzt der aus der Reihe aber nicht einer meiner RDS aus der Farm. 

Und wenn ich schon einen extra KOMMSRV laufen lasse, dann sicher auch als DFÜ Sammler. Sonst kann ich auch den FS SQL mit allem ausstatten.  

[#14]

---

@metalposaunist  schrieb:

---

Ich nicht. Weil dann 1 Server der ganzen Farm angemeldet sein muss? Windows Updates und bei 1 Server muss ich dran denken?

---

Ja stimmt  .. aber da greift ja wieder das Autologon 😁

Spass beiseite, das Prozedere resultiert noch aus der Welt der Hardware Bleche. Und da war halt der Kommsrv im Vergleich zum Terminalserver deutlich schwachbrüstiger. Und dann durfte man beim Update auf den lahmen Kommsrv warten, während die Server schon längst durch waren.

In Zeiten von Virtualisierung und Hosten im (Datev)RZ sieht das natürlich anders aus, hier haben alle Maschinen den gleichen Dampf.

[#15]

---

@siro schrieb:

... Ich präferiere den Sammler am ersten Terminalserver ...

---

... spricht etwas gegen den Sammler an einem 'normalen' Arbeitsplatz in einem Netz ohne Terminalserver (morgens der Erste, abends der Letzte, alle PCs mit eigener lokaler 'DFÜ über Internet') ?

(früher war der FS gleichzeitig Kommunikationsserver, ... war aber mMn kein Vorteil)

[#16]

---

@vogtsburger  schrieb:

---

... spricht etwas gegen den Sammler an einem 'normalen' Arbeitsplatz in einem Netz ohne Terminalserver (morgens der Erste, abends der Letzte, alle PCs mit eigener lokaler 'DFÜ über Internet') ?

---

Kann man so machen, aber warum hat dann jeder wieder lokale DFÜ über Internet?

[#17]

---

@siro schrieb:

... aber warum hat dann jeder wieder lokale DFÜ über Internet ?

---

... weil es ja keinen Kommunikationsserver gibt, nur einen Sammler.

Jeder Arbeitsplatz soll und muss auch selbst DFÜ betreiben können.

Außerdem lässt sich ja mit den SmartCards mehr machen als bloß Datev-DFÜ (z.B. E-Mail Verschlüsselung, VaSt, DUO, ...)

[#18]

---

@vogtsburger  schrieb:

... spricht etwas gegen den Sammler an einem 'normalen' Arbeitsplatz in einem Netz ohne Terminalserver (morgens der Erste, abends der Letzte, alle PCs mit eigener lokaler 'DFÜ über Internet') ?

(früher war der FS gleichzeitig Kommunikationsserver, ... war aber mMn kein Vorteil)

---

Zu umständlich. Kein Mitarbeiter kommt immer als erster. 

[#19]

---

@clblank schrieb: ... Zu umständlich. Kein Mitarbeiter kommt immer als erster.

... niemand verlangt, dass ein bestimmter Mitarbeiter immer als Erster kommt und als Letzter geht.

Aber der PC kann trotzdem der Erste sein, der eingeschaltet und der Letzte, der heruntergefahren wird, oder er bleibt bei Bedarf eben gestartet.

'Chacun à son goût'

[#20]

---

@vogtsburger  schrieb:... niemand verlangt, dass ein bestimmter Mitarbeiter immer als Erster kommt und als Letzter geht.

Früher nannte man einen solchen Mitarbeiter "Chef" 😆

[#21]

Gut, dann kann ich auch alles so lassen und dem Mitarbeiter, der morgens als erster kommt, bitten, den KOMM-Server neu zu starten und sich einzuloggen.

Das kann aber doch jetzt, im Rahmen einer von Datev gepredigten Digitalisierung,  nicht ernsthaft die Lösung sein. Hier muss die Datev mal eine Alternative anbieten, nachdem sie, ausgerechnet in Corona-Zeiten, ihren Mitgliedern mit dem letzten großen Update bzgl. der SmartCard ordentlich Steine in den Weg gelegt hat!

Hallo, DATEV, hört jemand mit?

[#22]

die Datev versteht unter "Digitalisierung" aus meiner Sicht nur "back to the roots", heim in's Reich der Datev-Bits und -Bytes, also in's Rechenzentrum.

... ich spekuliere, dass von Datev-Seite im Bereich "On Premises" keine Neuerungen und Verbesserungen geplant sind, höchstens Notlösungen.

Übrigens, ein Komm-Server hat noch eine kleine zusätzliche Nebenwirkung. Er kostet nämlich monatliche Gebühren (gestaffelt nach Anzahl der Betriebsstättenlizenzen).

[#23]

Technisch geht es.
Per BIOS den PC Morgens starten lassen (Kommserver als Dienst)
Abends per "Shutdown" ausschalten. (Muß ja nicht nachts durchlaufen, wenn der Server sichert.)

Probleme: 
- Lizenztechnisch ist für den Kommserver eine freie DATEV- Lizenz reserviert und die würde der Mitarbeiter nutzen.

- Der Mitarbeiter darf seine SC, die viele Rechte benötigt nie abziehen.