Archivi categoria: Microsoft Azure

Come monitorare Office 365 con Azure Log Analytics

In Azure Log Analytics è disponibile una solution specifica che consente di consolidare all’interno del workspace di Log Analytics differenti informazioni provenienti dall’ambiente Office 365, rendendo semplice e intuitiva la consultazione dei dati. In questo articolo saranno esaminate le caratteristiche di questa soluzione e verranno illustrati gli step da seguire per la relativa attivazione.

Caratteristiche dalla soluzione

La solution consente di utilizzare Log Analytics per effettuare le seguenti operazioni relative ad Office 365:

  • Monitorare le attività svolte dagli amministratori, al fine di tenere traccia delle modifiche apportate alle configurazioni e delle operazioni che richiedono privilegi elevati.
  • Analizzare le attività degli account Office 365 al fine di identificare le tendenze comportamentali e controllare l’utilizzo delle risorse. Si possono ad esempio esaminare quali file vengono condivisi all’esterno dell’organizzazione oppure controllare i siti di SharePoint più utilizzati.
  • Fornire supporto nelle attività di audit e compliance. Risulta possibile ad esempio controllare l’accesso a specifici file ritenuti confidenziali.
  • Identificare eventuali comportamenti non desiderati che vengono svolti degli utenti, sulla base di specifiche esigenze organizzative.
  • Svolgere con maggiore semplicità operazioni di troubleshooting che si rendono necessarie nel proprio ambiente Office 365.

Per poter attivare questa solution è necessario disporre di un account con il ruolo Global Administrator. Ad un singolo workspace Log Analytics è possibile connettere più sottoscrizioni Office 365. Nel caso si voglia far confluire nel workspace di Log Analytics anche gli eventi di Audit di Office 365 è necessario abilitare l’auditing sulla subscription Office 365, seguendo la procedura riportata in questa documentazione.

Figura 1 – Abilitazione Office 365 audit

Attivazione della soluzione

Per attivare l’Office 365 Management solution è necessario seguire questa procedura. La solution colleziona i dati direttamente da Office 365, senza l’iterazione di alcun agente di Log Analytics.

Figura 2 – Accesso al Workspace summary dal portale Azure e aggiunta solution

Figura 3 – Selezione della solution di Office 365

Figura 4 – Selezione del workspace da utilizzare

La solution richiede la presenza di una applicazione Azure Active Directory, configurata secondo quanto riportato in seguito, la quale viene utilizzata per accedere ai dati di Office 365.

Figura 5 – Aggiunta di una nuova App registration in Azure AD

Figura 6 – Creazione dell’App registration necessaria per la solution

Figura 7 – Attivazione dell’impostazione Multi-tenanted

Figura 8 – Aggiunta API Access per Office 365 Management APIs

Figura 9 – Selezione dei permessi necessari per Office 365 Management APIs

Figura 10 – Assegnazione dei permessi

Per poter configurare la solution è richiesta una chiave per l’applicazione Azure Active Directory creata.

Figura 11 – Generazione di una chiave per l’applicazione

Giunti a questo punto è necessario eseguire lo script PowerShell office365_consent.ps1 che abilita l’accesso amministrativo. Tale script è disponibile a questo indirizzo.

Figura 12 – Command line di esempio per l’esecuzione dello script office365_consent.ps1

Figura 13 – Richiesta del consenso amministrativo

L’ultimo step necessario per completare l’attivazione è l’esecuzione dello script PowerShell office365_subscription.ps1, anch’esso disponibile a questo indirizzo, il quale sottoscrive l’applicazione Azure AD creata al workspace Log Analytics.

Figura 14 – Command line di esempio per l’esecuzione dello script office365_subscription.ps1

In seguito alla configurazione iniziale possono essere necessari diversi minuti prima di visualizzare i dati di provenienti da Office 365 in Log Analytics. Tutti i record creati da questa solution in Log Analytics hanno valorizzato il Type in OfficeActivity. Il valore contenuto nella proprietà OfficeWorkload determina a quale Servizio di Office 365 si riferisce: Exchange, Azure Active Directory, SharePoint, oppure OneDrive. Nella proprietà RecordType viene invece riportata la tipologia di operazione svolta.

La solution aggiunge nella dashboard il seguente tile:

Figura 15 – Tile di Office 365

Selezionandolo si viene rimandati nella dashboard specifica, la quale suddivide per servizi le varie attività collezionate di Office 365.

Figura 16 – Dashboard di Office 365

Ovviamente è possibile eseguire anche delle query specifiche in base alle proprie esigenze:

Figura 17 – Esempi di query di riportare specifici record collezionati dalla solution

Conclusioni

La raccolta in Log Analytics delle attività svolte in Office 365 consente di avere un controllo capillare dell’ambiente, al fine di poter ottemperare al meglio e con un unico strumento alle normative riguardanti l’auditing e la compliance.

Azure File Sync: panoramica della soluzione

Il servizio Azure File Sync (AFS) permette di centralizzare le cartelle di rete della propria infrastruttura in Azure Files, consentendo di mantenere le caratteristiche tipiche di un file server on-premises, in termini di performance, compatibilità e flessibilità e allo stesso tempo di beneficiare delle potenzialità offerte dal cloud. In questo articolo verranno riportate le caratteristiche principali del servizio Azure File Sync e le procedure da seguire per effettuarne il deployment.

