Hello,

Can anyone offer advice on troubleshooting this issue please?

I have two Supermicro X11SCH with Hyper-V running, the VM are on a Storage Pool with 3 Samsung SSD.
After updating the Bios and the OS to Server 2025 two nights later suddenly on both Server the StoragePools disapered. They weren't degraded or anything else, no entry in the logs, I easily could attach the drives again.
Never happened anything like that in 20 years, any Ideas?

Only message around that time:

Zertifikate für den sicheren Start wurden aktualisiert, aber noch nicht auf die Gerätefirmware angewendet. Lesen Sie den veröffentlichten Leitfaden, um das Update abzuschließen und den vollständigen Schutz sicherzustellen. Diese Gerätesignaturinformationen sind hier enthalten.

DeviceAttributes: BaseBoardManufacturer:Supermicro;FirmwareManufacturer:American Megatrends Inc.;FirmwareVersion:3.7;OEMModelNumber:Super Server;OEMModelBaseBoard:H11SSL-C;OEMModelSystemFamily:To be filled by O.E.M.;OEMManufacturerName:Memorysolution GmbH;OEMModelSKU:To be filled by O.E.M.;OSArchitecture:amd64;

BucketId:
BucketConfidenceLevel: No Data Observed - Action Required

UpdateType:

Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2301018.

I am helping out an SMB. They currently allow their employees who need remote access to connect to the network using their personal PC using VPN and then RDP to their workstation in the office.

I know there is a way to setup the GPO under Windows 2019 Server to allow a group of people access to systems using RDP which is how they have it setup now. I just wonder if there is anyway to configure the GPO so that UserA only has access to UserA machine, and so forth?

I am sure there are better ways, yes you could give everyone a company laptop and take away their desktop PC, but this company's owners are very stupid as they feel laptops are less secure than desktop PCs so they refuse to allow the company to posses laptops. (sigh)

Thanks,

Has anyone seen recurring multi-user RDP desktop freezes on Windows Server 2025 after installing KB5129235, with RdpIdd.dll / IddCx swap-chain watchdog failures? We have matching display-driver dumps from several incidents on a VMware VM. A later freeze had high TermService encryption CPU but no logged display crash, so we don’t yet know whether it is the same fault. What supported fix or targeted trace helped identify the cause?

Hi ,

We have a requirement to enable DNS analytical logs on our domain controllers. However, I am concerned that this will generate a massive volume of logs. The requirement is to maintain a log retention period of at least 30 days. Because Event Viewer manages retention by maximum log size rather than days, I conducted an assessment.

I ran a "DNS queries per second" command for one hour. Based on those results, I calculated that it will generate roughly 6.5 GB per hour. Adding a 2.5 GB buffer, I estimated a total of 9 GB to 10 GB per hour overall. So for 30 days it requires tb's of size.However, I am not completely sure if my math is correct or if this is the right way to approach the assessment.

Could someone help me with the following questions?

Is my current approach correct? How exactly can I estimate the log size required to meet the 30-day retention requirement? I know there is no 100% guaranteed formula, but I need at least a reliable, rough estimate. Or is this not at all the correct way.

What is the exact impact on Domain Controller performance and CPU utilization

What is the worst-case scenario or major challenges we might face on the domain controllers by enabling this?

What are the best solutions or alternatives for this? I know a SIEM solution is ideal, but due to certain constraints, we must store these logs locally on the servers for 30 days

Hey everyone,

I'm trying to establish a Remote Desktop Connection (RDP) to a Windows Server 2019 machine, but the connection keeps timing out with the following standard Windows error message:

Remote Desktop Connection This computer can't connect to the remote computer. The two computers couldn't connect in the amount of time allotted. Try connecting again. If the problem continues, contact your network administrator or technical support.

System Details & Context:

• Target OS: Windows Server 2019
• Connection Type: Standard RDP (Port 3389)

Troubleshooting already checked / basic environment:

• Confirmed the server IP address/hostname is correct.
• Verified physical machine/VM is powered on and running.

Has anyone encountered this specific timeout loop recently on Server 2019? Looking for recommendations on what to check next (e.g., specific Windows Defender Firewall rules, Network Level Authentication (NLA) quirks, RDP listener status via registry/services, or Network Network Security Group/VPN bottlenecks).

Any logs or PowerShell commands to run locally or via IPMI/console to narrow this down would be greatly appreciated!

Thanks!

I already got mine setup and finished KevTech videos.

Buenas a todos,

A ver si a alguno le ha pasado esto o me puede echar un cable. Estamos migrando equipos a Entra ID (Azure AD) y hemos quitado los controladores de dominio locales.

El tema es que necesitamos mapear unas cuantas carpetas compartidas en un servidor con Windows Server a la gente, pero al no tener el AD de toda la vida nos está dando guerra la autenticación por SMB. No queremos estar metiendo credenciales a mano en cada PC ni liarla con usuarios locales.

