mwiederkehr

Public und Private Key gehören zusammen und werden zusammen erzeugt. Der Client kann seinen Public Key über einen ungeschützten Kanal dem Server übermitteln, aber selbst erzeugen kann ihn der Server nicht. Ein Pre-Shared-Key erhöht die Sicherheit, indem er der asymmetrischen Verschlüsselung noch eine symmetrische Verschlüsselung vorschaltet. Falls es in ein paar Jahren Quantencomputer geben sollte, welche das asymmetrische Verfahren brechen können, wären die Daten durch den PSK immer noch geschützt. Dies ist aber in den meisten Fällen mehr eine theoretische Gefahr: es ist eher unwahrscheinlich, dass jemand heute Deinen Traffic mitschneidet und sich dann Jahre später einen Quantencomputer kauft, um die Daten zu entschlüsseln. Wenn sich jemand Zugang zur Konfigurationsdatei verschafft, hat er auch Zugang zum Private Key und ja, das wäre eher nicht so gut. (Wenn jemand einen solchen Zugriff auf Deinen Rechner hätte, könnte er aber auch einen Keylogger oder so installieren.)

Früher musste man Office neu installieren, da es eine andere Edition war. Aktuell soll es funktionieren, indem man die alte Lizenz entfernt und beim nächsten Start einer Office-Anwendung dann die neue Lizenz einträgt (bzw. sich neu anmeldet): https://answers.microsoft.com/en-us/msoffice/forum/all/upgrade-from-office-365-business-premium-to/45f1d3f1-eeb7-47d1-9d32-2b1429fb70ad

Ich verwende für Standardserver die "Read Intensive" SSDs von HPE. Die haben offiziell 1 DWPD. Hatte noch nie einen Ausfall. Das gilt natürlich nicht für schreib-intensive Anwendungen. Bei meinen Kunden erzeugt das Windows Update wohl die höchste Schreiblast. Bezüglich Schutz von Backups vor Malware: Der Backupserver muss (zumindest bei Veeam) nicht Mitglied der Domäne sein und von den Hosts aus auch nicht erreichbar. Veeam holt sich die Daten, die Hosts liefern sie nicht. Ich schränke den Zugriff auf den Backupserver gern ein: nur RDP und nur vom Admin-Netz. Sichert man auf ein NAS, kann man dort ein Backup der Backupdaten konfigurieren. Und sei es nur ein Snapshot auf dem gleichen Volume, eine Malware kommt da nicht dran. Wie Du eindrücklich geschildert hast, sind auch Daten in der Cloud nicht 100% sicher. Es ist aber unwahrscheinlich, dass man sich lokal Malware einfängt und gleichzeitig der Cloud-Provider einen Fehler macht. Viele Cloud-Backup-Lösungen bieten mittlerweile einen Schutz gegen Malware. Bei Veeam Cloud Connect heisst das Feature "Insider Protection": gelöschte Backups werden damit für einen definierbaren Zeitraum nicht definitiv gelöscht, sondern sind nur noch für den Provider zugänglich. Bei Azure heisst das Feature "Immutable Storage" und man kann diverse Regeln festlegen, ob und wann etwas gelöscht oder überschrieben werden darf. Welche Lösung man auch wählt, man sollte prüfen, ob sie für den Fall "Malware läuft als Domain-Admin in meiner Produktivumgebung" gerüstet ist.

Wenn ich das richtig sehe, geht es bei der Anleitung um die Installation der Essentials-Rolle auf einem Server Standard, nicht um die Essentials-Edition. Ein Server mit Essentials-Edition muss laut Microsoft immer der einzige DC sein. Ausnahme: er ist Host für einen Essentials (und nur für diesen). Dann muss der Host nicht in einer Domäne sein. Technisch sollte es deshalb funktionieren, einfach keine Domäne einzurichten. Ein Lizenzverstoss ist es ggf. trotzdem. Habe mal irgendwo gelesen, dass der Essentials der einzige DC sein muss, WENN er als DC konfiguriert wird. Finde die Aussage leider gerade nicht mehr und weiss nicht, ob die von Microsoft kam oder nicht.