Figura 1 – Schema di overview di Azure File Sync

Azure File Sync è in grado di trasformare Windows Server in una “cache” per accedere rapidamente ai contenuti presenti su una determinata Azure file share. L’accesso locale ai propri dati può avvenire con qualsiasi protocollo disponibile in Windows Server, come SMB, NFS, e FTPS. Si ha la possibilità inoltre di disporre di più server “cache” dislocati in location geografiche differenti.

Queste le caratteristiche principali di Azure File Sync:

  • Multi-site sync: si ha la possibilità di effettuare la sincronizzazione tra differenti site, consentendo di accedere in scrittura agli stessi dati tra differenti Windows Servers ed Azure Files.
  • Cloud tiering: vengono mantenuti localmente solo i dati acceduti di recente.
  • Integrazione con Azure backup: viene a decadere la necessità di effettuare il backup dei dati on premises. La protezione dei contenuti è possibile farla tramite Azure Backup.
  • Disaster recovery: si ha la possibilità di effettuare in modo immediato il ripristino dei metadata dei file e di richiamare solamente i dati necessari, per velocizzare le operazioni di riattivazione del servizio in scenari di Disaster Recovery.
  • Accesso diretto all’ambiente cloud: è consentito accedere direttamente ai contenuti presenti sulla File Share da altre risorse Azure (IaaS e PaaS).

 

Requisiti

Per poter effettuare il deployment di Azure File Sync è necessario disporre dei seguenti requisiti:

Un Azure Storage Account, con una file share configurata in Azure Files, nella stessa region dove si vuole fare il deploy del servizio AFS. Per effettuare la creazione di uno storage account è possibile seguire l’articolo Create a storage account, mentre la procedura di creazione della file share è riportata in questo documento.

Un sistema Windows Server con sistema operativo Windows Server 2012 R2 o successivo, il quale dovrà avere:

  • PowerShell 5.1, che è incluso di default a partire da Windows Server 2016.
  • Moduli PowerShell AzureRM.
  • Agente Azure File Sync. Il setup di installazione dell’agente può essere scaricato a questo indirizzo. Nel caso si intenda utilizzare AFS in ambiente cluster è opportuno installare l’agente su tutti i nodi del cluster. A questo proposito è bene precisare che Windows Server Failover Clustering è supportato da Azure File Sync per deployment di tipologia “File Server for general use”. L’ambiente Failover Cluster non è invece supportato su “Scale-Out File Server for application data” (SOFS) oppure su Clustered Shared Volumes (CSVs).
  • Si consiglia di mantenere l’opzione “Internet Explorer Enhanced Security Configuration” disabilitata sia per gli Administrators che per gli Users.

 

Concetti e configurazione del servizio

Dopo aver verificato la presenza di questi requisiti l’attivazione di Azure File Sync richiede di procedere con la creazione del servizio Storage Sync:

Figura 2 – Creazione servizio Storage Sync

Si tratta della risorsa top-level per Azure File Sync, la quale funge da contenitore per le relazioni di sincronizzazione tra i differenti storage account e molteplici Sync Group. Il Sync Group definisce la topologia di sincronizzazione per un set di files. Gli endpoint che si trovano all’interno dello stesso Sync Group vengono mantenuti in sincronizzazione tra di loro.

Figura 3 – Creazione Sync Group

A questo punto è possibile procedere con la registrazione del server avviando l’agente Azure File Sync.

Figura 4 – Avvio del processo di Sign-in

Figura 5 – Selezione dei parametri di registrazione del server

Figura 6 – Conferma di registrazione dell’agente

Al termine della registrazione il server comparirà anche nella sezione “Registered servers” del portale Azure:

Figura 7 – Server registrati nel servizio Storage Sync

Conclusa la registrazione del server è opportuno inserire un Server Endpoint all’interno del Sync Group, il quale integra un volume oppure una folder specifica, con un Registered Server, creando una location per la sincronizzazione.

Figura 8 – Aggiunta di un Server Endpoint

Aggiungendo un Server Endpoint è possibile abilitare la funzionalità di Cloud tiering che consente di mantenere, localmente sulla cache della macchina Windows Server, i file acceduti più frequentemente, mentre tutti i restanti file vengono salvati in Azure sulla base di specifiche policy che è possibile configurare. Per maggiori informazioni relative alla funzionalità di Cloud Tiering è possibile consultare la documentazione ufficiale Microsoft. A questo proposito è opportuno specificare che al momento non c’è supporto tra Azure File Sync con abilitata la funzionalità di cloud tiering, e la deduplica del dato. Nel caso si desideri abilitare Windows Server Data Deduplication occorre mantenere disabilitata la funzionalità di cloud tiering.

Dopo aver aggiunto uno o più Server Endpoint è possibile consultare lo stato del Sync Group:

Figura 9 – Stato del Sync Group

 

Per ottenere dei deployment di successo di Azure File Sync è inoltre necessario verificare attentamente la compatibilità con le soluzioni antivirus e di backup che vengono utilizzate.

