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?
winpty error accessing powershell tab
WAC Ver: 2.4.1 running on Windows Server 2022 I can access and perform all other WAC functions on the remote connected server (Win 2022) but when I try to access the powershell tab and click 'connect' I am met with a "Session End: click 'Connect' to reconnect." error. Clicking 'Connect' just cycles the same error. The windows event log error is as follows: Category: Microsoft.WindowsAdminCenter.Common.ServiceLog EventId: 414 SpanId: d138bcb891359bec TraceId: f373ad4711a131524c5c01e8b6a2e591 ParentId: bb6d22e32ab6da73 ConnectionId: 0HND3HPV5LDCV RequestId: 0HND3HPV5LDCV:00000001 RequestPath: /api/PseudoConsole/nodes/fakeservername.com/powershellconsole ActionId: b3f1dbd0-b87e-49e5-a13d-ba66e8d18af1 ActionName: Microsoft.WindowsAdminCenter.Controllers.PseudoConsole.PseudoConsoleController.PowerShellConsole (Microsoft.WindowsAdminCenter.Controllers.PseudoConsole) Failed to open winpty (8), Columns=194, Rows=44 The internal windows firewall is turned off completely, and outside of WAC, initiating a "Enter-PSSession -ComputerName" command in powershell verison 7.5.1 works fine, I can run commands on the remote server from there. Any ideas?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 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...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.
