PowerShell Core 6 Release Candidate

This post was originally published on this site

PowerShell Core 6 Release Candidate

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

PowerShell Team ♥ Community

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

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

Roadmap to General Availability and the Future

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

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

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

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

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

PowerShell Core 6 Support

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

Thanks to everyone for their support and contributions!

Steve Lee
Principal Engineer Manager
PowerShell Team

HP Proliant 380G9 with H241 sas card

This post was originally published on this site


I have installed ESXi in HP Proliant 380G9, it has a Dual SAS port H241 controller

The problem that I have is that the OS only sees 1 port. I updated the firmware and drivers, and the issue is still there.

Any idea?

[root@USN:~] esxcli storage core adapter list

HBA Name  Driver  Link State UID Capabilities  Description

——–  —— ———- ——————– ———— ————————————————————

vmhba0    hpsa link-n/a sas.5001438042300370 (0000:03:00.0) Hewlett Packard Enterprise Smart Array P440ar

vmhba1    hpsa link-n/a sas.5001438040f60320 (0000:08:00.0) Hewlett Packard Enterprise Smart HBA H241


Thanks and regards

DSC Resource Kit Release November 2017

This post was originally published on this site

We just released the DSC Resource Kit!

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

The modules updated in this release are:

  • SecurityPolicyDsc
  • xAdcsDeployment
  • xComputerManagement
  • xDnsServer
  • xExchange
  • xNetworking
  • xPSDesiredStateConfiguration
  • xSQLServer
  • xStorage
  • xWebAdministration

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 Novemeber 8. 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 December 20 to ask questions and give feedback about your experience with the DSC Resource Kit.
Also, due to the Christmas holiday, the next DSC Resource Kit release will go out on Decemeber 20 instead of the normal 6-week cadence which would be December 27.

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
  • Updated SecurityOption to handle multi-line logon messages
  • SecurityOption: Added logic and example to handle scenario when using Interactive_logon_Message_text_for_users_attempting_to_log_on
  • Updated to meet HQRM guidelines – fixes issue 33.
  • Fixed markdown rule violations in README.MD.
  • 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.
  • Opted into Common Tests “Validate Module Files” and “Validate Script Files”.
  • Corrected description in manifest.
  • Added .github support files:
  • Resolved all PSScriptAnalyzer warnings and style guide warnings.
  • Converted all tests to meet Pester V4 guidelines – fixes issue 32.
  • Fixed spelling mistakes in README.MD.
  • Fix to ensure exception thrown if failed to install or uninstall service – fixes issue 3.
  • Converted AppVeyor.yml to use shared AppVeyor module in DSCResource.Tests – fixes issue 29.
  • xOfflineDomainJoin:
    • Updated to meet HQRM guidelines.
  • Added resource xDnsServerSetting
  • MSFT_xDnsRecord: Added DnsServer property
  • Fix issue where test for Unlimited quota fails if quota is not already set at Unlimited
  • MSFT_xProxySettings:
    • Created new resource configuring proxy settings.
  • MSFT_xDefaultGatewayAddress:
    • Correct 2-SetDefaultGateway.md address family and improve example description – fixes Issue 275.
  • MSFT_xIPAddress:
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
    • Changed unit tests so that they can be run in any order.
  • MSFT_xNetAdapterBinding:
    • Corrected style and formatting to meet HQRM guidelines.
    • Converted exceptions to use ResourceHelper functions.
  • xDSCWebService
    • BREAKING CHANGE: The Pull Server will now run in a 64 bit IIS process by default. Enable32BitAppOnWin64 needs to be set to TRUE for the Pull Server to run in a 32 bit process.
  • Changes to xSQLServer
    • Updated Pester syntax to v4
    • Fixes broken links to issues in the CHANGELOG.md.
  • Changes to xSQLServerDatabase
    • Added parameter to specify collation for a database to be different from server collation (issue 767).
    • Fixed unit tests for Get-TargetResource to ensure correctly testing return values (issue 849)
  • Changes to xSQLServerAlwaysOnAvailabilityGroup
    • Refactored the unit tests to allow them to be more user friendly and to test additional SQLServer variations.
      • Each test will utilize the Import-SQLModuleStub to ensure the correct module is loaded (issue 784).
    • Fixed an issue when setting the SQLServer parameter to a Fully Qualified Domain Name (FQDN) (issue 468).
    • Fixed the logic so that if a parameter is not supplied to the resource, the resource will not attempt to apply the defaults on subsequent checks (issue 517).
    • Made the resource cluster aware. When ProcessOnlyOnActiveNode is specified, the resource will only determine if a change is needed if the target node is the active host of the SQL Server instance (issue 868).
  • Changes to xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership
    • Made the resource cluster aware. When ProcessOnlyOnActiveNode is specified, the resource will only determine if a change is needed if the target node is the active host of the SQL Server instance (issue 869).
  • Changes to xSQLServerAlwaysOnAvailabilityGroupReplica
    • Made the resource cluster aware. When ProcessOnlyOnActiveNode is specified, the resource will only determine if a change is needed if the target node is the active host of the SQL Server instance (issue 870).
  • Added the CommonTestHelper.psm1 to store common testing functions.
    • Added the Import-SQLModuleStub function to ensure the correct version of the module stubs are loaded (issue 784).
  • Changes to xSQLServerMemory
    • Made the resource cluster aware. When ProcessOnlyOnActiveNode is specified, the resource will only determine if a change is needed if the target node is the active host of the SQL Server instance (issue 867).
  • Changes to xSQLServerNetwork
    • BREAKING CHANGE: Renamed parameter TcpDynamicPorts to TcpDynamicPort and changed type to Boolean (issue 534).
    • Resolved issue when switching from dynamic to static port. configuration (issue 534).
    • Added localization (en-US) for all strings in resource and unit tests (issue 618).
    • Updated examples to reflect new parameters.
  • Changes to xSQLServerRSConfig
    • Added examples
  • Added resource
    • xSQLServerDatabaseDefaultLocation (issue 656)
  • Changes to xSQLServerEndpointPermission
    • Fixed a problem when running the tests locally in a PowerShell console it would ask for parameters (issue 897).
  • Changes to xSQLServerAvailabilityGroupListener
    • Fixed a problem when running the tests locally in a PowerShell console it would ask for parameters (issue 897).
  • Changes to xSQLServerMaxDop
    • Made the resource cluster aware. When ProcessOnlyOnActiveNode is specified, the resource will only determine if a change is needed if the target node is the active host of the SQL Server instance (issue 882).
  • Opted into common tests for Module and Script files – See Issue 115.
  • xDisk:
    • Added support for Guid Disk Id type – See Issue 104.
    • Added parameter AllowDestructive – See Issue 11.
    • Added parameter ClearDisk – See Issue 50.
  • xDiskAccessPath:
    • Added support for Guid Disk Id type – See Issue 104.
  • xWaitForDisk:
    • Added support for Guid Disk Id type – See Issue 104.
  • Added .markdownlint.json file to configure markdown rules to validate.
  • Clean up Badge area in README.MD – See Issue 110.
  • Disabled MD013 rule checking to enable badge table.
  • Added .github support files:
  • Changed license year to 2017 and set company name to Microsoft Corporation in LICENSE.MD and module manifest – See Issue 111.
  • Set Visual Studio Code setting “powershell.codeFormatting.preset” to “custom” – See Issue 108
  • Added Documentation and Examples section to Readme.md file – see issue 116.
  • Prevent unit tests from DSCResource.Tests from running during test execution – fixes Issue 118.
  • xWebAppPoolDefaults now returns values. Fixes 311.
  • Added unit tests for xWebAppPoolDefaults. Fixes 183.

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 

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

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:


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


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:

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:

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)

