Category Archives: Microsoft Azure

How to monitor network activities in Azure with Traffic Analytics

Worldwide cloud networks have substantial differences compared to those in the on-premises, but they are united by the need to be constantly monitored, managed and analyzed. All this is important for to know them better, in order to protect them and optimize them. Microsoft introduced in Azure the solution called Traffic Analytics, fully cloud-based, allowing you to have an overall visibility on network activities that are undertaken in the cloud environment. This article analyzes the characteristics of the solution and explains how you can turn it.

Operating principles of the solution

In Azure to allow or deny network communication to the resources connected with Azure Virtual Networks (vNet) it uses the Network Security Group (NSG), containing a list of access rules. The NSGs are applied to network interfaces connected to the virtual machines, or directly to the subnet. The platform uses NSG flow logs to maintain the visibility of inbound and outbound network traffic from the Network Security Group. Traffic Analytics is based on the analysis of NSG flow logs and after an appropriate aggregation of data, inserting the necessary intelligence concerning security, topology and geographic map, can provide detailed information about the network traffic of your Azure cloud environment.

Figure 1 – Data flow of Traffic Analytics

Solution functionality

Using Traffic Analytics you can do the following:

  • View network activities cross Azure subscriptions and identify hotspots.
  • Intercept potential network security threats, in order to take the right remedial actions. This is made possible thanks to the information provided by the solution: which ports are open, what applications attempt to access to Internet and which virtual machines connect to unauthorized networks.
  • Understand network flows between different Azure regions and Internet, in order to optimize their deployment for network performance and capacity.
  • Identify incorrect network configurations that lead to having incorrect communication attempts.

How to enable the solution

In order to analyze the network traffic you must have a Network Watcher in every region where there are the NSGs for which you intend to analyze traffic. The Network Watcher is a regional service, which makes it possible to monitor and diagnose the networking of Azure. Enabling Network Watcher can be made by Azure Portal, using Powershell or via REST API. By creating it from the portal it is not possible to determine the name of the Network Watcher and its Resource Group, but is assigned a default name in both entities.

Figure 2 – Enabling Network Watcher from the portal

Figure 3 – Enabling Network Watcher using PowerShell

As this is a preview service in order to use it you need to redo the registration of the network resource provider on the Azure subscription interested. You must also register the provider Azure Insights.

Figure 4 - Registration of the providers through PowerShell

In order to enable the collection of NSG Flow Logs you must have a storage account on which to store them. You must also have a workspace OMS Log Analytics on which Traffic Analytics will consolidate the aggregated and indexed data. The information present in Log Analytics will then be used to generate the analysis.

First configuration step of the NSG flow logs settings:

Figure 5 - Selection of the NSGs on which enable the collection of flow logs

Choice of storage account and workspace OMS Log Analytics for each NSGs:

Figure 6 – Enabling the collection of NSG flow logs and consolidation in OMS Log Analytics

The steps above must be repeated for each NSG for which you want to enable Traffic Analytics.

Figure 7 – List of NSGs with settings enabled

Within a few minutes from enabling, time necessary to obtain a quantity of sufficiently indicative aggregated data, its dashboard is populated with the information of Traffic Analytics.

Figure 8 – Traffic Analytics Dashboard

From the dashboard of Traffic Analytics information is readily available such as: hosts with a high level of communication, the most widely used application protocols, the communications that occur more frequently and the flows relating to network traffic in the cloud.

Selecting the section of interest is shown the query of Log Analytics that extrapolates the data:

Figure 9 - Sample query of Log Analytics showing the allowed malicious traffic

For a complete overview of the possible scenarios for using Traffic Analytics you can see this Microsoft's document.

Conclusions

Traffic Analytics is a new feature, currently in preview, introduced in Azure. It is an effective and easy-to-use tool that helps you keep track of the status of your network in Azure reporting very useful data, as who and where are connected, which ports are exposed to the internet, which network traffic is generated and more. This information is critical for detecting anomalies and make appropriate corrective actions. All operations that are difficult to achieve without this fully integrated tool in the platform.

Using Azure Site Recovery Deployment Planner in VMware environments

When you have the need to implement Disaster Recovery scenarios towards Azure particularly in complex environments, through the solution Azure Site Recovery (ASR), you can use the Azure Site Recovery Deployment Planner, recently released by Microsoft, to make a detailed assessment of the on-premises environment. The tool is designed to cover both Hyper-V and VMware environments . In this article, we will detail the use of the tool when you are trying to activate a Disaster Recovery plan with replication of VMware virtual machines to Azure.

What is the use of this tool?

ASR Deployment Planner performs a detailed assessment of the on-premises environment, aimed at using the solution Azure Site Recovery (ASR), and provides elements to consider in order to contemplate the various operations needed to effectively implement the plan of DR: replica, virtual machine failover and DR-Drill. The tool also performs an estimate of Azure resources required for the protection of on-premises virtual machines, reporting information about costs for the use of ASR.

In the presence of VMware environments if you have the need to address real migration scenarios towards Azure, the most appropriate tool to use to carry out the assessment of the environment is Azure Migrate.

How to use the tool?

The use of ASR Deployment Planner involves two main stages. The first of profiling, during which the necessary information is collected from the environment VMware, and the second of report generation to perform the analysis.

ASR Deployment Planner can be downloaded at this link. This is a compressed folder whose contents should be copied on the system on which you intend to run the tool. ASRDeploymentPlanner.exe is the command line tool that must be executed with the appropriate parameters, there is no required installation.

