PowerShellGet version 1.5.0 has added support for module publishers to require explicit license acceptance from users before installing a module. This feature has been requested by several of our partners, in order to meet their legal requirements.

If a user installs, updates, or saves a module using PowerShellGet, and the publisher of that module requires the user to agree to a license, the user must indicate they accept the license or the operation fails. This works whether the module is installed directly or if it is installed because it is a dependency for another module.

Publishing Requirements for Modules

Publishers that would like to require license acceptance for their modules should fulfil the following requirements:

1. Set RequireLicenseAcceptance = $True in PSData section of module manifest.
2. Add license.txt in root directory of module.
3. Include License Uri in module manifest.

Install-Module, Save-Module, Update-Module

The PowerShellGet commands Install-Module, Save-Module, and Update-Module have all been modified to support license acceptance. When run, the command will show the license terms from license.txt and prompt the user to accept the license. Module will be delivered to the user system only if the user accepts the license terms. An example using Install-Module is shown below:

Install-Module, Save-Module, and Update-Module support a new parameter -AcceptLicense. This enables scripting, as users will not be prompted if -AcceptLicense is specified. Users who specify this flag are accepting all license terms for all modules that are installed when their command is run, including modules that are installed as dependencies.

-Force

Specifying -Force is NOT sufficient to accept a license. -AcceptLicense is required for permission to install. If -Force is specified and -AcceptLicense is not specified and license acceptance is required, the operation will fail.

Scripts Cannot Require License Acceptance

License Acceptance is not available for publishers to use with scripts. The feature requires a separate license.txt file, and scripts are published as single files. However, the scenario where a script depends on a module that requires license acceptance is supported. Save-Script, Install-Script, Update-Script will show license.txt for dependent modules(that require license acceptance) and prompt user to accept the license. They also support -AcceptLicense parameter.

Additional Resources

The documentation for this feature is included in the PowerShellGet documentation.

We always welcome and appreciate your feedback. The best places to give feedback for these changes are in the PowerShellGet Github Issues, and in Uservoice area for the PowerShell Gallery.

Fareha Rashid
PowerShell Community and Tools

The security industry is ablaze with news about how PowerShell is being used by both commodity malware and attackers alike. Surely there’s got to be a way to defend yourself against these attacks!

There absolutely is. PowerShell is – by far – the most securable and security-transparent shell, scripting language, or programming language available.

Our recommendations are:

1. Deploy PowerShell v5, built into Windows 10. Alternatively, you can deploy the Windows Management Framework, available down to and including Windows 7 / Windows Server 2008r2.
2. Enable, and collect PowerShell logs, optionally including Protected Event Logging. Incorporate these logs into your signatures, hunting, and incident response workflows.
3. Implement Just Enough Administration on high-value systems to eliminate or reduce unconstrained administrative access to those systems.
4. Deploy Device Guard / Application Control policies to allow pre-approved administrative tasks to use the full capability of the PowerShell language, while limiting interactive and unapproved use to a limited subset of the PowerShell language.
5. Deploy Windows 10 to give your antivirus provider full access to all content (including content generated or de-obfuscated at runtime) processed by Windows Scripting Hosts including PowerShell.

For further information about these steps and solutions, please see the much more detailed presentation: “Defending Against PowerShell Attacks“.

You can also download the slide deck used for this video: Defending-Against-PowerShell-Attacks.

For further details about PowerShell’s Security features, please see our post: PowerShell ♥ the Blue Team.
For further details about implementing Just Enough Administration, please see http://aka.ms/jeadocs.

Lee Holmes [MSFT]
Lead Security Architect
Azure Management

Today we would like to share a new flexible pricing strategy for managing server nodes using Azure Automation to deliver PowerShell Desired State Configuration, giving you greater control over costs of managing on-premises nodes.

As you might already know, Azure Automation DSC (Azure DSC) is a managed service that is free when used to manage virtual machines running in Microsoft Azure. This provides the functionality of the in-box DSC Pull server without needing to maintain a server to host the capability, plus a lot of additional features. Some of the goodies that you get with Azure DSC are as follows:

Features include

• Configuration as Code hosted service (no infrastructure for you to manage)
• Highly Scalable with no database maintenance tasks or tuning required
• Complete management experience including GUI, ARM API, and command line tools
• All configuration data is encrypted in transit and at rest
• Encryption and certificate management is automated across clients
• Central store for maintaining environment variables and secrets such as credentials
• Detailed node status reporting to the per-resource level
• Centrally manage client settings such as intervals, automatic reboots, and automatic drift correction
• Centrally diagnose configuration errors from a browser
• Highly extensible to custom scenarios through integration with Automation Runbooks
• Fast release cycle so you get new features and fixes faster
• Integration with the Log Analytics service in OMS for detailed reporting and alerting, including notifications to a mobile app
• And the most recent feature announced at Ignite 2017 – Canary releases to groups of server nodes