Azure File Sync e DFS Replication (DFS-R) sono due soluzioni per la replica del dato e possono funzionare anche in side-by-side purché siano rispettate queste condizioni:

  1. Azure File Sync cloud tiering deve essere disabilitato sui volumi con cartelle DFS-R replicate.
  2. I Server endpoints non devono essere configurati su cartelle DFS-R read-only.

Azure File Sync può essere un ottimo sostituto di DFS-R e per la migrazione è possibile seguire le indicazioni riportate in questo documento. Rimangono alcuni scenari specifici che possono richiedere l’utilizzo contemporaneo di entrambe le soluzioni di replica:

  • Non tutti i server on-premises che necessitano di una copia dei file possono essere connessi a Internet.
  • Quando i branch servers consolidano i dati in un singolo hub server, sul quale viene poi utilizzato Azure File Sync.
  • Durante la fase di migrazione di deployment di DFS-R verso Azure File Sync.

Conclusioni

Azure File Sync è una soluzione che consente di estendere il classico file server dislocato on-premises con nuove funzionalità di sincronizzazione dei contenuti, beneficando delle potenzialità del cloud pubblico di Microsoft in termini di scalabilità e flessibilità.

Azure IaaS and Azure Stack: announcements and updates (November 2018 – Weeks: 44 and 45)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Azure File Sync is now supported in North Central US and South Central US regions

To get the latest list of supported regions, see https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-planning#region-availability

 

M-Series VMs are now available in East Asia regions

Azure M-Series virtual machines (VMs) are now available in the Canada Central, Canada East  and East Asia regions. M-Series VMs offer configurations with memory from 192 GB to 3.8TiB (4TB) RAM and are certified for SAP HANA.

 

Approve and audit support access requests to VMs using Customer Lockbox for Azure

Customer Lockbox for Microsoft Azure helps customers control and audit a Microsoft support engineer’s access to compute workloads on Azure that may contain customer data. Microsoft support doesn’t have standing access to service operations. In some rare scenarios, to resolve a support issue, just-in-time access with limited and time bound authorization can be provided to Microsoft support engineers. Customer Lockbox helps ensure that Microsoft support engineers don’t access customers’ content in the Azure portal without the customer’s explicit approval. It also helps improve the existing support ticket workflow by expediting the customer’s approval process. This capability enables customers to have more granular control, better visibility and enhanced audit over the support process.

Azure IaaS and Azure Stack: announcements and updates (October 2018 – Weeks: 42 and 43)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Azure AD DS now supports Azure managed disks

Azure Active Directory Domain Services (AD DS) now supports Azure managed disks. Azure managed disks provide a greater degree of availability and resilience to failures. This enables the domain controllers of your managed domain to be more resilient to storage-related outages. All newly created managed domains now use Azure managed disks by default. Existing managed domains will slowly be migrated to use Azure managed disks over the course of calendar year 2018.

 

Azure DevTest Labs: Configure enforcing auto shutdown schedule for the lab

You can now configure enforcing a shutdown schedule for all the virtual machines in your lab so that you can save costs from wasteful running machines. To learn more about this feature, go to the team blog.

 

Azure Availability Zones expand with new services and to new regions

Availability Zones expand into additional regions, North Europe and West US 2. In addition to the continued expansion of Availability Zones across Azure regions, Microsoft announces an expanded list of zone-redundant services including Azure SQL Database, Service Bus, Event Hubs, Application Gateway, VPN Gateway, and ExpressRoute.

 

Azure Stack

Azure Stack 1809 update

This update package includes improvements, fixes, and known issues for Azure Stack.
The following improvements for Azure Stack are included:

  • Azure Stack syslog client (General Availability). This client allows the forwarding of audits, alerts, and security logs related to the Azure Stack infrastructure to a syslog server or security information and event management (SIEM) software external to Azure Stack. The syslog client now supports specifying the port on which the syslog server is listening.
    With this release, the syslog client is generally available, and it can be used in production environments.
  • You can now move the registration resource on Azure between resource groups without having to re-register. Cloud Solution Providers (CSPs) can also move the registration resource between subscriptions, as long as both the new and old subscriptions are mapped to the same CSP partner ID. This does not impact the existing customer tenant mappings.

Microsoft Azure: guida per la scelta della Region

Microsoft Azure è dislocato in differenti luoghi sparsi per il mondo e vanta il primato di disporre di datacenter nel maggior numero di aree geografiche rispetto a qualsiasi altro cloud provider. Questo aspetto consente di disporre di un’ampia scalabilità, necessaria per erogare gli applicativi in prossimità della locazione geografica degli utenti, preservando al tempo stesso la residenza dei dati e offrendo opzioni complete di conformità e resiliency. Poter scegliere, tra differenti region Azure, dove attivare i propri servizi, ha indubbiamente numerosi vantaggi, ma è bene tenere in considerazione differenti aspetti nel momento in cui ci si trova di fronte a questa scelta. In questo articolo saranno riportati i principali elementi che è opportuno tenere in considerazione nella scelta della region di Azure.

