Category Archives: Microsoft Azure

Azure Backup: as the solution evolves

Microsoft recently announced important news regarding the protection of virtual machines using Azure Backup. Thanks to an update of the backup stack you can get consistent improvements that make the solution more powerful and extend the potential. In this article will be investigated the benefits obtained by the update and will be examined the steps to switch to the new backup stack.

Features introduced by the new backup stack

Instant Recovery points and performance improvements

The Azure Backup job for the protection of virtual machines can be divided into two distinct phases:

  1. Creating a snapshot of the VM.
  2. Snapshot transfer to a Recovery Service vault.

Figure 1 - Steps of the backup job

Updating the backup stack, the recovery point is made available immediately after you create the virtual machine snapshot (Phase 1), and it is usable for restore operations according to the known methods. Unlike before that it was possible to use it only at the end of phase 2. From the Azure portal it is possible to distinguish the type of recovery point, as at the end of phase 1, the recovery point type is defined as "snapshots", while at the end of the snapshot transfer to the backup vault, the recovery point type is marked as "snapshot and vault".

The snapshots created during the backup process are maintained for 7 days. With this change are reduced considerably the execution time of the restore, carried out using the snapshots, which can be used in the same way to the checkpoint created by Hyper-V or VMware.

Support for large disks

The new backup stack also allows you to protect disks of size up to 4TB, both typologies: managed and unmanaged. Previously the limit in the maximum size of protected disks was 1 TB.

Distribution of disks during the recovery of virtual machines

After the upgrade of the backup stack you have the option to choose where to place the disks unmanaged of the virtual machines during the restore process. This reduces the configurations that would be necessary, post restore activities, putting all disks within the same storage account.

The Upgrade process

In order to enjoy the benefits introduced by the new backup stack you must manually upgrade your subscription which owns the Recovery Service Vault in the manner later described.

Consideration Pre-Upgrade

Before dealing with the upgrade of the stack you should consider the following aspects:

  • Since the upgrade is enabled at the Azure subscription level, the method of performing backups is changed for all protected virtual machines, present in the specific subscription. In the future it will be possible to have more granular control of this upgrade process.
  • The snapshots are saved locally to speed up the process of creation of the recovery point and to increase the speed of the restore processes. This means that there will be costs for the storage used by the snapshots preserved for 7 days.
  • The incremental snapshots are saved as page blob. For those who use managed disks there are no additional costs, while those using unmanaged disks must also consider the cost of the saved snapshots (during the 7 days) in the local storage account.
  • In the event of restore of a premium VM, starting from a snapshot recovery point, will be present, when creating the VM performed by the restore process, a temporary storage location.
  • For premium storage account you need to consider an allocation of 10 TB, for snapshots created for the purpose of instant recovery.

How to upgrade

The upgrade can be performed directly from the Azure portal or through PowerShell commands.

By accessing the Recovery Service vault from Azure portal, a notification will appear which indicates the ability to perform the backup stack upgrade.

Figure 2 – Backup stack upgrade notification

Selecting the notification the following message will appear that allows you to start the upgrade process.

Figure 3 - Launch of the backup stack upgrade process

The same operation can be performed using the following Powershell commands:

Figure 4 – Powershell commands to register the subscription to the upgrade process

Upgrade backup stack generally takes several minutes (maximum two hours), but it has no impact on scheduled backups.


This major update of the Azure Backup stack shows that the solution is evolving to expand its capabilities and to ensure higher performance levels. To make a contribution with new ideas or vote the features that are considered most important for Azure Backup you can access this page. For more details on Azure Backup you can see the Microsoft's official documentation.

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

Microsoft announces constantly news about Operations Management Suite (OMS) and System Center. Our community releases this summary monthly, allowing you to have a general overview of the main new features of the month, in order to stay up to date on these arguments and have the necessary references to conduct any insights.

Operations Management Suite (OMS)

Log Analytics

