Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / How Windows 11 Is Killing Enterprise PowerShell Scripts
Transcript
- Lucas: So we've talked a lot on this show about hardware changes Microsoft is forcing with Windows 11 — the TPM requirement, the CPU list, the shift to usb c. But there's a software change that's quietly causing chaos in enterprise IT departments right now, and it's not getting nearly the attention it deserves. Luna: Let me guess — PowerShell? Lucas: Bingo. Specifically, Windows 11 is steadily killing the version of PowerShell that most enterprises still rely on: Windows PowerShell 5.1. And the replacement, PowerShell 7, is different enough that thousands of scripts are breaking. Luna: I've seen this firsthand. A client of mine — mid-sized manufacturing firm, about 500 employees — they had a routine patch-management script that ran every Tuesday. After a Windows 11 feature update in April, it just stopped working. No error, no output, nothing. Lucas: Right, and that's the worst kind of failure — silent. What happened was the update changed the default execution policy for PowerShell 5.1. But more importantly, Windows 11 is now shipping with PowerShell 7 as the default console, and the old 5.1 engine is being moved to a feature-on-demand. It's still there, but Microsoft has made it clear: 5.1 is in maintenance mode. No new features, no bug fixes for most issues. Luna: So enterprises that haven't migrated are running scripts on borrowed time. And the gap between 5.1 and 7 is bigger than most IT teams realize. Lucas: Much bigger. Let me give you three concrete differences that break scripts. First: module auto-loading. In 5.1, if you referenced a cmdlet from an unloaded module, PowerShell would load it automatically. In PowerShell 7, that behavior is disabled by default. So a script that calls Get-ADUser with no explicit import-module command? It fails. Luna: That's a lot of scripts. I bet half the Active Directory scripts out there don't explicitly import the module. Lucas: Exactly. Second: the execution policy. In 5.1, the default execution policy on Windows 10 was Restricted — but many enterprise images set it to RemoteSigned via Group Policy. Windows 11, in some configurations, defaults to a more restrictive policy for PowerShell 7 than for 5.1. So scripts that ran fine on Windows 10 suddenly trigger 'UnauthorizedAccess' errors. Luna: And the third? Lucas: The deprecation of Windows PowerShell Workflow. That was a big deal for long-running automation tasks — parallel execution, checkpointing, the whole orchestration layer. PowerShell 7 doesn't have it. If you built workflows around that, you're rewriting from scratch. Luna: I remember the Workflow feature. It was never widely adopted, but the shops that did use it are in a tough spot. So what's the actual timeline here? When does Microsoft pull the plug on 5.1? Lucas: They haven't announced an end of life date, but the writing on the wall is clear: Windows Server 2025 ships with PowerShell 7 as the primary option. And on Windows 11, the latest Insider builds already don't include 5.1 in the default install. You have to add it manually via 'Optional Features'. I'd bet by late 2027, 5.1 is no longer a component you can add on new Windows 11 deployments. Luna: That's aggressive. A lot of enterprises are still running Server 2019 with 5.1 scripts that are critical to operations. They can't just flip a switch. Lucas: No, they can't. And that's the tension. Microsoft wants everyone on the latest, and they're willing to break things to force migration. But the enterprise reality is that a script that provisions new user accounts, or updates firewall rules, or runs inventory — if it breaks, someone's job gets harder that day. Luna: Let's talk about the manufacturing firm I mentioned. Their script was actually pretty standard — it checked for missing patches, installed them, and logged the results. Written in 2016, maybe 150 lines. The module auto-loading change was the culprit. They had to add Import-Module for the WindowsUpdate module. Took them a day to debug. Lucas: A day for a 150-line script. Now imagine a thousand-line script that uses custom modules, COM objects, and maybe calls into.NET assemblies. The migration effort is non-trivial. And there's another issue: PowerShell 7 is built on.NET Core 3.1, later.NET 6, now.NET 8. That means some.NET types that were available in the full.NET Framework from 5.1 are gone. Luna: Like what? Lucas: A common one is System.Windows.Forms. If you had a script that popped up a simple GUI dialog — say, an input box for a password — that won't work in PowerShell 7 without adding the assembly manually. And some COM objects, like Internet Explorer's COM control, are deprecated. Scripts that automate IE for web scraping? Dead. Luna: Which is probably fine, because IE is dead anyway. But the principle stands: Microsoft is forcing a modernization path that requires proactive effort. Lucas: Yes, and here's the thing — and I want to be honest about this — keeping this show going, keeping these deep dives coming every week, that takes effort too. We don't run ads, we don't have sponsors. A handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making episodes like this one. So if you find these breakdowns useful, that's where you can help directly. Luna: Yeah, and it's not a big ask — it's just a way for people who get value to keep the show ad-free. It works for us. Lucas: Exactly. So back to the PowerShell story — what should enterprises do right now? First: audit. Run a script that enumerates every.ps1 file on your network and tests it against PowerShell 7. Use the -Version parameter to check for incompatibilities. Microsoft actually has a tool called the PowerShell Script Compatibility Analyzer. It's not perfect, but it's a start. Luna: And for the scripts that fail, what's the typical fix? Lucas: Three things. One: add explicit Import-Module statements at the top of every script. Two: replace any use of the Workflow keyword with parallel loops or the new ForEach-Object -Parallel in PowerShell 7. Three: test your execution policy. Make sure the PowerShell 7 execution policy matches what you have for 5.1. You can set it via Group Policy now, but the policy paths are different. Luna: Different paths? That's a headache for centralized management. Lucas: It is. For PowerShell 5.1, the execution policy is under Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell. For PowerShell 7, it's under a new path: Computer Configuration > Policies > Administrative Templates > PowerShell Core. So if your GPO only targets the old path, PowerShell 7 ignores it. Luna: So an IT admin might think they've set a policy, but PowerShell 7 isn't seeing it. That's a security gap too — scripts could run with a less restrictive policy than intended. Lucas: Exactly. And that brings up another point: PowerShell 7 introduces new security features that 5.1 didn't have. For example, it supports Just Enough Administration out of the box with better logging. But if your scripts aren't updated, you can't take advantage of those improvements. Luna: So the migration isn't just about avoiding breakage — it's about security posture. Microsoft is essentially saying, 'You can't have the new security unless you move to the new runtime.' Lucas: That's the deal. And I think that's the right framing for enterprise decision-makers: don't think of this as a cost. Think of it as a prerequisite for the security improvements in Windows 11. Because the alternative — staying on 5.1 — means running a platform that Microsoft is no longer investing in. No security patches for the engine itself. Luna: But they said 5.1 is still supported on Windows 11 for now, right? Lucas: It is, but 'supported' means critical security fixes only. And even those will stop eventually. The PowerShell team has been clear: 'Windows PowerShell 5.1 is the last major version of Windows PowerShell.' No new features. No performance improvements. And as Windows 11 evolves, the compatibility surface will shrink. Luna: So what's the one thing you'd tell an IT manager to do this week? Lucas: Install PowerShell 7 on a test machine, run your top 10 most critical scripts, and see what breaks. Don't wait for a Windows update to force the issue. The April update that broke your friend's patch script — that's a preview of what's coming. By the time Microsoft makes 5.1 fully optional, you want your scripts already running on 7. Luna: And for the scripts that use Active Directory or Exchange? I know those modules aren't natively compatible with PowerShell 7. Lucas: That's a real pain point. The Active Directory module, for example, is still built on.NET Framework. It doesn't work directly in PowerShell 7. The workaround is to use the Windows Compatibility Module — that lets you load Windows PowerShell modules in PowerShell 7 via a proxy. But it adds overhead and sometimes breaks. Microsoft is slowly releasing updated modules, but it's not a fast process. Luna: So for now, it's a hybrid approach: run PowerShell 7 for most things, but keep a 5.1 session open for legacy modules. Lucas: Exactly. And that's okay as a transition strategy. But the endpoint has to be fully on 7. Because the longer you wait, the more scripts you accumulate that will break when the transition becomes mandatory. Luna: I think you're right about the timeline. It feels like Microsoft is accelerating. The next Windows 11 feature update, expected this fall, might be the one where 5.1 is truly optional. Lucas: I think so too. And that means the summer is the window to migrate. If you're an IT pro listening, start your audit now. And for those of us watching the industry, this is another example of Microsoft using Windows 11 as a lever to modernize enterprise IT — whether the enterprise is ready or not. Luna: Whether they like it or not. Lucas: Right. But in this case, the destination — PowerShell 7 — is genuinely better. Faster, cross-platform, open-source. It's just the journey that's painful. Luna: And that's the story for so much of Windows 11. Lucas: It really is. Alright, that's all for this episode. We'll be back next week with another deep dive into the corners of enterprise Windows that are quietly shifting.