Profiling and measurement of throughput

The machine on which you intend to make the profiling or calculating the throughput must meet the following requirements:

  • Operating System: Windows Server 2016 or Windows Server 2012 R2.
  • Hardware requirements: 8 vCPUs, 16 GB RAM and 300 GB HDD.
  • Software Requirements: .Net Framework 4.5, VMware vSphere PowerCLI 6.0 R3, Visual C++ Redistributable for Visual Studio 2012.
  • Internet access to Azure.

In addition the following conditions are required:

  • Presence of an Azure storage account (only if you want to calculate the throughput).
  • VMware vCenter statistics level set at level 2 or higher.
  • Ability to connect to vCenter server/ESXi host on port 443.
  • User with at least Read-only permission to access the VMware vCenter server/VMware vSphere ESXi.

In general it is a good idea to perform the profiling and the calculation of throughput on the Configuration Server you intend to use, or on a system with similar characteristics.

The tool is able to perform the profiling only for virtual machines with RDM and VMDK disks. There is no collection of information of VMs with iSCSI or NFS disks; in this regard it should be noted that Azure Site Recovery does not support virtual machines with these types of disks in a VMware environment.

During the profiling activity the tool connects to the vCenter Server or vSphere ESXi host to collect performance data for virtual machines. This implies that the data collection activities has no impact on the performance of virtual machines because there is no direct connection. The profiling is done once every 15 minutes as not to impact on VMware systems, but the query that is performed, however, collects performance data for all the time interval.

The profiling activity requires the presence of a text file containing the list of virtual machines (a name or an IP address for each row) you intend to examine. This file you can create it manually or, with the following commands, performed from the VMware vSphere PowerCLI console, you can extrapolate the list of all virtual machines on the vCenter or on vSphere ESXi host.

Figure 1 - Extrapolation of VMs from the vCenter

Figure 2 – Example of the file containing the list of VMs

At this point you can begin the profiling process. For production environments it is recommended to run it for at least a week, so you have a sufficiently long period of observation to achieve accurate profiling. To get the complete list of required and optional parameters, you can run the following command: ASRDeploymentPlanner.exe-Operation StartProfiling /?.

Among the optional parameters you can also specify an Azure Storage Account with its key to calculate the throughput that Site Recovery can reach during the replication process to Azure.

Figure 3 -Example of running the profiling

If the server, on which profiling process starts, be rebooted or goes in crash, the data collected would remain and you can simply restart the tool.

The tool can also be used for throughput calculation.

Figure 4 - Example of throughput measurement

The process of measuring the throughput will upload files with extension .VHD on the storage account specified. Upon completion of the upload these files are removed automatically from the storage account.

Report Generation

The machine on which you want to generate the report must have installed Excel 2013 or a higher version.

After the profiling process you can generate the report containing the output of the assessment. When you create the report, you must run the tool in report-generation mode. In this case to consult all the possible parameters you should run the command ASRDeploymentPlanner.exe -Operation GenerateReport /?.

Figure 5 - Example of the command for the report generation

The report generated is called DeploymentPlannerReport_xxx.xlsm within which you can see different information, including:

  • An estimate of the network bandwidth required for the initial replication process (initial replication) and for delta replication.
  • The type of Storage (standard or premium) required for each VM.
  • The total number of storage accounts (standard and premium) required.
  • The number of Configuration Server and Process Server you need to implement on-premises.
  • The number of VMs that can be protected in parallel to complete the initial replication at any given time.
  • Estimating the throughput attainable by ASR (on-premises to Azure).
  • An assessment of the supported virtual machines, providing details about the disks (number, its size and IOPS) and the type of the OS.
  • Estimation of DR costs, for use it in a specific region of Azure.

Figure 6 - Home page of the generated report

To obtain detailed information concerning the analysis of the report please visit the Microsoft's official documentation.

In addition to being present in the home page of the report a summary of the estimated costs, there is also a specific tab containing the details of the cost analysis.

Figure 7 – Section on cost estimates in the report generated

For more details on the information and its interpretation, you can check the official documentation.

Conclusions

Azure Site Recovery Deployment Planner is a very useful tool that, making a detailed assessment of the on-premises environment, allows not to omit any aspect to achieve in the best way a Disaster Recovery plan towards Azure, using Azure Site Recovery (ASR). This tool also allows you to have with great precision an estimate of the costs that you need support for the disaster recovery plan, so you can make the necessary evaluations.

Azure Backup: the protection of Linux on Azure

Azure Backup is a Microsoft cloud-based data protection solution that, making available several components, allows you to back up your data, regardless of their geographical location (on-premises or in the cloud) toward a Recovery Service vault in Azure. This article will examine the main aspects concerning the protection of Linux virtual machines present in Microsoft Azure, using Azure Backup.

In the security scenario of Azure Iaas virtual machines (Infrastructure as a Service) do not need any backup server, but the solution is completely integrated into the Azure fabric and are supported all Linux distributions approved to run in Azure environment, with the exception of Core OS. The protection of other Linux distributions is also allowed provided that there is the possibility to install the virtual machine VM agent and there is support for Python.

How Azure back up Linux VM

On Linux systems are installed, during the execution of the first backup job, a specific extension called VMSnapshotLinux, through which Azure Backup, during job execution, pilot taking snapshots that are transferred to the Recovery Service vault.

Figure 1 – Principles of backing up Azure IaaS VM with Azure Backup

