This post was originally published on this site

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:

Get-Content ./web.config.dsc.yaml | dsc config set

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 post was originally published on this site

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.

This post was originally published on this site

Microsoft Update (MU) changes for PowerShell 7

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.

This post was originally published on this site

We’re pleased to announce the release of PowerShell 7.5.0! For this release the focus has been on quality, security and stability of the platform. We greatly appreciate the enormous amount of community contributions in this release along with new cmdlets, experimental features and other quality of life additions. PowerShell 7.5 is built on top of .NET 9 and will be supported for 18 months as a standard support release.

Please note that support for PowerShell 7.2 is ended November 8, 2024. PowerShell 7.4 is the current LTS release of PowerShell and is supported until November 2026.

How do I get it?

PowerShell 7 is supported on Windows, Linux, and macOS. Consult the documentation for installation instructions and supported platforms.

What’s new in this release?

The PowerShell 7.5 milestone focused on security, quality and community contributions. A few highlights include:

• PSResourceGet now supports ACR as a container gallery, for more information check out the documentation
• PSReadLine has been updated to version 2.3.6
• New cmdlets ConvertTo-CliXml and ConvertFrom-CliXml (Thanks @ArmaanMcleod!)
• Performance improvements to the += operation for an array of objects. (Thanks @jborean93!)
• Web cmdlet improvements as well as improvements to other cmdlets (Thanks @CarloToso, @ArmaanMcleod, @Snowman-25 and @LNKLEO!)
• Many Tab completion improvements (Thanks @MartinGC94 and @ArmaanMcleod!)
• Many engine improvements. (Thanks @JustinGrote, @jborean93! and @ArmaanMcleod!)
• New experimental features PSDirectToVariable, PSNativeWindowsTildeExpansion, and PSSerializeJSONLongEnumAsNumber (Thanks @jborean93 and @domsleee!)
• This release also contained a number of bug fixes — for the full list of changes please refer to the changelog

For more information on what’s changed, see What’s new in PowerShell 7.5.

Experimental feature changes

The following experimental features were converted to mainstream features in PowerShell 7.5:

• PSCommandNotFoundSuggestion
• PSCommandWithArgs
• PSModuleAutoLoadSkipOfflineFiles

PowerShell 7.5 also includes the following experimental features:

• PSRedirectToVariable
• PSNativeWindowsTildeExpansion
• PSSerializeJSONLongEnumAsNumber

For more information, see Using Experimental Features in PowerShell.

What’s next?

We are also releasing previews of PowerShell 7.6, our next long term servicing (LTS) release. We appreciate all the efforts of the community, both individuals and working group members. We look forward to your continued feedback and contributions!

Jason

PowerShell Team

The post PowerShell 7.5 GA is now available appeared first on PowerShell Team.

This post was originally published on this site

We’re proud to announce the availability of PowerShell 7.5.0-rc.1! This is the first release
candidate version of PowerShell 7.5 and is considered a “go-live” release meaning that it’s a
supported release in production. PowerShell 7.5 is built on top of .NET 9 and will be
supported for 18 months as a standard support release.

Please note that support for PowerShell 7.2 is ended November 8, 2024. PowerShell 7.4 is
the current LTS release of PowerShell and is supported until November 2026.

How do I get it?

Since PowerShell 7 is supported on Windows, Linux, and macOS, and there are a
many ways to install it. If you installed the previous PowerShell 7.5 preview release on
Windows and opted into Microsoft Update, you will be automatically updated to 7.5.0-rc.1.

What’s new in this release?

The PowerShell 7.5 milestone focused on security, quality and community contributions.
A few highlights include:

• PSResourceGet now supports ACR as a container gallery, for more information check out the
  documentation
• PSReadLine has been updated to version 2.3.6
• New cmdlets ConvertTo-CliXml and ConvertFrom-CliXml(Thanks @ArmaanMcleod!)
• Web cmdlet improvements as well as improvements to other cmdlets
• Tab completion improvements
• This release also contained a number of bug fixes — for the full list of changes please refer to
  the changelog

