Articles from September 2017 on PowerShell.org - Welcome Automaters!

Call for topics closing 1 October

Sat, 30 Sep 2017 15:22:45 +0000

The call for topics is closing 1 October at 23:59 GMT. We’ve had a fantastic set of submissions. Creating an agenda for the 2018 Summit is going to be very difficult because we’ve had so many fantastic sessions submitted and I don’t have enough slots to take them all.

The call for topics is hosted by papercall.io – highly recommended – and the cut off is automatic.

I WILL NOT ACCEPT ANY SESSIONS SUBMITTED AFTER THE CUT OFF DATE.

Using Azure Desired State Configuration – Part II

Tue, 26 Sep 2017 14:00:21 +0000

Today we’re going to be talking about adding configurations to your Azure Automation Account. In this article, we’ll be discussing special considerations that we need to take into account when uploading our configurations. Then we’ll talk about compiling the configurations into Managed Object Format (.mof) files, which we’ll be able to use to assign to our systems.
Things to Consider
When building configurations for Azure DSC (or anything where we are pulling pre-created .mof files from), there are some things that we need to keep in mind.
Don’t embed PowerShell scripts in your configurations. - I spent a lot of time cleaning up my own configurations when learning Azure Automation DSC. When configurations are compiled, they’re done so on a virtual machine hidden under the covers and can cause some unexpected behaviours. Some of the issues that I ran into were:

Using environment variables like $env:COMPUTERNAME - This actually caused me a lot of headaches when I started building systems that were being joined to a domain. The name of the instance thatcompiles the .mof will be used for $env:COMPUTERNAME instead of the target computer name and you’ll be banging your head on the table wondering what happened. Some of the resources that have been published in the gallery have been updated to use a ’localhost’ option as a computer name input, such as xActiveDirectory. This takes care of a lot of those headaches.
Using Parenthetical Commands to establish values - Using something like Get-NetAdapter in a parenthetical argument to get a network adapter of your target system and pass the needed values on to your DSC Resource Providers won’t work for the same reasons as above. In this instance, I received a vague error indicating that I was passing an invalid property, and took a little bit of time before I understood what was going on.
I also ran into an issue with compiling a configuration because I had been using Set-Item to configure the WSMan maxEnvelopeSize in my configs because they can get really big. The error that I received was that WSMan wasn’t installed on the machine. It took me a bit to realize that this was because the machine compiling the .mof didn’t have WSMan running on the box and it was blowing up on the config.

Instead, if you need to run PowerShell scripts ahead of your deployment, you can use the custom script extension to perform those tasks in Azure, or just put the script into your image on-prem. There is one exception to this, and that’s what we’ll be talking about next.
Leverage Azure Automation Credential storage where possible - Passing credentials in as a parameter can cause all kinds of issues.

First and foremost, anyone that is building or deploying those configurations will know those credentials.
Second of all, it brings the possibility of someone tripping over the keyboard and entering a credential in improperly.

Allowing Azure Automation to tap the credential store during .mof compilation allows to credentials to stay in a secured bubble through the entire process. To pass a credential from Azure Automation to your config, you need to modify the configuration. Simply call Get-AutomationPSCredential to a variable inside your configuration, and then set that variable wherever those credentials are required. Like so:

$AdminCreds = Get-AutomationPSCredential -Name $AdminName Node ($AllNodes.Where{$_.Role -eq "WebServer"}).NodeName { JoinDomain DomainJoin { DependsOn = "[WindowsFeature]RemoveUI" DomainName = $DomainName Admincreds = $Admincreds RetryCount = 20 RetryIntervalSec = 60 } }Azure Automation under the covers will authenticate to the Credentials store with the RunAs account, and then pass those credentials as PSCredential to your DSC resource provider.
Stop Using localhost (or a specific computer name) as the Node Name - Azure Automation DSC allows you to use genericized, but meaningful names to configurations instead of just assigning things to localhost. So now you can use webServer, or domainController, or something that describes the role instead of a machine name. This makes it much easier to decide which configuration should go to what machine.

Upload The Configuration
So much like in my previous series on Azure Automation and OMS, we’re going to upload our DSC resources to our Automation Account’s modules directory. This requires getting the automation account, zipping up our local module files, sending them to a blob store, and importing those modules from the blob store. I’ve sectioned out the code into different regions to better break it down for your own purposes.