Now, Azure DSC will only charge you when a node communicates with the service (and keep in mind, there is no charge to use the DSC Pull Service for nodes running in Azure). Ok, so what counts as a node communicating with the service? Pulling configurations, pulling resources, and sending reports. Since DSC gives you the ability to control how often a node communicates with the service, you can control how much you pay per node per month.

The pricing breakdown for Azure DSC is $.0083 / node / hr with a maximum of $6 / node / month.

Let’s look at a couple of example scenarios and what it will mean in terms of how much you will pay per node per month.

Example scenarios

Starting with your on-premises business-critical servers, you might wish to have the maximum level of visibility in to the state of the machine, which is to say, has the machine drifted from the configuration you assigned. By default, the node will report every 15 minutes which would reach the maximum cost during months with 31 days, meaning you would pay a total of $6 for managing the configuration of that server during that month. The same would be true for business critical servers running in other cloud environments, such as Azure AWS or Google Cloud.

Now let’s envision a node where 15-minute reporting interval is unnecessary. Consider a file server at a remote office location where changes rarely occur to the system configuration and a daily report that verifies the machine follows the configuration you assigned is sufficient.

To set up DSC this way, you will change the following properties in the meta-configuration, assuming the node is already configured to communicate with AA DSC:

ConfigurationModeFrequencyMins 	= 1440
RefreshFrequencyMins 		= 1440

With DSC configured this way, your normal charge would be for 1 hr per day of usage per node.On a monthly basis, one hour per day would be $0.25 per node per month.

Similarly, let’s say your requirements are to confirm only once per week that the server has not changed and is still in compliance with the assigned configuration. This would mean setting the meta-configuration with the following values:

ConfigurationModeFrequencyMins 	= 10080
RefreshFrequencyMins 		= 10080

With DSC configured this way, your normal charge would be for 1 hr per week of usage per node.On a monthly basis, one hour per week would be $0.036 per node per month.

The billing granularity is for one hour, so the machine can reconnect within that same hour within incurring additional charges (such as if a new configuration has been published). Outside of the scheduled cycle, the other trigger to connect with the service would be a reboot, which would impact the predicted costs per month.

If you decide to add additional management services such as Inventory or Change Tracking, the cost returns to $6 per month plus the storage of data in your OMS workspace.

Multiple Options

As you can see from the above examples, without any additional automation or processes, you can make use of AA DSC and all its features and benefits while giving you greater control over how much you pay per month.

We do recognize that some customers require their network to operate in isolation so we will continue to support the in-box pull server that shipped in Windows Server 2012R2 and 2016. There are also community maintained Pull Service solutions such as Tug. For customers that can utilize a whitelisted IP range for network traffic but where concerned about the cost of a cloud service to manage configuration of on-premises nodes, hopefully this greater degree of control will allow more organizations to reap the benefits of AA DSC.

For more on setting up and using Azure Automation DSC see our documentation.

Michael Greene
Principle Program Manager
Microsoft PowerShell Desired State Configuration

PowerShell Core 6 Release Candidate

Last year, we announced that PowerShell was not only Open Source, but also cross platform.  The finish line is in sight and we recently published the Release Candidate for PowerShell Core 6!

PowerShell Team ♥ Community

It has been an amazing experience for the team working with the community on PowerShell Core 6!  Being able to work openly and transparently meant that we could address customer concerns much more quickly than in the days of Windows PowerShell.  The contributions from the community have also enabled PowerShell Core 6 to be more agile and richer in capability, particularly for cmdlets.  In fact, the community has contributed just over half of the pull requests (PRs)!

This really shows the benefit of Open Source and an active community and we certainly wouldn’t have gotten as far as we have without such a passionate and helpful community!

Roadmap to General Availability and the Future

When the PowerShell Team started working through all the work required to publish a release, we also created a branch for the eventual PowerShell Core 6.0.0 final release.  There are still some issues and work items needed to be completed for the GA (General Availability) release.  General Available simply means a supported release (replaces the legacy term Release to Manufacturing!).

This means that any changes merged to the master branch will show up in the 6.1.0 release.  I encourage the community to continue to make contributions to PowerShell Core with the expectation that it will be part of 6.1.0 and not 6.0.0.  Only issues (and associated pull requests) approved for 6.0.0 GA with milestone set to `6.0.0-GA` will be taken for the 6.0.0 release.

If you find any deployment or adoption blockers, please open issues on GitHub (or up vote existing ones with a thumbs up) and mention me (using `@SteveL-MSFT`) so I will be notified and those issues will be triaged and a decision will be made if we need to make or take a fix before 6.0.0 GA.

We are currently targeting having the GA release on January 10th, 2018.

The first PowerShell Core 6.1.0 beta release will be published after PowerShell Core 6.0.0 GA and we plan to continue a 3 week cadence for beta releases.  Note that if you use the install-powershell.ps1 script to install daily builds, it will be from the master branch (aka 6.1.0) and not from our 6.0.0 Release Candidate or GA.

