Pachehra

Random Issues - Azure

As topic suggested , i am going to discuss few issue or learning that we did recently. Lets understand the Scenario first -

Scenario 1 = >

As per the request we need to move the Azure VM from one region to another and we need to utilize the Av-Zone instead of Av-Set. Azure VM is in Av-set in source.

So as per situation we chose ASR for this task because in my opinion ASR works pretty good for Azure to Azure migration and nothing as such needed except recovery vault.

Learning 1- ASR creates the Av-Set as per Source , you can not move the VM in Av-zone during the replication via ASR it would only replicate to Av-set.

Learning 2 - We moved the VM via ASR , now we planed deleting the VM and re-creating the VM in Av-zone from left-out disk of deleted VM however we couldnt succeed even validation passed because disk wasn't in the Av-zone.

Solution :- We created snapshot of the VM and created Disk out of snapshot inside Av-zone and created VM inside zone finally.

Scenario 2 = > We need to move the VM's from one region to another and both the Vnets with the same address space. We chose ASR for this task and while enabling replication it got failed with error.

Learning :- Source machine had Static private IP and as i said address space are same at both the location hence it got failed because private IP of source wasn't available at the destination & ASR weren't assigning another IP because source IP was static.

Solution :- Before you start replication navigate to the Replication items and then computer & network there you can change the IP manually or you can change the IP at the source as Dynamic before enabling replication.

VM Migration between Regions via ASR - Issues Faced and Fixed

There was this situation I faced while migrating Azure VM from EastUs to Eastus-2. As region was changing hence, we chose ASR for this task which required nothing to setup except, some basic things like Recovery Service Vault and rest ASR will create by itself or you can create it as well.

But here we are not talking ASR but the Issues I encountered during Azure to Azure Migration of VM’s.

VM Greyed out and unable to select for the Replication:

There were few machines which I couldn’t even select for the replication as these were grayed out. Below snippet would show where exactly but now we can select them after couple of troubleshooting steps:-

- Check if there is any extension is pending or failed or in transitioning , Make sure there shouldn’t be any extension on the VM or if there is it should be succeeded.

- Make sure there shouldn’t be any DNS applied. In my scenario it was applicable as we removed the AD as well from Eastus infra and only VM were left which were in domain.

If you're using custom DNS then make sure that the DNS server is accessible from the Disaster Recovery region.Try accessing the DNS server from the virtual machine. If it is not accessible then make it accessible by either failing over the DNS server or creating the line of site between DR network and DNS.

After performing above mentioned steps I could select the VM’s for the replication however in few of the machines it got failed with error “Task execution has timed out”

Below are steps performed to fix the execution timed out issue or protection failed:-

Azure Agent is the reason for the above mentioned error so very first thing I did – went on the Azure portal >> Azure VM >> properties >> check Agent status in the below snippet it showing nothing but in my case it was Not Ready however it should be Ready.

- First thing check the “windows Azure Guest Agent Service” it should be running. In my case it was grayed out, could be because either agent was corrupted or old.

- If service is not running start the service or if it is case like mine then uninstall the agent and re-install latest one.

- Before you download and install the Agent make sure .Net 4.5 or above is there which is required for the agent to communicate with the service.

- latest version of the agent MSI download and install.

- Once agent is Ready , you will see the version and computer name as well in the properties tab and also VM Overview.

In my case agent was the culprit and after following these steps I fixed it.

Before I wrap up this post, also like to mention how to figure out weather you have .Net 4.5 or above.

- => Go to Start >> Run >> Regedit >> this would open the registry of the machine.

- => Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full

- If the Full subkey isn't present, then you don't have the .NET Framework 4.5 or later installed.

- => Check for a DWORD entry named Release. If it exists, then you have .NET Framework 4.5 or later versions installed.

Reference links

https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-troubleshoot-errors#unable-to-see-the-azure-vm-or-resource-group--for-selection-in-enable-replication

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-extension-troubleshoot#the-agent-installed-in-the-vm-but-unresponsive-for-windows-vms

https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed

Managed Identities - Azure AD

Managed Identities provides secure method for authenticating Azure resources against other Azure services, without needing to include any credentials.

Managed Identities can be used to authenticate to any service that supports Azure AD authentication without having any credentials in your code.

This feature provides the ability to authenticate on Azure resources "behind the scenes" & does not provide any implicit permissions or authorization , that must still be configured separately.

Lets see some important facts about Managed Identities usage :

