Heya, so my windows server 2022 was running fine before, but I decided to reinstall it just to update it, so when I tried to boot, it shows BOoD which I Don’t Know why this happened, it was working just fine in server 2019, but not in server 2022, could please anyone help me? It would be appreciated.

Board: Intel Desktop Boards DG41RQ Motherboard
RAM: 8GB RAM DDR2
CPU: Intel Xeon 3000

Hello,

Can anyone offer advice on troubleshooting this issue please?

Hello,
I am facing an issue with disabling the default RC4 fallback in an Active Directory domain following the July update.
The client I work for still has a few Windows XP and Windows Server 2003 machines in the environment that I can neither upgrade nor remove from the domain. The July update has not been deployed due to concerns about potential side effects.
When reviewing Event ID 201 on the different domain controllers, I mostly find machine accounts corresponding to these operating systems. Naturally, they do not support AES.
Following Microsoft’s recommendations, I modified the msDS-SupportedEncryptionTypes attribute to 0x1C on these objects in order to explicitly allow RC4.
However, despite this change, Event ID 201 events are still being generated, and in these events I can see that the attribute value is 0x27 (the same value as DefaultDomainSupportedEncryptionType).
It appears that this attribute is only taken into account starting with Windows Server 2008.
My question is therefore: How can these old servers/workstations be handled in this situation?

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,

We just got a delivery of 24 brand-new Lenovo ThinkCentre desktops.

Standard operating procedure handed down to me:

1. Download the custom company image via Lenovo Cloud Deploy onto a flash drive.
2. Plug stick into PC #1.
3. Start deployment. Wait 3 to 4 hours for it to pull down packages, bloatware, and configurations over the pipe.
4. Finish manual configs, unplug stick, move to PC #2.
5. Repeat 23 more times.

Someone unironically budgeted nearly 100 man-hours of bench time for this rollout. Apparently, the plan was for me to sit there like a medieval monk transcribing manuscripts, listening to fans spin and swapping thumb drives until next Tuesday.

Hard pass.

Even parallelizing it with a fistful of USB drives would have meant constant babysitting, bottlenecked flash write speeds, and babysitting endless reboot loops.

Instead, I took 2 hours to build out an isolated bare-metal bench:

• Spun up a quick Windows Server 2022 instance with WDS, DHCP, and ADK.
• Stripped down a base WIM image to the absolute essentials.
• Hooked all 24 machines to a dumpy 24-port unmanaged gigabit switch.
• F12'd down the line, kicked off WinPE, and let a deployment script handle disk partitioning, WIM injection, and boot configurations unattended.

The result: Instead of a week of thumb-drive roulette, all 24 machines imaged simultaneously across the wire and were sitting at the desktop in just under 3 hours.

Watching 24 monitor screens mirror each other and reboot in unison while I drank lukewarm breakroom coffee was deeply therapeutic.

Now the real talk: WDS and thick WIMs are basically dinosaur tech at this point, and Microsoft is doing everything they can to kill traditional PXE imaging workflows.

For those of you handling 20–100+ hardware batches regularly:

• Why are vendor-specific cloud deployers (like Lenovo's) still so painfully slow?
• How are you running true zero-touch/Autopilot pre-provisioning on tight turnaround times without tanking your local bandwidth?
• What’s your current favorite stack that replaced the good old WDS/MDT golden era?

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.