PowerShell Constrained Language Mode

This post was originally published on this site

What is PowerShell Constrained Language?

PowerShell Constrained Language is a language mode of PowerShell designed to support day-to-day administrative tasks, yet restrict access to sensitive language elements that can be used to invoke arbitrary Windows APIs.

You can place a PowerShell session into Constrained Language mode simply by setting a property:

PS C:> $ExecutionContext.SessionState.LanguageMode
PS C:> $ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"
PS C:> $ExecutionContext.SessionState.LanguageMode

PS C:> [System.Console]::WriteLine("Hello")
Cannot invoke method. Method invocation is supported only on core types in this language mode.
At line:1 char:1
+ [System.Console]::WriteLine("Hello")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : MethodInvocationNotSupportedInConstrainedLanguage

Of course, this is not secure. A user can simply start another PowerShell session which will run in Full Language mode and have full access to PowerShell features. As part of the implementation of Constrained Language, PowerShell included an environment variable for debugging and unit testing called __PSLockdownPolicy. While we have never documented this, some have discovered it and described this as an enforcement mechanism. This is unwise because an attacker can easily change the environment variable to remove this enforcement. In addition, there are also file naming conventions that enable FullLanguage mode on a script, effectively bypassing Constrained Language. Again, this is for unit testing. These test hooks cannot override a Device Guard UMCI policy and can only be used when no policy enforcement is applied.

Then what is it for?

PowerShell Constrained Language mode was designed to work with system-wide application control solutions such as Device Guard User Mode Code Integrity (UMCI). Application control solutions are an incredibly effective way to drastically reduce the risk of viruses, ransomware, and unapproved software. For DeviceGuard UMCI the approved applications are determined via a UMCI policy. PowerShell automatically detects when a UMCI policy is being enforced on a system and will run only in Constrained Language mode. So PowerShell Constrained Language mode becomes more interesting when working in conjunction with system-wide lockdown policies.

PowerShell’s detection of system policy enforcement through DeviceGuard is supported only for Windows platform running Windows PowerShell version 5.1. It is not currently implemented in Open Source PowerShell Core 6 beta, and it does not work on non-Windows platforms. So this is currently very much a Windows security feature. However, we will continue to enhance this for non-Windows platforms where feasible.

These lockdown policies are important for high-value systems that need to be protected against malicious administrators or compromised administrator credentials. With a policy enforced even administrators are limited to what they can do on the system.

