Last week at the PowerShell + DevOps Global Summit, we announced the dates for next year’s summit. The event will again be held at the Meydenbauer Center in Bellevue, Washington on April 27th to April 30th.
DevOps + Automation Summit - Nashville
We are also proud to announce that our flagship summit event would be getting a new addition to the family in the form of the DevOps + Automation Summit being held on October 21st to October 23rd, 2020 at the Renaissance Hotel in Downtown Nashville!
Today we’re opening nominations for the 2019 PowerShell Community Heroes! We want to know about those in the community that are doing a wealth of good. Have they written a fantastic script, or posted a blog series that has been exceptionally helpful? Are they doing a mad amount of pull requests in a module or in PowerShell Core? Here is your opportunity to make sure they get the recognition they deserve!
Tickets for the 2019 PowerShell + DevOps Summit sold out faster this year than its predecessors by almost exactly a full month. We are all so very excited to see everyone this year at the Meydenbauer in Bellevue, Washington! But as we continue to outpace each year, we also understand that this means that the demand for the content we deliver at Summit is also growing .
One of the early goals of the Summit was to keep the event relatively small to provide a more intimate feel. In doing so, it allows attendees a chance to see familiar faces as they come back every year, and have a chance to interact with the speakers, staff, and members of the PowerShell team. As the event has grown, we’ve been very careful to not lose that feel. So the question then is, what do we do in order to meet the demands of the community, and maintain that small event feel?
The PowerShell and DevOps Global Summit 2019 will be returning to the Meydenbauer Center in Bellevue, WA from Monday, April 29 to Thursday, May 2, 2019.
Since 2013, PowerShell and DevOps experts from around the world , will once again collaborate and learn how to maximize PowerShell in the workplace through fast-paced, knowledge-packed presentations. The Global Summit is the place for innovators to explore and further their knowledge of DevOps principles and practices in a Windows environment, make new connections, learn new techniques, and offer something to your peers and colleagues back at the office.
Ready to share your PowerShell or DevOps know-how? This is your official call to submit presentation ideas for selection!
What we are looking for?
The majority of our sessions will now follow a traditional 45-minute format. These sessions cover a wide variety of PowerShell and DevOps expertise. We have a number of agenda slots available for double length sessions. These sessions delve into the depths of a topic covering areas that need more than 45 minutes.
Your proposed session should fit into one of the following areas:
by Lawrence Hwang on July 15th, 2018 In Windows PowerShell, there’s a limitation with Invoke-WebRequest and sites that only use TLS 1.2. This article covers a workaround for this problem. This issue is not present with Invoke-WebRequest in PowerShell Core.
This week we’re starting a new series of blog posts called (obviously) ‘What You Missed This Week in PowerShell!’. Our team of volunteers is scouring the web to find interesting articles, and forum posts related to our favourite topic! In the meantime, I want to give a ’thank you’ to everyone that pulled together to make this possible. Many thanks to Greg Tate, Evgeny Fedorov, Patrick Singletary, Brett Bunker, Mark Roloff, and Robin Dadswell for your hard work on getting this started! -Will
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.
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:
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:
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 to OMS Log Analytics for dashboarding and alerting purposes (which, as we discussed in my 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.
