Vielen Dank für deine HIlfe. das hat mir alles schon sehr viel gebracht.
Also das mit 1 Tag habe ich jetzt wieder höher gesetzt - ich werde das einfach mal beobachten wie es sich auf den Alltag nun auswirkt und kann mit den Parameter noch spielen.
Die 3 Dedup-Tasks habe ich nun so geplant dass bis zum Vollbackup vom ganzen System alles durch sein sollte.
Der erste Task läuft ja eh stündlich und die Bereinigungen dann mit Puffer vor dem Backup.
Guten Morgen,
also das erste neue stongbox-image wird nun am Freitag erstellt.
Das Volume habe ich soweit ja vorkonfiguriert.
muss/sollte man hier noch was anpassen in den Zeiten oder soll das dann so bleiben?
Zeitplan
Basis: Freitag - ab 17:45 Uhr
Inkrementell: Samstag - Donnerstag - ab 19:00 Uhr
Überschreiben nach 1 Tag
Wir heben maximal 1-2 Images auf - Datenmenge einfach zu groß.
Würde dass dann so passen ... aktuell sieht es so aus bei mir:
0-0.stbox 465GB - Datenauslastung auf dem Laufwerk "nur" 200GB
Server läuft 2019 Standard.
Strongbox ist direkt unter C:\strongbox
Vielen Dank für die Inputs!!
Habe jetzt gleich als ersten Schritt eine neue Partition angelegt und Strongbox ausgelagert!
Die Powershell Befehle gingen auch durch. Bin gespannt 
also was jetzt die letzten zwei Wochen schief gelaufen ist - keine Ahnung ehrlich gesagt. Kam aus heiterem Himmel die Probleme
Werde jetzt mal testweiße am Freitag alles zurück setzen und die Einstellungen anpassen:
Basis-Image - Freitag - ab ca. 19 Uhr
Inkr-Image - restliche Tage ab ca. 19 Uhr
Überschreiben 1 Tag
Hallo zusammen,
zur Zeit spinnt unsere Strongbox-Sicherung, dass am Wochenende teilweise die Platte voll lief und Montagfrüh dann nix mehr ging. Leider finde ich keine Ursache dafür, was die großen Datenmengen verursacht... 
Gibt es eine Best-Practice Lösung oder Denkansätze?
Aktuell bei uns:
BackupExec sichert am Freitag um 23:55 ein Vollbackup aller Server etc.
Strongbox sichert erst Samstag ein Basis-Image (Abends) und dann So-Fr inkrementell (Abends).
Überschreiben ist auf 4 tage gesetzt.
Wäre es dann nicht eher sinnvoll das Basis-Image auf Freitag zu verlegen?
Beeinträchtigt der Strongbox-Job das normale Arbeiten? Normal dürfte um die Zeit (sagen wir mal ca. 18:45) keiner mehr da sein.
Danke für eure Hilfe
Seb
Guten Morgen,
Rollout hat sich erfolgreich installiert.
Aufälligkeit nach Windows Patchday (Server 2019) war, dass nach dem Reboot alle David Dienste nicht automatisch gestartet wurden (Eventlog 7000+7009 was nach einem Timeout aussieht).
Manueller Start ging dann ohne Probleme.
Zufall? Liegts am Rollout oder Patch oder einfach nur Pech in dem Fall gehabt?
Schönen Donnerstag
DVHF372501 Hotfix wurde heute bei uns noch runtergeladen. Hat wer dazu infos?
Ansonsten läuft hier alles normal seit dem Update
nein - das wäre heute Nacht dran gewesen.
Ist bei uns noch auf 500
1&1 Hotline konnte/wollte mir leider nicht helfen....
warte jetzt auch mal bis morgen ab.
Aber gut zu wissen, dass es nicht nur an uns liegt.
Hallo zusammen,
von jetzt auf gleich kommt beim eMail-Versand nach extern die Meldung "unbekannter Absender" und Mails gehen nicht raus.
Wir nutzen ein 1&1 Postfach zum Versand (nicht Ionos!)
Webmail funktioniert ganz normal.
SMTP Login-Test im DavidAdmin sagt Benutzer/Passwort falsch.
Mit den Daten kann ich mich aber im Webmail einloggen.
Hat sonst noch wer das Problem?
Besten Dank und einen schönen Abend
Ok dann scheint das Problem gefunden zu sein ... mal sehen ob von offizieller Seite dazu was passiert.
hab die alte Orderstruktur jetzt wiederhergestellt und die eine Zeile auskommentiert.
Läuft wieder wunderbar. Danke dir auch
Bzgl. WebApi habe ich eine Rückmeldung erhalten
Kopieren Sie einmal alle Dateien, ohne den Ordner "wwwroot" aus David\Z$BACKUP\David.244\David\code\DavidRestApi und
ersetzen die Dateien im Verzeichnis David\Code\DavidRestApi (diese zuvor in ein temp Verzeichnis verschieben)Beenden Sie zuvor den WebAPi Servivce - wie sieht es dann aus?
jetzt funktioniert zwar der externe Zugriff wieder aber beim nächsten Update ist es wieder "kaputt"
Habe den Support nochmals auf den abweichenden Port hingewiesen. Bin gespannt was raus kommt
Hab das mit der WebAPI und den Port schon gestern Tobit gemeldet. Samt logs und co.
Habe auch noch logs und screenshots eben nachgeschickt ... bin gespannt, ob zeitnah was passiert.
Das ist dann die alte Verlinkung. Auf den Hauptseiten gibt es den nicht mehr. Wurde geändert wie oben beschrieben in Tobit.Team.
grad übers handy getestet mit dem Link - hier gleiches Fehlerbild
Ja das kenne ich, nutzt ihr den Std. Port 8443 oder einen anderen für die WebAPI?
in den webapi settings is 8541 drin. wo er allerdings den 8443 hernimmt... keine ahnung
Logfile sieht nur so aus:
also alles was webapi betrifft
oder die Android / ios App
Einloggen geht noch aber dann gehts nicht weiter... man sieht nur den Ladekreis
Guten Morgen,
smart Client tot? Kollegen melden sich, dass nix mehr geht.
Weder mit App noch über Browser.
Dienst neu starten hilft nichts - kommt nur immer die eMail mit "External health check failed"
Im David-Administrator bei "Erreichbarkeit prüfen" ist alles grün.
Ich mach mal ein Ticket auf ... man man man
Schönen Freitag
Moin,
wir bekamen nun Rückmeldung vom David Support
"Wir prüfen hierzu eine Optimierung."
also mal abwarten. Es ist ja nichts weltbewegendes...
Hallo zusammen,
wir haben heute eine Auffälligkeit festgestellt und können es uns nicht erklären.
Habe schon ein Ticket parallel aufgemacht aber vielleicht hatte das Problem auch wer.
Betrifft Modern und Classic Client
Wenn man im Postausgang-Ordner eine Mail drucken will kommen je nach dem wie man den Druck startet zwei verschiedene "Designs" im Druck raus.
Wenn man die Mail in der Liste mit Rechtsklick --> Drucken ausdruckt, sieht alles korrekt aus mit Kopfzeile (Absender, Betreff, Empfänger etc.)
Wenn man aber die Mail öffnet und dann den Druck startet, werden oft Mails auf mehrere Seiten gezogen und z.B. Anhänge erst auf der zweiten Seite abgedruckt, obwohl auf der ersten Seite noch Platz wäre und auch der Kopfbereich sieht anders aus.
Kann man das "Problem" beheben oder ist das "Works as designed"? Ist jetzt nicht tragisch aber ist heute erst bewusst aufgefallen.
Wenn man Mails aus dem Posteingang z.B. über beide Wege druckt - sieht in beiden Fällen alles korrekt aus
Beispiel
Wünsche euch ein schönes Wochenende
Ok vielen Dank - habe den Hinweis mit dem "To:"-Feld im Header mal an den Support weitergegeben.
Envelope-To werten wir aktuell nicht aus - korrekt.
Bzgl. der 1&1 Situation allgemein - ja ich weiß, dass hier Handlungsbedarf besteht... das muss noch angegangen werden.
also das komische ist ja, dass alle mails korrekt ankommen.
nur eben die chayns passwort reset mails nicht ...
Die Einstellungen sind beim Catch-All im David-Admin so hinterlegt:
Auszuwertendes Adressefeld = leer
Zieladresse = *@domain.de
Postfachname bzw. email-adresse = AD-Username, falls relevant
admin@domain.de = Catch-All-Postfach
Header der Chayns Mail
X-POP3RCPLIST: *@domain.de
Return-Path: <SRS0=yGIn=KE=chayns.de=noreply@srs2.kundenserver.de>
Authentication-Results: kundenserver.de; dkim=pass header.i=@chayns.de
Received: from mout.kundenserver.de ([217.72.192.74]) by mx.kundenserver.de
(mxeue002 [212.227.15.41]) with ESMTPS (Nemesis) id 1Mg9B0-1qyPmx1Eh4-00odpQ
for <admin@domain.de>; Tue, 27 Feb 2024 11:01:05 +0100
Received: from mail.tobit.software ([62.153.122.27]) by mx.kundenserver.de
(mxeue101 [217.72.192.67]) with ESMTPS (Nemesis) id 1MRUpv-1rHadA015R-00KAMp
for <user01@domain.de>; Tue, 27 Feb 2024 11:01:05 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt;
d=chayns.de; s=sql-david;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=kzKRAz0me42csH2zYd1w7i3dHKpSXTtgoy657IsimPU=;
b=LvHo/KALx5PkCr48cNOa0jtVC3LKQHWTvH0avgKIk+d/0ZTKo4QCMce5GRqKS7itYAQQ
ExErJWs8RrY069uajwlTB8yb/i5n6DKTJWyuhJNa3tni38CAzd2F/3YgS/BHN/8BP+taGo
wVEnllOHbBAIvh/b+zK1sRuA8AydHmw9M=
From: <noreply@chayns.de>
Subject: =?utf-8?B?Y2hheW5zwq4gLSBLZW5ud29ydCDDpG5kZXJu?=
Date: Tue, 27 Feb 2024 10:01:05 +0000
Priority: normal
X-Priority: 3 (Normal)
Importance: normal
X-Mailer: David by Tobit Software, Germany, Mime Converter 101.20
X-David-Sym: 0
X-David-Flags: 0
Message-ID: <01542133.65DDC0EE@mail.tobit.software>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_000_01542133.65DDC0EE"
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:FUWZcvkMcDc=;XHva4tFdN3VmpYE+19om2iR/XOm
Envelope-To: <admin@domain.de>
X-Spam-Flag: NO
UI-InboundReport: notjunk:1;M01:als Beispiel ein Header von einer Mail an mich, die korrekt verteilt wurde
X-POP3RCPLIST: *@domain.de
Return-Path: <prvs=0787cfa8f2=absender01@firma.de>
Authentication-Results: kundenserver.de; dkim=none
Received: from mout.kundenserver.de ([217.72.192.75]) by mx.kundenserver.de
(mxeue003 [212.227.15.41]) with ESMTPS (Nemesis) id 1MIamr-1rhuZB3xMD-0084RL
for <admin@domain.de>; Tue, 27 Feb 2024 08:53:45 +0100
Received: from postfix.firma.de ([89.28.***.***]) by mx.kundenserver.de
(mxeue103 [217.72.192.67]) with ESMTPS (Nemesis) id 1MXFKC-1rP1CY0KsQ-00Q8He
for <meinemail@domain.de>; Tue, 27 Feb 2024 08:53:44 +0100
Received: from mail1.firma.local ([192.168.90.16]:18574 helo=postfix.firma.de)
by postfix.firma.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from <absender01@firma.de>)
id 1resHI-0006n2-1k
for meinemail@domain.de;
Tue, 27 Feb 2024 08:53:28 +0100
Received: from mail1.firma.local (192.168.90.16) by mail1.firma.local
(192.168.90.16) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Tue, 27 Feb
2024 08:53:28 +0100
Received: from mail1.firma.local ([fe80::***:***:***:***]) by
mail1.firma.local ([fe80::***:***:***:***]) with mapi id
15.02.1118.040; Tue, 27 Feb 2024 08:53:28 +0100
From: Firma Mitarbeiter <absender01@firma.de>
To: =?iso-8859-1?Q?=27meine Mail=27?=
<meinemail@domain.de>
Subject: xxxx
Thread-Topic: xxxxxx
Thread-Index: AdppUgTo0s/UNicST0qmQ39pjDwDoA==
Date: Tue, 27 Feb 2024 07:53:28 +0000
Message-ID: <589139e81af24965b92a9b69a7d14c32@firma.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.90.20]
Content-Type: multipart/related;
boundary="_006_589139e81af24965b92a9b69a7d14c32firmade_";
type="multipart/alternative"
MIME-Version: 1.0
X-Sophos-OBS: success
X-SASI-Version: Antispam-Engine: 5.1.4, AntispamData: 2024.2.27.70919
X-SASI-RCODE: 200
X-SASI-SpamProbability: 13%
X-SASI-Hits: BODYTEXTH_SIZE_3000_MORE 0.000000, BODY_SIZE_10000_PLUS 0.000000,
BODY_SIZE_100K_PLUS 0.000000, BODY_SIZE_25K_PLUS 0.000000,
BODY_SIZE_50K_PLUS 0.000000, BODY_SIZE_75K_PLUS 0.000000,
FRAUD_HIGH_X3 0.000000, FRAUD_HIGH_X3_WEBMAIL 1.000000, HTML_90_100 0.100000,
IMG_ATTACHED_2P 0.000000, JPG_COMMON_HEADER_ORDER 0.000000,
JPG_PIXPERBYTE_MED 0.000000, JPG_SPAMMY_SEGMENT 0.000000,
JPG_SPAMMY_Y_RESOLUTION 0.000000, JPG_SPAM_ATTACHED 0.000000,
MULTIPLE_ATTACHMENTS 0.000000, NO_FUR_HEADER 0.000000, OUTBOUND 0.000000,
OUTBOUND_SOPHOS 0.000000, SENDER_NO_AUTH 0.000000, SUPERLONG_LINE 0.050000,
WEBMAIL_SOURCE 0.000000, WEBMAIL_XOIP 0.000000, WEBMAIL_X_IP_HDR 0.000000,
__ANY_URI 0.000000, __ATTACH_CTE_BASE64 0.000000,
__ATTACH_CTE_QUOTED_PRINTABLE 0.000000, __BODY_TEXT_X4 0.000000,
__BULK_NEGATE 0.000000, __BUSINESS_SIGNATURE 0.000000,
__CID_8_DOT_8 0.000000, __COURIER_PHRASE 0.000000, __CP_MEDIA_BODY 0.000000,
__CP_URI_IN_BODY 0.000000, __CT 0.000000, __CTYPE_HAS_BOUNDARY 0.000000,
__CTYPE_MULTIPART 0.000000, __CTYPE_MULTIPART_ALT 0.000000,
__DATING_PHRASE 0.000000, __DQ_NEG_DOMAIN 0.000000, __DQ_NEG_HEUR 0.000000,
__DQ_NEG_IP 0.000000, __EXTORTION_PORN 0.000000,
__EXTRA_MPART_TYPE_1 0.000000, __EXTRA_MPART_TYPE_N1 0.000000,
__FRAUD_COMMON 0.000000, __FRAUD_REPLY 0.000000, __FRAUD_TRUST 0.000000,
__FRAUD_URGENCY 0.000000, __FUR_RDNS_SOPHOS 0.000000,
__HAS_ATTACHMENT 0.000000, __HAS_ATTACHMENT1 0.000000,
__HAS_ATTACHMENT2 0.000000, __HAS_FROM 0.000000, __HAS_HTML 0.000000,
__HAS_MSGID 0.000000, __HAS_XOIP 0.000000, __HIGHBIT_ASCII_MIX 0.000000,
__HTML_BAD_END 0.000000, __HTML_ENTITIES_X4 0.000000,
__HTML_TAG_DIV 0.000000, __HTTPS_URI 0.000000, __IMG_ATTACHED 0.000000,
__IMG_SIZE_10K_50K 0.000000, __JPG_HEIGHT_100 0.000000,
__JPG_SPAMMY_SEGMENT_2 0.000000, __JPG_SPAMMY_Y_RESOLUTION_3 0.000000,
__JPG_WIDTH_100 0.000000, __MIME_ATTACHMENT_1_N 0.000000,
__MIME_ATTACHMENT_N_2 0.000000, __MIME_ATTACHMENT_N_3 0.000000,
__MIME_ATTACHMENT_N_4 0.000000, __MIME_HTML 0.000000, __MIME_TEXT_H 0.000000,
__MIME_TEXT_H1 0.000000, __MIME_TEXT_H2 0.000000, __MIME_TEXT_P 0.000000,
__MIME_TEXT_P1 0.000000, __MIME_TEXT_P2 0.000000, __MIME_VERSION 0.000000,
__MSGID_32HEX 0.000000, __MULTIPLE_URI_TEXT 0.000000,
__OUTBOUND_SOPHOS_FUR 0.000000, __OUTBOUND_SOPHOS_FUR_IP 0.000000,
__OUTBOUND_SOPHOS_FUR_RDNS 0.000000, __PART_TYPE_HTML 0.000000,
__PHISH_PHRASE10_C 0.000000, __RCVD_FROM_HOMEUSER 0.000000,
__RUS_HASHBUSTER_1251 0.000000, __SANE_MSGID 0.000000,
__STOCK_PHRASE_7 0.000000, __STYLE_RATWARE_NEG 0.000000,
__STYLE_TAG 0.000000, __SUBJ_ALPHA_END 0.000000, __TAG_EXISTS_HTML 0.000000,
__TO_MALFORMED_2 0.000000, __TO_NAME 0.000000,
__TO_NAME_DIFF_FROM_ACC 0.000000, __TO_REAL_NAMES 0.000000,
__URI_ENDS_IN_SLASH 0.000000, __URI_HAS_HYPHEN_USC 0.000000,
__URI_IN_BODY 0.000000, __URI_MAILTO 0.000000, __URI_NOT_IMG 0.000000,
__URI_NS 0.000000, __URI_WITHOUT_PATH 0.000000, __URI_WITH_PATH 0.000000
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:qNENHhY/IHg=;i0+IQsw5m8U/KJRskjXia5+bR9M
OQEOWZMmXbMla+j1ezArZeey9
Envelope-To: <admin@domain.de>
X-Spam-Flag: NO
UI-InboundReport: notjunk:1;M01:P0:wWVZg8qLt+Y=;OMm9IZ0fNGz9ilZgz5JL9ULgq+54ps. ganz logisch ist das eh nicht ... wenn man auf sein Postfach zugreifen will, aber das Passwort nicht merh hat, kommt der Reset-Link is das entsprechende Postfach 