PowerShell Core 6 Support

PowerShell Core 6.0.0 will adopt the Microsoft Modern Lifecycle for support.  Essentially, this means that barring any critical security fixes, customer are expected to install the latest released version of PowerShell Core.  In general, if you find an issue, please open it on GitHub.  We’ll be providing more information on the specifics of this lifecycle and what it means for PowerShell Core soon.

Thanks to everyone for their support and contributions!

Steve Lee
Principal Engineer Manager
PowerShell Team

When DSC was announced at TechEd 2013, one of the goals was to “Create an ecosystem”.

The ecosystem for DSC has grown tremendously in the last 4 years.

At worldwide events for PowerShell (PowerShell + DevOps Global Summit, PowerShell Conference EU, PowerShell Conference Asia) there have been presentations lead by people actively using DSC to discuss real world, success, challenges, and community projects to resolve common issues. In addition there are community projects to build solutions for DSC entirely driven by the community, such as Datum to manage configuration data at scale, BaselineManagement to convert Group Policy to DSC configurations, and ReverseDSC to replicate known environments.

The PowerShell Gallery includes 1100 DSC Resources across 254 unique modules. Of those 1100 DSC Resources, 411 are currently released by the DSC team from the DSC Resource Kit.

During events and the monthly DSC Resource Kit community calls over the past year, I have heard consistently that the naming convention for DSC Resources is ready for an update. Most notably, the experimental “x” prefix and HQRM guidance could be confusing and does not match the approach used in other similar community ecosystems.

The Old Naming Convention

The original recommendation was to name resources using the following prefixes:

• “x” to identify a resource that is experimental and not supported
• “c” to identify a community modification

Resources that met a community agreed upon quality bar, or “High Quality Resource Modules”, have been using a naming suffix “Dsc”.

The New Naming Convention

The community has discussed and agreed upon a new simplified standard, explained in a recent update to the documentation.

DSC Resources going forward are no longer required to use the “x” or “c” naming conventions.

Instead, the guideline is that resources should use either the existing module name (if DSC Resources are combined with an existing module containing PowerShell functions) or the “Dsc” suffix. The best practices for finding a DSC Resource module is to search the PowerShell Gallery using the “DSC Resource” filter, or use the cmdlet:

Find-DscResource

The project name will not have any relationship with how or whether the project is supported. The documentation merged today also addresses this topic.

Why is it the right time to make this change

This is only possible because the DSC community, especially the DSC Resource project maintainers, are so passionate and actively working with DSC users to make the ecosystem better for everyone. The maintainers hold each other accountable to quality and technically enforce this through test automation.

The first community contributions to the DSC Resource Kit contained only the PowerShell code for the DSC module. The expectation for a contribution today includes following best practices, style guidelines, documentation, and test automation to demonstrate quality. As an example, the SharePointDsc module includes 2102 tests that must pass to accept a new contribution, and anyone can review the results of a new build. Similarly, SQLServerDsc includes 2507 tests (and has already adopted the new naming standard), xWebAdministration has 1032, and xActiveDirectory includes 653.

How do I know if a DSC Resource is supported

The old naming convention using “x” and “c” prefixes required users to modify their code when switching from experimental to stable versions of a module.  Support for DSC Resources should come from the organization supporting the technology that is being managed. The best way to make that clear is to express it in the project Readme. Just as someone interested in consuming the resource should review the project code and make sure it is suitable for their environment, they should review the entire project documentation.

When will this change happen

Finally, this change does not need to be implemented “overnight”. As maintainers release future versions of their projects and determine they are ready, they can choose to retire the “x” convention. The PowerShell Gallery will provide access to future releases by the new name and the history of previous releases by the old name. The project repository will be the source of truth.

Thank you! 
Michael Greene @migreene 
Principal Program Manager 
PowerShell DSC, Azure Automation DSC, and Azure Management Community

The release of PowerShell Core 6.0 is only the beginning and we are already thinking about the next leg of our journey.

Most of the effort of the team with PowerShell Core 6.0 was in these areas:

• Learning how to work in an Open Source project (and we are still learning)
• Complete the port of PowerShell to CoreCLR
• Add test coverage for PowerShell Core
• Build/integrate tooling for automating builds, packaging, test execution, and releases

The community did some amazing work to add new capabilities in both the engine as well as cmdlets!

If you participated in the January 2018 Community Call you already got an early preview of this content.

Timeline

First, we’re publishing PowerShell Core 6.0.1 as a servicing release by the end of January in order to update to .NET Core 2.0.5.  There are no other changes in the 6.0.1 release.

After that, the plan going forward is to have new supported minor releases every 6 months.  This means that we’re targeting a late June,  early July 2018 release for PSCore 6.1.

We will continue to have preview releases approximately every 3 weeks.