Ich sichere viele Hosts mittels Veeam Endpoint. Funktioniert zuverlässig und ist kostenlos. Aber wenn ich so auf die letzten Jahre zurückblicke, muss ich sagen, es war eigentlich den Aufwand nicht wert. Denn wie häufig fällt ein Host schon unrettbar aus? Fällt die Hardware aus, steckt man die Disks in den als Ersatz vorhandenen oder gelieferten Server. Und ein fehlerhaftes Windows Update hat mir zumindest seit Server 2012 noch nie das System unrettbar zerschossen. Und im schlimmsten aller Fälle ist der Host in kurzer Zeit neu installiert. Es empfiehlt sich aber, die VM mit der Backupsoftware nach Updates jeweils zu sichern (VHDX wegkopieren reicht). Denn sonst muss man im Notfall die auch noch installieren, konfigurieren etc. Das geht auch keine Woche, aber länger als einfach die VHDX-Dateien zurück zu kopieren.

Haben sich die Benutzer nach dem Hinzufügen zur Gruppe neu angemeldet?

Bei mir ist der Reader noch als x86 installiert und die Registry-Einstellungen befinden sich unter "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Adobe\Acrobat Reader\DC". Im Profil sind noch Dateien unter "AppData\Roaming\Adobe\Acrobat\DC" sowie "AppData\LocalLow\Adobe\Acrobat\DC" und "AppData\Local\Adobe\Acrobat\DC".

Hat der Benutzer einen anderen Standarddrucker als die anderen Benutzer? Hast Du schon versucht, die Einstellungen vom Adobe Reader beim Benutzer zurück zu setzen (AppData und Registry)? Abstürze beim Drucken habe ich hie und da erlebt (und in hartnäckigen Fällen half die Option "als Bild drucken"). Aber das war immer drucker- und nicht benutzerspezifisch.

Könnte das "Snap"-Feature schuld sein? In den Einstellungen unter System - Multitasking kann man das "Fenster andocken" deaktivieren. (Man kann auch im Startmenü nach "Snap" suchen.)

Ja, verständlich. (Erinnert mich an mein grandioses Scheitern, als ich im jugendlichen Leichtsinn einen Spamfilter als Event Sink für Exchange 2003 schreiben wollte. Hat sich der aufgehängt, kamen keine Mails mehr rein. War deshalb auch nur ein paar Tage im "produktiven" Einsatz im Ausbildungsbetrieb. ) Das verlinkte Projekt würde ich diesbezüglich als brauchbar bezeichnen. Der Code ist einfach und gut überschau- bzw. auditierbar. Ihn durch einige benutzerdefinierte Regex-Filter zu ergänzen wäre machbar. Nur darf man ob der Möglichkeiten von .NET nicht übermütig werden und "mal eben" eine Online-API anbinden...

C++ und so tief im System ist auch nichts für Jedermann... Es gibt aber ein Projekt, welches eine DLL bereitstellt, welche dann Test-Funktionen in einer .NET-DLL aufruft. Man muss dann "nur" noch das Passwort entgegen nehmen und true oder false zurückgeben: https://github.com/raandree/ManagedPasswordFilter Sieht durchdacht aus und die Einbindung neuer Filter mittels Reflection ist ein pfiffiges Konzept.

Starten kann man ein Meeting soweit ich weiss nur von der Software aus. Teilnehmen kann man auch per Browser, wenn man eine Einladung erhält. Dies geht sogar ohne Account als Gast. (Gewisse Funktionalität wie das Teilen des Bildschirms steht dann natürlich nicht zur Verfügung.) Aber: da die kostenfreie Version keine geplanten Meetings erlaubt, kann man wahrscheinlich damit keine Leute einladen.

Es gibt eine kostenfreie Version von Teams, welche aber einige Einschränkungen aufweist: https://support.office.com/en-us/article/differences-between-microsoft-teams-and-microsoft-teams-free-0b69cf39-eb52-49af-b255-60d46fdf8a9c Teams taugt definitiv für den produktiven Einsatz. Die Funktionalität geht erheblich weiter als "nur" Videokonferenzen. Wenn man nur während der aktuellen Situation schnell eine Videokonferenz braucht, sind Tools wie Blizz, Hangouts oder Zoom evtl. einfacher. Kommt darauf an, ob die Teilnehmer alle einen Account erstellen und eine Software installieren wollen/können, oder ob es per ID im Browser funktionieren muss.

Die Hardware sollte ausreichen. Ich würde aber kein Projekt mehr mit Server 2016 starten, zu mühsam ist die Update-Problematik. Da seit Server 2019 eine Domäne für RDS User-CALs benötigt wird, würde ich eine Standard-Lizenz kaufen und zwei VMs machen: ein DC und ein Terminalserver. Alternativ könntest Du bei dieser Benutzeranzahl auch einen Cloud-Service prüfen.

