Planet PowerShell Announcement - Enforcing HTTPS

Planet PowerShell

Planet PowerShell has grown over the last 18 months since its launch. The community has grown to over 60 talented individuals, with great content posted every day. During this time, I've been very cautious of making many significant changes, but this is about to change.

I've been working on some plans to improve Planet PowerShell and will be sharing the roadmap in the next few weeks. I wanted to make the first announcement early as it may require work from the content authors. I want to be sure that everyone is aware of this change.

From the 1st of August 2018, Planet PowerShell will only support aggregating blogs that support HTTPS. Not only that, but we will also validate the certificates presented. Any blogs that don't support HTTPS with a valid certificate will be removed from Planet PowerShell.

Why am I making this change? Simply, I'm making this change to make the world a safer place. There are many great reasons for making the switch:

• Protecting people’s privacy
• The browsers are starting to mark HTTP as insecure
• HTTPS gets better rankings in search engines
• HTTP 2 provides significant performance benefits.

I really can’t find a reason not support HTTPS on your blog. Getting a certificate is extremely easy and there are free options available. You can get a free certificate from Let’s Encrypt, put your blog behind CloudFlare for free or if you're a Microsoft MVP, DigiCert can issue one to you. If you're using GitHub pages, you can find extra guidance at Troubleshooting custom domains.

This gives everyone over 6 ½ weeks to prepare for this change. I've already gone through and identified blogs who are currently using HTTP but support HTTPS, I'll merge update for these shortly.

Currently are around 10 blogs that don’t support HTTPS, or have invalid certificates. I've created an Issue on GitHub to track this change and will include everyone whose blog doesn’t support HTTPS there.

GitHub Issue Templates and Plaster

GitHub recently announced new features and support for multiple issue templates. Before, GitHub supported a single template, by supporting multiple types of issues, we can gather the right information from the beginning.

When we create multiple issue templates, users will be prompted to specify the type of issue they want to create. We can target specific questions or information requests for specific types of issues.

GitHub provides two pre-created templates, bug report and feature request. These pre-created templates suit most situations. Bug report issues can focus on reproduction, expected behavior and other troubleshooting information. Feature request templates can focus on understanding the what, how and why a new feature is required. You can also create your own templates for other situations, you don’t have to use what GitHub provides.

I've updated my Plaster template for PowerShell modules to contain a bug report and feature request template. I modified GitHub’s template to ask for things like: • PowerShell transcripts. • Operating System and PowerShell versions. • A list of any other modules that might imported.

You can create templates via the GitHub interface, or simply include them in the ISSUE_TEMPLATE folder in your repository. You can also create the templates yourself. You need to include the name and a description for each template. Much like this:

---
name: Bug report
about: Create a report to help us improve

---

So, what do the new templates look like for a user? If you select Issues > New Issue, you can now select what kind of issue you'd like to raise. In the case in the image, we can choose bug report or feature request. Users can opt for “Open a regular issue”, in this case GitHub will use ISSUE_TEMPLATE.MD.

You can also define multiple pull request templates in the same manner. Simply put each template into the PULL_REQUEST_TEMPLATE folder. The experience is like creating an Issue. I'm creating different pull request templates for Planet PowerShell, so we can correctly track changes.

If you want to start using these templates as part of your Plaster templates, you can see my examples over at my Plaster template.

Presentation: Secure Azure Deployment Patterns

It was a wonderful experience to present at the Azure Global Bootcamp in Melbourne this year. This year I spoke about possible methods or patterns for securing Azure resources. This is an extremely board topic, though I focused on App Services, Virtual Network Endpoints and ARM templates.

You can find the PowerPoint slides to download here or view them via SlideShare.

Secure Azure Deployment Patterns from kieranjacobsen

Posh-SYSLOG 3.3 has been released

Several days ago, Jared (powershellshock) raised a Pull Request for Posh-SYSLOG to correct an issue with the module’s manifest. It seems that in version 3.0 of Posh-SYSLOG, I used the PowerShellHostVersion attribute of the module manifest and not PowerShellVersion to specify the minimum Powershell version. This wouldn't have created issues within a normal PowerShell session, but would have prevented the module from loading in VS Code (as Jared reported) or the ISE.

To understand the difference of these attributes, I suggest reading: PowerShellHostVersion – WTF?, by Jeffrey Snover.

This is by far my most popular module and it's become even more popular this year. Since January there's been almost 20 000 downloads of the module, compared to 1600 for the previous 2 years combined! I'm amazed that this simple little module has gained such popularity!

Getting the Module

If you have never used the module before, the easiest way to get Posh-SYSLOG is through the PowerShell Gallery:

PS> Install-Module -Name Posh-SYSLOG

If you already have the module installed, you can update the module from the PowerShell Gallery with:

PS> Update-Module -Name Posh-SYSLOG

You can also find the module on GitHub.

Found an issue? Then raise any bugs or feature requests via GitHub Issues.

