Quantcast
Channel: PowerShell
Viewing all 1519 articles
Browse latest View live

DSC Resource Kit Release April 2017

$
0
0

We just released the DSC Resource Kit!

This release includes updates to 5 DSC resource modules, including 3 new DSC resources. In these past 6 weeks, 57 pull requests have been merged and 46 issues have been closed, all thanks to our amazing community!

The modules updated in this release are:

  • PSDscResources
  • xCertificate
  • xDatabase
  • xPSDesiredStateConfiguration
  • xSQLServer

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

Our last community call for the DSC Resource Kit was last week on April 12. A recording of our updates as well as summarizing notes are available. Join us next time on May 24 to ask questions and give feedback about your experience with the DSC Resource Kit. Keep an eye on the community agenda for the link to the call.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

All resources with the ‘x’ prefix in their names are still experimental – this means that those resources are provided AS IS and are not supported through any Microsoft support program or service. If you find a problem with a resource, please file an issue on GitHub.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or Changelog.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
PSDscResources 2.6.0.0
  • Archive:
    • Fixed a minor bug in the unit tests where sometimes the incorrect DateTime format was used.
  • Added MsiPackage
xCertificate 2.5.0.0
  • Fixed issue where xCertReq does not process requested certificate when credentials parameter set and PSDscRunAsCredential not passed. See issue
xDatabase 1.6.0.0
  • Moved internal functions to a common helper module
xPSDesiredStateConfiguration 6.2.0.0
  • xMsiPackage:
    • Created high quality MSI package manager resource
  • xArchive:
    • Fixed a minor bug in the unit tests where sometimes the incorrect DateTime format was used.
  • xWindowsFeatureSet:
    • Had the wrong parameter name in one test case.
xSQLServer 7.0.0.0
  • Examples
    • xSQLServerDatabaseRole
      • 1-AddDatabaseRole.ps1
      • 2-RemoveDatabaseRole.ps1
    • xSQLServerRole
      • 3-AddMembersToServerRole.ps1
      • 4-MembersToIncludeInServerRole.ps1
      • 5-MembersToExcludeInServerRole.ps1
    • xSQLServerSetup
      • 1-InstallDefaultInstanceSingleServer.ps1
      • 2-InstallNamedInstanceSingleServer.ps1
      • 3-InstallNamedInstanceSingleServerFromUncPathUsingSourceCredential.ps1
      • 4-InstallNamedInstanceInFailoverClusterFirstNode.ps1
      • 5-InstallNamedInstanceInFailoverClusterSecondNode.ps1
    • xSQLServerReplication
      • 1-ConfigureInstanceAsDistributor.ps1
      • 2-ConfigureInstanceAsPublisher.ps1
    • xSQLServerNetwork
      • 1-EnableTcpIpOnCustomStaticPort.ps1
    • xSQLServerAvailabilityGroupListener
      • 1-AddAvailabilityGroupListenerWithSameNameAsVCO.ps1
      • 2-AddAvailabilityGroupListenerWithDifferentNameAsVCO.ps1
      • 3-RemoveAvailabilityGroupListenerWithSameNameAsVCO.ps1
      • 4-RemoveAvailabilityGroupListenerWithDifferentNameAsVCO.ps1
      • 5-AddAvailabilityGroupListenerUsingDHCPWithDefaultServerSubnet.ps1
      • 6-AddAvailabilityGroupListenerUsingDHCPWithSpecificSubnet.ps1
    • xSQLServerEndpointPermission
      • 1-AddConnectPermission.ps1
      • 2-RemoveConnectPermission.ps1
      • 3-AddConnectPermissionToAlwaysOnPrimaryAndSecondaryReplicaEachWithDifferentSqlServiceAccounts.ps1
      • 4-RemoveConnectPermissionToAlwaysOnPrimaryAndSecondaryReplicaEachWithDifferentSqlServiceAccounts.ps1
    • xSQLServerPermission
      • 1-AddServerPermissionForLogin.ps1
      • 2-RemoveServerPermissionForLogin.ps1
    • xSQLServerEndpointState
      • 1-MakeSureEndpointIsStarted.ps1
      • 2-MakeSureEndpointIsStopped.ps1
    • xSQLServerConfiguration
      • 1-ConfigureTwoInstancesOnTheSameServerToEnableClr.ps1
      • 2-ConfigureInstanceToEnablePriorityBoost.ps1
    • xSQLServerEndpoint
      • 1-CreateEndpointWithDefaultValues.ps1
      • 2-CreateEndpointWithSpecificPortAndIPAddress.ps1
      • 3-RemoveEndpoint.ps1
  • Changes to xSQLServerDatabaseRole
    • Fixed code style, added updated parameter descriptions to schema.mof and README.md.
  • Changes to xSQLServer
    • Raised the CodeCov target to 70% which is the minimum and required target for HQRM resource.
  • Changes to xSQLServerRole
    • BREAKING CHANGE: The resource has been reworked in it”s entirely.* Below is what has changed.
    • The mandatory parameters now also include ServerRoleName.
    • The ServerRole parameter wasbefore an array of server roles, now this parameter is renamed to ServerRoleName and can only be set to one server role.
      • ServerRoleName are no longer limited to built-in server roles. To add members to a built-in server role, set ServerRoleName to the name of the built-in server role.
      • The ServerRoleName will be created when Ensure is set to “Present” (if it does not already exist), or removed if Ensure is set to “Absent”.
    • Three new parameters are added; Members, MembersToInclude and MembersToExclude.
      • Members can be set to one or more logins, and those will replace all the memberships in the server role.
      • MembersToInclude and MembersToExcludecan be set to one or more logins that will add or remove memberships, respectively, in the server role. MembersToInclude and MembersToExclude can not be used at the same time as parameter Members. But both MembersToInclude and MembersToExclude can be used together at the same time.
  • Changes to xSQLServerSetup
    • Added a note to the README.md saying that it is not possible to add or remove features from a SQL Server failover cluster (issue 433).
    • Changed so that it reports false if the desired state is not correct (issue 432).
      • Added a test to make sure we always return false if a SQL Server failover cluster is missing features.
    • Helperfunction Connect-SQLAnalysis
      • Now has correct error handling, and throw does not used the unknown named parameter “-Message” (issue 436)
      • Added tests for Connect-SQLAnalysis
      • Changed to localized error messages.
      • Minor changes to error handling.
    • This adds better support for Addnode (issue 369).
    • Now it skips cluster validation för add node (issue 442).
    • Now it ignores parameters that are not allowed for action Addnode (issue 441).
    • Added support for vNext CTP 1.4 (issue 472).
  • Added newresource
    • xSQLServerAlwaysOnAvailabilityGroupReplica
  • Changes to xSQLServerDatabaseRecoveryModel
    • Fixed code style, removed SQLServerDatabaseRecoveryModel functions from xSQLServerHelper.
  • Changes to xSQLServerAlwaysOnAvailabilityGroup
    • Fixed the permissions check loop so that it exits the loop after the function determines the required permissions are in place.
  • Changes to xSQLServerAvailabilityGroupListener
    • Removed the dependency of SQLPS provider (issue 460).
    • Cleaned up code.
    • Added test for more coverage.
    • Fixed PSSA rule warnings (issue 255).
    • Parameter Ensure now defaults to “Present” (issue 450).
  • Changes to xSQLServerFirewall
    • Now it will correctly create rules when the resource is used for two or more instances on the same server (issue 461).
  • Changes to xSQLServerEndpointPermission
    • Added description to the README.md
    • Cleaned up code (issue 257 and issue 231)
    • Now the default value for Ensure is “Present”.
    • Removed dependency of SQLPS provider (issue 483).
    • Refactored tests so they use less code.
  • Changes to README.md
    • Adding deprecated tag to xSQLServerFailoverClusterSetup, xSQLAOGroupEnsure and xSQLAOGroupJoin in README.md so it it more clear that these resources has been replaced by xSQLServerSetup, xSQLServerAlwaysOnAvailabilityGroup and xSQLServerAlwaysOnAvailabilityGroupReplica respectively.
  • Changes to xSQLServerEndpoint
    • BREAKING CHANGE: Now SQLInstanceName is mandatory, and is a key, so SQLInstanceName has no longer a default value (issue 279).
    • BREAKING CHANGE: Parameter AuthorizedUser has been removed (issue 466, issue 275 and issue 80). Connect permissions can be set using the resource xSQLServerEndpointPermission.
    • Optional parameter IpAddress has been added. Default is to listen on any valid IP-address. (issue 232)
    • Parameter Port now has a default value of 5022.
    • Parameter Ensure now defaults to “Present”.
    • Resource now supports changing IP address and changing port.
    • Added unit tests (issue 289)
    • Added examples.
  • Changes to xSQLServerEndpointState
    • Cleaned up code, removed SupportsShouldProcess and fixed PSSA rules warnings (issue 258 and issue 230).
    • Now the default value for the parameter State is “Started”.
    • Updated README.md with a description for the resources and revised the parameter descriptions.
    • Removed dependency of SQLPS provider (issue 481).
    • The parameter NodeName is no longer mandatory and has now the default value of $env:COMPUTERNAME.
    • The parameter Name is now a key so it is now possible to change the state on more than one endpoint on the same instance. Note: The resource still only supports Database Mirror endpoints at this time.
  • Changes to xSQLServerHelper module
    • Removing helper function Get-SQLAlwaysOnEndpoint because there is no resource using it any longer.
    • BREAKING CHANGE: Changed helper function Import-SQLPSModule to support SqlServer module (issue 91). The SqlServer module is the preferred module so if it is found it will be used, and if not found an attempt will be done to load SQLPS module instead.
  • Changes to xSQLServerScript
    • Updated tests for this resource, because they failed when Import-SQLPSModule was updated.

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available in WMF 5.0) to find modules with DSC Resources:

# To list all modules that are part of the DSC Resource Kit
Find-Module -Tag DSCResourceKit
# To list all DSC resources from all sources 
Find-DscResource

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the xCertificate module, go to:
https://github.com/PowerShell/xCertificate.

All DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Katie Keim
Software Engineer
PowerShell Team
@katiedsc (Twitter)
@kwirkykat (GitHub)


DSC Configuration Sharing

$
0
0

The community around DSC Resources has been inspiring. The PowerShell Gallery now includes more than 2000 modules/scripts. 181 of those are modules focused on DSC, that collectively include 766 DSC Resources.

With this many building blocks available, it has become easier and faster to get a DSC project through the proof of concept phase to production-ready Windows Servers built using Configuration As Code.

When the author is new to DSC, their first configuration is a complex learning experience. The modules containing DSC Resources often have an /Examples folder with Configuration scripts showing how to use Resources, but they tend to be very specific and demonstrate only the functionality that the Resource was intended to solve. It can be hard to envision an end-to-end scenario-based Configuration. That typically comes later in the maturity model of learning DSC.

So how can we simplify and go faster? We’ve already seen that the community is very good at empowering people to be successful. Sharing examples helps people to look at existing work and identify patterns that can be repeated.

A community repo for DSC Configurations

Last week at the Automation Management Summit 2017, I previewed a new set of project repositories on GitHub. The goal of this work is to document a process for sharing end-to-end scenario-based Configurations.

Here is where to get started:
http://github.com/powershell/dscconfigurations

This project includes three individual repos:

  • DSC Configurations
    • DSC Configuration Template
    • DSC Configuration Tests

The goal of these is to provide guidance and tools to reduce the mean time to minimum viable product by iterating quickly. This was a key point of feedback at least year’s DSC Camp. The Template repo provides an example of how to layout a Configuration project. The Tests repo provides an automated solution to validate a Configuration script using Azure Automation and Azure Virtual Machines.

You will find the documentation in the submodules is still light to non-existant. I will be contributing to these as much as possible. In the mean time the community is welcome to submit Issues and PR’s to get things moving along more quickly. See the DSC Contribution Guidelines for more information.

Process change in the publishing model

I’d like to finish by pointing out an important change in process. With the DSC Resource Kit, today we follow a model where modules are authored and then handed off to the PowerShell team to be hosted in a central repository, and then published to the PowerShell Gallery. We are finding that in this model, we can actually become the bottleneck to release because it can be impossible to match pace with the throughput of so many people doing great authoring work in the community.

So with that in mind, the process for Configuration sharing will be that that the author should continue to host their code in a repo they own. Just like for Resources, they will continue to be the project maintainer. This is only a change to where the code is located on GitHub. Also just like Resources, the author can submit a request to the community for feedback and discuss their work in the monthly DSC Community Call. The end result of their work will still be to publish in the PowerShell Gallery. Additional details such as how to package Configurations and what tags to use will be documented in the DSCConfigurations project repo.

Thank you! I look forward to working together with everyone in the DSC community on DSC Configuration sharing.

Michael Greene

OpenSSH Security Testing Kick Off

$
0
0

Over the past while, we’ve been very busy porting OpenSSH to Win32. We’ve been working with the OpenSSH community in our GitHub repository, and are nearing a point where we are taking steps to make it production ready.

Image result for openssh logo

Security is obviously something that we have focused on during every phase of the project. As part of this production readiness phase, however, we are additionally funding an extensive penetration test. We have engaged Casaba Security as part of this effort, who will be digging deep into the implementation over the next 1-2 months.

As with all aspects of this project, one of our main goals is to contribute to the OpenSSH community as a whole, not just to create a Microsoft fork. As such, the scope of this analysis will include Microsoft contributions, but will dedicate significant time to OpenSSH core as well.

We will of course share the findings and final report from this review with the community.

Please Join Us!

As part of this phase, we’d love your participation, as well!

We’re keeping extensive design documentation for all decisions we’ve been making, especially security-sensitive ones. We’ve been tracking security discussions and issues as they arise. And there’s code. Lots of it J

We’d appreciate any expertise you’d like to contribute: security design reviews, security code reviews, security fixes for open issues, security testing, fuzzing, you name it. And don’t limit yourself to the Windows parts – findings in any aspect of OpenSSH improve the security of the whole community and industry.

Reporting Issues

If you think you’ve found a security vulnerability, please follow the OpenSSH reporting guidance by sending an email to openssh@openssh.com.

If you’ve got other forms of security feedback (for example, design feedback or defence-in-depth feedback), please use the [Security] prefix and file a GitHub issue.

 

We look forward to your feedback!

 

Lee Holmes
Principal Security Architect
Azure Management

PowerShell Core 6 Beta.1 Release

$
0
0

Approximately 9 months ago, we announced PowerShell Core 6 on GitHub being not only Open Source, but also cross platform.
Today, I’m proud to announce we are moving out of alpha and into beta!

We realize that moving a technology that started in Windows to Linux has to fit in properly to be accepted and provide a great experience across all platforms.  We appreciate all the great feedback — keep it coming!

You can download and read the change log from our usual release page.

If you’ve previously followed the steps to register the packages.microsoft.com Linux repository (see distro specific links below), you can just use apt-get or yum to get the latest version.

