Home / IT & Computer Science / AWS / Microsoft Future Ready: DevOps Development, Implementation and Azure Automation / Implementing Automation DSC
Implementing Automation DSC
.
Hello, and welcome back to this video on managing Azure [INAUDIBLE] with Azure Automation DSC. Well, that’s a lot of Azure in there. We talked a lot about DSC. But let’s just cut to the chase and get into some demos on how we can leverage Azure Automation to manage the nodes, i.e., the VMs that we’re hosting within Azure. And in this demo, we’ll briefly cover a couple of things. We will walk through the DSC capabilities of [INAUDIBLE] within Azure Automation. We will look at the process for registering Azure VMs, i.e., the [INAUDIBLE] instances we have into DSC, which makes them DSC nodes. We’ll talk about adding a DSC configuration.
And that is pretty impressive how you can pretty much compile your PowerShell right within Azure Automation. We’ll also cover then actual rollout of DSC scripts and see how it works and maybe cover a few topics here and there around that as well. So I will cut out to Azure portal and start walking you through the demo. So I’m back in the Azure portal. I’m looking at the account that I created, the Azure Automation account I created in the last module. And while we covered a lot of stuff here, we didn’t really go into what– this section here, the DSC configuration and the DSC nodes. So let’s first start off by going into DSC configurations. Now, this is pretty empty here.
What it’s telling me is I am yet to create a DSC configuration file. DSC configuration, as we have discussed, is really a script that will tell the DSC pull server the target state that the nodes need to arrive at. Now, if you’re coming from the good old PowerShell background, you’re probably using the PowerShell integrated shell to do your programming. Visual Studio Code, an open-source platform, an open-source text editor that was announced at Connect a couple of years back, has gained a lot of traction in the community. It is the number one repository on GitHub and one of the most popular and most contributed to.
And if you haven’t tried Visual Studio Code, I will absolutely encourage you to download it and use it. The benefit with using Visual Studio Code is that it’s got extensions for PowerShell. So you could natively debug your PowerShell, right from within Visual Studio Code. And it integrates with Visual Studio Team Services and [INAUDIBLE] so you get all the benefits of version control, CICD, and all that good stuff. As you download Visual Studio Code, don’t forget to browse to the marketplace, which is packed with extensions. So whether you are creating SQL scripts, or JSON scripts, or Python, or Ruby, or some of the frameworks I don’t even know the names of, you will find an extension for them.
And if you don’t, well, create one and submit it to the marketplace– open-source, right? So let’s look for PowerShell here. And you see, there is the power. It’s got almost half a million downloads. That’s traction for you. So let’s open up Visual Studio Code. And what I’m going to do is I’m going to drop a script that I have already. And this script basically revisions or has the configuration to provision a basic web server. And we can quickly walk through it. Following best practises, I’m passing the name of the machine rather than hard coding the computer name. And here’s a brief list of all the Windows features it enables.
Now, it’s enabling WebServer, WebAppDev, WebAspNet, Web App Extension, Asp, ISAPIFilters, and that list goes on. This is a straightforward script that you can Bing or Google and find on the internet as well. Or just pick one up from the open-source gallery. So this is a basic script for setting up a web server DSC configuration. What I’m going to do is I’m going to navigate back into the Azure portal, click Add Configuration, and at this point, I’m going to upload this DSC configuration file. Now, bear in mind that you can only upload one MB worth of files in here. So if you’re creating a DSC script, which is bigger than that, then it’s not going to work.
All right, so let’s add the web server ps1. Luckily, ours is less than a few KB, so it shouldn’t be a problem. Click OK, and at this point, the script gets imported into Azure Automation. If I click on the script here, you see a few functions at the top there. I, of course, have the ability to delete it, but I have the ability to compile and export it. So with compile, what it would do is it will compile the configuration file and produce the morph and resource files for it.
If you host your own DSC server, this exercise needs to be performed by yourself. Just to give you a feel for complexity, if you’re in an enterprise environment, where your pull server is in a trust domain, and you’re authoring an infrastructure, and it is in a separate trust domain, then you would have to create certificates to even broker the conversation between the two. This just abstracts that right off, away from you. So you don’t have to worry about doing that. It simply just takes the script from you, and then it gives you an ability to compile it and create the morph and resource files for it. So I’ll just click Compile, and it’s asking me to insert the computer name.
I’m just going to select developer. And the purpose here is that the DSC configuration file– I’m going to roll out to developer specific nodes only. Now, while this is compiling in the background, what I’m going to do is I’m going to go off and create a new VM within Azure. And the purpose here is that this is a vanilla Windows 2012– or Windows 2016 image, it doesn’t have web server role on it. And the whole purpose of the demo is we’ll then roll out this configuration on the target machine. So I’m going to move into the next tab. And in Azure DevTest Labs, I’m going to click Add.
To add a new machine, I’m going to browse to the marketplace of existing images. And, hopefully, search for Windows Server 2016. Scroll down. Select Windows Server 2016. Let’s call it IacDemo, IacDemoDSC01–
put my username, create a password, and just leave the rest of the stuff as is and click Create. Now, while this is working away in the background provisioning the machine, let’s come back to the configuration blade. And we can see that my request to compile has been queued. If I click on it, it’s just basically working away, creating an isolated environment to compile the script, create the morph file. And the benefit here is that you cannot only see the inputs that the script expects, but at the same time, you can even see the script listed here. So even if you come back to it, it’s just preserving the script for you.
And you can, of course, extract it or export it later, if you want to. So this is going to take a few seconds to complete the compilation process.
While this is running here, I’m going to flip to the other tab. And as you can see, the machine creation is in process as well. It’s in creation mode. Again, it takes about eight to 10 minutes for a VM-provisioning process to complete within DevTest Labs. So we’ll give it some time. I’m just going to go back and see the progress on the compile activity here.
Excellent, so the activity is completed. You see the green tick there, always a good sign. All right, let’s close this blade and step out from here. Click on BasicWebServer. And as I come in here, and I click on the completed activity, there’s more information available. So you can see that the compilation engine has identified two potential problems with my script. I haven’t really declared the import for a module that my script depends on. I’m skipping that because that module is already available in Azure Automation. But see, the benefit is because it’s compiling it centrally. It keeps track of all the warnings and error messages in one place as well.
So now that the compilation has completed, let’s quickly check the status of the machine provisioning. It looks like the machine provisioning is almost complete as well. The best way to validate that is to try and log on to the machine. So click Connect.
All right, seems like the machine provisioning process has completed. It gives me an option to enter my password. And the password is– I’m not telling you. I’m just waiting for it to complete the login process here, securing the connection, configuring remote session, and we’re within the virtual machine. Now, once this loads, the only thing I want to highlight here is that– actually a couple of things I want to highlight here is one, that this machine does not have IIS set up. It doesn’t have the web role enabled. And the second thing I want to show you is the Local Configuration Manager settings, before we associate this machine with the Azure Automation DSC pull server.
All right, we’re in the machine now. The first thing I’m going to do is bring up the run prompt and type inetmgr.
And clearly, if IIS is set up on this server, then– try again, inetmgr. If IIS was set up on this server, then instead of erroring out here, it would just launch IIS for me. And as you can see from the Server Manager as well, it doesn’t show up the web role here. It’s just kind of clear that web role isn’t set up. So let’s launch PowerShell now and see what the LCM, Local Configuration Manager settings, looks like.
A question that I get asked quite a bit is, when should you use the PowerShell console versus PowerShell ISE. Well, clearly, if you are trying to create a script, then PowerShell ISE is the way to do it. If you are just running a one off command, then PowerShell console is probably a better option to do it. All right, so the script that I’m going to run here is get a Local Configuration Manager. And what it’s going to do is it’s effectively just going to query the state of the Local Configuration Manager. Now, as you can see, the Configuration Manager is set up as PUSH, which means it’s really not connected to a pull server.
If you wanted to push a configuration to it, it will accept it. But by itself, it’s not going to go looking for a pull server and then try and download the configuration from there. The other thing is it’s not set up to reboot if the configuration needs it to reboot. At certain times when you’re deploying Windows features, you kind of need the server to reboot as part of that process. So clearly, it will fail in that scenario. Having established that the LCM is not configured, it’s only configured for PUSH and that there is no IIS role, I’m going to move out from within the machine and go back to Azure Automation.
And now, we work our way through integrating this node and registering it to the central DSC Server. So let’s close this blade and go into the DSC node section. So effectively, I get a few options here. I can add an Azure VM, or I could add an on-prem VM as well. All right, so let’s click on add Azure VM. And you will see this option, where you can select to onboard virtual machines that are already available in your Azure subscription. Click on that. And there we go. We can see the VM that we created, IacDemoDSC01. Click OK. And then, in this next section here, it’s asking for some data.
Now, it’s saying what is the configuration that you want to apply to this node. Do not leave this empty. But you can, of course, if you want to. But this is basically asking for the configuration that needs to go on this node. If you miss out on specifying it now, your node will get registered to the pull server, but it won’t have a DSC configuration that needs to be applied to it. Just remember to select this. So, in this case, we have the BasicWebServer developer. Let’s select this. The Refresh Frequency and Configuration Mode Frequency we’ll leave to the default because that’s the lowest available frequency and the Refresh rates.
And we’ll change the configuration mode from apply and monitor to apply and auto correct. What that means is if a new configuration is available, it will take that new configuration and auto correct itself. We will also select the options to allow module override and reboot if necessary. So the reboot if necessary is kind of important if you are deploying a Windows feature that requires the server to reboot. Then, DSC will remember to tell the LCM to pick up the configuration from where it left it after the reboot. And then, in the last option here, you have Action after Reboot– Continue Configuration or Stop Configuration. We’ll stick with Continue Configuration. It reduces the manual intervention.
We’ll just validate what you have selected. We selected one node, and the registration data has been specified. Let’s click Create. It usually takes a couple of seconds or up to a minute to register the node. Now, what would happen in the background at this point is that the Azure VM, which we requested to be connected to the DSC pull server, will now get an extension deployed to it, the DSC extension. So if I go into the tab of the tab where I created the virtual machine, and I click on the resource group, and I click on the virtual machine itself, and then I scroll down to the extension option here.
You would see that the Microsoft.PowerShell.DSC extension is now being installed on the virtual machine. It usually takes a couple of minutes for the installation to complete, but what’s happening is the DSC server in Azure automation and all the nodes communicate using this extension. The benefit, of course, is it takes away and abstracts the complexities of creating certificates to broker that conversation. Because it’s a service deployed on the target host, the communication is a lot simpler. So we’ll just wait for a couple of minutes for the extension installation to complete.
Excellent. The status has changed to provisioning succeeded. Now, if you wanted to find out what was happening behind the scenes, you can click on it and then click on View Detailed Steps, which will give you a drill down of everything that went in the background to make that integration happen. And it’s kind of useful when things don’t work as expected. You have a way of going in and looking at the raw logs. What I’ve seen in the past, though, is when you associate a node with DSC, and you unregister it, sometimes this extension does not get uninstalled. And if you re-register the same node, and if the extension hasn’t been uninstalled, it runs into certain issues.
So the best way forward in those scenarios is to uninstall this extension or delete it and then retry that process. All right, so if we go back into the virtual machine and rerun the command, we will see that a few values have been updated in the LCM. The Refresh Mode has changed from PUSH to Pull. Clearly meaning it’s associated to a pull server. Reboot node if needed is set to true. Apply and Auto correct– so all of that is now configured in the Local Configuration Manager. If I go back into the DSC pull server in Azure Automation, you would see that the node status is in progress.
What that means is while the node has been registered with the DSC pull server, the configuration that I had specified, which was BasicWebServer.developer, is still in the process of being applied to this node. And to find out more details, I can click on this node. And you can see that it’s still in the process of doing the consistency checks. If I click on the consistency checks, I can, of course, find out more details. It’s still in progress. It takes a couple of minutes for this script to enable the Windows features that it needs enabled on the target node.
As you can see, it’s still showing up in the in progress status here. Let’s just go back into the virtual machine and see what’s going on in there. So I can run the command, Get DscConfigurationsStatus.
And what that would basically do in the background is, it will get the DSC configuration. That’s the state of the DSC configuration that’s running in the background. As you can see, the error message that shows up here is the consistency checks or is in progress and must return before get DSC configuration can be invoked. So this is also telling you that it will not report the updated status up and until the current job that’s running on the server is completed. But as you can see in the background in the Server Manager, the IIS role is starting to show up in the Server Manager, which means the DSC configuration that we applied to this node is in full flight.
It’s being applied to this node. So it should complete in the next minute or two.
Virtual high five, the status is complying now, which means that the DSC configuration execution on this node is completed. Now, if I scroll down on the details played here, I can click on Resources to exactly find out what was happening behind the scenes. I can see that each of the roles that I had requested through the configuration file are now successfully deployed in the node. And I can also see how much time was spent in deploying each of the nodes. Now, next time this DSC script runs, it’s going to be far more quicker because all the roles were already present on the node. So effectively, it wouldn’t have to deploy anything.
So if we go back into the node now and rerun the same command, which was Get DscConfigurationsStatus, then it just says that status success. This is when it synched the mode, reboot requested. It just tells you what the result of the last configuration that was deployed. And at this point, if you browse to inetmgr–
there should be applause, right? You have deployed a web role without actually writing a single line of script. In theory, you have a script. But rather than writing a script that had imperative steps to– how to achieve the deployment, in this case, you just called out the features you needed and OS, as well as PowerShell DSC figured it out for you. At this point, if I launch a browser, and I type in localhost, I see IIS launching up there as well. So there’s really no end to what you can achieve with DSC. Just to give you a taste for what configurations possibly you can push through DSC, I’m going to run this small command, which is called Get WindowsFeatures.
It gives you a list of all the Windows features that the OS has available, as well as the status of whether they have already been enabled or deployed on your version of the OS. If I run this command, you can see it gives me a full list of all the features that I could, in theory, be pushing out through DSC script, for example, BitLocker, Windows Deployment Services, .NET Framework 3.5. The cross signifies that it’s already been installed, and where it says available is something I can push through a DSC script.
So coming out from here, in this demo here we looked at how easy it is to really take a DSC configuration, set it up in Azure Automation, have Azure Automation compile that DSC configuration for you, generate the morph files and the resources. How conveniently can you take any of the existing IIS VMs that you have within Azure, associate them within DSC pull server, and select the configurations that you need pushed out. And the configurations, in a matter of minutes, set up the Windows features or any other configuration you want to push out to the nodes. I hope you found this useful.
In the previous steps, you gained a basic understanding of DSC and how Automation DSC works. This step will demonstrate how to configure, implement and manage Azure IaaS with Automation DSC.
The DSC Configuration File
DSC configurations are Windows PowerShell scripts that define a special type of function.
Review this example of a simple configuration:
NOTE:
You can create the configuration in any editor, such as the PowerShell ISE. Save the file as a PowerShell script with a ps1 file type.
Import and Compile
After creating your DSC configuration file, you must import the file and compile it to the DSC pull server. Compiling will create the MOF file:
NOTE: If you prefer, you can use the PowerShell Start-AzureRmAutomationDscCompilationJob to compile the configuration file. There are two options to compile your Desired State Configuration (DSC) configurations: With Azure Automation in the Azure portal, or with Windows PowerShell.
Registering DSC Nodes
After your configuration is in place, you will select the Azure virtual machines or on-premises virtual machines that you would like to onboard:
For each machine, you will need to configure the registration data:.
- Node Configuration Name. DSC configuration that will run on this node. Your configuration should show in the drop-down.
- Refresh Frequency. Represents the frequency in minutes at which the PS DSC Local Configuration Manager contacts the Azure DSC pull server to download the latest node configuration.
- Configuration Mode Frequency. Represents the frequency in minutes at which the background application of DSC attempts to implement the current node configuration on the target node.
- Configuration Mode. Specifies how the Local Configuration Manager applies the configuration to the target nodes. ApplyandMonitor is the default. For other options, see Basic Settings.
- Allow Module Override. Controls whether new configurations downloaded from the Azure Automation DSC pull server are allowed to overwrite the old modules already on the target server.
- Reboot Node if Needed. Reboot the server if the configuration requires.
- Action after Reboot. There are two choices: ContinueConfiguration and StopConfiguration.
Monitoring DSC Jobs
Each time that Azure Automation DSC performs a consistency check on a managed node, the node sends a status report back to the pull server. You can view these reports on the blade for that node.
Notice that you can also Unregister the node and Assign a different configuration to this node. For more information, see Troubleshooting DSC.
This article is from the online course:
Microsoft Future Ready: DevOps Development, Implementation and Azure Automation
Created by
This article is from the free online
Microsoft Future Ready: DevOps Development, Implementation and Azure Automation
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
