Windows Server 2019 and .NET 4.8?
Hello, On a fully updated Windows Server 2019, roles and features allow me to install only .NET 4.7. One of the solution we are using require .NET 4.8 (Adaxes). When I install .NET 4.8 using the installer available here https://support.microsoft.com/en-us/topic/microsoft-net-framework-4-8-offline-installer-for-windows-9d23f658-3b97-68ab-d013-aa3c3e7495e0 It works, I can install Adaxes, but it break ServerManager as well as Azure AD Connect. What's the correct procedure to install .NET 4.8 on Server 2019 without breaking anything else? Thanks a lotAnnouncing Native NVMe in Windows Server 2025: Ushering in a New Era of Storage Performance
We’re thrilled to announce the arrival of Native NVMe support in Windows Server 2025—a leap forward in storage innovation that will redefine what’s possible for your most demanding workloads. Modern NVMe (Non-Volatile Memory Express) SSDs now operate more efficiently with Windows Server. This improvement comes from a redesigned Windows storage stack that no longer treats all storage devices as SCSI (Small Computer System Interface) devices—a method traditionally used for older, slower drives. By eliminating the need to convert NVMe commands into SCSI commands, Windows Server reduces processing overhead and latency. Additionally, the whole I/O processing workflow is redesigned for extreme performance. This release is the result of close collaboration between our engineering teams and hardware partners, and it serves as a cornerstone in modernizing our storage stack. Native NVMe is now generally available (GA) with an opt-in model (disabled by default as of October’s latest cumulative update for WS2025). Switch onto Native NVMe as soon as possible or you are leaving performance gains on the table! Stay tuned for more updates from our team as we transition to a dramatically faster, more efficient storage future. Why Native NVMe and why now? Modern NVMe devices—like PCIe Gen5 enterprise SSDs capable of 3.3 million IOPS, or HBAs delivering over 10 million IOPS on a single disk—are pushing the boundaries of what storage can do. SCSI-based I/O processing can’t keep up because it uses a single-queue model, originally designed for rotational disks, where protocols like SATA support just one queue with up to 32 commands. In contrast, NVMe was designed from the ground up for flash storage and supports up to 64,000 queues, with each queue capable of handling up to 64,000 commands simultaneously. With Native NVMe in Windows Server 2025, the storage stack is purpose-built for modern hardware—eliminating translation layers and legacy constraints. Here’s what that means for you: Massive IOPS Gains: Direct, multi-queue access to NVMe devices means you can finally reach the true limits of your hardware. Lower Latency: Traditional SCSI-based stacks rely on shared locks and synchronization mechanisms in the kernel I/O path to manage resources. Native NVMe enables streamlined, lock-free I/O paths that slash round-trip times for every operation. CPU Efficiency: A leaner, optimized stack frees up compute for your workloads instead of storage overhead. Future-Ready Features: Native support for advanced NVMe capabilities like multi-queue and direct submission ensures you’re ready for next-gen storage innovation. Performance Data Using DiskSpd.exe, basic performance testing shows that with Native NVMe enabled, WS2025 systems can deliver up to ~80% more IOPS and a ~45% savings in CPU cycles per I/O on 4K random read workloads on NTFS volumes when compared to WS2022. This test ran on a host with Intel Dual Socket CPU (208 logical processors, 128GB RAM) and a Solidigm SB5PH27X038T 3.5TB NVMe device. The test can be recreated by running "diskspd.exe -b4k -r -Su -t8 -L -o32 -W10 -d30 testfile1.dat > output.dat" and modifying the parameters as desired. Results may vary. Top Use Cases: Where You’ll See the Difference Try Native NVMe on servers running your enterprise applications. These gains are not just for synthetic benchmarks—they translate directly to faster database transactions, quicker VM operations, and more responsive file and analytics workloads. SQL Server and OLTP: Shorter transaction times, higher IOPS, and lower tail latency under mixed read/write workloads. Hyper‑V and virtualization: Faster VM boot, checkpoint operations, and live migration with reduced storage contention. High‑performance file servers: Faster large‑file reads/writes and quicker metadata operations (copy, backup, restore). AI/ML and analytics: Low‑latency access to large datasets and faster ETL, shuffle, and cache/scratch I/O. How to Get Started Check your hardware: Ensure you have NVMe-capable devices that are currently using the Windows NVMe driver (StorNVMe.sys). Note that some NVMe device vendors provide their own drivers, so unless using the in-box Windows NVMe driver, you will not notice any differences. Enable Native NVMe: After applying the 2510-B Latest Cumulative Update (or most recent), add the registry key with the following PowerShell command: reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 1176759950 /t REG_DWORD /d 1 /f Alternatively, use this Group Policy MSI to add the policy that controls the feature then run the local Group Policy Editor to enable the policy (found under Local Computer Policy > Computer Configuration > Administrative Templates > KB5066835 251014_21251 Feature Preview > Windows 11, version 24H2, 25H2). Once Native NVMe is enabled, open Device Manager and ensure that all attached NVMe devices are displayed under the “Storage disks” section. Monitor and Validate: Use Performance Monitor and Windows Admin Center to see the gains for yourself. Or try DiskSpd.exe yourself to measure microbenchmarks in your own environment! A quick way to measure IOPS in Performance Monitor is to set up a histogram chart and add a counter for Physical Disk>Disk Transfers/sec (where the selected instance is a drive that corresponds to one of your attached NVMe devices) then run a synthetic workload with DiskSpd. Compare the numbers before and after enabling Native NVMe to see the realized difference in your real environment! Join the Storage Revolution This is more than just a feature—it’s a new foundation for Windows Server storage, built for the future. We can’t wait for you to experience the difference. Share your feedback, ask questions, and join the conversation. Let’s build the future of high-performance Windows Server storage together. Send us your feedback or questions at nativenvme@microsoft.com! — Yash Shekar (and the Windows Server team)
Enforcing LDAP Signing breaks ADDS Replication (repadmin.exe)
Hi All, After months of auditing Event ID 2889 and remediating application simple binds (clear text usernames/passwords over the wire), I was left with only SASL binds (that do not use signing). I proceeded to set LDAP signing to 'negotiate' as per the GPOs below, and several dozen Microsoft KBs and from the community e.g.. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server Default Domain Controllers Policy Domain controller: LDAP server signing requirements: None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it Default Domain Policy Network security: LDAP client signing requirements: Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller. I still noted 1,000s of Event ID 2889s (0 – SASL Bind that does not use signing), primarily from DCs, and ::1 addresses I proceeded with enforcing LDAP signing ("Require Signing" for both GPO settings above) and noted: LDAP authentication was occurring via Kerberos (SASL/SPNEGO) with simple binds blocked as per tracing (and ldp.exe) confirmations: Error <8>: ldap_simple_bind_s() failed: Strong Authentication Required Error 0x2028 A more secure authentication method is required for this server. However, I came to work the next day and performed a manual replication: Repadmin /Syncall /APeD LDAP error 8 (Strong Authentication Required) Win32 Err 5. So I had to revert back to Negotiate. How can customers enforce LDAP signing if common Microsoft ADDS executables like repadmin.exe still use Simple Binds? Any ideas appreciated, thank you in advance. SteveAD Recycle Bin – “The specified value already exists” but Recycle Bin is non‑functional
I am unable to enable the Active Directory Recycle Bin in an on‑premises Active Directory forest. Environment On‑prem AD DS Forest Functional Level: Windows2016Forest Mixed DC versions (2016 / 2022) When attempting to enable the Recycle Bin using the following command: Enable-ADOptionalFeature -Identity "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "domain.local" the operation fails with the error: “The specified value already exists” However, the AD Recycle Bin is clearly not operational. Observed behaviour Deleted objects are hard‑deleted immediately Nothing ever appears under CN=Deleted Objects LDAP queries using (isDeleted=TRUE) return no results msDS-deletedObjectLifetime and tombstoneLifetime are unset (defaults) CN=Optional Features does not exist in the Configuration naming context Running: Get-ADOptionalFeature "Recycle Bin Feature" shows EnabledScopes referencing an NTDS Settings object, rather than the forest naming context (e.g. DC=domain,DC=local). This strongly suggests that the Recycle Bin optional feature has never been successfully enabled at forest scope, but the environment is now in a state where the enable command is blocked because AD believes it already exists. At present: Recycle Bin is non‑functional Deleted objects cannot be recovered Re‑enabling the feature is not possible via PowerShell or ADAC Has anyone seen this state before, or is aware of a supported method to: correct the optional feature metadata, or complete Recycle Bin enablement properly at forest scope? Any guidance would be appreciated, especially if this requires Microsoft AD DS intervention rather than a configuration change. (Microsoft support routing has been problematic, so I’m hoping someone here may have encountered this scenario before.)Windows Server 2025 DC — LSASS handle leak identified via WinDbg — authz!AuthzpDeQueueThreadWorker
Hello All!! Im having a problem, LSASS crashes on a Windows Server 2025 Domain Controller, I identified what appears to be the root cause using WinDbg memory dump analysis. Sharing this hoping someone else has seen it or Microsoft can confirm. The Problem LSASS handle count grows continuously over time and eventually crashes with a 0xC0000005 access violation (Event ID 1015). After a reboot the cycle repeats. The growth rate correlates with authentication load and faster during peak hours, slower overnight. WinDbg Dump Analysis Captured LSASS dump at high handle count and ran !handle 0 f: Token handles: overwhelmingly dominant Everything else: negligible Every leaked token shows: GrantedAccess: 0x8 (TOKEN_QUERY only) PointerCount: overflowed to negative integer Running !findstack authz 2 shows multiple worker threads all sitting in: authz!AuthzpDeQueueThreadWorker What Was Tested And Eliminated Stopped or disabled each individually and measured handle growth rate — zero meaningful difference from any: - Antivirus (all components) - Backup software - Application services - VSS snapshots - Hardware management agents etc.. Environment OS: Windows Server 2025, fully patched with the latest updates including April LSASS update. Role: Domain Controller DNS PAM: Not active. Conclusion Token handles are opened with TOKEN_QUERY access inside authz!AuthzpDeQueueThreadWorker and never released. Reference counter overflows to negative integer. Growth rate scales directly with authentication load. Current workaround: reboots during off hours. Has anyone else seen this pattern on Windows Server 2025? Is there a known fix or Microsoft acknowledgment for this specific authz token handle leak?
Error al agregar Windows Server 2025 a dominio existente, nivel funcional 2016
Buenas a todos, Me dirijo a esta comunidad en busca de orientación para resolver un problema que se me está presentando al intentar integrar un nuevo servidor con Windows Server 2025 Standard a mi infraestructura de Active Directory existente. Descripción del entorno: Dominio de Active Directory activo con Windows Server 2019 Standard. Nivel funcional de dominio y bosque configurado en Windows Server 2016. Controladores de dominio actuales: server-dc01.impresoratec y server-ad2019.impresoratec. El nombre de dominio interno utilizado es impresoratec (nombre NetBIOS/dominio de etiqueta única, sin sufijo DNS completo tipo .local o .com). Problema: Al intentar agregar el nuevo servidor con Windows Server 2025 al dominio, el proceso falla y se presenta el siguiente mensaje de error: "Es posible que el nombre de dominio "impresoratec" sea un nombre de dominio NetBIOS. Si este es el caso, compruebe que el nombre de dominio está registrado correctamente con WINS. [...] La consulta se refería al registro SRV para _ldap._tcp.dc._msdcs.impresoratec. La consulta identificó los siguientes controladores de dominio: server-dc01.impresoratec y server-ad2019.impresoratec. Sin embargo, no se pudo contactar con ningún controlador de dominio." El mensaje sugiere que los registros de host (A) o (AAAA) pueden contener direcciones IP incorrectas o que los controladores de dominio no son accesibles desde el nuevo servidor. Lo que he verificado hasta ahora: Los controladores de dominio existentes están en línea y operativos. La replicación entre los DCs actuales funciona con normalidad. El nuevo servidor con 2025 tiene conectividad de red general, pero no logra localizar los DCs al momento de unirse al dominio. Mi consulta: ¿Alguien ha experimentado este comportamiento al incorporar un servidor con Windows Server 2025 a un dominio con nivel funcional 2016 y un nombre de dominio de etiqueta única (single-label domain)? ¿Existe algún requisito previo adicional —como la actualización del esquema de AD, ajustes en DNS o en WINS— que deba cumplirse antes de agregar el nuevo DC? Agradezco de antemano cualquier orientación o experiencia que puedan compartir.
sign RDP file with timestamp
Hi, after installing the April 2026 update, our customers experience warning messages when using RDP files to connect to their servers hosted by us. We need to sign the RDP files. But we need to include a timestamp, so the signature stays valid after certificate expiration. rdpsign.exe does not support timestamping. Set-AuthenticodeSignature is unable to access the private key of our code signing certificate which is stored on a HSM. signtool.exe does not support RDP files. What is the recommended procedure in this case? Thank you!
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
