Team investments for 2025
First, apologies getting this out so late into the year. We’ve been very busy and just found the time to write this update.
Security improvements
We continue to treat security as a top priority and as issues are discovered or reported, we will continue to prioritize these issues over new feature development.
Bug fixes and community PRs
We continue to fix various reported issues, as well as prioritizing the review and merging of community pull requests. Based on community feedback, we’re now using a GitHub project to provide transparency on which issues and pull requests team members are focusing on.
PowerShell 7.6
PowerShell 7.6 will be our latest Long-Term Servicing (LTS) release. We continue to align with the .NET 10 release cycle and support lifecycle. There have already been 4 preview releases published.
Moving PowerShell content folder out of MyDocuments
This has been a long-standing request from the community due to automatic sync of MyDocuments folder and OneDrive. While some users want to leverage OneDrive for syncing across their systems, many other users complain about the performance impact on PowerShell module discovery when modules are stored in the OneDrive folder. There was a previous experimental feature PSModuleAutoLoadSkipOfflineFiles that is now mainstream in PowerShell 7.5. With this change, PowerShell skips modules that are not marked being available locally. However, this also led to confusion for users who expected their modules to be available when they were not on disk.
As any change here is a breaking change, we’ve spent a lot of time discussing the best way to approach this. We are close to finishing a proposal that we will publish to the PowerShell-RFC repository for community feedback when ready. We will have experimental feature available within the 7.6 preview cycle for users to test and provide feedback on.
Note that the PowerShell content folder does not just contain modules, but also the user’s PowerShell profile, scripts installed from PowerShell Gallery, and updated help files.
Enable native commands to integrate with PowerShell more easily
A common ask from several of our Microsoft partners who are building native commands (Azure CLI, Winget) is to more easily integrate features such as Feedback Providers and Tab Completion where they don’t need to publish a separate module from their application.
We have already published a design proposal in our RFC repo and would welcome any feedback from the community. One of the key requirements is that an application’s install and uninstall should be clean and not leave behind any artifacts in PowerShell.
Update PATH environment variable for WinGet
Currently, if you use WinGet to install a package, it will not update the PATH environment variable.
This means that newly installed applications are not available in the current PowerShell session.
This feature will be similar to the one made in cmd.exe and only apply to a specific applications.
PowerShell 7 configuration as DSC v3 resource
As part of our work to enable managing popular developer applications’ settings,
we are working on exposing pwsh as a DSC v3 resource.
This will allow users to manage the settings of PowerShell 7 in a declarative manner.
PowerShell Gallery
Significant behind-the-scenes work is happening to migrate the PowerShell Gallery from an Azure Cloud Services classic application to one hosted on Azure Kubernetes Service (AKS). This is a difficult effort but, ideally, one that won’t affect user access or performance.
EntraID server-side support
Concurrently, we are working on support for EntraID authentication that allows users to use a managed identify to publish modules to the PowerShell Gallery instead of an API key.
PSResourceGet
EntraID client-side support
Along with the changes necessary on the PowerShell Gallery side, corresponding changes are being made to PSResourceGet to support EntraID authentication.
Complete Micorosft Artifact Registry (MAR) support
We continue to progress towards General Availability for support of Microsoft Artifact Registry (MAR) in PSResourceGet. This allows users to have a default trusted repository for modules and scripts published by Microsoft. This is built on top of the support we already added for Azure Container Registry (ACR) Over time, we plan to generally support ORAS as a standard for storing artifacts in container registries, which would enable support any container registry that supports the OCI distribution spec.
Windows OpenSSH
We continue to merge upstream OpenSSH changes into our Windows OpenSSH distribution with previews published to GitHub and the final release updated into Windows.
DSC v3 resource
We continue to develop a DSC v3 resource for SSHD_CONFIG with expectations that previews will be available later this year.
Desired State Configuration v3 (DSC)
We already announced DSC 3.0 General Availablity last month and already have two service updates available.
DSC v3.0 is available in the Microsoft Store or from our GitHub repo. The macOS and Linux releases are curently only available from our GitHub repo.
DSC v3.1
In addition, we are making rapid progress on a DSC v3.1 release with multiple previews already available. Preview releases are also available from the Microsoft Store or our GitHub repo.
You can see what features are approved or being considered for the 3.1 release.
AI Shell
Our AI Shell project continues to make progress towards integration of AI into the shell to boost productivity.
Some further improvements being planned:
- Better macOS support
- Enhanced Azure PowerShell support
- Expansion of new Agents
- Better integration with PowerShell
- Support for Model Context Protocol (MCP)
Other tooling updates
We will continue to address reported issues and merge community pull requests for the following projects:
- PowerShell VSCode extension
- PowerShell Script Analyzer
- others as needed
Conclusion
Security is our top priority. We continue to improve the security of how we deliver software. Those improvements are not visible to the community, but they ensure that we are delivering secure software. We will continue to work on the community’s top issues and pull requests across our many projects, when possible. We are very thankful to our active community members!
Could you clarify what you mean by
This feature will be similar to the one made in cmd.exe and only apply to a specific applications.
Does this mean the feature will only be available to specific package managers?
Or to specific winget packages?
The cmd implementation does allow any package manager to use it see https://blogs.windows.com/windows-insider/2024/02/14/announcing-windows-11-insider-preview-build-26058-canary-and-dev-channels/
The intent is to use the same registry configuration used by cmd.exe so if you add a different package manager there, it’ll work the same
Thank you to Steve and the team for as always being open and transparent with the community, it fosters such goodwill.
My feedback on the following items:
Github Projects Adoption
I want to immediately point out that the adoption of GitHub projects is a massive lift in knowing what priorities are being worked on in the PowerShell repo itself. I'm glad this feedback was taken that the new Projects has far greater capabilities than in the past and the team has clearly evaluated and adopted those new features, and I thank you very much for that. I hope it stays that way...
Thanks for your feedback and I always appreciate your contributions to the community.
Regarding PSGallery, just to be clear, what we AREN'T doing currently is breaking up the PSGallery (which is based off an older nuget.org code base) to run as microservices in K8S. We have a requirement to move off of the deprecated (and soon to be gone) legacy cloud service app infrastructure. So initially we are moving to hosting the entirety of PSGallery within K8S. Over time, we'll think about the longer term with regards to microservices, ASP.NETCore, etc... and have more about that in the...