Since Constrained Language is so limited, you will find that many of the approved scripts that you use for advanced systems management no longer work. The solution to this is simple: add these scripts (or more effectively: your code signing authority that signed them) to your Device Guard policy. This will allow your approved scripts to run in Full Language mode.

For example, all PowerShell module files shipped with Windows (e.g., Install-WindowsFeature) are trusted and signed. The UMCI policy allowing signed Windows files lets PowerShell run these modules in Full Language mode. But if you create a custom PowerShell module that is not allowed by the policy then it will be considered untrusted and run with Constrained Language restrictions.

Consequently, any PowerShell module marked as trusted in the policy needs to be carefully reviewed for security vulnerabilities. A vulnerability could allow code injection, or leak private functions not intended for public use. In either case it could allow a user to run arbitrary code in Full Language mode, thus bypassing the system policy protections.

We have described these dangers in much more detail in our post, [Writing Secure PowerShell Scripts].

What does Constrained Language constrain?

Constrained Language consists of a number of restrictions that limit unconstrained code execution on a locked-down system. These restrictions are:

  • PowerShell module script files must explicitly export functions by name without the use of wildcard characters.
    This is to prevent inadvertently exposing powerful helper function not meant to be used publicly.
  • PowerShell module manifest files must explicitly export functions by name without the use of wildcards.
    Again, to prevent inadvertent exposure of functions.
  • COM objects are blocked.
    They can expose Win32 APIs that have likely never been rigorously hardened as part of an attack surface.
  • Only approved .NET types are allowed.
    Many .NET types can be used to invoke arbitrary Win32 APIs. As a result only specific whitelisted types are allowed.
  • Add-Type is blocked.
    It allows the creation of arbitrary types defined in different languages.
  • The use of PowerShell classes are disallowed.
    PowerShell classes are just arbitrary C# type definitions.
  • PowerShell type conversion is not allowed.
    Type conversion implicitly creates types and runs type constructors.
  • Dot sourcing across language modes is disallowed.
    Dot sourcing a script file brings all functions, variables, aliases from that script into the current scope.
    So this blocks a trusted script from being dot sourced into an untrusted script and exposing all of its internal functions.
    Similarly, an untrusted script is prevented from being dot sourced into a trusted script so that it cannot pollute the trusted scope.
  • Command resolution automatically hides commands you cannot run.
    For example, a function created in Constrained Language mode is not visible to script running in Full Language mode.
  • XAML based workflows are blocked since they cannot be constrained by PowerShell.
    But script based workflows and trusted XAML based workflows shipped in-box are allowed.
  • The SupportedCommand parameter for Import-LocalizedData is disabled.
    It allows additional commands prevented by Constrained Language.
  • Invoke-Expression cmdlet always runs in Constrained Language.
    Invoke-Expression cannot validate input as trusted.
  • Set-PSBreakpoint command is blocked unless there is a system-wide lockdown through UMCI.
  • Command completers are always run in Constrained Language.
    Command completers are not validated as trustworthy.
  • Commands and script run within the script debugger will always be run in Constrained Language if there is a system-wide lockdown.
  • The DSC Configuration keyword is disabled.
  • Supported commands and Statements are not allowed in script DATA sections.
  • Start-Job is unavailable if the system is not locked-down.
    Start-Job starts PowerShell in a new process and if the system is not locked-down the new process runs in Full Language mode.

As we can see, Constrained Language mode imposes some significant restrictions on PowerShell. Nevertheless, it remains a formidable and capable shell and scripting language. You can run native commands and PowerShell cmdlets and you have access to the full scripting features: variables, statements, loops, functions, arrays, hashtables, error handling, etc.

How is this different from JEA?

PowerShell Constrained Language restricts only some elements of the PowerShell language along with access to Win32 APIs. It provides full shell access to all native commands and many cmdlets. It is not designed to operate independently and needs to work with application control solutions such as UMCI to fully lockdown a system and prevent access to unauthorized applications. Its purpose is to provide PowerShell on a locked-down system without compromising the system.

JEA (Just Enough Administration) is a sandboxed PowerShell remote session that is designed to strictly limit what the logged on user can do. It is configured in ‘no language mode’, has no access to file or other drive providers, and makes only a small set of cmdlets available. These cmdlets are often custom and designed to perform specific management functions without giving unfettered access to the system. The set of cmdlets provided in the session is role based (RBAC) and the session can be run in virtual or Group Managed Service accounts.

The JEA scenario is where an administrator needs to perform a management task on a high-value machine (such as collect logs or restart a specific service). The administrator creates a remote PowerShell session to the machine’s JEA endpoint. Within that session the user has access to only those commands needed to perform the task and cannot directly access the file system or the registry or run arbitrary code.


PowerShell Constrained Language is designed to work with application whitelisting solutions in order to restrict what can be accessed in an interactive PowerShell session with policy enforcement. You configure which scripts are allowed full system access through the whitelisting solution policy. In contrast, JEA is a sandboxed PowerShell remote session that restricts an interactive session to specific commands based on user role.

Paul Higinbotham [MSFT]
PowerShell Team