Category Archives: Cloud

Azure Application Gateway: monitoring with Log Analytics

Azure Application Gateway is an application load balancer (OSI layer 7) for web traffic, available in Azure environment, that manages HTTP and HTTPS traffic of the applications. This article is discussed how to monitor of Azure Application Gateway using Log Analytics provides.

Figure 1 - Azure Application Gateway basic schema

Using the Azure Application Gateway you can take advantage of the following features:

  • URL-based routing
  • Redirection
  • Multiple-site hosting
  • Session affinity
  • Secure Sockets Layer (SSL) termination
  • Web application firewall (WAF)
  • Native support for WebSocket and HTTP/2 protocols

For more details on Azure Application Gateway can be found in the Microsoft's official documentation.

Configuring Diagnostics logs for the Application Gateway

The Azure Application Gateway can send diagnostic logs to a workspace of Log Analytics . This feature is very useful for checking the performance, to detect any errors and is essential for troubleshooting steps, in particular in the presence of the WAF module. To enable the diagnostic from the Azure portal you can select the Application Gateway resource and go to the "Diagnostics logs":

Figure 2 – Starting configuration of Diagnostics logs

Figure 3 – Configuring Diagnostics logs

After choosing your Log Analytics workspace where to send diagnostics data, in the Log section, you can select which type of log collecting among the following:

  • Access log (ApplicationGatewayAccessLog)
  • Performance log (ApplicationGatewayPerformanceLog)
  • Firewall log (ApplicationGatewayFirewallLog): these logs are generated only if the Web Application Firewall is configured on the Application Gateway.

In addition to these logs are also collected by default Activity Log generated by Azure. These logs are maintained for 90 days in the store of the Azure event logs. For more details you can refer this specific document.

Azure Application Gateway analytics solution of Log Analytics

Microsoft offers the solution Azure Application Gateway analytics that can be added to the workspace of Log Analytics by following these simple steps:

Figure 4 - Launching the procedure of adding the solution to the OMS workspace

Figure 5 – Selection of the Azure Application Gateway analytics solution

Figure 6 - Addition of the solution in the selected workspace

After enabling the sending of diagnostics logs into the workspace of Log Analytics and adding the solution to the same, by selecting the tile Azure Application Gateway analytics in the Overview page, you can see an overview of the collected log data from the Application Gateway:

Figure 7 – Screen overview of the Azure Application Gateway analytics solution

You can also view the details for the following categories.

  • Application Gateway Access logs:
    • Client and server errors for Application Gateway access logs
    • Requests per hour for each Application Gateway
    • Failed requests per hour for each Application Gateway
    • Errors by user agent for Application Gateways

Figure 8 - Screenshot of the Application Gateway Access logs

  • Application Gateway performance:
    • Host health for Application Gateway
    • Maximum and 95th percentile for Application Gateway failed requests

Figure 9 – Screenshot of the Application Gateway performance

Customized dashboard of Log Analytics for the Application Gateway monitor

In addition to this solution can also be convenient to use a special dashboard of Log Analytics, specifically for the monitoring of the Application Gateway, available at this link. The deployment of the dashboard is via ARM template and requires also in this case the Diagnostics logs of the Application Gateway enabled, as described above. The various queries of Log Analytics, used by the dashboard, are documented in this blog. Thanks to these queries the dashboard shows several additional information exposed by the diagnostic of the Application Gateway.

Figure 10 – Custom dashboard of Log Analytics for Application Gateway monitoring

Query of Log Analytics to monitor the Firewall Log

Using the solution Azure Application Gateway analytics of Log Analytics or the custom dashboard (stated in the previous paragraph) are not contemplated at the time the Firewall log, generated when is active the Web Application Firewall (WAF) on the Application Gateway. The WAF is based on rules of OWASP Core Rule Set 3.0 or 2.2.9 to intercept attacks, for the web applications, that exploit the known vulnerabilities. To name a few, we find for example the SQL injection and attacks cross site scripting.

In this case, if you decide to check the Firewall log, you must directly query the Log Analytics, for example:

Figure 11 – The Query to retrieve blocked requests by the WAF module, over the past 7 days, for a specific URI, divided by RuleID

To see the list of rules of the WAF, by associating the RuleId to its description, you can consult this document.

The descriptive message of the rule is also listed within the results returned by the query:

Figure 12 – The Query to retrieve blocked requests by the WAF module, over the past 7 days, for a specific URI and for a specific RuleId

Conclusions

In my experience, in Azure architectures that require secure publishing of web services to Internet, is often used Azure Application Gateway service with the WAF module active. With the ability to send diagnostic logs of this component to Log Analytics you have the option of having a qualified monitor, that is fundamental to analyse any error conditions and to assess the state of the component in all its facets.

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

In June have been announced, by Microsoft, a considerable number of news about Operations Management Suite (OMS) and System Center. Our community, through these articles released monthly, want to provide an overview of the main news of the month, in order to stay up to date on these arguments and have the necessary references for further information.

Operations Management Suite (OMS)

Log Analytics

Recently it was officially announced that the OMS portal will be deprecated, in favour of the Azure Portal. In this article are examined the aspects related to this change and what you should know to avoid being caught unprepared.

Figure 1 - Notifications in the OMS portal

Azure Backup

Azure Backup is enriched with an important new feature that allows you to natively protect SQL workload, running in IaaS virtual machines that reside in Azure. In this article are showed the benefits and the characteristics of this new feature.

Figure 2 – Protection of SQL Server on Azure VMs with Azure Backup

