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

Putting it all out there

Thu, 26 Oct 2017 11:11:31 +0000

Yesterday I pushed my first real project to a public repository on GitHub. It’s small right now though I hope to flesh it out over time, and it is very niche, but I hope it helps others who come across it. Regardless I’m proud of it. If you like, you can check it out here, I’d love your feedback, but that’s not the reason I’m writing this.
I’m here to tell you why I did it.
You see, I’m a private kind of person. I don’t often put myself out there for fear of embarrassing myself. I have always been worried that I might end up looking silly. That someone who knows more than I do, or knows something differently than I do would catch me out - and if that happened, I couldn’t put the genie back in the bottle. Back in school, I wouldn’t put my hand up even if I knew the right answer, just in case. I was ensnared by Impostor Syndrome, it was crippling, and it had to change.
So, what did I do? I started a blog, and in almost a year I’ve managed to get around 10-12 posts up. It isn’t much nor is it pretty, and sometimes I worry too much about the time in between posts, and rush to put something up which is not always perfect. But I’m happy to be doing it all the same. Mostly, I try to post about topics and problems that I haven’t been able to find complete information around elsewhere.
I’ve started spending more time sharing and interacting on Twitter and LinkedIn, rather than just reading and clicking links. I’ve even been followed and liked a few times. Lastly, I’ve been spending more time on these forums and elsewhere, helping out where I can.
Overall, I feel better in myself, and have a greater level of confidence in my skills, knowledge, and what I can bring to the table. In the end, that is what led me to feeling good enough to publish my project. I can’t say that I’m completely over Impostor Syndrome and I don’t think I ever will be. I can say that I don’t feel it as often as I used to, and I can use it to drive myself to be better.
When we are presented with a problem, we often go looking for answers from others. Flip that around and it means that if you have solved a problem, there is probably someone else looking for the answer and would really appreciate your experience. So why not put it out there?

PowerShell + DevOps Summit 2018 schedule

Tue, 24 Oct 2017 20:15:26 +0000

The schedule for the 2018 Summit still needs a little bit of polishing to finish it but it’s taking shape. I’ve started releasing information on sched.com that we’re using for all our scheduling needs for the Summit. The one and only truth regarding the sessions and their times can be found at https://powershelldevopsglobalsummit2018.sched.com/
I’ll be adding sessions over the next few days so keep checking.
I’m really excited about the schedule for the 2018 Summit. We’ll have 4 rooms for sessions with many of your favourite speakers returning and many new speakers which is really good to see. The Community Lightning Demos return by popular acclaim and we’ll be running an Iron Scripter competition as well. The PowerShell Team will be presenting all day Monday and at other sessions through out the Summit.
Registration opens 1 November and once you’re registered through eventbrite your information will be sync’d to sched.com so that you can access the schedule and use the scheduling app.

Using Azure Desired State Configuration – Part IV

Tue, 10 Oct 2017 14:00:07 +0000

So we’ve talked about Azure Automation DSC and the extensive reporting we can get from it. With the pricing as it is, it would be hard to argue as to why you would want to use anything else. But I’m a completionist, and there may be some edge cases that might come up where you wouldn’t be able to use the pull method for configurations. So let’s talk about how you can use Azure DSC to push a configuration to a virtual machine.
So let’s get started!
Publish the Configuration
In order to push a configuration, we need to publish it to a blob store. When you use Publish-AzureRmVmDscConfiguration, the command bundles all of the required modules along with the configuration into a .zip file. It does this by pulling the modules from your local machine that you’re running the command from, so you’ll need to make sure that you have the appropriate modules installed on your system.
First, we’ll go ahead and grab a storage account where these binaries can be published. In the storage account, we have a blob store for our configurations. This blob store is a private store.

$AutoResGrp = Get-AzureRmResourceGroup -Name 'mms-eus' $StorAcct = Get-AzureRmStorageAccount -ResourceGroupName $AutoResGrp.ResourceGroupName -Name 'modulestor'Now that we have our private store, we’re going to publish our configuration using the Publish-AzureRmVMDscConfiguration command.