Una region in Azure è composta da più datacenter che risiedono in una specifica area geografica e che sono connessi tra di loro tramite una network a bassa latenza. Per consultare la lista completa delle region Azure è possibile accedere alla pagina Azure locations. All’interno di una region sono presenti delle location fisicamente distinte denominate Availability Zones. Ogni Availability Zone è composta da uno più datacenter equipaggiati in modo indipendente dagli altri per quanto riguarda l’alimentazione, i sistemi di raffrescamento e la network. Ogni region è accoppiata con un’altra region all’interno della medesima area geografica, al fine di preservare la data resiliency ed aumentare i livelli di compliance.

Figura 1 – Pair region e Availability Zones all’interno dello stesso confine di data residency

Figure 2 – Azure regional pairs

La scelta della region Azure deve essere fatta prendendo attentamente in considerazione alcuni aspetti principali, ciascuno dei quali può influire in modo decisivo.

 

Performance

Sicuramente uno dei fattori predominanti nella scelta della region è data dalle performance, che sono vincolate dalle latenze di rete nel raggiungere i datacenter di Azure. Tipicamente si sceglie la region più vicina geograficamente, ma non sempre si riesce ad individuare facilmente. A supporto di questa scelta è possibile utilizzare alcuni utili strumenti di terze parti che forniscono dei valori oggettivi:

  • Azure Speed Test 2.0: accedendo a questo sito è possibile misurare la latenza dal proprio web browser ai vari Blob Storage Service che risiedono nelle varie region Azure.

Figure 3 – Risultato mostrato da Azure Speed Test

  • Azure Latency Test: viene riportata la latenza di rete dalla propria location verso le differenti region di Azure, con la possibilità di applicare facilmente dei filtri.

Figure 4 – Risultato mostrato da Azure Latency Test

 

Disponibilità dei servizi

Non tutti i servizi Azure sono disponibili in tutte le region, ne consegue che è opportuno verificare con attenzione se il servizio Azure che si intende utilizzare viene offerto nella region prescelta. Per consultare i servizi Azure disponibili in ciascuna region è possibile accedere a questa pagina, che consente di applicare rapidamente dei filtri per verificare la disponibilità dei servizi offerti per region.

 

Compliance legislative e residenza del dato

Molte organizzazioni sono caute nell’approccio al cloud computing in quanto hanno la necessità che i propri dati risiedano geograficamente su un determinato territorio. Mantenere la confidenzialità dei dati è per tutti fondamentale, ma per i clienti che hanno esigenze specifiche in termini di compliance e data-residency, Microsoft mette a disposizione tutte le informazioni necessarie:

  • Data residency: accedendo a questo sito web è possibile ottenere tutte le informazioni su dove risiedono i dati, facendo distinzione tra i servizi per i quali si scegli la region di appartenenza e quelli che non prevedono questa selezione durante il deployment.
  • Compliance: in questo portale vengono riportate informazioni di supporto utili per i clienti che devono adempiere a normative specifiche riguardanti l’utilizzo, la trasmissione e l’archiviazione dei dati.

 

Costi

I costi dei vari servizi Azure possono variare a seconda della region. Nel caso quindi gli altri fattori non siano determinanti nella scelta, può essere utile valutare di effettuare il deploy dei servizi nella region dove sono più vantaggiosi economicamente. Per poter verificare i costi dei vari servizi si può accedere alla pagina del pricing di Azure.

 

Conclusioni

La scelta della region Azure più opportuna per le proprie esigenze di business, deve essere fatta necessariamente tenendo in considerazione i diversi fattori riportati. Trattandosi di una scelta strategica e non facilmente modificabile, il consiglio è di esaminare con attenzione gli elementi citati, al fine di progettare al meglio la propria architettura in ambiente Microsoft Azure.

Azure Virtual WAN: introduzione alla soluzione

Azure Virtual WAN è un nuovo servizio di rete che consente di ottimizzare ed automatizzare la connettività branch-to-branch attraverso Azure. Grazie a questo servizio è possibile connettere e configurare i dispositivi di rete presenti nei branch per consentire la comunicazione con Azure (branch-to-Azure). In questo articolo vengono esaminati i componenti coinvolti in Azure Virtual WAN e viene riportata la procedura da seguire per la relativa configurazione.

 

Figura 1 – Azure Virtual WAN overview

La configurazione di Azure Virtual WAN prevede la creazione delle seguenti risorse.

 

Virtual WAN

La risorsa Virtual WAN rappresenta uno strato virtuale della rete Azure e colleziona differenti componenti. Si tratta di una stratificazione che contiene i link a tutti i virtual hub che si desidera avere all’interno della Virtual WAN. Le risorse Virtual WAN sono tra loro isolate e non possono contenere hub comuni.

Figura 2 – Avvio del processo di creazione di Azure Virtual WAN

Figura 3 – Creazione Azure Virtual WAN

Durante la creazione della risorsa Virtual WAN viene richiesto di specificare una location. In realtà si tratta di una risorsa globale che non risiede in una region particolare, ma viene richiesto di specificarla solo per poterla gestire e localizzare più facilmente.

Abilitando l’opzione Network traffic allowed between branches associated with the same hub viene consentito il traffico tra i vari sites (VPN o ExpressRoute) associati allo stesso hub (branch-to-branch).