Microsoft has decided to extend the Alerts in Log Analytics from OMS to the Azure Portal, centralizing on Azure Monitor. This process will be done automatically starting from 14 May 2018 (the date has been postponed, Initially it was planned for 23 April), will not result in any change to the configuration of Alerts and related queries, and it does not foresee any downtime for its implementation. For further details please consult the specific article “The extension of Log Analytics Alerts in Azure Monitor“.

Figure 1 – Notification of alerts extension in the OMS portal

To avoid situations where, the resources managed in Log Analytics may send in an unexpected way a high volume of data to the OMS Workspace, is introduced the ability to set a Daily Volume cap. This allows you to limit the data ingestion for your workspace. You can configure the Data volume cap in all regions, accessing to the section Usage and estimated costs:

Figure 2 – Setting the Daily volume cap

The portal also shows the trend of the volume of data in the last 31 days and the total volume of data, grouped by solution:

Figure 3 – Data ingestion for solution (latest 31 days and total)

Log Search API usage, used by the old Log Analytics query language, has been deprecated since 30 April 2018. The Log Search API has been replaced with theAzure Log Analytics REST API, which supports the new query language and introduces greater scalability than the results you can return. For more details on this you can consult theofficial announcement.


This month the new version ofOMS agent for Linux systems resolves a significant number of bugs and introduces new versions of the various components. It also introduced support for Debian 9, AWS 2017 and Open SSL 1.1. To obtain the updated version of the OMS agent you can access to the official GitHub page OMS Agent for Linux Patch v 1.6.0-42.

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

Azure Backup

As for Azure Backup, have been announced the following improvements in service scalability:

  • Ability to create up to 500 recovery services vaults in every subscription for region (previously the limit was 25).
  • The number of virtual machines that can be registered in each vault is increased to 1000 (it was previously 200).

Azure Backup, for the protection of Azure Iaas VM, now supports the storage account secured using storage firewalls and Virtual Networks. More details about this can be found on Microsoft's official blog.

Figure 5 - Protection of Azure Iaas VM in storage protected scenarios

There are different rules to enable the long-term backup for Azure SQL Database . The procedure, to keep the backup of Azure SQL DB up to 10 years, expected saving in an Azure Recovery Vault Service. By introducing this new feature, you have the option to keep the long-term backup directly within an Azure Blob Storage and will terminate the need for a Recovery Vault Service. All this gives you more flexibility and greater control of costs. For more details about it you can see the article SQL Database: Long-term backup retention preview includes major updates.

System Center

System Center Configuration Manager

For System Center Configuration Manager has been released the version 1804 for the Technical Preview branch. In addition to general improvements in the solution this update introduce new features concerning the OSD, the Software Center and the Configuration Manager infrastructure. All the new features included in this update can be found in the article Update 1804 for Configuration Manager Technical Preview Branch. Please note that the releases in the Technical Preview Branch help you evaluate the new features of SCCM and it is recommended to apply these updates only in test environments.

System Center Operations Manager

Microsoft has released theUpdate Rollup 5 (UR5) for System Center 2016 Long-Term Servicing Channel (LTSC). This update does not introduce new features, but fixes several bugs.

Following, are the references, about this update, for each System Center product:

There are no updates regarding Service Provider Foundation.

System Center Operations Manager 1801 introduces support for Kerberos authentication when the protocol WS-Management is used from the management server for the communication with UNIX and Linux systems. This allows you to have a higher level of security, eliminating the need to enable basic authentication for Windows Remote Management (WinRM).

Also in System Center Operations Manager 1801 introduces the following improvements on the management of the Linux log file monitor:

  • Support for Wild Card characters in the name and path of the log file.
  • Support for new match patterns that allow customized searches of log.
  • Support for pluging Fluentd published by fluentd community.