What’s changed in those 9 months?

Higher quality

1176 issues were opened, 566 closed, and 166 explicitly labeled as Resolution-Fixed meaning that a change was submitted, accepted, and merged.  Note that we haven’t been exactly consistent on using that label, so the actual number of issues fixed is higher.

712 pull requests were opened, 685 closed, and 577 merged.

More Linux distro coverage

We’ve expanded our testing on more Linux distros:

We’ll continue to add distros based on customer demand, although we depend on dotnetcore official supporting those distros.
Of course, we also support MacOS 10.

We also started publishing an AppImage which is a distro agnostic packaging technology allowing you to use PowerShell Core 6 on the most recent Linux distros.

We’ll also continue to publish Docker images supporting not only Linux Docker images, but also Windows Docker images.

More test coverage

We currently have 40% code coverage based on 5861 test cases run on Windows.  The current code coverage tooling doesn’t work on Linux (yet) although we currently run 4585 test cases on Linux and Mac.

Our goal to get out of Beta towards a Release Candidate is to have 80% code coverage so we still have lots of work left.
Adequate test coverage is critical for us to develop faster in the future to ensure new changes don’t cause regressions and potentially break existing customers.

Moving to .NET Standard 2.0

One of the big changes we’ve made for Beta.1 is moving to .NET Core App 2.0.0 (preview1) which is compatible with .NET Standard 2.0.
.NET Standard is a set of APIs all .NET platforms have to implement and greatly increases the available APIs you can use in your PowerShell modules or scripts.

What this means is that PowerShell modules built targeting .NET Standard 2.0 can work with both Windows PowerShell (down to .NET 4.5.1) and PowerShell Core 6.  For Beta.1, we have a known issue where the assemblies for Windows PowerShell modules should be compatible  with PowerShell Core 6, however they can’t be loaded if they are in the GAC.  This is something we’ll address in a future Beta release as side-by-side Windows PowerShell 5.1 and PowerShell Core 6 is one of our key scenarios.

We’ll continue to work on producing a quality SDK for PSCore6 to make it easy to develop portable PowerShell Modules that are compatible with Windows PowerShell 3, 4, 5 and PowerShell Core 6 on Windows, Linux, and Mac.

Telemetry

It is critical for us to know how we are growing our user base to help prioritize future investments.  Download numbers are not sufficient and with all the different places we publish our releases it become even less reliable as a data point.

In the Beta.1 release, we’ve added census telemetry using Application Insights.

If you prefer to not send us telemetry data, just follow the instructions in the README.

The dashboards we build from the telemetry data will be public and hopefully useful to the community over time if we add more telemetry.  Note that any additional telemetry will be added only after going through our RFC process.

The Road to a Release Candidate

Last January, we published a high level plan consisting of everything we knew we needed to get to a 6.0.0
release.  Continue to provide feedback on that plan if we missed anything that you consider important that prevents adoption of PowerShell Core 6.

We’ve also started to leverage the GitHub Projects feature to track high level scenarios as projects.  This is how the PowerShell team prioritizes our work.  Let us know in our Issues if something you care about isn’t prioritized appropriately.

Our Power BI Dashboard will continue to be updated to show various information about this project including related repositories other
than PowerShell/PowerShell.

During the Beta phase, we will continue to have timed releases approximately every 3 weeks with a updated Beta (Beta.2, then Beta.3, etc…) similar to what we did with Alpha releases.

Getting out of Beta and declaring a Release Candidate includes:

  • Fixing all the identified Beta issues
  • Getting to at least 80% code coverage
  • Enabling all the scenarios planned for 6.0.0
  • Hitting our usage targets based on telemetry (to be determined)

Special Recognition of the Community

Approximately 43% of the pull requests and almost 50% of the issues opened came from the community!  We appreciate all the contributions from the community whether it is opening issues, commenting on issues, submitting pull requests, or commenting on pull requests.  Note that this is specifically for the PowerShell/PowerShell repository; we also appreciate contributions across all of our repositories!

One individual has really stood out from the community and has by far provided the most contributions consistently in both quantity as well as quality: Ilya.

You can see a moving 30 day window of top community contributors in our Dashboard.

PowerShell Core 6 is the start of a new era for PowerShell and I’m excited to see how far we can go together with the community!

Steve Lee
Principal Software Engineer Manager
PowerShell Team

Announcing PowerShell for Visual Studio Code 1.0!

$
0
0

Today we are extremely excited to announce that the PowerShell extension for Visual Studio Code has reached version 1.0! We are shipping this update to line up with the PowerShell Core 6.0 Beta.1 release to provide the official PowerShell development experience for all supported platforms:

  • Windows 7 through 10 with PowerShell v3 and higher
  • Linux with PowerShell v6 (all PowerShell-supported distribtions)
  • macOS and OS X with PowerShell v6

Feature Overview

We’ve been working hard over the last year and a half to put together a first-class development experience for PowerShell that includes the following features:

  • PowerShell ISE-like interactive development experience with the PowerShell Integrated Console
  • Rich debugging experience including variables view, call stack, watch window, and various breakpoint types
  • Integrated script analysis and code fixes provided by PSScriptAnalyzer
  • Code navigations that allow you to find definitions and references of functions across your script files
  • Highly configurable code formatter based on community best practices
  • New file and project creation using Plaster templates
  • Editor scripting API through the $psEditor object model

You can find instructions for installing VS Code and the PowerShell extension at our GitHub repo.

You can also watch these YouTube video for an overview of using the PowerShell extension and Visual Studio Code (warning, loud audio at the beginning of the first video):

What does 1.0 mean?

As you probably have already discovered, the PowerShell Team has shifted to an open-source development model for the majority of our projects. This has enabled us to move extremely quickly, responding to customer feedback by releasing updates on a regular basis. Our focus now is on delivering value and quality quickly and incrementally rather than spending months polishing a single version for release.

With that in mind, we have a bit more flexibility on what it means to ship a 1.0 release of our tools. In the case of the PowerShell extension, increasing the version to 1.0 indicates a few things:

  • The development workflow of the PowerShell extension is stable enough to deliver a rich, interactive experience across all supported OSes – Windows, Linux, and macOS
  • Our public APIs are stable and will not have breaking changes in future 1.x releases
  • We will support the PowerShell extension and Visual Studio Code via issues reported through our respective GitHub repositories

Originally we were planning to release a series of beta releases similar to those of PowerShell Core before finalizing our 1.0 release. It turns out that the Visual Studio Marketplace currently does not support pre-release version names like 1.0.0-beta.1, so the clearest option was to continue forward with 1.0 so that we can indicate our level of committment and support of the extension.

What’s coming next?

We’ve got a lot of great improvements planned for the PowerShell extension, many of which will be coming online within the next few releases.

  • PowerShell “Project Model” via Plaster – We will be expanding Plaster to provide a rich toolset for developing PowerShell modules in any editor supported by PowerShell Editor Services. More details on this effort will be shared in the near future.
  • PSReadline support – We will add support for PSReadline in the Integrated Console to give the best possible command-line experience within the editor.
  • Expanded $psEditor APIs – We will make the editor even more scriptable with new APIs added in future updates.
  • Localization – English is currently the only supported language but we will eventually be adding
    other languages as requested by our community and partners.
  • User Guide – We are currently producing a complete User Guide for the extension that will help new
    users become productive quickly!
  • Instructional Videos – We will be producing a series of videos explaining how to use the PowerShell
    extension for script, module, and DSC resource development. Subscribe to the PowerShell Team’s YouTube channel to be notified as they are released!

What does this mean for the PowerShell ISE?

The PowerShell ISE has been the official editor for PowerShell throughout most of the history of Windows PowerShell. Now with the advent of the cross-platform PowerShell Core, we need a new official editor that’s available across all supported OS platforms and versions. Visual Studio Code is now that editor and the majority of our effort will be focused there.

However, the PowerShell ISE will remain in Windows supporting Windows PowerShell with no plans to remove it. We will consider investing effort there in the future if there is a high demand for it, but for now we think that we will be able to provide the best possible experience to the PowerShell community through Visual Studio Code.

Keep the feedback coming!

We’ve been receiving a lot of great feedback from the community over the last couple of years which has helped us to prioritize our efforts and deliver a great development experience for everyone. Please feel free to give us your feedback and feature requests at our GitHub repo and click “Watch” to keep up to date with the latest developments.

Thanks a lot for your continued feedback and support, we couldn’t do it without you!

David Wilson – @daviwil
Senior Software Engineer
PowerShell Team

Windows 10 Creators Update and PowerShell DSC

$
0
0

For those of you who are using or planning to update the Windows 10 Creators Update, we want to make you aware of some issues that we have discovered in DSC. The following scenario is an issue in this release:

  • In PowerShell ISE, Visual Studio code or on the command line, you receive the following error when trying to import PsDscResources in a DSC configuration:DscResourceError

We have a fix for this issue and are working diligently to get it released as soon as possible. We will let you know in a few days when you can expect to get your hands on the fix. 

We are also investigating some other potential issues with DSC while running in Strict Mode and will reply to this post when we know more.

Mark Gray
Senior Program Manager
The PowerShell Team

Coming Soon – PowerShell in Azure Cloud Shell

$
0
0

At BUILD 2017, we announced the preview of Azure Cloud Shell supporting the Bash shell. We are adding PowerShell support to Azure Cloud Shell, which gives you a choice of shell to get work done.

Sign-up today to participate in a limited preview of PowerShell in Azure Cloud Shell.

We look forward to sharing this awesome new PowerShell experience with you!

Hemant Mahawar – @HemanMahawar
Principal Program Manager
PowerShell Team

DSC Resource Kit Release May 2017

$
0
0

We just released the DSC Resource Kit! This release includes updates to 10 DSC resource modules including 3 new resources. In these past 6 weeks, 60 pull requests have been merged and 58 issues have been closed, all thanks to our amazing community!

The modules updated in this release are:

  • SharePointDsc
  • SecurityPolicyDsc
  • xCertificate
  • xComputerManagement
  • xCredSSP
  • xExchange
  • xHyper-V
  • xNetworking
  • xSqlServer
  • xStorage

UPDATE – xDFS has now also been released. Release notes can be found on the PowerShell Gallery here.
xStorage, xNetworking, and xCertificate have also just been released again to fix a conflict when using the modules together.

PSDscResources is also in the pipeline for release, but it is currently failing tests in AppVeyor.
It will be released when tests are passing.

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

Our last community call for the DSC Resource Kit was last week on May 24. A recording of our updates as well as summarizing notes are available. Join us next time to ask questions and give feedback about your experience with the DSC Resource Kit. Keep an eye on the community agenda for the link to the next call.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

All resources with the ‘x’ prefix in their names are still experimental – this means that those resources are provided AS IS and are not supported through any Microsoft support program or service. If you find a problem with a resource, please file an issue on GitHub.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or Changelog.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
SharePointDsc 1.7.0.0
  • Update SPSearchIndexPartition made ServiceAppName as a Key
  • New resouce: SPTrustedRootAuthority
  • Update SPFarmSolution to eject from loop after 30m.
  • New resource: SPMachineTranslationServiceApp
  • New resource: SPPowerPointAutomationServiceApp
  • Bugfix in SPSearchFileType made ServiceAppName a key property.
  • New resource: SPWebApplicationExtension
  • Added new resource SPAccessServices2010
  • Added MSFT_SPSearchCrawlMapping Resource to manage Crawl Mappings for Search Service Application
  • Added new resource SPSearchAuthoritativePage
  • Bugfix in SPWebAppThrottlingSettings for setting large list window time.
  • Fix typo in method Get-TargetResource of SPFeature
  • Fix bug in SPManagedAccount not returning the correct account name value
  • Fix typo in method Get-TargetResource of SPSearchIndexPartition
  • Update documentation of SPInstallLanguagePack to add guidance on package change in SP2016
  • Added returning the required RunCentralAdmin parameter to Get-TargetResource in SPFarm
  • Added web role check for SPBlobCacheSettings
  • Improved error message when rule could not be found in SPHealthAnalyzerRuleState
  • Extended the documentation to specify that the default value of Ensure is Present
  • Added documentation about the user of Host Header Site Collections and the HostHeader parameter in SPWebApplication
  • Fixed missing brackets in SPWebAppPolicy module file
  • Fixed issue with SPSecureStoreServiceApp not returning database information
  • Fixed issue with SPManagedMetadataServiceApp not returning ContentTypeHubUrl in SP2016
  • Updated SPTrustedIdentityTokenIssuer to allow to specify the signing certificate from file path as an alternative to the certificate store
  • New resource: SPSearchCrawlerImpactRule
  • Fixed issue in SPSite where the used template wasn’t returned properly
  • Fixed issue in SPWebApplicationGeneralSettings which didn’t return the security validation timeout properly
  • Fixed bug in SPCreateFarm and SPJoinFarm when a SharePoint Server is already joined to a farm
  • Bugfix in SPContentDatabase for setting WarningSiteCount as 0.
  • Fixing verbose message that identifies SP2016 as 2013 in MSFT_SPFarm
  • Fixed SPProductUpdate looking for OSearch15 in SP2016 when stopping services
  • Added TermStoreAdministrators property to SPManagedMetadataServiceApp
  • Fixed an issue in SPSearchTopology that would leave a corrupt topology in place if a server was removed and re-added to a farm
  • Fixed bug in SPFarm that caused issues with database names that have dashes in the names
SecurityPolicyDsc 1.4.0.0
  • Added functionality to support BaselineManagement Module.
  • Updated UserRightsAssignment resource to respect dynamic local accounts.
  • Added SecuritySetting resource to process additional INF settings.
xCertificate 2.6.0.0
  • Added mandatory properties for xPfxImport resource example.
  • xCertReq:
    • Fixed issue where xCertReq does not identify when DNS Names in SANs are incorrect.
    • Added Certificate Authority auto-discovery to resource xCertReq.
    • Added SAN and certificate template name to xCertReq”s Get-TargetResource
    • Added new parameter UseMachineContext to be able to use CA templates that try to fill the subject alternative name
  • CertificateDSc.Common:
    • Added function Get-CertificateTemplateName to retrieve template name
    • Added function Get-CertificateSan to retrieve subject alternative name
    • Added function Find-CertificateAuthority to enable auto-discovery
xComputerManagement 1.10.0.0
  • Added resources
    • xVirtualMemory
xCredSSP 1.3.0.0
  • Added a fix to enable credSSP with a fresh server installation
xExchange 1.15.0.0
  • xExchDatabaseAvailabilityGroupMember: Added check to ensure Failover-Clustering role is installed before adding server to DAG.
  • xExchInstall: Remove parameter “-AllowImmediateReboot $AllowImmediateReboot” when calling CheckWSManConfig.
  • xExchOutlookAnywhere: Add test for ExternalClientAuthenticationMethod.
  • Test: Update OAB and UMService tests to create test OAB and UMDialPlans, respectively.