For more information on what’s changed, see What’s new in PowerShell 7.5.

Experimental Features that were made stable for 7.5

The following experimental features were converted to mainstream features in PowerShell 7.5:

• PSCommandNotFoundSuggestion
• PSCommandWithArgs
• PSModuleAutoLoadSkipOfflineFiles

What’s next?

We expect to release PowerShell 7.5 GA in January 2025. We’ll have a separate blog post when the GA
release is available. We appreciate all the efforts of the community, both individuals and
working group members, and look forward to your continued feedback and contributions!

Sydney

PowerShell Team

The post PowerShell 7.5 RC-1 is now available appeared first on PowerShell Team.

This post was originally published on this site

PlatyPS is the primary tool for creating the PowerShell help displayed using Get-Help.
PowerShell help files are stored in an XML format known as
Microsoft Assistance Markup Language (MAML). Prior to PlatyPS, the help files were hand
authored using complex tool chains. Markdown is widely used in the open source community,
supported by many editors including Visual Studio Code, and easier to author. PlatyPS
simplifies the process by allowing you to write the help files in Markdown and then converted to
MAML.

Announcing Microsoft.PowerShell.PlatyPS

We’re pleased to announce the release of Microsoft.PowerShell.PlatyPS 1.0.0-Preview1. With
this release, there are two versions of PlatyPS.

• platyPS v0.14.2 is the current version of PlatyPS that’s used to create PowerShell help files
  in Markdown format.
• Microsoft.PowerShell.PlatyPS is the new version of PlatyPS that includes several improvements:
  • Provides a more accurate description of a PowerShell cmdlet and its parameters
  • Increased performance – processes 1000s of Markdown files in seconds
  • Creates an object model of the help file that you can manipulate in memory
  • Provides cmdlets that you can chain together to perform complex operations

Our main goal for this release is to address long standing issues, add more schema driven
features, and improve validity checking along with performance. This release is a substantial
rewrite with all new cmdlets. If you have scripts that use the older version of PlatyPS, you must
rewrite them to use the new cmdlets.

In this Preview release, we focused on:

• Re-write in C# leveraging markdig for parsing Markdown.
• New Markdown schema that includes all elements needed for Get-Help, plus information that was
  previously unavailable.
• The new cmdlets produce objects, supporting chaining cmdlets for complex operations.
• Full serialization to YAML to support our publishing pipeline.
• Automatic conversion of existing Markdown to the new object model.
• Export of the object model to Markdown, Yaml, and MAML.
• The module contains the following cmdlets:
  • Compare-CommandHelp
  • Export-MamlCommandHelp
  • Export-MarkdownCommandHelp
  • Export-MarkdownModuleFile
  • Export-YamlCommandHelp
  • Export-YamlModuleFile
  • Import-MamlHelp
  • Import-MarkdownCommandHelp
  • Import-MarkdownModuleFile
  • Import-YamlCommandHelp
  • Import-YamlModuleFile
  • New-CommandHelp
  • New-MarkdownCommandHelp
  • New-UpdateableHelp
  • Test-MarkdownCommandHelp
  • Update-CommandHelp
  • Update-MarkdownCommandHelp

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 Preview1, download and install the
module from PSGallery.

Install-PSResource -Name Microsoft.PowerShell.PlatyPS -Prerelease

Documentation to get started

For the preview1 release, the cmdlet reference is available in the GitHub repository at
Microsoft.PowerShell.PlatyPS. We’re working on publishing the documentation to the Learn
platform before the next release.

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.

Jason Helmick

Sr. Product Manager, PowerShell

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

This post was originally published on this site