Below there are the news concerning the Management Pack of SCOM:

  • MP for Windows Server Operating System 2016 and 1709 Plus
  • MP for SQL Server 2008-2012
  • MP for SQL Server 2014
  • MP for SQL Server 2016
  • MP for Microsoft SQL Azure Database
  • MP for SQL Server Dashboards
  • MP for UNIX and Linux 7.6.1085.0

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 theEvaluation Center and after the registration you can start the trial period.

Azure Monitor: how to check the health of Azure Services

Azure Monitor, through the service called Azure Service Health, can provide detailed information in case you experience conditions affecting the functioning of your services in the Microsoft cloud. In this article we will examine how Azure Service Health can help to identify the impact of the problems, send notifications and maintain administrators up to date as the issue is resolved. It will also further how this service can help to prepare for planned maintenance and to understand how these might affect the availability of your resources.

To get a visual on the overall state of Azure health, Microsoft offers its status page, that shows in real time the situation of the various products and services, divided into geographical areas. This page shows all the problems, even those who do not have a direct impact on the status of your services.

To obtain a customized view, covering only your own resources, you can use Azure Service Health. In this way is encouraged early detection of information concerning the following aspects:

  • Problems on services: lists the Azure services issues that impact on own resources.
  • Scheduled maintenance: lists the future maintenance affecting the availability of your own services.
  • Health advisories: these are the changes in Azure services that require attention. Possible examples of this can be reports of certain usage quotas are exceeded or when certain features of Azure are deprecated.

Figure 1 – Azure Service Health sections present in the Azure Portal

By accessing the section Azure Service Health – Service issues, in Azure Monitor, you can create custom dashboards. In order to receive notifications only for resources of interest, you are prompted to select the subsbriptions, the regions and the appropriate services. At the end of this selection, you can save the filters by assigning a name.

Figure 2 – Selection of regions

Figure 3 – Selection of Azure services

Figure 4 – Saving and naming

By selecting the button "Pin filtered world map to dashboard" you can see the custom map in the Azure Portal dashboard, so you instantly have a visual impact on the health status of the subscription, of the services and of the selected regions.

Figure 5 – Map, with filters applied, shown in the dashboard

If issues arise that impact your resources on Azure, by accessing the portal, you will receive a notification similar to the following:

Figure 6 - Reporting an ongoing issue that impacts your services

Selecting the custom map you will be sent in the Azure Service Health of Azure Monitor. This dashboard shows the relevant details and the list of your own resources, that potentially could be impacted by the issue, in addition to its status updates.

Figure 7 - Summary of the issue

From this page you can also download the PDF documentation (in some cases also in CSV format) describing the problem, in order to be sent to those who have no direct access to the Azure Portal. There are also useful links to contact Microsoft support if error condition persist after the issue is reported as solved.

Figure 8 – Resources potentially impacted by the issue

The section Health history shows past problems encountered on Azure services and that have had an impact on the health of your own resources.

Figure 9 - List of problems reported in the Health history

Azure Service Health, in the section Resource health, also displays the state of health of the resources by type.

Figure 10 – Resources Health by type

Selecting the individual Azure service you can consult both the current state of health that any problems that occurred in the past on a given resource.

Figure 11 – Current state of health and past events of a specific Virtual Machine

Thanks to the complete integration of Service Health on Azure Monitor, which holds the alerting engine of Azure, you can configure specific Alerts if there are issues on Azure side, that impact on the operation of the resources present on your own subscription. The notification occurs through Action Groups, that currently includes these possible actions:

  • Voice call (currently only in US) or sending SMS (for enabled countries).
  • Sending an email.
  • Calling a webhook.
  • Sending data to ITSM.
  • Recalling a Logic App.
  • Sending a push notification on mobile app of Azure.
  • Running a runbook of Azure Automation.

Figure 12 – Adding a Service Health Alert

Figure 13 -Configuring a Service Health Alert


The recent availability of Azure Service Health, introduced the ability to receive customized and targeted information on the health of your own resources in Azure, without having to search for potential problems of Azure globally by going to its status page. This saves time and easily understand, in the face of problems or scheduled maintenance, what is the impact on your own services.