xHyper-V 3.8.0.0
  • Fix bug in xVMDvdDrive with hardcoded VM Name.
  • Corrected Markdown rule violations in Readme.md.
xNetworking 4.0.0.0
  • Converted to use AppVeyor.psm1 in DSCResource.Tests repository.
  • Converted to use Example and Markdown tests in DSCResource.Tests repository.
  • Added CodeCov.io support.
  • Added a new example to xDNSServerAddress to clarify setting multiple DNS Servers.
  • Fix examples to correct display in auto documentation generation.
  • BREAKING CHANGE: Migrated xNetworkAdapter module functionality to xNetAdapterName resource.
  • Added CommonTestHelper module for aiding testing.
  • MSFT_xNetAdapterName:
    • Created new resource for renaming network adapters.
    • Added Find-NetAdapter cmdlet to NetworkingDsc.Common.
  • Correct example parameters format to meet style guidelines.
xSqlServer 7.1.0.0
  • Changes to xSQLServerMemory
    • Changed the way SQLServer parameter is passed from Test-TargetResource to Get-TargetResource so that the default value isn”t lost (issue 576).
    • Added condition to unit tests for when no SQLServer parameter is set.
  • Changes to xSQLServerMaxDop
    • Changed the way SQLServer parameter is passed from Test-TargetResource to Get-TargetResource so that the default value isn”t lost (issue 576).
    • Added condition to unit tests for when no SQLServer parameter is set.
  • Changes to xWaitForAvailabilityGroup
    • Updated README.md with a description for the resources and revised the parameter descriptions.
    • The default value for RetryIntervalSec is now 20 seconds and the default value for RetryCount is now 30 times (issue 505).
    • Cleaned up code and fixed PSSA rules warnings (issue 268).
    • Added unit tests (issue 297).
    • Added descriptive text to README.md that the account that runs the resource must have permission to run the cmdlet Get-ClusterGroup (issue 307).
    • Added read-only parameter GroupExist which will return $true if the cluster role/group exist, otherwise it returns $false (issue 510).
    • Added examples.
  • Changes to xSQLServerPermission
    • Cleaned up code, removed SupportsShouldProcess and fixed PSSA rules warnings (issue 241 and issue 262).
    • It is now possible to add permissions to two or more logins on the same instance (issue 526).
    • The parameter NodeName is no longer mandatory and has now the default value of $env:COMPUTERNAME.
    • The parameter Ensure now has a default value of “Present”.
    • Updated README.md with a description for the resources and revised the parameter descriptions.
    • Removed dependency of SQLPS provider (issue 482).
    • Added ConnectSql permission. Now that permission can also be granted or revoked.
    • Updated note in resource description to also mention ConnectSql permission.
  • Changes to xSQLServerHelper module
    • Removed helper function Get-SQLPSInstance and Get-SQLPSInstanceName because there is no resource using it any longer.
    • Added four new helper functions.
      • Register-SqlSmo, Register-SqlWmiManagement and Unregister-SqlAssemblies to handle the creation on the application domain and loading and unloading of the SMO and SqlWmiManagement assemblies.
      • Get-SqlInstanceMajorVersion to get the major SQL version for a specific instance.
    • Fixed typos in comment-based help
  • Changes to xSQLServer
    • Fixed typos in markdown files; CHANGELOG, CONTRIBUTING, README and ISSUE_TEMPLATE.
    • Fixed typos in schema.mof files (and README.md).
    • Updated some parameter description in schema.mof files on those that was found was not equal to README.md.
  • Changes to xSQLServerAlwaysOnService
    • Get-TargetResource should no longer fail silently with error “Index operation failed; the array index evaluated to null.” (issue 519). Now if the Server.IsHadrEnabled property return neither $true or $false the Get-TargetResource function will throw an error.
  • Changes to xSQLServerSetUp
    • Updated xSQLServerSetup Module Get-Resource method to fix (issue 516 and 490).
    • Added change to detect DQ, DQC, BOL, SDK features. Now the function Test-TargetResource returns true after calling set for DQ, DQC, BOL, SDK features (issue 516 and 490).
  • Changes to xSQLServerAlwaysOnAvailabilityGroup
    • Updated to return the exception raised when an error is thrown.
  • Changes to xSQLServerAlwaysOnAvailabilityGroupReplica
    • Updated to return the exception raised when an error is thrown.
    • Updated parameter description for parameter Name, so that it says it must be in the format SQLServer\InstanceName for named instance (issue 548).
  • Changes to xSQLServerLogin
    • Added an optional boolean parameter Disabled. It can be used to enable/disable existing logins or create disabled logins (new logins are created as enabled by default).
  • Changes to xSQLServerDatabaseRole
    • Updated variable passed to Microsoft.SqlServer.Management.Smo.User constructor to fix issue 530
  • Changes to xSQLServerNetwork
    • Added optional parameter SQLServer with default value of $env:COMPUTERNAME (issue 528).
    • Added optional parameter RestartTimeout with default value of 120 seconds.
    • Now the resource supports restarting a sql server in a cluster (issue 527 and issue 455).
    • Now the resource allows to set the parameter TcpDynamicPorts to a blank value (partly fixes issue 534). Setting a blank value for parameter TcpDynamicPorts together with a value for parameter TcpPort means that static port will be used.
    • Now the resource will not call Alter() in the Set-TargetResource when there is no change necessary (issue 537).
    • Updated example 1-EnableTcpIpOnCustomStaticPort.
    • Added unit tests (issue 294).
    • Refactored some of the code, cleaned up the rest and fixed PSSA rules warnings (issue 261).
    • If parameter TcpDynamicPort is set to “0” at the same time as TcpPort is set the resource will now throw an error (issue 535).
    • Added examples (issue 536).
    • When TcpDynamicPorts is set to “0” the Test-TargetResource function will no longer fail each time (issue 564).
  • Changes to xSQLServerRSConfig
    • Replaced sqlcmd.exe usages with Invoke-Sqlcmd calls (issue 567).
  • Changes to xSQLServerDatabasePermission
    • Fixed code style, updated README.md and removed *-SqlDatabasePermission functions from xSQLServerHelper.psm1.
    • Added the option “GrantWithGrant” with gives the user grant rights, together with the ability to grant others the same right.
    • Now the resource can revoke permission correctly (issue 454). When revoking “GrantWithGrant”, both the grantee and all the other users the grantee has granted the same permission to, will also get their permission revoked.
    • Updated tests to cover Revoke().
  • Changes to xSQLServerHelper
    • The missing helper function (“Test-SPDSCObjectHasProperty”), that was referenced in the helper function Test-SQLDscParameterState, is now incorporated into Test-SQLDscParameterState (issue 589).
xStorage 3.0.0.0
  • Converted AppVeyor build process to use AppVeyor.psm1.
  • Added support for auto generating wiki, help files, markdown linting and checking examples.
  • Correct name of MSFT_xDiskAccessPath.tests.ps1.
  • Move shared modules into Modules folder.
  • Fixed unit tests.
  • Removed support for WMI cmdlets.
  • Opted in to Markdown and Example tests.
  • Added CodeCov.io support.
  • Removed requirement on using Pester 3.4.6 because Pester bug fixed in 4.0.3.
  • Fixed unit tests for MSFT_xDiskAccessPath resource to be compatible with Pester 4.0.3.
  • xDisk:
    • BREAKING CHANGE: Renamed parameter DiskNumber to DiskId to enable it to
    • Added DiskIdType parameter to enable specifying the type of identifer
    • Changed to use xDiskAccessPath pattern to fix issue with Windows Server
    • Fixed style violations in xDisk.
    • Fixed issue when creating multiple partitions on a single disk with no size
  • xDiskAccessPath:
    • BREAKING CHANGE: Renamed parameter DiskNumber to DiskId to
    • Added DiskIdType parameter to enable specifying the type
    • Fixed incorrect logging messages when changing volume label.
    • Fixed issue when creating multiple partitions on a single disk with no size
  • xWaitForDisk:
    • BREAKING CHANGE: Renamed parameter DiskNumber to DiskId
    • Added DiskIdType parameter to enable specifying the type

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available in WMF 5.0) to find modules with DSC Resources:

# To list all modules that are part of the DSC Resource Kit
Find-Module -Tag DSCResourceKit
# To list all DSC resources from all sources 
Find-DscResource

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the xCertificate module, go to:
https://github.com/PowerShell/xCertificate.

All DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Katie Keim
Software Engineer
PowerShell Team
@katiedsc (Twitter)
@kwirkykat (GitHub)


Getting Started with PowerShell Core on Windows, Mac, and Linux

$
0
0

Today we have a guest post from Honorary Script Guy and Microsoft Premier Field Engineer Ashley McGlone, also known as GoateePFE.

This is deeper than Coke vs. Pepsi or Ford vs. Chevy. We are breaking down the barriers. Cats and dogs living together. Are you ready for this?

What is PowerShell Core?

The next release of PowerShell (6.0) was open-sourced last year and is currently in beta. However, it is PowerShell Core designed to run cross-platform on Windows, Mac, and Linux. PowerShell Core runs on top of .NET Core, a cross-platform, open-source version of the code base powering most of the Windows world. This version of PowerShell will be different than the Windows PowerShell edition you see built into Windows today.

My Mac Demo Rig

I have the coolest job, and I love my Microsoft Surface Pro 4. But now in my bag I also carry a MacBook Pro running VMs of Windows and Linux for one ultimate demo machine. Now I can demo PowerShell Core 6 and Visual Studio Code side-by-side on three different operating systems. I can even demo PowerShell remoting between all three operating systems.
How cool is that?!

The beta release of PowerShell Core 6 supports a significant list of Linux distributions. For my demos I chose Ubuntu Desktop so that I could do both PowerShell Core and Visual Studio Code. According to http://distrowatch.com this is one of the most popular Linux flavors.

Every customer who has seen this Microsoft guy demo PowerShell on three operating systems from a MacBook Pro has been impressed with the direction Microsoft is taking. Customers are excited about the cross-platform administrative opportunities now with PowerShell everywhere.

What do I need?

To get started with PowerShell Core you want to install and configure these three items on your operating system(s) of choice:

I was surprised how quickly I was up-and-running following the installation instructions. Each process involved relatively little tweaking for a beta experience.

If you are a Linux person you might be thinking, “OK. I already have OpenSSH installed.” Please read the OpenSSH link above for the step of editing the sshd_config file for PowerShell remoting support.

Validate the install

From Mac or Linux simply open the terminal window and type powershell. You should see the copyright banner (no year for beta) and get the PS prompt. Type $PSVersionTable to see your version.

goatee@ub:~$ powershell
PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS /home/goatee> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
BuildVersion                   3.0.0.0
CLRVersion
GitCommitId                    v6.0.0-beta.1
OS                             Linux 4.4.0-78-generic #99-Ubuntu SMP Thu Apr...
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Type Get-Command to see what cmdlets are available in your session.

PS /home/goatee> Get-Command

You might find it tricky to launch PowerShell Core 6 on a Windows VM that already has PowerShell natively installed. Here is one way to launch it:

  • Navigate to the beta install directory: C:\Program Files\PowerShell*beta_directory*\
  • Type $PSVersionTable to see the native version of PowerShell
  • Now type .\powershell.exe and press Enter
  • Type $PSVersionTable again to see that PSEdition is shown as Core and with a different version number

Note the trick here is the .\ in front of the EXE, otherwise it will find the native EXE for Windows PowerShell.

Now for something new! Try this:

Get-Variable Is*

Notice that you now have built-in variables indicating the operating system version. These variables enable you to check the current OS and perform different behaviors from within a script.

PS /home/goatee> Get-Variable Is*

Name                           Value
----                           -----
IsCoreCLR                      True
IsLinux                        True
IsOSX                          False
IsWindows                      False

Things to know

  • Case-sensitivity
    Windows is not case-sensitive, so neither is PowerShell on Windows. However, Linux is case-sensitive. PowerShell commands on Mac and Linux are not case-sensitive, but sometimes the operating system-specific values (e.g. the names of environment variables like PATH) are case-sensitive.
  • Slashes
    PowerShell on Windows has always allowed forward slashes and backward slashes in paths, so moving to Mac and Linux has minimal issues with the direction of the slashes. (However, it’s always a best practice to use variables like $pwd and $PSScriptRoot, and cmdlets like Split-Path/Join-Path to generate paths which conform to any given platform.)
  • Aliases
    PowerShell on Windows has always had Linux aliases like ls, cat, man, etc. However, these PowerShell aliases do not exist on Mac and Linux to avoid conflict with the native binary equivalents.

Now what can I do?