AzurePublicIPAddresses v1.0 has been released

I'm pleased to announce Version 1.0 of AzurePublicIPAddresses. This version includes support 6 new Azure regions:

• Australia Central
• Australia Central 2
• UK North
• UK South 2
• North Europe 2 (name TBC)
• East Europe (name TBC)

This release also represents a major milestone since the modules creation back in March 2016. The module has proven to be very stable, and hence I'm now giving it the stable 1.0 moniker. I'm confident that the existing design should support any new regions or source XML files that Microsoft may release without the need for breaking changes.

What's the future for this module? With the launch of Azure Service Tags, in some respects this module has become less useful, but, I'll maintain the module for the immediate future.

I'm also thinking how this module and the JSON based file for Azure Service Tags should fit together. My current through it to create a separate module that consumes that file and allows you to select addresses by region and service.

Getting the Module

If you have never used the module before, the easiest way to get AzurePublicIPAddresses is through the PowerShell Gallery:

PS> Install-Module -Name AzurePublicIPAddresses

If you already have the module installed, you can update the module from the PowerShell Gallery with:

PS> Update-Module -Name AzurePublicIPAddresses

You can also find the module on GitHub.

Found an issue? Then raise any bugs or feature requests via GitHub Issues.

PowerShell Syntax Highlighting with SquareSpace

SquareSpace has been my blogging platform of choice since 2011. My biggest complaint with the platform has always been syntax highlighting. SquareSpace comes with some simple highlighting, but it only supports a few languages, certainly not PowerShell. Over the years I've tried everything from simply using bold and italic text, to using custom HTML and even embedded Pastebin and GitHub Gists. No matter what I tried, I was never happy with the result.

I'd looked and failed to find something that worked. While I was preparing for my post Managing Windows Speculation Control Protections with PowerShell DSC, I decided to take one more look. Stephen Gurnett had written a post about highlighting support for Swift with SquareSpace using Highlight.js. I took a quick look and realised this would work for PowerShell.

Highlight.js provides syntax highlighting for 176 languages with 79 different styles. It features automatic language detection, supports multiple languages per page and works with any markup or js framework. The best part is it's dead simple, even on a SaaS blog like SquareSpace. You don’t need to host the code anywhere as it's available via CloudFlare's CDN.

Getting Started with Highlight.js

The first step is including the code on our site. From the SquareSpace configuration/management screen, navigate to Settings > Advanced (Under Website) > Code Injection. You'll see 4 sections, Header, Footer, Lock Page and Order Confirmation Page. In the header section, add this HTML:

<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/vs2015.min.css">
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/languages/powershell.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>

What does this all mean?

The first line tells a visitor’s browser to load another CSS stylesheet. In this example, the Visual Studio 2015 theme. Don’t worry, your existing styles can safely live together with the Highlight.js stylesheet.

The next line loads the Highlight.js JavaScript. This is the code that will make syntax highlighting work on your blog. We're loading it from CloudFlare’s JavaScript CDN.

The third line is important. By default, the Highlight.js that's available from CDN only supports a set of common languages: CSS, JavaScript, C#, Bash, INI, SQL, Markdown, JSON, HTML, etc. Sadly, PowerShell isn’t one of the common languages. To support PowerShell, we need this line to load the support for it.

The last line causes the magic to happen. This line triggers the Highlight.js to go and highlight any code blocks that it finds.

Using Highlight.js

For Highlight.js to work on SquareSpace, you'll need to use the markdown content block and then use the code block syntax. Your Markdown block would look something like:

```
Write-Host 'This is some PowerShell!'
```

That block would result in the this:

Write-Host 'This is some PowerShell!'

Highlight.js will attempt to detect what language is used within the content block, though you can specify the language. I opt to specify the language. You can specify blocks like this:

```json
[
  {
    "title": "apples",
    "count": [12000, 20000],
    "description": {"text": "...", "sensitive": false}
  },
  {
    "title": "oranges",
    "count": [17500, null],
    "description": {"text": "...", "sensitive": false}
  }
]
```

Which results in:

[
  {
    "title": "apples",
    "count": [12000, 20000],
    "description": {"text": "...", "sensitive": false}
  },
  {
    "title": "oranges",
    "count": [17500, null],
    "description": {"text": "...", "sensitive": false}
  }
]

If you don’t want to use markdown for all your content, you can always mix text and markdown blocks.

Issues

So Highlight.js isn’t perfect, especially its PowerShell support. Highlight.js doesn’t properly highlight all PowerShell syntax, for instance, it will only highlight CMDLets that it knows about. Support for things like DSC or Pester isn’t present. While annoying, these aren't show stopping issues.

Conclusion

I hope this helps you work with PowerShell in SquareSpace. Happy Blogging!

AzurePublicIPAddresses module now supports the France and Germany Azure Regions

Map of Azure Regions as of February 2018

