PowerShell counterpart for Failover Cluster Manager "Live Migration Settings"
In Failover Cluster Manager, there's "Live Migration Settings" where I can define what cluster networks I want to carry live migration traffic. Even after some research, I cannot find a PowerShell cmdlet that lets me do the same...Announcing Windows Server vNext Preview Build 29595
Hello Windows Server Insiders! Today we are pleased to release a new build of the next Windows Server Long-Term Servicing Channel (LTSC) Preview that contains both the Desktop Experience and Server Core installation options for Datacenter and Standard editions and Azure Edition (for VM evaluation only). Branding remains Windows Server 2025 in this preview - when reporting issues please refer to Windows Server vNext preview. Build 29531 established a new Server preview baseline build. Please perform a clean install of Build 29531 (or later) using the installation media linked below. Please note: Upgrades from Windows Server vNext preview builds older than 29531 are not supported. We encourage all Windows Server vNext preview users to perform a clean install using 29531 or later to successfully upgrade to future Windows Server vNext preview builds. While upgrades from earlier Windows Server previews (Build 26525 and older) are not technically blocked by setup.exe, a number of known issues have been identified related to upgrades necessitating the establishment of a new baseline build for our Server vNext Preview Program. The new baseline build (29531) will not be Flighted due to upgrade issues. Flighting support resumed with preview build 29550 or later. What's New Quick Machine Recovery available in Windows Server vNext Insider Previews. Quick machine recovery (QMR) is now available for Server vNext Insiders to test. This feature enables the recovery of Windows Server devices when they encounter boot critical errors that prevent them from booting. QMR can automatically search for cloud‑based remediations to recover from widespread boot failures significantly reducing the burden on IT administrators when multiple devices are impacted. This supports the goals of the Windows Resiliency Initiative by enabling applicable fixes to be delivered through trusted Windows Update to restore affected devices, helping reduce downtime and minimize manual recovery efforts across enterprise environments. This feature is currently enabled in the latest Server vNext Insider builds for customers to experience test mode. A Group Policy option to enable or disable the feature will be introduced in upcoming builds to provide additional administrative control. To simulate the quick machine recovery experience, use the following commands from an elevated command prompt: 1. Enable test mode: reagentc.exe /SetRecoveryTestmode 2. Configure Windows to boot to Windows Recovery Environment on the next boot: reagentc.exe /BootToRe 3. Reboot your device. The system goes through autoremediation of a simulated crash safely and reboots back to Windows Server. For more information, please review Quick machine recovery (QMR) and Windows Resiliency Initiative. When providing feedback using Feedback hub, please select QMR from the Recovery and Uninstall category in the app. NVMe-over-Fabrics (NVMe-oF) extends the NVMe protocol—originally designed for local PCIe-attached SSDs—across a network fabric. Instead of using legacy SCSI-based protocols such as iSCSI or Fibre Channel, NVMe-oF allows a host to communicate directly with remote NVMe controllers using the same NVMe command set used for local devices. In this Insider build, Windows Server supports: NVMe-oF over TCP (NVMe/TCP), allowing NVMe-oF to run over standard Ethernet networks without specialized hardware. NVMe-oF over RDMA (NVMe/RDMA), enabling low-latency, high-throughput NVMe access over RDMA-capable networks (for example, RoCE or iWARP) using supported RDMA NICs. For more information, please visit: Introducing the Windows NVMe-oF Initiator Preview in Windows Server Insiders Builds | Microsoft Community Hub ReFS Boot is enabled for Windows Server vNext preview builds. Known Limitations ReFS Boot systems create a minimum 2GB WinRE partition. When WinRE cannot be updated due to space constraints, the system may disable WinRE. Disabling WinRE does not remove the partition. If the WinRE partition is deleted and the boot volume is extended over it, this operation is unrecoverable without a clean install. For more information, please visit: Resilient File System (ReFS) overview | Microsoft Learn Feedback Hub app is available for Server Desktop users! The app should automatically update with the latest version, but if it does not, simply Check for updates in the app’s settings tab. Known Issues Server Core Upgrades and AppCompat FOD: Enabling AppCompat FOD after reinstall may fail due to legacy 3rd-party license compatibility issues on Server Core devices. Server Core users may be unable to install the latest AppCompat FOD after upgrading to build 29574. This appears to be limited to Server Core installations with 3rd-party application licenses that fail compatibility checks after upgrade. This will be addressed in a future build. Upgrading from older builds of Windows Server vNext previews (26525 or older) are not supported. Please perform a clean install of build 29531 or later. Users may experience failures when attempting to upgrade from earlier previews (build 26525 and older). VMs may fail to upgrade or start after upgrade from older preview builds impacting live migration and failover cluster scenarios. Download Windows Server Insider Preview (microsoft.com) Flighting: The label for this flight may incorrectly reference Windows 11. However, when selected, the package installed is the Windows Server vNext update. Please ignore the label and proceed with installing your flight. This issue will be addressed in a future release. Available Downloads Downloads to certain countries may not be available. See Microsoft suspends new sales in Russia - Microsoft On the Issues. Windows Server Long-Term Servicing Channel Preview in ISO format in 18 languages, and in VHDX format in English only. Windows Server Datacenter Azure Edition Preview in ISO and VHDX format, English only. Microsoft Server Languages and Optional Features Preview Keys: Keys are valid for preview builds only Server Standard: MFY9F-XBN2F-TYFMP-CCV49-RMYVH Datacenter: 2KNJJ-33Y9H-2GXGX-KMQWH-G6H67 Azure Edition does not accept a key. Symbols: Available on the public symbol server – see Using the Microsoft Symbol Server. Expiration: This Windows Server Preview will expire September 15, 2026. How to Download Registered Insiders may navigate directly to the Windows Server Insider Preview download page. If you have not yet registered as an Insider, see GETTING STARTED WITH SERVER on the Windows Insiders for Business portal. We value your feedback! The most important part of the release cycle is to hear what's working and what needs to be improved, so your feedback is extremely valued. Please use the new Feedback Hub app for Windows Server if you are running a Desktop version of Server. If you are using a Core edition, or if you are unable to use the Feedback Hub app, you can use your registered Windows 10 or Windows 11 Insider device and use the Feedback Hub application. In the app, choose the Windows Server category and then the appropriate subcategory for your feedback. In the title of the Feedback, please indicate the build number you are providing feedback on as shown below to ensure that your issue is attributed to the right version: [Server #####] Title of my feedback See Give Feedback on Windows Server via Feedback Hub for specifics. The Windows Server Insiders space on the Microsoft Tech Communities supports preview builds of the next version of Windows Server. Use the forum to collaborate, share and learn from experts. For versions that have been released to general availability in market, try the Windows Server for IT Pro forum or contact Support for Business. Diagnostic and Usage Information Microsoft collects this information over the internet to help keep Windows secure and up to date, troubleshoot problems, and make product improvements. Microsoft server operating systems can be configured to turn diagnostic data off, send Required diagnostic data, or send Optional diagnostic data. During previews, Microsoft asks that you change the default setting to Optional to provide the best automatic feedback and help us improve the final product. Administrators can change the level of information collection through Settings. For details, see http://aka.ms/winserverdata. Also see the Microsoft Privacy Statement. Terms of Use This is pre-release software - it is provided for use "as-is" and is not supported in production environments. Users are responsible for installing any updates that may be made available from Windows Update. All pre-release software made available to you via the Windows Server Insider program is governed by the Insider Terms of Use.BLOG: Determine and modernize Filesystem Deduplication
Version history - 1.6 Added references / links - 1.5 Added insights from Steven Ekren. Many thanks! / Added ReFS Docs link and added clarification about drawbacks. - 1.4 revised script so ReFS volumes with classic dedup will be identified, added more eligibly checks and error handling - 1.3 added point #4 in migration guidance - 1.2 revised script - 1.1 formatting This blog explains the two Windows deduplication modes classic Windows Data Deduplication (ReFS or NTFS) and ReFS Deduplication (ReFS). It covers how they differ, why you should consider upgrading to Windows Server 2025 to leverage the new ReFS dedup engine, and clear warnings about scenarios where ReFS is not recommended. Practical migration guidance and detection commands are included. Differences between classic dedup and ReFS dedup File system: Classic dedup runs on NTFS or ReFS; ReFS dedup runs on ReFS and Windows Server 2025 or later, only. Implementation: They are separate engines with different metadata formats and management cmdlets. Management: Classic dedup uses the Dedup PowerShell module (Get‑DedupVolume, Start‑DedupJob, Disable‑DedupVolume). ReFS dedup uses its own ReFS dedup cmdlets (Get‑ReFSDedupStatus, Enable‑ReFSDedup). Conversion: There is no in‑place conversion between the two; metadata and chunk formats are incompatible. Improvements: the new in-line ReFS Deduplication leverages the advantages of ReFS files system. This makes deduplication more efficient and less CPU intensive. The new ReFS Deduplication can also compress data in-line using L1Z algorithm. This makes it up to par with enterprise solutions, often found in SAN storage or Linux appliances. Compression needs to be set per volume, and optional. Edit: Steven Ekren, a former Senior Product Manager for Hyper-V shared valuable insights on how both engines operate in a comment on LinkedIn: [...] the basic conceptual difference between WS Deduplication and ReFS deduplication is that the Windows Server [dedup] version takes the duplicate file data and moves it to a repository and puts a reparse point in the file system from each point that references the data. This involves data movement and therefore not recommended for workloads that are changing it's data often, but best for more static data like documents and picture/videos. ReFS is a file system that uses links natively for all the objects so leaving the data in place and managing the links is much more efficient and doesn't involve the data copy and managing a repository. Effectively it's built into the file system. As the blog notes, there are some situations not recommended for this version of dedupe, but generally it's lower performance and storage I/O impact. Why upgrade to Windows Server 2025 Improved version of ReFS Filesystem Improved ReFS in-line deduplication + optional L1Z compression: Server 2025 includes enhancements to ReFS dedup performance, scalability, and integration with modern storage features. Support and fixes: Windows Server 2016 and 2019 are past mainstream support, increasing the likelihood of costly support cases and delayed fixes; upgrading reduces operational risk and ensures access to ongoing improvements. Future compatibility: Newer OS releases receive optimizations and bug fixes for ReFS and dedup scenarios that older releases will not. SMB compression: for reasonably faster data transfer at minimal CPU when transferring data through the networks. Feature and security related improvements refer to availabile Microsoft Windows Server 2025 Summit content on techcommunity.microsoft.com Scenarios where ReFS is not recommended ReFS on SAN in clustered CSV environments: Avoid placing ReFS dedup on top of SAN‑backed Cluster Shared Volumes (CSVFS) in production clusters; clustered SAN/CSV scenarios causing severe performance issues in practice. Please refer to the ReFS documentation. (personal opinion and experience, not endorsed by Microsoft): Many small, fast‑changing files: Workloads with frequent small writes, such as user profiles, folder redirection of AppData folders, or applications that churn small config files (for example, Lotus Notes config files) can cause locks, performance degradation, or unexpected behavior on ReFS. Exclude these disks from dedup or keep them on NTFS. Note: Restrictions on high churn rate, like lockups or high RAM consumption, deadlocks / BSOD might have been addressed in Windows Server 2025 and the ReFS Dedup, see comment of Steven Ekren. Improving reliability and performance is a top goal for ReFS, to improve the adoption and feature parity with NTFS. For information about feature parity please refer to the ReFS documentation. Migration guidance The following instructions describe a high level and supported migration path from Windows deduplication using the NTFS file system to native ReFS Deduplication. Note: Step #3, data migration is not required when already using ReFS with Data Deduplication. In this case it's enough to execute step #1 and #2. Note: Validate on non‑production data first. Plan for rehydration time and network/storage throughput. Ensure backups are current before starting. Make sure to have a full backup before upgrading Server OS or making changes. 1. Disable classic dedup on the NTFS source: Disable-DedupVolume -Volume YourDriveLetter: 2. Rehydrate (un‑deduplicate) the data: Start-DedupJob -Volume YourDriveLetter: -Type Unoptimization 3. Copy or move data to a ReFS volume (new target): For straightforward NTFS→ReFS copies, robocopy is recommended. A GUI and job based alternative to this is the File Server Migration Feature (uses robocopy) in Windows Admin Center. For complex scenarios, open files long path names very large datasets (< 5 TB) or many small files restructuring, GUI (including Windows Server Core) automation, improved logging cloud/hybrid migrations I recommend the usage of GS RichCopy Enterprise by GuruSquad for higher speed (up to 40%) and reliability, compared to robocopy. 4. Optionally remove the Windows Server feature When there is no old deduplication in use consider to remove the feature. Your advantages of doing so: removes an unneccessary service. removes the file system filter driver for dedup, which causes performance impacts, even when not in use. removes the PowerShell commandlets for the old dedup, so they cannot mistakenly used by existing scripts, unaware admins etc. When migrating files over network: SMB compression: consider both source and target run Windows Server 2025 and leverage SMB compression. SMB Compression is available in Microsoft xcopy, Microsoft robocopy and Gurusquad GScopy Enterprise. Balancing and Teaming with SMB: SMB does not require LFBO or SET Teaming. It automagically detects network links and actively balances on its own on Windows Server 2016 and later. Using teaming, depending the configuration, can negatively affect transfer speed. Quick detection and diagnostic commands Check file systems: Get-Volume | Select DriveLetter, FileSystem Check classic dedup feature: Get-WindowsFeature -Name FS-Data-Deduplication Get-DedupVolume Get-DedupStatus Check ReFS dedup: Get-Command -Module Microsoft.ReFsDedup.Commands Get-ReFSDedupStatus -Volume YourDriveLetter: Diagnostic script to detect both: <# .SYNOPSIS Detects classic NTFS Data Deduplication and ReFS Deduplication across local volumes. .DESCRIPTION - Reports NTFS volumes with classic Data Dedup enabled. - Lists ReFS volumes present on the host. - If the ReFS dedup cmdlet exists AND OS build >= 26100, checks ReFS dedup status per ReFS volume. - Color coding: * Classic dedup enabled → Yellow * Classic dedup not enabled → Cyan * ReFS dedup enabled → Green * ReFS dedup not enabled → Cyan .NOTES Version: 1.7 Author: Karl Wester-Ebbinghaus + Copilot Requirements: Elevated PowerShell session, PowerShell 5.1 or newer Supported OS: Windows Server 2025, Azure Stack HCI 24H2 or newer Unsupported OS: Windows 10, Windows 11 (script terminates) #> #region Initialization Write-Verbose "Initializing variables and environment..." $Volumes = $null $Volume = $null $DedupVolumesList = $null $DedupReFSVolumesList = $null $DedupReFSVolumesListLetters = $null $DedupReFSStatus = $null $refsCmd = $null $OSBuild = $null $runReFSDedupChecks = $null #endregion Initialization #region Volume Discovery Clear-Host Write-Verbose "Querying NTFS and ReFS volumes..." $Volumes = Get-Volume | Where-Object FileSystem -in 'NTFS','ReFS' #endregion Volume Discovery #region ReFS Dedup Cmdlet, OS Build and OS SKU Detection Write-Verbose "Checking for ReFS deduplication cmdlet..." $refsCmd = Get-Command -Name Get-ReFSDedupStatus -ErrorAction SilentlyContinue Write-Verbose "Reading OS build number..." try { $OSBuild = [int](Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name CurrentBuildNumber).CurrentBuildNumber } catch { Write-Verbose "Registry read for OS build failed. Falling back to Environment OSVersion." $OSBuild = [int][Environment]::OSVersion.Version.Build } # end try/catch for OS build detection Write-Verbose "Checking OS InstallationType and EditionID..." $CurrentVersionKey = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' $InstallationType = $CurrentVersionKey.InstallationType # "Client" or "Server" $EditionID = $CurrentVersionKey.EditionID # e.g. "AzureStackHCI", "ServerStandard", etc. Write-Verbose "Detected InstallationType: $InstallationType" Write-Verbose "Detected EditionID: $EditionID" Write-Verbose "Detected OSBuild: $OSBuild" # Block Windows 10/11 (Client OS) if ($InstallationType -eq 'Client') { Write-Error "Unsupported OS detected: Windows Client (Windows 10/11). Only Windows Server or Azure Stack HCI are supported. Script will terminate." exit } # Allow Azure Stack HCI explicitly if ($EditionID -eq 'AzureStackHCI') { Write-Verbose "Azure Stack HCI detected. Supported platform." } else { # Must be Windows Server if ($InstallationType -ne 'Server') { Write-Error "Unsupported OS detected. Only Windows Server or Azure Stack HCI are supported. Script will terminate." exit } Write-Verbose "Windows Server detected (EditionID: $EditionID). Supported platform." } Write-Verbose "Evaluating ReFS dedup eligibility based on cmdlet presence and build >= 26100..." $runReFSDedupChecks = $false if ($refsCmd -and ($OSBuild -ge 26100)) { $runReFSDedupChecks = $true Write-Verbose "ReFS dedup checks ENABLED (cmdlet present and OS build >= 26100)." } else { Write-Verbose "ReFS dedup checks DISABLED (cmdlet missing or OS build < 26100)." } #endregion ReFS Dedup Cmdlet, OS Build and OS SKU Detection #region Main Loop foreach ($Volume in $Volumes) { # begin foreach volume loop Write-Host "Volume $($Volume.DriveLetter): ($($Volume.FileSystem))" Write-Verbose "Processing volume $($Volume.DriveLetter)..." #region Classic Dedup + ReFS Volume Listing if ($Volume.FileSystem -eq 'NTFS' -or $Volume.FileSystem -eq 'ReFS') { Write-Verbose "Checking classic deduplication status for volume $($Volume.DriveLetter)..." $DedupVolumesList = Get-DedupVolume -Volume $Volume.DriveLetter -ErrorAction SilentlyContinue if ($DedupVolumesList) { Write-Host " → Classic Data Dedup ENABLED on $($Volume.DriveLetter), $($Volume.FileSystem)" -ForegroundColor Yellow } else { Write-Host " → Classic Data Dedup NOT enabled on $($Volume.DriveLetter),$($Volume.FileSystem)" -ForegroundColor Cyan } # end if classic dedup enabled Write-Verbose "Listing ReFS volumes on host..." $DedupReFSVolumesList = Get-Volume | Where-Object FileSystem -eq 'ReFS' if ($DedupReFSVolumesList) { $DedupReFSVolumesListLetters = ($DedupReFSVolumesList | ForEach-Object { $_.DriveLetter }) -join ',' Write-Host " → ReFS volumes present on host: $DedupReFSVolumesListLetters" } else { Write-Host " → No ReFS volumes detected on host" } # end if ReFS volumes present } # end NTFS/ReFS block #endregion Classic Dedup + ReFS Volume Listing #region ReFS Dedup Status if ($Volume.FileSystem -eq 'ReFS') { if ($runReFSDedupChecks) { Write-Verbose "Checking ReFS deduplication status for volume $($Volume.DriveLetter)..." $DedupReFSStatus = Get-ReFSDedupStatus -Volume $Volume.DriveLetter -ErrorAction SilentlyContinue if ($DedupReFSStatus) { Write-Host " → ReFS Dedup ENABLED on $($Volume.DriveLetter), $($Volume.FileSystem)" -ForegroundColor Green } else { Write-Host " → ReFS Dedup NOT enabled on $($Volume.DriveLetter), $($Volume.FileSystem)" -ForegroundColor Cyan } # end if ReFS dedup enabled } else { if (-not $refsCmd) { Write-Error " → Skipping ReFS dedup check: Get-ReFSDedupStatus cmdlet not present" -ForegroundColor Cyan } else { Write-Error " → Skipping ReFS dedup check: OS build $OSBuild < required 26100" -ForegroundColor Cyan } # end reason for skipping ReFS dedup check } # end if runReFSDedupChecks } # end if ReFS filesystem block #endregion ReFS Dedup Status Write-Host "" } # end foreach volume loop #endregion Main Loop #region End Write-Verbose "Script completed." #endregion End Recommendations and next steps Inventory: Identify volumes using NTFS dedup and ReFS dedup, and map workloads that create many small or rapidly changing files. Plan: Schedule rehydration and migration windows; test ReFS dedup on representative datasets. Upgrade: Prioritize upgrading servers still on 2016/2019 (End of Mainstream Support) to reduce support risk and gain the latest ReFS dedup improvements. Kindly consider reading my Windows Server Installation Guidance and Windows Server Upgrade Guidance Exclude: Keep user profiles, AppData, and other high‑churn small‑file paths off ReFS dedup or on NTFS. Consider ReFS Dedup with Compression: Enable compression optionally. Mind ReFS dedup compression is not the same as compress files integration in File Explorer or File Explorer properties (Windows 9x). It's transparent to the application Make smart decisions: Avoid using dedup when the dataset is changing fast or your dedup + compression rate is below 20%. Usually you can expect 40% or more savings, and up to 80% in specific use cases like VDI VHDX with ReFS Dedup + Compression. Plan your dedup jobs: Ensure of making use of the planning features for dedup jobs through PowerShell or Windows Admin Center (WAC) when using ReFS dedup on more than one volume per Server. Otherwise they might all run at the same time and impact your storage performance (esp. spinning rust) and consumption of RAM and CPU. Share and Educate: Inform your infrastructure team about the changes so they avoid using the traditional dedup on ReFS. Related blogposts: https://splitbrain.com/windows-data-deduplication-vs-refs-deduplication/ , Thanks Darryl van der Peijl and team. https://www.veeam.com/kb2023 Veeam best practices about Windows Deduplication and ReFS Deduplication.Customer Offerings: Hyper-V - Implementation, Migration, and Management
Happy April everyone! Brandon here, back once again to talk to you about a couple of new offerings that have just been released to assist our Unified customers with their on-premises virtualization needs! I continue to have the privilege of leading a great program and team helping customers to migrate from VMware to more cost-effective and/or modern solutions. These new offerings are <drum roll>: Hyper-V - Implementation, Migration, and Management Azure Local - Implementation, Migration, and Management NOTE: These offerings do not provide hands on keyboard support, do not create custom documentation for customers, and cannot provide direct support for any 3 rd party products that may be used in the process of migrations. Many customers are taking a closer look at Microsoft Hyper‑V as a strategic alternative to traditional virtualization platforms. Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you. If you are a Unified customer and looking to move off of VMware to Hyper-V, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me! Planning to go at it alone?? I’m starting here for a very good reason… Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up for a VMware migration, will have configuration issues, many times warranting a complete redesign and re-deployment. Problem 1: There are some potentially significant differences between the way VMware and Hyper-V are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Hyper-V environment. Problem 2: To achieve feature parity, or near feature parity, your management method must also change. Additionally, if you are converting/migrating to Hyper-V, the available methods need to be determined, the terminology and functional differences identified and learned, well, honestly, I could go on for awhile on this, but I’ll spare you until we talk… Problem 3: Perhaps the most obvious is that this may be a new platform for your team, and its important for them to gain experience through guided actions and knowledge transfer on the fly for those questions they really have, which is exactly what we aim to provide in guiding implementations and migrations! You mentioned management and conversion tools, what do you mean?? Hyper‑V has several methods for management, which can vary based on the feature needs and environment size. As a simple example, if I have 1500 virtualization hosts and 30,000 virtual machines spread out globally, its probably not going to be as efficient to manage everything only through locally available consoles. The capabilities of these management methods are continuing to grow and improve based on customer feedback, along with feedback from the field team. Let’s take a quick look at these options: Native Windows tools: Hyper-V management console, Failover Clustering management console, Server Manager, etc This management method is typically used for small labs or smaller production environments (for migrations/conversions these methods do not provide feature parity with VMware). System Center Virtual Machine Manager (SCVMM) This management method is fully supported for environments of all sizes. For migrations/conversions this method provides feature parity with VMware for management and features, along with offering VMware migration/conversion capability (offline). If you are already using any product from the System Center suite (SCCM, SCOM, SCORCH, SCSM, or DPM) then this can prove to be a great no cost option for you! Windows Admin Center: Administration Mode (aMode) This management method is fully supported for environments of all sizes, however, is not designed as an infrastructure wide virtualization management method, but for server management and administration. If your environment isn’t extremely large, and VMware feature parity is not a necessity, this can provide a great no cost option for management of your physical and virtual servers. In addition, this method provides an online conversion option (currently public preview), allowing for a more seamless migration from VMware. Windows Admin Center: Virtualization Mode (vMode) (currently public preview) This management method is fully supported for environments of all sizes, and is designed solely for the purpose of managing the Hyper-V virtualization infrastructure, tying together the primary needs for virtualization fabric into an easy to navigate web-based UI. Azure You can Arc enable any Windows host or virtual machine and have a method of management and integration with cloud based services. In addition, these can work in conjunction with all of the above options to improve your management experience for your platform, and allows for the easy implementation and integration of many cloud based technologies (such as Hyper-V replica backups to ASR) NOTE: You can learn more about Windows Admin Center evolution here: Windows Admin Center Architectural Changes | Microsoft Community Hub A Structured Engagement Model Successful Hyper‑V implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about a migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help! Key Phases of a Hyper‑V Implementation and/or Migration Most Hyper‑V engagements progress through a common set of phases: Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers) Planning and design aligned to business and operational outcomes, with a limited scope Deployment and configuration validation to ensure platform readiness Security and migration testing to reduce risk and confirm workload compatibility Optional feature enablement, including Azure Arc, to extend governance and management While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives. Key Outcomes for Customers Organizations that engage in Hyper-V implementation or migration efforts commonly achieve: Deeper familiarity with Microsoft virtualization technologies Successful deployment of PoC, pilot, or production environments Validated test migrations of virtual machines Identification and resolution of technical blockers Increased confidence in operational readiness These engagements are advisory and collaborative in nature, prioritizing customer enablement and success. Knowledge Transfer and Operational Readiness A central focus of a Hyper‑V engagement is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well. Looking Beyond Migration A Hyper‑V migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Hyper‑V becomes a platform for long‑term innovation, not just a replacement hypervisor. Conclusion Moving from VMware to Hyper‑V is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth. Thanks for reading, and maybe we’ll talk soon!
Capabilities of NVMe-oF so far?
Started playing around with NVMe-oF last night and got a successful connection to TrueNAS. I'm wondering what the current capabilities/limitations are. As far as I can tell you can't cluster the disk which is what I was primarily interested in. I was able to connect the same NQN endpoint to two servers but the WSFC cluster wouldn't detect it as a cluster available disk. Also the disks seems to disappear on every reboot and has to be set up again, so is there no auto-mount yet? I understand this is early preview so I don't have many expectations, just would like some clarity. Thank you.Updated Failover Clustering API Documentation
Does anyone know when the Failover Cluster API documentation will be updated? Currently, in learn it only shows Server 2008 and 2012. https://learn.microsoft.com/en-us/previous-versions/windows/desktop/mscs/failover-cluster-apis-portal The same goes for storage spaces. Is there any updated documentation?
CSV Auto-Pause on Windows Server 2025 Hyper-V Cluster
Hi everyone, i'm facing a very strange behavior with a newly created HyperV Clsuter running on Windows Server 2025. One of the two nodes keep calling for autopause on the CSV during the I/O peak. Does anyone have experienced this ? Here are the details : Environment Cluster: 2-node Failover Cluster Nodes: HV1 & HV2 (HPE ProLiant DL360 Gen11) OS: Windows Server 2025 Datacenter, Build 26100.32370 (KB5075899 installed Feb 21, 2026) Storage: HPE MSA 2070 full SSD, iSCSI point-to-point (4×25 Gbps per node, 4 MPIO paths) CSV: Single volume "Clsuter Disk 2" (~14 TB, NTFS, CSVFS_NTFS) Quorum: Disk Witness (Node and Disk Majority) Networking: 4×10 Gbps NIC Teaming for management/cluster/VMs traffic, dedicated iSCSI NICs Problem Description The cluster experiences CSV auto-pause events daily during a peak I/O period (~10:00-11:30), caused by database VMs generating ~600-800 MB/s (not that much). The auto-pause is triggered by HV2's CsvFs driver, even though HV2 hosts no VMs. All VMs run on HV1, which is the CSV coordinator/owner. Comparative Testing (Feb 23-26, 2026) Date HV2 Status Event 5120 SMB Slowdowns (1054) Auto-pause Cycles VM Impact Feb 23 Active 1 44 1 cycle (237ms recovery) None Feb 24 Active 0 8 0 None Feb 25 Drained (still in cluster) 4 ~60 (86,400,000ms max!) 3 cascade cycles Severe - all VMs affected Feb 26 Powered off 0 0 0 None Key finding: Draining HV2 does NOT prevent the issue. Only fully powering off HV2 eliminates all auto-pause events and SMB slowdowns during the I/O peak. Root Cause Analysis 1. CsvFs Driver on HV2 Maintains Persistent SMB Sessions to CSV SMB Client Connectivity log (Event 30833) on HV2 shows ~130 new SMB connections per hour to the CSV share, continuously, constant since boot: Share: \\xxxx::xxx:xxx:xxx:xxx\xxxxxxxx-...-xxxxxxx$ (HV1 cluster virtual adapter) All connections from PID 4 (System/kernel) — CsvFs driver 5,649 connections in 43.6 hours = ~130/hour Each connection has a different Session ID (not persistent) This behavior continues even when HV2 is drained 2. HV2 Opens Handles on ALL VM Files During the I/O peak on Feb 25, SMB Server Operational log (Event 1054) on HV1 showed HV2 blocking on files from every VM directory, including powered-off VMs and templates: .vmgs, .VMRS, .vmcx, .xml — VM configuration and state files .rct, .mrt — RCT/CBT tracking files Affected VMs: almost all Also affected: powered-off VMs And templates: winsrv2025-template 3. Catastrophic Block Durations On Feb 25 (HV2 drained but still in cluster): Operations blocked for 86,400,000 ms (exactly 24 hours) — handles accumulated since previous day These all expired simultaneously at 10:13:52, triggering cascade auto-pause Post-autopause: big VM freeze/lag for additional 2,324 seconds (39 minutes) On Feb 24 (HV2 active): Operations blocked for 1,150,968 ms (19 minutes) on one of the VM files Despite this extreme duration, no auto-pause was triggered that day 4. Auto-pause Trigger Mechanism HV2 Diagnostic log at auto-pause time: CsvFs Listener: CsvFsVolumeStateChangeFromIO->CsvFsVolumeStateDraining, status 0xc0000001 OnVolumeEventFromCsvFs: reported VolumeEventAutopause to node 1 Error status 0xc0000001 (STATUS_UNSUCCESSFUL) on I/O operation from HV2 CsvFsVolumeStateChangeFromIO = I/O failure triggered the auto-pause HV2 has no VMs running — this is purely CsvFs metadata/redirected access 5. SMB Connection Loss During Auto-pause SMB Client Connectivity on HV2 at auto-pause time: Event 30807: Share connection lost - "Le nom réseau a été supprimé" Event 30808: Share connection re-established What Has Been Done KB5075899 installed (Feb 21) — Maybe improved recovery from multi-cycle loop to single cycle a little, but did not prevent the auto-pause Disabled ms_server binding on iSCSI NICs (both nodes) Tuned MPIO: PathVerification Enabled, PDORemovePeriod 120, RetryCount 6, DiskTimeout 100 Drained HV2 — no effect Powered off HV2 — Completely eliminated the problem I'm currently running mad with this problem, i've deployed a lot of HyperV clusters and it's the first time i'm experiencing such a strange behavior, the only workaround i found is to take the second nodes off to be sure he is not putting locks on CSV files. The cluster is only running well with one node turned on. Why does the CsvFs driver on a non-coordinator node (HV2) maintain ~130 new SMB connections per hour to the CSV, even when it hosts no VMs and is drained?Why do these connections block for up to 24 hours during I/O peaks on the coordinator node? Why does draining the node not prevent CsvFs from accessing the CSV? Is this a known issue with the CsvFs driver in Windows Server 2025 Build 26100.32370? Are there any registry parameters to limit or disable CsvFs metadata scanning on non-coordinator nodes ? If someone sees somthing that i am missing i would be so grateful ! Have a great day.