#region GetAutomationAccount $AutoResGrp = Get-AzureRmResourceGroup -Name 'mms-eus' $AutoAcct = Get-AzureRmAutomationAccount -ResourceGroupName $AutoResGrp.ResourceGroupName #endregion #region compress configurations Set-Location C:\Scripts\Presentations\AzureAutomationDSC\ResourcesToUpload $Modules = Get-ChildItem -Directory ForEach ($Mod in $Modules){ Compress-Archive -Path $Mod.PSPath -DestinationPath ((Get-Location).Path + '\' + $Mod.Name + '.zip') -Force } #endregion #region Access blob container $StorAcct = Get-AzureRmStorageAccount -ResourceGroupName $AutoAcct.ResourceGroupName Add-AzureAccount $AzureSubscription = ((Get-AzureSubscription).where({$PSItem.SubscriptionName -eq $Sub.Name})) Select-AzureSubscription -SubscriptionName $AzureSubscription.SubscriptionName -Current $StorKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $StorAcct.ResourceGroupName -Name $StorAcct.StorageAccountName).where({$PSItem.KeyName -eq 'key1'}) $StorContext = New-AzureStorageContext -StorageAccountName $StorAcct.StorageAccountName -StorageAccountKey $StorKey.Value $Container = Get-AzureStorageContainer -Name ('modules') -Context $StorContext #endregion #region upload zip files $ModulesToUpload = Get-ChildItem -Filter "*.zip" ForEach ($Mod in $ModulesToUpload){ $Blob = Set-AzureStorageBlobContent -Context $StorContext -Container $Container.Name -File $Mod.FullName -Force New-AzureRmAutomationModule -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName -Name ($Mod.Name).Replace('.zip','') -ContentLink $Blob.ICloudBlob.Uri.AbsoluteUri } #endregionOnce we’ve uploaded our files, we can monitor them to ensure that they’ve imported successfully via the UI, or by using the Get-AzureRmAutomationModule command.

PS C:\Scripts\Presentations\AzureAutomationDSC\ResourcesToUpload> Get-AzureRmAutomationModule -Name LWINConfigs -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountNa me ResourceGroupName : mms-eus AutomationAccountName : testautoaccteastus2 Name : LWINConfigs IsGlobal : False Version : 1.0.0.0 SizeInBytes : 5035 ActivityCount : 1 CreationTime : 9/13/2017 9:56:10 AM -04:00 LastModifiedTime : 9/13/2017 9:57:26 AM -04:00 ProvisioningState : SucceededCompile the Configuration
Once we’ve uploaded our modules, we can then upload and compile our configuration. For this, we’ll use the Import-AzureRmAutomationDscConfiguration command. But before we do, there’s two things to note when formatting a configuration for deployment to Azure Automation DSC.

The configuration name has to match the name of the configuration file. So if your configuration is called SqlServerConfig, your config file has to be called SqlServerConfig.ps1.
The sourcepath parameter errors out with an ‘invalid argument specified’ error if you use a string path. Instead, it works if you use (Get-Item).FullName

We’ll be casting this command to a variable, as we’ll be using it later on when we compile the configuration. You’ll also want to use the publish parameter to publish the configuration after importation, and if you’re overwriting a configuration you’ll want to leverage the force parameter.

$Config = Import-AzureRmAutomationDscConfiguration -SourcePath (Get-Item C:\Scripts\Presentations\AzureAutomationDSC\TestConfig.ps1).FullName -AutomationAccountName $AutoAcct.AutomationAccountName -ResourceGroupName $AutoAcct.ResourceGroupName -Description DemoConfiguration -Published -Force
Now that our configuration is published, we can compile it. So let’s add our parameters and configuration data:

$Parameters = @{ 'DomainName' = 'lwinerd.local' 'ResourceGroupName' = $AutoAcct.ResourceGroupName 'AutomationAccountName' = $AutoAcct.AutomationAccountName 'AdminName' = 'lwinadmin' } $ConfigData = @{ AllNodes = @( @{ NodeName = "*" PSDscAllowPlainTextPassword = $true }, @{ NodeName = "webServer" Role = "WebServer" } @{ NodeName = "domainController" Role = "domaincontroller" } ) }You’ll notice that I have PSDscAllowPlainTextPassword set to true for all of my nodes. This is to allow the PowerShell instance on the compilation node to compile the configuration with credentials being passed into it. This PowerShell instance isn’t aware that once the .mof is compiled, it is encrypted by Azure Automation before it’s stored in the Automation Account.
Now that we have our parameters and configuration data set, we can pass this to our Start-AzureRmAutomationDscCompilationJob command to kick off the .mof compilation.

$DSCComp = Start-AzureRmAutomationDscCompilationJob -AutomationAccountName $AutoAcct.AutomationAccountName -ConfigurationName $Config.Name -ConfigurationData $ConfigData -Parameters $Parameters -ResourceGroupName $AutoAcct.ResourceGroupNameAnd now we can use the Get-AzureRmAutomationDscCompilationJob command to check the status of the compilation, or check through the UI.

