All posts by Janaka Rangama

Azure VM Serial Console Access Preview

One of the biggest challenges in any public cloud IaaS platform is enabling the direct serial-based access so that engineers can fix boot issues. However Microsoft Azure Compute team has overcome this challenge and has introduced serial console access (preview feature) to Azure VMs recently.

This allows access to a text-based console for Linux and Windows virtual machines. Furthermore this serial connection  to COM1 serial port of the VM provides access to the VM settings that are not related to its network/operating system state.

Following prerequisites must be met in order to use this feature.

If you want to disable this feature all you have to do is to disable the boot diagnostics setting for the desired VM.

This can be found under VM setiings blade > Support + Troubleshooting > Serial console (Preview)

Enabling Serial Console access in Windows VMs

  • RDP into your Azure VM running Windows OS.
  • Execute the following commands as an administrator in command prompt.
bcdedit /ems {current} on

bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
  • Once you reboot the VM serial console access will be enabled.

This preview is available in all Azure regions.

Isolated Azure VMs | New Sizes

Microsoft has announced two new IaaS VM sizes called E64i_v3 and E64is_v3 earlier today. These VM SKUs have isolated hardware and can be dedicated to a single customer.Microsoft recommends these two SKUs for workloads that needs a  a high degree of isolation from other customers for compliance and regulatory requirements.
Performance & Pricing Matters

The performance and pricing of E64i_v3 and E64is_v3 are same as their predecessors cousins E64_v3 and E64s_v3. Also the two new SKUs are available in all regions supported by E64_v3 and E64s_v3 sizes. As you may have already guessed, the simple  letter ‘i’ in the VM size name denotes that they are isolated.

Here are some facts about the new sizes.

  • E64i_v3 and E64is_v3 are hardware bound sizes unlike   E64_v3 and E64s_v3.
  • E64i_v3 and E64is_v3 operate on Intel® Xeon® Processor E5-2673 v4 2.3GHz hardware only and will be available until at least December 2021.
  • These sizes will have 12 months in advance after December 2021 to be decommissioned and after that MSFT will  offer updated isolated sizes with their next gen hardware.
  • On May 1st, 2018 these sizes will be made available as one-year Reserved VM Instances.
What are my other options?

Here is the full list of isolate VM sizes that is available in Azure Public cloud as of today.

 

Azure Standard Load Balancer | NSGs are a must

Azure Standard Load Balancer is a new Load Balancer SKU that provide 10x performance and more features than the Basic SKU. One of the coolest features is the ability to use two Standard Load Balancers as a public and internal Load Balancer at the same time. This allows a VM NIC to be connected to the backend pool of one public and one internal Load Balancer resource  where both are of Standard SKU.

I’m my test lab I tried to replicate the Internal + External loadbalancing scenario and found that only the Internal Load Balancer has been working. I’ve tried every possible change I could do including:

  • replicating the same inbound rules as the Internal LB,
  • deleting and re-creating the LB,
  • changing the health probes countless time,
  • changing the health probe settings,

and none of the tweaks I did worked for the External Azure Standard LB.

The Culprit

This article explains the security model of the new Azure Standard Load Balancer.  I had a through look in the documentation and found out the following section.

Standard Load Balancer is fully onboarded to the virtual network. The virtual network is a private, closed network. Because Standard Load Balancers and Standard public IP addresses are designed to allow this virtual network to be accessed from outside of the virtual network, these resources now default to closed unless you open them. This means Network Security Groups (NSGs) are now used to explicitly permit and whitelist allowed traffic. You can create your entire virtual data center and decide through NSG what and when it should be available. If you do not have an NSG on a subnet or NIC of your virtual machine resource, we will not permit traffic to reach this resource.

As you can see if we don’t assign an NSG rule to explicitly allow inbound traffic from the Internet to reach the LB backends (VMs) connected to the Azure Standard Load Balancer. Let’s examine a practical example.

In my example the backend VMs are connected to an Azure Standard LB that resides in the DMZ subnet of a VNet. I have created subnet specific NSGs so therefore the rule I’m going to create is assigned to the DMZ NSG.

As you can see all the inbound traffic originating from the Internet which are destined to ports 443,8443,8444 on DMZ subnet 10.150.4.0/24  have been whitelisted in this rule.  Also note that the External Azure Standard LB has three loadbalancing rules corresponsing to the same ports.

