Get-ClusterExcludedAdapter cmdlet
Following link https://learn.microsoft.com/en-us/powershell/module/failoverclusters/get-clusterexcludedadapter?view=windowsserver2025-ps when execute Get-ClusterExcludedAdapter cmdlet with error below Get-ClusterExcludedAdapter : The term 'Get-ClusterExcludedAdapter' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + Get-ClusterExcludedAdapter + ~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (Get-ClusterExcludedAdapter:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException same for cmdlet Add-ClusterExcludedAdapter (https://learn.microsoft.com/en-us/powershell/module/failoverclusters/add-clusterexcludedadapter?view=windowsserver2025-ps) Does anyone know why these commands are not available?
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...
Get-PartitionSupportedSize hangs forever when Azure File Sync is installed
This is occurring on several servers and all volumes that file sync setup Command: Get-PartitionSupportedSize -DiskNumber 5 -PartitionNumber 2 Server info: Windows 2019 VMware RDM disk setup to 3PAR storage. If I stop with above all works perfectly and has for years and previous windows versions I install Azure File Sync and the command hangs and will never return to a prompt. No error no output. This has to be some sort of bug right? Cannot find any info about this. We have several automated disk extension runbooks that need this resolved Any suggestions?Windows Server OSConfig and DSCv3
Introduction I wanted to formalize putting a post out here to get some discussion going on the attempts at modernization of Windows configuration, and importantly, infrastructure-as-code. Hopefully this is a healthy discussion that others can engage in. Much of what I'm going to try and post about is stuff we already are aware of, but I want to highlight how this is an ongoing concern with the Windows Server platform that makes it difficult to encourage people to even consider Windows in their environment other than for extremely legacy purposes. I want Windows Server to be the best it can be, and I encourage others to join in on the conversation! Problem Statement Windows Server needs a modernized configuration-as-code system. Must be capable of orchestrating without cloud tools (offline orchestration) Must provide for regular validation and attestation Ideally should be easily available to 3rd party configuration tools. Since Microsoft appears to have little interest in building their own modernized system that isn't Azure-based, this means that this MUST be orchestrated easily and securely by 3rd party tools. Should be as robust as GPO at maintaining and enforcing state. Security configurations in Windows are a right pain to manage with any 3rd party tooling, with the closest coming to it being the SecurityDSC module which wraps secedit.exe and security policy INFs. Why is OSConfig not the answer? OSConfig doesn't provide for me, as an engineer, to clearly define what the state of my machines are based on my company's business requirements. While the built-in Microsoft policy recommendations are great, there are reasons to deviate from these policies in a predictable and idempotent manner. Applying an OSConfig Baseline -> Then changing settings as-needed with special PowerShell commands This is not the answer. This is a bunch of imperative code that serves nobody. And it makes implementing this feature extremely challenging in today's modern world of Kubernetes, Docker, etc. I encourage the Windows Server team to engage with the PowerShell team on DSC 3.0. I think that team has it right, but they are a small group of people and do not have the resources to implement everything that would make DSC 3.0 a first-class configuration as code platform on Windows. And this is where the Windows team should come in. Steve Lee and crew have done a bangup job working on DSC 3.0, including taking feedback from folks to leverage Azure Bicep language for configuration. Security Policy Challenge The way to access security policies need to change. Even if I were to take DSC 3.0 I'd end up having to create a similar security policy INF file to import into Windows. It just seems so silly to me to have to write all of that out when Windows really should just provide an interface for doing this. In fact, security policy remains to be one of the largest problems to getting a good platform stood up. Windows Firewall Policy and GPO - The reason why host-based firewalling is painful to manage at scale in a Windows environment. GPO is definitely not the right place to be managing Windows firewall policy at scale. Particularly when you often have a core set of management rules you want to implement and application-specific needs. Making robust changes becomes a challenge since each policy is separate, preventing you from doing things like inheriting rules for higher level policies. While this is an inherent limitation of Group Policy, it highlights the need to get off of GPO as the core policy configuration tool for Windows. My recommendations I'd like for the Windows team to implement DSC 3.0-compatible resources for managing all core functionality of Windows. If you can do it in a GPO, you should be able to do it with Configuration as Code. Please stop relying on the community to make this work. All of this should be first party to the platform itself. Furthermore, I'd like to recommend that Microsoft either work with 3rd party configuration systems (Chef, Ansible, Puppet, Octopus, etc.) OR to also provide a way to hit the ground running. Perhaps something that integrates visually into Windows Admin Center would be nice. Conclusion This is a huge problem in the Windows world and continues to seem to fall on some deaf ears somewhere in the organization. While I no doubt am confident that the engineers on all of these teams very well know these issues and maybe even have discussed fixing them, clearly there's a breakdown somewhere.PowerShell, Hyper-V: Examine network object relationships.
Is it possible in PowerShell do do things like: Get all VMNetworkAdapters connected to a given VMSwitch Get all VMNetworkAdapters provided by a hypervisor (conected to either a VM or the management OS) When I have the name of a VMNetworkAdapter only, determine whether it's connected to the management OS, or a VM, and if connected to a VM, what VM that is without examining each single endpoint (VM, management OS) and creating a database of objects and their relationships that allows me to get the desired information? Certainly not a couple of PowerShell code lines only, and depending on the size and type (remote, local) of the virtualization environment, I can imagine that time is a factor too.BLOG: Windows Server / Azure Local keeps setting Live Migration to 1 - here is why
Affected products: Windows Server 2022, Windows Server 2025 Azure Local 21H2, Azure Local 22H2, Azure Local 23H2 Network ATC Dear Community, I have seen numerous reports from customers running Windows Server 2022 servers or Azure Local (Azure Stack HCI) that Live Migration settings are constantly changed to 1 per Hyper-V Host, as mirrored in PowerShell and Hyper-V Host Settings. The customer previously set the value to 4 via PowerShell, so he could prove it was a different value at a certain time. First, I didn't step into intense research why the configuration altered over time, but the stumbled across it, quite accidently, when fetching all parameters of Get-Cluster. According to an article a LCU back in September 2022 changed the default behaviour and allows to specify the live migrations at cluster level. The new live migration default appears to be 1 at cluster level and this forces to change the values on the Hyper-V nodes to 1 accordingly. In contrast to the commandlet documentation, the value is not 2, which would make more sense. Quite unknown, as not documented in the LCU KB5017381 itself, but only referenced in the documentation for the PowerShell commandlet Get-Cluster. Frankly, none of the aren't areas customers nor partners would check quite regularly to spot any of such relevant feature improvements or changes. "Beginning with the 2022-09 Cumulative Update, you can now configure the number of parallel live migrations within a cluster. For more information, see KB5017381 for Windows Server 2022 and KB5017382 for Azure Stack HCI (Azure Local), version 21H2. (Get-Cluster).MaximumParallelMigrations = 2 The example above sets the cluster property MaximumParallelMigrations to a value of 2, limiting the number of live migrations that a cluster node can participate in. Both existing and new cluster nodes inherit this value of 2 because it's a cluster property. Setting the cluster property overrides any values configured using the Set-VMHost command." Network ATC in Azure Local 22H2+ and Windows Server 2025+: When using Network ATC in Windows Server 2025 and Azure Local, it will set the live migration to 1 per default and enforce this across all cluster nodes. Disregarding the Cluster Settings above or Local Hyper-V Settings. To change the number of live migration you can specify a cluster-wide override in Network ATC. Conclusion: The default values for live migration have been changes. The global cluster setting or Network ATC forcing these down to the Hyper-V hosts based on Windows Server 2022+/ Azure Local nodes and ensure consistency. Previously we thought this would happen after using Windows Admin Center (WAC) when opening the WAC cluster settings, but this was not the initial cause. Finding references: Later the day, as my interest grew about this change I found an official announcement. In agreement to another article, on optimizing live migrations, the default value should be 2, but for some reason at most customers, even on fresh installations and clusters, it is set to 1. TLDR: 1. Stop bothering on changing the Livemigration setting manually or PowerShell or DSC / Policy. 2. Today and in future train your muscle memory to change live migration at cluster level with Get-Cluster, or via Network ATC overrides. These will be forced down quite immediately to all nodes and will be automatically corrected if there is any configuration drift on a node. 3. Check and set the live migration value to 2 as per default and follow these recommendations: Optimizing Hyper-V Live Migrations on an Hyperconverged Infrastructure | Microsoft Community Hub Optimizing your Hyper-V hosts | Microsoft Community Hub 4. You can stop blaming WAC or overeager colleagues for changing the LM settings to undesirable values over and over. Starting with Windows Admin Center (WAC) 2306, you can set the Live Migration Settings at cluster level in Cluster > Settings. Happy Clustering! 😀feature Installation Error
I am facing this issue in Windows Server 2019 STD. i am also tried to solve this issue to select sources\sxs path from the OS media but still i am getting the same error. Mistakenly i have removed .Net framework from this server and after that i am facing this issue. please help me to solve this issue.
Unusual Behavior using GPO PowerShell Scripts During Restart/Shutdown in Hyper-V – Need Help
I have noticed strange behavior in Hyper-V. Group Policy is configured to execute PowerShell scripts for logon, logout, startup, and shutdown. The typical sequence of script execution is: startup → logon → logout → shutdown. However, an issue arises when a restart is initiated while logged in (i.e., after startup and logon scripts have already been executed). Upon clicking the restart button from the GUI, the following occurs: after the logout and shutdown scripts run as expected, the startup script is executed and the logon script (!) is triggered. This happens despite the fact that the lock screen is displayed after the restart, and no user has logged in yet. This phenomenon consistently occurs when restarting or shutting down from the GUI while logged in. It does not occur when restarting via the command line using shutdown /r /t 0 or shutting down with shutdown /s /t 0. Why does Hyper-V behave in this inexplicable manner, executing the logon script in such cases? Is it possible to configure something within the virtual machine to address this issue? Or are there specific Group Policies for script execution that could control this behavior? Could there be certain Registry entries that influence the shutdown or restart process to prevent this issue in Hyper-V? Alternatively, could the problem be resolved by modifying the startup or logon scripts, for instance, by adding conditions to verify if an actual login has occurred? Any ideas or suggestions to explain or resolve this behavior would be greatly appreciated.