Ich halte das ebenfalls für keine gute Idee. Der Mailserver des Absenders behält die Mails ja in der Warteschlange. Und er informiert den Absender, falls die Zustellung länger dauert. Nimmt stattdessen ein Server von Domainfactory die Mails an, wurden sie aus Sicht des Absenders zugestellt, obwohl der Empfänger sie noch nicht im Postfach hat. (Und wenn Domainfactory ein Problem hat, können die Mails verloren gehen, ohne dass Absender oder Empfänger davon wissen.) Bei Wartungsarbeiten gehe ich noch weiter und mache den Port 25 auf der Firewall zu. Aufgemacht wird er erst wieder, wenn das Update erfolgreich installiert wurde. So könnte man im Extremfall sogar die Datenbank aus einer Sicherung wieder herstellen, ohne Mails zu verlieren.

Eine Lösung für Dein konkretes Problem habe ich nicht, aber ich kann Dir nur dazu raten, für solche Sachen einen vServer mit Vollvirtualisierung zu verwenden. Dann läuft ein "normaler" Kernel und Du bist nicht eingeschränkt mit TUN/TAP etc. Auch wenn Du es so irgendwie hinbekommen würdest, irgendwann aktualisieren sie den Host und dann geht es vielleicht nicht mehr. Als Tipp kann ich Hetzner nennen, bei denen sind auch die kleinen vServer voll virtualisiert. Es gibt aber natürlich noch viele andere Anbieter.

Mir fallen dazu zwei mögliche Lösungen ein: SSH Reverse Tunnel: die Controller bauen eine SSH-Verbindung zum Server auf. Über diese Verbindung wird der Port weitergeleitet. WireGuard: Eine recht neue Lösung. Ein VPN, welches Verbindungen auch von hinter NAT-Firewalls aufbauen kann. Damit wären die Controller vom Server aus so erreichbar, als stünden sie im gleichen Netzwerk.

Mit Kanalbündelung gingen bei ISDN 128k, aber hat dann auch doppelt gekostet... Zum Glück hatte der Nachbar dann mal Kabelinternet (DSL gab es da noch nicht). Für die Verbindung über die Strasse musste ich einen der ersten Access Points kaufen (Cisco...). Ersparnisse weg, dafür 512k und ohne Zeitlimit.

Als Tipp für den Anfang die Parameter, die ich jeweils setze: robocopy /e /v /mir /copyall /b /efsraw /XJ /r:0 /w:0 /tee /log:c:\temp\robocopy_log.txt \\quelle\d$\Daten D:\Daten Erklärung: /e: Unterverzeichnisse kopieren, inkl. leeren Verzeichnissen /v: ausführliche Ausgabe /mir: Dateien spiegeln (in Quelle nicht vorhandene Dateien werden in Ziel gelöscht) /copyall: alle Dateiattribute (Schreibgeschützt, Archiv, Sicherheitsinformationen, Besitzer etc.) kopieren /b: im Backup-Modus kopieren (damit können auch sonst nicht zugängliche Dateien wie Benutzerprofile kopiert werden) /efsraw: EFS-Dateien kopieren, ohne sie zu entschlüsseln (funktioniert sonst nicht, wenn der ausführende Benutzer keinen Schlüssel hat) /XJ: Links nicht folgen (sonst Endlosschleife bei "App Data" im Profil) /r:0: keine Wartezeit bei Fehlern /w:0: keine Wiederholung bei Fehlern /tee: Ausgabe auf Shell und in Logdatei Damit habe ich schon manchen Server migriert. Ein Knackpunkt bei Dir könnte die sehr grosse Anzahl der Dateien sein, welche abgeglichen werden muss über die schmale Leitung. Bei sehr vielen Dateien dauert das Vergleichen seine Zeit, auch wenn schlussendlich nur wenige Dateien kopiert werden müssen. Das findest Du mit einem Testlauf aber schnell heraus.

Robocopy kann inkrementell im Sinne von "nur geänderte Dateien" kopieren. Wenn einzelne Dateien nicht allzu gross sind, ist es das Tool der Wahl. Bei sehr grossen Dateien, die man inkrementell im Sinne von "nur geänderte Blöcke" kopieren muss, würde ich rsync nehmen. Das bedeutet (unter Windows) aber mehr Aufwand.

