ntoskrnl.exe and build version not getting updated after applying KB5078740 on server 2025
I have installed the latest March patch kb5078740 on server 2025 which was upgraded from server 2022. the patch is showing installed but the ntoskrnl.exe and build version is still showing 10.0.26100.4652. Qualys is detecting it as patch not installed based on file version which should be 10.0.21600.32522. Please let me know how to fix this issue.
Experiences Creating a CA with ML‑DSA Using Microsoft Smart Card Key Storage Provider (ADCS / PQC)
Hi all, I’m exploring the possibility of using post‑quantum cryptography within an Active Directory Certificate Services (ADCS) environment in the Insider release 29550. Specifically, I’m interested in creating a Certificate Authority (CA) where the CA’s key material is generated and stored using a Microsoft Smart Card Key Storage Provider (KSP) with support for ML‑DSA. This is an option selectable in the "Specify the cryptographic options". Has anyone in the community successfully done the following: Created a CA using ML‑DSA: Micosoft Smart Card KSP as the cryptographic provider? If so, what smart card or hardware token did you use that supports ML‑DSA via the Microsoft Smart Card KSP? (e.g., specific vendor and/or model that exposes ML‑DSA support correctly to Windows) Is it actually possible to create a CA using ML‑DSA as the cryptographic provider? If yes, what are the key steps or gotchas? What changes when ML‑DSA is used as the CA key provider compared to traditional providers like RSA/ECC? Any differences in certificate creation, enrollment, templates, compatibility with clients, etc.? Is there any official documentation for using ML‑DSA or PQC with ADCS? Are there other post‑quantum cryptographic (PQC) options already supported or coming soon in ADCS?
Beyond RC4 for Windows authentication - Question regarding KB5073381
In KB5021131 MS recommends setting the value for DefaultDomainSupportedEncTypes to 0x38, in the new KB 5073381 it's 0x18. This removes the setting that forces "AES Session Keys" which should be fine if Kerberos Tickets can only use AES Encryption. But what about accounts that have RC4 enabled in their msds-supportedEncryptionTypes attribute? They could still use RC4 for Kerberos ticket encryption and would then also fallback to RC4 session ticket encryption. As far as I believe the DefaultDomainSupportedEncTypes was explicitly introduced to avoid this scenario. Or is there now some hard-coded mechanism that always ensures that Session Keys are AES encrypted?Bookmark the Secure Boot playbook for Windows Server
Secure Boot is a long‑standing security capability that works in conjunction with the Unified Extensible Firmware Interface (UEFI) to confirm that firmware and boot components are trusted before they are allowed to run. Microsoft is updating the Secure Boot certificates originally issued in 2011 to ensure Windows devices continue to verify trusted boot software. These older certificates begin expiring in June 2026. While Windows Server 2025 certified server platforms already include the 2023 certificates in firmware. For servers that do not, you will need to manually update the certificates. Unlike Windows PCs, which may receive the 2023 Secure Boot certificates through Controlled Feature Rollout (CFR) as part of the monthly update process, Windows Server requires manual action. Luckily, there is a step=by-step guide to help! With the Secure Boot Playbook for Windows Server, you'll find information on the tools and options available to help you update Secure Boot certificates on Windows Server. Check it out today!CrowdStrike Secure Boot Lifecycle Management Content Pack
CrowdStrike has recently released the Secure Boot Lifecycle Management Content Pack. This new feature helps Falcon for IT module users manage Windows Secure Boot certificate updates ahead of these certificates’ expiration beginning in late June 2026. The dashboard provides an at‑a‑glance view of Secure Boot–enabled devices, showing which systems are already compliant with the updated 2023 Secure Boot certificate, which are in progress, and which are blocked or require opt‑in to a managed rollout. It also highlights certificate update failures that may require investigation. In addition, overall readiness is summarized through a compliance gauge, while a 30‑day trend shows how pass and fail counts change as remediation progresses. Filters by operating system, server edition, hostname, and update status help administrators quickly identify devices that need action to help ensure systems remain secure after the certificates expire. The feature also provides management options to opt devices into Microsoft's managed rollout for gradual, tested deployment, and to block updates on hardware with known compatibility issues to prevent boot failures. Note that this feature is available as part of CrowdStrike's Falcon for IT module. CrowdStrike Endpoint Detection and Response (EDR) customers who are not licensed for this module can enable a free trial from the CrowdStrike Store. To learn more about this feature, please see the content pack tutorial video.NTFS permissions are partially not working.
Participant A is sometimes unable to see Participant B’s files. The issue can be resolved by clicking the option: "Replace all child object permission entries with inheritable permission entries from this object." However, the problem keeps reappearing. Windows Server 2022 Datacenter (VMware 7.1), formatted as NTFS.ASP Classic stop working after Windows Server 2012 for x64-based System KB5073698
I hope this will be useful to others. We have a legacy application implemented using classic ancient ASP after the most recent windows server rollup update the ASP pages stop working, without any error message, the worker thread just crashed. It turned out that the network stack was hardened and the old ASP engine did not expect a failure on network operations. I did a short write up here with the solution https://www.linkedin.com/pulse/classic-asp-bug-took-four-days-solve-ridiculous-root-cause-pedruzzi-adw9e
Windows 11 automatically restarting after install security Update — With GPO and WSUS.
Hi everyone, I’m facing a strange behavior with Windows 11 devices that receive updates through WSUS and are fully managed via Group Policy. Here’s the scenario: We have a GPO configured as follows: -Configure Automatic Updates → 4 (Auto download and schedule the install) -Scheduled installation every day at 10:00 -Install during automatic maintenance → disabled -Active Hours configured -Turn off auto-restart for updates during active hours → Enabled -Update deadlines set to 0 (to avoid any forced restart) -No other restart-related policies set in the domain Even with this configuration, after updates are installed, Windows 11 shows the following message: “Your organization manages update settings. We will restart and install this update at X minutes.” And then the device automatically restarts, even when: -a user is logged in -it is outside Active Hours -deadlines are disabled -no-auto-restart is enabled This behavior does not happen on Windows 10 — only on Windows 11.
