DSC Resource Kit November 2016 Release

November 2, 2016, 5:19 pm

≫ Next: Tips and Tricks from PowerShell Core Validation

≪ Previous: Join the PowerShell 10th Anniversary Celebration!

We just released the DSC Resource Kit!

Since our last release on September 21, we have added 1 new repository, PSDscResources, which will serve as the new home of the in-box DSC resources from the PSDesiredStateConfiguration module. This new module now has over 75,000 downloads from the PowerShell Gallery! Wow! Read more about PSDscResources in our blog post here.

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

The modules updated in this release are:

xActiveDirectory
xCertificate
xExchange
xNetworking
xPSDesiredStateConfiguration
xRemoteDesktopSessionHost
xSqlServer
xStorage
xWebAdministration
SharePointDsc
SystemLocaleDsc
PSDscResources

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 October 26. Unfortunately, we had technical difficulties with Skype and weren’t able to actually see or hear any of our wonderful community members. We still posted a recording of our updates as well as summarizing notes. 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 next call date.

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)!

As with past Resource Kits, 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
xActiveDirectory	2.14.0.0	xADDomainController: Adds Site option.
xCertificate	2.2.0.0	Converted appveyor.yml to install Pester from PSGallery instead of from Chocolatey. Moved unit tests to correct folder structure. Changed unit tests to use standard test templates. Updated all resources to meet HQRM standards and style guidelines. Added .gitignore file Added .gitattributes file to force line endings to CRLF to allow unit tests to work. xCertificateCommon: Moved common code into new module CertificateCommon.psm1 Added standard exception code. to use acceptable verb Test-*. Added help to all functions. xCertificateImport: Fixed bug with Test-TargetResource incorrectly detecting change required. Reworked unit tests for improved code coverage to meet HQRM standards. Created Integration tests for both importing and removing an imported certificate. Added descriptions to MOF file. Removed default parameter values for parameters that are required or keys. Added verbose messages. Split message and error strings into localization string files. Added help to all functions. xPfxImport: Fixed bug with Test-TargetResource incorrectly detecting change required. Reworked unit tests for improved code coverage to meet HQRM standards. Created Integration tests for both importing and removing an imported certificate. Added descriptions to MOF file. Removed default parameter values for parameters that are required or keys. Added verbose messages. Split message and error strings into localization string files. Added help to all functions. xCertReq: Cleaned up descriptions in MOF file. Fixed bugs generating certificate when credentials are specified. Allowed output of certificate request when credentials are specified. Split message and error strings into localization string files. Created unit tests and integration tests. Improved logging output to enable easier debugging. Added help to all functions. xPDT: Renamed to match standard module name format (MSFT_x). Modified to meet 100 characters or less line length where possible. Split message and error strings into localization string files. Removed unused functions. Renamed functions to standard verb-noun form. Added help to all functions. Fixed bug in Wait-Win32ProcessEnd that prevented waiting for process to end. Added Wait-Win32ProcessStop to wait for a process to stop. Removed unused and broken scheduled task code.
xExchange	1.11.0.0	xExchActiveSyncVirtualDirectory: Fix issue where ClientCertAuth parameter set to “Allowed” instead of “Accepted”
xNetworking	3.0.0.0	Corrected integration test filenames: MSFT_xDefaultGatewayAddress.Integration.Tests.ps1 MSFT_xDhcpClient.Integration.Tests.ps1 MSFT_xDNSConnectionSuffix.Integration.Tests.ps1 MSFT_xNetAdapterBinding.Integration.Tests.ps1 Updated all integration tests to use v1.1.0 header and script variable context. Updated all unit tests to use v1.1.0 header and script variable context. Removed uneccessary global variable from MSFT_xNetworkTeam.integration.tests.ps1 Converted Invoke-Expression in all integration tests to &. Fixed unit test description in xNetworkAdapter.Tests.ps1 xNetAdapterBinding Added support for the use of wildcard (*) in InterfaceAlias parameter. BREAKING CHANGE – MSFT_xIPAddress: SubnetMask parameter renamed to PrefixLength.
xPSDesiredStateConfiguration	5.0.0.0	xWindowsFeature: Cleaned up resource (PSSA issues, formatting, etc.) Added/Updated Tests and Examples BREAKING CHANGE: Removed the unused Source parameter Updated to a high quality resource xDSCWebService: Add DatabasePath property to specify a custom database path and enable multiple pull server instances on one server. Rename UseUpToDateSecuritySettings property to UseSecurityBestPractices. Add DisableSecurityBestPractices property to specify items that are excepted from following best practice security settings. xGroup: Fixed PSSA issues Formatting updated as per style guidelines Missing comment-based help added for Get-/Set-/Test-TargetResource Typos fixed in Unit test script Unit test “Get-TargetResource/Should return hashtable with correct values when group has no members” updated to handle the expected empty Members array correctly Added a lot of unit tests Cleaned resource xUser: Fixed PSSA/Style violations Added/Updated Tests and Examples Added xWindowsPackageCab xService: Fixed PSSA/Style violations Updated Tests Added “Ignore” state
xRemoteDesktopSessionHost	1.3.0.0	Converted appveyor.yml to install Pester from PSGallery instead of from Chocolatey.
xSQLServer	3.0.0.0	xSQLServerHelper added functions Test-SQLDscParameterState Get-SqlDatabaseOwner Set-SqlDatabaseOwner Examples xSQLServerDatabaseOwner 1-SetDatabaseOwner.ps1 Added tests for resources MSFT_xSQLServerDatabaseOwner.Tests.Tests.ps1
xStorage	2.8.0.0	added test for existing file system and no drive letter assignment to allow simple drive letter assignment in MSFT_xDisk.psm1 added unit test for volume with existing partition and no drive letter assigned for MSFT_xDisk.psm1 xMountImage: Fixed mounting disk images on Windows 10 Anniversary Edition Updated to meet HQRM guidelines. Moved all strings into localization files. Fixed examples to import xStorage module. Fixed Readme.md layout issues. xWaitForDisk: Added support for setting DriveLetter parameter with or without colon. MOF Class version updated to 1.0.0.0. xWaitForVolume: Added new resource. StorageCommon: Added helper function module. Corrected name of unit tests file. xDisk: Added validation of DriveLetter parameter. Added support for setting DriveLetter parameter with or without colon. Removed obfuscation of drive/partition errors by eliminating try/catch block. Improved code commenting. Reordered tests so they are in same order as module functions to ease creation. Added FSFormat parameter to allow disk format to be specified. Size or AllocationUnitSize mismatches no longer trigger Set-TargetResource because these values can”t be changed (yet). MOF Class version updated to 1.0.0.0. Unit tests changed to match xDiskAccessPath methods. Added additional unit tests to Get-TargetResource. Fixed bug in Get-TargetResource when disk did not contain any partitions. Added missing cmdletbinding() to functions. xMountImage (Breaking Change): Removed Name parameter (Breaking Change) Added validation of DriveLetter parameter. Added support for setting DriveLetter parameter with or without colon. MOF Class version updated to 1.0.0.0. Enabled mounting of VHD/VHDx/VHDSet disk images. Added StorageType and Access parameters to allow mounting VHD and VHDx disks as read/write. xDiskAccessPath: Added new resource. Added support for changing/setting volume label.
xWebAdministration	1.15.0.0	Corrected name of AuthenticationInfo parameter in Readme.md. Added sample for xWebApplication for adding new web application. Corrected description for AuthenticationInfo for xWebApplication and xWebsite.
SharePointDsc	1.4.0.0	Set-TargetResource of Service Application now also removes all associated proxies Fixed issue with all SPServiceApplication for OS not in En-Us language, add GetType().FullName method in: SPAccessServiceApp SPAppManagementServiceApp SPBCSServiceApp SPExcelServiceApp SPManagedMetaDataServiceApp SPPerformancePointServiceApp SPSearchServiceApp SPSearchCrawlRule SPSecureStoreServiceApp SPSubscriptionSettingsServiceApp SPUsageApplication SPUserProfileServiceApp SPVisioServiceApp SPWordAutomationServiceApp SPWorkManagementServiceApp Fixed issue with SPServiceInstance for OS not in En-Us language, add GetType().Name method in: SPDistributedCacheService SPUserProfileSyncService Fixed issue with SPInstallLanguagePack to install before farm creation Fixed issue with mounting SPContentDatabase Fixed issue with SPShellAdmin and Content Database method Fixed issue with SPServiceInstance (Set-TargetResource) for OS not in En-Us language Added .Net 4.6 support check to SPInstall and SPInstallPrereqs Improved code styling SPVisioServiceapplication now creates proxy and lets you specify a name for it New resources: SPAppStoreSettings Fixed bug with SPInstallPrereqs to allow minor version changes to prereqs for SP2016 Refactored unit tests to consolidate and streamline test approaches Updated SPExcelServiceApp resource to add support for trusted file locations and most other properties of the service app Added support to SPMetadataServiceApp to allow changing content type hub URL on existing service apps Fixed a bug that would cause SPSearchResultSource to throw exceptions when the enterprise search centre URL has not been set Updated documentation of SPProductUpdate to reflect the required install order of product updates
SystemLocaleDsc	1.1.0.0	Fix AppVeyor.yml build process. Convert Get-TargetResource to output IsSingleInstance value passed in as parameter.
PSDscResources	2.0.0.0, 2.1.0.0	2.0.0.0 Initial release 2.1.0.0 Added WindowsFeature

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)

↧

Tips and Tricks from PowerShell Core Validation

November 29, 2016, 2:00 pm

≫ Next: Join our first PowerShell Core Community Call – Dec 8, 2016

≪ Previous: DSC Resource Kit November 2016 Release

It has been a privilege for the CAT team to work with customers and the PowerShell team to validate early builds and experiences with PowerShell Core. Some of the customers involved were key influences on the whitepaper, The Release Pipeline Model Applied to Windows Server and Microsoft Cloud. As a result, validation has included many experiences from outside the traditional Microsoft tool chain, such as Vagrant and Jenkins.

For this blog post, I wanted to share some of the learnings that I gained during the validation experience. This is not meant to be a complete picture of PowerShell Core. Rather, a glimpse at some exciting new possibilities.

Voyage of Discovery

In my mind the best thing about PowerShell as a scripting language is the never ending journey of exploration. When I have the need to accomplish a task and I’m unfamiliar with the area of technology, I rely on Get-Command. If I need to gather information I start the learning process by looking for commands that begin with the verb Get, so I open the console and type Get-Command Get-*. When I need to create something new, I’m going to be looking for commands that start with the verb New. When I need to change a value, I am probably looking for commands that start with Set. If I plan to run something, the commands probably start with Invoke, and so forth.

