AI Shell Preview 6 is here!

We are super excited to announce the latest preview release of AI Shell. This release focuses on enhancing the user experience with new features, improved error handling, and better integration with Model Context Protocol (MCP) tools.

What’s new at a glance

• MCP client integration
• Built-in tools
• Resolve-Error command improvements
• Aliases and flows for staying in your terminal

MCP Integration

AI Shell now acts as an MCP client, which allows you to add any MCP server to your AI Shell experience. Connecting to an MCP server massively improves the capability of your AI Shell giving you the tools that provide more relevant data or carry out actions!

Adding MCP Servers

To add an MCP server, create an mcp.json file in $HOME\.aish\ folder. The following example shows two MCP servers: everything and filesystem. You can add any MCP servers you want.

{
    "servers": {
      "everything":{
        "type":"stdio",
        "command":"npx",
        "args":["-y", "@modelcontextprotocol/server-everything"]
      },
      "filesystem": {
        "type": "stdio",
        "command": "npx",
        "args": [
          "-y",
          "@modelcontextprotocol/server-filesystem",
          "C:/Users/username/"
        ]
      }
    }
  }

If it’s a remote MCP server, change the type to https. You know that you have successfully added an MCP server when you see it in the AI Shell UI. You can confirm that it’s running by checking the status of the server through the /mcp command. Using /mcp also lists each MCP Server and the tools available.

Standalone experience with AI Shell and MCP Servers

MCP servers enhance your standalone experience with AI Shell, allowing your command line to use MCP servers and AI to perform tasks. For example, @simonb97/server-win-cli is an MCP server that allows you to run commands on your Windows machine, whether it be PowerShell, CMD, Git Bash, or any configured shell you use! It also provides configuration settings to define which commands and operations are allowed to run.

Additional MCP servers:

• DesktopCommander
• Other community MCP Servers

Built-in Tools for AI Shell

This release introduces built-in tools that are now accessible to agents within AI Shell. These commands are similar to MCP Server tools, but are exclusive to the AI Shell experience. These tools are designed to enhance the AI Shell experience by providing context-aware capabilities and automation features. They can be used in conjunction with the MCP servers to create a powerful AI-driven shell environment.

Here is a simple demo showing how you can have AI Shell run commands on your behalf using the run_command_in_terminal tool:

This example shows how additional context is provided to AI Shell to improve results:

You can also use the get_terminal_content tool to get the content from the connected terminal and provide it to AI Shell to help it understand what you are trying to do:

Resolve-Error Command Improvements

Previously the Resolve-Error command was only able to run after an error occurred in the previous command. Now, Resolve-Error identifies which command the user wants to troubleshoot:

• If the last error’s command matches the most recent command in history, it’s assumed to be the one the user is interested in.
• If the last error’s command isn’t the most recent and $LastErrorCode is null or zero, the error likely comes from an earlier command, not the very last one.
• If $LastErrorCode is non-zero and $? is false, the last command was a failing native command.
• If $LastErrorCode is non-zero but $? is true, it’s unclear which command or failure the user is focused on, so the agent analyzes the terminal content to determine the relevant context.

This logic allows AI Shell to better understand what the error the user is trying to resolve is rather than requiring you to ask for AI’s help immediately after an error occurs.

Staying in your shell

The Invoke-AIShell and Resolve-Error commands allow you to stay in your working terminal to interact with the AI Shell agent. To learn more about the parameters added, see the previous blog post that details these features. For your convenience, these commands have aliases that make them quicker to use.

How to install AI Shell

To install the latest version of AI Shell, run the following command in your PowerShell terminal:

Invoke-Expression "& { $(Invoke-RestMethod 'https://aka.ms/install-aishell.ps1') }"

We hope that these enhancements make your experience with AI Shell more powerful! We are always looking for feedback and suggestions, so please submit issues or feature requests in our GitHub repository.

Thank you so much!

AI Shell Team

Steven Bucher & Dongbo Wang

The post Introducing MCP Support in AI Shell Preview 6 appeared first on PowerShell Team.

We’re pleased to announce the general availability (GA) release of Microsoft.PowerShell.PlatyPS v1.0.0.

PlatyPS is the tool that Microsoft uses to create the PowerShell content you get from Get-Help and build the content published as PowerShell documentation on Microsoft Learn.