The extension of Log Analytics Alerts in Azure Monitor

Being able to take advantage of a centralized and effective service for the management of Alerts of your infrastructure is definitely an important and fundamental part of the monitor strategy. For this purpose Microsoft has introduced a new experience in the management of the Alerts through Azure Monitor. This article will present how to evolve the management of Alerts in Log Analytics and what are the benefits introduced by this change.

In Log Analytics there is the ability to generate Alerts when, in the research that is done with scheduled frequency in the OMS repository, you will get the results that match with the criteria established. When an Alert is generated in Log Analytics you can configure the following actions:

  • Email notification.
  • Invocation of a webhook.
  • Running a runbook of Azure Automation.
  • IT Service Management activities (requires the presence of the connector for the ITSM solution).

Figure 1 – Alerts in Log Analytics

Until now, this type of configuration has been managed from the OMS portal.

Azure Monitor is a service that allows you to monitor all Azure borne resources, and it holds the "alerting" engine for the entire cloud platform. By accessing the service from the Azure portal you will have available, in a unique location, all Alerts of your infrastructure, from Azure Monitor, Log Analytics, and Application Insights. You can then take advantage of a unified experience both with regard to the consultation of the Alerts that for its authoring.

At present the Alerts created in Log Analytics are already listed in the Azure Monitor dashboard, but any change involves accessing to the OMS portal. To facilitate this management Microsoft has therefore decided to extend the Alerts in Log Analytics from the OMS portal to the Azure Portal. This process will be done automatically starting from 23 April 2018, will not result in any change to the configuration of Alerts and related queries, and it does not foresee any downtime for its implementation.

It follows that, after this operation, any actions associated with the Alerts will be made through Action Groups, which will be created automatically by the extension process.

The extension of Log Analytics Alerts in the Azure Portal, besides the advantage of being able to manage them from a single portal, allows you to take advantage of the following benefits:

  • There is no longer the limit of 250 Alerts.
  • You have the ability to manage, enumerate and display not only the Alerts of Log Analytics, but also those from other sources.
  • You have greater flexibility in the actions that can be undertaken against a Alerts, thanks to the use of Action Groups, such as the ability to send SMS or voice call.

If you don't want to wait for the automatic process you can force the migration via API or from the portal OMS, according to the steps later documented:

Figure 2 - Starting the "Extend into Azure" process from the OMS portal

Figure 3 – Step 1: view the details of the extension process.

Figure 4 – Step 2: summary of the proposed changes

Figure 5 – Step 3: confirmation of the extension process

Specifying an email address you can be notified at the end of the migration process, that contains the summary report.

Figure 6 - Notification of the planned extension of the Alerts

During the process of extension of Log Analytics Alerts on Azure you will not be able to make changes to existing and creating new Alerts Alerts shall be made from Azure Monitor.

At the end of the extension process the Alerts will be visible even from the OMS portal and you will receive notification via email, to the address specified during the migration wizard:

Figure 7 – Email notification at the end of the extension process

From the Azure portal, in the section “Monitor – Alerts”, you will have a full management of Log Analytics Alerts:

Figure 8 - Example of modifying an Alert Rule from the Azure Monitor

The extension of the Alerts of Log Analytics in Azure Monitor does not involve costs, but you should be aware that, the use of Azure Alerts generated by Log Analytics query, is not subject to billing only if it falls within the limits and under the conditions reported in the page of Azure Monitor costs.


Thanks to this activity of extension of Log Analytics Alerts, Azure Monitor is confirmed that it is the new management engine of all Alerts, by providing to the administrators a simple and intuitive interface and enriching the possible actions of a notification alert.

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

In March there have been several news announced by Microsoft on Operations Management Suite (OMS) and System Center. In this series of articles, which we make with monthly basis, are listed all the main innovations of the current month, accompanied by the necessary references to be able to conduct further studies.