Released an updated version of the’Azure Backup agent (MARS), which can be obtained by accessing this link.

Using Azure Backup there is the possibility of generating the reports needed to be able to easily check the status of resource protection, details on the different backup jobs configured, the actual storage utilization and status of its alert. All this is made possible by using Power BI, allowing you to have a high degree of flexibility in the generation and customization of reports. In this video, recently published, there is show how to configure a Power BI workspace for sharing reports of Azure Backup within your organization. To analyze the steps required to configure the reporting of Azure Backup you can refer this article.

Figure 3 – Sharing PowerBI reports of Azure Backup

Azure Backup introduces the ability to protect workloads running on Azure Stack environment. The tenant who use the Azure Stack solution can then have a short term protection directly on the Azure Stack environment and can make use of Azure Recovery Service vault for long term retention and to perform offsite. For more details on this you can consult therelease announcement.

Figure 4 – Azure Stack Tenant backup with Microsoft Azure Backup Server

Azure Site Recovery

In Azure Site Recovery (ASR) was announced in "general availability (GA)" the ability to configure the Disaster Recovery (DR) of Azure Virtual Machines. Configuring the replication of virtual machines in different regions of Azure, you have the ability to make applications resilient to a fault affecting a specific Azure region. This feature is available in all the Azure regions where you can use ASR. Azure is the first public cloud to offer a native solution for Disaster Recovery for applications that run in IaaS.

During the preview, Microsoft has taken into account the different feedback from the customers and added to the solution, the following import capabilities:

We highlight these useful references regarding this solution:

Security and Audit

The solution Azure Network Security Group Analytics will be replaced by Traffic Analytics that was released in General availability (GA). This solution, fully cloud-based, allows you to have an overall visibility on network activities that are undertaken in the cloud environment. For more details about you can see "How to monitor network activities in Azure with Traffic Analytics"

System Center

System Center Data Protectrion Manager

In environments where System Center Data Protection Manager (SCDPM) is connected to Azure Backup service was introduced the ability to view all the items protected, details on the use of storage and information about the recovery points, direct from the Azure Portal, within the Recovery Service vault. This feature is supported for SCDPM 2012 R2, 2016 and for Azure Backup Server v1 and v2, as long as you have the latest version of Azure Backup Agent (MARS).

Figure 5 – Information from DPM outlined in Recovery Service vault

System Center Configuration Manager

It is usually released a technical preview per month in Configuration Manager, but this month, due to the considerable number of new features, they were released two.

The first is the version 1806 for the Technical Preview branch of System Center Configuration Manager. The main innovation introduced by this update is the addition of support for third-party software update catalogs. From the Configuration Manager console, you can easily subscribe to third-party software update catalogs, then publish updates via Software Update Point. These updates will be issued to the client by using the classic method of Configuration Manager to deploy software update.

Figure 6 – Access to third-party software update catalogs from the SCCM console

In addition to this new feature were released updates on:

  • Sync MDM policy from Microsoft Intune for a co-managed device
  • Office 365 workload transition in co-management
  • Configure Windows Defender SmartScreen settings for Microsoft Edge
  • Improvements to the Surface dashboard
  • Office Customization Tool integration with the Office 365 Installer
  • Content from cloud management gateway
  • Simplified client bootstrap command line
  • Software Center infrastructure improvements
  • Removed Network Access Account (NAA) requirement for OSD Boot Media
  • Removed Network Access Account (NAA) requirement for Task Sequences
  • Package Conversion Manager
  • Deploy updates without content
  • Currently logged on user information is shown in the console
  • Provision Windows app packages for all users on a device

The second is the version 1806.2 for the Technical Preview branch of System Center Configuration Manager, that mainly includes the following news related to the Phased deployment:

  • Ability to monitor the status natively, from the Deployments node.
  • Ability to create Phased deployment of applications and not just for task sequences.
  • Ability to carry out a gradual rollout during the deployment phase.

Also this preview contains updates regarding:

  • Management Insights for proactive maintenance
  • Mobile apps for co-managed devices
  • Support for new Windows app package formats
  • New boundary group options for optimized P2P behaviors
  • Third-party software updates support for custom catalogs
  • Compliance 9 – Overall health and compliance (Report)

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.

System Center Operations Manager

Released an updated version of the Management Pack for OS Windows Server 2016 and 1709 Plus which includes several updates and issues resolutions. For further information you can consult this article.

Released the version 8.2 of the MP Author that includes several improvements. For a list of what's new in this version you can see theofficial announcement of the release.

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.

The management of Log Analytics from the Azure portal

For some time, Microsoft has started a process that led to bundle several features and settings of OMS Log Analytics in the Azure portal. Recently it was officially announced that the OMS portal will be deprecated, in favour of the Azure Portal. This article will examine aspects related to this change and what you should know to avoid being caught unprepared.

The choice to leave the OMS portal, in favour of the Azure Portal, was made in order to provide a unique user experience to monitor and manage the systems, regardless of their location (on-premises or on Azure). Thanks to the Azure portal you can browse and manage all Azure services and soon you will also have complete control over OMS Log Analytics. The expectation is that the gap currently present between the two portals is finally filled by the end of summer and short Microsoft will announce the date for the final disposal of the OMS portal.

Figure 1 - Notifications in the OMS portal

Figure 2 – Overview of Log Analytics in the Azure Portal

What does this change?

The disposal of the OMS portal, in addition to a noticeable change in user experience, also entails a change in the use of Log Analytics to aspects reported below.

Management of alerts