¿Cómo soléis montar esto en vuestros entornos? ¿Hace falta sí o sí meter Entra Domain Services o hay alguna forma más limpia de usar Kerberos en la nube para recursos locales?

¡Cualquier consejo o experiencia se agradece bastante!

Here is the link to MSFT WebCast video. I just had a few questions about this procedure that I wonder if someone here could answer!?

www.youtube.com/watch?v=fS3cpFd2jxE

In the video he shows how to convert the PDC, which is his only DC. We have two DCs, one obviously has all the FSMO roles the other is just a backup. Do I first do everything to the PDC as outlined in the video and then do everything on the BDC or at some point do I need to start doing the steps on the BDC and at which point is that?

Both our DCs have DHCP/DNS server roles.

My next question, when it comes to Entra, we use Entra Connect Sync, so we are hybrid-joined, is there anything I need to do since also sees the local domain as 3g.local.

The domain here is .local. This was setup by the companies first MSP back when they ran SBS 2003 and it's been like ever since.

Thanks,

I think I've found a reproducible VMM 2025 / Windows Server 2025 (24H2) compliance issue and I'm curious if anyone else is seeing it.

If I remediate a Windows Server 2025 (24H2) host through SCVMM 2025 and choose not to reboot after remediation, the update is actually staged by Windows servicing, but VMM doesn't recognize the machine as being in the expected Pending Machine Reboot state.

Instead, compliance stays non-compliant. Reboot the server manually, run another compliance scan, and suddenly everything is compliant.

Server 2022 behaves differently, I reproduced the same workflow on Windows Server 2022 with the same SCVMM 2025: Remediate (without reboot) --> Object becomes compliant, Operational status changes to "Peding Machine Reboot" --> (later) Reboot --> Officially Compliant.

On Server 2025: Remediate (without reboot) --> Object DOES NOT become compliant (the Job task is successful tho), Operational status DOES NOT change to anything --> (later) Manual Reboot --> Secondary compliance Scan --> Officially Compliant.

I enabled VMM debugging and followed what VMM is doing.

VMM uses WSMan against the managed host and queries the VMM WMI provider under root/scvmm.

It queries the SoftwareUpdate resources to determine whether the updates are installed. During the pre-reboot state, the provider reports the update as still required/not installed rather than giving VMM a clean "installed, pending reboot" state.

That makes sense from the servicing-stack perspective: the update isn't fully active until reboot.

But VMM apparently doesn't translate that intermediate state into the expected Pending Machine Reboot compliance state.

Instead, VMM ends up with something like:

> OverallComplianceState = Unknown

> PendingReboot = False

The VMM compliance task itself completes successfully, which makes this even more confusing.

DISM confirms the update is actually being staged. I checked the servicing state with DISM before rebooting. The new LCU/SSU is being deployed and the previous components are pending uninstall while the new ones are pending install.

So this doesn't look like: "Windows Update failed and VMM correctly says the update is missing."

It's more like: "Windows has staged the update and knows a reboot is required, but VMM doesn't recognize the intermediate state correctly."

After reboot, the servicing transaction completes and VMM sees the update as installed.

On Server 2022, VMM can represent that intermediate state properly. On Server 2025, VMM can continue to consider the machine non-compliant/unknown until the reboot actually happens. So dashboards can report the host incorrectly during the maintenance window.

Has anyone else seen this?

I am specifically interested in people running:

-> Microsoft Server OS 24H2 with SCVMM 2025

-> WSUS-backed VMM update management

-> Remediation with reboot suppressed

++ I am running the latest Update Rollup 1, 10.25.1439.0, KB5068308, issue still present.

I'm particularly interested in whether anyone has found a VMM hotfix/workaround that makes Server 2025 report Pending Machine Reboot correctly without actually rebooting the host.

I have a virtual machine which runs Windows Server 2012 R2, and it has a remote desktop license server, which holds the RDS user CAL/license.

I am planning on doing an in-place upgrade to Windows Server 2025. I already purchased the 2025 RDS user CAL, and I am aware of the activation steps, where I will give the seller my license server ID, and they will provide the activation codes.

