Archive for April, 2018

Azure Automation – getting started

Azure Automation allows Azure administrators to run PowerShell and other scripts against an Azure subscription. They provide several benefits versus running the same scripts from the user desktop computer including:

  • Scripts run in Azure and are not dependent on the end-user desktop
  • Scripts are highly available by design.
  • Scheduling is a built-in feature
  • Authentication is streamlined for both classic ASM and current ARM resources

To get started with Azure Automation;

  1. Create an Azure Automation account
  2. Install needed PowerShell modules
  3. Create, run, test, schedule scripts

Create an Azure Automation account

In the current portal, Create Resource > Monitoring and Management > Automation > Create

In the ‘Add Automation Account’ blade enter/select a name for the Automation Account, Azure Subscription, Resource Group, and Azure Location

Azure will take a few minutes to create the automation account and associated objects.

We can now run scripts against the Azure subscription selected above. Here are some examples:

Create a test script

In the Automation Account blade, click Runbooks

Click ‘Add a runbook’ link on the top to create a new runbook of type PowerShell

Azure creates the runbook/script, and opens the ‘Edit PowerShell Runbook’ blade

Type in the desired command, click Save, then ‘Test pane’

In the ‘Test’ blade, click ‘Start’. Azure will queue and execute the script


  • This is not like the PowerShell ISE. There’s no auto-completion for one thing.
  • If Azure comes across a bad command, it will try to execute THE ENTIRE SCRIPT repeatedly, and is likely to get stuck.
  • This shell does not support user interaction. So, any cmdlet that would typically require a user confirmation/interaction of any type will fail. For example, Install-Module cmdlet will fail since it requires user approval/interaction to install PowerShellGet.

Install needed modules

To see available modules click ‘Modules’ in the Automation Account blade

Click ‘Browse Gallery’ on top and search for the desired module

These modules come for the Microsoft PowerShell Gallery.

Click on the desired module, view its functions, and click Import to import it to this automation shell

Now that the module is imported, we can use it in scripting in this particular automation shell:



Azure Data Box

Azure Data Box is Microsoft’s parallel of AWS’¬† Snowball Edge or/and Google Transfer Appliance. It’s the evolution of Azure Import/Export service that allows a client to use client-provided disk to import/export data to/from Azure. As of April 2018;

Basic information

  • Azure Data Box is a 45 lb. NAS
  • 80 TB Usable Storage / 100 TB Physical Storage
  • Cost $80 + shipping both ways + Egress charges if exporting from Azure
  • 7-10 days processing time from device receipt date

Use Case

File share transfer/initial seeding

  • Azure Data Box connects to the client network as an IP NAS
  • Client uses¬†WAImportExport free tool to copy BitLocker encrypted data to the Azure Data Box at local on-premises LAN speeds
  • At LAN speed of 1 Gbps and sustained local disk transfer rate of 128 MB/s, it takes about 7.5 days to copy 80 TB of data, provided the client does not require/impose copy throttling to maintain adequate data access performance.


  • Azure Data Box provides a free short term rental of a 100TB NAS. Alternatively a client can use their own disk(s) or NAS devices to transfer data to Azure using the same steps.
  • Azure Data Box is not intended for VM replication or migration.
  • It takes about 3 weeks between start of 80TB local data copy on-premises to data being available in Azure Storage Account (1+ week for local copy, 1+ week for Microsoft processing + shipping time)
  • Azure Data Box is useful in case of transferring mostly static data from on-premises to Azure. Daily data change rate must be below 5% (otherwise 100% of the data could have changed during the 20 day between start copy and data available in Azure)