Instead of using the Alert management solution of Log Analytics you must use Azure Monitor, in addition to allowing you to monitor all Azure borne resources, also holds the "alerting" engine for the entire cloud platform. The article "The extension of Log Analytics Alerts in Azure Monitor"introduces the new management of the Alerts in Log Analytics and the benefits introduced by this evolution.

Access Permissions for the portal

Access management in the Azure Portal, based on role-based access control (RBAC), is definitely more flexible and powerful than the one in the OMS portal. Azure provides these two default built-in user roles for Log Analytics:

  • Log Analytics Reader
  • Log Analytics Contributor

For details regarding access management of Log Analytics from the Azure portal you can consult this documentation. Starting from 25 June will start the automatic conversion process, during which each user or security group present in the OMS portal will be reported with the appropriate role in the Azure Portal, according to the following association:

Figure 3 - Association between OMS portal permissions and Azure roles

Mobile App

As for the portal OMS, even the OMS mobile app will be deprecated. In its place you can access to the Azure portal directly from the mobile browser, waiting for future extensions of the Azure Mobile App. To receive notifications on mobile devices, when alerts are generated, you can use Azure Action Groups.

Application Insights Connector

TheApplication Insights Connector is used to return the data of Application Insights inside the workspace of Log Analytics. This connector is no longer needed and will be deprecated, from November of this year, given that the same functionality can be achieved using cross-resource queries.

Azure Network Security Group Analytics

The solution Azure Network Security Group Analytics will be replaced by Traffic Analytics, accessible only from the Azure Portal. For more details on this new tool you can refer to the article "How to monitor network activities in Azure with Traffic Analytics"

 

Current gap in the Azure portal

To date it is imposed the use the OMS portal, for who uses the following solutions, as they are not totally usable in the Azure Portal:

Microsoft is working to update this solutions and make them available using the Azure Portal. To stay up to date on changes about this you can refer to the page Azure Updates.

 

Considerations

To manage Log Analytics should be used the Azure portal since today, which enables new tools, to benefit from the better experience offered, and to take advantage of the portal's features, as the dashboards, searches, and tagging for resource management. The OMS portal will be disposed soon, but it can still be required if you need to use the solutions not yet compatible (above reported), waiting for their upcoming update that will make them fully functioning with the Azure Portal.

Azure Backup: the protection of SQL Server in Azure Virtual Machines

Azure Backup is enriched with an important new feature that allows you to natively protect SQL workload, running in IaaS virtual machines that reside in Azure. In this article we will explore the benefits and the characteristics of this new feature.

Figure 1 - Protection with Azure backups of SQL Server in Azure VMs

Azure Backup has always been with an approach cloud-first allowing you to protect your systems quickly, safe and effective. The SQL Server protection in Azure IaaS virtual machines provides the only solution of its kind, characterised by the following elements:

  • Zero-backup infrastructure: you do not need to maintain a classic backup infrastructure, composed from the backup server, by various agents installed on systems and storage that host backups. Furthermore, nor is it required to use backup scripts, often needed in other backup solutions, to protect SQL Server.
  • Monitor backups by Recovery Services Vault: Using the dashboard, you can easily and intuitively monitor various backup jobs for all types of workloads protected: Azure IaaS VMs, Azure Files and SQL server databases. You can also set up email notifications against unsuccessful backup or restore.
  • Centralized management: you have the option to configure common protection policy, usable for databases residing on separate servers, where is defined the scheduling and the retention for short-term and long-term backup.
  • Restore DB to a precise date and time: an intuitive graphical interface allows the operator to restore the most appropriate recovery point for the selected date. Azure Backup will take care of managing the restoration of full backups, differential and log backup chain in order to get the database at the selected time.
  • Recovery Point Objective (RPO) of 15 minutes: You can back up the transaction log every 15 minutes.
  • Pay as you go service (PAYG): billing takes place monthly on the basis of consumption and there are no upfront costs for the service.
  • Native integration with SQL Server APIs: Azure Backup invokes the native APIs of the solution to ensure a high efficiency and reliability of the operations performed. Backup jobs can be viewed using SQL Server Management Studio (SSMS).
  • Support for Always On Availability Group: the solution is able to back up databases that reside within an Availability Group (AG), ensuring the protection in case of failover events, honoring the preference backup set at the AG level.

This new feature supports the following versions of the operating system and SQL Server, independently that are VMs are generated by a marketplace image or less (SQL Server installation done manually).

Supported operating systems

  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016

Linux, at the moment, is not supported.

Supported SQL Server VersionsEditions

  • SQL 2012 Enterprise, Standard, Web, Developer, Express
  • SQL 2014 Enterprise, Standard, Web, Developer, Express
  • SQL 2016 Enterprise, Standard, Web, Developer, Express
  • SQL 2017 Enterprise, Standard, Web, Developer, Express

To take advantage of this feature, the following requirements must be met:

  • Have a Recovery Services vault in the same region where resides the Azure virtual machine hosting SQL databases to be protected.
  • The virtual machine with SQL Server need connectivity to Azure public IPs.
  • On the virtual machine that holds the databases to be protected must be present specific settings. Azure Backup requires the presence of the VM extension AzureBackupWindowsWorkload. This extension is installed in the virtual machine during the process of discovery and enables communication with Azure Backup. The extension installation involves the creation in the VM, by Azure Backup, of the Windows virtual service account named NT Service AzureWLBackupPluginSvc. This virtual service account needs permissions of log in and sysadmin on SQL side, to protect your databases.