PlatyPS is the primary tool for creating the PowerShell help displayed using Get-Help.
PowerShell help files are stored in an XML format known as
Microsoft Assistance Markup Language (MAML). Prior to PlatyPS, the help files were hand
authored using complex tool chains. Markdown is widely used in the open source community,
supported by many editors including Visual Studio Code, and easier to author. PlatyPS
simplifies the process by allowing you to write the help files in Markdown and then converted to
MAML.

Announcing Microsoft.PowerShell.PlatyPS

We’re pleased to announce the release of Microsoft.PowerShell.PlatyPS 1.0.0-Preview1. With
this release, there are two versions of PlatyPS.

• platyPS v0.14.2 is the current version of PlatyPS that’s used to create PowerShell help files
  in Markdown format.
• Microsoft.PowerShell.PlatyPS is the new version of PlatyPS that includes several improvements:
  • Provides a more accurate description of a PowerShell cmdlet and its parameters
  • Increased performance – processes 1000s of Markdown files in seconds
  • Creates an object model of the help file that you can manipulate in memory
  • Provides cmdlets that you can chain together to perform complex operations

Our main goal for this release is to address long standing issues, add more schema driven
features, and improve validity checking along with performance. This release is a substantial
rewrite with all new cmdlets. If you have scripts that use the older version of PlatyPS, you must
rewrite them to use the new cmdlets.

In this Preview release, we focused on:

• Re-write in C# leveraging markdig for parsing Markdown.
• New Markdown schema that includes all elements needed for Get-Help, plus information that was
  previously unavailable.
• The new cmdlets produce objects, supporting chaining cmdlets for complex operations.
• Full serialization to YAML to support our publishing pipeline.
• Automatic conversion of existing Markdown to the new object model.
• Export of the object model to Markdown, Yaml, and MAML.
• The module contains the following cmdlets:
  • Compare-CommandHelp
  • Export-MamlCommandHelp
  • Export-MarkdownCommandHelp
  • Export-MarkdownModuleFile
  • Export-YamlCommandHelp
  • Export-YamlModuleFile
  • Import-MamlHelp
  • Import-MarkdownCommandHelp
  • Import-MarkdownModuleFile
  • Import-YamlCommandHelp
  • Import-YamlModuleFile
  • New-CommandHelp
  • New-MarkdownCommandHelp
  • New-UpdateableHelp
  • Test-MarkdownCommandHelp
  • Update-CommandHelp
  • Update-MarkdownCommandHelp

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 Preview1, download and install the
module from PSGallery.

Install-PSResource -Name Microsoft.PowerShell.PlatyPS -Prerelease

Documentation to get started

For the preview1 release, the cmdlet reference is available in the GitHub repository at
Microsoft.PowerShell.PlatyPS. We’re working on publishing the documentation to the Learn
platform before the next release.

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.

Jason Helmick

Sr. Product Manager, PowerShell

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

This post was originally published on this site

PowerShell 7.5

We continue to follow our yearly release schedule for PowerShell 7 and the next version will align with .NET 9.

Pseudo-terminal support

PowerShell currently has a design limitation that prevents full capture of output from native commands by PowerShell itself.
Native commands (meaning executables you run directly) will write output to STDERR or STDOUT pipes.
However, if the output is not redirected, PowerShell will simply have the native command write directly to the console.
PowerShell can’t just always redirect the output to capture it because:

• The order of output from STDERR and STDOUT can be non-deterministic because they are on different pipes,
  but the order written to the console has meaning to the user.
• Native commands can use detection of redirection to determine if the command is being run interactive or non-interactively
  and behave differently such as prompting for input or defaulting to adding text decoration to the output.

To address this, we are working on an experimental feature to leverage pseudoterminals
to enable PowerShell to capture the output of native commands while still allowing the native command to seemingly write directly to the console.

This feature can then further be leveraged to:

• Ensure complete transcription of native commands
• Proper rendering of PowerShell progress bars in scripts that call native commands
• Enable feedback providers to act upon native command output
  • For example, it would be possible to write a feedback provider that looked at the output of git commands
    and provided suggestions for what to do next based on the output.