To have an effective data protection you should be able to make consistent backups at the application layer. Azure Backup by default for Linux virtual machines creates consistent backups at file system level but can also be configured to create application-consistent backup. On Windows systems this is done using the VSS component, while for Linux VM it is made available one scripting framework through which you can run the pre-scripts and post-scripts to control the backup execution.

Figure 2 – Application-consistent backups in Linux VM on Azure

Azure Backup before starting the virtual machine snapshot creation process invokes the pre-script, if this is completed successfully the snaspshot is created, at the end of which runs the post-script. The scripts are fully customizable by the user and they need to be created according to specific characteristics of the application present on the virtual machine. For more details please visit the Microsoft's official documentation.

How to enable the backup of Linux virtual machines running on Azure

Recently it has been introduced the possibility to enable from the Azure portal the protection of virtual machines already from the moment of creation:

Figure 3 - Enabling backup when creating the VM

Alternatively you can enable the protection after creating the virtual machine by selecting it from the Recovery Service vault or by accessing the blade of the VM in the section Operations – Backup. From the same panel, you can view the status of backups.

File Recovery of Linux virtual machine on Azure

Azure Backup, besides the possibility to restore the entire virtual machine, also allows for Linux systems to restore individual files using the File Recovery feature. To do this you can follow these steps below.

From the Azure portal, you select the virtual machine for which you need to restore the files and in the Backup section you start the task of File Recovery:

Figure 4 - Starting the process of File Recovery

At this point will appear the panel where you must select the recovery point that you want to use for the restore operation. Then press the button Download Script which generates a script with extension .sh, and password, that is used to mount the recovery point as system's local disk.

Figure 5 – Recovery Point selection and script download

The script must be copied on the Linux machine and to do that you can use WinSCP:

Figure 6 – Copy of the script on the Linux machine

By accessing the Linux system in terminal mode, you must assign execution permission to the copied script , using the command chmod +x and then you can run the script:

Figure 7 – Script for File Recovery

At the time of the execution the script requires the password which is shown in the Azure portal and then proceed with steps for making your recovery point connection via iSCSI channel and mount it as file system.

Now you can access the mount point path which exposes the selected recovery point and restore or consult the necessary files:

Figure 8 – Access to the path of the mount point

After completing the restore operation is appropriate to make an unmount of the discs through the appropriate button from the Azure portal (in any case the connection to the mountpoint is closed forcefully after 12 hours) and you need to run the script with the parameter -clean to remove the path of the recovery point from the machine.

Figure 9 – Unmount disks and removing mount points from the machine

If in the VM for which you want to restore the files are present LVM partitions, or RAID arrays you must perform the same procedure, but on a different Linux machine to avoid conflicts in the discs.

Conclusions

Azure Backup is a fully integrated solution in the Azure fabric that allows you to protect easily and with extreme effectiveness even Linux virtual machines present on Azure. All this happens without the need to implement complex infrastructure for the data protection. Azure Backup also helps to protect many large-scale systems and to maintain a centralized control of the data protection architecture.

OMS and System Center: What's New in January 2018

The new year has begun with different ads from Microsoft regarding what's new in Operations Management Suite (OMS) and System Center. This article summarizes briefly with the necessary references in order to learn more about.

Operations Management Suite (OMS)

Log Analytics

The release of theIT Service Management Connector (ITSMC) for Azure provides a bi-directional integration between Azure monitoring tools and ITSMC solutions such as: ServiceNow, Provance, Cherwell, and System Center Service Manager. With this integration you can:

  • Create or update work-items (event, alert, incident) in ITSM solutions on the basis of alerts present in Azure (Activity Log Alerts, Near real-time metric alerts and Log Analytics alerts).
  • Consolidate in Azure Log Analytics data related to Incident and Change Request.

To configure this integration you can consult the Microsoft's official documentation.

Figure 1 – ITSM Connector dashboard of the Log Analytics solution

Agent

This month the new version ofOMS agent for Linux systems fixes important bugs also introducing an updated version of the components SCX and OMI. Given the large number of bug fixes included in this release the advice is to consider the adoption of this upgrade. To obtain the updated version of the OMS agent you can access to the official GitHub page OMS Agent for Linux Patch v 1.4.3-174.

Figure 2 – Bug fixes and what's new for the OMS agent for Linux

Azure Backup

During the process of creating virtual machines from Azure portal now there is the ability to enable the protection via Azure Backup:

Figure 3 – Enabling backup while creating a VM

This ability improves in a considerable way the experience of creation of the virtual machine from the Azure Portal.

Azure Site Recovery

Azure Site Recovery allows you to handle different scenarios to implement Disaster Recovery plans, including replication of VMware virtual machines to Azure. In this context the following important changes have been introduced:

  • Release of a template in the format Open Virtualization Format (OVF) to deploy the Configuration Server. This allows you to deploy the template in your virtualization infrastructure and have a system with all the necessary software already preinstalled, with the exception of MySQL Server 5.7.20 and VMware PowerCLI 6.0, to speed up the deployment and the registration to Recovery Service Vault of the Configuration Server.
  • Introduced in Configuration Server a web portal to drive the main configuration actions necessary such as proxy server settings, details and credentials to access the vCenter server and the management of the credentials to install or update the Mobility Service on virtual machines involved in the replication process.
  • Improved the experience for deploying the Mobility Service on virtual machines. Since the 9.13.xxxx.x version of the Configuration Server would be used VMware tools to install and update the Mobility Service on all VMware virtual machines protected. This means that you no longer need to open firewall ports for WMI and for File and Printer Sharing services on Windows systems, previously used to perform the push installation of the Mobility Service.