To enable the backup of SQL workloads in virtual machine in Azure it is necessary to carry out a process of discovery and later you can configure the protection.

Discovery process

This paragraph shows the procedure to be followed, by accessing the Azure Portal, to enable discovery of databases:

Figure 2 – Initiation of the discovery process

Figure 3 – Discovery in progress

Figure 4 – Discovery of DBs on selected systems

 

Configuring SQL backup

After the discovery phase of the the databases you can proceed with the configuration of SQL Server backup.

Figure 5 - Start the backup configuration, post DBs discovery inside the VMs

Figure 6 – Selection of DBs to be protected

Figure 7 – Creation of the policy that defines the type of SQL backup and data retention

Figure 8 – Enabling backup

 

Backup monitor and restore process

Figure 9 – Dashboard of the Recovery Service vault

Figure 10 - Number of backup items of SQL in Azure VMs

Figure 11 – SQL backup status

By selecting the single DB you can start the restore process.

Figure 12 - Starting the restore process of the DB

Figure 13 – Selecting the destination where to restore the DB

Figure 14 – Selecting the restore point to use

Figure 15 – Restore settings and directories where to place the files

Figure 16 – Starting the restore job

 

The Cost of the Solution

The cost for the protection of SQL Server in Azure Backup is calculated on the number of instances protected (individual Azure VMs or Availability Groups). The cost of a single protected instance depends on the size, which is determined by the overall size of the various protected DBs (without considering the amount of compression and encryption). At this cost it has to be added the cost of Azure storage actually consumed. This is Block Blob Storage including locally redundant storage (LRS) or geo-redundant storage (GRS). For more details on costs please visit the Microsoft's official page.

 

Conclusions

Azure Backup is enhanced with an important feature and confirms to be a great enterprise solution for systems protection, wherever they are. With this feature, Azure differs from any other public cloud, providing a solution for the protection of SQL Server in IaaS virtual machines, totally integrated into the platform. For more information on Azure Backup solution you can consult the official documentation.

Everything you need to know about new Azure Load Balancer

Microsoft recently announced the availability in Azure of Standard Load Balancer. They are load balancers Layer-4, for TCP and UDP protocols that, compared to Basic Load Balancer, introduce improvements and give you more granular control of certain features. This article describes the main features of the Standard Azure Load balancers, in order to have the necessary elements to choose the most suitable type of balancer for your needs.

Any scenario where you can use the SKU Basic of Azure Load balancers, can be satisfied using the Standard SKU, but the two types of load balancers have important differences in terms of scalability, functionality, guaranteed service levels and cost.

Scalability

The Standard Load balancers have higher scalability, compared to Basic Load Balancer, as regards the maximum number of instances (IP Configuration) that can be configured in the backend pool. The SKU Basic allows you to have up to 100 instances, while using the Standard SKU the maximum number of instances is equal to 1000.

Functionality

Backend pool

With regard to the Basic Load Balancer, in the backend pool, can reside exclusively:

  • Virtual machines that are located within an availability set.
  • A single standalone VM.
  • Virtual Machine Scale Set.

Figure 1 – Possible associations in the Basic Load Balancer backend pool

In Standard Load Balancer instead, it is allowed to enter into backend pool any virtual machine attested on a particular virtual network. The integration scope, in this case, is not in fact the availability set, as for the Basic load balancer , but it is the virtual network and all its associated concepts. A requirement to consider, in order to insert into the backend pool of Standard Load Balancer the virtual machines, is that these should not have associated public IP or must have Public IP with Standard SKU.

Figure 2 Standard Load Balancer backend pool association

Availability Zones

Standard Load Balancers provide integration scenarios with Availability Zones, in the regions that include this feature. For more details you can refer this specific Microsoft document, that shows the main concepts and implementation guide lines.

Ports High Availability

The load balancers with Standard SKU, of type "Internal", allow you to balance the TCP and UDP flows on all ports simultaneously. To do that, in the rule of load-balancing, there is the possibility to enable the "HA Ports" option:

Figure 3 - Configuring the load balancing rule with "HA Ports" option enabled

The balancing is done for flow, which is determined by the following elements: source IP address, source port, destination IP address, destination port, and protocol. This is particularly useful in scenarios where are used Network Virtual Appliances (NVA's) requiring scalability. This new feature improves the tasks that are required for NVAs implementations.

Figure 4 - Network architecture which provides the use of LB with "HA Ports" option enabled

Another possible use for this feature is when you need to balance a large number of ports.

For more details on the option "HA Ports" you can see the official documentation.

Diagnostics

Standard Load Balancer introduce the following features in terms of diagnostic capability:

  • Multi-dimensional metrics: You can retrieve various metrics that allow you to see, in real time, usage status of load balancer, internal and public. This information is particularly useful for troubleshooting.

Figure 5 – Load Balancer metrics from the Azure Portal

  • Resource Health: in Azure Monitor you have the opportunity to consult the health status of Standard Load Balancer (currently only available for Standard Load Balancer, type Public).

Figure 6 – Resource health of Load Balancer in Azure Monitor

You can also consult the history of the health state :

Figure 7 – Health history of Load Balancer

All details related to diagnostics, of the Standard Load Balancer, can be found in the official documentation.

Security

The Load Balancer with standard SKU are configured to be secure by default in fact, in order to operate, you must have a Network Security Group (NSG) where the traffic flow is explicitly allowed. As previously reported, the Load Balancer standards are fully integrated into the virtual network, which is characterized by the fact that it is private and therefore closed. The Standard Load Balancer and the public Standard IP are used to allow the access to the virtual network from outside and now by default you must configure a Network Security Group (closed by default) to allow the desired traffic. If there is no a NSG, on the subnet or on the NIC of the virtual machine, you will not be allowed the access by the network stream from the Standard Load Balancer.

The Basic Load Balancers by default are opened and the configuration of a Network Security Group is optional.

Outbound connections

The Load Balancer on Azure support both inbound and outbound connectivity scenarios. The Standard Load Balancer, compared to the Load Balancer Basic, behave differently with regard to outbound connections.

To map the internal and private IP address of the virtual network to the public IP address of the Load Balancer it uses the Source Network Address Translation technique (SNAT). The Load Balancer Standard introduce a new algorithm to have stronger SNAT policies, scalable and accurate, that allow you to have more flexibility and have new features.

Using the Standard Load Balancer you should consider the following aspects with regard to outbound scenarios:

  • Must be explicitly created to allow outgoing connectivity to virtual machines and are defined on the basis of incoming balancing rules.
  • Balancing rules define how occur the SNAT policies.
  • If there are multiple frontend, It uses all the frontend and for each of these multiply the preallocated SNAT ports available.
  • You have the option to choose and control whether a specific frontend you don't want to use for outbound connections.

Basic Load Balancers, in the presence of more public frontend IP, it is selected a single frontend to be used in outgoing flows. This selection can not be configured and occurs randomly.

To designate a specific IP address, you can follow the steps in this section of the Microsoft documentation.

Management operations

Standard Load balancers allow enabling management operations more quickly, much to bring the execution times of these operations under 30 seconds (against the 60-90 seconds to the Load Balancer with Basic SKU). Editing time for the backend pools are also dependent on the size of the same.

Other differences

At the moment, Public Standard Load Balancer cannot be configured with a public IPv6 address:

Figure 8 – Public IPv6 for Public Load Balancer

Service-Level Agreements (SLA)

An important aspect to consider, in choosing the most appropriate SKU for different architectures, is the level of service that you have to ensure (SLA). Using the Standard Load Balancer ensures that a Load Balancer Endpoint, that serve two or more instances of health virtual machines, will be available in time with an SLA of 99.99%.

The Load Balancer Basic does not guarantee this SLA.

For more details you can refer to the specific article SLA for Load Balancer.

 

Cost

As for Basic Load Balancer are not expected cost, for Standard Load Balancer there are usage charge provided on the basis of the following elements:

  • Number of load balancing rules configured.
  • Number of inbound and outbound data processed.

There are no specific costs for NAT rules.

In the Load Balancer cost page can be found the details.

 

Migration between SKUs

For Load Balancer is not expected to move from the Basic SKU to the Standard SKU and vice versa. But it is necessary to provide a side-by-side migration, taking into consideration the previously described functional differences.

Conclusions

The introduction of the Azure Standard Load Balancer allows you to have new features and provide greater scalability. These characteristics may help you avoid having to use, in specific scenarios, balancing solutions offered by third party vendors. Compared to traditional Load balancers (Basic SKU) change operating principles and have distinct characteristics in terms of costs and SLAS, this is good to consider in order to choose the most suitable type of Load Balancer, on the basis of the architecture that you must accomplish.

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

Compared to what we were used to seeing in recent months, in the month of may, have been announced by Microsoft a few news about Operations Management Suite (OMS) and System Center. This article will summarize bringing the references needed to conduct further studies.

Operations Management Suite (OMS)

Log Analytics

Microsoft announced the retirement, starting from 8 June 2018, of the following solutions:

This means that, as of this date, you can no longer add this solutions in the Log Analytics workspaces. For those who are currently using it, is appropriate to consider that the solution will still work, but will be missing its support and will not be released new updates.

In this article are reported some important recommendations that should be followed when using the operators "Summarize" and "Join" in Log Analytics and Application Insights query. It is recommended to adjust the syntax of any existing query, using these operators, to comply with the specifications given in the article.

Security and Audit

It should be noted this interesting article where it is shown how you can detect and investigate unusual and potentially malicious activities using Azure Log Analytics and Security Center.

Azure Site Recovery

Microsoft has announced that the following versions of the REST API of Azure Site Recovery will be deprecated since 31 July 2018:

  • 2014-10-27
  • 2015-02-10
  • 2015-04-10
  • 2015-06-10
  • 2015-08-10

You will need to use at least version API 2016-08-10 to interface with Azure Site Recovery. This type of change has no impact on the portal of Azure Site Recovery and to the solution access via PowerShell.

System Center

System Center Orchestrator

The Integration Packs of Orchestrator, version 7.3 for System Center 2016, have been released.
The download can be done at this link and includes the following components:

  • System Center 2016 Integration Pack for System Center 2016 Configuration Manager.
  • System Center 2016 Integration Pack for System Center 2016 Data Protection Manager.
  • System Center 2016 Integration Pack for System Center 2016 Operations Manager.
  • System Center 2016 Integration Pack for System Center 2016 Service Manager.
  • System Center 2016 Integration Pack for System Center 2016 Virtual Machine Manager.

These Integration Packs allow you to develop automation, interfacing directly with the other components of System Center. The Integration Pack for System Center 2016 Operations Manager has been revised to require no more the presence of the Operations Manager console to function correctly.

System Center Operations Manager

Following, are updates released for Operations Manager Management Packs:

  • Active Directory Federation Services version 10.0.1.0
  • Active Directory Federation Services 2012 R2 version 7.1.10100.1

System Center Service Management Automation

Service Management Automation sees the release ofUpdate Rollup 5. Among the issues addressed are:

  • Runbooks that, using cmdlets of System Center 2016 Service Manager, fail with the error "MissingMethodException".
  • Runbooks that fail with the exception "unauthorized access".

Improvements have also been made in the debug logging.

To see the complete list of issues and the details on how to upgrade, you can access to the specific knowledge base.

 

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

Conclusions

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 create a Docker environment in Azure using VM Extension

Docker is a software platform that allows you to create, manage and execute isolated applications in containers. A container is nothing more than a methodology for creating software packages in a format that allows it to be run independently and isolated on a shared operating system. Unlike the virtual machine containers do not include a complete operating system, but only the libraries and settings needed to run the software. Therefore there are a series of advantages in terms of size, speed, portability and resource management.

Figure 1 – Diagram of containers

 

In the world of Microsoft Azure there are different configuration and use possibilities about Docker containers that I list synthetically:

  • VM Extension: through a specific Extension you can implement Docker inside a virtual machine.
  • Azure Container Service: deploys quickly into a cluster environment Azure Docker Swarm, DC/OS or Kubernetes ready for production. This is the most complete solution for the orchestration of containers.
  • Docker EE for Azure: is a template available on the Azure Marketplace, a collaboration between Microsoft and Docker, which makes it possible to provision a clustered Docker Enterprise Edition integration with Azure VM Scale Sets, the Azure Load balancers and the Azure Storage.
  • Rancheros: is a Linux distribution designed to run containers available as template within the Marketplace Azure Docker.
  • Web App for Containers: you have the option of using containers, making the deployment in the Azure App Service managed platform as a Web App running in a Linux environment.
  • Azure Container Instances (currently in preview): is definitely the easiest and quickest way to run a container Docker in the Azure platform, without the need to create virtual machines, ideal in scenarios where containers blocks.
  • Azure Service Fabric: supports the containers in both the Windows and Linux. The platform contains natively support for Docker Wrote (currently in preview), allowing you to orchestrate applications based on containers in the Azure Service Fabric.
  • DC/OS on Azure: This is a managed cloud service that provides an environment for the deployment of workloads in cluster using DC/OS platform (Datacenter Operating System).

All these possibilities enable, according to the needs and to the scenario that you must implement, choosing the most appropriate deployment methodology in the container for execution environment Azure Docker.

In this article we will create a Docker environment in a Virtual Machine using the Docker Extension. Starting from a virtual machine in Azure, you can add the Docker Extension which installs and configures the daemon Docker, the client Docker and Docker Wrote.

This extension is supported for the following Linux distributions:

  • Ubuntu 13 or higher.
  • CentOS 7.1 or higher.
  • Red Hat Enterprise Linux (RHEL) 7.1 or higher.
  • CoreOS 899 or higher.

Adding the extension from the Azure Portal can be done via the following steps. The section Extensions Select the virtual machine button Add:

Figure 2 – Adding Extensions to the VM from the Azure Portal

 

Then shows the list of Extensions available, you stand onExtension Docker and press the button Create.

Figure 3 – Selection of Extension Docker

 

To enable secure communication with the Docker system implemented in your Azure environment you should use certificates and keys issued by a trusted CA. If you do not have a CA to generate these certificates you can follow the instructions in section Create a CA, Server and client keys with OpenSSL present in the official documentation of Docker.

 

Figure 4 – Communication scheme docker by encrypted protocol TLS

 

The Extension wizard requires first to enter the communications port of the Engine Docker (2376 is the default port). Also the CA's certificate is requested, your Server certificate and Server Key, in base64-encoded format:

Figure 5 – Parameters required by the wizard to add the Docker VM Extension

 

Adding the Extension Docker takes several minutes at the end of which the virtual machine will be installing the latest stable version of Docker Engine and daemon Docker will listen on the specified port using certificates entered in the wizard.

Figure 6 – Details of the Extension Docker

 

In case you need to allow Docker communication from outside the vNet where is attested the VM with Docker you must configure appropriate rules in Network Security Group used:

Figure 7 – Configuration example NSG to allow communication Docker (door 2376)

 

At this point the Docker environment is ready to be used and from a remote client you can start the communication:

Figure 8 – Docker command run from a remote client to retrieve information

 

Conclusions

The Azure Docker VM extension is ideal to implement easily, in a reliably and securely mode, a dev or production Docker environment on a single virtual machine. Microsoft Azure offers a wide range of possibilities in the choice of implementation related to the Docker platform, with a lot of flexibility by letting you choose the most appropriate solution for your needs.

Azure Multi-Factor Authentication: Introduction to Solution

To help secure access to critical data and applications may be necessary to provide multifactor authentication which generally requires the use of at least two of the following test methods:

 

  • Something you know (typically a password).
  • Something that you own (a unique device and not easily duplicable, such as a phone).
  • A biometric recognition system that aims to identify a person based on one or more biological or behavioral characteristics (Biometrics).

 

Microsoft allows you to adopt a two-factor authentication solution using theAzure Multi-Factor Authentication (MFA) which provides for the adoption of a second method of verifying during the authentication process. Using this solution can be configured the following additional authentication factors:

 

  • Phone call: a call is made to the phone registered to users. In this case the user will be prompted to answer the call and to verify that you can access by pressing the button # or entering a PIN code.
  • Text message (SMS): is sent to the user's mobile phone an SMS that contains a pin code of 6 figures who must be entered during the authentication process.
  • Notified by Mobile App: the user's smartphone is sent through Mobile App a challenge that must be approved by the user to complete the authentication process.
  • Verification code via Mobile App: in this user's smartphone Mobile App generates a code of 6 digits each 30 seconds. The user would then put the latest code at the time that authenticates.
  • Party OATH token: There is the possibility to configure Azure Multi-Factor Authentication to accept verification methods provided by third-party solution.

 

The Azure Multi-Factor Authentication (MFA) provides for two possible deployment models:

 

  • MFA as a solution entirely in the Cloud.
  • MFA system installed and configured on-premises systems.

 

To locate the most appropriate deployment model you need to consider several aspects: What I'm putting in security, where are the users who need access to your solution and what features I really need.

 

What you are trying to protect?

This is the first question you should ask yourself whose answer we can already point to a specific deployment template. If indeed there is a need to enable the dual factor authentication for IIS applications that are not published by Azure App Proxy or remote access solutions (VPN or Remote Desktop Gateway) You must use the server Azure MFA implemented on-premises systems.

 

Figure 1 – What is secured by MFA

 

Where the users are located?

Another important aspect to consider is where the users are located on the basis of the Identity model adopted, come mostra la figura 2.

 

Figure 2 – Location of users

 

What features are needed?

Depending on the type of deployment selected (MFA in the cloud or local MFA) different capabilities that we could opt for a choice rather than another, come mostra la figura 3.

 

Figure 3 Available in two models – MFA

 

Requirements for the use of MFA

In order to use the Azure Multi-Factor Authentication (MFA) You must have access to a subscription Azure. If you want to test your service you can possibly use a trial subscription of Azure.

 

The hardware requirements as regards Multi-Factor Authentication Server Azure are minimal (200 MB disk space and 1 GB RAM), While the following software features:

 

  • Operating System: Windows Server 2008 R2 or higher
  • Microsoft .NET 4.0 Framework
  • IIS 7.0 or higher if you want to install the User Portal or the Web Service SDK

 

Each server MFA must be able to communicate on port 443 outbound to the following web address:

 

  • HTTPS://pfd.phonefactor.net
  • HTTPS://pfd2.phonefactor.net
  • HTTPS://css.phonefactor.net

 

Also if there are firewall policy to block outbound to the door 443 You must open the IP address range are documented in section "Azure Multi-Factor Authentication Server firewall requirements"the Microsoft's official documentation.

 

Azure Multi-Factor Authentication in the cloud

Enabling MFA cloud scenario is very simple and is done per user. To do so you need to access the service Azure Active Directory, figura 4, from the Azure Portal:

 

Figure 4 – Step 1: enabling MFA to the cloud

 

After selecting the Directory, in the "Users and groups" select "Multi-Factor Authentication":

 

Figure 5 – Step 2: enabling MFA to the cloud

 

You will be redirected to another website where selecting the specific user, figura 6, You can enable the MFA:

 

Figure 6 – Step 3: enabling MFA to the cloud

 

At this point the user is mail-enabled MFA. The same thing can also be done by selecting multiple users simultaneously and by the same portal you can configure various settings of Azure Multi-Factor Authentication. For more details about I invite you to consult Microsoft's official documentation.

 

The same thing can be accomplished by using the cmdlets PowerShell for Azure to which allow us to easily make enabling MFA to more users with just a few lines of code, as shown in the following example:

 

$users = “user1@ugisystemcenter.org”,”user2@ugisystemcenter.org”,”user3@ugisystemcenter.org”

foreach ($user $users)

{

$St = New-Object-TypeName Microsoft StrongAuthenticationRequirement. Online. Administration.

$St. Relyingparty = “*”

$St. State = "Enabled"

$is = @($St)

$User-StrongAuthenticationRequirements-MsolUser-UserPrincipalName $sta set

}

 

Azure Multi-Factor Authentication on-premises

On-premises deployment of Azure Multi-Factor Authentication Server requires you to download the setup installer direct from the Azure Portal. If you want to dismiss Azure Multi-Factor Authentication as a standalone service with user authentication and billing options you need to create a new Classic Azure Portal Multi-Factor Auth Provider (This feature will soon be available on the new Azure Portal).

 

Figure 7 — Creating new Multi-Factor Auth Providers

 

By selecting the button Manage you will be redirected towards the Azure Portal Multi-Factor Authentication, figura 8, from where can I donwload the setup and build the service activation credentials.

 

Figure 8 – Multi-Factor Authentication Server downloads and generation credentials

 

If you want to use the bundled license to Enterprise Mobility Suite, Azure to Premium or Enterprise Cloud Suite is not necessary to create a Multi-Factor Auth Provider but simply log into the Azure Portal Multi-Factor Authentication to directly download the setup.

 

After coming into possession of the setup you can install the Azure MFA Server. During setup you will be asked only the installation path, figura 9.

 

Figure 9 – Setup Azure MFA Server

 

Figure 10 – Setup Azure MFA Server

 

At this point you must run on Multi-Factor Authentication Server you just installed that will guide us in the activation process.

 

Figure 11 – Applying Multi-Factor Authentication Server

 

Figure 12 – Step 1: How to activate Multi-Factor Authentication Server

 

On the following screen you must enter the logon credentials that are generated by the Azure Portal Multi-Factor Authentication (see Figure 8).

 

Figure 13 – Step 2: How to activate Multi-Factor Authentication Server

 

After completing the first server Configuration Wizard cannot start Azure MFA, figura 14, to enable replication across multiple servers highly available service and configure the MFA Azure.

 

Figure 14 Multi-server MFA – Configuration Wizard

 

In the scenario where the Multi-Factor Authentication Server is enabled on multiple systems, the servers communicate with each other via RPC calls MFA Azure and to make sure that everything happens safely must authenticate with each other. This authentication process can occur either through specific security group membership in Active Directory (named Phone Factor Admins) is through the use of SSL certificates.

 

Now that you have configured the server Azure MFA there is the ability to easily import users from Active Directory, figura 15, and enable the desired authentication dual factor.

 

Figure 15 -Import users from Active Directory

 

In the scenario of use of Azure Multi-Factor Authentication (MFA) Server is good to specify that user data is saved on-premises systems and no data is stored permanently on the cloud. In fact, when a user places the process of multi-factor authentication the server Azure MFA sends the following data to the Azure Cloud service MFA to verify and reporting purposes:

 

  • Unique ID of the user (username or internal MFA server ID)
  • Name and surname (Optional)
  • Email Address (Optional)
  • Phone number (in the case of a telephone call or send SMS)
  • Token device (When using authentication via mobile app)
  • Authentication method
  • Authentication result
  • Name and IP address of the server Azure MFA
  • Client IP (If available)
  • Result verification (success or denied) and motivation if deny

 

In addition to targeted different import users from Active Directory on which you want to enable the dual factor authentication you can integrate with the Active Directory Directory service server Azure MFA and set up a targeted and scheduled import of users according to certain criteria. For details please visit the official documentation Directory integration between Active Directory and server Azure MFA.

 

Solution Licensing models

Azure Multi-Factor Authentication is available as standalone service, with user authentication and billing options, or in bundle with Azure Ad Premium, Enterprise Mobility Suite and Enterprise Cloud Suite. Azure Multi-Factor Authentication is available through a Microsoft Enterprise agreement, the Open Volume License program, the program Cloud Solution Provider and a Direct contract, as annual per user model. The service is also available with a model based on consumption per-user and per-authentication, billed every month according to the Azure monetary commitmen.

 

For more information on costs of the solution you can consult the following document: Prices of Multi-Factor Authentication.

 

Conclusions

Azure Multi-Factor Authentication is a simple solution to use, scalable and reliable that offers the possibility of introducing a second method of validation so that users are able to access more securely to your data and applications, both present on-premises cloud environments. For those interested in trying out the service can easily activate a subscription Azure for free by going to Free Trial of Azure.

Windows Server 2016: Configuring the Failover Cluster Witness in the Cloud

In the article Windows Server 2016: What's New in Failover Clustering all were thorough main innovations introduced with Windows Server 2016 in the failover clustering. In this article we will detail the configuration of the cluster witness in Microsoft Azure cloud, analyzing the possible scenarios and the benefits of this new feature.

 

Possible scenarios supported by Witness Cloud

Among the supported scenarios that lend themselves more to this type of configuration are:

  • Multi-site stretched cluster.
  • Failover Cluster that does not require shared storage (SQL Always On, Exchange DAGs, etc).
  • Failover Cluster composed of nodes hosted on Microsoft Azure, other public or private cloud.
  • Scale-out type cluster File Server.
  • Cluster made actually small branch-office.

 

Cloud Witness configuration

We begin by specifying that a requirement to configure the cluster to use the Cloud Witness is that all nodes that make up the cluster has an internet access to Azure. Cloud Witness in fact uses the HTTPS protocol (door 443) to establish a connection with the Azure blob Storage Service Account.

 

Configuring the subscription requires a Witness Azure Cloud in which to configure a Storage Account that will be used as Witness and Cloud on which are written the blob file used for the arbitration of the cluster.

 

From the Azure portal you must create a storage account type Genaral Purpose. For this purpose is incorrect, create it with a performance level standard as they are not necessary for high performance that is provided with the use of SSDS. After selecting the most suitable location and replication policies you can proceed with the process of creating.

 

Figure 1 – Storage Account creation

 

After you create your storage account you must retrieve its required access key for authentication, which will be required in configuration steps.

 

Figure 2 – Account Storage access keys

 

At this point you can change the settings of the cluster Quorum from Failover Cluster Manager by following the steps below:

 

Figure 3 – Failover Cluster Quorum Settings Configuration Manager

 

Figure 4 – Witness Quorum selection

 

Figure 5 – Selection of Cloud Witness

 

Figure 6 – Storage Account name and access key

 

After successful configuration will be present among the various cluster resources also Cloud Witness:

 

Figure 7 – Cloud Resource Witness

 

Azure Storage Account is created a container named msft-cloud-witness, within which there will be a single blob file that has as its name the ID I joined the cluster. This means that you can use the same Microsoft Azure Storage Account to set up the different Cloud cluster Witness, where there will be a blob file for each cluster.

 

Figure 8 – Container inside of the Storage Account and its contents

 

Advantages of using Cloud Witness

The use of Cloud Witness gets the following benefits:

  • Eliminates the need to have an additional separate data center for certain cluster configurations by using Microsoft Azure.
  • Cancels the administrative effort required to maintain an additional virtual machine cluster witness role.
  • Given the small amount of data written to the Storage Account service charge is ridiculous.
  • The same Microsoft Azure Storage Account can be used as a witness to different clusters.

 

Conclusions

In the Windows Server failover cluster 2016 proves ready for integration with the cloud. With the introduction of cloud cluster systems more easily is possible Witness substantially reducing overall costs for implementing, the management effort and increasing flexibility of architecture cluster.