No need to store credentials in application code.
Fully managed by MS, so no need to rotate the credentials.
Automates the creation/registration of an application within Azure AD, Service Principal & Client-ID
Built-in functionality for Azure resources to securely obtain an authentication token.
Does not imply any authorization as identity must still be granted permissions.

Managed identities has three main components -

Principal ID : object id of the service principal
Client ID : unique identifier generated by Azure AD
Azure Instance Metadata Service (IMDS) : Rest endpoint accessible to VMs via 169.254.169.254

Types of Managed Identities :

1) System Assigned :

Fully managed by Azure & directly created for and associated with a resource.
Exists with the resources & deleted if resource deleted.
Associate with a single resource

2) User Assigned :

Created as an individual resource & managed by an administrator.
Can be associated with one or more Azure services.

Lest Check how to create Managed Identity and provide access permission and finally assign that identity to Azure VM and then try to get an access token using VM assigned idenetity & use it to call Azure Resource Manager.

Navigate to Managed Identity in Azure Portal and create one , follow the snippets :

Lets navigate to Subscriptions and then IAM to provide the Permissions to the Managed identity and in our case we would provide reader access.

Now lets navigate the Virtual Machine settings and click on identity , here we would add the managed identity as user assigned.

Now as we have discussed above we have completed all the task and assigned managed identity to the VM , Now lets login to the VM and obtain the access token first , via Powershell

$response = Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' -Method GET -Headers @{Metadata="true"}

Response from above command is in JSON , lets extract it by -

$content = $response.Content | ConvertFrom-Json

$ArmToken = $content.access_token

Finally call ARM using this access token

(Invoke-WebRequest -Uri https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE GROUP>?api-version=2016-06-01 -Method GET -ContentType "application/json" -Headers @{ Authorization ="Bearer $ArmToken"}).content

You will get a response like this

{"id":"/subscriptions/98f51385-2edc-4b79-bed9-7718de4cb861/resourceGroups/DevTest","name":"DevTest","location":"westus","properties":{"provisioningState":"Succeeded"}}

We will discuss managed Identities with Azure Container Instances in next post.

Refernce link :

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-arm#feedback

Availability Sets Vs Availability Zones - Azure

In this post lets figure out what to use and what is the difference between Av-set and Av-zone.

Most important part is these 2 are separate features provided by Azure for HA & cant be used together. You can either opt for Av-set or Av-zone, you can use both together.

Av-set is old feature as compare to Av-zone and available on all the regions but not Av-zone. If you want to use Av-zone , first confirm availability in your region and second confirm are all the services supported, may possible few services not zonal as of now but soon will be.

Below are the few difference and understanding of Av-set and Av-zone :-

Availability Set	Availability Zone
It is a logical grouping capability for VM's where VM's are placed between different fault and Update domains	It is unique physical locations within Azure regions & each Zone is made up of one or more data-centers equipped with independent power, cooling and networking
Update domain - 20 & Fault Domain - 3	1,2 & 3 - Av-Zone
Offers 99.95% SLA (2 or more VM)	Offers 99.99% SLA
Protect from Hardware failures within Data Centers	Protect from entire data center failure
Basic LB can work with Av-set	Standard LB supports Av-Zone

Here is the Video for Azure VM availability options:-

If you think something is missing , please add comment or if you want to add something.

Storage Account Failover (Preview) in Storage Account - Azure

This Storage account fail-over is in pre-view but i feel its wonderful feature that would help in Disaster Recovery and Migration as well. Hope this feature would be in GA & in this post we would be discussing about this feature in respect of the Migration or moving VM's , snapshot , disk in other region. Well the best way of moving or migrating Azure VM from one region to other is ASR , we all know that but incase we need to move without ASR or somehow we cant use ASR then this feature would be handy.

Lets Understand it first then will try to register the provider and perform the fail-over :

Customer managed account fail-over enables you to fail your entire storage account over to the secondary region.

When you force failover to the secondary region, Clients can begin writing data to the secondary endpoint once failover is complete.

Failover typically takes about an Hour.

Storage account with GRS and RA-GRS are entitled for this feature thats quite obvious but once you fail-over to the secondary region, the storage account is configured to be LRS & you can make it GRS or RA-GRS.

Data replicated from Primary account to secondary is always asynchronous hence there is always delay before a write to the primary region is replicated to secondary region.

When you force failover the , all data in primary region is lost as the secondary region becomes the new primary region & configured as LRS.

Last Sync Time property indicates the most recent time that data replicated from primary to secondary region. Any data write after last sync would be lost.

First register the provider if not already to utilize this preview feature and once you run the below command it takes days to get register.

Register-AzProviderFeature -FeatureName customercontrolledfailover -ProviderNamespace Microsoft.Storage