Once this feature is part of PowerShell 7, there are other interesting scenarios that can be enabled in the future.

Platform support

Operating system versions and distributions are constantly evolving.
We want to ensure that a supported platform is a platform that is tested and validated by the team.

During 2024, the engineering team will focus on:

• Making our tests reliable so we are only spending manual effort investigating real issues when test fails
• Simplify how we add new platforms to our test matrix so new distro requests can be fulfilled more quickly
• More actively track the lifecycle of platforms we support
• Automate publishing the supported platforms list so that our docs are always up to date

Bug fixes and community PRs

The community has been great at opening issues and pull requests to help improve PowerShell.
For this release, we will focus on addressing issues and PRs that have been opened by the community.
This means less new features from the team, but we hope to make up for that with the community contributions
getting merged into the product. We will also be investing in the Working Group application process to expand the reach of those groups.

Please use reactions in GitHub issues and PRs to help us prioritize what to focus our limited time on.

Artifact management

Fundamentals work

Ensure PowerShell Gallery addresses the latest compliance requirements for security, accessibility, and reliability.

Include new types of repositories for PSResourceGet

We plan to introduce integration with container registries, both public and private, which will
help enterprise customers create a differentiation between trusted and untrusted content.
This change will allow for a Microsoft trusted repository while the PowerShellGallery continues as untrusted by default.
By having more options for private galleries, in addition to a Mirosoft trusted repository and the PowerShell Gallery,
this enables customers to have control over package availability suitable for their environments.

Concurrent installs

To improve performance during long-running installations, we plan to enable parallel operations
so multiple module installations can happen at the same time.
This change will be particularly impactful in modules with many dependencies, such as the Az module,
which currently can take significant time to install.

Local caching of artifact details

Currently the find-psresource cmdlet pulls information about available artifacts from service endpoints
and outputs the list locally. We believe there is opportunity to locally cache the metadata about available
artifacts to reduce network dependency and improve performance when resolving dependency relationships.
This would also help enable implementing a feedback provider to suggest how to install module that is not currently installed.
So if a user tries to run a cmdlet that is not installed, the feedback provider will suggest what module to install to get the cmdlet to work.

Intelligence in the shell

We are obvserving and being thoughtful about what it will mean to integrate the experiences
provided by large language models into shell experience.
Our current outlook is to think beyond natural language chat to deep integration of learning opportunities.

We also believe there are lots of improvements to the interactivity of PowerShell that does not require a large language model.
This includes some more subtle improvements to the interactive experience of PowerShell that would help increase productivity
and efficiency at the command line.

Configuration

Desired State Configuration (DSC) helped to enable configuration as code for Windows.
With v3, we are focusing on enabling cross-platform use, simplifying resource development, improving experience
to integrate with higher level configuration management tools, and improving the experience for end users.
Our goal is to be code complete by end of March and work towards a release candidate by middle of the year.
This is a complete rewrite of DSC and we welcome feedback during the design and development process.

Remoting

Win32_OpenSSH

We hope to continue bringing new versions of OpenSSH to the Windows Server platform. Another goal
is to reduce the complex steps required to install and manage SSH at scale, to enable
partners that create automation tools to use the same mechanism when connecting to Windows servers
as they use for Linux.

SSHDConfig

Monitoring and management of the sshd_config file at scale across platforms can be challenging.
We are working on a DSC v3 resource to enable management of sshd_config using a syntax that is
closer aligned to the command line tools used by modern cloud platforms.
Initially, we’ll be targeting auditing scenarios but we hope to enable full management of the file in the future.

Help system

platyPS is a module that enables you to write PowerShell help
documentation in Markdown and convert it to PowerShell help format.
This tool is used by Microsoft teams and the community of module authors to more easily write and maintain help documentation.
We hope to continue work in this area to address partner feedback.

Other projects

The projects above will already keep the team very busy, but we will continue to maintain other existing projects.
We appreciate the community contributions to these projects and will continue to review issues and PRs:

• VSCode extension
• PSScriptAnalyzer module
• ConsoleGuiTools module
• TextUtility module
• PSReadLine module
• SecretManagement module

Our other projects will continue to be serviced on an as needed basis.

Thanks to the community from Steve Lee and Michael Greene on behalf of our team!

The post PowerShell and OpenSSH team investments for 2024 appeared first on PowerShell Team.

This post was originally published on this site

As we come to towards the end of 2023, we are excited to announce the general availability of PowerShell 7.4!
This release is built on .NET 8 and similarly,
is our latest Long Term Support (LTS) release supported for 3 years.

We want to thank our community and many contributors for their invaluable help identifying issues,
engaging in discussions in our repository, providing fixes and new features,
and helping us ship a high quality release!

How do I get it?

Since PowerShell 7 is supported on Windows, Linux, and macOS, there are a
variety of ways to get it.
If you installed the previous PowerShell 7 stable release (7.3) via the Windows Store or MSI (and opted into
Microsoft Update),
you will be automatically updated to 7.4 GA.

What’s new?

This release continues to focus on enhancing the shell experience and addressing
commonly reported customer and partner issues.

A detailed report of What’s New
is available in our documentation or via the WhatsNew
module.

Here are a few highlights:

PSResourceGet 1.0

This release includes PSResourceGet, which itself
was made generally available earlier this year.
PSResourceGet replaces PowerShellGet (although the two work side-by-side for legacy scripts) and where we will invest future
enhancements to the PowerShell module ecosystem.
This release focuses on a new codebase that is more maintainable and also provides better performance.
In addition, this module uses a different set of cmdlets to allow for breaking changes that provide a more intuitive user experience.

PSReadLine 2.3

This release includes the latest PSReadLine release
that contains a number of enhancements and bug fixes.

New stable features

The PowerShell Committee reviewed the experimental features we’ve had in the preview releases along with
community feedback (issues) and telemetry indicating the feature was used and not disabled and decided that
the following features were ready to be deemed stable for this release:

• PSConstrainedAuditLogging
  This feature enables PowerShell 7 to adhere to WDAC Audit mode and log events into the Windows Event Log.
  In this mode, PowerShell runs scripts in Full Language Mode, but logs events if there would be
  a difference in behavior in System Lockdown mode.
  This makes it easier for administrators to deploy PowerShell 7 in environments that have System Lockdown mode enabled
  by understanding what scripts would need to be modified to run in that mode.
• PSCustomTableHeaderLabelDecoration
  A common feedback from users is that with objects rendered as tables, it was not clear when a header
  label was not a property of the object.
  For example, when using Get-Process, you’ll see a column with the header CPU(s) to indicate the
  amount of cpu seconds used by that process.
  However, if you tried to access that property, you would find it’s actually called just CPU and the (s)
  was added to the header to indicate that it was in seconds.
  This new feature allows you to decorate the header label to make it clear that it is not a property of the object.
  The default decoration simply renders the header label in italics.
• PSWindowsNativeCommandArgPassing
  This is continuation of a feature we first added in 7.3.
  A major difference between Windows and non-Windows is how arguments are parsed particularly when quotes are involved.
  As more Open Source command-line tools are being used on Windows, we want to make sure that PowerShell
  can pass arguments to those tools in a way that works as expected.
  However, many legacy command-line tools on Windows do not handle arguments in the industry standard way.
  As such, a Windows mode for $PSNativeCommandArgumentPassing special cases some known tools to fallback to how
  it worked with Windows PowerShell while modern tools the new Standard mode.
  A Legacy mode is available for those that need to support legacy tools that do not work with the Windows mode.