PowerShell help files are stored as Microsoft Assistance Markup Language (MAML), an XML format. PlatyPS simplifies the authoring process by allowing you to write the help files in Markdown, then convert to MAML. Markdown is widely used in the software industry, supported by many editors including Visual Studio Code, and easier to author.

With this release, Microsoft.PowerShell.PlatyPS is the supported tool. This release is a substantial rewrite with all new cmdlets. platyPS v0.14.2 is no longer supported. We encourage all users to upgrade to Microsoft.PowerShell.PlatyPS for the latest features, performance improvements, and ongoing support. If you have scripts that use the older version of platyPS, you must rewrite them to use the new cmdlets.

Microsoft.PowerShell.PlatyPS includes several improvements:

• Re-write in C# leveraging markdig for parsing Markdown (the same library used by Microsoft Learn to render Markdown)
• Provides a more accurate description of a PowerShell cmdlet and its parameters and includes information that was previously unavailable
• Creates an object model of the help file that you can manipulate and supports chaining cmdlets for complex operations
• Increased performance – processes 1000s of Markdown files in seconds

Microsoft.PowerShell.PlatyPS runs on:

• Windows PowerShell 5.1+
• PowerShell 7+ on Windows, Linux, and macOS

Installing Microsoft.PowerShell.PlatyPS

To begin working with Microsoft.PowerShell.PlatyPS 1.0.0, install the module from PSGallery.

Install-PSResource -Name Microsoft.PowerShell.PlatyPS

Documentation to get started

For this release, the cmdlet reference is available at Microsoft.PowerShell.PlatyPS. For an example of how to use the new cmdlets, see Example #1 in New-MarkdownCommandHelp.

Call to action

Our goal is to make it easier for you to update and maintain PowerShell help files. We value your feedback. Stop by our GitHub repository and let us know of any issues you find.

Interested in contributing to the PlatyPS project? We welcome feature ideas and contributions. Please follow the contribution guidance in the Github Readme.

Jason Helmick

Sr. Product Manager, PowerShell

The post Announcing Microsoft.PowerShell.PlatyPS 1.0.0 appeared first on PowerShell Team.

We’re pleased to announce the General Availability of Microsoft’s Desired State Configuration (DSC) version 3.1.0. This release marks a significant milestone in our effort to deliver cloud-native configuration management for cross-platform environments. DSC is a declarative configuration and orchestration platform that defines a standard way of exposing settings for applications and services. DSC v3.1.0 is built on collaboration with key improvements driven by partner requests. Special thanks to the Windows Package Manager (WinGet) team and the incredible support of the DSC community.

For additional details about the initial DSC v3.0.0 release, see:

• DSC v3.0.0 Announcement
• DSC v3.0.0 Get Started
• DSC v3.0.0 Enhanced Authoring

What’s New in DSC v3.1

This release continues our momentum by delivering features and improvements driven by real world use, partner feedback, and community contributions.

DSC v3.1 includes updates and fixes across the platform. Here are some of the most important improvements:

WinGet and partner-driven enhancements

• Core infrastructure updates to enable DSC-based management in WinGet scenarios.
• Extended resource invocation APIs, allowing for richer integration by external tools.
• Increased flexibility for configuration refresh and reporting, driven by partner needs.

Resource authoring improvements

• Improved handling and validation for resource schema files, with clearer error messages.
• Fixed issues with module loading and path resolution that impacted PSDSC resources.
• More robust handling of resources with required and optional properties.

Cross-Platform reliability and bug fixes

• Fixed several Linux-specific issues in resource execution, state detection, and error reporting.
• Improved Windows compatibility, particularly for recent versions and in mixed-OS environments.
• Addressed inconsistencies in the application of ensure properties and desired state evaluation.

Performance and quality

• Optimized configuration drift detection, resulting in faster and more reliable test operations.
• Reduced occurrence of configuration runs left in an indeterminate or failed state.
• Improved error handling for edge cases in set, test, and get operations.

Diagnostics and usability

• Expanded logging and diagnostics, making it easier to trace resource behavior and configuration activity.
• Improved the clarity and usefulness of error and warning messages across platforms.
• More consistent reporting of operation outcomes in both interactive and automated scenarios.

For a full list of changes, see the DSC v3.1 changelog

Installing DSC

To get started, follow these steps to install DSC on your system:

On Windows, you can install DSC from the Microsoft Store using winget. By installing from the Store or using winget, you get automatic updates for DSC.

Search for the latest version of DSC:

winget search DesiredStateConfiguration --source msstore