Operations Management Suite (OMS)

Azure Automation

In Azure Automation new features have been officially released that allow you to:

  • Manage the distribution of updates (Update management).
  • Collect inventory information about the applications installed on systems (Inventory).
  • Track changes made on the machines (Change tracking).

The our article, posted in recent months, shows how to configure the Azure Automation Account to take advantage of these new features and reports the key features.

Figure 1 – Related solutions in Log Analytics

Azure Backup

Azure Backup introduces several new features that address the following aspects:

  • Large disk support: ability to protect disks of size up to 4 TB, both typologies: managed and unmanaged. The limit was previously of 1 TB.
  • Backup and Restore performance improvements: to reduce the execution time of the backup and restore will be retained snapshots, performed during the backup process, for 7 days.
  • Instant recovery point: the recovery point is made available instantly at the moment of creation of the snapshot made by the backup job, in a similar way to the checkpoint created by Hyper-V or VMware.
  • Distribute the disks of restored VM: during the restore process you are given the opportunity to choose where to place the disks unmanaged of virtual machines. This reduces the configurations, post restore activities, that would be required putting all disks within the same storage account .

To take advantage of these improvements you need to upgrade your subscription which owns the Recovery Service Vaults. The upgrade can be performed directly from the Azure Portal (there will be an appropriate notification in the dashboard of the Recovery Service vault ) or via PowerShell commands. For further information you can consult theMicrosoft's official announcement.

Figure 2 – Subscription upgrade process at the new stack

Microsoft has also announced that the Azure Backup service is now also available in the regions of Azure France (France Central and France South).


System Center

Microsoft has officialized the release of Windows Server 2019 which will be available to the public in the second half of 2018. In the same time will be made available System Center 2019 and it will have full support for Windows Server 2019 from the very first day of release.

System Center Configuration Manager

During the month has been released the version 1802 for the Current Branch (CB) of System Center Configuration Manager that introduces new features and major improvements in the product.

This summarizes the areas impacted by this update:

Modern Management

  • Endpoint Protection workload transition in co-management
  • Management insights
  • Co-management reporting

Figure 3 – Co-management reporting

Microsoft 365 Adoption

  • Phased deployments
  • Windows AutoPilot Device Information report
  • Support for Windows 10 ARM64 devices
  • Surface Device Dashboard
  • Microsoft Edge browser policies
  • Report to show default browser for client machines
  • Windows 10 Servicing for a specific collection report
  • Improvements to Office 365 client management dashboard
  • Improvements for Windows Defender Exploit Guard
  • New settings for Windows Defender Application Guard

Streamlined Infrastructure

  • Configure Windows 10 Delivery Optimization to use Configuration Manager boundary groups
  • Add management points to your boundary group fallback relationships
  • Moving Distribution Points between sites

Improvements in Cloud Management Gateway

  • Cloud management gateway support for Azure Resource Manager
  • Install user-available applications on Azure AD-joined devices
  • Windows 10 in-place upgrade task sequence over the Internet

Improvements in Software Center

  • Approve application requests for users per device
  • Improvements to client settings for Software Center

Improvements in OSD

  • Improvements to Windows 10 in-place upgrade task sequence
  • Deployment Template for Task Sequences

Miscellaneous Improvements

  • Support for hardware inventory strings greater than 255 characters in length
  • Run scripts

Figure 4 – Run Script status

To see the complete list of new features and to get more details about it you can access the Microsoft's official documentation.

The update will be made available globally in recent weeks and will be displayed in the node "Updates and Servicing" in the SCCM console. To force the availability of this update you can use this PowerShell script.

For System Center Configuration Manager has been released the version 1803 for the Technical Preview branch. In addition to general improvements in the solution are introduced useful changes that can improve the Configuration Manager infrastructure. In addition, interesting improvements have been made to the Software Center. All the new features included in this update can be found in the article Update 1803 for Configuration Manager Technical Preview Branch.

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