The monitoring features included natively in Azure Site Recovery have been greatly enriched for having a complete and immediate visibility. The Panel Overview of Recovery Service Vault is now structured, for the section Site Recovery, as follows:

Figure 4 – Azure Site Recovery dashboard

These the various sections, which are updated automatically every 10 minutes:

  1. Switch between Azure Backup and Azure Site Recovery dashboards
  2. Replicated Items
  3. Failover test success
  4. Configuration issues
  5. Error Summary
  6. Infrastructure view
  7. Recovery Plans
  8. Jobs

For more details on the various sections you can see the official documentation or view this short video.

Known Issues

Please note the following possible problem in the execution of backup of Linux VMs on Azure. The error code returned is UserErrorGuestAgentStatusUnavailable and you can follow this workaround to resolve the error condition.

System Center

System Center Configuration Manager

Released the version 1801 for the branch Technical Preview of System Center Configuration Manager: Update 1801 for Configuration Manager Technical Preview Branch.

Among the new features in this release there are:

  • Ability to import and run signed scripts and monitor the execution result.
  • The distribution point can be moved between different primary sites and from a secondary site to a primary site.
  • Improvement in the client settings for the Software Center, with the ability to view a preview before the deployment.
  • New settings for Windows Defender Application Guard (starting with Windows 10 version 1709).
  • Ability to view a dashboard with information about the co-management.
  • Phased Deployments.
  • Support for hardware inventory string longer than 255 characters.
  • Improvements in the scheduling of Automatic Deployment Rule.

Please note that the Technical Preview Branch releases help you to evaluate new features of SCCM and it is recommended to apply these updates only in test environments.

In addition to System Center Configuration Manager current branch, version 1710 was issued an update rollup that contains a large number of bug fixes.

Evaluation of OMS and System Center

Please remember that in order to test and evaluate for free Operations Management Suite (OMS) you can access this page and select the mode that is most appropriate for your needs.

To test the various components of System Center 2016 you can access to the’Evaluation Center and after the registration you can start the trial period.

Service Map in Operations Management Suite: introduction to the solution

In an IT world that is increasingly heterogeneous and ever changing, with hybrid and distributed architectures with systems on-premises and in public cloud providers, is crucial to adopt solutions that manage operations, effectively monitor the entire environment and facilitate any troubleshooting tasks. Operations Management Suite (OMS) is IT management tool from Microsoft, designed in the era of cloud, that includes different solutions designed just for these purposes.

This article describes the main features of the solution Service Map present in Operations Management Suite (OMS) and it will indicate the procedure to be followed to configure Service Map and make the onboarding of the agents.

What is Service Map ?

Service Map is a solution that can be activated in OMS and it is able to automatically carry out the discovery of application components, on both Windows and Linux systems, and to create a map that shows almost real-time communications between the various services. All this allows you to view the servers as interconnected systems that deliver services. Service Map shows in detail the TCP connections that exist between the various systems, with the references of the processes involved in communications and related ports used. This allows you to determine and isolate any problems and to verify communication attempts that are attempted by various systems to detect any unwanted connections or problems in establishing communications needed. This solution is also useful when you must approach to cloud systems migration scenarios to consider all the connections needed for the proper functioning of the application, without neglecting any aspect.

Figure 1 -Example of schema generated by Service Map

Solution activation

By accessing the OMS portal you can easily add the solution Service Map, present in the gallery, by following the steps documented in the following article: Add Azure Log Analytics management solutions to your workspace (OMS).

Figure 2 - Addition of the solution Service Map

Enabling Service Map does not require specific configurations but you need to install on each system a specific agent called Microsoft Dependency Agent, which retrieves information required by the solution. The Microsoft Dependency Agent can only be installed on 64 bit platforms 64 and requires as a prerequisite the presence of the OMS agent . The Service Map Agent does not transmit any information directly into the OMS workspace and therefore is not required to open specific ports to the outside. Data to Service Map are always sent by the OMS agent, directly or through an OMS gateway:

Figure 3 – Data Communication of Service Map

When you activate Service Map in a OMS workspace, the management pack Microsoft. IntelligencePacks. ApplicationDependencyMonitor is sent to all Windows system present in the workspace.

Installation of the Microsoft Dependency Agent on Windows systems

The installation of the Microsoft Dependency Agent on Windows systems is done by invoking, with administrative privileges, the executable InstallDependencyAgent-Windows.exe which can be downloaded at this link. This executable provides the interactive installation using a Wizard or you can use the parameter /S to install the agent of Service Map in a completely silent way, useful if you want to activate it on multiple systems via scripts.

Installation of the Microsoft Dependency Agent on Linux systems

On Linux systems the installation of the Microsoft Dependency Agent takes place through the execution, with root permissions, of a shell script that is contained in the binary InstallDependencyAgent-Linux64.bin, which can be obtained by accessing this link. Also in this case there is the silent installation without user interaction, using parameter -s.

For systems on Azure, you can deploy the Microsoft Dependency Agent even through a specific Azure VM Extension. The extension is available for both Windows and Linux systems and the deploy can be done either via PowerShell scripts or via a JSON template in Azure Resource Manager mode (ARM).

To verify that the installation of the Service Map agent is completed successfully you can check that they are present and running the following components:

  • Service “Microsoft Dependency Agent” on Windows systems.
  • Daemon “microsoft-dependency-agent” on Linux machines.