Figura 4 – Branch-to-branch connectivity option

 

Site

Il site rappresenta l’ambiente on-prem. Sarà necessario creare tanti site quante sono le location fisiche. Se ad esempio è presente un branch office a Milano, uno a New York e uno a Londra, sarà necessario ceare tre site separati, i quali contengono i rispettivi endpoint degli apparati di rete utilizzati per instaurare la comunicazione. Nel caso si utilizzino apparati di rete di partner Virtual WAN, vengono fornite delle soluzioni che in modo nativo esportano queste informazioni nell’ambiente Azure.

Figura 5 – Creazione di un site

Nelle impostazioni avanzate è possibile abilitare l’opzione BGP, che se attivata diventa valida per tutte le connessioni create per il site specifico. Tra i campi facoltativi è possibile specificare le informazioni sui device, che possono essere di aiuto al Team Azure per future eventuali ottimizzazioni o in caso di supporto.

 

Virtual Hub

Un Virtual Hub è una Microsoft-managed virtual network. L’hub è il componente core di rete in una determinata region e può esistere un solo hub per Azure region. L’hub contiene diversi service endpoint per consentire di instaurare la connettività con l’ambiente on-prem. La creazione di un Virtual Hub comporta la generazione di una nuova VNet e opzionalmente di un nuovo VPN Gateway. L’Hub Gateway non è un classico virtual network gateway che si utilizza per la connettività ExpressRoute e VPN ed è utilizzato per creare una connessione Site-to-Site tra l’ambiente on-prem e l’hub.

Figura 6 – Creazione di un Hub

Figura 7 – Associazione del site con un Hub

Gli Hub è opportuno che siano associati ai site che risiedono nella stessa region dove si trovano le VNet.

 

Hub virtual network connection

La risorsa Hub virtual network connection è utilizzata per connettere l’hub con la rete virtuale. Attualmente è possibile creare connessioni (peering) con virtual network che risiedono nella stessa region dell’hub.

Figura 8 – Connessione della VNet a un hub

 

Configurazione del dispositivo VPN on-prem

Per configurare il dispositivo VPN on-prem è possibile procedere manualmente, oppure nel caso si utilizzino soluzioni di partner Virtual WAN, la configurazione dei dispositivi VPN può avvenire automaticamente. In quest’ultimo caso il device controller ottiene il file di configurazione da Azure e applica la configurazione ai dispositivi, evitando di dover procedere con configurazioni manuali. Il tutto risulta molto comodo ed efficace, consentendo di risparmiare tempo. Tra i vari partner virtual WAN troviamo: Citrix, Riverbed, 128 Technology, Barracuda, Check Point, NetFoundry e Paloalto. Questa lista è destinata ad ampliarsi a breve con ulteriori partner.

Selezionando Download VPN configuration viene creato uno storage account nel resource group ‘microsoft-network-[location]’ dal quale è possibile scaricare la configurazione dell’apparato VPN on-prem. Tale storage account può essere rimosso dopo aver recuperato il file di configurazione.

Figura 9 – Download della configurazione VPN

Figura 10 – Download del file di configurazione presente sullo storage account

Al termine della configurazione dell’apparato on-prem il site sarà connesso, come mostrato nella figura seguente:

Figura 11 – Stato del site connesso

Viene inoltre fornita la possibilità di instaurare delle connessioni ExpressRoute con Virtual WAN, associando il circuit ExpressRoue all’hub. Si prevede inoltre la possibilità di avere connessioni Point-to-Site (P2S) verso il virtual Hub. Al momento queste funzionalità sono in preview.

Nella sezione Health vengono riportate delle informazioni utili per verificare lo stato di salute della connettività per ciascun Hub.

Figura 12 – Check Hub health

 

Conclusioni

Virtual WAN è il nuovo servizio Azure che consente di realizzare in modo centralizzato, semplice e veloce il collegamento di vari branch, tra di loro e con il cloud pubblico di Microsoft. Tale servizio consente di ottenere un’ottima esperienza di connettività, traendo vantaggio dalla rete globale di Microsoft, la quale può vantare di raggiungere diverse region in tutto il mondo, più di qualsiasi altro cloud provider pubblico.

Azure IaaS and Azure Stack: announcements and updates (October 2018 – Weeks: 40 and 41)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Advanced Threat Protection for Azure Storage (public preview)

Advanced Threat Protection for Azure Storage, available in public preview, detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit storage accounts. This feature helps customers detect and respond to potential threats on their storage account as they occur.

 

Ephemeral OS Disk (limited preview)

Limited preview of Ephemeral OS Disk, a new type of OS disk created directly on the host node, providing local disk performance and faster boot/reset time. Ephemeral OS Disk is supported for all virtual machines (VM) and virtual machine scale sets (VMSS). Ephemeral OS Disk is ideal for stateless workloads that require consistent read/write latency to OS disk, as well as frequent reimage operations to reset the VM(s) to the original state. This includes workloads such as website applications, game server hosting services, VM pools, computation, jobs and more. Ephemeral OS Disk also works well for workloads that are leveraging low-priority VM scale sets.

Azure confidential computing (public preview)