RFCs for new features we plan to deliver will be published in February.

Milestone Quality

There’s some work that we deferred and will be a focus to be completed in February:

• Complete PowerShell Standard SDK – including guidance on converting Windows PowerShell modules to portable modules that are also PowerShell Core compatible
• Author documentation in the Docs Repo for issues/PRs labeled with Documentation Needed
• Backport changes in PowerShell Core 6.0 to Windows PowerShell 5.1 for issues/PRs labeled with Consider-WindowsPowerShell51
  • Note that depending on the risk of the change,
    even if an issue/PR has this labeled,
    it doesn’t guarantee it’ll be backported
• Enable automated test runs for all supported distros/platforms
• Build infrastructure and tooling for cross system remoting tests
• Have consistency and meet compliance requirements for the following repos:
  • PSEditorServices
  • VSCode-PowerShell
  • PSScriptAnalyzer
  • Archive Module
  • PSRP WSMan Client for non-Windows

New Features

Being an open source project means that different people can invest in different priorities and submit their changes via pull requests,  these are the areas that the PowerShell team will be focusing on.  Some of these will be complete while others may be just the start of something bigger.

Security Parity with Windows PowerShell

The original port of PowerShell stubbed out support for DeviceGuard/AppLocker because those APIs were not available on Nano Server.  This work will ensure that DeviceGuard/AppLocker policies are enforced in PowerShell Core 6.0 on Windows systems.

Run Signed Script Blocks Remotely

PowerShell supports restricting access using constrained language mode and only allowing signed scripts with a trusted certificate to run with Full Language mode.  This new capability will allow using Invoke-Command to remotely execute a signed script block on a target locked down system with Full Language mode.

Windows PowerShell Compatibility Pack

With the announcement of the Windows Compatibility Pack for .NET Core for .NET Core, PowerShell Core will regain some APIs that had been dropped in the transition to .NET Core.  This means we can re-enable some cmdlets that weren’t part of the PowerShell Core 6.0 release: WMI, EventLog, and PerfCounters.  In addition, some highly requested APIs will be available which means that some existing Windows PowerShell modules might just work in PowerShell Core 6.0.  This module will replace the WindowsPSModulePath module to add the Windows PowerShell $env:PSModulePath to PowerShell Core 6.0.  Finally, we can use this module to optionally add back some aliases that we removed from PowerShell Core 6.0 that exist in Windows PowerShell.

Concurrency in PowerShell Script

You can do threading today in PowerShell using runspaces, however, it may be complex for some users.  Rather than spend time creating something from scratch, we’re evaluating two existing modules that might already meet our needs:

• PSThreadJob created by one of engineers on my team, Paul
• PoshRSJob created by a PowerShell MVP, Boe

PSReadLine 2.0 GA

PSReadLine is our default interactive experience on Windows PowerShell 5.1 and PowerShell Core 6.0.  This is a side project by Jason Shirk who recently put out a Beta1 release of 2.0. Some of my engineers will be spending time contributing to this project to get it to production quality so we can include it in PowerShell Core 6.0.

Machine Learning and PowerShell

A new area that we want to explore is leveraging the cloud and machine learning to provide inline suggestions at the interactive command-line.  The two primary scenarios I want to target is to support both local and cloud based suggestions. This is a completely new area for the team so expect the initial release to be limited, but something we can build upon going forward.

An RFC will be published for this feature.

Experimental Feature Flags

As we build new capabilities, some features may not be fully complete where we don’t have sufficient community feedback. Being experimental, we may make large design changes that would not be backwards compatible. Users can choose to not use these features by not opting into turning on these feature flags.  Feature flags can also allow us to have two different implementations of the same feature (that could not work side-by-side) and collect feedback that way.

An RFC will be published for this feature.

HelpSystem as a Module

This is the start of a bigger work item to componentize PowerShell so that we can have a smaller distribution of PowerShell Core for managed targets that don’t need all of the interactive experience components.

PowerShell help content today is written in XML.  However, our docs are maintained as Markdown and we have platyPS that converts the Markdown to XML.  We want to remove the need to convert to XML and have the HelpSystem use Markdown natively.  After this work is done, the help system would still be included with the general distribution of PowerShell Core as an independent module.

An RFC for this has already been published.

Markdown Rendering Support

In addition to help being in Markdown natively, we would like to be able to render in the console any Markdown.  For example, error messages or script output can leverage Markdown to provide emphasis.  Initially there will be limited rendering support, but this is something we can improve over time.  For example, eventually supporting plug-able syntax highlighting for code fencing.

An RFC will be published for this feature.

Enable sudo to Work Over PowerShell Remoting (for non-Windows)

On Unix-based systems, administrators use sudo to elevate themselves to run administrator tasks requiring higher privilege.  Due to how sudo works, PowerShell remoting is not able to pass the request for the administrator password prompt from sudo.  Note that sudo works perfectly fine locally in PowerShell Core 6.0.