It is a simple solution yet can cause a huge trouble in your environment. In my case not having the NSG rules assigned has resulted in a Traffic Manager endpoint (of course the endpoint was an External Azure Standard LB) to be  in a degraded state during a DR drill. Therefore it is quite important to make sure that you have created the appropriate NSG rules if you are using the Standard SKU for your external Azure LBs.

 

Process Server fails to communicate after ASR Update Rollup 22

Recently I have been working on an ASR implementation for a customer, where it was required to upgrade the MARS version from 9.8 to 9.13. Microsoft has set a deadline of 28th February for this update as after that enabling replication using older version of MARS wouldn’t work. Here is what you see when you are prompted to perform this upgrade.

Since we were running an incompatible version of MARS (Microsoft claims that you need to have a n-4 version of DRA in order to successfully perform this update) we had to perform a step upgrade from 9.8 to 9.10 and then to 9.13. This link provides to reference to that.

The Issue

Both process servers in the environment have been successfully upgraded to 9.13 as a step upgrade. But as soon as the latest version was installed, both the config server and the secondary process server lost communication with the ASR vault and refresh server connection task has been failing for no reason.

We have raised this with Microsoft support and the support engineer assigned to our case found out one alarming issue under ASR operational log under Windows Event viewer in the config server.

 

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.  File name: 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'    

at SrsRestApiClientLib.SrsCreds.InitializeServiceUrl()    

at SrsRestApiClientLib.SrsCreds..ctor(String resourceId, String siteId, String draId, X509Certificate2 cert, AcsConfiguration acsConfig, Boolean retryFetch, String apiVersion, Proxy webProxy, String msiVersion, String vmmVersion)    

at SrsRestApiClientLib.ClientHelper.InitializeDra(String resourceId, String siteId, String draId, X509Certificate2 cert, AcsConfiguration acsConfig, String apiVersion, Proxy webProxy, String msiVersion, String vmmVersion)    

at Dra.SrsCommunication.SrsCommunicationClient.InitializeSrsCommunication()    

at Dra.SrsCommunication.SrsCommunicationClient..ctor(IDraFabricAdapter fabricAdapter)    

at Dra.Dra.Initialize(IDraFabricAdapter fabricAdapter)    

at Dra.DraFactory.CreateInstance(IDraFabricAdapter fabricAdapter)    

at Microsoft.VirtualManager.Engine.DRA.Core.Core.Initialize()   

WRN: Assembly binding logging is turned OFF.  To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.  Note: There is some performance penalty associated with assembly bind failure logging.  To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].  ,{00000000-0000-0000-0000-000000000000}



======================

The Culprit

As you may have already notice there is an exception logged stating that the DRA cannot find ‘Microsoft.IdentityModel, Version=3.5.0.0’, which is indeed a part of Windows Identity Foundation 3.5 role in Windows Server. When we checked the installed roles in the config server this role wasn’t present and we have enabled it again to see whether it would have made any difference. Viola!, the process servers reestablished the communication to the vault soon after this role has been installed.

Aftermath

ASR engineering team has confirm that the DRA has a pre-requisite to check whether the config server has Microsoft .NET framework 4.5 installed. Furthermore with .NET 4.5, WIF role is fully integrated into the .NET Framework, meaning that it should be automatically installed alongside .NET 4.5 should have been present in this case. They have reproduced the issue and verified that in upgrade from 9.10 to 9.13, no issues are observed as there are no options available to disable WIF along with .NET Framework 4.5 installation (DRA runs ion a minimum of .NET 4.5 and the latest requirement supports Recently .NET framework 4.6.2).

My best bet is that this has happened when we performed the upgrade from 9.8 to 9.10 as we haven’t reproduced that possibility. The config server haven’t had any major change in its configuration so the only suspect is the 9.8 to 9.10 upgrade. Well I’m exploring that possibility right now and will be publishing a another post if my theory is confirmed. But until then, it still remains a mystery.

Protecting Azure IaaS VMs with Managed Disks with Site Recovery

Microsoft Azure Site Recovery team has just announced the capability to protect Azure IaaS VMs with managed disks using ASR as a public preview in all ASR enabled regions. This was an important steps as lot of customers were expecting to protect their VM workloads with managed disks, compared to the previous unmanaged disk scenario.

A2A Managed Disk Architecture