For Windows people trying Mac or Linux

  • Get a list of available modules:
      PS /home/goatee> Get-Module -ListAvailable
    
          Directory: /home/goatee/.local/share/powershell/Modules
    
      ModuleType Version    Name                                ExportedCommands
      ---------- -------    ----                                ----------------
      Manifest   1.1.0.0    Microsoft.PowerShell.Archive        {Compress-Archive,...
      Manifest   3.0.0.0    Microsoft.PowerShell.Host           {Start-Transcript,...
      Manifest   3.1.0.0    Microsoft.PowerShell.Management     {Add-Content, Clea...
      Manifest   3.0.0.0    Microsoft.PowerShell.Security       {Get-Credential, G...
      Manifest   3.1.0.0    Microsoft.PowerShell.Utility        {Format-List, Form...
      Script     1.1.2.0    PackageManagement                   {Find-Package, Get...
      Script     3.3.9      Pester                              {Describe, Context...
      Script     1.1.2.0    PowerShellGet                       {Install-Module, F...
      Script     0.0        PSDesiredStateConfiguration         {ThrowError, Get-P...
      Script     1.2        PSReadLine                          {Get-PSReadlineKey...
    
  • PowerShell commands and pipelines work like they always have:
    PS /home/goatee> Get-Process | Sort-Object CPU -Descending | Select-Object -First 5
    
    NPM(K)    PM(M)      WS(M)     CPU(s)     Id  SI ProcessName
    ------    -----      -----     ------     --  -- -----------
         0     0.00      38.65       8.04   1259 259 Xorg
         0     0.00      64.11       4.79   1985 985 compiz
         0     0.00     101.68       3.42   2104 949 gnome-software
         0     0.00      90.87       2.86   2693 568 powershell
         0     0.00       9.47       2.36   2110 949 prlcc
    
  • Use Windows aliases on Mac and Linux:
    dir
    cd
    
  • Because PowerShell Core is based on .NET Standard, you can do .NET stuff from the console just like on Windows:
    PS /home/goatee> [math]::pi
    3.14159265358979
    
    PS /home/goatee> [math]::pow(2,8)
    256
    
    PS /home/goatee> (Get-Date).AddDays(7)
    Monday, May 29, 2017 3:51:47 PM
    
  • PSReadline and tab completion work as well, but the default EditMode is set to Emacs, resulting in slightly different behavior: when you hit Tab, if you have not typed enough characters to match a single completion, you will get a list of available commands starting with those characters instead of a full completion.

For Mac or Linux people trying PowerShell

The cmdlet Get-Command will tell you all the commands available in your session. Then pass the command name to Get-Help just like man:

PS /home/goatee> Get-Command

PS /home/goatee> Get-Help Get-Process

You will find that PowerShell help looks much like familiar man pages. You should first download the help file content on any new install like this:

PS /home/goatee> Update-Help

Notice that you can blend native commands and PowerShell in a single, object-oriented pipeline.

cat /etc/passwd | ConvertFrom-Csv -Delimiter ':' -Header Name,Passwd,UID,GID,Description,Home,Shell | Sort-Object Name | Format-Table

Here are some of the many similarities between PowerShell and bash (with more here):

Linux PowerShell
compgen / man builtin Get-Command
man Get-Help
ls Get-ChildItem
cat / tail Get-Content
ps / top Get-Process
wc Measure-Object
sort Sort-Object
tee Tee-Object
grep Select-String
touch New-Item
tar Compress-Archive / Expand-Archive
history Get-History / Invoke-History
cd ~ cd ~ / cd $home
pwd $pwd
env Get-ChildItem env:\

These command all have a wide assortment of parameters viewable with Get-Help. In PowerShell, parameter names are intuitive, verbose, and largely shared across commands for uniformity.

Here is an example of tail in PowerShell:

# Linux
tail -f my.log

# PowerShell
Get-Content -Path my.log -Tail 10 -Wait

Here is an example of wc in PowerShell. Note that the results are slightly different, because the output of ps is different than Get-Process.

PS /home/goatee> ps aux | wc
    191    2240   19045

PS /home/goatee> Get-Process | Measure-Object
Count    : 190
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

PS /home/goatee> Get-Process | Measure-Object -Line -Word -Character

Lines Words Characters Property
----- ----- ---------- --------
  188   376       7394

CTRL+R will let you search and execute command history in PowerShell on all operating systems. This functionality is just one feature of the PSReadline module automatically loaded for you.

PowerShell Remoting over SSH

PowerShell Core 6 includes new parameters for remoting over SSH. This is why you had to install and configure OpenSSH on each box.

Enter-PSSession -Hostname <IP or FQDN> -Username <username> -SSHTransport

This area required a bit of tweaking to get working for me, so pay close attention to the steps in the guide. Windows people will need to learn a bit of vi or nano to edit the sshd_config file on Linux with the entries from the guide.

Here is what it looks like to browse a Windows machine from a Linux SSH remoting session:

PS /home/goatee> Enter-PSSession -HostName 10.211.55.3 -UserName goatee10\testadmin -SSHTransport
goatee10\testadmin@10.211.55.3's password:
[10.211.55.3]: PS C:\Users\testadmin\Documents> cd\
[10.211.55.3]: PS C:\> dir

    Directory: C:\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         5/3/2017   8:20 PM                MSOTraceLite
d-----        3/18/2017   5:03 PM                PerfLogs
d-r---        4/27/2017   1:38 PM                Program Files
d-r---        4/19/2017  11:57 AM                Program Files (x86)
d-----        5/13/2017   3:24 PM                Source
d-r---         5/2/2017   7:50 AM                Users
d-----         5/5/2017   9:24 AM                Windows

[10.211.55.3]: PS C:\> exit

PS /home/goatee>

Visual Studio Code

After installing Visual Studio Code, you want to add the PowerShell extension. Open Code, click the square on the left bar, type powershell, and install the extension. It will ask you to click to reload the window.

With the release of the PowerShell v1.x extension for Visual Studio Code it is now possible to have a cross-platform PowerShell editing experience very similar to the ISE on Windows boxes:

  • F5 and F8 will run all or selection of a script.
  • You have the interactive output window at the bottom.
  • Intellisense and tab-completion make coding faster. CTRL+SPACE works here also.
  • The debugger has breakpoints and stepping.

And it is also better than the ISE in many ways:

  • Typing paired punctuation is automatic ( () [] {} ” “”).
  • Select some code, right click, and choose Format Selection or Format Document to format your code according to standard practices. (My favorite new feature!)
  • Right click a function and choose Go To Definition or Find All References.
  • Searching highlights results in the scroll bar.
  • Script Analyzer provides coding best practices alerts.

If you are editing a new file in Code you need to trigger the PowerShell experience in one of two ways:

  • Save the file with a .ps1 or .psm1 extension.
  • In the bottom right corner click on Plain Text and then choose PowerShell for the language mode.

These steps trigger the interactive output window and syntax completion. It is amazing to have full parity in the editing experience across Windows, Mac, and Linux.

If you would like to learn more about editing PowerShell with VS Code, check out David Wilson’s presentation to the AZPosh user group or his presentation from the PowerShell and DevOps Global Summit 2017.

Desired State Configuration

This blog post is getting quite long, so I will not get into Desired State Configuration today. However, you can read Get started with Desired State Configuration (DSC) for Linux in the documentation site.

Truly Cross-Platform Code

Depending on the task at hand we can run the exact same code on PowerShell Core on all three platforms. For example, on the operating system of your choice run this REST call and process the JSON response:

(Invoke-WebRequest -Uri 'http://jsonplaceholder.typicode.com/posts?userid=1' -Method Get).Content | ConvertFrom-Json

It is remarkable to see the same code run on all platforms. This paints a bright future for sysadmins everywhere.

Your Turn

I hope you have enjoyed this quick tour of the new cross-platform PowerShell scripting experience. Try it today on your favorite operating system. If you find things that do not work as you expected, then please submit an issue on GitHub.
Cheers!

DSC Resource Kit Release July 2017

$
0
0

We just released the DSC Resource Kit!This release includes updates to 12 DSC resource modules. In these past 6 weeks, 106 pull requests have been merged and 115 issues have been closed, all thanks to our amazing community! This is by far the most issues we have ever had closed for a single release!

The modules updated in this release are:

  • PsDscResources
  • SecurityPolicyDsc
  • SharePointDsc
  • xCertificate
  • xComputerManagement
  • xFailOverCluster
  • xHyper-V
  • xNetworking
  • xSqlServer
  • xStorage
  • xWebAdministration
  • xWindowsUpdate

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

Our last community call for the DSC Resource Kit was last week on July 5. A recording of our updates as well as summarizing notes are available. Join us for the next call on August 16 to ask questions and give feedback about your experience with the DSC Resource Kit. Keep an eye on the community agenda for the link to the next call.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

All resources with the ‘x’ prefix in their names are still experimental – this means that those resources are provided AS IS and are not supported through any Microsoft support program or service. If you find a problem with a resource, please file an issue on GitHub.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or Changelog.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
PSDscResources 2.8.0.0
  • Archive:
    • Added handling of directory archive entries that end with a foward slash
    • Removed formatting of LastWriteTime timestamp and updated comparison of timestamps to handle dates in different formats
  • WindowsProcess:
    • Fix unreliable tests
  • Updated Test-IsNanoServer to return false if Get-ComputerInfo fails
  • Registry:
    • Fixed bug when using the full registry drive name (e.g. HKEY_LOCAL_MACHINE) and using a key name that includes a drive with forward slashes (e.g. C:/)
SecurityPolicyDsc 1.4.0.0
  • Fixed bug in which friendly name translation may fail if user or group contains “S-“.
  • Fixed bug identified in issue 33 and 34 where Test-TargetResource would return false but was true
SharePointDsc 1.8.0.0
  • Fixed issue in SPServiceAppProxyGroup causing some service names to return as null
  • Added TLS and SMTP port support for SharePoint 2016
  • Fixed issue in SPWebApplication where the Get method didn’t return Classic web applications properly
  • Fixed issue in SPSubscriptionSettingsServiceApp not returning database values
  • Updated Readme of SPInstall to include SharePoint Foundation is not supported
  • Fixed issue with Access Denied in SPDesignerSettings
  • Fixed missing brackets in error message in SPExcelServiceApp
  • Removed the requirement for the ConfigWizard in SPInstallLanguagePack
  • Fixed Language Pack detection issue in SPInstallLanguagePack
  • Added support to set Windows service accounts for search related services to SPSearchServiceApp resource
  • Fixed issue in SPCreateFarm and SPJoinFarm where an exception was not handled correctly
  • Fixed issue in SPSessionStateService not returning correct database server and name
  • Fixed missing Ensure property default in SPRemoteFarmTrust
  • Fixed issue in SPWebAppGeneralSettings where -1 was returned for the TimeZone
  • Fixed incorrect UsagePoint check in SPQuotaTemplate
  • Fixed issue in SPWebAppPolicy module where verbose messages are causing errors
  • Fixed incorrect parameter naming in Get method of SPUserProfilePropery
  • Fixed issue in SPBlobCacheSettings when trying to declare same URL with different zone
  • Improve documentation on SPProductUpdate to specify the need to unblock downloaded files
  • Added check if file is blocked in SPProductUpdate to prevent endless wait
  • Enhance SPUserProfileServiceApp to allow for NoILM to be enabled
  • Fixed issue in SPUserProfileProperty where PropertyMapping was Null
xCertificate 2.8.0.0
  • xCertReq:
    • Added FriendlyName parameter to xCertReq.
    • Changed exceptions to be raised using New-InvalidOperationException from PSDscResources.
    • Changed integration tests to use Config Data instead of value in config to support additional tests.
    • Converted unit tests to use Get-InvalidOperationRecord in CommonTestHelper.
    • Improved unit test style to match standard layout.
    • Minor corrections to style to be HQRM compliant.
    • Improved Verbose logging by writing all lines of CertReq.exe output.
    • Fixed CA auto-detection to work when CA name contains a space.
  • Corrected all makrdown rule violations in README.MD.
  • Added markdownlint.json file to enable line length rule checking in VSCode with markdownlint extension installed.
  • Added the VS Code PowerShell extension formatting settings that cause PowerShell files to be formatted as per the DSC Resource kit style guidelines.
  • Fixed verbose preference not being passed to CertificateDsc.Common functions – fixes Issue 70.
  • Converted all calls to New-InvalidArgumentError function to New-InvalidArgumentException found in CertificateDsc.ResourceHelper – fixes Issue 68
  • Replaced all calls to Write-Error with calls to New-InvalidArgumentException and InvalidOperationException`
  • xWaitForCertificateServices:
    • Added new resource.
  • Cleaned up example format to meet style guidelines and changed examples to issue 2048 bit certificates.
  • Fixed spelling error in xCertificateExport Issuer parameter description.
xComputerManagement 2.0.0.0
  • Updated resources
    • BREAKING CHANGE: xScheduledTask: Added nearly all available parameters for tasks
xFailOverCluster 1.7.0.0
  • Changes to xClusterPreferredOwner
    • Script Analyzer warnings have been fixed (issue 50). This also failed the tests for the resource.
  • Changes to xClusterDisk
    • Fixed test that was failing in AppVeyor (issue 55).
  • Changes to xFailOverCluster
    • Added “Code of Conduct” text to the README.md (issue 44).
    • Added TOC for all resources in the README.md (issue 43).
    • Fixed typos and lint errors in README.md.
    • Fixed style issue in example in README.md.
    • Removed “Unreleased” “tag” from the resources xClusterQuorum and xClusterDisk (issue 36)
    • Added new sections to each resource (Requirements, Parameters and Examples) in the README.md. Some does not yet have any examples, so they are set to “None.”.
    • Added GitHub templates PULL_REQUEST_TEMPLATE, ISSUE_TEMPLATE and CONTRIBUTING.md (issue 45).
    • Split the change log from README.md to a separate file CHANGELOG.md (issue 48).
    • Added the resource xClusterPreferredOwner to README.md (issue 51).
    • Added the resource xClusterNetwork to README.md (issue 56).
    • Removed Credential parameter from parameter list for xWaitForCluster. Parameter Credential does not exist in the schema.mof of the resource (issue 62).
    • Now all parameters in the README.md list their data type and type qualifier (issue 58.)
    • Added Import-DscResource to example in README.md.
    • Added CodeCov and opt-in for all common tests (issue 41).
    • Added CodeCov badge to README.md
      • Fixed CodeCov badge links so they now can be clicked on.
    • Fixed lint rule MD013 in CHANGELOG.md.
    • Fixed lint rule MD013 in README.md.
    • Fixed lint rule MD024 in README.md.
    • Fixed lint rule MD032 in README.md.
    • Removed example from README.md (issue 42).
    • Fixed typo in filename for ISSUE_TEMPLATE. Was “ISSUE_TEMPLATE”, now it is correctly “ISSUE_TEMPLATE.md”.
    • Changed appveyor.yml to use the new default test framework in the AppVeyor module in DscResource.Tests (AppVeyor.psm1).
    • Added VS Code workspace settings file with formatting settings matching the Style Guideline (issue 67). That will make it possible inside VS Code to press SHIFT+ALT+F, or press F1 and choose “Format document” in the list. The PowerShell code will then be formatted according to the Style Guideline (although maybe not complete, but would help a long way).
    • Added new stubs for FailoverClusters module (Tests\Unit\Stubs\FailoverClusters.stubs.psm1) to be able to run unit tests on a computer that does not have or can install Failover Clustering PowerShell module.
    • Added a script file (Tests\Unit\Stubs\Write-ModuleStubFile.ps1) to be able to rebuild the stub file (FailoverClusters.stubs.psm1) whenever needed.
    • Added code block around types in README.md.
  • Changes to xCluster
    • Added examples
      • 1-CreateFirstNodeOfAFailoverCluster.ps1
      • 2-JoinAdditionalNodeToFailoverCluster.ps1
      • 3-CreateFailoverClusterWithTwoNodes.ps1 (this is the example from README.md)
    • Fixed typo in xCluster parameter description.
    • Added links to examples from README.md
    • Refactored the unit test for this resource to use stubs and increase coverage (issue 73).
      • Removed the password file (MSFT_xCluster.password.txt) which seemed unnecessary.
    • Test-TargetResource now throws and error if domain name cannot be evaluated (issue 72).
    • Set-TargetResource now correctly throws and error if domain name cannot be evaluated (issue 71).
  • Changes to xWaitForCluster
    • Added example
      • 1-WaitForFailoverClusterToBePresent.ps1
    • Added link to example from README.md
  • Changes to xClusterDisk
    • Refactored the unit test for this resource to use stubs and increase coverage (issue 74).
    • Removed an evaluation that called Test-TargetResource in Set-TargetResource and instead added logic so that Set-TargetResource evaluates if it should remove a disk (issue 90).
    • Changed the code to be more aligned with the style guideline.
    • Added examples (issue 46)
      • 1-AddClusterDisk.ps1
      • 2-RemoveClusterDisk.ps1
    • Added links to examples from README.md.
  • Changes to xClusterPreferredOwner
    • Refactored the unit test for this resource to use stubs and increase coverage (issue 76).
    • Changed the code to be more aligned with the style guideline.
    • Added examples (issue 52)
      • 1-AddPreferredOwner.ps1
      • 2-RemovePreferredOwner.ps1
    • Added links to examples from README.md.
  • Changes to xClusterNetwork
    • Refactored the unit test for this resource to use stubs and increase coverage (issue 75).
    • Changed the code to be more aligned with the style guideline.
    • Updated resource and parameter description in README.md and schema.mof.
    • Added example (issue 57)
      • 1-ChangeClusterNetwork.ps1
    • Added links to examples from README.md.
xHyper-V 3.9.0.0
  • MSFT_xVMHyperV:
    • Increased xVMHyperV StartupMemory and MinimumMemory limits from 17GB to 64GB.
    • EnableGuestService works on localized OS (language independent).
    • Adds missing Hyper-V-PowerShell feature in examples.
  • Added the following resources:
    • MSFT_xVMProcessor to manage virtual machine processor options.
    • MSFT_xVMHost to managing Hyper-V host settings.
  • MSFT_xVMSwitch:
    • Added support for Switch Embedded Teaming (SET) in Server 2016.
    • Fixed a bug where Get-TargetResource threw an error if a non External switch is used.
    • Updated unit tests to use template version 1.2.0.
    • Style fixes.
    • Added support for Localization.
  • xHyper-V module:
    • Added vs code formatting rule settings.
    • Fix Markdown rule violations in Readme.md.
    • Added .MetaTestOptIn.json for Markdown common test to be included.
    • Added Appveyor badge for Dev branch in Readme.md and moved to Branches section.
    • Added missing properties for all resources in Readme.md.
    • Added and corrected missing / wrong DataTypes and Dsc attributes in Readme.md.
    • Updated Readme to match DscResources style.
    • Created change log and linked to it from Readme.
    • Removed version info from Readme.
    • Updated appveyor.yml to use Appveyor module.
    • Examples:
      • Removed code from Readme and linked to example files instead.
      • Moved code to new example files where there was only code in Readme.
    • Codecov:
      • Updated appveyor.yml to include codecov.
      • Added .codecov.yml.
      • Added codecov badges to Readme.
  • MSFT_xVHD:
    • Support setting the disk type.
    • Added unit tests.
    • Added example Sample_xVHD_FixedVHD.ps1
    • Style fixes
xNetworking 5.0.0.0
  • Find-NetworkAdapter:
    • Fixed to return null if exception thrown.
    • Allowed passing no selection parameters.
  • MSFT_xNetAdapterName:
    • Fixed bug in Get-TargetResource when Name is the only adapter selector parameter.
    • Improved verbose logging.
    • More improvements to verbose logging.
  • Added Get-DnsClientServerStaticAddress to NetworkingDsc.Common to return statically assigned DNS server addresses to support fix for issue 113.
  • MSFT_xDNSserverAddress:
    • Added support for setting DNS Client to DHCP for issue 113.
    • Added new examples to show how to enable DHCP on DNS Client.
    • Improved integration test coverage to enable testing of multiple addresses and DHCP.
    • Converted exception creation to use common exception functions.
  • MSFT_xDhcpClient:
    • Updated example to also cover setting DNS Client to DHCP.
  • Added the VS Code PowerShell extension formatting settings that cause PowerShell files to be formatted as per the DSC Resource kit style guidelines.
  • MSFT_xDefaultGatewayAddress:
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
  • Updated badges in README.MD to match the layout from PSDscResources.
  • MSFT_xIPAddress:
    • BREAKING CHANGE: Adding support for multiple IP addresses being assigned.
xSQLServer 8.0.0.0
  • BREAKING CHANGE: The module now requires WMF 5.
    • This is required for class-based resources
  • Added new resource
    • xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership
    • Added localization support for all strings.
    • Refactored as a MOF based resource due to challenges with Pester and testing in Powershell 5.
  • Changes to xSQLServer
    • BREAKING CHANGE: xSQLServer does no longer try to support WMF 4.0 (PowerShell 4.0) (issue 574). Minimum supported version of WMF is now 5.0 (PowerShell 5.0).
    • BREAKING CHANGE: Removed deprecated resource xSQLAOGroupJoin (issue 457).
    • BREAKING CHANGE: Removed deprecated resource xSQLAOGroupEnsure (issue 456).
    • BREAKING CHANGE: Removed deprecated resource xSQLServerFailoverClusterSetup (issue 336).
    • Updated PULL_REQUEST_TEMPLATE adding comment block around text. Also rearranged and updated texts (issue 572).
    • Added common helper functions for HQRM localization, and added tests for the helper functions.
      • Get-LocalizedData
      • New-InvalidResultException
      • New-ObjectNotFoundException
      • New-InvalidOperationException
      • New-InvalidArgumentException
    • Updated CONTRIBUTING.md describing the new localization helper functions.
    • Fixed typos in xSQLServer.strings.psd1
    • Fixed CodeCov badge links in README.md so that they point to the correct branch.
    • Added VS Code workspace settings file with formatting settings matching the Style Guideline (issue 645). That will make it possible inside VS Code to press SHIFT+ALT+F, or press F1 and choose “Format document” in the list. The PowerShell code will then be formatted according to the Style Guideline (although maybe not complete, but would help a long way).
      • Removed powershell.codeFormatting.alignPropertyValuePairs setting since it does not align with the style guideline.
      • Added powershell.codeFormatting.preset with a value of “Custom” so that workspace formatting settings are honored (issue 665).
    • Fixed lint error MD013 and MD036 in README.md.
    • Updated .markdownlint.json to enable rule MD013 and MD036 to enforce those lint markdown rules in the common tests.
    • Fixed lint error MD013 in CHANGELOG.md.
    • Fixed lint error MD013 in CONTRIBUTING.md.
    • Added code block around types in README.md.
    • Updated copyright information in xSQLServer.psd1.
    • Opt-in for markdown common tests (issue 668).
      • The old markdown tests has been removed.
  • Changes to xSQLServerHelper
    • Removed helper function Grant-ServerPerms because the deprecated resource that was using it was removed.
    • Removed helper function Grant-CNOPerms because the deprecated resource that was using it was removed.
    • Removed helper function New-ListenerADObject because the deprecated resource that was using it was removed.
    • Added tests for those helper functions that did not have tests.
    • Test-SQLDscParameterState helper function can now correctly pass a CimInstance as DesiredValue.
    • Test-SQLDscParameterState helper function will now output a warning message if the value type of a desired value is not supported.
    • Added localization to helper functions (issue 641).
      • Resolved the issue when using Write-Verbose in helper functions discussed in 641 where Write-Verbose wouldn”t write out verbose messages unless using parameter Verbose.
      • Moved localization strings from xSQLServer.strings.psd1 to xSQLServerHelper.strings.psd1.
  • Changes to xSQLServerSetup
    • BREAKING CHANGE: Replaced StartWin32Process helper function with the cmdlet Start-Process (issue 41, 93 and 126).
    • BREAKING CHANGE: The parameter SetupCredential has been removed since it is no longer needed. This is because the resource now support the built-in PsDscRunAsCredential.
    • BREAKING CHANGE: Now the resource supports using built-in PsDscRunAsCredential. If PsDscRunAsCredential is set, that username will be used as the first system administrator.
    • BREAKING CHANGE: If the parameter PsDscRunAsCredential are not assigned any credentials then the resource will start the setup process as the SYSTEM account. When installing as the SYSTEM account, then parameter SQLSysAdminAccounts and ASSysAdminAccounts must be specified when installing feature Database Engine and Analysis Services respectively.
    • When setup exits with the exit code 3010 a warning message is written to console telling that setup finished successfully, but a reboot is required (partly fixes issue 565).
    • When setup exits with an exit code other than 0 or 3010 a warning message is written to console telling that setup finished with an error (partly fixes issue 580).
    • Added a new parameter SetupProcessTimeout which defaults to 7200 seconds (2 hours). If the setup process has not finished before the timeout value in SetupProcessTimeout an error will be thrown (issue 566).
    • Updated all examples to match the removal of SetupCredential.
    • Updated (removed) severe known issues in README.md for resource xSQLServerSetup.
    • Now all major version uses the same identifier to evaluate InstallSharedDir and InstallSharedWOWDir (issue 420).
    • Now setup arguments that contain no value will be ignored, for example when InstallSharedDir and InstallSharedWOWDir path is already present on the target node, because of a previous installation (issue 639).
    • Updated Get-TargetResource to correctly detect BOL, Conn, BC and other tools when they are installed without SQLENGINE (issue 591).
    • Now it can detect Documentation Components correctly after the change in issue 591 (issue 628)
    • Fixed bug that prevented Get-DscConfiguration from running without error. The return hash table fails if the $clusteredSqlIpAddress variable is not used. The schema expects a string array but it is initialized as just a null string, causing it to fail on Get-DscConfiguration (issue 393).
    • Added localization support for all strings.
    • Added a test to test some error handling for cluster installations.
    • Added support for MDS feature install (issue 486)
      • Fixed localization support for MDS feature (issue 671).
  • Changes to xSQLServerRSConfig
    • BREAKING CHANGE: Removed $SQLAdminCredential parameter. Use common parameter PsDscRunAsCredential (WMF 5.0+) to run the resource under different credentials. PsDscRunAsCredential Windows account must be a sysadmin on SQL Server (issue 568).
    • In addition, the resource no longer uses Invoke-Command cmdlet that was used to impersonate the Windows user specified by $SQLAdminCredential. The call also needed CredSSP authentication to be enabled and configured on the target node, which complicated deployments in non-domain scenarios. Using PsDscRunAsCredential solves this problems for us.
    • Fixed virtual directory creation for SQL Server 2016 (issue 569).
    • Added unit tests (issue 295).
  • Changes to xSQLServerDatabase
    • Changed the readme, SQLInstance should have been SQLInstanceName.
  • Changes to xSQLServerScript
    • Fixed bug with schema and variable mismatch for the Credential/Username parameter in the return statement (issue 661).
    • Optional QueryTimeout parameter to specify sql script query execution timeout. Fixes issue 597
  • Changes to xSQLServerAlwaysOnService
    • Fixed typos in localization strings and in tests.
  • Changes to xSQLServerAlwaysOnAvailabilityGroup
    • Now it utilize the value of “FailoverMode” to set the “FailoverMode” property of the Availability Group instead of wrongly using the “AvailabilityMode” property of the Availability Group.
xStorage 3.2.0.0
  • xDisk:
    • Fix error message when new partition does not become writable before timeout.
    • Removed unneeded timeout initialization code.
  • xDiskAccessPath:
    • Fix error message when new partition does not become writable before timeout.
    • Removed unneeded timeout initialization code.
    • Fix error when used on Windows Server 2012 R2 – See Issue 102.
  • Added the VS Code PowerShell extension formatting settings that cause PowerShell files to be formatted as per the DSC Resource kit style guidelines.
  • Removed requirement on Hyper-V PowerShell module to execute integration tests.
  • xMountImage:
    • Fix error when mounting VHD on Windows Server 2012 R2 – See Issue 105
xWebAdministration 1.18.0.0
  • Added sample for xWebVirtualDirectory for creating a new virtual directory. Bugfix for 195.
  • Added integration tests for xWebVirtualDirectory. Fixes 188.
  • xWebsite:
    • Fixed bugs when setting log properties, fixes 299.
xWindowsUpdate 2.7.0.0
  • xWindowsUpdateAgent: Fix Get-TargetResource returning incorrect key

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available in WMF 5.0) to find modules with DSC Resources:

# To list all modules that are part of the DSC Resource Kit
Find-Module -Tag DSCResourceKit
# To list all DSC resources from all sources 
Find-DscResource

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the xCertificate module, go to:
https://github.com/PowerShell/xCertificate.

All DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Katie Keim
Software Engineer
PowerShell Team
@katiedsc (Twitter)
@kwirkykat (GitHub)

PowerShell 6.0 Roadmap: CoreCLR, Backwards Compatibility, and More!

$
0
0
As we’ve made progress on open-source PowerShell, it’s time to start talking more in-depth about:
  • different editions of PowerShell
  • PowerShell’s relationship to .NET Core and .NET Standard
  • the future of PowerShell
  • when you might expect to start taking a dependency on PowerShell Core 6.0 in production

PowerShell Editions

There are two editions of PowerShell:

Windows PowerShell is the edition of PowerShell built on top of .NET Framework
(sometimes referred to colloquially as “FullCLR”):

  • This is the PowerShell that has been in widespread use for the last ~10 years.
  • Because of it’s dependency on the .NET Framework, Windows PowerShell is only available on Windows (hence the name).
  • The released versions of Windows PowerShell include 1.0, 2.0, 3.0, 4.0, 5.0, and 5.1.
  • Windows PowerShell is available as a built-in component in Windows and Windows Server.
  • On Windows PowerShell 5.0/5.1, $PSVersionTable.PSEdition is set to Desktop.

PowerShell Core is the edition of PowerShell built on top of .NET Core
(sometimes simplified to “CoreCLR”, though it technically includes CoreFX as well).

  • PowerShell Core is cross-platform, available on Windows, macOS, and Linux, thanks to the cross-platform nature of .NET Core.
  • On PowerShell Core, $PSVersionTable.PSEdition is set to Core.

Note: while PowerShell Core 6.0 is cross-platform, there is also a PowerShell Core 5.0/5.1 released exclusively as part of Nano Server.

Compatibility

Our goal with PowerShell Core is to remain as compatible with Windows PowerShell as technically possible. To that end, we’re leveraging a technology called .NET Standard 2.0 to provide binary compatibility with existing .NET assemblies. Many PowerShell modules depend on these assemblies (often times DLLs), so .NET Standard allows them to continue working with .NET Core. You can learn more about .NET Standard on the .NET Blog, YouTube, and via this excellent FAQ on GitHub.

We’ve also done our best to make sure that all aspects of the PowerShell language and “built-in” modules (e.g. Microsoft.PowerShell.Management, Microsoft.PowerShell.Utility, etc.) work the same as they do in Windows PowerShell. In many cases, with the help of our amazing community, we’ve added new capabilities and bug fixes to those cmdlets.

Most of the modules that ship as part of Windows (e.g. DnsClient, Hyper-V, NetTCPIP, Storage, etc.) have not been explicitly ported to .NET Core yet. However, with the promise of .NET Standard and CDXML, many of these traditional Windows PowerShell modules work great in PowerShell Core.

To that end, we ask that you give the latest PowerShell Core beta a try on Windows with your existing modules and scripts, and tell us what does and doesn’t work for you on GitHub. That includes modules available from the PowerShell Gallery. If you’ve tried it in PowerShell Core 6.0, we want to know about it!

When you’re ready to install and give it a try, just hop on over to our README’s install instructions and pick the instructions for your platform of choice. PowerShell Core is completely side-by-side with your existing Windows PowerShell installation, so you don’t have to worry about breaking any of your existing scripts or workloads. Plus, PowerShell Core doesn’t require any reboots at install-time, so you can start using it immediately!

You should also expect a more advanced, developer-oriented blog post from us in the near future about how to:

  • port existing Windows PowerShell modules to PowerShell Core
  • develop new modules that target both Windows PowerShell (downlevel to 3.0) and PowerShell Core

Future of Windows PowerShell

Windows PowerShell 5.1, much like .NET Framework 4.x, will continue to be a built-in, supported component of Windows 10 and Windows Server 2016. However, it will likely not receive major feature updates or lower-priority bug fixes. With PowerShell Core, we are actively addressing bugs that may have existed in previous versions of Windows PowerShell. We’re even open to contributions so that these bug fixes can be made by members of our community.

There are no changes to the support cycles for the shipping version of Windows Management Framework (WMF).

Timeline

Our current timeline is highly dependent on the level of verifiable compatibility between first-/third-party Windows PowerShell modules and PowerShell Core. In other words, by verifying your existing scripts/cmdlets work on PowerShell Core 6.0 (and telling us about it!), the sooner we’ll feel confident in getting to production.

That being said, it is our strong desire to ship a high-quality PowerShell Core 6.0 by the end of the year that you can feel confident about deploying in production. When this happens, we also plan on having more details about how you can use PowerShell Core 6.0 with official support from Microsoft.

Stay tuned!

Joey Aiello
Program Manager, PowerShell

PowerShell Documentation Migration

$
0
0

 

Hi, I’m Zach Alexander and I’m a PM on the PowerShell Team working on documentation.

I wanted to let you know that there will be a brief downtime for online PowerShell documentation.

This downtime will occur on August 2nd and shouldn’t last more than a few hours. We will start around 4:30pm Pacific and estimate we will be back up by 7:30pm.

This downtime is needed so we can move our content off MSDN and onto https://docs.microsoft.com/! Moving to docs.microsoft.com means better community tools, better navigation, and a better reading experience.

This migration will not break most existing links. We will have redirection set up as part of the migration so most links end up going to the correct location. If we missed a link, feel free to file an issue on UserVoice or GitHub. This migration will also not affect our PowerShell Documentation repo on GitHub. We will continue to take suggestions and contributions from that repo, which will be rendered into the documents you see on docs.microsoft.com.

We’re excited to be moving to docs.microsoft.com! We have had a great experience open-sourcing our documentation, and continuing that journey with even better tooling can only mean even better docs!

 

 

PSSwagger – Automatically generate PowerShell cmdlets from OpenAPI (f.k.a Swagger) specification

$
0
0

As a PowerShell enthusiast or DevOps professional, have you ever thought of having a tool that automatically generates PowerShell cmdlets to manage or access a RESTful Web Service? We are happy to share PSSwagger – the PowerShell Cmdlet generator for OpenAPI based web services. At PowerShell Conference Europe 2017, Jeffrey first showcased PSSwagger, and today we are open-sourcing the PSSwagger module and releasing its preview version to the PowerShell Gallery!

Some of the benefits of PSSwagger are:
• One module that works cross-platform – generated modules supports both PowerShell Core and Windows PowerShell 5.1.
• Consistent user experience – the generated PowerShell commands automatically follow the PowerShell cmdlet guidelines and best practices.
• Get additional features for free – paging and asynchronous execution of long running operations.
• Web Service owners can minimize the effort to author PowerShell commands to manage or access their web service.
• Ability to load multiple different versions of a generated module into the same process.

Please refer to the PSSwagger Readme for more details on installing and using it.
You can start using and contributing to PSSwagger today. For any questions or feedback, please let us know on the PSSwagger GitHub or Gitter Channel.

Looking forward!!
PowerShell team

DSC Resource Kit Release August 2017

$
0
0

DSC Resource Kit Release

We just released the DSC Resource Kit!

This release includes updates to 10 DSC resource modules. In these past 6 weeks, 91 pull requests have been merged and 74 issues have been closed, all thanks to our amazing community!

The modules updated in this release are:

  • SecurityPolicyDsc
  • xCertificate
  • xComputerManagement
  • xDhcpServer
  • xDnsServer
  • xExchange
  • xFailOverCluster
  • xNetworking
  • xPSDesiredStateConfiguration
  • xSqlServer

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

Our last community call for the DSC Resource Kit was last week on August 16. A recording of our updates as well as summarizing notes are available. Join us for the next call at 12PM (Pacific time) on September 27 to ask questions and give feedback about your experience with the DSC Resource Kit. You can download a calendar event for the next call here.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

All resources with the ‘x’ prefix in their names are still experimental – this means that those resources are provided AS IS and are not supported through any Microsoft support program or service. If you find a problem with a resource, please file an issue on GitHub.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or Changelog.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
SecurityPolicyDsc 1.5.0.0
  • Refactored user rights assignment to read and test easier.
xCertificate 3.0.0.0
  • Add CodeCov.io code coverage reporting.
  • Opted into “Common Tests – Validate Example Files”.
  • Fixed bugs in examples.
  • Updated License and Manifest Copyright info to be 2017 Microsoft Corporation.
  • xCertReq:
  • Added .github support files:
    • CONTRIBUTING.md
    • ISSUE_TEMPLATE.md
    • PULL_REQUEST_TEMPLATE.md
  • Opted into Common Tests “Validate Module Files” and “Validate Script Files”.
  • Converted files with UTF8 with BOM over to UTF8 – fixes Issue 87.
  • Converted to use auto-documentation/wiki format – fixes Issue 84.
xComputerManagement 2.1.0.0
  • xComputer: Changed comparison that validates if we are in the correct AD Domain to work correctly if FQDN wasn”t used.
  • Updated AppVeyor.yml to use AppVeyor.psm1 module in DSCResource.Tests.
  • Removed Markdown.md errors.
  • Added CodeCov.io support.
  • xScheduledTask
    • Fixed incorrect TaskPath handling – Issue 45
  • Change examples to meet HQRM standards and optin to Example validation tests.
  • Replaced examples in README.MD to links to Example files.
  • Added the VS Code PowerShell extension formatting settings that cause PowerShell files to be formatted as per the DSC Resource kit style guidelines – Issue #91.
  • Opted into Common Tests “Validate Module Files” and “Validate Script Files”.
  • Converted files with UTF8 with BOM over to UTF8 – fixes Issue 90.
  • Updated Year to 2017 in License and Manifest – fixes Issue 87.
  • Added .github support files – fixes Issue 88:
    • CONTRIBUTING.md
    • ISSUE_TEMPLATE.md
    • PULL_REQUEST_TEMPLATE.md
  • Resolved all PSScriptAnalyzer warnings and style guide warnings.
  • xOfflineDomainJoin:
    • Changed to use CommonResourceHelper to load localization strings.
    • Renamed en-US to be correct case so that localization strings can be loaded.
    • Suppress PSScriptAnalyzer rule PSAvoidGlobalVars for $global:DSCMachineStatus = 1.
  • xComputer:
    • Suppress PSScriptAnalyzer rule PSAvoidGlobalVars for $global:DSCMachineStatus = 1.
  • xVirtualMemory:
    • Suppress PSScriptAnalyzer rule PSAvoidGlobalVars for $global:DSCMachineStatus = 1.
xDhcpServer 1.6.0.0
  • Added xDhcpServerClass
xDnsServer 1.8.0.0
  • Converted AppVeyor.yml to pull Pester from PSGallery instead of Chocolatey
  • Fixed bug in xDnsServerADZone causing Get-TargetResource to fail with an extra property.
xExchange 1.16.0.0
  • Add missing parameters to xExchClientAccessServer
xFailOverCluster 1.8.0.0
  • Changes to xFailOverCluster
    • Added a common resource helper module with helper functions for localization.
      • Added helper functions; Get-LocalizedData, New-InvalidResultException, New-ObjectNotFoundException, New-InvalidOperationException and New-InvalidArgumentException.
    • Fixed lint error MD034 and fixed typos in README.md.
    • Opt-in for module files common tests (issue 119).
      • Removed Byte Order Mark (BOM) from the files; CommonResourceHelper.psm1 and FailoverClusters.stubs.psm1.
    • Opt-in for script files common tests (issue 121).
      • Removed Byte Order Mark (BOM) from the files; CommonResourceHelper.Tests.ps1, MSFT_xCluster.Tests.ps1, MSFT_xClusterDisk.Tests.ps1, MSFT_xClusterPreferredOwner.Tests.ps1, MSFT_xWaitForCluster.Tests.ps1.
    • Added common test helper functions to help test the throwing of localized error strings.
      • Get-InvalidArgumentRecord
      • Get-InvalidOperationRecord
      • Get-ObjectNotFoundException
      • Get-InvalidResultException.
    • Updated year to 2017 in license file and module manifest (issue 131).
  • Changes to xClusterDisk
    • Enabled localization for all strings (issue 84).
    • Fixed the OutputType data type that was not fully qualified.
    • Minor style changes.
    • Fixed Script Analyzer warnings for Write-Verbose.
  • Changes to xClusterNetwork
    • Replaced the URL for the parameter Role in README.md. The new URL is a more generic description of the possible settings for the Role parameter. The previous URL was still correct but focused on Hyper-V in particular.
    • Fixed typos in parameter descriptions in README.md, comment-based help and schema.mof.
    • Enabled localization for all strings (issue 85).
    • Minor style changes.
    • Fixed Script Analyzer warnings for Write-Verbose.
  • Changes to xCluster
    • Resolved Script Analyzer rule warnings by changing Get-WmiObject to Get-CimInstance (issue 49).
    • Minor style change in tests. Removed “-” in front of “-Be”, “-Not”, “-Throw”, etc.
    • Enabled localization for all strings (issue 83).
    • Added tests to improve code coverage.
      • Fixed random problem with tests failing with error “Invalid token for impersonation – it cannot be duplicated.” (issue 133).
    • Minor style changes.
    • Fixed Script Analyzer warnings for Write-Verbose.
  • Changes to xWaitForCluster
    • Refactored the unit test for this resource to use stubs and increase coverage (issue 78).
    • Now the Test-TargetResource correctly returns false if the domain name cannot be evaluated (issue 107).
    • Changed the code to be more aligned with the style guideline.
    • Updated parameter description in the schema.mof.
    • Resolved Script Analyzer warnings (issue 54).
    • Enabled localization for all strings (issue 88).
    • Minor style changes.
  • Changes to xClusterQuorum
    • Refactored the unit test for this resource to use stubs and increase coverage (issue 77).
    • Changed the code to be more aligned with the style guideline.
    • Updated parameter description in the schema.mof.
    • Added example (issue 47)
      • 1-SetQuorumToNodeMajority.ps1
      • 2-SetQuorumToNodeAndDiskMajority.ps1
      • 3-SetQuorumToNodeAndFileShareMajority.ps1
      • 4-SetQuorumToDiskOnly.ps1
    • Added links to examples from README.md.
    • Minor style changes.
    • Enabled localization for all strings (issue 87).
  • Changes to xClusterPreferredOwner
    • Enabled localization for all strings (issue 86).
    • Fixed typo in the returned hash table from Get-TargetResource.
    • Minor style changes.
xNetworking 5.1.0.0
  • MSFT_xDhcpClient:
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
  • README.MD:
    • Cleaned up badges by putting them into a table.
  • MSFT_xDnsConnectionSuffix:
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
  • README.MD:
    • Converted badges to use branch header as used in xSQLServer.
  • Added standard .markdownlint.json to configure rules to run on Markdown files.
  • MSFT_xDnsClientGlobalSetting:
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
  • Updated year to 2017 in LICENSE and module manifest.
  • MSFT_xDnsServerAddress:
    • Fix error when setting address on adapter where NameServer Property does not exist in registry for interface – see issue 237.
    • Corrected style and formatting to meet HQRM guidelines.
  • MSFT_xIPAddress:
    • Improved examples to clarify how to set IP Address prefix – see issue 239.
  • MSFT_xFirewall:
    • Fixed bug with DisplayName not being set correctly in some situations – see issue 234.
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
  • Added .github support files:
    • CONTRIBUTING.md
    • ISSUE_TEMPLATE.md
    • PULL_REQUEST_TEMPLATE.md
  • Opted into Common Tests “Validate Module Files” and “Validate Script Files”.
  • Converted files with UTF8 with BOM over to UTF8 – fixes Issue 250.
  • MSFT_xFirewallProfile:
    • Created new resource configuring firewall profiles.
  • MSFT_xNetConnectionProfile:
    • Corrected style and formatting to meet HQRM guidelines.
    • Added validation for provided parameters.
    • Prevent testing parameter values of connection that aren”t set in resource – fixes Issue 254.
    • Improved unit test coverage for this resource.
xPSDesiredStateConfiguration 7.0.0.0
  • xService
    • BREAKING CHANGE: The service will now return as compliant if the service is not installed and the StartupType is set to Disabled regardless of the value of the Ensure property.
  • Fixed misnamed certificate thumbprint variable in example Sample_xDscWebServiceRegistrationWithSecurityBestPractices
xSQLServer 8.1.0.0
  • Changes to xSQLServer
    • Added back .markdownlint.json so that lint rule MD013 is enforced.
    • Change the module to use the image “Visual Studio 2017” as the build worker image for AppVeyor (issue 685).
    • Minor style change in CommonResourceHelper. Added missing [Parameter()] on three parameters.
    • Minor style changes to the unit tests for CommonResourceHelper.
    • Changes to xSQLServerHelper
    • Opt-in for module files common tests (issue 702).
      • Removed Byte Order Mark (BOM) from the files; CommonResourceHelper.psm1, MSFT_xSQLServerAvailabilityGroupListener.psm1, MSFT_xSQLServerConfiguration.psm1, MSFT_xSQLServerEndpointPermission.psm1, MSFT_xSQLServerEndpointState.psm1, MSFT_xSQLServerNetwork.psm1, MSFT_xSQLServerPermission.psm1, MSFT_xSQLServerReplication.psm1, MSFT_xSQLServerScript.psm1, SQLPSStub.psm1, SQLServerStub.psm1.
    • Opt-in for script files common tests (issue 707).
      • Removed Byte Order Mark (BOM) from the files; DSCClusterSqlBuild.ps1, DSCFCISqlBuild.ps1, DSCSqlBuild.ps1, DSCSQLBuildEncrypted.ps1, SQLPush_SingleServer.ps1, 1-AddAvailabilityGroupListenerWithSameNameAsVCO.ps1, 2-AddAvailabilityGroupListenerWithDifferentNameAsVCO.ps1, 3-RemoveAvailabilityGroupListenerWithSameNameAsVCO.ps1, 4-RemoveAvailabilityGroupListenerWithDifferentNameAsVCO.ps1, 5-AddAvailabilityGroupListenerUsingDHCPWithDefaultServerSubnet.ps1, 6-AddAvailabilityGroupListenerUsingDHCPWithSpecificSubnet.ps1, 2-ConfigureInstanceToEnablePriorityBoost.ps1, 1-CreateEndpointWithDefaultValues.ps1, 2-CreateEndpointWithSpecificPortAndIPAddress.ps1, 3-RemoveEndpoint.ps1, 1-AddConnectPermission.ps1, 2-RemoveConnectPermission.ps1, 3-AddConnectPermissionToAlwaysOnPrimaryAndSecondaryReplicaEachWithDifferentSqlServiceAccounts.ps1, 4-RemoveConnectPermissionToAlwaysOnPrimaryAndSecondaryReplicaEachWithDifferentSqlServiceAccounts.ps1, 1-MakeSureEndpointIsStarted.ps1, 2-MakeSureEndpointIsStopped.ps1, 1-EnableTcpIpWithStaticPort.ps1, 2-EnableTcpIpWithDynamicPort.ps1, 1-AddServerPermissionForLogin.ps1, 2-RemoveServerPermissionForLogin.ps1, 1-ConfigureInstanceAsDistributor.ps1, 2-ConfigureInstanceAsPublisher.ps1, 1-WaitForASingleClusterGroup.ps1, 2-WaitForMultipleClusterGroups.ps1.
    • Updated year to 2017 in license file (issue 711).
    • Code style clean-up throughout the module to align against the Style Guideline.
    • Fixed typos and the use of wrong parameters in unit tests which was found after release of new version of Pester (issue 773).
  • Changes to xSQLServerAlwaysOnService
    • Added resource description in README.md.
    • Updated parameters descriptions in comment-based help, schema.mof and README.md.
    • Changed the datatype of the parameter to Uint32 so the same datatype is used in both the Get-/Test-/Set-TargetResource functions as in the schema.mof (issue 688).
    • Added read-only property IsHadrEnabled to schema.mof and the README.md (issue 687).
    • Minor cleanup of code.
    • Added examples (issue 633)
      • 1-EnableAlwaysOn.ps1
      • 2-DisableAlwaysOn.ps1
    • Fixed PS Script Analyzer errors (issue 724)
    • Casting the result of the property IsHadrEnabled to [System.Boolean] so that $null is never returned, which resulted in an exception (issue 763).
  • Changes to xSQLServerDatabasePermission
    • Fixed PS Script Analyzer errors (issue 725)
  • Changes to xSQLServerScript
    • Fixed PS Script Analyzer errors (issue 728)
  • Changes to xSQLServerSetup
    • Added Swedish localization (issue 695).
    • Now Get-TargetResource correctly returns an array for property ASSysAdminAccounts, and no longer throws an error when there is just one Analysis Services administrator (issue 691).
    • Added a simple integration test (issue 709).
    • Fixed PS Script Analyzer errors (issue 729)

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available in WMF 5.0) to find modules with DSC Resources:

# To list all modules that are part of the DSC Resource Kit
Find-Module -Tag DSCResourceKit
# To list all DSC resources from all sources 
Find-DscResource

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the xCertificate module, go to:
https://github.com/PowerShell/xCertificate.

All DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Katie Keim
Software Engineer
PowerShell DSC Team
@katiedsc (Twitter)
@kwirkykat (GitHub)

Windows PowerShell 2.0 Deprecation

$
0
0

We recently announced that Windows PowerShell 2.0 is being deprecated in the Windows 10 Fall Creators Update. Deprecation is a process whereby technologies or applications are marked as legacy, signalling to users that they may be removed in the future, and that should move away from them and towards newer alternatives.

We do not currently have a timeline to remove Windows PowerShell 2.0, but as we continue to evaluate its usage in the PowerShell ecosystem, we will be working to remove it in a future release. When this decision is made, we will give plenty of notice via official Windows deprecation channels (like the above support link), as well as this blog. However, at this time, we recognize that it’s usage is still prevalent, and we won’t make this decision without giving ample time for users to migrate away from it.

I’m a PowerShell expert, just give me the quick version

If you’re very familiar with the PowerShell ecosystem, this is a quick guide for moving off of Windows PowerShell 2.0. If not, read on through the rest of the blog for a better explanation of the technical details.

If you’re running any scripts using powershell -version 2, you should use a later version of PowerShell (like Windows PowerShell 5.1 or PowerShell Core 6.0).

If you’re hosting any PowerShell assemblies (e.g. System.Management.Automation.dll) in a .NET CLR2 (i.e. .NET Framework 2.0 – 3.5) application, you should work to move your application to CLR4 (i.e. .NET Framework 4.6+) or .NET Core.

What is Windows PowerShell 2.0?

Windows PowerShell 2.0 first shipped as the version of Windows PowerShell built into Windows 7 (where it was not an optional feature). It was also shipped, via the Windows Management Framework (WMF) to older versions of Windows, including:

  • Windows Server 2008
  • Windows Vista
  • Windows Server 2003
  • Windows XP

When Windows PowerShell 3.0 was released as part of Windows 8, Server 2008 R2, and WMF 3.0, Windows PowerShell moved to a newer version of the .NET Framework (CLR4) that was not compatible older applications. In order to maintain backwards compatibility with these older applications, we kept Windows PowerShell 2.0 as an optional, side-by-side component in later versions of Windows and Windows Server. You could take advantage of this optional component by using powershell -version 2 to start the older version of the engine, or by continuing to use a PowerShell assembly in a .NET CLR2 application. Note: specifying any version higher than 2 with -version (e.g. 3, 4, or 5) will load the latest, non-2.0 version of Windows PowerShell on the machine, regardless of the number specified.

Why is it being deprecated?

Windows PowerShell 5.x has some great new features that enhance security including enhanced transcription logging and AMSI protection.

As PowerShell Core 6.0 enters the marketplace, we’d like to reduce the complexity of the PowerShell ecosystem. Removing an outdated version of .NET from the equation makes development easier for cmdlet and script authors by focusing on the .NET Standard ecosystem that includes only .NET Framework 4.6+ and .NET Core 2.0.

What does this mean for me?

You can check whether Windows PowerShell 2.0 is installed by running the following (as an administrator).

On Windows 7/8.1/10, the following will return a State as either Enabled or Disabled:

Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2

On Windows Server, the following will return an InstallState of either Installed or Removed:

Get-WindowsFeature PowerShell-V2

If Windows PowerShell 2.0 is not installed on your machine(s) and everything is working fine, you probably don’t need to worry about deprecation.

If Windows PowerShell 2.0 is installed, there are a few cases where you might be using it:

Scripting with Windows PowerShell 2.0

  • You’re running powershell.exe -version 2 (often shortened to powershell -v 2) when running scripts or as a shell. This is the easiest to mitigate: simply try running your scripts without the -version 2. If it works fine, stop using -version 2.
  • You’re running a PowerShell script that calls #requires -version 2 at the top. If Windows PowerShell 2.0 is installed, this will automatically start and run the script with it regardless of where the script is executed. (Note: if Windows PowerShell 2.0 is not installed, this line is ignored and the script is executed with whatever version of Windows PowerShell is installed.)

Hosting Windows PowerShell 2.0 in a .NET 2.0/3.5 Application

If you’ve developed an application with .NET 2.0/3.5 (aka CLR2), and you’re hosting a PowerShell assembly like System.Management.Automation.dll, then you’re using the Windows PowerShell 2.0 version of those assemblies. If this is the case, you should work to migrate your application to .NET 4.6+ (aka CLR4) using reference assmeblies from Windows PowerShell 3.0 or later. That way, you’ll be using the latest version of the Windows PowerShell assemblies available on the box. (Note: this may require that your Windows 7 or Server 2008 R2 users install .NET 4.6+ and/or WMF 3.0 or higher.)

Installation Checks for Windows PowerShell 2.0

You may also have a legacy application that checks for the existence of Windows PowerShell on the box via the registry, particularly for the existence of HKLM:\Software\Microsoft\Windows\PowerShell\1\PowerShellEngine. As long as your application only targets supported versions of Windows and Windows Server (7/8.1/10 and Server 2008R2/2012/2012R2/2016), you can remove this validation altogether.

If not, you should instead check for the existence of the file %systemroot%\system32\WindowsPowerShell\v1.0\powershell.exe. If your installer absolutely requires a registry-based validations, you should first check for HKLM:\Software\Microsoft\Windows\PowerShell\3\PowerShellEngine (note the 3) before falling back to HKLM:\Software\Microsoft\Windows\PowerShell\1\PowerShellEngine.

Using a Microsoft Application Leveraging Windows PowerShell 2.0

There are a number of first-party Microsoft applications that continue to use Windows PowerShell 2.0 under the hood, including some System Center applications, some versions of SQL Server, some versions of Exchange, and others. We will be working with these teams over the coming months to migrate them off of Windows PowerShell 2.0. In the meantime, Windows PowerShell 2.0 will remain a part of Windows 10 and Windows Server 2016, and we have no plans to remove it until those dependencies are mitigated.

That’s it!

In summary, the deprecation of Windows PowerShell 2.0 doesn’t mean that it’s being removed yet, but you should work to move off of it, as we may decide to remove it in a future release. When we do have more concrete plans to remove it, we’ll give fair warning before taking it out. In the meantime, do your best to migrate away from it, using the above as a guide.

Joey Aiello
Program Manager, PowerShell


DSC Future Direction Update

$
0
0

PowerShell Core and DSC

PowerShell is open sourced and moving over to .Net Standard 2.0 for the reasons outlined in Jeffrey’s blog post. Like PowerShell, PowerShell Desired State configuration (DSC) needs to meet customers in this multi-platform, multi-cloud, multi-OS world where they live. In Joey’s blog post, he outlined what this means to the future of PowerShell. What does all of this mean for DSC going forward?

In this post, we will discuss what direction we plan to take DSC including:

  • The DSC engine / local configuration manager (LCM)
  • DSC cmdlets
  • DSC Azure Extension
  • On-prem DSC pull server

Editions

Windows PowerShell Desired State Configuration is included as part of Windows PowerShell

  • Requires WMI
  • Ships as part of Windows and Windows Management Framework (WMF)
  • Requires Windows PowerShell 4.0, 5.0, 5.1
  • Supports resources written in native C (WMI based) and PowerShell
  • Cmdlets use WinRM or CIM for remote connections

DSC on Linux is open source version for Linux SKUs

  • Requires OMI
  • Supports resources written in native C and Python
  • Is not at feature parity with Windows DSC
  • Is separate open source code base

Desired State Configuration Core (DSC Core) is a soon to be released version of DSC that aligns with PowerShell Core

  • No dependency on WMI
  • No dependency on WMF
  • Xcopy-able package
  • Supports resources written in native C/C++ (no WMI), Python and PowerShell
  • Runs on Windows and Linux
  • Required (includes in package) PowerShell Core and .NET Core

Note: The above descriptions are based on current plans and implementation and may change slightly upon release

Philosophy for DSC Core

Our goals with DSC Core are to minimize dependencies on other technologies, provided a single DSC for all platforms, and position it better for cloud scale configuration while maintaining compatibility with Windows PowerShell Desired State Configuration.

As noted above, Windows PowerShell Desired State Configuration has dependencies on a number of other technologies. As a Windows component, this made sense since most if not all of these components were already part of Windows. The side effects of these dependencies (ex. WMF), however, include larger package sizes, upgrade complications due to other product’s use of these components, reboots required during installation, etc. For these reasons and more, DSC Core will reduce its dependencies on other technologies as much as possible.

What does this mean for compatibility?

  • DSC Resources: There will be support for native C resources, PowerShell 6 and Python (on Linux) supported resources. All existing and new DSC resources that use supported.NET standard 2.0 commands will work with DSC Core.
  • Cmdlets: The existing cmdlets will not work with DSC Core. A new set of cmdlets will be provided for use with DSC Core. We will do our best to maintain backward compatibility of these new cmdlets with Windows PowerShell DSC as well as maintaining script compatibility (ie. cmdlets will have same names and parameters). We are looking for feedback from the community on how important having backwards compatibility in these cmdlets is so, if you have an opinion, please add your comment to this post.
  • Azure DSC Extension: A new Azure extension will be provided that uses DSC Core.
  • Pull Server: The existing protocol that DSC uses to communicate with the Pull Server will be supported by DSC Core so existing Pull Server as well as Azure Automation DSC(AA DSC) will be compatible with DSC Core.
  • Configurations: Configuration scripts will be fully supported and will require no changes. They will just need to be compiled in PowerShell 6.

Note: The above compatibility is based on current plans and implementation. Since this is still a work in progress some things may change slightly upon release.

Although DSC exists for Windows and Linux currently, they are separate projects. They each have, for example, their own code base, features and defaults, etc. DSC Core will be a single project for all platforms. This means that features and functionality will be common whether you are using Windows or Linux. And more importantly, going forward new features, fixes, etc. will be available for both Windows and Linux.

Lastly, key portions of DSC Core are being rearchitected to better support cloud scale configuration. As an example, our intent is to support multiple versions of DSC Core side by side while retaining the DSC promise of a known end state. This enable scenarios like having some configuration that are “Autocorrected” every 15 min while other configurations are “Monitored” every 6 hours. This type of flexibility combined with a small xcopy-able package will make DSC Core much more flexible and scalable in the cloud world.

WMF version of DSC

What happens to Windows PowerShell Desired State Configuration when DSC Core is released? As a Windows product, Windows PowerShell Desired State Configuration will continue to be supported and security fixes will be released for it but all new features and functionality will be driven in and release in DSC Core.

You will be able to run Windows PowerShell Desired State Configuration and DSC Core side by side but in order to prevent undetectable conflicts between the two agent’s configurations, this should be treated as a migration scenario with the goal of eventually moving to DSC Core and disabling Windows PowerShell Desired State Configuration.

Pull Server

On-prem

The on-prem pull server is the Windows feature that ships with Windows since 2012 R2 and is included in WMF. There are three versions: 4.0, 5.0 and 5.1.

I am sure you have noticed that we did not discuss the Pull server in many of the above sections. There are a couple of reasons for this. First, since it is an extremely important but separate part of DSC, it deserves its own section. Second, we are still working on what the future of this looks like.

That said, we are committed to supporting and fixing critical security and performance issues with the on-prem pull server while we lock down on our plan for providing solutions for all of our customers whether you are in the Hybrid cloud, moving from on-prem to the cloud or staying on-prem. We want to be transparent with you so that we can ensure that we are going down the right path with this and all things DSC so expect an update on this in the coming months.

Azure Configuration Management (Azure Automation DSC)

Azure Automation DSC is the recommended pull server solution for enterprise and cloud environments. It supports both Windows PowerShell Desired State Configuration and will support DSC Core. It is and will remain our premium managed service. This provides the functionality of the in-box DSC Pull server and much, much more. Some of the additional goodies that you get with Azure Automation DSC are as follows:

  • Hosted Service (no infrastructure for you to manage)
  • Highly scalable pull service
  • Configuration status reporting
  • Central management that supports Azure Portal, PowerShell, Azure CLI, and Rest API iteration
  • Highly extensible through close integration with Automation Runbooks
  • Fast release cycle so you get new features and fixes faster

Timeline

There is a ton of work that we want to do here, much of which is already in flight. Instead of holding everything until we are done, we will enable specific scenarios and then release. Our first release will be focused on Azure scenarios and will be release through the Azure DSC extension. The first release is expected to be around the end of the calendar year. From there we will be taking advantage of the faster release cadence available in the cloud to push new features and functionality first through the Azure DSC extension and then we will release as a downloadable package. ETA for this package is not yet determined, but we will publish a roadmap that we will keep updated here.

We are really looking forward to getting your feedback and sharing all of the work that we have been putting into DSC Core with you so don’t touch that dial.

Mark Gray, DSC Program Manager
Indhu Sivaramakrishnan, DSC Software Engineering Manager

PowerShell in Azure Cloud Shell (Preview) is now publically available in Azure Portal

$
0
0

Yesterday, at IGNITE 2017, we announced the public availability of PowerShell in Azure Cloud Shell. With the addition of PowerShell in Cloud Shell, alongside Bash in Azure Cloud Shell, you now have the flexibility to choose the shell experience that works best for you.

Thank you to our private preview users who helped shape the current experience by providing valuable feedback via issues and feature requests. We encourage you to continue your support by sharing your thoughts, experience, and input through the Azure Cloud Shell UserVoice.

Hemant Mahawar – @HemanMahawar
Principal Program Manager
PowerShell Team

DSC Resource Kit Release October 2017

$
0
0
We just released the DSC Resource Kit!This release includes updates to 6 DSC resource modules. In these past 6 weeks, 52 pull requests have been merged and 39 issues have been closed, all thanks to our amazing community!

The modules updated in this release are:

  • SecurityPolicyDsc
  • SharePointDsc
  • xAdcsDeployment
  • xComputerManagement
  • xNetworking
  • xSqlServer

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

Our last community call for the DSC Resource Kit was last week on September 27. A recording of our updates as well as summarizing notes will be available soon. Join us for the next call at 12PM (Pacific time) on November 8 to ask questions and give feedback about your experience with the DSC Resource Kit.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

All resources with the ‘x’ prefix in their names are still experimental – this means that those resources are provided AS IS and are not supported through any Microsoft support program or service. If you find a problem with a resource, please file an issue on GitHub.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or Changelog.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
SecurityPolicyDsc 2.0.0.0
  • Added SecurityOption and AccountPolicy
  • Removed SecuritySetting
SharePointDsc 1.9.0.0
  • New resource: SPServiceIdentity
xAdcsDeployment 1.2.0.0
  • xAdcsWebEnrollment:
    • xAdcsWebEnrollment.psm1 – Change reference and variable from CAType to CAConfig
xComputerManagement 3.0.0.0
  • xComputer: Added parameter to set the local computer description along with documentation and unit tests for this change.
  • BREAKING CHANGE: xScheduledTask:
    • Converted all Interval/Duration type parameters over to be string format to prevent the Timezone the MOF file was created in from being stored. This is to fix problems where MOF files are created in one timezone but deployed nodes to a different timezone – See Issue 85
    • Added ConvertTo-TimeSpanFromScheduledTaskString function and refactored to reduce code duplication.
    • Added support for setting repetition duration to Indefinitely.
  • xComputer:
    • Moved strings to localization file.
    • Updated to meet HQRM guidelines.
  • xVirtualMemory:
    • Refactored shared common code into new utility functions to reduce code duplication and improve testability.
    • Moved strings into localizable strings file.
    • Converted calls to throw to use New-InvalidOperationException in CommonResourceHelper.
    • Improved unit test coverage.
    • Updated to meet HQRM guidelines.
xNetworking 5.2.0.0
  • Added Documentation and Examples section to Readme.md file – see issue 259.
  • Prevent unit tests from DSCResource.Tests from running during test execution fixes Issue 264.
  • MSFT_xNetworkTeamInterface:
    • Updated Test-TargetResource to substitute VLANID value 0 to $null
  • MSFT_xNetAdapterRsc:
    • Created new resource configuring Rsc
  • MSFT_xNetAdapterRss:
    • Created new resource configuring Rss
  • MSFT_xHostsFile:
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
xSQLServer 8.2.0.0
  • Changes to xSQLServer
    • Updated appveyor.yml so that integration tests run in order and so that the SQLPS module folders are renamed to not disturb the units test, but can be renamed back by the integration tests xSQLServerSetup so that the integration tests can run successfully (issue 774).
    • Changed so the maximum version to be installed is 4.0.6.0, when running unit tests in AppVeyor. Quick fix until we can resolve the unit tests (see issue 807).
    • Moved the code block, that contains workarounds in appveyor.yml, so it is run during the install phase instead of the test phase.
    • Fix problem with tests breaking with Pester 4.0.7 (issue 807).
  • Changes to xSQLServerHelper
    • Changes to Connect-SQL and Import-SQLPSModule
      • Now it correctly loads the correct assemblies when SqlServer module is present (issue 649).
      • Now SQLPS module will be correctly loaded (discovered) after installation of SQL Server. Previously resources depending on SQLPS module could fail because SQLPS was not found after installation because the PSModulePath environment variable in the (LCM) PowerShell session did not contain the new module path.
    • Added new helper function “Test-ClusterPermissions” (issue 446).
  • Changes to xSQLServerSetup
    • Fixed an issue with trailing slashes in the “UpdateSource” property (issue 720).
    • Fixed so that the integration test renames back the SQLPS module folders if they was renamed by AppVeyor (in the appveyor.yml file) (issue 774).
    • Fixed so integration test does not write warnings when SQLPS module is loaded (issue 798).
    • Changes to integration tests.
      • Moved the configuration block from the MSFT_xSQLServerSetup.Integration.Tests.ps1 to the MSFT_xSQLServerSetup.config.ps1 to align with the other integration test. And also get most of the configuration in one place.
      • Changed the tests so that the local SqlInstall account is added as a member of the local administrators group.
      • Changed the tests so that the local SqlInstall account is added as a member of the system administrators in SQL Server (Database Engine) – needed for the xSQLServerAlwaysOnService integration tests.
      • Changed so that only one of the Modules-folder for the SQLPS PowerShell module for SQL Server 2016 is renamed back so it can be used with the integration tests. There was an issue when more than one SQLPS module was present (see more information in issue 806).
      • Fixed wrong variable name for SQL service credential. It was using the integration test variable name instead of the parameter name.
      • Added ErrorAction “Stop” to the cmdlet Start-DscConfiguration (issue 824).
  • Changes to xSQLServerAlwaysOnAvailabilityGroup
    • Change the check of the values entered as parameter for BasicAvailabilityGroup. It is a boolean, hence it was not possible to disable the feature.
    • Add possibility to enable/disable the feature DatabaseHealthTrigger (SQL Server 2016 or later only).
    • Add possibility to enable the feature DtcSupportEnabled (SQL Server 2016 or later only). The feature currently can’t be altered once the Availability Group is created.
    • Use the new helper function “Test-ClusterPermissions”.
    • Refactored the unit tests to allow them to be more user friendly. Added the following read-only properties to the schema (issue 476)
      • EndpointPort
      • EndpointURL
      • SQLServerNetName
      • Version
    • Use the Get-PrimaryReplicaServerObject helper function
  • Changes to xSQLServerAlwaysOnAvailabilityGroupReplica
    • Fixed the formatting for the AvailabilityGroupNotFound error.
    • Added the following read-only properties to the schema (issue 477)
      • EndpointPort
      • EndpointURL
    • Use the new helper function “Test-ClusterPermissions”.
    • Use the Get-PrimaryReplicaServerObject helper function
  • Changes to xSQLServerHelper
    • Fixed Connect-SQL by ensuring the Status property returns “Online” prior to returning the SQL Server object (issue 333).
  • Changes to xSQLServerRole
    • Running Get-DscConfiguration no longer throws an error saying property Members is not an array (issue 790).
  • Changes to xSQLServerMaxDop
    • Fixed error where Measure-Object cmdlet would fail claiming it could not find the specified property (issue 801)
  • Changes to xSQLServerAlwaysOnService
    • Added integration test (issue 736).
      • Added ErrorAction “Stop” to the cmdlet Start-DscConfiguration (issue 824).
    • Changes to SMO.cs
      • Added default properties to the Server class
        • AvailabilityGroups
        • Databases
        • EndpointCollection
      • Added a new overload to the Login class
      • Added default properties to the AvailabilityReplicas class
        • AvailabilityDatabases
        • AvailabilityReplicas
      • Added new resource xSQLServerAccount (issue 706)
        • Added localization support for all strings
        • Added examples for usage
      • Changes to xSQLServerRSConfig
        • No longer returns a null value from Test-TargetResource when Reporting Services has not been initialized (issue 822).
        • Fixed so that when two Reporting Services are installed for the same major version the resource does not throw an error (issue 819).
        • Now the resource will restart the Reporting Services service after initializing (issue 592). This will enable the Reports site to work.
        • Added integration test (issue 753).
        • Added support for configuring URL reservations and virtual directory names (issue 570)

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available in WMF 5.0) to find modules with DSC Resources:

# To list all modules that are part of the DSC Resource Kit
Find-Module -Tag DSCResourceKit
# To list all DSC resources from all sources 
Find-DscResource

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the xCertificate module, go to:
https://github.com/PowerShell/xCertificate.

All DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Katie Keim
Software Engineer
PowerShell DSC Team
@katiedsc (Twitter)
@kwirkykat (GitHub)

Polaris – simple Microservices using only PowerShell

$
0
0

Polaris – Simple Microservices using only PowerShell

Polaris is a cross-platform, minimalist web framework for PowerShell Core 6. With 6 lines of code, you have your very own webserver running and ready to accept requests – all within PowerShell:

New-GetRoute -Path "/json" -ScriptBlock {
    param($request,$response);

    $json = @{ Hello = "World"; TestingTesting = @(1,2,3); }

    $response.Json(($json | ConvertTo-Json));
}

Start-Polaris
PS /> Invoke-RestMethod http://localhost:8080/json

Hello TestingTesting
----- --------------
World {1, 2, 3}

Disclaimer

We open sourced this as an experiment. It’s not an officially supported Microsoft library and there is no plan yet to do so. However, we are listening to the community to determine if this work is important enough to continue investing in.

Why we made Polaris

PowerShell is evolving and we want to experiment with other use cases for PowerShell. With .NET Standard 2.0 out, we were able to get our hands on the .NET HttpListener class originally from the .NET Framework. With it comes a solution that works anywhere that PowerShell does.

We also wanted to give those that are really familiar with PowerShell a way to run their own webservers to allow for a language-agnostic way to run PowerShell scripts thanks to HTTP. Imagine a mobile app triggering remote PowerShell scripts all through HTTP. Or hosting a static site and interacting with an external API all using PowerShell for server code.

We’re excited to see all the use cases emerge and receive feedback from PowerShell’s already incredible community.

Roadmap

We have a few paths we are interested in taking. We hope the community helps direct us.

  • Expanding on the current implementation using HttpListener to deliver features you’d expect from projects ASP.NET or Express.js (route parameters, query parameters, middleware etc)
  • Investigating the use of Kestrel/ASP.NET Routing instead of HttpListener
  • Support for Windows PowerShell (5.x and lower)
  • Creating a routing domain-specific language (DSL) for isolating and running script blocks as routes. Drawing inspiration from Pester.

We’re open-sourcing this really early on so that we can receive feedback from you. To get started with Polaris, hop on over to the project’s GitHub. We’re excited to hear what you have to say.

Tyler Leonhardt
Software Engineer
PowerShell Community and Tools

Navigate Azure Resources Just Like a File System

$
0
0

At Microsoft Ignite (around 8:15 min), we announced the Public Preview of PowerShell in Azure Cloud Shell.  A unique feature of PowerShell experience in Azure Cloud Shell is navigation of Azure resources via the Azure drive (Azure:).  Today, we are making this feature available on PowerShell Gallery as well as making the source code available on GitHub. This enables you to navigate Azure resources from any machine running Windows PowerShell 5 or higher.

Simple Hierarchy in PowerShell (SHiPS) – An Easier Way to Build PowerShell Providers

AzurePSDrive is built on top of an abstraction layer – SHiPS, which simplifies developing PowerShell providers.  SHiPS is also a PowerShell provider that exposes datastores in a hierarchical manner (like a file system). In other words, the data in your datastore can be treated like files and directories so that a user can navigate data via cd or dir commands.

Writing a PowerShell provider can be challenging as one needs to implement various methods exposed by the base PowerShell provider classes and interfaces to make it work. SHiPS simplifies this experience by exposing fewer methods and enables PowerShell providers to be written using PowerShell classes syntax.

Now, SHiPS module is also available through PowerShell Gallery as well as its source code is available via GitHub.

With SHiPS, you can:

  • Author PowerShell providers using PowerShell classes as well as C#
  • Navigate the data store using Get-Item and Get-ChildItem cmdlets
  • Build navigation model that works on both Windows PowerShell (.Net FullCLR) and PowerShell Core (.Net CoreCLR)

Built on Top of Community Contribution

SHiPS is built on top of P2F (PowerShell Provider Framework), created by Jim Christopher, which does the heavy lifting for the implementation of SHiPS.  SHiPS with P2F provides the simplification of developing PowerShell provider.

User Experience

Once a SHiPS-based navigation is defined, such as AzurePSDrive, users can easily create a PSDrive by installing the modules from the PowerShell Gallery.

Update-Module AzureRM         # refresh AzureRM modules to the latest version
Install-Module AzurePSDrive   # will install SHiPS as its dependency
Import-Module AzurePSDrive
Login-AzureRmAccount 
New-PSDrive -Name Azure -PSProvider SHiPS -root 'AzurePSDrive#Azure'
cd Azure:
PS Azure:\>dir

In this example, AzurePSDrive is a PowerShell module written using PowerShell classes. It defines a PowerShell class called Azure as the PowerShell provider root. The syntax for root parameter of PSDrive for SHiPS provider is Module#ClassName. During New-PSDrive, SHiPS loads the module, AzurePSDrive, and creates an instance of an ‘Azure’ object. When a user types dir, SHiPS calls GetChildItem() implemented within the Azure class.

For more information, see SHiPS design documents, public APIs and samples.

Call to Action

Try AzurePSDrive on your machine or in Azure Cloud Shell and build PowerShell providers using SHiPS. Provide your feedback, bugs, and feature requests through Github Issues.

Jianyun Tao
Principal Software Engineer
PowerShell Team

Viewing all 1519 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>