Azure confidential computing protects your data while it’s in use. It is the final piece to enable data protection through its lifecycle whether at rest, in transit, or in use. It is the cornerstone of Microsoft ‘Confidential Cloud’ vision, which aims to make data and code opaque to the cloud provider. DC-series of virtual machines in US East and Europe West are in public preview. While these virtual machines may ‘look and feel’ like standard VM sizes from the control plane, they are backed by hardware-based Trusted Execution Environments (TEEs), specifically the latest generation of Intel Xeon Processors with Intel SGX technology. You can now build, deploy, and run applications that protect data confidentiality and integrity in the cloud. The DC-series of VMs are the first set of Generation 2 virtual machines. As such, Microsoft has specially configured operating images that are required with these virtual machines (Generation 2 support for Ubuntu Server 16.04 and Windows Server 2016 Datacenter). These images are automatically used when deploying through the portal. Custom images are not yet supported. DC-series VMs will not show up in the size selector for arbitrary marketplace images, as not all images have been updated yet.

Azure IaaS and Azure Stack: announcements and updates (September 2018 – Weeks: 38 and 39)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Virtual machine serial console

The Azure virtual machine serial console is now generally available in all public regions. New features include magic SysRq keys, non-maskable interrupts, and subscription-wide enable/disable. More details are available in the documentation for Windows and Linux.

 

Immutable storage for Azure Storage Blobs

Financial services organizations regulated by SEC, CFTC, FINRA, IIROC, FCA, etc., are required to retain business-related communications in a Write-Once-Read-Many (WORM) or immutable state to ensure that they’re non-erasable and non-modifiable for a specific retention interval. The immutable storage requirement is not limited to financial organizations. It also applies to industries such as healthcare, insurance, media, public safety, and legal services.

To address this requirement, immutable storage for Azure Blob storage is now generally available in all Azure public regions. Through configurable policies, users can keep Azure Blob storage data in an immutable state where blobs can be created and read, but not modified or deleted.

For more details on the feature, see the Microsoft Azure blog.

 

Azure Premium Blob Storage (preview)

Azure Blob Storage introduces a new performance tier—Premium Blog Storage, complimenting the existing hot, cool, and archive tiers. Data in Premium Blob Storage is stored on solid-state drives, which are known for lower latency and higher transactional rates compared to traditional hard drives. Premium Blob Storage is ideal for workloads that require very fast access times. This includes most scenarios with a human in the loop, such as interactive video editing, static web content, and online transactions. It also works well for workloads that perform many transactions that are relatively small, such as capturing telemetry data, message passing, and data transformation.

 

Azure Availability Zones in West US 2 and North Europe

Azure Availability Zones, a high-availability solution for mission-critical applications, is now generally available in West US 2 and North Europe.

Availability Zones are physically separate locations within an Azure region. Each Availability Zone consists of one or more datacenters equipped with independent power, cooling, and networking. With the introduction of Availability Zones, we now offer a service-level agreement (SLA) of 99.99% for uptime of virtual machines.

Availability Zones are generally available in select regions.

 

Public IP prefix (preview)

A Public IP prefix is a reserved range of static IP addresses that can be assigned to your subscription. You can use a prefix to simplify IP address management in Azure. Knowledge of the range ahead of time eliminates the need to change firewall rules as you assign IP addresses to new resources. This predictability significantly reduces management overhead when scaling in Azure.

For more information about Public IP prefixes in Azure and how to use them, see Public IP Prefix.

 

Virtual network peering across Azure Active Directory tenants

Virtual network peering enables direct VM-to-VM connectivity across virtual machines deployed in different virtual networks using the Microsoft backbone. Virtual network peering is now available for virtual networks that belong to subscriptions in different Azure Active Directory tenants.

 

Azure Load Balancer: Outbound Rules for Standard Load Balance GA

This new ability allows you to declare which public IP or public IP prefix should be used for outbound connectivity from your virtual network, and how outbound network address translations should be scaled and tuned.

 

Azure Load Balancer TCP resets on idle (preview)

Azure Load Balancer supports sending of bidirectional TCP resets on idle timeout for load balancing rules, inbound NAT rules, and outbound rules.  For more information, including pricing details, please visit the Azure Load Balancer TCP reset page.

 

ExpressRoute Direct 100Gbps connectivity

ExpressRoute Direct provides 100G connectivity for customers with extreme bandwidth needs. This is 10x faster than other clouds. With ExpressRoute Direct you can send 100 Gbps of network traffic to Azure services such as Azure Storage and Azure Virtual Networks. All your traffic can be on a single 100G ExpressRoute Circuit or you subdivide 100G among your business units in any combination of 40G, 10G, 5G, 2G, and 1G ExpressRoute circuits.

 

ExpressRoute Global Reach

ExpressRoute Global Reach allows you to connect two ExpressRoute circuits together. Your sites that are already connected to ExpressRoute can now privately exchange data via their ExpressRoute circuits. ExpressRoute Global Reach can be enabled on both ExpressRoute Standard and ExpressRoute Premium circuits. ExpressRoute Global Reach is available in the following locations: Hong Kong, Ireland, Japan, Netherlands, United Kingdom, and United States with Korea and Singapore coming soon. More locations will be available later this year.

 