Get-AzureRmAutomationDscCompilationJob -Id $DSCComp.Id -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountNameThe compilation itself can take up to around five minutes, so grab yourself a cup of coffee. Once it returns as complete, we can get to registering our endpoints and delivering our configurations to them. Join us next week as we do just that!
]]>

Using Azure Desired State Configuration – Part I

Mon, 25 Sep 2017 14:00:45 +0000

I’ve been wanting to do this series for a while, and with some of the recent changes in Azure Automation DSC, I feel like we can now do a truly complete series. So let’s get started!
Compliance is hard as it is. And as companies start moving more workloads into the cloud, they struggle with compliance even more so. Many organizations are moving to Infrastructure-as-a-Service for a multitude of reasons (both good and bad). As these workloads become more numerous, IT departments are struggling with keeping up with auditing and management needs. Desired State Configuration, as we all know, can provide a path to not only configuring your environments as they deploy as new workloads, but can maintain compliancy, and give you rich reporting.
Yes. Rich reporting from Desired State Configuration, out of the box. You read it right. You can get rich graphical reporting out of Azure Automation Desired State Configuration out of the box. And you can even use it on-prem!

In this series, we’re going to be discussing the push and pull methods for Desired State Configuration in Azure. We’ll be going over some of the ‘gotchas’ that you have to keep in mind while deploying your configurations in the Azure environment. And we’ll be talking about how we can use hybrid workers to manage systems on-prem using the same tools.
Push vs. Pull
Desired State Configuration, like a datacenter implementation, can be handled via push or pull method. Push method in Azure does not give you reporting, but allows you to deploy your configurations to a new or existing environment. These configurations, and the modules necessary to perform the configuration, are stored in a private blob that you create, and then the Azure Desired State Configuration extension can be assigned that package. It is then downloaded to the target machine, decompressed, modules installed, and the configuration .mof file generated locally on the system.
Pull method fully uses the capabilities of the Azure Automation Account for storing modules, configurations, and .mof compilations to deploy to systems. The target DSC nodes are registered and monitored through the Azure Automation Account and reporting is generated and made available through the UI. This reporting can also be forwarded toOMS Log Analytics for dashboarding and alerting purposes (which, as we discussed inmy previous series, can be used with Azure Automation Runbooks for auto-remediation).
Pros and Cons to Each
So let’s talk about some of the upsides and downsides to each method. These may affect your decisions as you architect your DSC solution.

Pricing - Azure DSC is essentially free. Azure Automation DSC is free for Azure nodes, while there is a cost associated with managed on-prem nodes. This charged per month and is dependent on how often the machines are checking in. You can get more information on the particularshere.
Reporting - If you’re looking for rich reporting, Azure Automation DSC is definitely the way to go. You can still get statuses from your Azure DSC nodes via PowerShell, but this leaves the onus on you to format that data and make it look pretty. We’ll be taking a look at how we can do this a bit later.
Flexibility - Azure Automation DSC allows you to use modules stored in your Azure Automation Account. If you wish to use a new module, you simply add that module, update your configuration file, and recompile. With Azure DSC, you need to repackage your configuration with all of the modules, re-publish them, and re-push them to your target machines.
Side-by-Side Module Versioning Tolerance - Currently, Azure DSC actually has an advantage over Azure Automation DSC in this respect. You cannot currently have multiple module versions in your module repository. So if you’re using Automation DSC and calling the same DSC resources in multiple configs, they need to all be on that same module version.
On-Prem Management Capabilities - Azure Automation DSC has the ability to manage on-prem virtual machines, either directly or via Hybrid Workers. This gives you the ability to manage all of your virtual machines and monitor their configuration status from a single pane of glass. Azure DSC does not have this capability.
Managing Systems in AWS - Yes. You can also manage your virtual machines in AWS using the AWS DSC Toolkit via Azure Automation DSC!

So that’s the overview of what we’re going to be talking about through this series. Tomorrow, we’ll be getting into how to add configurations into Azure Automation DSC and compiling your configs.

]]>

The Future of PowerShell's Desired State Configuration

Wed, 13 Sep 2017 15:28:06 +0000

Microsoftrecently published a “Future of DSC” post that I thought deserved some independent commentary.

