Storage Migration Service - Cutover Fails/hangs During Rename and Reboot Source Server Step
Hi folks. We are using the Storage Migration Service to migrate several servers from 2K8 R2 to 2019 and running into some issues during the various parts of the Cutover phase. This particular post deals with the Rename and Reboot step of the Cutover phase which we last attempted April 29, 2019(still working with Support, but no solutions yet). Details below: 1) We have an active case open with Support, but I wanted to Post to the Community to see if we get lucky. 2) We were able to get to the "Start Cutover" phase and it began around 5:30 PM CST on our last try. 3) Following it's progress, the process got through the final copy(approximately 600GB of data) and rename of the source server showing it was 44% done around 7:30 PM CST. 4) The source server never completed a reboot, but it did change the name and NIC settings. 5) The last update we saw on the Admin Center page was "44% Adding the source computer to the domain..." 6) We left it at this message until 10:30 PM CST. At this time I went ahead and manually rebooted the source server, hoping it would continue the process. 7) It didn't and since I was running out of time in my Change Window, I renamed the original server back, reset the NIC settings, and restarted it to get it back up and available. 8) I also disconnected the NIC on the new server to make sure we had no conflicts while we continued to troubleshoot. As of today 6/20/19, the new server has been put back on the network, I've wiped out the target drive and re-created it, reset it's network info, set up a new Migration Job, and going to try another Cutover this weekend. Any tips, suggestions, or other ideas appreciated. Thanks, Don K
Profile Bloat in Azure VM and VMware VDI: A Policy-Driven Strategy for Reducing Storage Growth
OneDrive profile bloat is one of those issues that often starts as a minor desktop optimization discussion, but quickly becomes a storage, performance, and governance problem at enterprise scale. In Azure Virtual Machines and VMware VDI environments, when OneDrive is tied to the user profile, the sync cache, local file state, and stale content can accumulate over time and create unnecessary growth in profile containers, VHD/VHDX files, and backup overhead. The result is higher infrastructure cost, slower login and logoff times, and inconsistent user experience across pooled or multi-session desktops. This is not a problem that should be solved by disabling OneDrive. In most enterprise scenarios, OneDrive remains a critical collaboration workload, but it must be managed as a controlled service rather than a user-local convenience. The most effective strategy is to install OneDrive at the machine level, enforce policy by user class and device context, and use Files On-Demand and cloud content dehydration to minimize local persistence. This approach preserves user productivity while reducing the operational impact on virtualized desktop infrastructure. A policy-driven design is particularly important in multi-user environments where not all workloads should be treated the same. Developer desktops, standard business users, and restricted or consultant user groups have different productivity needs and different data-risk profiles. For example: General business users may benefit from a balanced policy with Files On-Demand enabled and moderate dehydration thresholds. Developer or QA environments may require more local flexibility while still controlling profile growth. Restricted or external-user populations should have strong sync boundaries, personal account restrictions, and minimal local persistence. To support this model, organizations should align their deployment around a few core principles: install OneDrive at the machine level in the standard image or build pipeline use group policy and loopback processing to apply user-specific policy based on OU or security group enable Files On-Demand by default configure Storage Sense and cloud content dehydration based on workload profile restrict personal Microsoft account sync in higher-risk scenarios use FSLogix compaction and profile optimization as secondary controls, not as the primary solution This model is especially relevant for organizations running Azure Virtual Desktop, Azure VM-based workloads, VMware Horizon, and other multi-user Windows desktop environments. The benefits are practical and measurable: lower local storage consumption, reduced VHD/VHDX growth, improved desktop performance, lower backup cost, and stronger governance over enterprise data movement. As IT and endpoint engineering teams continue modernizing virtual desktop environments, I would encourage us to think of OneDrive not as a user-profile feature, but as an enterprise-managed workload with policy boundaries. When implemented properly, this gives us the best balance between productivity, storage efficiency, and security. I’d be very interested in hearing how others are handling this in their environments: Are you deploying OneDrive at the machine level? Are you enforcing Files On-Demand by default? How are you segmenting policy by user class or device type? Have you measured the impact on VHD/VHDX growth or profile size after enforcement? Source document: https://github.com/RodrigoACriscuolo/criscra/blob/main/Home.Profile-Bloat
Settings Crashes After DC Promotion; Windows Update Unavailable (Server 2016/2022)
Objective Resolve the issue where the Windows Settings app crashes immediately upon opening, so that I can access Settings and install Windows updates normally. Environment and Problem Description We have two domain controllers in our Active Directory domain, named AD and DC. Both are running Windows Server 2016. - AD holds all five FSMO roles and runs as a Hyper-V virtual machine hosted on another server. - DC is a physical server. Both domain controllers have the same problem. Control Panel opens normally, but the Settings app does not. When I click Settings, a window briefly flashes on the screen without displaying any content (or only the gear icon appears), and then the window immediately closes. I cannot open Settings-related pages, including Windows Update. As a result, I cannot use the normal Windows Update interface to install updates. The issue also affects monthly updates downloaded manually from the Microsoft Update Catalog. When I run an update package, the following error appears: Windows Update Standalone Installer: Installer encountered an error: 0x80070005 Access is denied. I performed the following test in an isolated environment: 1. Restored a backup of AD and installed a fresh Windows Server 2022 machine named AD3. AD3 was not connected to any other hosts or networks during the test. 2. Before AD3 was promoted to a domain controller, the Settings app worked normally. 3. Immediately after promoting AD3 to a domain controller, Settings stopped opening and began closing immediately. 4. I then transferred all five FSMO roles to AD3 and demoted AD, so that AD was no longer a domain controller. 5. Surprisingly, the Settings app on AD started working again after AD was demoted. This behavior strongly suggests that the problem is related to the domain controller role or something that changes when a server is promoted to a domain controller. However, I have not identified the underlying cause. Is there a recommended diagnostic procedure or a known issue that could explain this behavior? I would appreciate any technical guidance on how to identify the root cause and resolve the problem without having to demote the domain controllers. Thank you.
Windows server 2022 is not updating with latest patch KB5126655
Windows server 2022 is not updating with latest patch KB5126655. However, successfully installed 2026-10 Cumulative update for .Net framework. Last successful Cumulative update for the operating system version 21H2 is 2026-06. Try to update the latest patch manually, the server is rolling back the patch.KB5122882 and Intel SATA RAID boot problem
There is a bigger issue on Supermicro motherboards when Intel SATA RAID is configured: the system fails to boot after an update. I have verified this on three different boards; X9SCL-F, X11SCW-F, X11SSL-F, after a second restart : A disk read error occurred The array is functioning correctly; I can see it when running the system from an ISO, and I have tested all possible boot repair options.
Windows Server 2025 – DHCP Failover con dos controladores de dominio: el ámbito no se sincroniza
Hola buenas a todos. Recientemente he configurado una implementación de DHCP Failover entre dos controladores de dominio con Windows Server 2025 (DC1 y DC2), utilizando el modo Hot Standby. La configuración del ámbito se replica correctamente después de la configuración inicial, pero después de realizar cualquier cambio manual en las opciones del ámbito (por ejemplo, modificar la puerta de enlace predeterminada o añadir una nueva reserva), los cambios no se sincronizan automáticamente con el servidor asociado. Cada vez tengo que ejecutar manualmente «Replicar ámbito». Ambos servidores están en la misma subred y pueden comunicarse sin problemas. ¿Se trata de un problema conocido de DHCP Failover en Windows Server 2025, o hay alguna configuración específica que pueda estar pasando por alto para habilitar la replicación automática de los cambios realizados en el ámbito? Gracias.
Kerberos Event ID 4771 (0x18) across multiple users while interactive logons succeed
Users are able to perform interactive/manual logons successfully with their current credentials. The failures are also generated outside normal working hours. The Client Address in the 4771 events corresponds to the workstation/IP of the respective user. We have observed many different Client Addresses (at least 15 different source IPs), so the failures are not originating from a single host. As an initial troubleshooting step, we executed: klist purge for one affected user. The Kerberos ticket cache was cleared successfully, but the Event ID 4771 failures continued afterward with no noticeable change. Previous guidance suggested checking for stale/stored credentials, scheduled tasks, Windows services, Credential Manager entries, mapped resources, proxy authentication, or background applications that might be attempting authentication with outdated credentials. Another recommendation was to use Sysmon on an affected workstation and correlate outbound Kerberos traffic on port 88 with the timestamp of the 4771 event in order to identify the process or executable generating the request. Before making changes or deploying additional monitoring software in the client's environment, we would like to determine the safest and most appropriate troubleshooting approach. Given that: interactive logons work normally; 0x18 failures occur for many users; each user's Client Address generally corresponds to their own workstation; the issue occurs across many different workstations; and clearing the Kerberos ticket cache did not change the behavior, what would be the recommended Microsoft troubleshooting method to identify the exact process, service, application, or stored credential generating these failed Kerberos pre-authentication requests? Thank you.Windows Server 2025 DC with two network adapters registers the NAT IP in DNS
Hi everyone, I'm a student of IT systems administration and I'm practicing with a Windows Server 2025 domain controller in a virtual machine on my laptop. The DC has two network adapters, one in NAT mode to have internet and another one in an internal network 192.168.10.0/24 where I have a Windows 11 client joined to the domain.
Hyper-V Ubuntu VM: Memory Demand Different at Hyper-V and OS Level
Hello all, Looking for advice and insight for a strange problem we are experiencing. We have a cluster of Windows Server 2025 hosts, on which we are using Hyper-V manager to run mostly Windows VMs. To access these VMs, we are using Apache Guacamole which is hosted on a Ubuntu VM on our cluster. We originally assigned 32GB memory to this VM. Recently, we have noticed an increased memory demand for this VM at the Hyper-V level which prompted us to increase the assigned memory of the VM to 64GB. Despite this, the memory demand has continued rising despite no apparent change in the usage of Guacamole. When logging into the VM and observing the memory usage here, the VM is using no where near the amount that is assigned. As shown in the attached images which were taken at the same time: Memory Demand Hyper-V Level (And seems to be continuing to increase...): Memory Demand OS Level: This morning, the memory demand spiked to 95GB on Hyper-V but at OS level was only 12GB and we were forced to restart the VM. The biggest concern is where this discrepancy is coming from and the potential unnecessary disruptions that will be caused from having to restart/rebuild the VM. Has anyone experienced this sort of issue before and found a fix? Can anyone suggest how to debug this issue? TIA