Enable-SSHRemoting

PowerShell includes a Enable-PSRemoting command on Windows to make it easy to enable PowerShell remoting over WSMan using WinRM.  This feature adds a new Enable-SSHRemoting command that would initially identify missing dependencies (like OpenSSH) and also configure sshd_config to enable PowerShell remoting over SSH.

An RFC for this has already been published.

PowerShell Module for IoT (Internet of Things)

PowerShell Core 6.0 has experimental support for ARM systems running Windows 10 IoT or Raspbian (Stretch).

To help bootstrap the community to develop more interesting uses for IoT using PowerShell, we want to provide the start of a module to enable using PowerShell script to interact with sensors attached to your IoT device.  We would then work with the community to increase capability of this module over time.

An RFC will be published for this feature.

Closing

As you can see, we have a large set of work ahead of us for the 6.1 release.

The feature set was decided based on:

• Existing customer feedback or known customer pain points
• Driving towards longer goals through strategic investments
• Specific partner/customer asks
• Interests within the PSCore engineering team

The next 6 months will be lots of work, but it’ll also be fun.  I also expect the community to continue to contribute new features beyond this list for 6.1.  My team will continue to fix bugs, respond to issues, review PRs, and merge PRs while working on 6.1.

Please feel free to provide feedback on the PowerShell Core 6.1 Roadmap via GitHub!

Steve Lee
Principal Engineering Manager
PowerShell

In September 2017 we communicated some of our plans for PowerShell Desired State Configuration (DSC). Over the past few months, we have been executing on these plans and collecting feedback from customers and partners. The intent of this blog is to provide an update on the plans we shared back in September. I will have additional posts in the near future to discuss updates for Azure DSC Extension and Windows Pull Server.

Specifically:

• What is the relationship between the next version of DSC and PowerShell Core?
• Will DSC be Open Source?
• What does this mean for my skillset and my existing projects?

We appreciate the continued feedback and look forward to working with the DSC community to make incremental improvements as we progress together.

What Are We Trying to Achieve?

The mission for DSC is to provide a platform for server configuration management that is maintained together with the community, releasing at an agile cadence, to meet the demands of hybrid cloud environments.

Local Configuration Manager (LCM)

LCM is the engine that runs DSC so it is a logical place for us to start work on a new version. For DSC in Windows, this shipped in Windows Server 2012 R2 and later and has been updated through the WMF release cycle.

The work going on by the DSC team since the last major update has been focused on making LCM a small, lightweight, cross-platform, and portable engine that can meet the requirements for cloud management capabilities long term. In fact, the new codebase is already in use by some of the Management services available in Azure such as Inventory and Change Tracking, and is scaling to hundreds of thousands of servers.

The team’s plan is to make LCM an open source project in GitHub within the next 12 months. We want to make sure we are prepared when we reach that milestone. Our team has gained experience through management of many open source projects including the DSC Resource community and from shipping PowerShell Core as an open source language. We understand that the onramp to open source projects includes a complex set of requirements, so we can be respectful and responsive to community contributions. We are working through creation of the repository with the appropriate assets such as governance and documentation.  I will have more to share in a few months at the PowerShell Summit events happening around the world.

Initially, the new LCM would be distributed as compiled binaries via GitHub releases and through Azure Services. It will need to be installed on systems where the current DSC platform exists today, and we will need to offer conflict detection across versions.

To be crystal clear, we do not plan for LCM to require .NET, .NET Core, or PowerShell Core. The project is written in C++ and will be able to be compiled for multiple platforms.

Provider Model

The community has been providing valuable feedback regarding backward compatibility with existing DSC Resources. To deliver DSC provided by LCM, we anticipate a provider model with the ability to work with multiple languages.

To make sure we are not creating unnecessary work for community maintainers, the first implementation of the provider model for LCM will be Windows PowerShell. This means that in the future a new open source LCM would be able to manage configurations that include the existing community-maintained DSC Resources authored using Windows PowerShell. Our intention is that no changes to the resources will be required.

We also expect to have LCM providers for PowerShell Core, C++, and Python. These providers will introduce the ability to Get/Set/Test across Windows, Linux, and MacOS, by a common LCM.  Leveraging cross-platform languages, authors will have the opportunity to create DSC resources that can be used on multiple operating systems. For resources written in PowerShell Core, there are built-in Boolean variables $IsWindows, $IsLinux, and $IsMacOS that will simplify OS detection for resource authors.

Feature Backlog

The feedback in User Voice will not be lost as we transition to the new project. Examples of top requests include support for maintenance windows, intermediate state, sharing information between resources, and support for managed service accounts. These will be moved to GitHub to be the top items in the new DSC project and we will carry forward any existing work in these areas.

What is The Impact?

