News April-Patchday für Windows 11: 1.000 Hz Monitore, Secure-Boot-Status und 165 Sicherheitslücken

Die RDP Meldung war das erste das ich deaktiviert habe. Ich greif vom HomeDesktop auf den HomeServer zu und da ist die Meldung ziemlich nervig. Registry Tweak for Disable
 
Ich bin gerade etwas genervt von den Secure-Boot-Updates. Auf meinem AM5-System hat es einwandfrei funktioniert, obwohl das Bios ziemlich genau ein Jahr alt ist.

Beim AM4-System (Asrock B450M-Pro4) kam im Dashboard eine Fehlermeldung und ich habe deshalb das top-aktuelle Bios draufgezogen - was eine ziemlich nervige Angelegenheit geworden ist "dank" FTPM, Secure-Boot und Verknüpfung mit dem Microsoft-Konto- und siehe da: stimmt angeblich immer noch nicht (lt. Dashboard) :grr:

Update: nach mehreren Neustarts jetzt doch in Ordnung -> also nicht nur einmal neu starten, sondern mehrmals :cool_alt:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: iamsiggi
1776262257239.png

So schaut es bei einem Thinkpad P14s Gen6 aus - heute wurde ein BIOS Update veröffentlicht:

[New functions or enhancements]
- Add Microsoft Option ROM UEFI CA 2023.
(Note) DB is not updated automatically. It is required to perform “Restore Factory Keys” in Secure Boot menu in ThinkPad Setup.
BitLocker Encryption must be suspended/disabled before performing “Restore Factory Keys”
(Note) Certificate “Microsoft Option ROM UEFI CA 2023” is added to DB only when “Allow Microsoft 3rd Party UEFI CA” is set to On.
  • Add solutions for security review-BIOS binary check.
  • Updated UEFI CA for Lenovo Cloud Server.
 
Die Sicherheitsmeldungen zum RDP werden für sehr viel Support Aufwand sorgen.
 
  • Gefällt mir
Reaktionen: culus, IDontWantAName und qiller
Simanova schrieb:
Die Sicherheitsmeldungen zum RDP werden für sehr viel Support Aufwand sorgen.
Bei uns kamen durchaus dazu anfragen rein...
 
  • Gefällt mir
Reaktionen: qiller
@Laborer:

manuell kannst du es probieren über:
1. Admin-CMD/PS:
Code:
wincsflags /query

sollte sowas anzeigen (hier schon umgestellt):
Code:
Flag: F33E0C8E
  Current Configuration: F33E0C8E002
  State: Enabled
  Pending Configuration: None
  Pending Action: None
  CVE: CVE-2026-21265
  FwLink: https://aka.ms/getsecureboot
  Available Configurations:
    F33E0C8E002
    F33E0C8E001

2. wenn "Current Configuration: F33E0C8E001" dann umstellen auf 002 mit
Code:
wincsflags /apply --key "F33E0C8E002"

3. Status abfragen in einer Admin PS:
Code:
Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\ -Name UEFICA2023Status | Select-Object UEFICA2023Status
sollte anzeigen "notStarted"

4. Windows sagen, dass Update für Secureboot bereitstehen in einer Admin PS:
Code:
Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot’ -Name ‘AvailableUpdates’ -Value 0x5944

5. die Umstellung starten in einer Admin PS:
Code:
Start-ScheduledTask -TaskName ‘\Microsoft\Windows\PI\Secure-Boot-Update’

6. noch mal Status abfragen in einer Admin PS:
Code:
Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\ -Name UEFICA2023Status | Select-Object UEFICA2023Status
sollte anzeigen "inProgress"

7. Neustart

8. nochmal den Task starten in einer Admin PS:
Code:
Start-ScheduledTask -TaskName ‘\Microsoft\Windows\PI\Secure-Boot-Update’