Zone-Redundant VPN and ExpressRoute Virtual Network Gateways

To improve the resiliency, scalability and availability of gateways, Zone Redundant VPN and ExpressRoute Gateways bring support for Azure Availability Zones. With these new Zone-Redundant/Zonal Gateways, you will be able to deploy Azure VPN and Azure ExpressRoute gateways in Azure Availability Zones, thus making them physically and logically separate within a region to protect your on-premises network connectivity to Azure from zone-level failures.

 

Azure Firewall: General availability and new capabilities

Azure Firewall, now GA, offers fully stateful network and application level traffic filtering for VNet resources, with built-in high availability and cloud scalability delivered as a service. For more information, please refer to Azure Firewall documentation.

 

Shared Image Gallery (public preview)

Shared Image Gallery provides an Azure-based solution to make the custom management of virtual machine (VM) images easier in Azure. Shared Image Gallery provides a simple way to share your applications with others in your organization, within or across regions, enabling you to expedite regional expansion or DevOps processes, simplify your cross-region HA/DR setup and more. Shared Image Gallery also enables you to quickly deploy thousands of VMs concurrently from a custom image.

 

Automatic OS image upgrade in virtual machine scale sets is now generally available.

After you enable this feature for your scale sets, when a new OS image is published with the latest features, security patches, and performance improvements, your scale sets and Azure Service Fabric clusters can receive these updates automatically. The new image will roll out to the VMs in your scale sets in batches based on preconfigured health probes to check for application issues. You can monitor the status of upgrades programmatically or through an out-of-the-box experience in the Azure portal. To learn more about this capability and to start enabling it for your VMs in VM scale sets, see this documentation.

 

Azure Virtual Machine Image Builder available in private preview

Azure Virtual Machine (VM) Image Builder, now available in private preview, allows you to migrate your image building pipeline to Azure. Submit a template describing your VM source image and customizations, indicate where to distribute a bootable image, and then start building your VM images.

 

Ultra SSD, a new Azure Managed Disks offering (preview)

Ultra SSD, a new Azure Managed Disks offering for your most demanding data-intensive workloads, is now available in preview. Ultra SSDs can deliver unprecedented and extremely scalable performance with sub-millisecond latency:

  • Choose a disk size from 4 GiB up to 64 TiB.
  • Achieve the optimal performance you need per disk even at low storage capacities.
  • Scale performance up to 160,000* IOPS and 2 GB/s per disk with zero downtime.

 

Azure Stack

Service Fabric now available on Azure Stack

Azure Service Fabric is now available on Azure Stack. Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers.

 

Red Hat OpenShift and Microsoft Azure Stack together for hybrid enterprise solutions

OpenShift and Azure Stack present exciting new options for customers who use Microsoft and Red Hat technologies and offer the greatest possible flexibility and consistency where these solutions are run and managed – whether its in the public cloud or on-premises with Azure Stack. OpenShift and Azure Stack enable a consistent application experience across Azure, Azure Stack, bare-metal, Windows and RHEL bringing together Microsoft’s and Red Hat’s developer frameworks and partner ecosystems.

Azure Networking: caratteristiche del Global VNet peering

Le Virtual Network in ambiente Azure sono per loro natura logicamente isolate, per consentire di connettere in modo sicuro differenti risorse Azure. Il Global VNet peering in ambito Azure fornisce la possibilità di mettere in comunicazione virtual network che risiedono su differenti region di Azure. In questo articolo verranno approfonditi i benefici e le attuali costrizioni imposte dal Global VNet peering. Sarà inoltre mostrata la procedura da seguire per l’attivazione di un Global VNet peering.

Figura 1 – Esempio di connessione di VNet di Azure in region differenti

Nel momento in cui viene configurato il peering tra due virtual network che risiedono in region di Azure diverse, si espande il confine logico e le macchine virtuali attestate su queste VNet possono comunicare tra di loro con i propri indirizzi IP privati, senza dover utilizzare gateway e indirizzi IP pubblici. Inoltre, è possibile adottare il modello di rete hub-spoke, per condividere le risorse quali firewall oppure virtual appliance, mettendo in comunicazione anche virtual network in differenti region di Azure, attraverso il Global VNet peering.

Benefici del Global VNet peering

I principali benefici che si possono ottenere utilizzando il Global VNet peering per mettere in comunicazione le virtual network sono:

Figura 2 – Rete di backbone di Microsoft

  • Si può usufruire di una connettività a bassa latenza e con un bandwidth elevato.
  • La configurazione è semplice e non richiede la presenza di gateway per istaurare tunnel VPN tra le differenti network.

 

Attuali costrizioni del Global VNet peering