I view myself as a novice with Linux based servers. I am certainly not an expert but I am by no means a rookie either. Still, it is a muscle I don’t regularly exercise, so to accomplish even the most routine tasks I require a search engine. My testing began by connecting to an Ubuntu 14.04 server running on Azure using SSH. I followed the documented steps from the PowerShell repo to install .NET core and PowerShell Core. Then just as I would when remotely connected to Windows Server Core or Nano, I executed Get-Command to start looking at which cmdlets are available and how I could combine them to perform operations wizardry.

The “ah ha!” moment for me has been combining PowerShell Core with the existing Linux tools and scripting languages. Now the same work patterns that I describe above are applicable on platforms where my domain knowledge has less depth, but I am exploring topics using a familiar approach.

A simple proof of concept

I wanted to experiment with simple “operations tasks” that I handle daily on Windows based machines. The bare bones list that came to mind was:

getting the IPv4 address of the machine
finding out which DNS name servers it is pointing to
checking the drive configuration

I purposefully chose these areas because (at the time of this writing) there are not yet cmdlets available. The challenge would be understanding how to weave together the cmdlets at my disposal until the tasks become simple.

Getting text using Select-String

Of the three challenges, the most simple solution was checking which DNS name servers the machine is pointing to. This also allows me to demonstrate a core concept that will be an important skill, getting text.

The existing tools and scripting languages on Linux are GREAT at working with text output. That is a fundamental skill. These tools, such as the cat command, could simply be ‘wrapped’ by PowerShell functions if needed. I wanted to be stubborn and try working with the native PowerShell cmdlets for pulling information out of text. The Select-String cmdlet has helped a lot in this pursuit.

If you are not familiar with Select-String, try the command Get-Help Select-String -detailed from the console. This will provide you with more information. Get-Help is a handy way to learn more about cmdlets as you are experimenting.

get-content /etc/resolv.conf | select-string nameserver

nameserver 10.0.0.5

In this example, the one-line command is just capturing the contents of the file resolv.conf, and then returning each line that includes the work ‘nameserver’. Of course it will not always be so simple. You might need to capture multiple lines of text and extract specific values. A good trick to know is the -Context parameter for Select-String. The value will be the number of lines before and after the text you are selecting that you want to have returned. Seperate the values with a comma. So to return any line with the word ‘nameserver’ and the line after it, see the example below.

get-content /etc/resolv.conf | select-string nameserver -context 0,1

> nameserver 10.0.0.5
  search dns.example.com

Getting text using Regular Expressions

As I mentioned above, there are Linux tools to handle this. Great tools, in fact, such as grep, awk, and sed. The challenge I gave myself was to use the style and approach to working with regular expressions that I am most familiar with from PowerShell script examples. Including both the -match operator and the .NET method Regex.Matches.

Objects

All this working with text is unfamiliar to experienced PowerShell users. A core concept in PowerShell is working with Objects. The last example, getting a list of available disks, provided an opportunity to try this. Also, since getting disk information is a privileged operation, I got a chance to try the sudo command within a function in PowerShell Core.

Piling on the ideas we have explored so far, I need to find the command that will provide text output with disk information, and I will need to manipulate that text. The new concept this example introduces is taking that text and putting it in an object using the New-Object cmdlet. The text string values are simply passed in to the -Property parameter as a hashtable.

Note the use of square brackets to index in to an array. For example, $array[0] returns just the first value.

Function Get-DiskInfo {
    $disks = sudo parted -l | Select-String "Disk /dev/sd*" -Context 1,0
    $diskinfo = @()
    foreach ($disk in $disks) {
        $diskline1 = $disk.ToString().Split("`n")[0].ToString().Replace('  Model: ','')
        $diskline2 = $disk.ToString().Split("`n")[1].ToString().Replace('> Disk ','')
        $i = New-Object psobject -Property @{'Friendly Name' = $diskline1; Device=$diskline2.Split(': ')[0]; 'Total Size'=$diskline2.Split(':')[1]}
        $diskinfo += $i
    }
    $diskinfo
}

Get-DiskInfo
[sudo] password for psuser:

Friendly Name            Total Size Device
-------------            ---------- ------
Msft Virtual Disk (scsi)  31.5GB    /dev/sda
Msft Virtual Disk (scsi)  145GB     /dev/sdb

Now you can work with specific properties of the object. Recall you can always pipe the object to Get-Member to see which properties and methods are available.

(Get-DiskInfo).Device
/dev/sda
/dev/sdb

Performing the same work across platforms

For the final challenge, is it now possible to author a function in PowerShell that can be run across Windows, Linux, and macOS? There is a simple solution that makes this very straightforward.

PowerShell Core includes variables:

$IsLinux
$IsOSX
$IsWindows

So in your function you can perform Linux type work in one IF block and Windows type work in another, and as long as you return an object with the same properties you can work with the results using the same cmdlets. In testing I found it handy to check if I was in Linux or OSX and if not, use cmdlets from modules I expected to find in Windows. Since the $IsWindows variable is not available (at the time of this writing) in the version of PowerShell provided with Windows.

function Get-Something {
    if ($IsLinux -or $IsOSX) {
        # Get this information using approaches for Linux and/or OSX
        $something = get-content /file | select-string text
        }
    else {
        # Get this information using cmdlets already available in Windows
        $something = get-whatever -parameter value
    }

    $something | Where-Object {$_ -ne 'excluded value'}
}

For more information

For more information on this topic and for expansion on the examples used above, see ‘Learning PowerShell’ in the docs folder of the PowerShell repo. While you are there, you might also visit the ‘demos’ folder at the root of the repository for the latest examples of using PowerShell in cross-platform environments.

Thank you!
Michael Greene
Principal Program Manager
ECG CAT

↧

Join our first PowerShell Core Community Call – Dec 8, 2016

December 1, 2016, 3:25 pm

≫ Next: WMF 5.1 Releasing January 2017

≪ Previous: Tips and Tricks from PowerShell Core Validation

tl;dr: We’re having a PowerShell Core Community Call with the PowerShell Committee and you should join us! Hit the bottom of this page for an .ics and a link to the Skype meeting.

The PowerShell Team loves feedback. Whether it’s fielding your Windows PowerShell suggestions and bugs through our Windows Server UserVoice, answering your quick questions via the @PowerShell_Team account on Twitter, fixing your PowerShell Core 6.0 issues on GitHub, or even discussing entirely new designs–yours and our own–on the PowerShell-RFC repository, our peer-to-peer engagement with YOU has never been stronger.

As part of strengthening this engagement, we’ve had a number of community calls for some of our projects such as the DSC Resource Kit, PowerShell PackageManagement, and PowerShell ScriptAnalyzer. On these calls, we are able to have high-bandwidth conversations regarding your top issues, our initial thoughts on new designs, or even the high-level direction of a project. We’ve found that, while our online feedback channels are great at high scale, sometimes it’s better to just have a conversation between us, the folks most involved with development, and you, the IT professionals and developers who use our products every day.

Today, we’re delighted to announce our first monthly PowerShell Core Community Call. Join the members of the PowerShell Committee to provide your feedback on PowerShell Core, as well as to discuss RFCs top GitHub Issues, our release cadence, and the general direction of PowerShell. Make sure to bring any questions or thoughts that you have about PowerShell Core as we’ll be spending plenty of time addressing them.

As some initial agenda topics, we’ll discuss:

RFCs tagged as Review - Committee
Issues tagged as Review - Committee
The future direction of PowerShell 6.0
Anything else you want to bring to the table!

(Note that we want this call to be as useful as possible for all of you, so we’re certainly open to changing the format, topics, or scheduling based on your feedback.)

Join us on Skype or by phone on December 8th @ 9am PST (Pacific Standard Time, GMT -0800):

Join Skype Meeting
Join by phone (US): +1 (866) 641-7188 or find a local number
Conference ID: 56500606

.ics file

We can’t wait to hear from you!

↧

WMF 5.1 Releasing January 2017

December 6, 2016, 10:00 am

≫ Next: Azure DSC extension for Nano Server

≪ Previous: Join our first PowerShell Core Community Call – Dec 8, 2016

We previously announced that the Windows Management Framework (WMF) 5.1 would release shortly after the GA release of Windows Server 2016, however the PowerShell team found some issues with upgrades that could affect a small set of our customers. We are resolving these issues now, and target early January for the release of WMF 5.1 to the public.

We understand there is pent-up demand for this release. WMF 5.1 provides important enhancements over WMF 5.0, and removes WMF5.0’s need for installing WMF 4.0 first, on Windows 7 and Windows Server 2008 R2.

WMF upgrades previous versions of the Windows management stack. Upgrade code is complex, and getting this correct with WMF 5.1 has taken some time. We are close to the final bits we plan to release, but want to ensure we are able to support upgrades correctly for all of our users. As a note, learning from WMF5.0, we also feel it is important to avoid releasing near the December holiday season in the US, so that that the full PowerShell team is available immediately after we release to answer any questions that arise from the new features we have built into this product.

So, thank you for your patience. We look forward to delighting you with WMF 5.1.

↧

Azure DSC extension for Nano Server

December 7, 2016, 1:39 pm

≫ Next: DSC Resource Kit Release December 2016

≪ Previous: WMF 5.1 Releasing January 2017

NOTE: For information on OS support, and other features, please refer to our release history.

We are proud to announce that the Azure DSC extension now works on Nano Server! You will need to use extension version 2.21 or above, but the functionality and cmdlets remain the same. The extension will take care of adding the DSC package to Nano Server. Nano’s smaller footprint should speed up your end-to-end deployment time.

Look at our existing documentation to get started. You can also use use Azure Tools for Visual Studio to help your deployments along!

↧

DSC Resource Kit Release December 2016

December 14, 2016, 6:00 pm

≫ Next: Code Coverage now available for PowerShell Core!

≪ Previous: Azure DSC extension for Nano Server

We just released the DSC Resource Kit!

Since our last release on November 2, we have added 1 new module, AuditPolicyDsc, which allows you to edit your audit policy subcategories and options. Thank you to Adam Haynes for this great new module!

Outside of the DSC Resource Kit, we also recently published an update to GPRegistryPolicy in the PowerShell Gallery. The latest version now includes a DSC resource to help you locally manage policy registry keys.

We have also added two new maintainers to the DSC Resource Kit:

Johan Ljunggren (xSqlServer)
Daniel Scott-Raynsford (xAdcsDeployment, xCertificate, xNetworking, xStorage)

These guys have shown outstanding dedication to their modules and continue to be invaluable contributors to the DSC Resource Kit. Congrats!

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

We are holding the release of xPSDesiredStateConfiguration and PSDscResources until Friday (12/16) so that we can finish updating some of the in-box resources. We will update this blog post when those modules are released on Friday.

The modules updated in this release are:

SharePointDsc
xActiveDirectory
xAdcsDeployment
xCertificate
xComputerManagement
xDatabase
xDscDiagnostics
xExchange
xFailOverCluster
xHyper-V
xNetworking
xSCSMA
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 December 7. 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 next call date.

Included in this Release

Module Name	Version	Release Notes
AuditPolicyDsc	1.0.0.0	Initial release with the following resources: AuditPolicySubcategory AuditPolicyOption
SharePointDsc	1.5.0.0	Fixed issue with SPManagedMetaDataServiceApp if ContentTypeHubUrl parameter is null Added minimum PowerShell version to module manifest Added testing for valid markdown syntax to unit tests Added support for MinRole enhancements added in SP2016 Feature Pack 1 Fixed bug with search topology that caused issues with names of servers needing to all be the same case Fixed bug in SPInstallLanguagePack where language packs could not be installed on SharePoint 2016 Added new resource SPSearchFileType Updated SPDatabaseAAG to allow database name patterns Fixed a bug were PerformancePoint and Excel Services Service Application proxies would not be added to the default proxy group when they are provisioned Added an error catch to provide more detail about running SPAppCatalog with accounts other than the farm account
xActiveDirectory	2.15.0.0	xAdDomainController: Fixes SiteName being required field.
xAdcsDeployment	1.1.0.0	Converted AppVeyor.yml to pull Pester from PSGallery instead of Chocolatey. Changed AppVeyor.yml to use default image. xAdcsCertificateAuthority: Change property format in Readme.md to be standard layout. Converted style to meet HQRM guidelines. Added verbose logging support. Added string localization. Fixed Get-TargetResource by removing IsCA and changing Ensure to return whether or not CA is installed. Added unit tests. Updated parameter format to meet HQRM guidelines. xAdcsOnlineResponder: Change property format in Readme.md to be standard layout. Added unit test header to be latest version. Added function help. Updated parameter format to meet HQRM guidelines. Updated resource to meet HQRM guidelines. xAdcsWebEnrollment: Change property format in Readme.md to be standard layout. Added unit test header to be latest version. Added function help. Updated parameter format to meet HQRM guidelines. Updated resource to meet HQRM guidelines. Added CommonResourceHelper.psm1 (copied from xPSDesiredStateConfiguration). Removed Technet Documentation HTML file from root folder. Removed redundant code from AppVeyor.yml. Fix markdown violations in Readme.md. Updated readme.md to match DSCResource.Template\Readme.md.
xCertificate	2.3.0.0	xCertReq: Added additional parameters KeyLength, Exportable, ProviderName, OID, KeyUsage, CertificateTemplate, SubjectAltName Fixed most markdown errors in Readme.md. Corrected Parameter decoration format to be consistent with guidelines.
xComputerManagement	1.9.0.0	Added resources xPowerPlan
xDatabase	1.5.0.0	Converted appveyor.yml to install Pester from PSGallery instead of from Chocolatey. Added logging for when dac deploy fails
xDscDiagnostics	2.6.0.0	Added JobId parameter set to Get-xDscConfiguration Added IIS binding collection
xExchange	1.12.0.0	xExchangeCommon : In StartScheduledTask corrected throw error check to throw last error when errorRegister has more than 0 errors instead of throwing error if errorRegister was not null, which would otherwise always be true. Fix PSAvoidUsingWMICmdlet issues from PSScriptAnalyzer Fix PSUseSingularNouns issues from PSScriptAnalyzer Fix PSAvoidUsingCmdletAliases issues from PSScriptAnalyzer Fix PSUseApprovedVerbs issues from PSScriptAnalyzer Fix PSAvoidUsingEmptyCatchBlock issues from PSScriptAnalyzer Fix PSUsePSCredentialType issues from PSScriptAnalyzer Fix erroneous PSDSCDscTestsPresent issues from PSScriptAnalyzer for modules that do actually have tests in the root Tests folder Fix array comparison issues by removing check for if array is null Suppress PSDSCDscExamplesPresent PSScriptAnalyzer issues for resources that do have examples Fix PSUseDeclaredVarsMoreThanAssignments issues from PSScriptAnalyzer Remove requirements for second DAG member, or second Witness server, from MSFT_xExchDatabaseAvailabilityGroup.Integration.Tests
xFailOverCluster	1.6.0.0	xCluster: Fixed bug in which failure to create a new cluster would hang
xHyper-V	3.6.0.0	xVHD: Updated incorrect property name MaximumSize in error message
xNetworking	3.1.0.0	Changed parameter format in Readme.md to improve information coverage and consistency. Changed all MOF files to be consistent and meet HQRM guidelines. Removed most markdown errors (MD*) in Readme.md. Added xNetAdapterRDMA resource Fixes to support changes to DSCResource.Tests.
xSCSMA	1.5.0.0	Added $IdentifyingNumber for TP5/RTM and small WMI improvements
xSQLServer	4.0.0.0	Fixes in xSQLServerConfiguration Added support for clustered SQL instances BREAKING CHANGE: Updated parameters to align with other resources (SQLServer / SQLInstanceName) Updated code to utilize CIM rather than WMI Added tests for resources xSQLServerConfiguration xSQLServerSetup xSQLServerDatabaseRole xSQLAOGroupJoin xSQLServerHelper and moved the existing tests for Restart-SqlService to it. xSQLServerAlwaysOnService Fixes in xSQLAOGroupJoin Availability Group name now appears in the error message for a failed Availability Group join attempt. Get-TargetResource now works with Get-DscConfiguration Fixes in xSQLServerRole Updated Ensure parameter to “Present” default value -SqlServerRole to -SqlServerRoleMember Changes to xSQLAlias Add UseDynamicTcpPort parameter for option “Dynamically determine port” Change Get-WmiObject to Get-CimInstance in Resource and associated pester file Added CHANGELOG.md file Added issue template file (ISSUE_TEMPLATE.md) for “New Issue” and pull request template file (PULL_REQUEST_TEMPLATE.md) for “New Pull Request” Add Contributing.md file Changes to xSQLServerSetup Now `Features` parameter is case-insensitive. BREAKING CHANGE: Removed xSQLServerPowerPlan from this module. The resource has been moved to xComputerManagement and is now called xPowerPlan. Changes and enhancements in xSQLServerDatabaseRole BREAKING CHANGE: Fixed so the same user can now be added to a role in one or more databases, and/or one or more instances. Now the parameters `SQLServer` and `SQLInstanceName` are mandatory. Enhanced so the same user can now be added to more than one role BREAKING CHANGE: Renamed xSQLAlias to xSQLServerAlias to align with naming convention. Changes to xSQLServerAlwaysOnService Added RestartTimeout parameter Fixed bug where the SQL Agent service did not get restarted after the IsHadrEnabled property was set. BREAKING CHANGE: The mandatory parameters now include Ensure, SQLServer, and SQLInstanceName. SQLServer and SQLInstanceName are keys which will be used to uniquely identify the resource which allows AlwaysOn to be enabled on multiple instances on the same machine. Moved Restart-SqlService from MSFT_xSQLServerConfiguration.psm1 to xSQLServerHelper.psm1.
xStorage	2.9.0.0	Updated readme.md to remove markdown best practice rule violations. Updated readme.md to match DSCResources/DscResource.Template/README.md. xDiskAccessPath: Fix bug when re-attaching disk after mount point removed or detatched. Additional log entries added for improved diagnostics. Additional integration tests added. Improve timeout loop. Converted integration tests to use `$TestDrive` as working folder or `temp` folder when persistence across tests is required. Suppress `PSUseShouldProcessForStateChangingFunctions` rule violations in resources. Rename `Test-AccessPath` function to `Assert-AccessPathValid`. Rename `Test-DriveLetter` function to `Assert-DriveLetterValid`. Added `CommonResourceHelper.psm1` module (based on PSDscResources). Added `CommonTestsHelper.psm1` module (based on PSDscResources). Converted all modules to load localization data using `Get-LocalizedData` from CommonResourceHelper. Converted all exception calls and tests to use functions in `CommonResourceHelper.psm1` and `CommonTestsHelper.psm1` respectively. Fixed examples: Sample_InitializeDataDisk.ps1 Sample_InitializeDataDiskWithAccessPath.ps1 Sample_xMountImage_DismountISO.ps1 xDisk: Improve timeout loop.
xWebAdministration	1.16.0.0	Log directory configuration on xWebsite used the logPath attribute instead of the directory attribute. Bugfix for

How to Find Released DSC Resource Modules

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

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?

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

↧

Code Coverage now available for PowerShell Core!

January 11, 2017, 10:59 am

≫ Next: PowerShell Core Community Call #2 – Jan 26, 2016

≪ Previous: DSC Resource Kit Release December 2016

