Encrypted vhdx moved to new host, boots without pin or recovery key
Hyper-V environment. Enabled VTPM on guest Server, 2022 OS and encrypted OS drive C:\ with BitLocker. Host server 2022 has physical TPM. Shut down guest OS and copied vhdx file to another Hyper-V host server that is completely off network (also server 2022 with a physical TPM). Created a new VM based on the "encrypted" vhdx. I was able to start the VM without needing a PIN or a recovery key. Doesn't this defeat the whole point of encrypting vhd's? Searching says that this should not be possible, but I replicated it twice on two different off network Hyper-V host servers. Another odd thing is that when the guest boots on the new host and you log in, the drive is NOT encrypted. So, where's the security in that? Does anyone have any ideas on this or if I'm missing something completely? Or have I just made Microsoft angry for pointing out this glaring flaw??
Issues with Group Policy Update (gpupdate)
I am getting an error when I attempt to perform a gpupdate /force on workstations. I have checked the health of the DC's and find no issues. I am going to include a screenshot of the error - hoping someone can guide me as on how to resolve. The system will say to reboot but the policy never seems to run just keeps prompting for reboot.
Did Microsoft make a mistake? WinServer 2022 Standard and up.
Microsoft removed functionality of Windows Deployment Service. I know their are ways to to get around this but they either are hackjobs or deploying your own windows with PE. as far as i know of writing this. I know I could go linux. they have a simple cd to follow. Or Mac has their own version for macs. but not microsoft. They THREW it away for some stupid reason. Do I really have to do a VM or worse ditch DNS & DHCP?
Access denied. 0x80090010 Enroll cert of Windows hello for Business with on-prem PKI CA Server
We have created Certficate Template from on-prem CA Server ( Windows server 2019 ) using this link : https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/rdp-sign-in?tabs=intune However We can not Enroll Certificate Windows Hello for Business Certificate from User's Desktop ( Windows 11 ) and every time error occurred or Access Denied ( Certificate enrollment for Domain\UserName failed to enroll for a WHfBCertificateAuthentication certificate with request ID N/A from -ERCA.Domain.local\Domain-ERCA-CA-1 (Access denied. 0x80090010 (-2146893808 NTE_PERM)) We have also given Read and Enroll permission to EveryOne and Autheticated Users from CA Certficiate template , but still same erro Please advise if anything more can be done to resolve this issue.Windows Activation Error 0x80072F8F
Hi, I'm getting the below error code 0x80072F8F when trying to activate the windows (Windows server 2008 R2). Though i tried the following methods to resolve the issue unfortunately issue remains the same Method 1: I checked the date, time, year in BIOS and on windows as well and they were accurate. I also set the date or year back and restarted the system (set date one year back, reboot, set actual date, reboot, activate) but no luck Method 2: Changed the media boot install registry key from 1 to 0 Kindly let me know if there is any workaround to activate windows other than the above mentioned methods. Thanks in advanceServer 2025 not accepting Ricoh scans
The scanner has stopped scanning to their server since I upgraded the server OS from Windows Server 2022 to 2025. • Installed the Ricoh drivers for both the scanner and printer (from Ricoh’s web site) • Created a new simple share/filepath for the scanner to send to (\\SERVER2022\Scans) • Used IP address (10.1.10.2) instead of server name in file (UNC) path • Entered admin credentials with or without server name (it is a workgroup server, not a DC) • Created another user and tried all above with that new admin • With either server share and/or user, tried different permissions on the shared folder • Tried disabling/enabling inherited permissions on the shared folder • Disabled the Advanced Firewall entirely for testing – no change either way • Double checked incoming ports/programs on the firewall – all required were open • Activated SMB1 on server, tried with or without SMB2/SMB3 disabled • I was able to create a share on two other computers; one running Windows 10 and one running Windows 11. They both worked.
Windows Server 2025 24H4 is not useable anymore after Nov. Update KB5068861
Hello, currently, on several Windows Server 2025 Datacenter systems, version 24H2, I am experiencing severe issues accessing network resources after the automatic installation of update KB5068861. This affects network access from Windows Server 2025 24H2 to Windows Server 2025 24H2. Access from these servers to older Windows Server 2016 systems works without any problems. When entering a UNC path—whether by name or by IP—I am always prompted for my credentials, even as a domain administrator. No matter which credentials I enter, I always receive the message that the username or password is incorrect. Under “Change advanced sharing settings,” the two switches “Network discovery” and “File and printer sharing” are set to OFF in the domain network after the update. Re-enabling these two options, which are normally enabled by default, does not improve the situation. Since this patch, I also have an issue on a Windows Server 2025 RDS host where a logged-in user cannot type in the “Search” field. Additionally, the performance on the RDS host feels extremely sluggish. Unfortunately, uninstalling the patch is not possible. The patch KB5067036 is not installed. I have already performed a restore to the day before KB5068861 was installed, but without the desired improvement in performance. Even after the restore, I still cannot access the network via UNC through File Explorer as a user. In the search window, I can access via UNC path. As an administrator, access via UNC path works both in File Explorer and in the “Search” field. Everything worked fine before 11/11/2025. Has anyone had similar experiences or already found a solution? Is a patch for the patch planned? Currently, troubleshooting feels like groping in the dark! In this state, the 24H2 server is no longer usable. What was Microsoft even thinking, releasing such faulty patches—and for weeks now? Is there still any quality control at Microsoft for such critical updates and patches? Thanks for every support, idea, and comment.Cache drive reconfiguration in Server 2025 Storage Spaces Direct cluster
We have a three node S2D cluster running Server 2025, with the storage in a 3 way mirror, running Hyper-V VMs. Each node has 4 x NVMe drives that are currently being used as cache drives, but which are connected to a RAID controller (in HBA mode), so in the S2D configuration they appear as SSD drives rather than NVMe drives. We've purchased the required cables and drive bays to be able to reconfigure the NVMe drives so that they're attached directly to the PCIe bus, so they'll show up as NVMe drives and hopefully give us a performance boost, so I'm just trying to plan the reconfiguration. I was hoping it would be a relatively simple process of shutting everything down, reconfiguring the storage and bringing everything back online, but ChatGPT suggests things won't be that easy and that a complete reconfiguration of the storage would be required. So in a nutshell, can the cache drives be reconfigured without a complete rebuild of the S2D storage ? Cheers, Rob
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?