The Microsoft Dependency Agent sends data through the OMS agent every 15 seconds and depending on the complexity of the environment each agent can transmit approximately 25 MB per day of information related to the Service Map solution. For the Service Map agent can be estimated a use of resources equal to 0,1 % of the system memory and the 0,1 % of the CPU of the system.

Notes and resources related to Service Map solution

How to use operationally Service Map is illustrated very well and in detail in this official Microsoft document. In addition to entering into the specifics of the Service Map functioning consult this article that shows the main features via a practice demo.

Service Map is currently only available in the following regions of Azure: East US, West Europe, West Central US and Southeast Asia.

Costs of the solution

Service Map is included in the package Insight & Analytics and the licensing may be covered in the free plan (up to a maximum of 5 Service Map systems) or takes place per node. For more information, please visit the page of the OMS pricing.

Conclusions

Service Map is a useful solution that can be used to improve the visibility of application flows, evaluate the impact of maintenance on individual systems and improve troubleshooting against fault. The Service Map activation is technically very simple and the added value provided by this solution is considerable, being able to consult at any time a completed and updated map of interconnection of systems, regardless of their geographical location.

Please note that you can test and evaluate for free Operations Management Suite (OMS) by accessing this page and selecting the mode you find most suitable for your needs.

System Center Virtual Machine Manager 1711: managing virtual machines on Azure

As is already the case for the operating system from next year for the System Center products Microsoft will release updated versions every 6 months (semi-annual channel). The main objective of releasing new versions of the product at a higher rate is to improve support for increasingly heterogeneous environments, enhancing the user experience, performance and stability, and ensure a speedy integration with the cloud world.

Figure 1 – Release Cadence of System Center products

The only exception is that Configuration Manager will continue to respect the release of 3 versions every year to better support integration with Intune.

System Center 1801 will introduce new features with regard to Operations Manager, Virtual Machine Manager, and Data Protection Manager, while for Orchestrator \ SMA and Service Manager will include only security-related updates and resolution of issues.

In November was announced the preview of the new version of System Center (version 1711) which you can download at this link to evaluate the new features that will be introduced in the next year.

In this article, we will learn the feature found in Virtual Machine Manager that allows you to manage Azure virtual machines from SCVMM console. With the current version of Virtual Machine Manager, this feature is now limited because it only supports the management of virtual machines that you create with the defined deployment model Azure Service Management (ASM) and only for the public region of Azure. Even the authentication process must necessarily be done through management certificate. In SCVMM 1711 (Technical Preview) the integration to manage virtual machines in Azure extends by introducing the following changes:

  • Support for virtual machines created using the deployment model Azure Resource Manager (ARM).
  • Authentication in Azure Active Directory and not only certificate-based.
  • Subscription management present not only in the public region of Azure, but also in specific region as Germany, China and US Government.

Following are the steps that you must follow to configure this integration using Azure Active Directory as authentication and authorization process. This authentication method is required to manage both Azure virtual machines created in classic mode (ASM) that in ARM mode. To do this configuration it is necessary to create an Azure Application and assign the necessary permissions to access to the Azure subscription. To create the application you can follow the step reported in detail in Microsoft's official documentation.

Figure 2 – Adding a new Azure Active Directory Application

After you create the Azure Application you should make a note of its Application ID and you need to generate a new Application Key. These values are required by the configuration wizard of SCVMM:

Figure 3 - Application ID and the generation of an authentication key

The Azure AD Application must be a member of a role that only allow you to manage the virtual machines in the Azure subscription. For this reason, you must associate the App you just created to the role Virtual Machine Contributor in the Azure subscription.

Figure 4 - Assignment of the role "Virtual Machine Contributor" to the Azure AD App

By accessing the Virtual Machine Manager console, from the workspace VMs and Services you can add one or more Azure subscriptions:

Figure 5 – Addition of the Azure subscription from the SCVMM console

The configuration screen requires the input of data relating to the subscription and the information to perform the authentication process by Azure AD App:

Figure 6 – Subscription data and authentication information through Azure AD

At the end of this configuration will be displayed in the Virtual Machine Manager console the virtual machines configured in the Azure subscription. On these virtual machines at the moment you can do only the following basic tasks: Start, Stop, Stop e Deallocate, Restart and launch the RDP connection. In addition, for each virtual machine there are some information related to the configuration of the Azure environment.

Figure 7 – Managing Azure virtual machines from SCVMM console

Conclusions

Having in a single console all virtual machines, including those present in Azure, enables administrators to manage, even with simple tasks, easily and with greater rapidity hybrid environments. At the moment it comes as a basic integration but thanks to an accelerated release cycle expected for Virtual Machine Manager is very likely that this integration can be expanded more and more.

Azure Site Recovery: disaster recovery of VMware virtual machines

The solution Azure Site Recovery (ASR) protects virtual or physical systems, hosted both Hyper-V environment that VMware, automating the replication process to a secondary data center or to Microsoft Azure. With a single solution you can implement Disaster Recovery plans for heterogeneous environments orchestrating the replication process and actions needed for the successful recovery. Thanks to this solution, the DR plan will be easily available in any eventuality, even the most remote, to ensure business continuity. Recently, the solution has been expanded while also providing the ability to implement a disaster recovery strategy for Azure virtual machines, allowing you to enable replication between different regions.

In this article I'll show you how ASR can be used to replicate virtual machines in VMware environment to Azure (scenario 6 in the following figure), examining the characteristics and technical procedure to be followed. The following illustration shows all the scenarios currently covered by ASR solution:

Figure 1 – Scenarios covered by Azure Site Recovery