Below command would help you check if provider is registered already

Get-AzProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage

Created the storage account with GRS redundancy :-

Optional# lets copy the managed snapshot to this storage account so that we could fail-over and check if we could create the VM out of that disk.

$resourceGroupName = 'RG'
$snapshotName = 'snapshotname'
$resourceGroupNameStorageAccount = 'RG'
$storageAccountName = 'storageaccountname'
$storageContainerName = 'containername'
$destinationVHDFileName = 'vhdfilename'

$storageAccountKey = Get-AzStorageAccountKey -resourceGroupName $resourceGroupNameStorageAccount -AccountName $storageAccountName

$sas = Grant-AzSnapshotAccess -ResourceGroupName $resourceGroupName -SnapshotName $snapshotName -DurationInSecond 9600 -Access Read

$destinationContext = New-AzStorageContext –storageAccountName $storageAccountName -StorageAccountKey ($storageAccountKey).Value[0]

Start-AzStorageBlobCopy -AbsoluteUri $sas.AccessSAS -DestContainer $storageContainerName -DestContext $destinationContext -DestBlob $destinationVHDFileName

This command would give the status of the copy :-

Get-AzStorageBlobCopystate -Context $destinationContext -Blob $destinationVHDFileName -Container $storageContainerName

Once copy is success , lets force fail-over and try to create the VM out of it. Once you hit the button prepare for fail-over, it would show you last sync time and ask for confirmation.

Hit the failover button and after a short while your secondary region would become primary and primary would become unavailable and so is the data on primary region so be very cautious while performing this.

Well incase of primary unavailable , MS fail-over by itself or you can do by force but if you do that by force as discussed above , you will loose all data inside the primary and your secondary will become primary - what you can do , you can copy data from secondary region to some-other region and perform your task.

Azure Security Best Practices - TOP

In this post we will be talking about the Top Most security best practices one should follow in their Azure infrastructure and latter we would talk about alot of security practices needed to make your environment secure.

Security Best Practices :-

=> Security Center - Opt for the standard tier of the Security Center which assess your environment continuously and provides you all the security vulnerabilities and their fixes, Apply access & application control to block malicious activity, Detect threats using analytics and intelligence.

=> Key Vault : Store your keys and secrets in the Azure key vault. Key vault is designed to support any type of secret , passwords, database credentials, API Keys and certificates.

=> WAF : Web application firewall is a feature of App Gateway that provides centralized protection to your web applications from exploits and vulnerabilities. You can use 3rd party as well.

=> MFA & Conditional Access : MFA would help administrators protect their organization and users with additional authentication methods & Conditional Access - enables the administrators to require the end-user to be in a trusted location to register for MFA or SSPR.

=> Encryption : Encrypt your VHD's , Storage , DB in rest or in transit and store the keys & secrets in vault.

=> Network Traffic : Control or protect the traffic with the help of NSG's and JIT to access the VM. Control the RDP access from Internet and create the layered architecture like DMZ(Jump) >> Private (web) >> Internal (DB)

=> DDOS : Distributed denial of services is a type of attack that tries to exhaust application resources. Azure provides Basic DDOS protection but recommended is Standard, which provides additional mitigation capabilities.

=> Anti-virus & malware : Azure VM should have the anit-virus and malware as these are just like on-prem VM hence admins responsibility.

=> Whitelist IP : Azure provides whitelisting Ip's on SQL server, sql DB and storage account as well. Enabling whitelisting for those IP which require only is a good security practice.

=> Virtual Endpoints : Enable endpoints for all the PaaS services which supports this to utilize the Azure backend network rather sending traffic over internet.

=> VM Updates : Ensure your Azure VM are updating regularly.

=> Password : Use proper password security policies to prevent abuse.

Please add in comments if you think something is missing and should be there as a top best security practice.

How to stay connect-azaccount in the PS - Even after closing PS

In this post we are going to talk about the one cmdlet which would allow you to stay connected with your az account context even if you closed your PS Session.

Lets configure with the help of few easy commands :-

Connect-AzAccount

*Prompt would appear to login with user name and password*

Once you logged in either select or set the context -

Set-AzContext -SubscriptionId "xxxx-xxxx-xxxx-xxxx"

Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
Work test@outlook.com Subscription1 AzureCloud xxxxxxxx-x...

Now you need to enable the autosave az context , so that whenever you open the PS you would have the same context and no need to go thought the login process again - use this cmdlet -

Enable-AzContextAutosave

Once you run the above command you are all set until your credentials are not expired.