By following a provider model that can leverage Windows PowerShell and multiple other languages, we honor our commitment to existing versions of Windows, while introducing new choices such as the latest versions of PowerShell.  The development of your skillset around DSC and the investment you have made in custom resources will carry forward, while enabling more agility to releasing incremental updates and the features you have requested.

Feedback

We look forward to hearing your feedback and suggestions. Please leave blog comments here, or via Twitter using tag #PSDSC. I look forward to more in depth conversation in the DSC forum, PowerShell User Groups, and the community-led PowerShell Summits in 2018.

Michael Greene
@migreene
Principal Program Manager
Microsoft PowerShell DSC and Azure Configuration Management

This is the first a set of posts which will help you take advantage of a new Nuget package PowerShellStandard Library 5.1.0. This package allows developers to create modules and applications which host the PowerShell engine which are portable between Windows PowerShell version 5.1 and PowerShell Core 6.0. This means that you can create PowerShell modules and applications which run on Windows, Linux, and Mac with a single binary!

In this post, I’ll walk through the steps for creating a simple binary module which has a single, (very) simple cmdlet. I will also be using the dotnet cli tools for creating everything I need.

First, we need create a project for our new module and create a project template:

PS> New-Item -Type Directory myModule

Directory: C:\Users\James\src\pwsh
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/26/2018 2:41 PM myModule

PS> Set-Location myModule
PS> dotnet new library
The template "Class library" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on C:\Users\James\src\pwsh\myModule\myModule.csproj...
 Restoring packages for C:\Users\James\src\pwsh\myModule\myModule.csproj...
 Generating MSBuild file C:\Users\James\src\pwsh\myModule\obj\myModule.csproj.nuget.g.props.
 Generating MSBuild file C:\Users\James\src\pwsh\myModule\obj\myModule.csproj.nuget.g.targets.
 Restore completed in 222.92 ms for C:\Users\James\src\pwsh\myModule\myModule.csproj.

Restore succeeded.

You can see that the dotnet cli has created a source file and .csproj file for my project. Right now they’re quite generic, but we can add a reference to the PowerShellStandard Library very easily:

PS> dotnet add package PowerShellStandard.Library --version 5.1.0-preview-02
 Writing C:\Users\James\AppData\Local\Temp\tmp2C8D.tmp
info : Adding PackageReference for package 'PowerShellStandard.Library' into project 'C:\Users\James\src\pwsh\myModule\myModule.csproj'.
log : Restoring packages for C:\Users\James\src\pwsh\myModule\myModule.csproj...
info : Package 'PowerShellStandard.Library' is compatible with all the specified frameworks in project 'C:\Users\James\src\pwsh\myModule\myModule.csproj'.
info : PackageReference for package 'PowerShellStandard.Library' version '5.1.0-preview-02' added to file 'C:\Users\James\src\pwsh\myModule\myModule.csproj'.
PS> get-childitem

Directory: C:\Users\James\src\pwsh\myModule
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/26/2018 2:42 PM obj
-a---- 3/26/2018 2:42 PM 85 Class1.cs
-a---- 3/26/2018 2:42 PM 259 myModule.csproj

if we inspect the .csproj file, we can see the reference

PS> Get-Content .\myModule.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
 <TargetFramework>netstandard2.0</TargetFramework>
 </PropertyGroup>
<ItemGroup>
 <PackageReference Include="PowerShellStandard.Library" Version="5.1.0-preview-02" />
 </ItemGroup>
</Project>

We can now implement our cmdlet in the Class1.cs file

PS> get-content Class1.cs
using System;
using System.Management.Automation;

namespace myModule {
  [Cmdlet("Get","Thing")]
  public class GetThingCommand : PSCmdlet {
    protected override void ProcessRecord() {
      WriteObject("GetThing");
    }
  }
}

We can now build, import the dll (as a module) and run our new cmdlet

PS> dotnet build
Microsoft (R) Build Engine version 15.5.180.51428 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Restoring packages for C:\Users\James\src\pwsh\myModule\myModule.csproj...
 Restore completed in 164.19 ms for C:\Users\James\src\pwsh\myModule\myModule.csproj.
 myModule -> C:\Users\James\src\pwsh\myModule\bin\Debug\netstandard2.0\myModule.dll

Build succeeded.
 0 Warning(s)
 0 Error(s)

Time Elapsed 00:00:03.16
PS> import-module .\bin\Debug\netstandard2.0\myModule.dll
PS> get-thing
GetThing

This is a completely portable module, I can load this from PowerShell 5.1 and run it without problem. Of course, we’ve barely scratched the surface, but you can see how this can get you started!

PowerShell Core 6 Release Candidate

Last year, we announced that PowerShell was not only Open Source, but also cross platform.  The finish line is in sight and we recently published the Release Candidate for PowerShell Core 6!

PowerShell Team ♥ Community

It has been an amazing experience for the team working with the community on PowerShell Core 6!  Being able to work openly and transparently meant that we could address customer concerns much more quickly than in the days of Windows PowerShell.  The contributions from the community have also enabled PowerShell Core 6 to be more agile and richer in capability, particularly for cmdlets.  In fact, the community has contributed just over half of the pull requests (PRs)!