The challenge here was how do you replicate disk without requiring a VM object. To overcome this hurdle, ASR uses one storage account, in source region which will cache the disks to the target region. This enables ASR to create a replica managed disk in the target region for each VM protected in the primary region and this replica disk will be the data store for the source disk in the primary region. One important thing to note is that the initial replication between the source and target happens externally using a snapshot at the VM level, so are delta syncs.

Things to Remember

  • VM protection can be enabled via VM settings blade or in the recovery services vault settings.
  • If you have VMs with unmanaged disks that are currently protected by ASR, you need to disable protection and convert the VMs to managed disks first as conversion from unmanaged to managed disks while protected by ASR is not supported.
  • There is an option for you to selected the type of the replica disks, to standard or premium. See below screenshot.
  • Only one cache storage account is needed to so store the data changes from source to primary regions, but you can leverage multiple cache accounts per VM as well.

Azure Backup OOTB with VM Creation

OOTB stands for Out-of-the-Box. What does Azure Backup has to do with it? Well this blogpost explains how you can protect your VM with Azure Backup at the time of its creation.

Previously when you wanted to add an Azure VM to be protected by Azure Backup, you had to created a recovery services vault and  select the desired VM or you had to allow backup through the VM Management blade. The catch here is both these options are post creation activities. In my opinion, administrators often forget to protect their Azure VMs  post creation. With this new update, we can protect our Azure VMs during it’s creation.

When you create a VM in the portal under Settings  > Configure Optional Features blade you can find the backup option now.

Here you can create a new recovery services vault or select an existing one and then create or choose an existing backup policy to backup your Azure VM.

 

 

Azure Site Recovery | New Onboarding Experience for VMWare to Azure Workloads

Microsoft has introduced a new onboarding experience with the latest update to Azure Site Recovery service for VMware to Azure  workloads. In this blogpost we are going to explore how this new experience save time when you setup your ASR infrastructure on-premises.

Open Virtualization Format (OVF) template-based configuration server deployment

Previously you had to download and install the ASR configuration server package in to a VMWare VM running a supported OS which you have created earlier. With this update you will be using a OVF template, which you can directly import in a VMWare host as a guest VM that functions as the configuration server for your ASR setup. All the necessary software, except MySQL Server 5.7.20 and VMware PowerCLI 6.0, is pre-installed in this VM template.

Below video from Microsoft ASR product team explains how you can leverage the new OVF template setup.

Web Portal for Configuration Management

With this update, Microsoft has introduced a new web portal in the configuration server. All configuration servers deployed using the OVF template will use this portal modify the following settings.

New Mobility Service Deployment model

If you are familiar with VMWare to Azure scenario in ASR, then you know the difficulties of the mobility service push deployment method for your VMware VMs. Previously this required you to open firewall rules for WMI and File and Printer Sharing services in Windows for the protected VMs. The reason being that WMI and File and Printer Sharing services were used by ASR service to push install the mobility service on the protected VMs. Not every organization allows this firewall exception in production environments.

In the latest ASR release, VMware tools will be install/update mobility services on all protected VMware VMs replacing the need to open above mentioned services in firewall rules. One thing to keep in mind is that VMware tools based mobility service installation is available only if you update your configuration servers to version 9.13. xxxx.x.

Azure Site Recovery Comprehensive Monitoring

One of the challenges I had with Azure Site Recovery is to provide a Business Continuity Dashboard experience for the IT administrators in my customer organizations. Previously I was able to achieve somewhat of this task by creating Azure Dashboards that showcase the components of the ASR environment. However Microsoft has recently introduced an out-of-the-box comprehensive monitoring dashboard experience for Azure Site Recovery. This gives full visibility into whether business continuity objectives are being met for organizations and also a failover readiness model that monitors resource availability and suggests configurations based on best practices.

What’s new in Azure Site Recovery Monitoring

Below is the new dashboard you see when you navigate to the Overview section of your recovery services vault in Azure.

  • Enhanced vault overview page – The new vault overview page features a dashboard that presents everything you need to know to understand if your business continuity objectives are being met. In addition to the information needed to understand the current health of your business continuity plan, the dashboard features recommendations based on best practices, and in-built tooling for troubleshooting issues that you may be facing.
  • Replication health model – Continuous, real time monitoring of replication health of servers based on an assessment of a wide range of replication parameters.
  • Failover readiness model – A failover readiness model based on a comprehensive checklist of configuration and disaster recovery best practices, and resource availability monitoring, to help gauge your level of disaster preparedness.
  • Simplified troubleshooting experience – Start at the vault dashboard and dive deeper using an intuitive navigational experience to get in depth visibility into individual components, and additional troubleshooting tools including a brand new dashboard for replicated machines.
  • In-depth anomaly detection tooling to detect error symptoms, and offer prescriptive guidance for remediation.