$DSCBlob = Publish-AzureRmVMDscConfiguration -ConfigurationPath C:\Scripts\Configs\cmdpconfig.ps1 -ResourceGroupName $StorAcct.ResourceGroupName -ContainerName 'dscpushconfig' -StorageAccountName $StorAcct.StorageAccountName -Force $Archive = $DSCBlob.Split('/') | Select-Object -Last 1As previously mentioned, the command reads your configuration, and then grabs the necessary modules from your local machine and adds them to the package when it publishes the configuration. This way, the machine has all of the necessary bits to perform the configuration. You can actually validate this by downloading the packaged .zip file from the blob store and seeing for yourself.
Along with the modules and configuration, you’ll also find a dscmetadata.json file that is essentially a manifest of the required modules.

Install the VM Extension
Now that our binaries have been published, we can get our target machine and deploy the Azure DSC VM extension to it while assigning the configuration. When you deploy the extension, it’s best to use the latest version available. If you want to check which version is the latest, you can check out the release history on thePowerShell Team Blog.

$ArmVmRsg = Get-AzureRmResourceGroup -Name 'nrdtste' $ArmVm = Get-Azurermvm -ResourceGroupName $ArmVmRsg.ResourceGroupName -Name 'ctrxeusdbnp01' Set-AzureRmVMDscExtension -ArchiveResourceGroupName $StorAcct.ResourceGroupName -ArchiveBlobName $Archive -ResourceGroupName $ArmVm.ResourceGroupName -ArchiveStorageAccountName $StorAcct.StorageAccountName -ArchiveContainerName 'dscpushconfig' -Version '2.26' -VMName $ArmVm.Name -ConfigurationName 'CMDPConfig' -VerboseLike with Azure Automation DSC, when you register the VM extension, your PowerShell session will be held open until the extension returns a success or failure status. Once it returns, you can check the status of the configuration using Get-AzureRmVmDscExtensionStatus.

PS C:\Users\willa> Get-AzureRmVMDscExtensionStatus -ResourceGroupName $ArmVm.ResourceGroupName -VMName $ArmVm.Name ResourceGroupName : nrdtst3 VmName : ctrxeusdbnp01 Version : 2.26 Status : Provisioning succeeded StatusCode : ProvisioningState/succeeded Timestamp : 10/9/2017 1:12:22 PM StatusMessage : DSC configuration was applied successfully. DscConfigurationLog : {[2017-10-09 13:11:18Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] The operation 'Get-WindowsFeature' succeeded: Server-Gui-Shell, [2017-10-09 13:11:18Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ End Test ] [[WindowsFeature]RemoveUI] in 9.5980 seconds., [2017-10-09 13:11:18Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ Start Set ] [[WindowsFeature]RemoveUI], [2017-10-09 13:11:19Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] Uninstallation started......}If you want to dive a little deeper, we can of course grab the specific DscConfigurationLog information:

PS C:\Users\willa> (Get-AzureRmVMDscExtensionStatus -ResourceGroupName $ArmVm.ResourceGroupName -VMName $Armvm.Name).DscConfigurationLog [2017-10-09 13:11:18Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] The operation 'Get-WindowsFeature' succeeded: Server-Gui-Shell [2017-10-09 13:11:18Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ End Test ] [[WindowsFeature]RemoveUI] in 9.5980 seconds. [2017-10-09 13:11:18Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ Start Set ] [[WindowsFeature]RemoveUI] [2017-10-09 13:11:19Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] Uninstallation started... [2017-10-09 13:11:19Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] Continue with removal? [2017-10-09 13:11:19Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] Prerequisite processing started... [2017-10-09 13:11:24Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] Prerequisite processing succeeded. [2017-10-09 13:12:21Z] [WARNING] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] You must restart this server to finish the removal process. [2017-10-09 13:12:21Z] Settings handler status to 'transitioning' (C:\Packages\Plugins\Microsoft.Powershell.DSC\2.26.1.0\Status\0.status) [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] Uninstallation succeeded. [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] Successfully uninstalled the feature Server-Gui-Shell. [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: [[WindowsFeature]RemoveUI] The Target machine needs to be restarted. [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ End Set ] [[WindowsFeature]RemoveUI] in 62.7090 seconds. [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ End Resource ] [[WindowsFeature]RemoveUI] [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: [] A reboot is required to progress further. Please reboot the system. [2017-10-09 13:12:21Z] [WARNING] [ctrxeusdbnp01]: [] A reboot is required to progress further. Please reboot the system. [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ End Set ] [2017-10-09 13:12:21Z] [VERBOSE] [ctrxeusdbnp01]: LCM: [ End Set ] in 74.8080 seconds. [2017-10-09 13:12:21Z] [VERBOSE] Operation 'Invoke CimMethod' complete. [2017-10-09 13:12:21Z] [VERBOSE] Time taken for configuration job to complete is 75.071 secondsAs you can see, the configuration is complete pending a reboot. This brings us to a few of the caveats associated with the push method for Azure DSC.

Unfortunately, unlike with the Register-AzurRmAutomationDscNodeConfiguration command available for Azure Automation, you cannot currently configure the LCM direct from the command. Instead, you’ll want to add a LocalConfigurationManager block to your top level config to set any attributes for the LCM.
As the system is downloading the packaged modules and configuration files, the mof file is configured locally on the machine. While the current.mof file is encrypted, there is a copy of the mof that is generated in the C:\Packages\Plugins\Microsoft.Powershell.DSC
\ directory. You’ll want to be careful as to what you’re passing in plain text in that regard.
You can retrieve the DscConfigurationLog data for validation of your configs and the state of the machines, but this process requires automation and can take some time to compile.

So now we’ve explore Azure Desired State Configuration using the available push and pull methods. And we’ve explored the rich reporting capabilities that are available to you in Azure Automation DSC. It’s been a long journey, but I hope you’ve found this content to be useful to you!
Until next time!

]]>

