Use a custom Automation account for Azure to Azure Site Recovery Mobility Service Updates

by Scott Muniz | Sep 3, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Sr. Customer Engineer Dave Newman here on a short post regarding Azure Site Recovery. Hope this helps you in your day to day cloud journey

When replicating Azure VMs from one Azure Region to another for DR purposes, the Mobility Service extension must be added to each protected VM. The extension installation is completed automatically during the “Enable replication” phase of protecting Azure VMs.

Periodically, the Azure Site Recovery (ASR) product group will release an Update rollup to include new features, component updates, support improvements and bug fixes. These are not always on a consistent cadence. Typically, there will be at least one each quarter but sometimes, the case of bug fixes there could be more than one. At the time of this writing there have been 8 releases in the last 12 months.

The ASR product team has created an automated process that will update the Mobility service extension on Azure VMs that are being replicated. When you establish a new Recovery services vault in your target region and select VMs from the source region to protect, the process of creating new resources on the target side includes the creation of a new Azure automation account that will manage this process. When enabled, the management of the agent versions is handled by a global runbook. A job is created in that Automation account that will initialize daily at midnight to check for the presence of a new agent version. If none is found, then the job completes with no action. If a new version is found, the extension will be updated on the VMs via an Azure Automation runbook to bring the systems into compliance with that latest version.

This seems great but there are a few issues. The new Azure Automation account is automatically named and there is no option to specify what that name will be. This will break naming convention. Good governance rules in Azure dictate that wherever possible that a naming convention should be followed. The way the ASR automatically chooses a name is that it takes the first 8 characters of the name of the Recovery service vault, appends a dash (hyphen) and three random alphanumeric characters and then appends the string “-asr-automationaccount”.

If your vault is currently named “AZWUSPRODRSV01”, then the name of your automation account would look something like “AZWUSPRO-a1b-asr-automationaccount”. (the “a1b” character set will be a randomly chosen alphanumeric string.) Not a very governance compliant name.

The second issue is that when creating an Azure Automation account, the default process for authenticating action is to use a “RunAs Account” as defined in the Automation account. This account is an Azure AD Service Principal that is granted a Role Based Access Control (RBAC) role by the creation process. The granted role is Contributor at the Subscription level. That means that the person creating the Automation account needs to have rights in Azure AD to create Azure AD Service Principals and have Owner or User Access Admin RBAC role at the subscription level. Other than User Access Admin, you cannot assign roles with greater privilege than you have been granted. If you are on the DR/Backup team at your organization, you may not have those permissions.

The question at hand is, how can you create a naming convention compliant Azure automation account and tell ASR to use that Automation account for the process of updating the Mobility service extension on protected Azure VMs?

Step one in this is to ensure that a naming convention compliant Azure automation account exists in the same location and resource group as your recovery services vault on the target side. The creation of an Automation account often requires coordination between the Identity team and the Azure team. As mentioned previously, the person creating this Azure resource needs to have the Owner RBAC role defined at the Subscription level.  As a person on the DR/Backup Team you may need to work with someone else who has the appropriate permissions to have this resource created. The creation of the Azure AD Service Principal account is something that could be achieved by temporarily granting the built-in Azure AD role of Application Administrator or Application Developer to the user creating the Automation account. A tutorial for the creation of an Automation account can be found here.

Once the Automation account exists, the recovery service vault in the target region needs to be configured to use that account. This can either be done at the instantiation of the vault or can be done to an existing vault. Both methods will be shown.

If you are building out your recovery services vault for the first time for Azure to Azure DR replication, you can follow the normal steps as outlined in this tutorial. Before you complete the tutorial, stop at the end of the Configure replication settings section. Do not click the Create target resources button just yet. The tutorial shows how you can customize the process so that you can use naming convention conforming target objects. There is another option visible on that blade that the tutorial does not cover. At the bottom of the blade there is an option for Extension settings with a [+] Show details link.

As you can see, it indicates that extension updates are being managed for you. But this is where it wants to do the collection of actions as mentioned earlier in this document that might fail because of permissions. If you open the Extension settings, you will see that there are a few options. You have the option to turn the process off and manage updates manually if you wish. This avoids the need for an Automation account but adds the manual effort of keeping the VMs updated as new versions become available.

The other box allows you to choose a specific, pre-existing, naming convention compliant Automation account.

Once this has been defined you can Create target resources and the system will not attempt to create resources that do not line up with your well-defined Azure governance.

If you have already configured replication for VMs and have seen the process of creating that Automation account fail because of lack of permissions, we will now show how to resolve that issue.

For an existing recovery services vault that you want to either establish or reconfigure, you will need to navigate to the Manage section in the left side menu of your vault and choose the Site Recovery infrastructure option.