Introducing PowerShell Core 6.0

Few Days back Microsoft has announced the general availability of PowerShell Core 6.0. It is a new edition of PowerShell that enables you to work with PowerShell regardless of your operating system, be it Windows, MacOS or Linux. It’s runtime is built on top of .NET Core 2.0 and it also exposes the APIs offered by .NET Core 2.0, so that you can use the same APIs in your PowerShell scripts, cmdlets etc…

PowerShell vs. PowerShell Core

 

Below are the key differences between the two editions of PowerShell.

 

Windows PowerShell

PowerShell Core

It is the edition of PowerShell built on top of .NET Framework

(sometimes referred to as “FullCLR”):

It is the edition of PowerShell built on top of .NET Core

(sometimes simplified to “CoreCLR”).

Because of its dependency on the .NET Framework, Windows PowerShell is only available on Windows (hence the name).

PowerShell Core is launched as pwsh.exe on Windows and pwsh on macOS and Linux

The released versions of Windows PowerShell include 1.0, 2.0, 3.0, 4.0, 5.0, and 5.1.

On PowerShell Core, $PSVersionTable.PSEdition is set to Core.

Windows PowerShell is available as a built-in component in Windows client and Windows Server.

Although PowerShell Core 6.0 is cross-platform, there is also a PowerShell Core 5.0/5.1 released exclusively as part of Microsoft Nano Server.

Windows PowerShell is launched as powershell.exe.

Any usage of .NET-based functionality (e.g. C# cmdlets, Add-Type, and the invocation of static .NET Methods), relies on the .NET Core runtime. This means PowerShell Core is limited to the functionality exposed by .NET Core and .NET Standard.

On Windows PowerShell 5.0/5.1, $PSVersionTable.PSEdition is set to Desktop.

 

Any usage of .NET-based functionality (e.g. C# cmdlets, Add-Type, and the invocation of static .NET Methods), relies on the .NET Framework runtime. This means Windows PowerShell’s .NET usage is limited to the functionality exposed by the .NET Framework and .NET Standard.

 

Continues to be supported via critical bug fixes in the newest releases of Windows and Windows Server

 

 

You can Download PowerShell Core depending on your OS platform using below links.

 

PowerShell Core on Windows https://aka.ms/getps6-windows

PowerShell Core on macOS and Linux https://aka.ms/getps6-linux

Azure Stack Policy Module for Azure

When you want to deploy your services across both Azure & Azure Stack, you need to make sure that both environments has the same resources and services available. Also the resources should be compatible with each other. The Azure Stack Policy module enables the same versioning and services that Azure Stack has in your Azure subscription. This will allow you to create a new Azure Policy that limits the available resources in your Azure environment to that of Azure Stack.

Let’s see how we can achieve this with PowerShell.

Installing the Policy Module

Apply the Policy

If you want to apply the default Azure Stack policy to your Azure subscription itself, you can use the below example.

Login-AzureRmAccount
$s = Select-AzureRmSubscription -SubscriptionName "<Azure Subscription Name>"
$policy = New-AzureRmPolicyDefinition -Name AzureStackPolicyDefinition -Policy (Get-AzsPolicy)
$subscriptionID = $s.Subscription.SubscriptionId
New-AzureRmPolicyAssignment -Name AzureStack -PolicyDefinition $policy -Scope /subscriptions/$subscriptionID

If you want to apply the policy into a particular resource group, you can execute the below snippet. This is useful when you have other Azure services running in the same Azure subscription which are not compatible with Azure Stack. Targeting a specific resource group to deploy the default Azure Stack policy will allow you to test apps that are developed for Azure Stack.

Login-AzureRmAccount
$rgName = '<resource group name>'
$s = Select-AzureRmSubscription -SubscriptionName "<Azure Subscription Name>"
$policy = New-AzureRmPolicyDefinition -Name AzureStackPolicyDefinition -Policy (Get-AzsPolicy)
New-AzureRmPolicyAssignment -Name AzureStack -PolicyDefinition $policy -Scope /subscriptions/$subscriptionID/resourceGroups/$rgName