The replication scenario of VMware virtual machines to Azure requires the presence of the following architecture:

Figure 2 - Architecture in the replication scenario VMware to Azure

In order to activate the replication process is required the presence of at least one on-premises server on which you install the following roles:

  • Configuration Server: coordinates communications between the on-premises world and Azure, and manages the data replication.
  • Process Server: This role is installed by default with the Configuration Server, but may be provided more Process Server based on the volume of data to be replicated. It acts as a replication gateway, then receives replication data, performs an optimization through caching and compression mechanisms, provides encryption and sends them to the storage in the Azure environment. This role is also responsible to make the discovery of virtual machines on VMware systems.
  • Master target server: even this role is installed by default with the Configuration Server, but for deployment with a large number of systems can be more servers with this role. Take action during the failback process of resources from Azure by managing replication data.

On all virtual machines subject to the replication process is required the presence of Mobility Service, that is installed by Process Server. It is a special agent in charge of replicating the data in the virtual machine.

Following describes the process to follow to make the deployment of on-premises and Azure components required to enable replication of VMware virtual machines to Microsoft's public cloud.

The core component required on Azure side is the Recovery Service Vault within which, in the section Site Recovery, you can start the configuration process controlled by the chosen scenario.

Figure 3 – Choice of replication scenario of VMware virtual machines within the Recovery Service Vault

Then you must install on the on-premises machine the Configuration Server by following the steps listed:

Figure 4 – Steps to follow to add the Configuration Server

In this section of the Azure portal it is possible to download the Microsoft Azure Site Recovery Unified Setup and the key required for the registration of the server to the vault. Before starting the installation make sure that the machine on which you intend to install the Configuration Server be able to access the public URLs of the Azure service and that is enabled during the setup the web traffic on port 80 needed to download the MySQL component used by the solution.

The setup prompts you for the following information:

Figure 5 – Choice of roles to install

Select the first option for installing the roles Configuration Server and Process Server. The second option is useful if you need to install additional Process Server to enable a scale out deployment.

Figure 6 - Accept the license agreement by MySQL Community Server

Figure 7 - Key selection required for the registration to the Site Recovery Vault

Figure 8 - Choice of the methodology to access the Azure Services (direct or via proxy)

Figure 9 – Check to verify prerequisites

Figure 10 – Setting passwords for MySQL

Figure 11 – Further check on the presence of the required components to protect VMware VMs

Figure 12 – Choice of the installation path

Installation requires approximately 5 GB of available space, but are recommend at least 600 GB for the cache.

Figure 13 — Select the network interface and the port to use for replication traffic

Figure 14 – Summary of installation choices

Figure 15 - Setup of the different roles and components successfully completed

At the end, the setup shows the connection passphrase which is used by the Configuration Server, that is good to save with care.

Then you must configure the credentials that will be used by Azure Site Recovery to discover virtual machines in the VMware environment and for the installation of the Mobility Service on virtual machines.

Figure 16 - Definition of the credentials used by the service

After complete these steps you can select the Configuration Server from the Azure portal and then define VMware system data (vcenter or vSphere) with which to interface.

Figure 17 - Select the Configuration Server and add vCenter / vSphere host

On completion of this configuration it is necessary to wait few minutes to allow the Process Server to perform the discovery of VMware virtual machine on the specified environment.

Then you need to define the settings for the target of the replica:

  • On which subscription and what recovery model (ASM or ARM).
  • Which storage account use to host the replicated data.
  • vNet on which attest the replicated systems.

Figure 18 – Target replication settings

The next step involves defining the replication policy in terms of RPO (in minutes), retention of the recovery points (expressed in hours) and how often make consistent snapshot at the application level.

Figure 19 – Creation of the replication policy

Upon completion of this task is proposed to carry out the analysis of your environment using the tool Deployment Planner (available directly through the link in the Azure Portal) in order to ensure that the requirements, network resources and storage resources are sufficient to ensure the proper operation of the solution.

Figure 20 - Steps of infrastructure preparation completed successfully

After completing the infrastructure preparation steps you can activate the replication process:

Figure 21 - Source and Replica Target

Figure 22 - Selection of the virtual machines and of the related discs to be replicated

This section also specifies which account the Process Server will use to install the Mobility Service on each VMware virtual machine (account configured previously as documented in Figure 16).

Figure 23 - Replication policies selection and optionally enable Multi-VM consistency

If the "Multi-VM consistency" option will be selected it will create a Replication Group within which will be included the VMs that you want to replicate together for using shared recovery point. This option is recommended only when you need a consistency during the fail over to multiple virtual machines that deliver the same workload. Furthermore, by activating this option you should keep in mind that to activate the system failover process is necessary to set up a specific Recovery Plan and you can not enable failover for a single virtual machine.

At the end of these configurations you can activate the replication process

Figure 24 – Activation of the replication process and its result

Figure 25 - State of the replica for the VMware virtual machine

One of the biggest challenges when implementing a Disaster Recovery scenario is to have a chance to test its functionality without impacting production systems and its replication process. Equally true is that do not test properly the DR process is almost equivalent to not having it. Azure Site Recovery allow you to tests in a very simple way the Disaster Recovery procedure to assess the effectiveness:

Figure 26 – Testing the Failover procedure

Figure 27 - Outcome of the Test Failover process

Conclusions