Something to bear in mind is that the existing, open-source “DSC for Linux” was not authored by the PowerShell team. It was written by Microsoft’s Unix Services team, and it doesn’t currently offer the exact functionality of the Windows implementation. So some of this announcement is the PowerShell team actually “taking on” DSC for other platforms.
This includes a new Local Configuration Manager (LCM) for PowerShell Core, which implies it’ll run anywhere PowerShell core does - Linux, macOS, and so on - as well as Windows, since PowerShell Core can run on Windows, too. It no longer requires the complex-to-install OMI stack, and it supports DSC resources written in PowerShell, Python scripts, and C/C++.
Now, it’s important to note that this is a pre-release announcement, and the plans may not survive engagement. That’s means the situation is still fluid, and it’s probably a bit early to start making plans. This is a situation tomonitor, notact upon, at this date.
This does mean that, if plans play out as they are now,everything about DSC today will probably change a lot. There will be new commands to replace things like Start-DscConfiguration. But some things won’t change: the Pull Server protocol, for example, will be supported by DSC Core (this is easy to do as the protocol isn’t complex and is all REST-based), so the existing Pull Server and Azure Automation DSC will still work.
The upside to all of this - and Microsoft’s intent, from what I can tell - is to converge on a single code base for DSC, and make all platforms “first class citizens.” Today’s DSC - what the team calls “DSC for Windows PowerShell” or “Windows Management Framework (WMF) version of DSC” - is at a dead-end. They’re not going to delete it, but they’re going to focus development on DSC Core.That has implications. It means that, in order to move forward, any custom resources you write and use need to use native C/C++, PowerShell 6 scripts, or commands that are supported under .NET Standard 2.0. WMI is right out, although it’ll be interesting to see if the team maintains that stance, or chooses to make WMI available on Windows but not on Linux (which would break the “same code running everywhere” philosophy they’re currently aimed at).
The native Pull server’s future appears to be unknown. I’m not sure that’s a bad thing; it’s presented nowadays as “sample code,” and it’s always been a problematic and minimally-useful chunk of code. I wish more people were looking atTug, which is an open-source Pull Server framework that you can code up (in PowerShell or .NET) to act however you want. It comes with a simple implementation that more or less mimics the native Pull Server, without the Jet database engine dependency (fun story: Jet/EBD was chosen because the team could get it working on Nano, and now Nano isn’t ever going to be used for that purpose as it’s been repositioned as a “container OS”). If more people invested in Tug, DSC would be a lot better off overall.
My thoughts?
Overall, “yay” for “same functionality on all platforms.” The potential need to rewrite a crapload of DSC resources, and possibly losing WMI (if I’m reading this right), is a big “boo,” and might push people away from an already-fragile relationship with DSC. “Boo” also to another re-do of DSC (v4 to v5 was not immaterial), making it feel like Microsoft didn’t really have a good long-term vision for the technology to begin with (and indeed, some of the architectural problems in v5, like how partial configurations work, further suggest a lack of vision). DSC Core may be a chance for Microsoft to re-think past approaches and fix mistakes, so “yay” if they do that along the way.
Predominantly, though, a big “boo” to a continued lack of tooling. I get that DSC is an “under the hood” technology latter, but like zero other teams at Microsoft have, at this point, helped pile any kind of tooling on top of it. It’s like we have the Chef engine or Puppet engine, but not of the tooling that makes those things truesolutions.
Taking off my Microsoft fanboy hat, I can see it being difficult for a CIO to take a strong dependency on DSC at this point. We’re aiming for its third iteration, whichwill break backward compatibility and, in some ways, reduce functionality. Microsoft still can’t produce a production-viable on-prem pull server, and doesn’t seem interested in doing so. We still don’t have any kind of management tooling (in part, I think, to the continued shitshow that is the System Center “strategy” these days), so DSC remains a highly do-it-yourself endeavor. Not every organization is going to be comfortable with that. I do think Tug - again, with some do-it-yourself investment - can make DSC vastly more intelligent and powerful (you can, for example, code it to assemble MOFs on-the-fly, extract configuration fragments from a database, or literally anything else you might want), but people in the Microsoft space are used to prepackaged solutions that just install and go.
I like the “write once, run anywhere” promise; that’s what .NET was supposed to be all about when Microsoft stepped away from Java back in the day. I get how DSC Core,for VMs running in Azure, may be a first-class citizen for dynamic, declarative configurations, and how that all leads nicely to a DevOps style footing. For on-prem, DSC is going to continue to be challenging for people who aren’t accustomed to a lot of DIY, and who are trying to take hard and long-lasting dependencies on a configuration technology.

]]>

PowerShell and DevOps Summit 2018 – session acceptance

Sat, 02 Sep 2017 11:21:32 +0000

We have started the acceptance process for the sessions to be presented at the 2018 Summit. Those currently accepted sessions are listed in the brochure
The deadline for submissions still remains as 2 October 2017
We’ll probably be formally accepting a number of other sessions during September BUT the bulk of the agenda won’t be finalised until after the deadline closes.
You still have plenty of time to get your submissions into the system. The earlier you do so the more time we have to help you refine the submission.