Attualmente ci sono alcune costrizioni che è opportuno tenere in considerazione quando si effettua un Global VNet peering:

  • In presenza di un Global VNet peering non è possibile utilizzare i gateway remoti (opzione “use remote gateways”) oppure consentire il transito del gateway (opzione “allow gateway transit”) sulle virtual network. Queste opzioni sono attualmente utilizzabili solo quando si effettua un peering di virtual network che risiedono nella stessa region di Azure. Ne consegue quindi che i Global VNet peering non sono transitivi, quindi le VNet di downstream in una region non possono dialogare, utilizzando questa metodologia, con le VNet in un’altra region. Ad esempio, ipotizzando uno scenario dove tra la vNet1 e la vNet2 è presente un Global VNet peering e tra la vNet2 e la vNet3 è presente un altro Global VNet peering. In questo caso non ci sarà comunicazione tra la vNet1 e la vNet3. Se si ha la necessità, è possibile creare un ulteriore Global vNet peering per metterle in comunicazione.
  • Per una risorsa che risiede su una virtual network, non è consentito comunicare utilizzando l’indirizzo IP di un Azure internal load balancer che risiede sulla virtual network in peer. Questo tipo di comunicazione è consentita solo se il source IP e l’indirizzo IP del Load Balancer sono nella stessa VNet.
  • Il Global VNet peering si può creare in tutte le Azure public regions, ma non con VNet che risiedono negli Azure national clouds.
  • La creazione del Global VNet peering è consentita anche tra VNet che risiedono in subscription differenti, purché siano associate allo stesso tenant di Active Directory.
  • Le virtual network possono essere messe in peering solo se non è presente overlapping nei relativi address space. Inoltre, in seguito alla creazione del peering, se si ha la necessità di modificare gli address space è necessario a priori rimuovere il peering.

 

Configurazione del Global VNet peering

La configurazione del Global VNet peering è estremamente semplice. Nelle immagini seguenti vengono documentati gli step per mettere in comunicazione due virtual network create in region differenti, nel caso specifico West Europe e Australia Southeast.

Figura 3 – Aggiunta del peering dalle impostazioni della VNet

Figura 4 – Configurazione dei parametri del peering

Selezionando l’opzione “Allow virtual network access”, viene consentita la comunicazione tra le due virtual network. Tale impostazione consente che l’address space della VNet in peer sia aggiunto al tag Virtual_Network.

Figura 5 – Peering aggiunto, in stato Initiated

Le stesse operazioni, documentate nella figura 3 e nella figura 4, è necessario ripeterle anche sulla Virtual Network che risiede nell’altra region e con la quale si vuole configurare il Global VNet peering. La comunicazione sarà attivata nel momento in cui lo stato del peering sarà “Connected” su entrambe le VNet.

Figura 6 – Peering in stato Connected

Selezionando una macchina virtuale, attestata su una virtual network con configurato il global vNet Peering, si vedrà una rotta specifica per la VNet associata, come mostrato nella figura seguente:

Figura 7 – Effective route della VNet in Global Peering

Il Global VNet peering prevede dei costi per il traffico di rete in ingresso e in uscita che transitano dal peering e il costo varia a seconda delle zone contemplate. Per maggiori dettagli è possibile fare riferimento alla pagina ufficiale dei costi.

 

Conclusioni

Il Global VNet peering consente di avere un’ottima flessibilità nel gestire in modo semplice ed efficace come i vari workload possono connettersi tra di loro, consentendo di espandere i possibili scenari di implementazione in Azure, senza dover considerare i confini geografici come un limite. Importanti benefici possono essere ottenuti in particolare in architetture di replica del dato e di disaster recovery.

Azure IaaS and Azure Stack: announcements and updates (September 2018 – Weeks: 36 and 37)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Virtual network service endpoints for Azure Key Vault

Virtual network service endpoints are generally available for Azure Key Vault in all public Azure regions.

 

Configure just-in-time virtual machine access from the VM blade

Just-in-time virtual machine access can now be configured from the virtual machine blade (in preview) to make it even easier for you to reduce your exposure to threats.

 

Filter VM sizes by current or previous generation

With a recent update to the virtual machine size picker, the default filter set will show current-generation virtual machine sizes only.

 

Announcing the Public Preview for Azure Active Directory Integration with Azure Files

Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard SMB protocol. Integration with AAD enables SMB access to Azure file shares using AAD credentials from AAD DS domain joined Windows VMs.

 

 

Azure Stack

Managed Disks in Azure Stack

Azure Managed Disks simplifies disk management for Azure VMs by managing the storage accounts associated with the VM disks. You only have to specify the type (Premium or Standard) and the size of disk you need, and Azure creates and manages the disk for you. This work will bring more options and simplicity to Azure Stack users when working with VMs. This update applies primarily to Azure Stack users.

 

Ability to incrementally add capacity to Azure Stack

Azure Stack operators can now add a node to an existing Azure Stack scale unit within the supported scale unit limits. This enables Azure Stack operators to increase the capacity of a single Azure Stack, and specifics should be discussed with hardware partners.

 

Azure Stack support for Azure Backup

Azure Stack operators can now backup and recover guest OS, data disks, and volumes using Azure Backup. This new ability gives operators more options when developing a backup strategy for Azure Stack.

 

Azure Government cloud integration for Azure Stack

Azure Stack is now integrated with the Azure Government cloud, enabling connections to Azure Government identity, subscription, registration, billing, backup/DR, and Azure Marketplace. Azure Stack unlocks a wide range of hybrid cloud use cases for government customers, such as tactical edge and regulatory scenarios.