Being able to rely on a single solution as Azure Site Recovery that lets you enable and test procedures for business continuity in heterogeneous infrastructures, contemplating even virtual machines in VMware environment, certainly has many advantages in terms of flexibility and effectiveness. ASR makes it possible to deal with the typical obstacles encountered during the implementation of Disaster Recovery plans reducing the cost and complexity and increasing the levels of compliance. The same solution can also be used to deal with the actual migration to Azure with minimal impact on end users thanks to nearly zero application downtime.

Azure Backup: the System State protection in the Cloud

The ability to protect the System State of Windows Server machines directly in Azure using the Azure Backup Agent was recently included. This feature was in preview for a few months and now it is available to be used in production environments. In this article I'll show you how you can protect with Azure Backup the System State of the machines, analyzing the characteristics and the benefits brought by this new feature.

The Azure Backup Agent allows you to save files, folders and thanks to the incorporation of the System State are covered by the protection of Windows Server machines the following components:

  • Boot files, including system files, and all files protected by Windows File Protection (WFP).
  • Active Directory and Sysvol (on domain controllers).
  • The registry.
  • IIS metabase (on Web Server IIS machines): includes IIS configurations and web sites hosted by the web server.
  • Database cluster (on cluster nodes).
  • Certificate Services (on the certification authority).
  • Information about the Performance counters.
  • Component Services Class registration database.

Thanks to the incorporation of the System State, Azure Backup becomes ideal for protection strategies of Active Directory, File Server and IIS Web Server.

Figure 1 – Protection of System State in Azure

This solution is supported starting with Windows Server 2008 R2 to Windows Server 2016.

To enable this type of protection is necessary to create within the subscription Azure a Recovery Service Vault, install the Azure Backup Agent on Windows Server machine and complete its registration by following the steps shown in the following diagram:

Figure 2 - Activation steps for the protection with Azure Backup

By accessing the Azure portal and selecting the Recovery Service Vault, within which you want to include the protection, in the Backup section appears the possibility of protecting the System State for workloads running On-Premises:

Figure 3 – Selection of System State as a component to be protected

By selecting the button "Prepare Infrastructure" it lists the necessary steps to protect the System State of the machines:

Figure 4 – Steps for preparing the infrastructure

From the panel above you need to download the Recovery Service Agent installation setup and the Vault credentials.

The installation of the agent (MARSAgentInstaller.exe) is very fast and consists of the following steps:

Figure 5 - Selecting the installation folder and the cache location

In the cache location it is advisable to have as free space at least 5% of protected data.

Figure 6 – Configuration of proxy system for Internet access

Figure 7 – Check the requirements and installation

Figure 8 – Initiation of the process of registration with the Recovery Service Vault

Figure 9 – Selection of login credentials to the vault

Figure 10 - Generate and save the passphrase

The Passphrase is used to encrypt and decrypt the backups, it is never sent to Azure, it is not recoverable in any way by Microsoft support personnel and it is essential to be able to perform restore operations, so you must keep it very carefully.

Figure 11 – Registration successfully

From Microsoft Azure Backup console, you can schedule a backup and for servers, in the selection of items to protect, there is the System State:

Figure 12 - Selection of the System State Protection

Figure 13 - Settings on the frequency of the backup

Figure 14 - Definition of the retention rules

Figure 15 - Final Step, activation of the System State backup

System State protection can also be automated with PowerShell. You also have the possibility to consult easily the backup jobs directly from the Azure portal, and you can configure notifications to be notified in case of failure of protection jobs.

The offsite backups is ensured with this solution without investing in infrastructure costs and saving time in operational activities. It is also good to keep in mind that the cost of this solution are really beneficial, in fact, typically the size of the System State for a single machine is significantly less than 50 GB then the System State protection pricing level falls within the lower cost band specified for the instances protected with Azure Backup. For more details on the cost of the solution you can consult the Azure Backup pricing page. No cost for any restore operations is also required.

Conclusions

The System State for Windows Server machines is a critical component that should be saved for a proper and effective strategy to protect its infrastructure. Azure Backup due to its defined approach cloud-first extend their potential enabling you to protect the System State of the machines easily, securely and with low costs. To try Azure Backup and other Azure services you can create a Azure free Account.

Azure Site Recovery: disaster recovery of Virtual Machines in Azure

In azure, there is the possibility of using Azure Site Recovery (ASR) to implement easily an efficient disaster recovery strategy by enabling replication of virtual machines among different regions of Azure. Although in Azure are present integrated mechanisms to deal with localized hardware failures, it may be appropriate to implement a solution that can ensure applications compliance , performed on virtual machines in Azure, against both catastrophic events, such as earthquakes or hurricanes, that software issues that may impact on the functioning of an entire region of Azure. This article will show you how to configure a virtual machine replication and how to enable a disaster recovery scenario.

This feature has been defined one-click replication because of its simplicity, it is currently in public preview and it is usable in all the Azure regions where ASR is available.

Before you enable this functionality is essential to ensure that the necessary requirements are met and to do that you can see the compatibility matrix for the replication scenario of virtual machines among different regions.

By accessing the Azure Portal it is possible to select the virtual machine that you intend to replicate and perform the configuration in the section Disaster recovery:

Figure 1 – Disaster Recovery Section of the VM

Selecting Disaster Recovery shows the following configuration panel:

Figure 2 – VM replication configuration panel

The first required parameter is the target region where you want to replicate the virtual machine. The replication activation process also create the necessary Azure artifacts (Resource Group, Availability Set if used by the selected VM, Virtual Network and Storage accounts) or you can select them at will if they were created earlier.

Figure 3 – The resources needed in the region target