Name                              Id           Version Source
---------------------------------------------------------------
DesiredStateConfiguration         9NVTPZWRC6KQ Unknown msstore
DesiredStateConfiguration-Preview 9PCX3HX4HZ0Z Unknown msstore

Install DSC using the id parameter:

# Install latest stable
winget install --id 9NVTPZWRC6KQ --source msstore

# Install latest preview
winget install --id 9PCX3HX4HZ0Z --source msstore

On Linux and macOS, you can install DSC using the following steps:

1. Download the latest release from the PowerShell/DSC repository.
2. Expand the release archive.
3. Add the folder containing the expanded archive contents to your PATH environment variable.

Support lifecycle

DSC follows semantic versioning.

The first release of DSC version 3.0.0 is a Stable release. DSC version 3.1.0 is the current Stable release. Patch releases update the third digit of the semantic version number. For example, 3.1.1 is a patch update to 3.1.0. Stable releases receive patches for critical bugs and security vulnerabilities for three months after the next Stable release. For example, version 3.1.0 is supported for three months after 3.2.0 is released.

Always update to the latest patch version of the release you’re using.

Call to action

For more information about Desired State Configuration v3.0 (DSC), see the DSC documentation. We value your feedback. Stop by our GitHub repository and let us know of any issues you find.

Jason Helmick

Sr. Product Manager, PowerShell

The post Announcing Microsoft Desired State Configuration v3.1.0 appeared first on PowerShell Team.

AI Shell Preview 4 Is here: Better macOS support, and more!

We’re excited to share the latest preview release of AI Shell that includes new features and improvements based on your feedback. This release focuses on improving the user experience by improving access to Azure OpenAI deployments, improvements to the Invoke-AIShell command, and expanded compatibility with macOS.

MacOS support improvements

We’ve made significant improvements to the macOS side car experience with iTerm2. Previously, the side car experience was unreliable and didn’t support the /code post command. Now you have a more reliable experience with feature parity with your experience on Windows. For this experience you need to run PowerShell 7 in iTerm2. For more information about PowerShell 7 on macOS, see Installing PowerShell on macOS.

Support for Microsoft Entra ID

To keep password and keys secure, we’ve added support for Entra ID authentication to to Azure OpenAI instances. Now you can access your Azure OpenAI resource without storing keys in the configuration file. The following example shows how to configure Entra ID authentication:

{
  // Declare GPT instances.
  "GPTs": [
      // Declaration of an Azure OpenAI instance with EntraID authentication
      {
        "Name": "ps-az-entraId",
        "Description": "A GPT instance with expertise in PowerShell scripting using Entra ID authentication.",
        "Endpoint": "<Your Endpoint>",
        "Deployment": "<Your Deployment Name>",
        "ModelName": "<Your Model Name>",
        "AuthType": "EntraID",
        "SystemPrompt": "You are a helpful and friendly assistant with expertise in PowerShell scripting and command line."
      }
  ],

  // Specify the default GPT instance to use for user query.
  "Active": "ps-az-entraId"
}

This is the hierarchy of credentials that AI Shell will use to authenticate to Azure OpenAI:

• EnvironmentCredential
• WorkloadIdentityCredential
• ManagedIdentityCredential
• SharedTokenCacheCredential
• VisualStudioCredential
• AzureCliCredential
• AzurePowerShellCredential
• AzureDeveloperCliCredential
• InteractiveBrowserCredential

For more information on what these particular credentials are, please see the DefaultAzureCredential reference.

Invoke-AIShell command additions

We’ve added additional parameters to the Invoke-AIShell command to allow for easier use of the side pane without leaving the left side of the screen.

• -PostCode – This parameter allows you to post code generated from the side pane to the connected PowerShell session. It reduces the need to switch between the side pane and terminal to run the /code post command.
• -CopyCode – This parameter allows you to copy code from the side pane without using the /code copy command.
• -Exit – This parameter allows you to exit the side pane without using the /exit command.

These new parameters allow you to use your terminal normally. You can inject AI generated commands without cluttering your main buffer and keep all the details and descriptions in the side pane. This is a great way to use AI Shell as side by side shell assistant! Coupled with PSReadLine Predictive IntelliSense, you can quickly and easily use AI Shell in your normal shell workflow.

Phi Silica agent

We’ve added a new experimental agent called Phi Silica. This agent uses the built-in Phi Silica model included with the latest Copilot+ PCs, allowing you to have an offline experience with AI Shell.