This really shows the benefit of Open Source and an active community and we certainly wouldn’t have gotten as far as we have without such a passionate and helpful community!

Roadmap to General Availability and the Future

When the PowerShell Team started working through all the work required to publish a release, we also created a branch for the eventual PowerShell Core 6.0.0 final release.  There are still some issues and work items needed to be completed for the GA (General Availability) release.  General Available simply means a supported release (replaces the legacy term Release to Manufacturing!).

This means that any changes merged to the master branch will show up in the 6.1.0 release.  I encourage the community to continue to make contributions to PowerShell Core with the expectation that it will be part of 6.1.0 and not 6.0.0.  Only issues (and associated pull requests) approved for 6.0.0 GA with milestone set to `6.0.0-GA` will be taken for the 6.0.0 release.

If you find any deployment or adoption blockers, please open issues on GitHub (or up vote existing ones with a thumbs up) and mention me (using `@SteveL-MSFT`) so I will be notified and those issues will be triaged and a decision will be made if we need to make or take a fix before 6.0.0 GA.

We are currently targeting having the GA release on January 10th, 2018.

The first PowerShell Core 6.1.0 beta release will be published after PowerShell Core 6.0.0 GA and we plan to continue a 3 week cadence for beta releases.  Note that if you use the install-powershell.ps1 script to install daily builds, it will be from the master branch (aka 6.1.0) and not from our 6.0.0 Release Candidate or GA.

PowerShell Core 6 Support

PowerShell Core 6.0.0 will adopt the Microsoft Modern Lifecycle for support.  Essentially, this means that barring any critical security fixes, customer are expected to install the latest released version of PowerShell Core.  In general, if you find an issue, please open it on GitHub.  We’ll be providing more information on the specifics of this lifecycle and what it means for PowerShell Core soon.

Thanks to everyone for their support and contributions!

Steve Lee
Principal Engineer Manager
PowerShell Team

This is the first a set of posts which will help you take advantage of a new Nuget package PowerShellStandard Library 5.1.0. This package allows developers to create modules and applications which host the PowerShell engine which are portable between Windows PowerShell version 5.1 and PowerShell Core 6.0. This means that you can create PowerShell modules and applications which run on Windows, Linux, and Mac with a single binary!

In this post, I’ll walk through the steps for creating a simple binary module which has a single, (very) simple cmdlet. I will also be using the dotnet cli tools for creating everything I need.

First, we need create a project for our new module and create a project template:

PS> New-Item -Type Directory myModule

Directory: C:\Users\James\src\pwsh
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/26/2018 2:41 PM myModule

PS> Set-Location myModule
PS> dotnet new library
The template "Class library" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on C:\Users\James\src\pwsh\myModule\myModule.csproj...
 Restoring packages for C:\Users\James\src\pwsh\myModule\myModule.csproj...
 Generating MSBuild file C:\Users\James\src\pwsh\myModule\obj\myModule.csproj.nuget.g.props.
 Generating MSBuild file C:\Users\James\src\pwsh\myModule\obj\myModule.csproj.nuget.g.targets.
 Restore completed in 222.92 ms for C:\Users\James\src\pwsh\myModule\myModule.csproj.

Restore succeeded.

You can see that the dotnet cli has created a source file and .csproj file for my project. Right now they’re quite generic, but we can add a reference to the PowerShellStandard Library very easily:

PS> dotnet add package PowerShellStandard.Library --version 5.1.0-preview-02
 Writing C:\Users\James\AppData\Local\Temp\tmp2C8D.tmp
info : Adding PackageReference for package 'PowerShellStandard.Library' into project 'C:\Users\James\src\pwsh\myModule\myModule.csproj'.
log : Restoring packages for C:\Users\James\src\pwsh\myModule\myModule.csproj...
info : Package 'PowerShellStandard.Library' is compatible with all the specified frameworks in project 'C:\Users\James\src\pwsh\myModule\myModule.csproj'.
info : PackageReference for package 'PowerShellStandard.Library' version '5.1.0-preview-02' added to file 'C:\Users\James\src\pwsh\myModule\myModule.csproj'.
PS> get-childitem

Directory: C:\Users\James\src\pwsh\myModule
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/26/2018 2:42 PM obj
-a---- 3/26/2018 2:42 PM 85 Class1.cs
-a---- 3/26/2018 2:42 PM 259 myModule.csproj

if we inspect the .csproj file, we can see the reference

PS> Get-Content .\myModule.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
 <TargetFramework>netstandard2.0</TargetFramework>
 </PropertyGroup>
<ItemGroup>
 <PackageReference Include="PowerShellStandard.Library" Version="5.1.0-preview-02" />
 </ItemGroup>
</Project>

We can now implement our cmdlet in the Class1.cs file