9. Status noch mal checken (ggf. mehrfach, da er einen Moment braucht) in einer Admin PS:
Code:
Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\ -Name UEFICA2023Status | Select-Object UEFICA2023Status
sollte anzeigen "Updated"
 
  • Gefällt mir
Reaktionen: CountSero, Lemon Wolf, Laborer und eine weitere Person
@Nebula123
Danke vielmals 😀👍
Jetzt scheint es richtig zu sein, auch bei Gerätesicherheit wird jetzt der Text angezeigt, so wie es im Bild des Artikels abgebildet ist.
Ich bin dafür, dass dein Beitrag in den Artikel eingefügt wird, denn es wird wohl nicht jeder in den Beiträgen nachsehen.

Normalerweise müsste das doch automatisch geschehen, ohne das man da selbst herumfummeln muss.
Oder liegt das einfach nur an der Trägheit seitens Microsoft, wo sie dies nicht automatisch an alle gleich schnell ausliefern?
 
  • Gefällt mir
Reaktionen: Laborer
Drecks-Update. Als erstes kam nach dem Update "Windows muss in einer MInute neu gestartet werden" weil irgendwas schief gegangen war (hab schon vergessen was es war). Zig Programme aus dem Autostart spuckten nur Fehlermneldungen aus. Wenn das so schon losgeht....arrgh... PC neu gebootet dann ging es. Aber nun soll ich nach dem Update eine neue Windows Hello PIN vergeben, wtf - ich hab in meinen Gruppenrichtlinien extra angegeben dass die PIN nie ablaufen soll, wurde einfach ignoriert. Ausserdem soll sie jetzt 6 Zeichen lang sein, ich hatte aber immer 4, reicht mir. Dann wurde beim Anmelden mein Fingerabruck-Sensor einfach abgeschaltet. Ich musste erst die PIN auf eine Länge ändern die ich nicht wollte und dann noch meinen Finger neu registrieren. Dann neu booten und explizit Fingersensor auswählen. Was ein Rotz, nichts davon hat Microsoft zu interessieren, ich habe nur einen lokalen Admin-Account und sonst nichts, keinen MS Online Müll-Account, nichts, nada. Das alles musste ich wieder umständlich auf meine Wünsche zurücksetzen mit einem Registry-Hack und neuen Gruppenrichtlinien.
Dann sollte ich mich bei Steam und EA neu anmelden. Was soll das?
Dann hat er mir für meine NVME SSDs einfach wieder den ollen Standardtreiber aktiviert. Was geht MS das an welchen Treiber ich für meine Disks aktiviere? Der neue NVME Treiber lief bei mir ohne Probleme.
Ein verschissenes Update und dann so eine Prozedur um einem das Leben unnötig kompliziert zu machen.
 
Update lief auch bei mir ohne Probleme durch... mal abwarten ob sich die nächsten Tage was zeigt. :D

Nen 1k HZ OLED zu nem vernünftigem Preis wäre auch was für nen zukünftiges Upgrade...
 
Secureboot Zertifikate kann man über 3 Methoden aktualisieren lassen (die man nicht mischen soll, lt. MS):
  • per Registry Keys
  • per wincsflags (die Methode hat @Nebula123 oben skizziert)
  • per GPO

https://techcommunity.microsoft.com...ring-in-2026/4469235#community-4469235-_step4

snakesh1t schrieb:
Dont work after microsoft patch day!
War heute beim Doc^^. Aber der große Sturm wird morgen erst losgehen :x. Die meisten Clients werden ja erst heute beim Runterfahren gepacht.
 
Nebula123 schrieb:
sollte anzeigen "inProgress"
Stand dann schon auf "Updated" - musste also nur die Steps 1-6 durchführen :)

Bin auch dafür, dass dies verlinkt wird :)

Woher das KnowHow zu dem Thema wenn ich fragen darf?
 