I'm pleased to announce that my PowerShell for working with Azure’s public IP address listings now supports the new Azure Regions in France and Germany. This release, 0.9, introduces some minor breaking changes, needed to support the Germany regions.

Each month of so, I check the Microsoft Azure Datacenter IP Ranges file for new regions. This month, I noticed that the France Central and France South are included.

The Azure Germany regions, Germany Northeast and Germany Central, are managed under a trustee model by T-Systems. This is like that of Azure in China. I hadn’t seen the German regions IP ranges before, but last week I found the file: Windows Azure Datacenter IP Ranges in Germany. My goal always was to support every available Azure Region, as such, I've now included these regions.

I must admit, I didn’t fully design this module to be future proof, I assumed all regions would be included in a single file. I first included Azure in China in version 0.8, with the -ChinaRegion parameter. While functional, this wasn’t future proof. To offer support for Azure Germany, version 0.8 includes some breaking changes in the Get-MicrosoftAzureDatacenterIPRangeFile CMDLet.

With version 0.9, I've removed the -ChinaRegion parameter and replaced it with -Region. This new parameter takes one of 3 values: Standard, China or Germany. This parameter now has this behaviour:

• Standard: the default value, downloads the Microsoft Azure Datacenter IP Ranges file.
• China: downloads the Windows Azure Datacenter IP Ranges in China file
• Germany: downloads the Windows Azure Datacenter IP Ranges in Germany file

If you were separately downloading the China region file, you'll need to ensure that you update your scripts logic.

I've also tweaked Get-MicrosoftazureDatacenterIPRange. The first change was to add support for the extra file to download, and the parameter change. I've also modified the logic around how the CMDLet stores the region information. I don’t expect these changes to cause any issues.

Getting the Module

If you have never used the module before, the easiest way to get AzurePublicIPAddresses is through the PowerShell Gallery:

PS> Install-Module -Name AzurePublicIPAddresses

If you already have the module installed, you can update the module from the PowerShell Gallery with:

PS> Update-Module -Name AzurePublicIPAddresses

You can also find the module on GitHub.

Found an issue? Then raise any bugs or feature requests via GitHub Issues.

Managing Windows Speculation Control Protections with PowerShell DSC

As part of their response to the Speculative Execution vulnerabilities, Spectre and Meltdown, Microsoft released updates for all supported systems. Microsoft made the decision to not enable these protections in Windows Server by default. It's up to you as the administrator to enable the protections.

Microsoft’s used the reg command to make the registry changes. This tool is great on a single machine, but it doesn’t scale. You need to use a configuration management tool like PowerShell DSC to make the changes at scale.

These changes could be made using the registry DSC resource, but I wanted a more simplified configuration using a custom DSC resource. I looked, and couldn’t find a resource, so I created cSpeculationControlFixes.

Managing the Protections

With the cSpeculationControlFix resource, administrators can enable or disable the protections. You'll need to restart the system for the changes to take effect, cSpeculationControlFix will notify the LCM if a reboot is required.

Configuration EnableSpeculationControl
{
    Import-DscResource -Module cSpeculationControlFixes
    cSpeculationControlFix enableSpeculationControlFix
    {
        Status = 'Enabled'
    }
}

Spectre Variant 2

Microsoft now provides a mechanism for enabling and disabling the Spectre Variant 2 protections separately from the other protections. With the cSpectreVariant2 resource, an administrator can enable or disable just the Spectre Variant 2 protections. For this resource to work, you need to have the updates described in this knowledge base article. Once again, cSpectreVariant2 will notify the LCM if a reboot is required.

Configuration EnableSpectreVariant2
{
    Import-DscResource -Module cSpeculationControlFixes
    cSpectreVariant2 enableSpectreVariant2Fix
    {
        Status = 'Enabled'
    }
}

Configuration DisableSpectreVariant2
{
    Import-DscResource -Module cSpeculationControlFixes
    cSpectreVariant2 enableSpectreVariant2Fix
    {
        Status = 'Disabled'
    }
}

Anti-Virus Compatibility Flag

A massive issue with these updates is that Windows Update won't offer to install these updates unless your anti-virus product as created the appropriate compatibility flag. This issue is, what about those computers, mainly servers, that don’t have an anti-virus product installed? The truth is, these update, nor any further security updates will be available.

To combat this, the cSpeculationControlAVCompatibility resource allows and administrator to enable this flag on systems that don’t have an anti-virus installed.

Configuration EnablecSpeculationControlAVCompatibility
{
    Import-DscResource -Module cSpeculationControlFixes

    cSpeculationControlAVCompatibility enablecSpeculationControlAVCompatibility
    {
        Status = 'Enabled'
    }
}

Getting the Module

The easiest way to get cSpeculationControlFixes is using the PowerShell Gallery, or from GitHub.

Installing the module from the gallery is as easy as:

PS> Install-Module -Name cSpeculationControlFixes

If you discover any issues, please report then via GitHub Issues.

Kieran Jacobsen