This experimental AI provider is a proof of concept that’s still under development. You should only use it for testing. Expect breaking changes in future releases.

Additional minor improvements

Here are a few additional improvements that have been made in this release:

• Updated model information to support latest OpenAI models (#368)
• Add /clear as an alias to the command /cls to clear console in AIShell (#370)
• Update installation script to install the AIShell module on macOS too (#374)
• Enhanced model management and system prompt integration in OllamaAgent (#351) (Thanks @cnupy!)

To see the full list of changes, check out the changelog in the release page.

How to install AI Shell Preview 4

To install the latest version of AI Shell, run the following command in your PowerShell terminal:

Invoke-Expression "& { $(Invoke-RestMethod 'https://aka.ms/install-aishell.ps1') }"

As usual we would love for you to try AI Shell and provide feedback in our GitHub repository.

Thanks so much!

AI Shell Team

Steven Bucher & Dongbo Wang

The post AI Shell Preview 4 Release! appeared first on PowerShell Team.

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!

The post PowerShell, OpenSSH, and DSC team investments for 2025 appeared first on PowerShell Team.

Microsoft Desired State Configuration (DSC) v3.0.0 provides powerful feature that enhance the authoring experience.

• Shell completion
• Schema-based validation
• Support for modern DSLs like Azure Bicep

DSC command completer

The completer command returns a shell script that, when executed, registers completions for the given shell.

DSC can generate completion scripts for the following shells:

• Bash
• Elvish
• Fish
• PowerShell
• Z Shell

To learn more, see the dsc completer command reference documentation.

Enhanced Authoring with Schemas

Working with DSC platform involves writing configuration documents and resource manifests. DSC validates these data files using a JSON schema. While the DSC schemas are useful for authoring, DSC also includes a set of enhanced schemas for authoring the files in VS Code.

These schemas define extra keywords specific to VS Code that:

• Improve the contextual help when hovering on or selecting a property in the data file.
• Add contextual help for enum values.
• Improve the error messages for invalid values.
• Add default snippets to autocomplete values.

To learn more, see Authoring with Enhanced Schemas.

Authoring with Bicep (Coming soon!)

Bicep is Microsoft’s domain specific language (DSL) for creating declarative Azure Resource Manager (ARM) deployments. It offers a clean, intuitive syntax that makes writing and maintaining DSC configurations more efficient. By using Bicep as a DSL, DSC users enjoy the benefits of strong validation, modularity, and seamless integration with Azure-native tooling, without the complexity of authoring in JSON or YAML.

You can write and invoke Bicep configurations locally–without access to Azure–or as part of your Azure deployments, combining Infrastructure as code (IaC) and Configuration as code (CaC).

The following Bicep configuration document calls the classic PowerShell resource WindowsFeature from the PSDesiredStateConfiguration module to install the IIS web server feature on Windows Server.

targetScope = 'dsc'
resource powershellAdapter 'Microsoft.Windows/WindowsPowerShell@2025-01-07' = {
  name: 'Web server install'
  properties: {
    resources: [
      {
        name: 'Run WindowsFeature'
        type: 'PSDesiredStateConfiguration/WindowsFeature'
        properties: {
          Name: 'Web-server'
          Ensure: 'Present'
        }
      }
    ]
  }
}

By default, a Bicep file is scoped to a Bicep resource. To use Bicep with DSC, you must set the scope to dsc. Bicep support is still being developed. We’ll make an announcement when Bicep support and documentation is available.

Call to action

For more information about DSC v3.0, see the DSCv3 documentation. We value your feedback. Stop by our GitHub repository and let us know of any issues you find.

Jason Helmick

Sr. Product Manager, PowerShell

The post Authoring Enhancements in Microsoft Desired State Configuration v3.0.0 appeared first on PowerShell Team.

This is the second post in a multi-part series about the new release of DSC.

Microsoft Desired State Configuration (DSC) v3.0.0 is a modern, cross-platform configuration management framework designed to help administrators and developers declaratively define and enforce system states. Whether you’re managing infrastructure, deploying applications, or automating system configurations, DSC provides a flexible and scalable approach to configuration as code.

Installing DSC

To get started, follow these steps to install DSC on your system:

On Windows, you can install DSC from the Microsoft Store using winget. By installing from the Store or using winget, you get automatic updates for DSC.

winget search DesiredStateConfiguration
winget install --id <insert-package-id> --source msstore

On Linux and macOS, you can install DSC using the following steps:

1. Download the latest release from the PowerShell/DSC repository.
2. Expand the release archive.
3. Add the folder containing the expanded archive contents to your PATH environment variable.

Getting started with the DSC command

The dsc command operates on a configuration document or invokes specific resources to manage settings.

Run the following command to display the dsc command help:

dsc --help

Apply configuration or invoke specific DSC resources

Usage: dsc.exe [OPTIONS] <COMMAND>

Commands:
  completer  Generate a shell completion script
  config     Apply a configuration document
  resource   Invoke a specific DSC resource
  schema     Get the JSON schema for a DSC type
  help       Print this message or the help of the given subcommand(s)

Options:
  -l, --trace-level <TRACE_LEVEL>    Trace level to use [possible values: error, warn, info, debug, trace]
  -t, --trace-format <TRACE_FORMAT>  Trace format to use [default: default] [possible values: default, plaintext, json]
  -h, --help                         Print help
  -V, --version                      Print version

Use the command to get version information.

dsc --version

dsc 3.0.0

To learn more, see the dsc command reference documentation.

Access DSC resources with dsc resource

The dsc resource command displays or invokes a specific DSC resource. The dsc resource command contains subcommands for listing DSC resources and invoking them directly.

Use the following command to display a list of installed DSC resources.

dsc resource list

Type                                        Kind      Version  Caps      RequireAdapter  Description
----------------------------------------------------------------------------------------------------
Microsoft.DSC.Transitional/RunCommandOnSet  Resource  0.1.0    gs------                  Takes a si…
Microsoft.DSC/Assertion                     Group     0.1.0    gs--t---                  `test` wil…
Microsoft.DSC/Group                         Group     0.1.0    gs--t---                  All resour…
Microsoft.DSC/PowerShell                    Adapter   0.1.0    gs--t-e-                  Resource a…
Microsoft.Windows/RebootPending             Resource  0.1.0    g-------                  Returns in…
Microsoft.Windows/Registry                  Resource  0.1.0    gs-w-d--                  Manage Win…
Microsoft.Windows/WMI                       Adapter   0.1.0    g-------                  Resource a…
Microsoft.Windows/WindowsPowerShell         Adapter   0.1.0    gs--t---                  Resource a…

When the command includes the adapter option, dsc checks for any resource adapters with a matching name. Classic PowerShell resources are part of the Microsoft.Windows/WindowsPowerShell adapter.

dsc resource list --adapter Microsoft.Windows/WindowsPowerShell

Partial listing

Type                                                   Kind      Version  Caps      RequireAdapter
----------------------------------------------------------------------------------------------------
PSDesiredStateConfiguration/Archive                    Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/Environment                Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/File                       Resource  1.0.0    gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/Group                      Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/GroupSet                   Resource  1.1      gs--t---  Microsoft.Windo…
PSDesiredStateConfiguration/Log                        Resource  1.1      gs--t---  Microsoft.Windo…

To learn more, see the dsc resource command reference documentation.

Manage a basic configuration

The dsc config command includes subcommands for managing the resource instances defined in a DSC configuration document.

The following YAML configuration document calls the classic PowerShell resource WindowsFeature from the PSDesiredStateConfiguration module to install a Windows web server (IIS) on Windows Server.

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2024/04/config/document.json
resources:
  - name: Use Windows PowerShell resources
    type: Microsoft.Windows/WindowsPowerShell
    properties:
      resources:
        - name: Web server install
          type: PSDesiredStateConfiguration/WindowsFeature
          properties:
            Name: Web-Server
            Ensure: Present

To set a machine to the configuration, use the dsc config set subcommand. The following example shows how you can send the configuration document to DSCv3 using PowerShell:

dsc config get --file ./web.comfig.dsc.yaml

To learn more, see the dsc config command reference documentation.

Next steps

Learn more about Authoring Enhancements in Desired State Configuration v3.0.0.

Call to action

For more information about DSC v3.0, see the DSCv3 documentation. We value your feedback. Stop by our GitHub repository and let us know of any issues you find.

Jason Helmick

Sr. Product Manager, PowerShell

The post Get started with Microsoft Desired State Configuration v3.0.0 appeared first on PowerShell Team.

This is the first post in a multi-part series about the new release of DSC.

We’re pleased to announce the General Availability of Microsoft’s Desired State Configuration (DSC) version 3.0.0.

This version marks a significant evolution in cloud-native configuration management for cross-platform environments. DSC is a declarative configuration and orchestration platform that defines a standard way of exposing settings for applications and services. It’s a tool for managing systems and applications by describing what they should look like rather than how to make it that way. DSC simplifies system, service, and application management by separating what to do from how to do it.

Benefits of DSC

• Declarative and Idempotent: DSC configuration documents are declarative JSON or YAML files that define the desired state of your system in a straight-forward way. They include the instances of DSC resources that need configuration. DSC ensures the system matches that state, repeatedly if needed, without making unnecessary changes.
• Flexible: DSC Resources define how to manage state for a particular system or application component. Resources can be authored in any language, not only PowerShell.
• Cross-Platform: DSC works on Linux, macOS, and Windows without needing extra tools or dependencies.
• Integratable: Designed to be easily integrated into existing configuration solutions. DSC returns schematized JSON objects for trace messages and command output. Tool developers and script authors can easily validate and parse the output for integration with other configuration tools and frameworks. DSC simplifies how you call it by accepting JSON from stdin for all configuration and resource commands. DSC resources include a manifest that defines the resource properties as a JSON schema and how to invoke the resource. You can reuse this definition across various toolchains for tighter integration with DSC.
• Backwards compatible: This release of DSC can use all existing PowerShell 7 and Windows PowerShell DSC resources.

With DSC, you can:

• Create configuration files that define how your environment should look.
• Write DSC resources in any programming language to manage your systems and applications.
• Invoke DSC resources to perform specific actions.
• Define a standard way for applications and services to make their settings discoverable and usable. This means that you can discover and invoke resources directly, even without DSC.

Differences from PowerShell DSC

Windows PowerShell 5.1 includes PowerShell Desired State Configuration (PSDSC). We refer to as classic DSC, which encompasses PSDSC v1.1 and v2. However, DSC can use any classic DSC resources that exist today, including the script-based and class-based PSDSC resources. You can use PSDSC resources in DSC with both Windows PowerShell and PowerShell.

The release of DSC is a major change to the DSC platform. DSC differs from PSDSC in a few important ways:

• DSC no longer includes or supports the Local Configuration Manager (LCM).
• DSC doesn’t depend on PowerShell. You can use DSC without PowerShell installed and manage resources written in bash, python, C#, Go, or any other language.
• DSC doesn’t include a local configuration manager. DSC is invoked as a command-line tool. It doesn’t run as a service.
• The PSDSC configuration documents used Managed Object Format (MOF) files. Few tools were able to parse MOF files, especially on non-Windows platforms. DSC isn’t compatible with MOF files, but you can still use all existing PSDSC resources.
• DSC is built on industry standards, such as JSON, JSON Schema, and YAML. These standards make DSC easier to integrate into tools and workflows compared to PSDSC.
• DSC configuration documents are defined in JSON or YAML. The configuration documents use expression functions to enable dynamic values, rather than using PowerShell code to retrieve environment variables or join strings.
• DSC supports supplying parameter values for configuration documents at runtime either as JSON or by pointing to a parameters file instead of generating a configuration MOF file before applying the configuration.
• Unlike PSDSC, DSC returns strongly structured output. This structured output adheres to a published JSON Schema, making it easier to understand the output and to integrate it into your own scripts, reporting, and other tooling. When you test or set resources and configurations with DSC, the output tells you how a resource is out of the desired state or what DSC changed on your system.

Features of DSC

• Groups: DSC supports a new resource kind that changes how DSC processes a list of resources. Resource authors can define their own group resources and configuration authors can use any of the built-in group resources.The DSC repository has an example that shows how you can group resources together and use the dependsOn keyword to define the order those groups are applied in a configuration.
• Assertions: Use the Microsoft.Dsc/Assertion (a special group resource) to validate the environment before running the configuration.The DSC repository has an example that shows how you can use an assertion to manage a resource that should only run on a specific operating system.
• Importers: DSC supports a new resource kind that pulls in a configuration from an external source for reuse in the current configuration document. Resource authors can define their own importer resources and configuration authors can use the built-in Microsoft.DSC/Include resource.The DSC repository has an example that shows how you can use the Microsoft.Dsc/Include resource to reuse a separate configuration document file, enabling you to compose a complex configuration from smaller, simpler configuration documents.
• Exporting: DSC supports a new operation that resources can implement to return the list of all existing instances of that resource. You can use the dsc resource export command to get every instance of that resource on a machine. Use the dsc config export command to look up a set of resources and return a new configuration document containing every instance of those resources.
• Configuration functions: DSC configuration documents support a set of functions that enable you to change how DSC processes the resources.The DSC repository has an example that shows how you can reference the output from one resource in the properties of another.

Support lifecycle

DSC follows semantic versioning. The first release of DSC, version 3.0.0, is a Stable release.

The first release of DSC, version 3.0.0, is a Stable release. Patch releases update the third digit of the semantic version number. For example, 3.0.1 is a patch update to 3.0.0. Stable releases receive patches for critical bugs and security vulnerabilities for three months after the next Stable release. For example, version 3.0.0 is supported for three months after 3.1.0 is released.

Always update to the latest patch version of the release you’re using.

Next steps

As I mentioned at the top of this post, this was the first in a series of posts about the new DSC. For the subsequent posts:

• DSC refers to Desired State Configuration (DSC) v3.0.0
• PSDSC refers to PowerShell Desired State Configuration (PSDSC) v1.1 and v2

Now you are ready for the next post: Get Started with Desired State Configuration v3.0.0 (DSC)

Call to action

For more information about Desired State Configuration v3.0 (DSC), visit the DSC documentation. We value your feedback. Stop by our GitHub repository and let us know of any issues you find.

Jason Helmick

Sr. Product Manager, PowerShell

The post Announcing Microsoft Desired State Configuration v3.0.0 appeared first on PowerShell Team.

What’s New in AI Shell Preview 2?

We’re excited to announce the Preview 2 release of AI Shell! With this update you can expect the following improvements:

• Improved support for Azure PowerShell
• Broader support for third party OpenAI-compatible models
• Refactored code sample for creating an Ollama agent
• Improved native command error handling
• An easier way to deploy Azure OpenAI instances
• Additional bug fixes

Improved support for Azure PowerShell

The improvements to the azure agent are designed to reduce friction when managing Azure resources with the Azure CLI and PowerShell. The agent now offers deeper integration with Azure PowerShell, making it easier to use AI-created Azure PowerShell scripts.

• The /replace command now supports Azure PowerShell. The agent walks you through replacement of parameter values in generated Azure PowerShell responses.
• The agent now support Azure PowerShell authentication using the Connect-AzAccount command. Previously, the agent only supported Azure CLI authentication.

Broader support for third party OpenAI-compatibles models

With this release, the openai-gpt agent extends support to third party models that follow the OpenAI API specifications, allowing for a more flexible AI experience. Many of these models are open source tools for running SLMs and LLMs locally. The openai-gpt agent nows supports the following additional models:

• Ollama
• LM Studio
• Deepseek
• LocalAI
• Google Gemini
• Grok

To use these models, you only need to configure the endpoint, key and model name in the agent config file. The following openai.agents.config file contains example configurations for two of the new AI providers.

{
    "GPTs": [
        {
          "Name": "gpt-deepseek",
          "Description": "A GPT instance using DeepSeek v3.",
          "Endpoint": "https://api.deepseek.com",
          "ModelName": "deepseek-chat",
          "Key": "<your-deepseek-api-key>",
          "SystemPrompt": "You are a helpful assistant."
        },

        {
          "Name": "gpt-gemini",
          "Description": "A GPT instance using Google Gemini.",
          "Endpoint": "https://generativelanguage.googleapis.com/v1beta/openai/",
          "ModelName": "gemini-1.5-flash",
          "Key": "<your-gemini-api-key>",
          "SystemPrompt": "You are a helpful assistant."
        }
    ]

    "Active": "gpt-deepseek"
}

Improved native command error handling

Resolve-Error (alias fixit) now uses the screen scraper API on Windows to capture the error output of native commands. This allows AI Shell to provide better resolution of error messages that come from native commands rather than from PowerShell.

Ollama agent improvements

We refactored the example code for the agent ollama. This example provides the basic structure that you can use to build out your own agent. The refactored code now uses the OllamaSharp library and add the ability to configure the agent using settings files.

The ollama agent isn’t shipped with AI Shell but you can build it yourself. See the instructions in the locally build the repo section of the README. Thank you @kborowinski on GitHub for this contribution!

Tools for easy deployment of Azure OpenAI instances

We added a Bicep template that deploys an Azure OpenAI instance in seconds. Using the template is much faster than manually creating an instance in the Azure portal. This template includes documentation with step by step instructions.

• Bicep template
• Documentation

Additional bug fixes

There are many bug fixes in this release. For a complete list of changes, see the changelog.

How to get AI Shell Preview 2

Use the following command in PowerShell 7 to install or upgrade AI Shell:

Invoke-Expression "& { $(Invoke-RestMethod 'https://aka.ms/install-aishell.ps1') }"

For more information, see Install AI Shell.

Automatically start AI Shell

One piece of feedback we often hear is: How can I have AI Shell automatically start up when I open Windows Terminal?

It’s easy! Just add Start-AIShell to your PowerShell profile script. Here’s how:

1. Open your profile in the text editor of your choice.
2. Add the following code to the end of the file:

   if ($PSVersionTable.PSVersion -ge ([version]'7.4.6') -and
     (Get-Process -Id $pid).Parent.Name -eq 'WindowsTerminal') {
      Start-AIShell
   }

Now, AI Shell will automatically start when you open Windows Terminal.

If you need help creating a profile scripts, see about_Profiles.

Try it out and share your feedback

We would love to hear your feedback as we continue improving AI Shell. Join the discussion in our GitHub Issues and let us know how AI Shell is helping your automation workflows.

Stay tuned for future updates as we bring more AI-powered capabilities to your CLI experience.

Thanks!

Steven Bucher and Dongbo Wang

AI Shell Team

The post Announcing AI Shell Preview 2 appeared first on PowerShell Team.

It has been a while since we’ve updated folks on the latest behaviors for Microsoft Update! This post gives some background on Microsoft Update, explains our update rules, and announces our plans for updating your installs of PowerShell 7.2.

About Microsoft Update

Microsoft Update (MU) is a service that provides automatic updates for Microsoft products and services. We first started using MU in PowerShell 7.2. MU provides a convenient way to automatically update PowerShell 7, which ensures you can control your update schedule, test it against your environment, and scale across your enterprise with ease.

Enabling MU

During MSI installation, two checkboxes control update settings:

• Enable updates for PowerShell through Microsoft Update or WSUS (recommended) Allows the system to receive updates for PowerShell 7 through Microsoft Update, Windows Server Update Services (WSUS), or System Center Configuration Manager (SCCM).
• Enable Microsoft Update when I check for updates (recommended) Permits the system to receive updates for all supported Microsoft software, not just Windows.

We recommend that you select both options to ensure comprehensive update coverage.

If you want to set these options while installing PowerShell from the command line, you can find detailed instructions in the PowerShell documentation.

Update Availability

After we release a new PowerShell version, it can take up to two weeks before the update is available through Microsoft Update. We strive to publish the update no later than 2 weeks after the GitHub release, but there is no guarantee. There may be circumstances that delay the update. If you need the update before it’s available via MU, you can download it directly from the PowerShell Releases page on GitHub.

What is the expected behavior of MU?

We defined the rules for updates in an intentional way to ensure that users who are using LTS versions stay on LTS versions. This means that you might not be updated to the latest version of PowerShell 7 when you expected.

These are the rules for updates:

• If you are running 7.4 (LTS), you will receive updates to 7.4 (LTS)
• If you are running 7.5 (stable), you will receive updates to 7.5 (stable)
• If you are running any preview or release candidate (rc) version, you will receive updates to next latest preview version as they come out.

We will never update an LTS version to a stable non-LTS version, like 7.4 to 7.5. However, a stable non-LTS release WILL be upgraded to the higher LTS release when support for the stable release ends. The only time we update an LTS version to a different version would be when an LTS version is out of support. For example, we will update 7.4 to 7.6 (next LTS) once 7.4 goes out of support.

Preview versions will never be updated to the latest stable version. Instead, we will update you to the latest preview release. This means if you are on 7.5-rc.1 you will be updated to 7.6-preview.2 (since preview.1 was skipped) instead of 7.5.

Helpful Links

Hopefully this post helps you understand the MU process. If you want more information about our MU release process, PowerShell releases, or the PowerShell Support Lifecycle, check out the following articles.

• Microsoft Update FAQ
• PowerShell GitHub Releases
• PowerShell Support Lifecycle

Feedback

As always, we look forward to your feedback. You can provide feedback via GitHub Issues.

Thank you so much!

Steven Bucher

PM on the PowerShell Team

The post Microsoft Update changes for PowerShell 7 appeared first on PowerShell Team.