From the Site Recovery infrastructure blade, choose Extension update settings. This allows you to toggle on and off the automatic management of the extension updates. It also indicates the name of the Automation account being used if this function is turned on.

If the toggle is set to off because the automation account failed to create, and if a new automation account has already been created and is available in the same resource group and in the same Azure location as the vault, that automation account will display as the account the system wants to use. If that is the case, then all you need to do to resolve this issue is to flip this switch to On.

This document has shown how can you create a naming convention compliant Azure automation account and tell ASR to use that Automation account for the process of updating the Mobility service extension on protected Azure VMs.

The ask that I have heard many times on this issue up updating ASR is – can I do this for my on-premises to Azure VMware systems that have the Mobility Service agent installed. The short answer is that there is no automated process available from the ASR product team currently, but it is something on the product roadmap. 

Hope this helps you in your cloud journey for protecting your Azure VMs. 

What’s New: Azure Firewall Connector in Public Preview!

by Scott Muniz | Sep 3, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

This installment is part of a broader series to keep you up to date with the latest features in Azure Sentinel. The installments will be bite-sized to enable you to easily digest the new content.

Azure Sentinel supports a set of standard patterns for ingesting data at scale. Customers are able to easily onboard data sources via an extensive gallery of connectors and data collection technologies. Data is the foundation for Azure Sentinel. To increase our set of data sources, we are delighted to announce that the Azure Firewall data connector is now public preview!

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It’s a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability.

You can connect Azure Firewall logs to Azure Sentinel, enabling you to view log data in workbooks, use it to create custom analytics,, and incorporate it to improve your investigation/hunting activities.

Learn more about monitoring Azure Firewall logs.

How to enable:

1. From the Azure Sentinel navigation menu, select Data connectors.

      2.  Select Azure Firewall from the data connectors gallery, and then select Open Connector Page on the preview pane.

Enable Diagnostic logs on all the firewalls whose logs you wish to connect:

      3.  Select the Open Azure Firewall resource > link.

      4.  From the Firewalls navigation menu, select Diagnostic settings.

      5.  Select + Add diagnostic setting at the bottom of the list.

GIF Demonstration:

Get Started Today!

Try out the new connector and let us know your feedback using any of the channels listed in the Resources.

You can also contribute new connectors, workbooks, analytics and more in Azure Sentinel. Get started now by joining the Azure Sentinel Threat Hunters GitHub community and follow the guidance.

Azure Maya Mystery Part III: Ascent to the Summit

by Scott Muniz | Sep 3, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Art by Dana Moot II

The past summer has been a magical one for the game-loving members of the Azure Advocacy team, as we presented to you our three-part game series entitled the Azure Maya Mystery. If you haven’t been following along, you can read about its genesis and continuation right here on dev.to.

True to our mission as Advocates on the Academic Team, lead developers Jen and Chris wanted to sneak in a little educational content, and we hope you have enjoyed learning more about Maya glyphs this summer. Congratulations, by the time you complete Level 3, you will know the meaning of 13 ancient Maya glyphs!

The following content contains spoilers about gameplay!

Back in July, we introduced you, the intrepid explorer, to a text-based online experience where you were introduced to a mysterious pyramid you have found, deep in the jungle. As you circle its base, reading half-hidden glyphs, you discover the keys to climb its steep flight of steps to its entrance.

Using your knowledge gleaned from matching clues found in Microsoft Learn and the newly discovered glyphs, you discover a code needed to open the pyramid’s door. You use your learnings about Azure Static Web Apps to launch a chat window to discover part of the pyramid’s name, and then gain entry into the pyramid.

But suddenly, the floor collapses under your feet and you start to slide!

In August, you discovered Level 2, where you speak to a grumpy turtle, launch a web app using Node.js to gather necessary equipment, dive into a cenote, or underground spring, and salvage broken glyphs.

Fitting them back together, you are granted access to the main chamber by the turtle, who seems to be more than a simple reptilian ally.

Now, in the very last level of the Azure Maya Mystery game, you will be able to ascend to the pinnacle of the pyramid by helping complete the restoration of the pyramid and reach the summit. Along the way, you will learn the name of the pyramid and the identity of the goddess to whom it is dedicated.

Using a web app powered by a machine learning model for image recognition, you will gain insight into the full meaning of the three parts of the pyramid’s name. Discover its meaning, and unlock the entry to the summit, where you will be rewarded by the goddess presiding over the pyramid.

We hope you have enjoyed learning about our three technical foci over this summer: Azure Static Web Apps, Node.js, and Machine Learning. In addition, we hope you enjoyed the scavenger hunt we sent you on as you shuttled between Microsoft Learn and the Mystery! Finally, we hope you learned a little about Maya pyramids and glyphs and enjoyed the adventure.

Visit the third level of the Maya Mystery today, ascend to the summit, and earn your reward!