Bekanntermaßen verliert der Kommserver sporadisch die gerätebezogene Absicherung des Sicherheitspaketes und diese muß erneut aktiviert werden.
Frage:
Wie kann, ab besten per Batch- Datei und Mailversand der Admin informiert werden, wenn das SiPa mal wieder die Absicherung gecancelt hat?.
Oder, lässt sich irgenwie am Kommserver der Status anzeigen, ob die gerätebezpgene Absicherung aktiv ist, oder nicht?
vielleicht ist es ja auch möglich, die "gerätebezogene Absicherung" prophylaktisch und regelmäßig (z.B. alle 60 Minuten) zu aktivieren, egal, ob noch aktiviert oder nicht. Im Logbuch würde dann evtl. stehen "gerätebezogene Absicherung ist bereits aktiviert"
-Virtualsiert oder auf Blech?
Kommserver als eigenes Blech, welches auch zum normalen Arbeiten genutzt wird.
? Man kann einfach nicht sehen, ob die Absicherung aktiv ist, oder nicht ?
-> Morgens wird vom betroffenen Mitarbeiter routinemäßig die "Absicherung aktiviert"
Wie gesagt... Sporadisch und oftmals, wenn Datensicherungen der Clienten über das Netz auf die im Kommserver verbaute HD II laufen. (C:\ befindet sich auf der SSD I )
Die Datensicherungen (wöchentlich 10 * 50 GB) sind in den DATEV- Anwendungen performance- mäßig nicht spürbar.
Kommserver als eigenes Blech, welches auch zum normalen Arbeiten genutzt wird.
Dafür ist er eigentlich nicht gedacht.
Werden verschiedene Smartcards verwendet?
Läuft der Rechner durch?
Gerät läuft durch und selbstverständlich werden keine Smartcards gewechselt.
Der Kommserver ist als Dienst installiert, so daß er auch funktioniert, wenn sich niemand einloggte.
Nur... Sporadisch (egal ob ein Mitarbeiter aktiv ist) wird die SC- Absicherung raus gekickt und hier möchte ich sofort eine Email haben, so daß administrativ eingegriffen werden kann.
Gibt es irgend welche Neuerungen?
Wie oben geschrieben: Es handelt sich um einen Kommserver, der sich selbstständig Nachts ausgeschalt und Morgens um 5:00 neu startet und sich dann noch im Hintergrund die Nacht- Datensicherung des Servers in Generationen auf eine interne Platte kopiert.
Ich meine doch eher, dass es von DATEV vorgesehen ist, dass Server 24/7 durchlaufen und 1x im Monat zwecks Windows- und DATEV Updates neugestartet werden müssen. Bis dahin läuft bei mir die gerätebezogene Absicherung 1A ohne Probleme.
Ggf. mal das Sicherungskonzept überdenken? Selbst Windows 10 PCs lassen sich online im laufenden Betrieb sichern.
Sicherungskonzept:
Der große Server stoppt nachts den SQL- Server lt. DATEV- Empfehlungen
Hierbei darf kein PC eingeloggt sein. Dafür haben alle PC, auch der Kommserver spät Abends die Shutdown /s Aufgabe aktiv.
Das hat sich seit Jahren bewährt und soll nicht geändert werden.
Das "Abwerfen" vom Kommserver wird regelmäßig durch DATEV- Downzeiten ausgelöst, also wenn per Kommserver auf ein nicht, oder zu langsam reagierendes RZ zugegriffen werden soll..
@martinkolberg schrieb:Der große Server stoppt nachts den SQL- Server lt. DATEV- Empfehlungen
Naja, ob das aber noch state-of-the-art ist? Nur weil DATEV das empfiehlt, heißt das ja nicht, dass das auch 2020 noch technisch gut ist. Ich kenne niemanden, der Server zum Sichern herunterfährt. Speziell VMs sichert man dank VSS auch im laufenden Betrieb. Klappt auch mit SQL problemlos.
Dann ist ja jeden Tag der 64GB RAM vom DATEV SQL leer und man startet jeden Tag mit 0MB Cache? Das doch oldschool.
Warum DATEV den SQL und Co. herunterfahren möchte zum sichern: damit SQLs gesichert werden, die 100% in Ordnung sind. Aber ab DVD 14.0 kann man sich ja auch zur täglichen SQL Prüfung benachrichtigen lassen. Sehe aktuell keinen Grund den SQL täglich zu killen. Es gab hier mal eine ausführliche Antwort der DATEV für das Für und Wider aber auch hier muss man Richtung Zukunft gehen: SQL online behalten.
@martinkolberg schrieb:Das hat sich seit Jahren bewährt und soll nicht geändert werden.
Okay, dann bin ich raus 😁.
Da sich die Daten auf dem Server auf einer SSD befinden ist das Neueinlesen des Caches kein wirkliches Problem. Der erste Start vom DAP (mit 6 Reitern incl. RZ- Komm) dauert anstelle der üblichen 10 Sekunden dann 15 Sekunden. Das ist doch OK für einen knapp 10 Jahre alten Server.
Ja, es gibt die VSS zum Sichern im laufenden Betrieb. Klappt auch mit SQL problemlos.
Korrekt, aber DATEV hat diverse SQL- Datenbanken, die integer bleiben sollen.
Natürlich sollte Nachts nicht wirklich mit DATEV gearbeitet werden, aber für eine garantiert fehlerfreie Sicherung sollten alle SQL- Dateien vom identischen Zeitpunkt stammen.
Danke für den Himweis, daß es eine neue Benachrichtigung gibt, die wohl aktiv anzustoßen ist.
Zusatz: Wenn es im Laufe des Tages irgendwo in den DATEV- Anwendungen hakte (Benutzersperren, usw.), dann "reparierte" sich das bislang immer "über Nacht".