Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

[Azure Automation] Interface discovery. Part I

  • July 6, 2017
  • 9 min read
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.

Azure Automation is an orchestration service who is available on Azure, and that offer the possibility to have 500 free minutes and 5 DSC nodes free. After that, the minute cost

0.002€ and the DSC node 5.06€: https://azure.microsoft.com/en-us/pricing/details/automation/

Azure Automation will give you one interface to manage all your scripts. In the past, we used the Task Scheduler of Windows, on many servers. Hard to find which script is running on which server after some years. By moving your scripts to Azure Automation, you’ll not have this problem anymore, you’ll manage all scripts on a unique interface. And for the script that must run on On-Premises servers, you have the Hybrid Worker solution, who, by installing an agent on a server, will give you the possibility to execute runbooks directly on the server.

You can create an Azure Automation account from the Azure interface. When this account is created, you will see an interface like this:

Microsoft Azure Automation Accounts

Some points are important here:

  • Runbooks: your PowerShell scripts, your workflow.
  • Jobs: Runbooks that ran.
  • Assets: It’s where that you will manage variables, credentials, certificates, etc.
  • Hybrid Worker Groups: Manage connection to your servers.
  • DSC Configurations: Manage your DSC configurations.
  • DSC Nodes: Manage your DSC nodes.

Runbooks

Start by the Runbooks part. You will create your runbooks directly from here. You have the possibility to create runbooks with PowerShell or graphically, in normal or in a workflow:

Microsoft Azure Runbooks

You can import runbook that has been created on another Azure Automation account or PowerShell scripts that exist.

Jobs

Regarding the Jobs part, it’s here that you will have the runbook history that has been executed, and if they ran with an error or not:

Microsoft Azure Jobs

Assets

Explore now the Assets part. Here, you’ll be able to create:

  • Schedules
  • Import modules via the gallery or that you created
  • Certificates
  • Connections
  • Variables
  • Credentials

Schedules will give you the opportunity to automate the starting of a runbook, at hours/days that you defined:

Microsoft Azure Assets Schedules

Modules are very important. In fact, if you want to use commands of a specific module, this module must be imported. If you execute the runbook within a Hybrid Worker, the module must be installed on the associated server. You can import your own module or from the gallery:

Microsoft Azure Assets Modules

Certificates part contains certificates that can be used in scripts (cer and pfx extensions are allowed):

Microsoft Azure Assets Certificates

Connections part give you the possibility to do a connection directly to Azure or third-party tool and use them in your scripts:

Microsoft Azure Assets Connections

Explore now the Variables part. This part is very interesting because it’s here that you will create variable to use them in your different scripts. Using of variables is very convenient because you just modify a variable, without modifying the script. You have some types of variables and you can encrypt them if you want to store password, etc.

Microsoft Azure Assets Variables

To finish, explore the Credentials part. Here, you will create a combination of username/password, like if you use the Get-Credential in PowerShell:

Microsoft Azure Assets Credentials

Hybrid Workers

The Hybrid Workers part will give you the possibility to execute scripts On-Premises. In fact, after installing the agent on a server, when you execute an Azure runbook, you have the choice to execute the runbook on Azure or on a Hybrid Worker Group. With this solution, you can run scripts on your local network, from Azure.

To do this, you must have an OMS workspace: https://www.microsoft.com/oms

With the Azure Automation solution deployed. When it’s done, deploy the OMS agent on a server who will be present in the Hybrid Worker Group. You can have multiple servers in a group.

Configure the agent to allow the communication to Azure Automation: https://docs.microsoft.com/en-us/azure/automation/automation-hybrid-runbook-worker

When the connection is established, it will appear in Azure Automation:

Hybrid worker Groups

DSC Configuration

Here, you can import your DSC configurations:

DSC configurations

And compile them:

DSC configurations compilation

Azure DSC configurations tempfolder creation

DSC Nodes

To manage DSC nodes, and apply configurations, you can do it directly from the interface. You can register nodes who are on Azure (the extension will be deployed automatically) or register an On-Premises server:

Azure DSC Nodes

When you selected nodes, you can apply the first configuration:

Azure DSC Nodes Add Azure VM

After few minutes, an agent is deployed and nodes are compliant if the DSC script has been applied correctly:

Azure DSC Nodes Refresh

Monitoring

To have a quick view on jobs, on the home page, you have statistics:

Azure Monitoring Job Statistics

You can find keys if you want to execute a runbook on this Azure Automation account:

Azure Automation account

And the detail of free minutes remaining on your Azure Automation account:

Azure Automation account pricing tier and usage

You can manage the source control, with Github, VSTS, etc:

Azure Automation account Source control

Finally, to finish, you can use RunAs account to connect to your Azure AD (classic and ARM):

Azure Automation account run as accounts

This first part is now finished. You discovered Azure Automation successfully. In the next part, we will see where to start to migrate scripts from On-Premises to Azure Automation.

Found Florent’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!