• PSNativeCommandErrorActionPreference
  This is another continuation of a feature we first added in 7.3.
  This feature allows you to treat a non-zero exit code from a native command as an ErrorRecord that would come from a cmdlet.
  This allows you to set $ErrorActionPreference to Stop and have PowerShell stop execution whether a cmdlet had an error
  or a native command had a non-zero exit code.
  This simplifies scripts that previously would have to check $LASTEXITCODE after execution of a native command or wrap it in a helper function.
• PSNativeCommandPreserveBytePipe
  This feature allows you to preserve the byte stream when piping to or from a native command.
  Previously, all streams were converted to strings when piping to or from a native command and thus lost the original byte stream.
  This is useful for tools that expect binary input such as tar or zip.

There are still a number of experimental featues in this release pending additional user feedback before we can promote them to stable.
For example, we continue to iterate on the Feedback Provider
model as we get more feedback from users and partners who implement it.

Breaking changes

There are a few Breaking Changes
in this release that you should be aware of although we expect them to be rare.

One that could affect some users is the new -ProgressAction common parameter.
Similar to other common parameters, the new -ProgressAction parameter is automatically available to cmdlets and advanced functions.
This parameter allows you to control how progress is reported for a cmdlet or advanced function call.
Previously, you would have to set $ProgressPreference to SilentlyContinue to suppress progress and then restore it to its previous value.

What’s Next?

We will continue to focus on making PowerShell a great shell environment next year with PowerShell 7.5.
As usual, we’ll continue to address issues and bugs reported by our community and partners as well as adopt the latest .NET 9 preview releases.
Specific team investments will be discussed in a separate blog post early next year.

Thanks again to our community and partners for their continued support and feedback!

The post PowerShell 7.4 General Availability appeared first on PowerShell Team.

This post was originally published on this site

PowerShell 7.4 RC-1 is now available

We’re proud to announce the availability of PowerShell 7.4.0-rc.1!
This is the first release candidate version of PowerShell 7.4 and is considered a “go-live” release
meaning that it is a supported release in production.
Now is the time to test out PowerShell 7.4 in your environment.
PowerShell 7.4 is built on top of .NET 8 and as a LTS (Long Term Support) release will be supported for 3 years.

How do I get it?

Since PowerShell 7 is supported on Windows, Linux, and macOS, there are a variety of ways to get it.
If you had installed the previous PowerShell 7.4 preview release (7.4.0-preview.6) via the Windows Store or MSI (and opted into Microsoft Update),
you will be automatically updated to 7.4.0-rc.1.

Note that after releases there are some delays in all release channels getting the latest bits.
If this version is not available on your release channel of choice expect it to be available
within 2 weeks.

What’s new in this release?

• PSResourceGet is now GA and has reached a 1.0.0 version in this release– for more info on this module release check out this blog post
• PSReadLine has been incremented to a new feature version 2.3.4– for more info on this module release check out this blog post
• This release also contained a number of bug fixes– for the full list of changes please refer to the changelog

For more info on what’s changed in PowerShell 7.4, check out this page of the documentation.

Experimental Features which were made stable for 7.4

The following features were developed and released as experimental during the PowerShell 7.4
previews. Through telemetry and user feedback we determined that they should
be available as non-experimental features in the 7.4 release.

• PSConstrainedAuditLogging
• PSCustomTableHeaderLabelDecoration
• PSWindowsNativeCommandArgPassing
• PSNativeCommandErrorActionPreference
• PSNativeCommandPreserveBytePipe

What’s next?

PowerShell 7.4 will be our next LTS release and expected to ship once an RC is determined to be ready.
We’ll have a separate blog post when the GA release of 7.4 becomes available.
We appreciate all the efforts of the community, both individuals and working group members,
and look forward to your continued feedback and contributions!

Sydney
PowerShell Team

The post PowerShell 7.4 Release Candidate 1 appeared first on PowerShell Team.