This is the first of a series of posts on PowerShell Core and the tools we use to test it. If you’ve looked at the main project for PowerShell (https://github.com/PowerShell/PowerShell, you may have noticed a new badge down in the Build status of nightly builds:

We are supplying code coverage numbers for our test pass via the OpenCover project (https://github.com/OpenCover/opencover) and we visualize our code coverage percentage via coveralls.io (https://coveralls.io/github/PowerShell/PowerShell?branch=master). This means you can see some details about our testing and how much of PowerShell is covered by our test code.

You can get your own coverage numbers easily via our OpenCover module which may be found in the <RepoRoot>test/tools/OpenCover directory. To generate a code coverage report, you need to create a build which supports code coverage. Currently, that’s only available on Windows, but we do have an easy way to get it:

(All of these commands assume that you are at the root of the PowerShell repo)

# create a code coverage build.
PS> Start-PSBuild -Configuration CodeCoverage -Publish

# Now that you have a build, save away the build location
PS> $psdir = split-path -parent (get-psoutput)

# Import the OpenCover Module
PS> Import-module $pwd/test/tools/OpenCover

# install the opencover package
PS> Install-OpenCover $env:TEMP

# now invoke a coverage test run
PS> Invoke-OpenCover -OutputLog Coverage.xml -test $PWD/test/powershell -OpenCoverPath $env:Temp/OpenCover -PowerShellExeDirectory $psdir

If you want to get code coverage for only the tests that we run in our Continuous Integration (CI) environment, add the parameter -CIOnly. Then you’ll need to wait for a bit (on my system and using -CIOnly, it takes about 2.5 hours to run).

Looking at the Data

The OpenCover module can also help you visualize the results from a very high level.

# first collect the coverage data with the Get-CodeCoverage cmdlet
PS> $coverData = Get-CodeCoverage .\Coverage.xml
# here’s the coverage summary
PS> $coverData.CoverageSummary
NumSequencePoints       : 309755
VisitedSequencePoints   : 123779
NumBranchPoints         : 105816
VisitedBranchPoints     : 39842
SequenceCoverage        : 39.96
BranchCoverage          : 37.65
MaxCyclomaticComplexity : 398
MinCyclomaticComplexity : 1
VisitedClasses          : 2005
NumClasses              : 3309
VisitedMethods          : 14912
NumMethods              : 33910

# you can look at coverage data based on the assembly
PS> $coverData.Assembly | ft AssemblyName, Branch, Sequence

AssemblyName                                     Branch Sequence
------------                                     ------ --------
powershell                                       100    100
Microsoft.PowerShell.CoreCLR.AssemblyLoadContext 45.12  94.75
Microsoft.PowerShell.ConsoleHost                 22.78  23.21
System.Management.Automation                     41.18  42.96
Microsoft.PowerShell.CoreCLR.Eventing            23.33  28.57
Microsoft.PowerShell.Security                    12.62  14.43
Microsoft.PowerShell.Commands.Management         14.69  16.76
Microsoft.PowerShell.Commands.Utility            52.72  54.40
Microsoft.WSMan.Management                       0.36   0.65
Microsoft.WSMan.Runtime                          100    100
Microsoft.PowerShell.Commands.Diagnostics        42.99  46.62
Microsoft.PowerShell.LocalAccounts               0      0
Microsoft.PowerShell.PSReadLine                  6.98   9.86

I’m not going to go through all the different properties that are reported, we’ll take a closer look at those in future posts. The Get-CoverageData cmdlet is still fairly rudimentary, but it will provide some details. This is part of our public repo, so I encourage you to enhance it and log issues if you find them!

Better Coverage Visualization

Another way to view coverage data is via the ReportGenerator package, which creates HTML reports and provides much more details about the coverage. The ReportGenerator package is available via the find-package cmdlet in the PackageManagement module. The following will install the package, and show how to run it:

# find and install the report generator package
PS> find-package ReportGenerator -ProviderName nuget -Source https://nuget.org/api/v2 | install-package -Scope CurrentUser
PS> $ReportGenExe = “$HOME\AppData\Local\PackageManagement\NuGet\Packages\ReportGenerator.2.5.2\tools\ReportGenerator.exe”
# invoke the report generator and create the report in c:\temp\Coverage
PS> & $ReportGenExe -reports:Coverage.xml -targetdir:c:\temp\Coverage

Now that you’ve created the reports, you can visualize them with your browser.

PS> invoke-item C:\temp\Coverage\index.htm

Click on the “Enable filtering button”, and then “Collapse all” and you should see something similar to:

You can then drill in on what interests you (Microsoft.PowerShell.Commands.Utility, for example)

Of course, there’s a lot more detail to discover, and I encourage you to poke around. In my next post, I’ll go through an entire workflow:

Select an area for improvement
Create new tests
Gather new coverage data
Compare results from previous runs

I’ll target something specific (a cmdlet) and show how to determine the gaps and how to fill them.

Call To Action!

Now that you see how easily you can generate code coverage data, this is a great opportunity to provide some additional coverage and increase the quality of our releases. If you see some area which you’re passionate about or notice an area which you would like to measure better, it’s a great way to provide improved coverage. As you create new PRs, you can aim for high coverage in your new functionality (85-90%), and now you can measure it!

↧

PowerShell Core Community Call #2 – Jan 26, 2016

January 11, 2017, 2:47 pm

≫ Next: Windows Management Framework (WMF) 5.1 Released

≪ Previous: Code Coverage now available for PowerShell Core!

tl;dr: Our next PowerShell Community Call is January 26th, 2017 @ 9am PST. Hit the bottom of this page for an .ics and a link to the Skype meeting.

Hi everyone! I’m proud to announce the 2nd PowerShell Core Community Call. As with the first call, this is a chance for the PowerShell Committee to have a direct conversation with you, PowerShell users who give us feedback to make PowerShell 6.0 great. It’s also an opportunity for you to gain some insight into how we think about design problems, as well as to learn new features and additions to PowerShell at the earliest stages of their development.

In our last community call, we had over 50 people join us! You can find the notes in a folder marked CommunityCall in the PowerShell-RFC repository.

As in our last Community Call, we’ll discuss:

RFCs tagged as Review - Committee
Issues tagged as Review - Committee
PRs tagged as Review - Committee
Anything else you want to bring to the table!

Join us on Skype on January 26th, 2017 @ 9am PST (Pacific Standard Time, GMT -0800):

Join Skype Meeting
Join by phone (US): +1 (866) 641-7188 or find a local number
Conference ID: 48399670

.ics file

See you then!

↧

Windows Management Framework (WMF) 5.1 Released

January 19, 2017, 1:13 pm

≫ Next: DSC Resource Kit Release January 2017

≪ Previous: PowerShell Core Community Call #2 – Jan 26, 2016

We are pleased to announce that we are releasing the Windows Management Framework (WMF) 5.1 today via the Microsoft download center.

WMF 5.1 upgrades Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 to the PowerShell, WMI, WinRM and SIL components that were released with Windows Server 2016 and Windows 10 Anniversary Edition.

You can find out more about the WMF 5.1 release in the Release Notes.

Please note that for Windows 7 and Windows Server 2008 R2 the installation instructions have changed significantly. Please read the Install and Configure topic in the release notes. We have removed the requirement for pre-installing WMF 4 on Windows 7 and Windows Server 2008 R2, but to do so we had create a script for checking the prerequisites that accompanies the MSU in a ZIP file. This affects only Windows 7 and Windows Server 2008 R2. The Install and Configure topic in the release notes provides details on using the script.

As always, we welcome your feedback on PowerShell and WMF via our UserVoice site.

Thank you –

The PowerShell Team

↧

DSC Resource Kit Release January 2017

January 25, 2017, 7:37 pm

≫ Next: PowerShell Open Source Community Dashboard

≪ Previous: Windows Management Framework (WMF) 5.1 Released

We just released the DSC Resource Kit!

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

The modules updated in this release are:

AuditPolicyDsc
xDismFeature
xExchange
xNetworking
xPSDesiredStateConfiguration
xSQLServer
xWebAdministration

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

xHyper-V has changes to be released, but the tests have a few issues at the moment. We will release it as soon as those issues are resolved.
PSDscResources does not currently have any changes to release, but there are some changes queuing up. We will release it again soon once those changes are ready.
We will update this blog post when either of these modules is released.

A new version of xActiveDirectory was also released about two weeks ago with some bug fixes for xADDomain and xADDomainController.

Our last community call for the DSC Resource Kit was last week on January 18. A recording of our updates as well as summarizing notes are available. Join us next time at 9AM PST on March 1 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 agenda.

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

Module Name	Version	Release Notes
AuditPolicyDsc	1.1.0.0	Added the AuditPolicyCsv resource.
xDismFeature	1.2.0.0	xDismFeature: Resource no longer includes the Source parameter when it is not specified Converted appveyor.yml to install Pester from PSGallery instead of from Chocolatey.
xExchange	1.13.0.0	Fix function RemoveVersionSpecificParameters xExchMailboxServer: Added missing parameters except these, which are marked as “This parameter is reserved for internal Microsoft use.”
xNetworking	3.2.0.0	Fixed typo in the example”s Action property from “Blocked” (which isn”t a valid value) to “Block” Added support for auto generating wiki, help files, markdown linting and checking examples. Added NetworkingDsc.ResourceHelper module based on copy from PSDscResources. MSFT_xFirewall: Cleaned up ParameterList table layout and moved into a new file (MSFT_xFirewall.data.psd1). Separated Localization strings into strings file. Added standard help blocks to all functions to meet HQRM standards. Added CmdletBinding attribute to all functions to meet HQRM standards. Style changes to meet HQRM standards. Fixed issue using CIDR notation for LocalAddress or RemoteAddress. See GitHub issue. Fixed integration tests so that values being set are correctly tested. Added integration tests for Removal of Firewall rule. Added NetworkingDsc.Common module to contain shared networking functions. MSFT_xDNSServerAddress: Separated Localization strings into strings file. MSFT_xDefaultGatewayAddress: Separated Localization strings into strings file. Style changes to meet HQRM standards. MSFT_xDhcpClient: Separated Localization strings into strings file. Fix parameter descriptions in MOF file. Style changes to meet HQRM standards. MSFT_xDnsClientGlobalSetting: Renamed Localization strings file to be standard naming format. Moved ParameterList into a new file (MSFT_xDnsClientGlobalSetting.data.psd1). Style changes to meet HQRM standards. Removed New-TerminatingError function because never called. Converted to remove Invoke-Expression. MSFT_xDnsConnectionSuffix: Separated Localization strings into strings file. Style changes to meet HQRM standards. MSFT_xHostsFile: Renamed Localization strings file to be standard naming format. Style changes to meet HQRM standards. Refactored for performance Code now reads 38k lines in > 1 second vs 4 Now ignores inline comments Added more integration tests MSFT_xIPAddress: Separated Localization strings into strings file. Style changes to meet HQRM standards. MSFT_xNetAdapterBinding: Separated Localization strings into strings file. Style changes to meet HQRM standards. MSFT_xNetAdapterRDMA: Renamed Localization strings file to be standard naming format. Style changes to meet HQRM standards. MSFT_xNetBIOS: Renamed Localization strings file to be standard naming format. Style changes to meet HQRM standards. MSFT_xNetConnectionProfile: Separated Localization strings into strings file. Style changes to meet HQRM standards. MSFT_xNetworkTeam: Style changes to meet HQRM standards. MSFT_xNetworkTeamInterface: Updated integration tests to remove Invoke-Expression. Style changes to meet HQRM standards. MSFT_xRoute: Separated Localization strings into strings file. Style changes to meet HQRM standards. MSFT_xFirewall: Converted to remove Invoke-Expression.
xPSDesiredStateConfiguration	5.2.0.0	xWindowsProcess Minor updates to integration tests because one of the tests was flaky. xRegistry: Added support for forward slashes in registry key names. This resolves issue 285.
xSqlServer	5.0.0.0	Improvements how tests are initiated in AppVeyor Removed previous workaround (issue 201) from unit tests. Changes in appveyor.yml so that SQL modules are removed before common test is run. Now the deploy step are no longer failing when merging code into Dev. Neither is the deploy step failing if a contributor had AppVeyor connected to the fork of xSQLServer and pushing code to the fork. Changes to README.md Changed the contributing section to help new contributors. Added links for each resource so it is easier to navigate to the parameter list for each resource. Moved the list of resources in alphabetical order. Moved each resource parameter list into alphabetical order. Removed old text mentioning System Center. Now the correct product name is written in the installation section, and a typo was also fixed. Fixed a typo in the Requirements section. Added link to Examples folder in the Examples section. Change the layout of the README.md to closer match the one of PSDscResources Added more detailed text explaining what operating systemes WMF5.0 can be installed on. Verified all resource schema files with the README.md and fixed some errors (descriptions was not verified). Added security requirements section for resource xSQLServerEndpoint and xSQLAOGroupEnsure. Changes to xSQLServerSetup The resource no longer uses Win32_Product WMI class when evaluating if SQL Server Management Studio is installed. See article kb974524 for more information. Now it uses CIM cmdlets to get information from WMI classes. Resolved all of the PSScriptAnalyzer warnings that was triggered in the common tests. Improvement for service accounts to enable support for Managed Service Accounts as well as other nt authority accounts Changes to the helper function Copy-ItemWithRoboCopy Robocopy is now started using Start-Process and the error handling has been improved. Robocopy now removes files at the destination path if they no longer exists at the source. Robocopy copies using unbuffered I/O when available (recommended for large files). Added a more descriptive text for the parameter `SourceCredential` to further explain how the parameter work. BREAKING CHANGE: Removed parameter SourceFolder. BREAKING CHANGE: Removed default value “$PSScriptRoot….” from parameter SourcePath. Old code, that no longer filled any function, has been replaced. Function `ResolvePath` has been replaced with `[Environment]::ExpandEnvironmentVariables($SourcePath)` so that environment variables still can be used in Source Path. Function `NetUse` has been replaced with `New-SmbMapping` and `Remove-SmbMapping`. Renamed function `GetSQLVersion` to `Get-SqlMajorVersion`. BREAKING CHANGE: Renamed parameter PID to ProductKey to avoid collision with automatic variable $PID Changes to xSQLServerScript All credential parameters now also has the type [System.Management.Automation.Credential()] to better work with PowerShell 4.0. It is now possible to configure two instances on the same node, with the same script. Added to the description text for the parameter `Credential` describing how to authenticate using Windows Authentication. Added examples to show how to authenticate using either SQL or Windows authentication. A recent issue showed that there is a known problem running this resource using PowerShell 4.0. For more information, see issue #273 Changes to xSQLServerFirewall BREAKING CHANGE: Removed parameter SourceFolder. BREAKING CHANGE: Removed default value “$PSScriptRoot….” from parameter SourcePath. Old code, that no longer filled any function, has been replaced. Function `ResolvePath` has been replaced with `[Environment]::ExpandEnvironmentVariables($SourcePath)` so that environment variables still can be used in Source Path. Adding new optional parameter SourceCredential that can be used to authenticate against SourcePath. Solved PSSA rules errors in the code. Get-TargetResource no longer return $true when no products was installed. Changes to the unit test for resource xSQLServerSetup Added test coverage for helper function Copy-ItemWithRoboCopy Changes to xSQLServerLogin Removed ShouldProcess statements Added the ability to enforce password policies on SQL logins Added common test (xSQLServerCommon.Tests) for xSQLServer module Now all markdown files will be style checked when tests are running in AppVeyor after sending in a pull request. Now all Examples will be tested by compiling to a .mof file after sending in a pull request. Changes to xSQLServerDatabaseOwner The example “SetDatabaseOwner” can now compile, it wrongly had a `DependsOn` in the example. Changes to SQLServerRole The examples “AddServerRole” and “RemoveServerRole” can now compile, it wrongly had a `DependsOn` in the example. Changes to CONTRIBUTING.md Added section “Tests for examples files” Added section “Tests for style check of Markdown files” Added section “Documentation with Markdown” Added texts to section “Tests” Changes to xSQLServerHelper added functions Get-SqlDatabaseRecoveryModel Set-SqlDatabaseRecoveryModel Examples xSQLServerDatabaseRecoveryModel 1-SetDatabaseRecoveryModel.ps1 xSQLServerDatabasePermission 1-GrantDatabasePermissions.ps1 2-RevokeDatabasePermissions.ps1 3-DenyDatabasePermissions.ps1 xSQLServerFirewall 1-CreateInboundFirewallRules 2-RemoveInboundFirewallRules Added tests for resources xSQLServerDatabaseRecoveryModel xSQLServerDatabasePermissions xSQLServerFirewall Changes to xSQLServerDatabaseRecoveryModel BREAKING CHANGE: Renamed xSQLDatabaseRecoveryModel to xSQLServerDatabaseRecoveryModel to align with naming convention. BREAKING CHANGE: The mandatory parameters now include SQLServer, and SQLInstanceName. Changes to xSQLServerDatabasePermission BREAKING CHANGE: Renamed xSQLServerDatabasePermissions to xSQLServerDatabasePermission to align wíth naming convention. BREAKING CHANGE: The mandatory parameters now include PermissionState, SQLServer, and SQLInstanceName. Added support for clustered installations to xSQLServerSetup Migrated relevant code from xSQLServerFailoverClusterSetup Removed Get-WmiObject usage Clustered storage mapping now supports asymmetric cluster storage Added support for multi-subnet clusters Added localized error messages for cluster object mapping Updated README.md to reflect new parameters Updated description for xSQLServerFailoverClusterSetup to indicate it is deprecated. xPDT helper module Function GetxPDTVariable was removed since it no longer was used by any resources. File xPDT.xml was removed since it was not used by any resources, and did not provide any value to the module. Changes xSQLServerHelper moduled Removed the globally defined `$VerbosePreference = Continue` from xSQLServerHelper. Fixed a typo in a variable name in the function New-ListenerADObject. Now Restart-SqlService will correctly show the services it restarts. Also fixed PSSA warnings.
xWebAdministration	1.17.0.0	Added removal of self signed certificate to the integration tests of xWebsite, fixes 276. Added EnabledProtocols to xWebApplication. Changed SSLFlags for xWebApplication to comma seperate multiple SSL flags, fixes 232.

How to Find Released DSC Resource Modules

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

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 DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.

How to Contribute

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

Questions, comments?

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

↧

PowerShell Open Source Community Dashboard

January 31, 2017, 4:54 pm

≫ Next: Installing latest PowerShell Core 6.0 Release on Linux just got easier!

≪ Previous: DSC Resource Kit Release January 2017

Since going cross-platform and open source on GitHub, I’ve wanted to know how we are doing as a community and who the top contributors we should recognize are.
The available GitHub graphs are not sufficient as they focus on commits, and there are many other ways for the community to contribute to PowerShell.
Certainly receiving Pull Requests (PRs) has a direct impact on the code base, but opening issues, commenting on issues, and commenting on PRs (aka code reviews) are also immensely appreciated and valuable to help improve PowerShell.In addition, PowerShell is not a single repository, but several repositories that help to make PowerShell successful:

PowerShell-RFC where we do design work for new proposed features
PowerShell-Docs which contains all the PowerShell help and documentation
platyPS: tooling for our help documentation that enables authoring and editing of docs in Markdown instead of XML
Microsoft.PowerShell.Archive: a built-in module for creating and expanding ZIP archives (in the future we plan to move other built-in modules to their own repositories like this)
ODataUtils: a module to generate PowerShell cmdlets from an OData REST endpoint
JEA where we store samples and resources associated with Just Enough Administration (JEA)
PSL-OMI-Provider: an optional component for Linux/Mac to enable PowerShell remoting over WS-Man protocol (both client and server)
PSReadline: the default interactive command line experience for PowerShell

Although most of the contributions happen in the PowerShell/PowerShell repo, I want to ensure we recognize contributions in these other repositories (and new ones in the future).

To get a more holistic view, I decided to create a dashboard in PowerBI.
A follow-up blog post will go into some of the technical details and challenges to having an Azure Function execute a PowerShell script calling GitHub REST APIs and storing the result in an Azure StorageTable queried by PowerBI.
The PowerShell scripts I used for this dashboard will be published to the PowerShell Gallery.

You can access the dashboard at http://aka.ms/PSGitHubBI.

The first page, Top Community Contributors, recognizes individuals outside of Microsoft for their contributions for each of the 4 types of contributions described previously.
Two things to note:

the rankings are based on a moving 30 day window
ties for the rank are due to individuals having exactly the same count for a contribution type

The second page, Top Microsoft Contributors, is the same as the first table but for Microsoft employees who are members of the PowerShell organization on GitHub.

The third page, Contributions over Time, has two graphs:

The first graph compares community contributions and Microsoft contributions.
It really shows that going open source was the right decision as the community has provided lots of contributions and helped to move PowerShell forward more than what the PowerShell Team could have done alone!
The second graph shows a comparison over time of the different types of contributions, but is not separated out between the community and Microsoft.

The last page, Downloads, shows a trend of the cumulative downloads of our official releases with a view comparing the different operating systems and the different release versions.
Eventually, I would like to replace the download numbers with usage numbers based on Census Telemetry, which is a much more accurate representation of growth of PowerShell adoption.

I intend to iterate and improve upon this dashboard to make it useful not only to the PowerShell Team, but also to the PowerShell community.
I plan to provide similar dashboards for some of our other projects such as DSC resources, ScriptAnalyzer, Editor Services, OpenSSH on Windows, and others.

Please leave any suggestions or feedback as comments to this blog post. If you find this dashboard useful, or you believe we can improve upon it in some way, please let us know!

Steve Lee
Principal Software Engineer Manager
PowerShell Core

↧

Installing latest PowerShell Core 6.0 Release on Linux just got easier!

February 1, 2017, 9:00 am

≫ Next: Building a GitHub Dashboard using PowerShell, AzureStorageTable, AzureFunction, and PowerBI

≪ Previous: PowerShell Open Source Community Dashboard

As we continue our journey from Alpha releases and eventually to Beta, you can continue to download the latest releases from our GitHub repository.
However, our goal has always been to enable installation through popular existing Linux package management tools like apt-get and yum.I am pleased to announce that we have now published PowerShell Core 6.0 alpha.15 to https://packages.microsoft.com!

Install PowerShell Core on Ubuntu 14.04

# Import the public repository GPG keys
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -

# Register the Microsoft Ubuntu repository
curl https://packages.microsoft.com/config/ubuntu/14.04/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list

# Update apt-get
sudo apt-get update

# Install PowerShell
sudo apt-get install -y powershell

# Start PowerShell
powershell

Install PowerShell Core on Ubuntu 16.04

# Import the public repository GPG keys
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -

# Register the Microsoft Ubuntu repository
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list

# Update apt-get
sudo apt-get update

# Install PowerShell
sudo apt-get install -y powershell

# Start PowerShell
powershell

Install PowerShell Core on CentOS

# Enter superuser mode
sudo su

# Register the Microsoft RedHat repository
curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/microsoft.repo

# Exit superuser mode
exit

# Install PowerShell
sudo yum install -y powershell

# Start PowerShell
powershell

After registering the Microsoft repository once as superuser, from then on, you just need to use either sudo apt-get install powershell or sudo yum update powershell (depending on which distro you are using) to update it.

We plan to simultaneously publish to https://packages.microsoft.com and our GitHub repository for each new release.

Steve Lee
Principal Software Engineer Manager
PowerShell Core

↧

Building a GitHub Dashboard using PowerShell, AzureStorageTable, AzureFunction, and PowerBI

February 9, 2017, 9:16 am

≫ Next: Managing Security Settings on Nano Server with DSC

≪ Previous: Installing latest PowerShell Core 6.0 Release on Linux just got easier!

Last week, I published a PowerShell Community Dashboard and today, I’m going to share the code and cover some of the learnings.The code is published as a module on the PowerShell Gallery.
Make sure you get v1.1 as I found an issue where if you’re not a member of the PowerShell Org on GitHub, you won’t have permission to query the members so I changed the code to accommodate that.You can install the module using:

install-module PSGitHubStats

(and it works on PowerShell Core 6.0 including Linux! I only tested it with alpha.15, though…)

Once installed, you can just run it manually:

PS C:\> Get-PSDownloadStats -publishedSinceDate 1-1-2017 -accessToken $accesstoken

Tag             Name                                                 OS      Distro    Count Published
---             ----                                                 --      ------    ----- ---------
v6.0.0-alpha.15 powershell-6.0.0-alpha.15.pkg                        MacOS   MacOS     1504  1/25/2017 7:25:52 PM
v6.0.0-alpha.15 powershell-6.0.0_alpha.15-1.el7.centos.x86_64.rpm    Linux   CentOS    436   1/25/2017 7:25:52 PM
v6.0.0-alpha.15 powershell_6.0.0-alpha.15-1ubuntu1.14.04.1_amd64.deb Linux   Ubuntu14  368   1/25/2017 7:25:52 PM
v6.0.0-alpha.15 powershell_6.0.0-alpha.15-1ubuntu1.16.04.1_amd64.deb Linux   Ubuntu16  951   1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win10-win2k16-x64.msi      Windows Windows10 349   1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win10-win2k16-x64.zip      Windows Windows10 70    1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win7-win2k8r2-x64.msi      Windows Windows7  119   1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win7-win2k8r2-x64.zip      Windows Windows7  34    1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win7-x86.msi               Windows Windows7  192   1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win7-x86.zip               Windows Windows7  17    1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win81-win2k12r2-x64.msi    Windows Windows8  74    1/25/2017 7:25:52 PM
v6.0.0-alpha.15 PowerShell_6.0.0-alpha.15-win81-win2k12r2-x64.zip    Windows Windows8  21    1/25/2017 7:25:52 PM

PS C:\> $contributors = Get-PSGitHubReport -startDate 1-1-2017 -repos powershell/powershell -accessToken $accesstoken
PS C:\> $contributors | ? {$_.Org -eq "Community"} | sort -Property Total -Top 10 -Descending

   Org: Community

Name             PRs               Issues           PR Comments      Issue Comments   Total            End Date
----             ---               ------           -----------      --------------   -----            --------
iSazonov         8                 4                44               46               102              2017-02-03 10...
vors             5                 4                12               6                27               2017-02-03 10...
thezim           0                 2                0                9                11               2017-02-03 10...
juneb            0                 4                0                4                8                2017-02-03 10...
Jaykul           0                 3                0                5                8                2017-02-03 10...
pcgeek86         0                 3                0                5                8                2017-02-03 10...
jeffbi           0                 0                0                6                6                2017-02-03 10...
MaximoTrinidad   0                 2                0                3                5                2017-02-03 10...
g8tguy           0                 0                0                5                5                2017-02-03 10...
mwallner         0                 1                0                3                4                2017-02-03 10...

The $accesstoken is something you would generate and needed because the number of queries I have to do against the GitHub API will likely exceed the unauthenticated rate limit.
I ran over the rate limit many times while generating my report, even as an authenticated user. I solved this by adding a sleep command to the report generation.

One thing you may notice with the module vs the dashboard is that you get the raw numbers rather than just the rankings.
On the dashboard, we decided to only show the rankings so that people don’t focus specifically on the numbers.

Get-PSDownloadStats should be pretty straight forward.
There is some specialized logic in that function to determine the target operating system for the release package which unfortunately depends on the filename.

Publishing to AzureTable is fairly simple once you figure out the magic sauce to provide in the headers to make sure you’re calling the appropriate version of the REST API:

if ($publishToAzure)
{
    $json = $pkg | ConvertTo-Json -Compress
    $date = [datetime]::UtcNow.ToString("R", [System.Globalization.CultureInfo]::InvariantCulture)
    [string] $canonicalizedResource = "/$storageAccount/$storageTable"
    $contentType = "application/json"
    [string] $stringToSign = "POST`n`n$contentType`n$date`n$canonicalizedResource"
    $headers = @{"Prefer"="return-no-content";"Authorization"=(CreateAuthHeader -canonicalizedString $stringToSign -storageAccount $storageAccount -storageKey $storageKey);
        "DataServiceVersion"="3.0;NetFx";"MaxDataServiceVersion"="3.0;NetFx";"Accept"="application/json;odata=nometadata";
        "Accept-Charset"="UTF-8";"x-ms-version"="2013-08-15";"x-ms-date"=$date}
    $null = Invoke-RestMethod -Uri $storageUrl -Headers $headers -Body $json -Method Post -ContentType $contentType
}

I deliberately chose to use an AzureTable for a few reasons:

Power BI supports reading from AzureTable natively (although I think you can only do it from the Power BI desktop app) as I couldn’t find the option in the web interface
I didn’t need the relational capabilities nor the additional cost of AzureSQL for my purposes
I can import JSON directly into AzureTable

The most complicated part of working with AzureTable is correctly crafting the authentication header built from a canonicalized string AzureTable expects to protect against replay attacks.
The string is defined in the previous code section as $stringToSign while this bit of code hashes it and converts the result to Base64:

Function CreateAuthHeader([string]$canonicalizedString,[string]$storageAccount,[string]$storageKey)
{
    [string]$signature = [string]::Empty
    [byte[]]$bytes = [System.Convert]::FromBase64String($storageKey)
    [System.Security.Cryptography.HMACSHA256] $SHA256 = New-Object System.Security.Cryptography.HMACSHA256(,$bytes)
    [byte[]] $dataToSha256 = [System.Text.Encoding]::UTF8.GetBytes($canonicalizedString)
    $signature = [System.Convert]::ToBase64String($SHA256.ComputeHash($dataToSha256))
    "SharedKey $($storageAccount):$signature"
}

Ilya‘s RFC on Get-StringHash should help make this simpler and more readable eliminating several lines of code from that function.

Once I had the module working in the command line, I validated it was correctly uploaded to Azure using Microsoft Azure Storage Explorer. Now I needed to have the script run regularly. I considered both Azure Automation and Azure Functions and decided to use the latter as it was newer, which gave me an opportunity to learn it. One immediate problem I had is that Azure Functions today only supports PowerShell v4. I originally used PowerShell classes for my internal types and thus changed it all to PSCustomObjects.
I’ve since contacted the Azure Functions team and asked them to support both Windows PowerShell v5.x and PowerShell Core 6.0 in the future.

With Azure Functions, you really only have the ability to run a PowerShell script. This means that unless you install the Azure PowerShell module at runtime (and PowerShellGet isn’t part of PowerShell v4), you really can only use what is available with PowerShell. Azure Automation would be better suited if you want to use modules.

I just cut and pasted the code out of my module into the web interface and added a call to my functions at the end supplying all the necessary parameters to make sure I was getting the right data from GitHub, and uploading the data correctly into AzureTable. One thing to note is that you’ll see I pass -UseBasicParsing to all my Invoke-WebRequest calls as the ParsedHtml property in the output relies on MSHTML which relies on Internet Explorer.
IE is not available in the Azure Function container your script is running in. I should also mention that I use both Invoke-WebRequest and Invoke-RestMethod where the former is needed when I need to access the response headers specifically for pagination of the GitHub API response which is handled by this bit of code:

if ($null -ne $output.Headers.Link) {
    $links = $output.Headers.Link.Split(",").Trim()
    foreach ($link in $links) {
        if ($link -match "<(?<url>.*?)>;\srel=`"(?<rel>.*?)`"") {
            if ($matches.rel -eq 'next') {
                $query = $matches.url
            }
        }
    }
}

I’ll be working to add this capability into Invoke-RestMethod so this bit of code can be removed.

Building the Power BI visualization is a whole other topic and @MSFTzachal really did most of the work, but my recommendation is to use the Power BI desktop app which I found easier and more powerful than the current web interface.

Steve Lee
Principal Software Engineer Manager
PowerShell Core

↧

Managing Security Settings on Nano Server with DSC

February 17, 2017, 12:40 pm

≫ Next: Code Coverage – Part 2

≪ Previous: Building a GitHub Dashboard using PowerShell, AzureStorageTable, AzureFunction, and PowerBI

We have released DSC resources building upon the previously released security and registry cmdlets for applying security settings. You can now implement Microsoft-defined security baselines using DSC.

AuditPolicyDsc

SecurityPolicyDsc

GPRegistryPolicy

Install all 3 from the Gallery with the command:

install-module SecurityPolicyDsc, AuditPolicyDsc, GpRegistryPolicy

A sample configuration, below, takes the Security Baselines for Windows Server 2016 and extracts the .inf, .csv and .pol containing the desired security settings from the exported Group Policy Objects. (You can find information on extracting the necessary files in the Registry cmdlets blogpost.) Simply pass the files into the new DSC resources, and you have successfully implemented security baselines using DSC!

This is most useful for Nano Server, since Nano Server doesn’t support Group Policy. However, this approach will work for all installation options. It’s not a good idea to manage the same server using both Group Policy and DSC since the two engines will constantly attempt to overwrite each other if they are both managing the same setting.

WARNING: As with all security settings, you can easily lock yourself out of remote access to your machine if you are not careful. Be sure to carefully review security settings before applying them to Nano Server, and stage test deployments before using security baselines in production!

Configuration SecurityBaseline
{
    Import-DscResource -ModuleName AuditPolicyDsc, SecurityPolicyDSC, GpRegistryPolicy
    node localhost
    {
        SecurityTemplate baselineInf
        {
            Path = "C:\Users\Administrator\Documents\GptTmpl.inf"
            # https://msdn.microsoft.com/powershell/dsc/singleinstance
            IsSingleInstance = "Yes"
        }
        AuditPolicyCsv baselineCsv
        {
            IsSingleInstance = "Yes"
            CsvPath = "C:\Users\Administrator\Documents\audit.csv"
        }
        RegistryPolicy baselineGpo
        {
            Path = "C:\Users\Administrator\Documents\registry.pol"
        }
    }
}
#Compile the MOF file
SecurityBaseline
Start-DscConfiguration -Path ./SecurityBaseline

↧

Code Coverage – Part 2

February 22, 2017, 3:36 pm

≫ Next: Using PowerShell Modules in Azure Functions

≪ Previous: Managing Security Settings on Nano Server with DSC

In my last post on code coverage, I shared the process for you to collect coverage for your environment. This week, I’ll be describing a way to use our tools to create new tests and show how you can measure the increase of coverage for PowerShell Core after adding new tests. To recap, we can collect code coverage with the OpenCover module, and then inspect the coverage. In this case I would like to know about coverage for a specific cmdlet. For this post, we’re going to focus on the Clear-Content Cmdlet because coverage is ok, but not fantastic and it is small enough to go over easily.

Here’s a partial capture from running the OpenCover tools:

By selecting the class Microsoft.PowerShell.Commands.ClearContentCommand we can drill into the specifics about the class which implements the Clear-Content cmdlet. We can see that we have about 47% line coverage for this class which isn’t fantastic, by inspecting the red-highlights we can see what’s missing.

It looks like there are some error conditions, and some code which represents whether the underlying provider supports should process are not being tested. We can create tests for these missing areas fairly easily, but I need to know where these new tests should go.

Test Code Layout

Now is a good time to describe how our tests are laid out.

https://github.com/PowerShell/PowerShell/test contains all of the test code for PowerShell. This includes our native tests, C-Sharp tests and Pester tests as well as the tools we use. Our Pester tests should all be found in https://github.com/PowerShell/PowerShell/test/powershell and in that directory there is more structure to make it easier to find tests. For example, if you want to find those tests for a specific cmdlet, you would look in the appropriate module directory for those tests. In our case, we’re adding tests for Clear-Content, which should be found in https://github.com/PowerShell/PowerShell/test/powershell/Modules/Microsoft.PowerShell.Management. (You can always find which module a cmdlet resides via get-command). If we look in this directory, we can already see the file Clear-Content.Tests.ps1, so we’ll add our tests to that file. If that file didn’t exist, you should just create a new file for your tests. Sometimes the tests for a cmdlet may be combined with other tests. Take this as an opportunity to split up the file to make it easier for the next person adding tests. If you want more information about how we segment our tests, you can review https://github.com/PowerShell/PowerShell/docs/testing-guidelines/testing-guidelines.md.

New Test Code

Based on the missing code coverage, I created the following replacement for Clear-Content.Tests.ps1 which you can see in this PR: https://github.com/PowerShell/PowerShell/pull/3157. After rerunning the code coverage tools, I can see that I’ve really improved coverage for this cmdlet.

There seems to be a small issue with OpenCover as some close braces are not being marked as missed, but you can see the improvement:

Now it’s your turn and we could really use your help. If you have areas of the product that you rely on, and don’t have the tests that you think they should have, please consider adding tests!

↧

Using PowerShell Modules in Azure Functions

February 24, 2017, 12:16 pm

≫ Next: DSC Resource Kit Release March 2017

≪ Previous: Code Coverage – Part 2

Previously, I blogged about how I created PowerShell GitHub Dashboard using Azure Functions to run a PowerShell script and didn’t use PowerShell Modules as I didn’t find an easy way to do it with Azure Functions. Stefan informed me that you can easily do it using FTP! Today, I’m publishing a guest blog post that Stefan authored that walks you through how to use PowerShell Modules in Azure Functions!

Steve Lee published a couple of blog posts about how he created a PowerShell Open Source Community Dashboard in PowerBi. In his last blog post he explained how he used PowerShell, Azure StorageTable, Azure Function and PowerBi to create the Dashboard.

In his solution, the Azure Function is executing a PowerShell script which calls the Github REST APIs and stores the result in an Azure StorageTable, finally queried by PowerBI.

Azure Functions and especially PowerShell Azure Functions are something I’m interested in for the last couple of weeks. I already wrote a blog post called “PowerShell Azure Functions lesson learned“. If you are just starting to explore PowerShell Azure Functions I would highly recommend to look.

In his blog post Steve mentions that within Azure Functions you only can run a PowerShell script and that you cannot use PowerShell modules within your PowerShell Azure Function. Well that’s not correct, there is a way to use PowerShell Modules within your PowerShell Azure Function.

In this blog post I’ll explain how you could start using PowerShell Modules in Azure Functions. I’ve to give credit to David O’Brien for introducing PowerShell Azure Functions to me.

Which PowerShell Modules are available with a PowerShell Azure Function?

First you need to create an Azure Function. On the Github page about Azure Functions you can find all the info to get started.

After creating your PowerShell Azure Function, you can start exploring the current available PowerShell Modules just like you would do on your local machine.

Get-Module -ListAvailable | Select-Object Name, Version | Sort-Object -Property Name

Let first start with retrieving the currently installed PowerShell Modules in Azure Functions by outputting the result to the log window in Azure Functions. We are also interested in the locations of the PowerShell Modules.

Write-Output ‘Getting PowerShell Module’

$result = Get-Module -ListAvailable |

Select-Object Name, Version, ModuleBase |

Sort-Object -Property Name |

Format-Table -wrap |

Out-String

Write-output `n$result

Copy above PowerShell code into the run.ps1 Azure Function and click on Run.

If we expand the log window we see that the following PowerShell Modules are installed.

I prefer to see the output result in my PowerShell ISE so I often use the following code in my Azure Function.

$result = Get-Module -ListAvailable |

Select-Object Name, Version, ModuleBase |

Sort-Object -Property Name |

Convertto-Json -depth 1

Out-File -encoding Ascii -FilePath $res -inputObject $Result

You can now call your Azure Function from the PowerShell ISE with the following PowerShell script.

$HttpRequestUrl = ‘[enter azure function url here]’

Invoke-RestMethod -Uri $HttpRequestUrl -Method POST -ContentType ‘application/json’ | ConvertFrom-Json

This results in the following.

The next step is checking the Environment variable PSModulePath to find out where all the PowerShell Modules are stored.

$result = $env:psmodulepath |

Convertto-Json -depth 1

Out-File -encoding Ascii -FilePath $res -inputObject $Result

Where can we store our own PowerShell Modules?

Well because Function apps are built on App Service, all the deployment options available to standard web apps are also available for function apps The App Service has a deployment option to configure deployment credentials.

Remark: When you configure a FTP/Deployment username and password this applies to all your Web Apps within your Microsoft Azure Account.

To upload PowerShell Modules via FTP we need to configure the Function App Settings.

Select Function app settings -> Go to App Service Settings to configure the Deployment credentials.

Next select in the App Service settings for the Azure Function Deployment Credentials.

Enter a FTP/deployment username and password.

Now you are ready to connect via a FTP client to your Azure Function (Web App).

You can find the FTP Hostname in your Azure Portal.

Connect via FTP Client to Azure Function Web App

Open your favorite FTP Client and connect to the FTP endpoint. I’m using Filezilla as my favorite FTP client.

Copy and past host, username from App Service overview page on the Azure Portal and click on Quickconnect.

After connecting via FTP we can create a new Module folder under wwwroot\HttpTriggerPowerShellDemo (or your name of your Azure Function). Create a new directory called Modules.

After the creation of the Modules directory we can upload our PowerShell Module(s) to this remote directory. Make sure you have first downloaded your module to your local system. We are going to upload my favorite PowerShell Module Wunderlist.

Drag and drop the local Wunderlist module to the remote Modules folder.

You have now uploaded the Wunderlist module to your Azure Function.

How can we start using this module in our Azure Function?

First we can check if we can load the module and return the help from one of the Functions in the Module.

Use the following code in your Azure Function:

Write-Output “Loading Wunderlist Module”

import-module ‘D:\Home\site\wwwroot\HttpTriggerPowerShellDemo\Modules\Wunderlist\1.0.10\Wunderlist.psm1’

$Result = Get-Help Get-WunderlistUser | Out-String

Write-Output $Result

Result:

To get my Wunderlist Module working you need to also configure a ClientId and AccessToken. For more information you can check the following blog post Using Wunderlist Module in Azure Automation–Part 2. Long story short, you need to store the ClientID and AccessToken as Environment variables using the Web App Settings.

Go to Function App Settings and click on Configure app settings.

Add ClientID and AccessToken variables in the Application settings. Don’t forget to Save the new settings.

We can now use these Environment variables in our Azure Function without any extra configuration needed.

As a final test, we are going to test if we can create a new Wunderlist Task from our Azure Function.

By using a HTTP Post method with a body value as input for our Function we can do some more advanced Azure Function activities.

Use the following code in your Azure Function:

# Get the input request

$in = Get-Content $req -Raw | ConvertFrom-Json

Write-Output $in.Title

# Import Wunderlist Module

Write-Output “Loading Wunderlist Module”

import-module ‘D:\Home\site\wwwroot\HttpTriggerPowerShellDemo\Modules\Wunderlist\1.0.10\Wunderlist.psm1’

# Create new Wunderlist Task

Write-Output “Creating Wunderlist Task”

$Result = New-WunderlistTask -listid ‘267570849’ -title $in.Title

Write $Result

Hope you have now learned how to use your “own” PowerShell modules within your PowerShell Azure Functions.

Stefan Stranger
Secure Infrastructure Consultant
Microsoft

↧

DSC Resource Kit Release March 2017

March 8, 2017, 4:31 pm

≫ Next: Windows Management Framework (WMF) 5.1 now in Microsoft Update Catalog

≪ Previous: Using PowerShell Modules in Azure Functions

We just released the DSC Resource Kit!

This release includes updates to 10 DSC resource modules, including 19 new DSC resources. In these past 6 weeks, 155 pull requests (the most ever!) have been merged and 71 issues have been closed, all thanks to our amazing community!

A few weeks ago we also released a new DSC resource module called SecurityPolicyDsc with resources to configure local security policies through secedit. Thank you to Jason Walker for this great new module!

The modules updated in this release are:

OfficeOnlineServerDsc
PSDscResources
SecurityPolicyDsc
SharePointDsc
xCertificate
xExchange
xPSDesiredStateConfiguration
xRemoteDesktopSessionHost
xSQLServer
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 March 1. A recording of our updates as well as summarizing notes are available. Join us next time at 9AM PST on April 12 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.

Included in this Release

Module Name	Version	Release Notes
OfficeOnlineServerDsc	1.0.0.0	Added documentation to the module to finalise for release Renamed resources to shorten names before release “OfficeOnlineServerWebAppsFarm” becomes “OfficeOnlineServerFarm” “OfficeOnlineServerWebAppsMachine” becomes “OfficeOnlineServerMachine”
PSDscResources	2.5.0.0	Enable codecov.io code coverage reporting Group Added support for domain based group members on Nano server. Added the Archive resource Update Test-IsNanoServer cmdlet to properly test for a Nano server rather than the core version of PowerShell Registry Fixed bug where an error was thrown when running Get-DscConfiguration if the registry already existed
SecurityPolicyDsc	1.2.0.0	SecurityTemplate: Remove [ValidateNotNullOrEmpty()] attribute for IsSingleInstance parameter Fixed typos
SharePointDsc	1.6.0.0	Updated SPWebApplication to allow Claims Authentication configuration Updated documentation in regards to guidance on installing binaries from network locations instead of locally New resources: SPFarmPropertyBag Bugfix in SPSite, which wasnt returing the quota template name in a correct way Bugfix in SPAppManagementServiceApp which wasnt returning the correct database name Bugfix in SPAccessServiceApp which did not return the database server Bugfix in SPDesignerSettings which filtered site collections with an incorrect parameter Updated the parameters in SPFarmSolution to use the full namespace Bugfix in SPFarmsolution where it returned non declared parameters Corrected typo in parameter name in Get method of SPFeature Added check in SPHealAnalyzerRuleState for incorrect default rule schedule of one rule Improved check for CloudSSA in SPSearchServiceApp Bugfix in SPSearchServiceApp in which the database and dbserver were not returned correctly Improved runtime of SPSearchTopology by streamlining wait processes Fixed bug with SPSearchServiceApp that would throw an error about SDDL string Improved output of test results for AppVeyor and VS Code based test runs Fixed issue with SPWebAppPolicy if OS language is not En-Us Added SPFarm resource, set SPCreateFarm and SPJoinFarm as deprecated to be removed in version 2.0
xCertificate	2.4.0.0	Converted AppVeyor build process to use AppVeyor.psm1. Correct Param block to meet guidelines. Moved shared modules into modules folder. xCertificateExport: Added new resource. Cleanup xCertificate.psd1 to remove unneccessary properties. Converted AppVeyor.yml to use DSCResource.tests shared code. Opted-In to markdown rule validation. Examples modified to meet standards for auto documentation generation.
xExchange	1.14.0.0	xExchDatabaseAvailabilityGroup: Added parameter AutoDagAutoRedistributeEnabled,PreferenceMoveFrequency
xPSDesiredStateConfiguration	6.1.0.0	Moved DSC pull server setup tests to DSCPullServerSetup folder for new common tests xArchive: Updated the resource to be a high quality resource Transferred the existing “unit” tests to integration tests Added unit and end-to-end tests Updated documentation and examples xUser Fixed error handling in xUser xRegistry Fixed bug where an error was thrown when running Get-DscConfiguration if the registry key already existed Updated Test-IsNanoServer cmdlet to properly test for a Nano server rather than the core version of PowerShell
xRemoteDesktopSessionHost	1.4.0.0	Updated CollectionName parameter to validate length between 1 and 15 characters, and added tests to verify.
xSqlServer	6.0.0.0	Changes to xSQLServerConfiguration BREAKING CHANGE: The parameter SQLInstanceName is now mandatory. Resource can now be used to define the configuration of two or more different DB instances on the same server. Changes to xSQLServerRole xSQLServerRole now correctly reports that the desired state is present when the login is already a member of the server roles. Added new resources xSQLServerAlwaysOnAvailabilityGroup Changes to xSQLServerSetup Properly checks for use of SQLSysAdminAccounts parameter in $PSBoundParameters. The test now also properly evaluates the setup argument for SQLSysAdminAccounts. xSQLServerSetup should now function correctly for the InstallFailoverCluster action, and also supports cluster shared volumes. Note that the AddNode action is not currently working. It now detects that feature Client Connectivity Tools (CONN) and Client Connectivity Backwards Compatibility Tools (BC) is installed. Now it can correctly determine the right cluster when only parameter InstallSQLDataDir is assigned a path (issue 401). Now the only mandatory path parameter is InstallSQLDataDir when installing Database Engine (issue 400). It now can handle mandatory parameters, and are not using wildcards to find the variables containing paths (issue 394). Changed so that instead of connection to localhost it is using $env:COMPUTERNAME as the host name to which it connects. And for cluster installation it uses the parameter FailoverClusterNetworkName as the host name to which it connects (issue 407). When called with Action = “PrepareFailoverCluster”, the SQLSysAdminAccounts and FailoverClusterGroup parameters are no longer passed to the setup process (issues 410 and 411). Solved the problem that InstanceDir and InstallSQLDataDir could not be set to just a qualifier, i.e “E:” (issue 418). All paths (except SourcePath) can now be set to just the qualifier. Enables CodeCov.io code coverage reporting. Added badge for CodeCov.io to README.md. Examples xSQLServerMaxDop 1-SetMaxDopToOne.ps1 2-SetMaxDopToAuto.ps1 3-SetMaxDopToDefault.ps1 xSQLServerMemory 1-SetMaxMemoryTo12GB.ps1 2-SetMaxMemoryToAuto.ps1 3-SetMinMaxMemoryToAuto.ps1 4-SetMaxMemoryToDefault.ps1 xSQLServerDatabase 1-CreateDatabase.ps1 2-DeleteDatabase.ps1 Added tests for resources xSQLServerMaxDop xSQLServerMemory Changes to xSQLServerMemory BREAKING CHANGE: The mandatory parameter now include SQLInstanceName. The DynamicAlloc parameter is no longer mandatory Changes to xSQLServerDatabase When the system is not in desired state the Test-TargetResource will now output verbose messages saying so. Changes to xSQLServerDatabaseOwner Fixed code style, added updated parameter descriptions to schema.mof and README.md.
xWindowsUpdate	2.6.0.0	Converted appveyor.yml to install Pester from PSGallery instead of from Chocolatey. Fixed PSScriptAnalyzer issues. Fixed common test breaks (markdown style, and example style). Added CodeCov.io reporting Deprecated xMicrosoftUpdate as it”s functionality is replaced by xWindowsUpdateAgent

How to Find Released DSC Resource Modules

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

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 DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.

How to Contribute

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

Questions, comments?

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

↧

Windows Management Framework (WMF) 5.1 now in Microsoft Update Catalog

March 28, 2017, 10:27 am

≫ Next: Regular cadence for PowerShell Core Community Call

≪ Previous: DSC Resource Kit Release March 2017

The Windows Management Framework (WMF) 5.1 is now available in the Microsoft Update catalog for Windows Server 2012, Windows Server 2012 R2, and Windows 8.1. These updates are listed in the catalog as KB3191564 and KB3191565. Those who use WSUS to manage updates for their systems are now able to install WMF 5.1 for most of the WMF-supported Windows versions.

The packages for Windows 7 and Windows Server 2008 R2 are only available via the Download Center at this time.

As previously announced, WMF 5.1 is a required update for WMF 5.0, and may be installed directly over WMF 5.0. As of June 1, 2017, users with WMF 5.0 must upgrade to WMF 5.1 to receive support. At that time, WMF 5.0 will be removed from the Download Center and from the WSUS catalog.

As always, we welcome your feedback on PowerShell and WMF via our UserVoice site.

Thank you –

The PowerShell Team

↧

Regular cadence for PowerShell Core Community Call

March 30, 2017, 1:05 pm

≫ Next: A Comparison of Shell and Scripting Language Security

≪ Previous: Windows Management Framework (WMF) 5.1 now in Microsoft Update Catalog

tl;dr: PowerShell Core Community Calls are on the third Thursday of every month at 9:30am Pacific Time (note, this is currently PDT). Use this .ics file to avoid missing one.

Hi everyone! After three successful PowerShell Core Community Calls, we’re switching to a more standard cadence so that you can plan ahead and join us! For those of you that haven’t heard of the PowerShell Core Community Call, it’s a one hour meeting where the PowerShell Committee gets together to talk with you to help us make decisions on the evolving design of PowerShell 6.

We discuss RFCs, feature requests, and contentious bugs, in addition to giving you a quick update about the status of the project and the direction we’re headed.

If you want to catch up on our last three calls to get a feel for what they’re like, you can find some notes, chat transcripts, and YouTube recordings in a folder marked CommunityCall in the PowerShell-RFC repository.

Typically, we start by discussing the following:

RFCs tagged as Review - Committee
Issues tagged as Review - Committee
PRs tagged as Review - Committee
Anything else you want to bring to the table!

Join us on Skype on the 3rd Thursday of every month @ 9:30am PDT (Pacific Daylight Time, GMT -0700):

Join Skype Meeting
Join by phone (US): +1 (866) 641-7188 or find a local number
Conference ID: 4334578

.ics file

And if there’s anyone else you know that might be interested in getting more involved in PowerShell development, feel free to invite them to the call!

↧

A Comparison of Shell and Scripting Language Security

April 10, 2017, 10:02 am

≫ Next: DSC Resource Kit Release April 2017

≪ Previous: Regular cadence for PowerShell Core Community Call

PowerShell Security is a topic on everybody’s mind. Most of all – ours.

As PowerShell has become more popular with Administrators, it has also become more popular for unauthorized administrators – also known as “Attackers”. In any operating system or platform, the power and efficiency you provide to authorized administrators is also available to unauthorized administrators. For example, Unix, Linux, and Mac all have dozens of powerful built in compilers, scripting languages, and debuggers. It’s a power user’s dream, but also a liability.

The PowerShell team has recognized this double-edged sword since the introduction of PowerShell in 2006. In the last 10 years, we’ve invested greatly in both securing and hardening PowerShell. In PowerShell version 5, we really cranked up the dials on making PowerShell security transparent – the results of which we describe in our post, “PowerShell ♥ the Blue Team“.

As part of this effort, we’ve also done a deep comparative analysis on security between available shells and scripting languages. Where are we weak? What security features do other shells or scripting languages offer that PowerShell could perhaps learn from?

We broke this evaluation into seven major categories:

Event Logging – The engine logs audit events of important operational events.
Transcription – The engine logs application inputs and outputs.
Dynamic Evaluation Logging – The engine logs the content of all content evaluation, including those generated or composed at runtime.
Application Whitelisting – The engine allows enforcement of code integrity / application whitelisting policies, including user-authored documents / scripts.
Antimalware Integration – The engine actively integrates with antimalware software to evaluate the safety of code generated at runtime.
Local Sandboxing – The engine allows sandboxing of behavior for local and interactive use.
Remote Sandboxing – The engine allows sandboxing of behavior when accessed remotely.
Untrusted Input Tracking – The engine allows script developers to track and make security decisions based on whether a variable or input was influenced by user input.

This is the result of our analysis. We would love any feedback you have – especially if you are aware of a feature or protection we missed. Misrepresenting any of this data does nobody any good.

Lee Holmes [MSFT]
Azure Management Security

↧