Die "Windows App" aus den MS Store ist jetzt auch übrigends die offizielle RDP Anwendung die alte wird nicht mehr weiter gepflegt, man braucht aber kein Konto mehr für die App. Habe sie aber noch nicht getestet.
 
0xffffffff schrieb:
Kritischer sind da mMn. verstecke Hintergrundsysteme wie die Intel Management Engine die an dem eigentlichen OS vorbei machen können was sie wollen.
Leider hat das jeder Hersteller aber heutzutage… Ich kann der Argumentation folgen, dass man dem User oder Virus keinen Zugriff auf diesen Bereich geben möchte wegen Sicherheit, aber es öffnet Tür und Tor für den Hersteller.
 
cryeR schrieb:
Die "Windows App" aus den MS Store ist jetzt auch übrigends die offizielle RDP Anwendung die alte wird nicht mehr weiter gepflegt, man braucht aber kein Konto mehr für die App. Habe sie aber noch nicht getestet.
Wie viele unterschiedliche Arten für dieses eine Programm gibts denn mittlerweile? xD Wir nutzen für unsere RDS-Infra eigentlich nur die klassische/alte Version (mstsc.exe)
 
Phoenixxl schrieb:
Wie viel Strom willst du im Leerlauf verbrauchen?

Gar keinen, weil wer seinen Rechner im Leerlauf lässt, ist doch selbst Schuld. Dafür gibt es den Standby.
 
@MaverickM Die 2-3W mehr in Officebetrieb zählt für die meisten wohl als „Leerlauf“ - hier waren es tatsächlich im Schnitt nicht mehr und sofern man keine Workstation für CAD oder ähnliches benötigt wird das für die meisten nicht anders aussehen … die wenigsten werden ihren PC wie eine Konsole ausschließlich zum Zocken nutzen :p
 
Wolfgang.R-357: schrieb:
Normalerweise müsste das doch automatisch geschehen, ohne das man da selbst herumfummeln muss.
Oder liegt das einfach nur an der Trägheit seitens Microsoft, wo sie dies nicht automatisch an alle gleich schnell ausliefern?
ja, MS hat versprochen, dass man dass automatisch laufen soll, aber damit das Update klappt brauchst du aber 2 Sachen: Die entsprechenden Windows Updates, die das Update durchführen können UND die Zerts auf Firmwareebene. An letzterem krankt es teilweise.
So habe ich schon Rechner mit Intel 8./9. Gen gesehen, die die notwendigen BIOS-Updates nicht mehr bekommen. Oder aktuelle HP/Lenovo Business-PCs, wo man die neuen Keys im BIOS explizit aktivieren muss.

Von VM-Umgebungen ganz zu schweigen; hier muss man händisch ran (bis auf Hyper-V). Bei VMware brauchst du VM-Version 21 und musst die .nvram-Datei der VM neu erstellen lassen, bei Proxmox muss ein "key-enroll" für jede VM gemacht werden (jeweils im ausgeschalteten Zustand)
Ergänzung ()

Laborer schrieb:
Woher das KnowHow zu dem Thema wenn ich fragen darf?
Ich darf das für alle meine Kunden machen, hunderte VMs und tausende PCs/NBs. Während ich das bei den Clients einigermaßen steuern kann muss man das bei den VMs händisch machen.


Bei den Fireware Updates oder der Key-Aktivierung im BIOS darf man sich dann ggf. noch mit Bitlocker rumschlagen (Recovery-Key)
 
  • Gefällt mir
Reaktionen: Laborer
Nebula123 schrieb:
bei Proxmox muss ein "key-enroll" für jede VM gemacht werden (jeweils im ausgeschalteten Zustand)
Da ich das auch noch bei einigen VMs vorhabe und noch nie gemacht habe: Habe gelesen, man soll die VM runterfahren, die 4MB große EFI-Disk löschen und dann diese nochmal neu anlegen, anstatt die Keys übers Menü neu auszurollen?
 
Zurück
Oben