PS> get-content Class1.cs
using System;
using System.Management.Automation;

namespace myModule {
  [Cmdlet("Get","Thing")]
  public class GetThingCommand : PSCmdlet {
    protected override void ProcessRecord() {
      WriteObject("GetThing");
    }
  }
}

We can now build, import the dll (as a module) and run our new cmdlet

PS> dotnet build
Microsoft (R) Build Engine version 15.5.180.51428 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Restoring packages for C:\Users\James\src\pwsh\myModule\myModule.csproj...
 Restore completed in 164.19 ms for C:\Users\James\src\pwsh\myModule\myModule.csproj.
 myModule -> C:\Users\James\src\pwsh\myModule\bin\Debug\netstandard2.0\myModule.dll

Build succeeded.
 0 Warning(s)
 0 Error(s)

Time Elapsed 00:00:03.16
PS> import-module .\bin\Debug\netstandard2.0\myModule.dll
PS> get-thing
GetThing

This is a completely portable module, I can load this from PowerShell 5.1 and run it without problem. Of course, we’ve barely scratched the surface, but you can see how this can get you started!

In the next Current Branch release of Windows Server a new feature will be released to provide support for SQL Server as the database platform to support Windows Pull Server for DSC.

This capability will open new scenarios:

• High availability
• The SQL ecosystem of reporting and analysis tools

If you are a member of Windows Server Insiders you can test this now by downloading a preview build.

If you are unfamiliar with the pull service role for DSC, the documentation page has been updated with details regarding how to setup Windows Pull Server environments using the latest versions of the xDSCWebService resource. The key changes are introduction of properties SQLProvider and SQLConnectionString (link to code). There is no other change to the deployment and configuration process other than using the latest version of the resource and of course, having a SQL instance available. You do not have to pre-stage any tables, the resource handles that on the first request, and both SQL authentication and Windows authentication are supported.

Plans for DSC pull service

Previously I blogged about the plans we have for the DSC platform and committed to providing more information about the direction of DSC as a solution, including pull service.

Following this release of Windows Pull Server, there are no additional plans to release new features to the pull service capability in Windows Server. Support for Windows Pull Server in production environments will continue following the Windows Server support lifecycle. This does not change our plans to further invest in the DSC platform (detailed here).

The focus for new features in DSC pull service will be delivered in Azure Automation DSC.

Azure Automation DSC

The service already offers many features not available in Windows Pull Server including:

• All data is encrypted in transit and at rest
• Client certificates are created and managed automatically
• Secrets store for centrally managing assets such as secrets, variables, and service connections
• Centrally manage node LCM configuration
• Centrally assign configurations to client nodes
• Release configuration changes to “canary groups” for testing before reaching production
• Graphical reporting
• Status detail at the DSC resource level of granularity
• Verbose error messages from client machines for troubleshooting
• Integration with Azure Log Analytics for alerting, automated tasks, and a mobile app for reporting and alerting

We are working hard on new capabilities of this service and plan to introduce new features based on User Voice feedback, including:

• Managing Configuration Data at scale
• Simplify the onboarding experience and the process of authoring, especially for new users of DSC
• Integrate the Azure Automation DSC and Change Tracking / Inventory services in to a Azure Configuration Management platform
• Integrate Azure Automation DSC with Visual Studio Online

For customers who can leverage a cloud service for managing server nodes, this platform provides the highest degree of scalability and frequency of new features/capabilities.

With the latest licensing update, this service is available to manage server nodes on Azure for no additional charge, and for on-premises nodes the pricing is flexible based on the LCM configuration.

Also, on-premises nodes do not require broadly scoped open Internet access to be managed by Azure Automation DSC. Customers can whitelist only the Azure public IP endpoints We also plan to ship the ability to use http proxy in future releases of Local Configuration Manager.

Community maintained solutions for pull service

We have documented the pull service protocol and encourage continued development of open source implementations of DSC pull service maintained by the community.

There are two open source projects currently implementing pull service in unique approaches:

• Tug provides a web service backed by PowerShell scripting so any action can be taken as a result of a request.
• Traek is an implementation of pull service in Node.js with intention to host the solution on Kubernetes.

There is no intention at this time to publish the source code for the Windows Pull Server that is shipping in Windows Server.

Using DSC in isolated environments

For customers that require total isolation from public cloud service, there are options available to continue using the existing skillset and custom resources.

• The implementation of pull service in Windows Server 2012 R2 and 2016 will continue to be supported
• A release pipeline environment working with DSC in push mode, possibly combined with Windows Pull Server to deliver modules and reporting
• Contribute to community implementations of pull service protocol such as Tug and Traek
• We will continue to work with DSC partners such as Chef, Puppet, and Ansible, who offer a rich ecosystems of tools and can utilize DSC resources

Thank you,
Michael Greene
Principal Program Manager
Microsoft Desired State Configuration
@migreene