Using Azure Desired State Configuration – Part III

Tue, 03 Oct 2017 14:00:59 +0000

Last week we talked about modifying and uploading our configurations to Azure Automation DSC. We were able to import credentials from Azure’s Automation Account Credential store, and then compile the .mof files in the automation account for deployment. This week, we’ll be looking at how we apply those configurations to existing systems via PowerShell. Then we’ll take a look at some of the reporting available via Azure Automation DSC and send those reports over to Operations Management Suite for dashboarding.
So when we left off. We successfully published our configurations in Automation DSC. If we run Get-AzureRmAutomationDscNodeConfiguration against the configuration I published, we get the following:

Get-AzureRmAutomationDscNodeConfiguration -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName -ConfigurationName TestConfig
As you can see, when we published the configuration, it generated two configuration .mofs based on our node names - domainController and webServer. Now of course, we’re not going to be calling our servers webServer and domainController, rather, these are generalized names for our configurations. We get the root configuration (TestConfig), and then the node specific configuration based on the root document (webServer or domainController). This gives us a lot of flexibility as we can now statefully name our configurations, and assign them to machines without dealing with guids or having all of the mofs defined by a computer name or any other nonsense! We just assign what named configuration goes to what system, and away we go.
We don’t even really care what the computer name is, as long as the correct config gets assigned. This is really helpful when working on Azure Resource Manager templates, because I don’t even really know what the system name will be until runtime. I just designate a set of systems as ‘webServer’, assign the config and deploy.
Moo.
Register the Virtual Machine
So let’s go ahead and get a system that we want to target. I just so happen to have one in Azure right here:

$TargetResGroup = 'nrdtste' $VMName = 'ctrxeusdbnp01' $VM = Get-AzureRmVM -ResourceGroupName $TargetResGroup -Name $VMNameNow that we have our VM object, we’re going to create a hash-table with some configuration items for the DSC Local Configuration Manager on the target system.

$DSCLCMConfig = @{ 'ConfigurationMode' = 'ApplyAndAutocorrect' 'RebootNodeIfNeeded' = $true 'ActionAfterReboot' = 'ContinueConfiguration' }Once we have all of this, we can now go ahead and register our target node in Automation DSC using the Register-AzureRmAutomationDscNode command.

Register-AzureRmAutomationDscNode -AzureVMName $VM.Name -AzureVMResourceGroup $VM.ResourceGroupName -AzureVMLocation $VM.Location -AutomationAccountName $AutoAcct.AutomationAccountName -ResourceGroupName $AutoAcct.ResourceGroupName @DSCLCMConfigYou might note with this command that you can also assign it a configuration as you register the node. However, I’ve had occasional issues with this method. So we’re going to go ahead and register the node first, then assign the configuration. As another note, while the system is being registered, the command will hold your session until it returns a success or failure. So grab another cup of coffee and enjoy it for a few minutes while we wait.

Apply a Configuration
Now we can see our machine has registered successfully. But if we run the Get-AzureRmAutomationDscNode command, we can see that the NodeConfigurationName property is empty. So let’s fix that.