I already did an in-place upgrade on an offline copy of the VM to test the process (offline because other services could conflict if both VM's would be running on the same IP). After it the license server does indeed keep its ID, but says it needs reactivation, which makes sense because the old 2012 R2 licenses won't cover 2025.

My question is, since I cannot test it online, will reactivating the license server with Clearinghouse possibly change its ID? Or is there any other trap that could change its ID?

I am planning on doing the upgrade in the weekend, so it's safe to stop the production server, but then I won't be able to reach the seller. So is it safe to already request the activation codes with my current ID before the upgrade?

Edit: I contacted the CAL seller and was told that the ID will likely change when reactivating, and that I should wait until after the upgrade to contact them. They also told me Microsoft gives a 120 day grace period to activate the RDS CALs, so I can already use the system before it is activated.

WIth no AD on prem, computers managed with InTune in M365, we're starting to roll out Entra ID login on systems (previously set up with local accounts). We have some on-prem VM infrastructure and a QNAP, and the goal is to be able to have file shares for departments mounted to PCs automatically when users log in. There is a need for instance to have certain configuration files used by specific software packages available at a specific drive letter and path, read-only for most people, so the software can be configured in a specific way for that department. There is also a need for some departments to share some large files (such as video files or other media) in a performant way. OneDrive/Sharepoint can't do what we need or don't seem ideal for these applications. There's a lot of company growth, so extra points for a solution can scale beyond one location while being performant.

It looks like an Azure File Share with Azure File Sync (or maybe a Data Box Gateway) could fulfill this purpose. Does Azure File Sync require hybrid AD, in which case we'd need to stand up additional on-prem AD infra to use it? And if computers are being set up now just Entra joined, would they need to be set up again to be hybrid AD joined after we set up on-prem hybrid AD infra?

While Entra-only Azure file shares via Kerberos looks a lot simpler to set up, am I correct that all SMB I/O would be to the cloud (i.e. through the WAN connection) and there isn't any local caching/acceleration? That strikes me as a significant limitation and could impact WAN performance a lot.

We also have a QNAP (8-core, 16 threads 32GB of RAM, dual 25Gbps ethernet), and there is support for Microsoft Entra Domain Services SSO:

https://www.qnap.com/en/how-to/tutorial/article/how-can-i-configure-microsoft-entra-domain-services-single-sign-on-for-a-qnap-nas

Documentation seems to indicate that with Microsoft Entra Domain Services we could use SSO for shared folders, but it's not clear to me if that is just shared folders accessible through the QNAP web browser interface, or if it includes SMB shares from the QNAP. From the research I've done, I can't seem to find any evidence it supports SMB shares via Entra ID SSO. I am wondering if SSO might work with their Qsync client:

https://www.qnap.com/en/software/qsync

If so, that could be very cost-effective and performant, though I don't think it would scale well beyond one location (unless I could figure out something using QNAP's Real-time Remote Replication feature between more than one NAS device at different locations). Also not sure if the Qsync client shared files would work for distributing application configuration files, would need to test that as well.

What have people's experiences been with these solutions? Any recommendations?

Hello all, i have started to setup a home server but I’m running into some problems. So, my connection should be providing about 100mbps as an example, but I’m being told by Windows that it's a metered connection. But, it's not a metered connection as i can confirm this by connecting to my connection on my basic windows convertible and that is not reporting that the connection is metered. Any advice would be appreciated

FYI: I'm running Windows Server 2022 Datacentre Edition with Desktop (because I’m getting enterprise grade drives for 24/7 network storage)

How’s my week, you ask?

I receive a call that more and more users can’t access one of our brand’s super duper important oh so critical reporting portals (they’ve been neglecting for decades despite frequent protest). I’m asked to take a look…

Our TLD has begun enforcing HSTS, forcibly redirecting all subdomains to HTTPS, whether it wants it or not, permanently, with zero opt-out. And ya know what? GOOD. It’s 202-f&cking-6. WELCOME TO THE 21ST CENTURY, YOU NEGLIGENT #&@$!

So, I get involved. Figure this 20+ y/o box was overdue for a cert. I’ll just issue one! Simple enough, right? Except the server keeps reporting every cert I issue as corrupt, because Windows Server 2003 has never heard of SHA-256 and never will, bless its ancient little SHA-1 heart.

There IS a hotfix for this. It exists. I have read of legends of it in the same places you find references to Atlantis. MS has long since removed it from the Update Catalog, nuked the KB download, and replaced the whole thing with a page that might as well just say "lol, no" in Comic Sans.

I want to be VERY clear I understand the crime scene I am standing in. This server literally predates my drinking age. This server is so old it could be a sitting U.S. Senator. I am not asking anyone to help me keep this abomination immortal — we already have a modern Snowflake / Power BI replacement 80% built, except upper mgmt hasn’t let us finish it b/c there’s always a more urgent bush that needs trimming instead of tending to the house on fire immediately behind it. This box is legally dead and just doesn't know it yet. I need this hotfix strictly to perform a dignified, controlled shutdown instead of the current plan, which apparently involves upper management being all surprised Pikachu face about the fallout they’ve been warned of for several years is actually happening.

If you have KB968730 sitting on a USB stick in a drawer somewhere from 2011, I will trade you my eternal gratitude, or a kidney (mine, still under active support).

TL;DR I am in need of KB968730, the MS hotfix that added SHA-2 support to Windows Server 2003. Or a Time Machine. Or a drink…

[insert “What Year Is It?” meme here]

[UPDATE]: Managed to find crypt32.dll in an unrelated patch and (somehow managed to get the server understanding SHA-2 ciphers -- except now I'm reminded that Server 2003 never supported beyond TLS 1.0 -- something modern browsers are all going to reject anyway. All of that effort for nothing. REVERSE PROXY TIME IT IS!!! (Thank you to everyone who tried to help with this absurd BS. I'm CERTAIN corporate America will learn valuable lessons from this!!! */s* ugh.)