System Center Updates Publisher

System Center Updates Publisher (SCUP) is the Microsoft solution that allows you to manage custom third-party update. This month a new version of SCUP has been officially released and can be downloaded at this address. The new release introduces support for Windows 10 and Windows Server 2016. All details about this release can be found in the’official announcement.

System Center Operations Manager

Following, are reported the news about Management Packs of SCOM:

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 try System Center products you can access to the’Evaluation Center and after the registration you can start the trial period.

Azure SQL Database: how to manage connectivity with vNet Service Endpoints

To have more control over accesses performed on SQL Azure Database, last month, Microsoft has publicly released the option to enable Virtual Network (vNet) Service Endpoints for SQL Database. This article will explain the working principle, with resulting benefits, and it will show its configuration.

Characteristics and principles of operation

The vNet Service Endpoints for the Azure SQL Database let you isolate the logical Microsoft SQL Servers in the cloud, guaranteeing access only from one or more subnets that are defined in their own Azure Virtual Network. This feature ensures that all traffic generated by own vNet to Azure SQL Database will always remain within the network backbone of Azure. This is a feature available in all regions of Azure and there are no additional costs for using it.

Figure 1 – Summary of architecture

On the firewall of the Azure SQL Database remains the ability to enable communication from the Azure services and to filter access based on a range of Public IP address.

Figure 2 – Azure SQL Server firewall settings

By enabling the setting 'Allow access to Azure services ' you are granted to access to SQL Server from all public IP address of Azure and from all Azure subnets, including those not of your own. Going to apply additional filters based on the public IP is difficult to manage and require the configuration of static public IP addresses on the Azure resources.

With the introduction of Virtual Network (vNet) Service Endpoints for SQL Server you can have more control over potential communications and less effort for resource management. The operating principle of the vNet Service Endpoints does not extend to the on-premises world even when there is connectivity with Azure (VPN or ExpressRoute), but to allow access from on-premises systems you must continue to use firewall rules to limit connectivity only to the public IP of your membership.

The Virtual Network (vNet) Service Endpoints are available, with the same principle of operation, also for Azure Storage and for Azure SQL Data Warehouse (currently in preview).

How to configure

Enabling vNet Service Endpoints require the activation on the subnet of the virtual network of Azure, from which you plan to connect to SQL Server, of the SQL Server Endpoint (Microsoft.SQL).

Figure 3 – Enabling SQL Server Service Endpoint on the subnet

Figure 4 – SQL Server Service Endpoint successfully enabled on the subnet

Next you must add on the SQL Database side the virtual network, with the Service Endpoint enabled , in the section Firewall and virtual networks.

Figure 5 – Added Virtual Network with Service Endpoints of SQL Server enabled

Each Virtual Network Rule is applied to Azure SQL Database server level and not at the individual database level.

This configuration means that by connecting to DB hosted by the Azure SQL Server from a machine attested on a vNet with Service Endpoints enabled, will be used as the source IP an address in the address space of the vNet. This aspect has to be considered, in existing configurations, to avoid that when you enable SQL Server Service Endpoint on the subnet, blocks access to SQL Server. For this purpose it is possible to avoid it allowing temporarily access with the setting "Allow access to Azure services", or by defining the vNet in firewall rule of SQL Server before enabling the Service Endpoint on the subnet. This requires using the flag IgnoreMissingServiceEndpoint or select the following flag present in the Azure portal:

Figure 6 – Added Virtual Network without Service Endpoints of SQL Server enabled


The Virtual Network (vNet) Service Endpoints are able to expand the virtual networks of Azure and its identity to certain Azure services, as Azure SQL Server, through a direct connection. This increases the security level of the services in the Microsoft cloud, optimize routing to access resources from the Azure vNet and lessens the management effort, all with a few easy steps.

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.


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 address. 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.


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 OperationsBackup. 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.


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


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 releases in the Technical Preview Branch help you evaluate the 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.