What we need to do is capture the configuration we want to apply, so we do this by grabbing it with Get-AzureRmAutomationDscNodeConfiguration. Then, we’ll capture the target DSC endpoint with the Get command we previously used, and cast both objects to our Set-AzureRmAutomationDscNode command to apply the configuration to the appropriate node.

$Configuration = Get-AzureRmAutomationDscNodeConfiguration -AutomationAccountName $AutoAcct.AutomationAccountName -ResourceGroupName $AutoAcct.ResourceGroupName -Name 'CompositeConfig.webServer' $TargetNode = Get-AzureRmAutomationDscNode -Name $VM.Name -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName Set-AzureRmAutomationDscNode -Id $TargetNode.Id -NodeConfigurationName $Configuration.Name -AutomationAccountName $AutoAcct.AutomationAccountName -ResourceGroupName $AutoAcct.ResourceGroupName -Verbose -ForceAfter a couple of seconds, we can see that the configuration has been assigned to our node. Once the LCM hits it’s next review cycle, it’ll pick up the configuration and start applying:

We can check on the status of our target node by using the Get-AzureRmAutomationDscNodeReport command like so to get some useful information:

Get-AzureRmAutomationDscNodeReport -NodeId $TargetNode.Id -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName -LatestAnd it will output some pretty useful information.

Azure Automation DSC Reports
This is where I have to admit that the UI really shines. You can see all of your systems at a glance, with what configuration is assigned and it’s current state.

Furthermore, you can actually drill down through the nodes to see what resources are being applied, what their dependencies are, and what the state of the particular configuration item is.

There is a wealth of data that you can find here in an easy to read dashboard. Furthermore, you can connect this to a Log Analytics instance (or other products that support restful API), and ship it up for alerting and more dashboarding.
Connecting to Log Analytics
So connecting your Azure Automation DSC is pretty straightforward. To be able to use it, you need to have an OMS tier that includes the Automation and Control offering to start. If you do, then all you have to do is follow a couple of simple commands.
First, we have to get the resourceIds for the Automation Account and the Log Analytics workspace.

#Get the resourceId of the automation account. $AutoAcctResource = Find-AzureRmResource -ResourceType "Microsoft.Automation/automationAccounts" -ResourceNameContains 'testautoaccteastus2' #Get the resourceId of the Log Analytics Workspace $LogAnalyticsResource = Find-AzureRmResource -ResourceType "Microsoft.OperationalInsights/workspaces" -ResourceNameContains 'LWINerd'Then we can use those resourceIds to pass to Set-AzureRmDiagnosticSetting and specify our DSCNodeStatus category.

Set-AzureRmDiagnosticSetting -ResourceId $AutoAcctResource.ResourceId -WorkspaceId $LogAnalyticsResource.ResourceId -Enabled $true -Categories "DscNodeStatus" -VerboseThen you’ll get a return similar to this:

PS C:\Scripts\Presentations\AzureAutomationDSC\ResourcesToUpload> Set-AzureRmDiagnosticSetting -ResourceId $AutoAcctResource.ResourceId -WorkspaceId $LogAnalyticsResource.ResourceId -Enabled $true -Categories "D scNodeStatus" -Verbose StorageAccountId : ServiceBusRuleId : EventHubAuthorizationRuleId : Metrics TimeGrain : PT1M Enabled : False RetentionPolicy Enabled : False Days : 0 Logs Category : JobLogs Enabled : False RetentionPolicy Enabled : False Days : 0 Category : JobStreams Enabled : False RetentionPolicy Enabled : False Days : 0 Category : DscNodeStatus Enabled : True RetentionPolicy Enabled : False Days : 0 WorkspaceId : /subscriptions/f2007bbf-f802-4a47-9336-cf7c6b89b378/resourceGroups/mms-eus/providers/Microsoft.OperationalInsights/workspaces/LWINerd Id : /subscriptions/f2007bbf-f802-4a47-9336-cf7c6b89b378/resourcegroups/mms-eus/providers/microsoft.automation/automationaccounts/testautoaccteastus2/providers/microsoft.insights/diagnosticSettings/service Name : service Type : Location : Tags :After a little while, we can check back to our log search and start performing queries and configuring alerts.

So that’s Azure Automation DSC in a nutshell! But don’t worry, I haven’t forgotten about Azure DSC’s push method. We’ll be talking about that next blog!

]]>