The replication process also requires the presence of a Cache Storage Accounts in the source region that is used as a temporary repository to store changes before they are reported in the storage account defined in the target region. This is done to minimize the impact on production applications that reside on the replicated VM.

Figure 4 - Cache Storage Account in the replication process

Always in the configuration panel is required which is proposed Vault Recovery Services use creating a replication policy that defines the recovery point retention and the rate at which consistent snapshots are made at the application level.

By selecting Enable Replication will begin the creation process of Azure resources required, the VM is registered in the selected Recovery Services Vault and replication process is activated.

The Disaster Recovery section lists details about the replication and it is possible to perform a failover or a test failover:

Figure 5 - Details relating to the replication process of the VM and activation of the failover process

The procedure Test Failover Specifies which recovery point using between: latest, latest processed, latest app-consistent or custom. In addition it is possible to select in which virtual network attest the virtual machine during the test failover in order to perform the test without generating any impact on the production systems.

Figure 6 – Test Failover of a VM

Similar the Failover panel that allows you to specify only which recovery point to use as the network on which attest the machine has already been defined in the configuration phase.

Figure 7 – Failover of a VM

Only when you start the Failover process affected virtual machines are created on the target resource group, attested to the target vNet and configured in the availability set appropriate when used.

Figure 8 – Failover process

Conclusions

Thanks to this new feature introduced in Azure Site Recovery it is possible to activate with ease replication of virtual machines in different Azure regions, without the necessity of having expensive secondary infrastructure to activate a disaster recovery plan.

What's New in Azure Automation: Inventory, Change Tracking and Update Management

In Azure Autiomation were recently introduced new features, currently in preview, which make it possible to manage the distribution of updates, collect inventory information about the applications installed on the systems and keep track of changes made on the machines. This article will show you how to configure the Azure Automation Account to take advantage of these new features and it will show their main characteristics.

In order to use each of these features it is necessary that the Automation Account is associated with a Log Analytics Wokspace.

If the Automation Account where you want to enable these new features is not linked to any Workspace of Log Analytics is requested, in the process of activation, the binding to an existing Workspace or it propose the creation of a new Workspace:

Figure 1 - Association of Automation Account to Log Analytics Workspace

The capabilities of Change Tracking and Inventory are enabled simultaneously by the Azure portal and at the end of the activation will appear the following notification:

Figure 2 – Notification after enabling Change Tracking and Inventory features

For enabling Update management you will need to perform the same operation.

Figure 3 – Enabling the Update Management feature

At the end of these activities in the Log Analytics Workspace will be present the following solution:

Figure 4 – Solution added in Log Analytics

After the completion of the activation, the solution begins to show the data of machines already connected to the OMS Workspace associated with the Automation Account. You could also get the onboarding by further machines directly from the relevant sections of the Azure Portal:

Figure 5 - Adding additional systems

This process requires the installation of the OMS agent on systems and can be done either on Windows and Linux. If the machines are on the Azure fabric the OMS agent installation process is integrated and can happen quickly with a simple click from the Azure Portal. Otherwise you can still associate the systems by manually installing the OMS agent, independently from their location (on-premises or others cloud).

For the functionality of Inventory and Change Tracking you can access the settings (common among the two solutions) to customize the registry key information, the files under Windows and Linux that you plan to inventory and monitor:

Figure 6 – Edit your settings

Figure 7 - Personalization of the configuration

 

Inventory

This feature allows you to retrieve inventory information relating to: installed software, files, Windows Registry keys, Windows Services and Linux Daemons. All this can be accessed easily directly from the Azure portal and it is possible to apply search filters:

Figure 8 - Search the inventory data

 

Change Tracking

The functionality of Change Tracking monitors changes made to systems relatively to Daemons, File, Registry, software and services on Windows . This feature can be very useful to diagnose specific problems and to enable alerts against unexpected changes.

Figure 9 - Consultation of changes

By accessing the Log Analytics console you can also carry out more targeted searches:

Figure 10 – Log Search Analytics

Also in the Change Tracking there is the possibility to connect theAzure Activity Log of an Azure subscription to collect also changes you make in Azure side.

Figure 11 – Azure Activity Log connection

 

Update Management

The solution of Update Management allows a total visibility on the update compliance for both Windows and Linux systems:

Figure 12 - Global status of compliance of the updates on managed systems

Using the search panel you can quickly identify missing updates:

Figure 13 – Identify missing updates

The solution is not only very useful for consultation, It also allows you to schedule the deployment to install the updates within a specific maintenance window.

Figure 14 – Deplyment schedule

Very soon, even the ability to deploy on Linux systems. Among the features offered there is the ability to exclude specific updates from the deployment.

Figure 15 - Deployment Settings

Scheduled deployments and their execution status can be monitored in real time directly from the Azure Portal:

Figure 16 – List of scheduled update deployments

Figure 17 – Update Deployment in progress

Figure 18 – Update Deployment successfully completed

Selecting the deployment completed you will be sent to a well-structured and easy-to-use dashboard that allows you to check the details of the deployment:

Figure 19 – Deployment dashboard

Also useful the ability to retrieve logs that are related to deployment for troubleshooting purposes.

Conclusions

These are features that give you the ability to control and manage easily, and efficiently environments composed of few units in the cloud up to contemplate hybrid scenarios with a large number of systems. These features are currently in preview therefore intended to further expand their potential. In particular the functionality of Update Management to manage and orchestrate the updates deployment in complex environments in an efficient and flexible way will have to evolve, but it is definitely in a good point of the develop. For more details of Azure Automation I invite you to consult official documentation.