Ist auch einfacher, kann dafür weniger. Ein Vorteil von XML ist ja, dass man ein Dokument validieren kann. Das ist bei JSON nicht gegeben. Richtig Freude macht auch XSL. Damit kann man sehr viel machen, ohne an einer Anwendung Änderungen vornehmen zu müssen. Wenn man von seiner Anwendung aus ein PDF generieren muss, welches vom (versierten) Anwender anpassbar sein muss, kann man entweder etwas wie Crystal Reports nehmen oder aber man schreibt ein XML, transformiert es mittels XSLT zu XSL-FO und dieses dann in ein PDF. Das Stylesheet ist vom Benutzer frei anpassbar. Umgebungen wie das .NET Framework liefern die notwendigen Werkzeuge (Interpreter etc.) schon mit. Man kann aus einer XML-Datei (oder besser: einem Schema) auch direkt Klassen erzeugen lassen. Liest man dann ein XML ein, hat man alle Elemente in einem Array mit den richtigen Datentypen. (Und das ist unglaublich schnell: ich arbeite oft mit XML-Dateien über 100 MB und das Einlesen dauert keine Sekunde.)

Du musst keine Lizenzen zuweisen, das macht der Server selbst. Bei Gerätelizenzen bekommt jedes Gerät nach der Anmeldung ein "Lizenzzertifikat" und auf dem Lizenzserver wird entsprechend eine Lizenz abgezogen. Bei Benutzerlizenzierung wird die Lizenz im AD eingetragen. Die Anzahl der Benutzerlizenzen wird nicht kontrolliert im Sinne von "kein Login mehr möglich, wenn keine freien Lizenzen vorhanden sind". Dies ginge gar nicht, da Microsoft Benutzer im Sinne von Personen lizenziert, nicht im Sinne von Benutzerkonten. Bei einem Audit muss man aber natürlich trotzdem die korrekte Anzahl an Lizenzen vorweisen können. Mischen kannst Du die Lizenzen nicht. Ein Terminalserver befindet sich immer entweder im "pro Benutzer"- oder "pro Gerät"-Modus. Die Gerätelizenzen sind nicht von einer Domäne abhängig. Auch ein Client auf Android bezieht eine Lizenz.

Zum Thema Quarantäne: kann davon nur abraten. Aus den Gründen, die Norbert schon genannt hat und fast noch wichtiger: es gab Reklamationen von Benutzern, dass sie wichtige Informationen zu spät erhalten hätten. Schickt ein Kunde eine Anfrage und die wird falsch positiv erkannt und abgelehnt, erhält er eine Fehlermeldung und ruft an. Geht die Mail in die Quarantäne, sieht der Benutzer sie erst am nächsten Tag. Man hat dann das Interval für Quarantäne-Mails auf eine Stunde herabgesetzt. Das hat dazu geführt, dass manche Benutzer mehrmals pro Tag eine Mail durchlesen mussten, nur um zu sehen, dass alles korrekt erkannter Spam war. Bei Antispam halte ich Quarantänen deshalb für nicht sinnvoll. Bei potentiell gefährlichen Dateianhängen kann man sich überlegen, diese an ein anderes Postfach umzuleiten. Wobei man da den Datenschutz beachten muss, besonders wenn die private Nutzung von E-Mail am Arbeitsplatz nicht explizit verboten ist. Neben den genannten Lösungen ist vielleicht https://efa-project.org/ noch einen Blick wert. Habe davon viel Positives gehört. (Kein Wunder, die Komponenten dahinter sind seit Jahren etabliert, wie SpamAssassin etc.)

Bei neueren Versionen von Windows gab es in der Vergangenheit nur selten Sicherheitslücken bei RDP bzw. dem Gateway und von denen waren noch weniger ohne Authentifizierung ausnutzbar. Von daher halte ich das Risiko für vertretbar, wenn man seine Systeme aktuell hält. Als wichtiger erachte ich den Schutz gegen fremde Logins wegen schwachen oder (ehemaligen) Mitarbeitern bekannten Passwörtern. Wenn ein Mitarbeiter geht, gibt es den Schlüssel ab. Er weiss jedoch vielleicht das Passwort eines Kollegen und dank Terminalserver kann er sich immer noch einloggen, auch wenn er keinen Zutritt zur Firma mehr hat. Deshalb halte ich es für ratsam, den Zugriff von aussen auf die Benutzer zu beschränken, die ihn benötigen und mittels Zwei-Faktor-Authentifizierung abzusichern. Da haben wir mit Duo gute Erfahrungen gemacht.

Was kommt denn für eine Fehlermeldung? Grundsätzlich kannst Du den (alten?) Weg über die .Net-Klasse "Net.Mail.SmtpClient" gehen oder den neuen über den Befehl "Send-MailMessage", aber nicht beide gleichzeitig.