An Azure service principal is a security identity used by applications, services, and automation tools to access designated Azure resources. The service principal is a ‘user identity’ (username and password) with an assigned role/permissions in Azure Active Directory (AAD). The service principal should only need to do specific things, unlike a general user identity. In this example, a new Service Principal will be created in AAD and assigned to an Azure Resource Group. Read here for the steps to register a new Service Principal using the Azure ARM Portal
1. #Login to Azure Subscription
Connect-AzureRmAccount -Subscription <Your Subscription Name>
2. #Declare Variables
$subscriptionId = <YOUR SUBSCRIPTION ID>
$tenantId = <YOUR TENANT ID>
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String 'YOUR SECURE PASSWORD OF CHOICE'
At the time of writing this, moving/migration of VMs with managed disks to a new Azure Subscription, is not supported in Azure. It is possible however, to move managed snapshots of a VM’s vhds to another Azure subscription, and then ‘reconstruct’ the VM using the OS and data disks snapshots or managed disks. The VM object itself is just metadata running the vhds (The Move option for both snapshots or managed disks displays in the Azure portal, but we found that the portal Move option does not work for our various Azure Accounts and Subscriptions.(See screen shot below).) The Move operations of snapshots or managed disks can be done easily via PowerShell.
Why move managed disks to another subscription? For example, once a Dev/Test environment is proven, the typical procedure is to migrate the IaaS infrastructure to an Enterprise Subscription for a production environment. Also, moving copies of snapshots out of the main subscription is beneficial for data retention in case of Disaster Recovery or accidental deletions.
A work around for this current limitation – not being able to move/migrate a VM, is to move the managed snapshot(s) to a new Subscription, and then create new managed disks of OS and data vhds for VM in another subscription. It is also possible to migrate a copy of a snapshot or a managed disk into a Storage Account as a page blob to be used by other subscriptions or even other Azure accounts. Read about moving Snapshots to a Storage Account
Unsuccessful Snapshot Move In ARM Portal:
While the option to Move to another subscription is shown on the snapshot blade, validation of the process failed giving the error that this subscription is not ‘registered to use Microsoft.Computer/ManagedResourcesMove feature…but a snap shot can easily be copied to another subscription via PowerShell.
Azure Snapshots of managed virtual hard drives (vhds) are stored in Resource Groups (as opposed to ‘unmanaged’ Snapshots being stored in storage accounts). While it is possible to move the managed snapshots to another subscription using PowerShell, there are advantages to having a copy of crucial core snapshots readily available and protected as a Page Blobs in a Storage Account.
With PowerShell, copies of the Snapshots can be exported to an Azure Storage Account to be able to:
- Maintain a separated set of crucial snapshot copies that cannot be deleted by accident, helpful as another Disaster Recovery point
- Quickly & easily copy Snapshots to a different Azure account or subscription using Microsoft Azure Storage Explorer and then create new managed disks and VMs in the different Account or subscription
- At the time of this writing, VMs with managed disks cannot be moved from one Azure region to another. The workaround is to export a snapshot of the VMs managed disks to a storage account in a different region, and then re-create the VM with the managed disk(s) in a Resource Group in the different region. Read more here.
1. #Login to Azure Portal (read here for a slick way to select the correct subscription context)
Working in Hyper-V before moving all of our resources from physical servers in datacenters to Azure IaaS or PaaS, we regularly took new snapshots of Virtual Machines (VMs) before testing major development changes, adding Windows updates, testing new application settings etc., to allow us to easily revert to the previous state of the VM if desired. In Azure, snapshots are taken of the virtual disks (vhd), not the VM instance itself. Snapshots are full, read-only copies of the vhds. A new VM is created with new managed disks created from stored snapshots of OS data disks; data disk snapshots are turned into managed data disks and then attached to a VM.
An Azure snapshot of a data or operating system (os) vhd can be used:
- For custom backup/restore of a VMs vhds
- For troubleshooting disk problems.
- To create a copy of production servers for use in development, or the opposite, copy a dev environment into production mode.
- To quickly duplicate a fresh VM instance. For example, we use specific single-tier and double-tier web server/sql server environments that need to be reproduced for various testing scenarios. A new ‘exact copy’ environment, with all accounts and applications in place, can be ready for access within 5 minutes if necessary, using stored Azure Snapshots of the OS and data disks. These are considered ‘specialized’ disks…
- To create a ‘repository’ of prepared OS and data disks for use in creating multiple VM copies.
- To create a dr backup repository of snapshots in a different region or subscription (or both), in case of accidental deletion of key OS or data disks.
- Backing up a VM before making a major change – although it is not possible to revert the VM to the previous state, the VM can be deleted and using the saved snapshots > create new managed OS and data disks > create a new VM using the previous VMs Nic, etc.
With multiple Azure subscriptions within a single Azure account, it is crucial to be logged into the correct Azure subscription (AzureRM Context), to be able to access the Azure resources within a specific subscription, via PowerShell (POSH). There is a default subscription that is set to open with each new POSH session. If this default subscription isn’t the preferred working subscription, you will have to select the correct subscription for every new POSH session.
With the Azure Context Autosave feature (added Sept 2017), it is possible that after setting the subscription for the current session, you can have the Azure credentials, account and subscription information saved and automatically loaded when you open a new POSH window – by using the Enable-AzureRmContextAutosave cmdlet
And for easy subscription selection, I recently found these simple POSH cmdlets here, to be able to brilliantly select the correct Azure Subscription by clicking on the list of Azure subscriptions in the Azure Windows account. No copying and pasting of subscription ID, name and/or tenant ID required!
Azure’s Point-to-Site (P2S) VPN gateway connection creates a secure connection to an Azure virtual network’s (VNet) resources from an individual client computer. A VPN gateway is created on its own subnet in an Azure VNet, and then configured to allow P2S connections. No VPN physical device is required and there are minimal, if any, changes required to be made to the on-prem network. A P2S VPN connection is established by starting it from the client computer.
A P2S solution is useful for connecting to Azure VNets from a remote location or when there are only a few clients that need to access an Azure VNet’s resources. We use a P2S connection as a proof-of-concept (POC) for a .Net Web App hosted within an Azure VM webserver to be able to connect to an on-prem Sql Database.
The following cmdlets and process flow is from an excellent article in Azure Documentation, Configure a Point-to-Site connection to a VNet using native Azure certificate authentication: PowerShell with detailed explanations for each of the following steps – we’ve just put it all together in a single, easy to follow list of PowerShell cmdlets to run sequentially in an elevated Windows PowerShell ISE session, to quickly set up a P2S Gateway – after changing the variables for each use case.
Download Zip of POSH cmdlets
There is also an ARM Quickstart Template Point-to-Site Gateway that will quickly provision a P2S Gateway on Azure for you covering Steps 2 – 7 below!
The latest version of PowerShell, version 5.1 was released for WS2012R2, WS2012, W8.1, W2008R2, W7 SP1 on 1/19/2017. The WMF 5.1 version of PowerShell is already running in WS2016 and W10 machines.
Install and Configure
WS2016 and W10: