zahni

Auch bei einem anderen User? Dann solltet Ihr Eure Einstellungen prüfen. Ein Self-Signed-Zertifikat kann nicht automatisch vertrauenswürdig sein. Bei dem User, der es erstellt, u.U. schon. Da kann man aber auch per GPO verhindern, dass ein User etwas in den entsprechenden Store importieren kann...

Dann ist die Signatur aber nicht vertrauenswürdig...

Und zum Programmieren: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamea Stichwort "Unicode version"

Im Moment gibt der Server nur HTTP 301 mit einem Redirect auf sich selbst aus. Das ist eher nicht sinnvoll.

Wie ich schon schrieb, werden KMS-Host-Key von MS via VLSC vergeben. Was Dir da irgendein Händler geschickt hast und ob Du nun eine valide Lizenz hast, können wir nicht beurteilen. Wenn Du eine valide Lizenz hast, wirst Du von MS auch einen funktionierenden KMS-Host-Key bekommen.

"IN" ist hier aber sinnvoller. Ich weis gerade nicht, was der SQL-Server bei Wildcards macht. Standard ist aber "%" als Wildcard. Beachte auch, dass SQL-Server bei einem führenden Wildcard u.U. keine Index-Suche machen können. Bei großen Tabellen sollten diese Parameter vermieden werden.

Kannst Du selbst probieren: https://www.jetbrains.com/de-de/decompiler/

Falls es .Net ist: Dafür gibt es Decompiler.

Da kann ich nur raten: Windows 10/2019 haben irgendein neues Treibermodell eingeführt. Es kann gut sein, dass der Wert in der Registry nicht mehr relevant oder bei VMs immer 0 ist. Das musst Du mit dem Hersteller der Software klären.

Was ist das Ziel? Ist der VMWare-Video-Treiber installiert? Dann kannst Du in den VM-Einstellungen mehr Speicher zuweisen. 16 MB reichen meistens.

Ich glaube nicht, dass Du im "Graumarkt" so ohne Weiteres funktionierende KMS-Host-Keys bekommst...

Und zu ursprünglichen Frage: Ein KMS-Host-key ab Windows Server 2016 sollte Windows 10 auch aktivieren. Ist eine VM 2019, braucht man natürlich den 2019'er Host-key. Den Datenträger aus dem VLSC verwenden. Ansonsten muss man u.U,. einen Client-Key nachschieben: https://docs.microsoft.com/de-de/windows-server/get-started/kmsclientkeys

Hallo und willkommen im Forum. Für Experimente empfehle ich https://www.soapui.org/

Prüfe, ob auf dem Ding der Virenscanner an ist. Wenn, ja abschalten.

Hast Du dieses Tool auf dem KMS-Server installiert? https://www.microsoft.com/de-de/download/details.aspx?id=35584

FTP-Server Ich interpretiere das so, dass MS im SMBv3 ab 1903 Compression eingeführt hat und dieser Code anfällig ist. Daher sind Clients gefährdet, weil die Funktion im Client wohl nicht abschalten kann, im Gegensatz zum Server.

Details gibt es hier https://fortiguard.com/encyclopedia/ips/48773 Es wird empfohlen diesen Workaround zu implementieren: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/adv200005 Wobei offenbar der aktuelle Windows Server 2019 nicht betroffen ist. Nur neuere Versionen inkl. Window 10 ab 1903.

Stammt von eine der "bösen" Symantec-CAs...

Windows 2019 ist ausgewählt. Und Blauzahn machen "meine" Server nicht. Die Infos bei Google sind etwas dünn...

Das wird mir "online" bei Windows Server 2019 angeboten, via WSUS aber nicht.

Das ist nicht Sinn der Gruppenrichtlinien. Du möchtest auch nicht, dass Endanwender bestimmte Einstellungen verstellen.

Ja, das ist Absicht.

Wozu sollte man eine Access-DB signieren wollen? Das ist eine Datenbank mit dynamischen Inhalt.

Eventlog prüfen. Im 1. Schritt kann man mal die Queue Length bei Aktivität prüfen: https://www.poweradmin.com/blog/current-average-disk-queue-length-counters/

Das ist ein ziemlich merkwürdiges externes RAID-System (dass man intern verbauen kann) mit SATA-Anschluß nach draußen: https://www.raidsonic.de/products/internal_cases/soho_raid/index_de.php?we_objectID=912#technical_data Das Teil würde ich mal vorsichtig entsorgen...