Articles Tagués ‘Microsoft Azure’

Hello Everyone,

Si vous souhaitez découvrir les Datacenters Azure de plus près et en savoir plus sur les différentes couches logicielles et matérielles qui les composent, incluant le « Compute /Storage /Network », je vous invite donc à consulter cette présentation.

Très bonne PPT, par le grand Mark Russinivoch, CTO MS Azure Corp.

Bonne lecture à tous.

HK o__O.

Publicités

Hello Azure Guys,

Great News 🙂

Azure Availability Zones est désormais disponibles (in Public Preview pour l’instant) sur les deux Régions Azure suivantes :

  • États-Unis de l’Est 2 (US Est 2)
  • Europe de l’Ouest (West Europe)
Pourquoi  « ‘Azure Availability Zone » ?

Azure Availability Zones (ou Zones de Disponibilités Azure) vous permet de protéger vos ressources Cloud en cas de perte d’un Datacenter Azure en entier.

En effet, ces Zones (Datacenters) sont situés au niveau d’une même Région Azure et fonctionnent de manière indépendante (Alimentation électrique, climatisation, réseau…). Pour assurer une résilience, il existe au moins trois zones (3 Datacenters) distinctes dans toutes les régions supportant l’Availability Zones.

La séparation physique et logique des zones dans une région protège vos données et ressources Cloud en cas de problème ou défaillance sur un Datacenter.

Azure Availability Zones & Services Cloud pris en charge

Au moment de l’écrire du présent post, seuls les services Azure suivants prennent en charge l’Azure Availability Zones :

  • Linux Virtual Machines
  • Windows Virtual Machines
  • Zonal Virtual Machine Scale Sets
  • Managed Disks
  • Load Balancer
Azure Availability Zones & Familles de VMs Azure pris en charge

Seules les séries de VMs Azure suivantes prennent en charge l’Azure Availability Zones :

  • Av2
  • Dv2
  • DSv2

 

HowTo : Activer Azure Availability Zones sur votre abonnement (Subscription) Azure

Tout d’abord, vous devez « Sign-up » ici  : comme mentionné précédemment, Azure Availability Zones est en mode « Preview » pour l’instant

Connectez-vous ensuite à votre abonnement et activer A-A-Z

 

Useful Links

Je vous invite à consulter les liens ci-après pour en savoir plus :

https://docs.microsoft.com/en-us/azure/availability-zones/az-overview

https://azure.microsoft.com/en-us/updates/azure-availability-zones/


Ce post a été updaté le 16/10/2017


Resource Manager « Locks », qu’est ce que c’est ?!

Le modèle de déploiement ARM (Azure Resource Manager) inclut une fonctionnalité qui va sûrement intéresser les IT en charge d’administrer et de sécuriser les services et ressources Azure : il s’agit de « Resource Manager Locks »

Ces verrous vous permettent de protéger vos ressources Azure jugées « Critiques » en mettant en place des règles de restrictions pour empêcher toute modification et/ou suppression accidentelle. Les Locks Resource Manager n’ont aucun rapport avec une hiérarchie RBAC (Role-Based Access Control) car une fois appliqués, ils positionnent des restrictions sur la ressource pour TOUS les utilisateurs. Cela devient très utile quand vous souhaitez protéger des « Ressources Azure Critiques » contre toute modification ou suppression, même accidentelle.

Notez qu’il existe deux niveaux de verrouillage, à savoir :

  • CanNotDelete : ce niveau empêche tous les utilisateurs de supprimer la(es) ressource(s) Azure sur la(es) quelle(s) le verrou est activé. Les ressources Azure restent en revanche accessibles en lecture et peuvent être modifiée à tout moment.
  • ReadOnly : ce niveau rend les ressources Azure accessibles en « Lecture seule » uniquement. Les utilisateurs ne peuvent donc ni modifier ni supprimer la(s) ressource(s) sur la(es) quelle(s) le verrou est activé. Appliquez ce niveau de verrouillage a le même effet /impact que d’attribuer le rôle « Lecteur » à vos utilisateurs, en effet, les mêmes autorisations accordées par le rôle « Lecteur » sont appliquées via le Lock « ReadOnly ».

Les « Locks » Resource Manager peuvent être appliqués aux :

  • Abonnements (Azure Subscriptions)
  • Groupes de Ressources (Azure Resources Group)
  • Ressources (Azure Resources)

Note importante : quand vous appliquez un verrou au niveau d’un abonnement, toutes les ressources placées dans cet abonnement (y compris celles que vous créerez plus tard) héritent le même niveau de verrouillage. De plus, et contrairement au RBAC, une fois appliqués, les Locks impactent tous les utilisateurs, quelque soit leur rôle. Donc, si la modification ou suppression d’une ressource (déjà Lockée) devient vraiment nécessaire, vous devrez d’abord supprimer le verrou associé à la ressource avant de la modifier ou la supprimer.


Les Permissions : ce que vous devez connaître !

Les permissions qui vous permettent de créer et supprimer les verrous nécessitent l’accès à l’une des permissions RBAC suivante :

  • Microsoft.Authorization/*
  • Microsoft.Authorization/locks/*

Par défaut, ces actions /permissions sont prédéfinies pour les rôles « Owner /Propriétaire » et « User Access Administrator /Administrateur de l’accès Utilisateur ». Si nécessaire, vous pouvez les ajouter à des rôles spécifiques /personnalisés.

 

Logs /Traçabilité 

Les opérations de « Création & Suppression » de verrous sont (par défaut) inscrites dans les Journaux d’Activité Azure (Azure Activité Logs).

Les utilisateurs qui tente de supprimer ou modifier une ressource ayant un « Lock » déjà en place recoivent le message d’erreur suivant :

Au niveau du New Azure Portal (portal.Azure.com) :

Au niveau de l’interface Azure CLI, l’Admin IT reçoit le message suivant :

The scope ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-dev-rg/providers/Microsoft.Storage/storageAccounts/hkcriticalstorage1’ cannot perform delete operation because following scope(s) are locked: ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c’. Please remove the lock and try again.

Même chose côté PowerShell, le message d’erreur suivant est retourné à l’Admin IT :

Remove-AzureRmResource : ScopeLocked : The scope ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-dev-rg/providers/Microsoft.Storage/storageAccounts/hkcriticalstorage1’
cannot perform delete operation because following scope(s) are locked: ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c’. Please remove the lock and try again.

 

HowTo : Créer vos « Verrous /Locks »

Les « Locks » Resource Manager peuvent être créés soit au moment de la création de la ressource (au niveau du Template ARM) ou ultérieurement via le nouveau portal Azure (portal.Azure.com), Windows PowerShell ou encore l’interface en ligne de commande (Az CLI 2.0).

Création des « Locks » lors de la création d’une Ressource

La création de Verrous lors de la configuration du Template ARM est le meilleur moyen de s’assurer que votre protection est bien place une fois vos ressources Azure créées /provisionnées.

Les Verrous sont des ressources ARM de « Haut Niveau », ils ne font pas partis de la configuration (sous-couche) des ressources Azure mais plutôt référence à la (aux) ressource(s) à verrouiller, celles-ci doivent donc d’abord exister pour pouvoir créer des « Locks ».

Dans l’exemple suivant, nous allons créer un compte de stockage nommé hkcriticalstorage1 et ensuite verrouiller cette ressource contre la suppression. Notez que le paramètre « Type » fait référence au type de ressource que vous voulez « Verrouiller ».

 

{
« type »: « Microsoft.Storage/storageAccounts »,
« name »: « hkcriticalstorage1 »,
« apiVersion »: « 2015-01-01 »,
« location »: « [resourceGroup().location] »,
« tags »: {
« displayName »: « hkcriticalstorage1 »
},
« properties »: {
« accountType »: « Standard_LRS »
}
},
{
« name »: « [concat(‘hkcriticalstorage1’, ‘/Microsoft.Authorization/criticalStorageLock’)] »,
« type »: « Microsoft.Storage/storageAccounts/providers/locks »,
« apiVersion »: « 2015-01-01 »,
« properties »: {
« level »: « CannotDelete »
}
}
]

 

Le niveau de verrouillage peut être défini à « ReadOnly » simplement en changeant la valeur du paramètre « Level » et la définissant à ReadOnly

Création des « Locks » via le Portail Azure

Comme expliqué précédemment, les verrous s’appliquent à différent niveau : abonnement, groupe de ressource ou encore à des ressources individuelles.

Pour ajouter un « Lock », il suffit de sélectionner l’objet sur lequel vous souhaitez l’appliquer, et cliquez (depuis le volet gauche) sur :

Verrous (ou Locks si votre portail Azure est en En« glish ») : s’il s’agit d’un Groupe de Ressources ou une Ressource individuelle

 

 

 

 

Verrous de ressources (ou Resource Locks si votre portail Azure est en En« glish ») : s’il s’agit d’un Abonnement Azure

 

 

 

 

 

 

Dans l’exemple suivant, nous allons ajouter un « Lock » au niveau de mon abonnement (Visual Studio Premium avec MSDN) en spécifiant les informations suivantes :

  • Nom du Verrou : hk-subscription-lock-del(etion)
  • Type de verrou : Supprimer
  • Remarques : Ce Verrou permet d’empêcher tout utilisateur de supprimer les ressources de l’abonnement Azure « VS Prem MSDN » de HK

Pour ce faire, il faut simplement cliquer sur « Verrous de ressources » > Ajouter > et spécifier ensuite les informations de configuration:

Pour confirmer que les ressources Azure hébergées au niveau de l’abonnement héritent bien ce « Lock » nouvellement créé, cliquez sur n’importe quelle ressource de l’abonnement et rendez-vous ensuite sur « Verrous » ou « Locks », constatez l’apparition du « Lock », précédemment créé :

Création des « Locks » via Windows PowerShell

Le code PS ci-après peut être utilisé pour ajouter un « Lock » à une ressource existante. Encore une fois, le type de ressource (paramètre ResourceType) dépend du type de la ressource que vous souhaitez verrouiller.

Pour supprimer le Verrou, vous devez utiliser la Cmd-let Remove-AzureRmResourceLock.

 

Création des « Locks » via Azure CLI 2.0

Note : si vous n’avez pas encore connecter votre Interface Azure CLI 2.0 à votre compte Azure, je vous invite à consultez cet article.

La commande qui vous permet de créer et gérer les « Verrous » est : Az Lock

Depuis l’interface CLI 2.0, saisissez Az Lock -h pour faire apparaître l’aide en ligne de cette commande :

Pour créer un « Lock » de type « ReadOnly » et l’appliquer au niveau de votre abonnement Azure, la commande suivante est utilisée :

az lock create –name criticalStorageLock –resource-group hk-criticalstorage-rg –lock-type ReadOnly

Je vous invite à consulter cet article très bien rédigé par l’équipe MS Azure pour en savoir plus sur toute la syntaxe et paramètre disponibles avec la commande Az Lock.

 

Ce qu’il faut retenir

Notez que les Locks permettent seulement la protection contre toute suppression ou modification accidentelle des ressources Azure « Critiques », ceux-ci ne permettent pas une restriction totale car les Admins Azure peuvent facilement supprimer les verrous et récupérer les droits de « Supprimer et/ou Modifier » les ressources Azure.

Perso, je considère les Locks comme une couche de protection supplémentaire des ressources Azure car, ils s’appliquent à TOUS les utilisateurs, quelque soit leur rôle (hiérarchie RBAC), cela permettra donc une amélioration de la sécurité /protection de l’infrastructure Cloud, Azure.

What Next ?

Je vous laisse créer et tester vos new Resource Manager Locks sur vos ressources Azure et me faire part de votre feedback pour cette fonctionnalité.

Restez connecté, plusieurs articles autour de l’Azure sont en cours de finalisation et verront le jour très prochainement sur mon blog :).

A bientôt.

Rappel sur les Groupes de Ressources Azure [Azure Ressource Groupe]

Toutes les ressources créés /provisionnées dans Microsoft Azure ont besoin d’être associées à des « Groupes de Ressources ». il s’agit ici d’une fonctionnalité de base du modèle ARM (Azure Resource Manager).

Utiliser un groupe de ressources Azure vous permettra de grouper toutes vos ressources Cloud (VM, NIC, stockage, IP Public..etc) dans une sorte de « Conteneur logique » et de les gérer de manière centraliser

Puis-je déplacer mes ressources Azure d’un Groupe de Ressources vers un autre ?

Yes, cela est tout à fait possible !

Vous pouvez être amené à déplacer une ou plusieurs ressources Azure (VM, VNET, Compte de stockage…) d’un Groupe de Ressources vers un autre.

e.g : Déplacement d’une VM (ayant servie par exemple à la mise en pré-production d’une solution ou application pour validation) d’un groupe de ressources nommée « hk-preprod-rg » vers un Groupe de Ressources nommé « hk-prod-rg ». Un autre scénario classique est le déplacement d’une ou plusieurs VM Azure ayant servie pour la mise en place d’un PoC qui doit finir en Production. Vous aurez donc comme tâche le move de ces VMs d’un Groupe de Ressources TaGué « PoC » vers un autre TaGué « Prod ».

Comment ça marche ?

Le déplacement d’une ressource Azure d’un Groupe de Ressources vers un autre peut se faire via trois outils :

  • Nouveau Portail Azure : portal.azure.com
  • Windows PowerShell : module Azure
  • Azure CLI 2.0 : commande az resource move

 

Déplacement de Ressources via le Nouveau Portail Azure
  • Connectez-vous sur portal.azure.com
  • Cliquez sur le Groupe de Ressources « source » regroupant votre ou vos ressources Azure à déplacer. Dans l’exemple suivant, la ressource que je souhaite déplacer est associée au groupe de Ressources « hk-preprod-rg« .
  • Localisez et cliquez sur la Ressource à déplacer. Dans l’exemple, la VM « hk-preprod-vm1 » sera déplacée vers le Groupe de Ressources « hk-prod-rg« 

  • Depuis « Vue d’ensemble« , cliquez sur « Déplacer » et sélectionnez ensuite « Déplacer vers un autre groupe de ressources » :

  • L’assistant suivant apparaît, comme illustré dans l’image ci-dessous, vous pouvez également déplacer une ou toutes les autres ressources associées à la ressource que vous souhaitez déplacer. Sélectionnez le groupe de ressources de « Destination » et cliquez sur « Ok » pour démarrer le déplacement de la ressource.

  • Si vous cliquez sur le Groupe de Ressources de « Destination », vous constaterez l’apparition d’une notification vous indiquant le Déplacement de ressource.

 

Déplacement de Ressources via Windows PowerShell
  • Lancez Windows PowerShell (en tant qu’Administrateur) et saisissez Login-AzureRmAccount pour connecter votre compte Azure

  • Une fois connecté, saisissez la commande suivante et notez l’ID de la ressource à déplacer. Dans l’exemple suivant, nous allons afficher les informations sur la ressource Azure « hk-preprod-vm1« , qui est une VM Azure associée au groupe de Ressources « hk-preprod-rg » :

Get-AzureRmResource -ResourceName hk-preprod-vm1 -ResourceGroupName hk-preprod-rg

  • Pour déplacer votre ressource (dans l’exemple suivant > hk-preprod-vm1 dont l’ID de ressource est /subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-preprod-rg/providers/Microsoft.Compute/virtualMachines/hk-preprod-vm1), vous pouvez exécuter l’une des deux commandes suivante :

Move-AzureRmResource -ResourceId /subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-preprod-rg/providers/Microsoft.Compute/virtualMachines/hk-preprod-vm1 -DestinationResourceGroupName hk-prod-rg

ou

Get-AzureRmResource -ResourceName hk-preprod-vm1 -ResourceGroupName hk-preprod-rg | Move-AzureRmResource -DestinationResourceGroupName hk-prod-rg

  • Le déplacement de la ressource démarre …

 

Déplacement de Ressources via l’interface Azure CLI 2.0
  • Lancez l’Invite de commande CMD.exe (en tant qu’Administrateur) et suivez les instructions détaillées dans cet article pour connecter l’interface Azure CLI 2.0 à votre compte Azure
  • Comme sous Windows PowerShell, vous devez d’abord récupérer l’ID de la ressource à déplacer. Pour ce faire, Saisissez la commande suivante. Notez que dans l’exemple ci-dessous, la ressource à déplacer est la VM « hk-preprod-vm1 » associée au groupe de ressource source « hk-preprod-rg » :

az resource show -n hk-preprod-vm1 -g hk-preprod-rg –resource-type « Microsoft.Compute/virtualMachines »

Cette ressource (dont l’ID est /subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-preprod-rg/providers/Microsoft.Compute/virtualMachines/hk-preprod-vm1) sera déplacée vers le Groupe de ressources de Destination « hk-prod-rg », la commande suivante est utilisée :

az resource move –ids /subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-preprod-rg/providers/Microsoft.Compute/virtualMachines/hk-preprod-vm1 –destination-group hk-prod-rg


Plusieurs « HowTo » Azure sont en cours de finalisation et seront bientôt publiés, n’hésitez pas à vous abonner sur le Blog pour Keep updated de toute nouvelle publication.

A bientôt.

 

 

 

 
Introduction 

Un réseau virtuel Azure (Azure Virtual Network) est la représentation de votre réseau local d’entreprise dans le Cloud. En effet, quand vous décidez de déployer des ressources dans le Cloud et choisissez Microsoft comme fournisseur de Cloud public, eh bien votre « Réseau dans le Cloud » est le Azure Virtual Network (appelé aussi VNET : cf documentations Microsoft)

Vous pouvez configurer votre ou vos VNETs Azure de la même manière que pour votre ou vos réseaux locaux « On-Premise » : définir le plan d’adressage IP, les sous-réseaux (Subnets), le(s) serveur(s) DNS, les stratégies de sécurité, le routage …Etc

Vous pouvez également subdiviser votre VNET Azure en sous-réseaux pour isoler les différents trafics réseaux (e.g : environnements DMZ /INT /PREPROD /PROD) , ces sous-réseaux peuvent aussi représenter des « Branch Office » ou simplement des Sites de Backup /PRA pour votre S.I, un VNET Azure devient alors une extension de vos réseaux locaux internes « On-Prem » dans le Cloud.

La création d’un VNET Azure peut se faire via :

Le nouveau portail Azure : portal.azure.com

Windows PowerShell : utilisation du module PS Azure

Azure CLI 2.0 : via l’utilisation de la commande az network vnet

Nous allons découvrir à travers cet article la troisième méthode qu’est l’utilisation de l’interface Azure CLI 2.0

Now let’s create & manage our Azure Virtual Network via Azure CLI 2.0__O

 

Comment ça marche ?
  • Ouvrez une Session Windows sur la machine d’administration sur laquelle Azure CLI 2.0 a été installé
  • Lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez az pour vérifier la disponibilité de l’interface Azure CLI 2.0
  • Après avoir saisi et exécuté la commande az, le Menu suivant vous est retourné :

  • La commande qui nous intéresse est Network. En effet, l’interface az dans le contexte Network vnet permet de créer et gérer les réseaux virtuels Azure.
  • Pour afficher toutes les commandes & sous-commandes liés à la création et gestion des VNETs, saisissez la commande suivante : az network vnet -h 

  • Pour afficher /lister les VNETs existants, saisissez az network vnet list –output table
    • Note : le paramètre –output table est utilisé pour une meilleure lisibilité du résultat retourné (résultat affiché sous forme de tableau)

  • Pour créer une nouveau VNET nommé « hk-vnet01 » dans le groupe de ressource « hk-ResourceGroup » et l’héberger au niveau de la région Azure « Europe de l’Ouest« , la commande suivante est utilisée : az network vnet create -n « hk-vnet01 » -g « hk-ResourceGroup » -l WestEurope

  • Pour créer une nouveau VNET nommé « hk-vnet02 » dans le groupe de ressource « hk-ResourceGroup » et l’héberger au niveau de la région Azure « Europe de l’Ouest » en spécifiant l’espace d’adressage 10.10.0.0/16 et en créant un premier sous-réseau dont l’ID est 10.10.1.0/24, la commande suivante est utilisée : az network vnet create -g hk-ResourceGroup -n hk-vnet02 -l WestEurope –address-prefix 10.10.0.0/16 –subnet-name HK-SUB-PROD –subnet-prefix 10.10.1.0/24

  • Pour afficher des informations détaillées sur un VNET spécifique (hk-vnet01 dans l’exemple suivant), la commande suivante est utilisée : az network vnet show -n « hk-vnet01 » -g « hk-ResourceGroup »

  • Pour supprimer un VNET spécifique (hk-vnet02 dans l’exemple suivant), la commande suivante est utilisée : az network vnet delete -n hk-vnet02 -g hk-ResourceGroup

  • Enfin, pour mettre à jour (modifier) un VNET spécifique, la commande suivante est utilisée : az network vnet update suivie du nom du groupe de ressource hébergeant le VNET (paramètre -g) et le nom du VNET à modifier /updater (paramètre -n). Les paramètres –address-prefixes et –add sont à utiliser pour mettre à jour la configuration de votre VNET. Si toutefois vous voulez afficher l’aide en ligne pour la commande az network vnet update, exécutez la commande suivante : az network vnet update -h

 

 

Lors de la phase « étude » d’un projet de migration de Datacenter vers Microsoft Azure, vous devez d’abord étudier, de manière approfondi les Workloads devant ET pouvant être migrées vers de la VM Azure.

Un client m’a récemment fait part du besoin suivant : je souhaiterais déployer une infra WDS (2012 R2 ou 2016) sur Azure (services WDS hébergé sur de la VM Azure).

Cette demande ne peut malheureusement être étudiée ni réalisée car :

WDS (Windows Deployment Services) est un rôle Windows non supporté sur une VM Azure

Vous aurez compris, il est primordial d’étudier et prendre connaissance de la liste complète des rôles, fonctionnalités et logiciels NON SUPPORTES sur une VM Azure avant de se précipiter et commencer à préparer et créer des environnements cibles unitelement … (perte de $$ et du time :)).

Nous allons découvrir à travers cet article les rôles Windows et composants serveurs que vous pouvez migrer « from OnPrem » ou directement déployer dans un environnement Azure VM (en mode IaaS  : Infrastructure-as-aService)

 

Rôles et Fonctionnalités Windows supportés sur une VM Azure

Les rôles suivants sont supportés sur une VM Azure exécutant Windows Server 2008 R2 ou ultérieur :

  • Active Directory Certificate Services (AD CS) : certains Best Practices doivent être respectés pour déployer correctement une nouvelle PKI AD CS ou étendre votre PKI existante vers le Cloud Azure.
  • Active Directory Domain Services (AD DS)
  • Active Directory Federation Services (AD FS)
  • Active Directory Lightweight Directory Services (AD LDS)
  • Application Server
  • DNS Server
  • Failover Clustering *
  • Services de fichiers
  • Services de Stratégie et d’Accès Réseau
  • Services d’impression et de Numérisation de document
  • Services Bureau à distance (RDS : Remote Desktop Services **
  • Web Server (IIS)
  • Windows Server Update Service (WSUS)

 

*  : L’utilisation d’un Cluster à Basculement Windows Server sur une VM Azure présente certains prérequis :

Le Cluster à Basculement doit être exécuté sur les OS Windows Server suivants : Windows Server 2008 R2, 2012 ou 2012 R2

Pour les Cluster Windows Server 2008 R2 et 2012, le Hotfix 2854082 doit être installé sur tous les nœuds du Cluster

Le Cluster doit être accessible par une adresse IP unique

Le Cluster doit utiliser le Stockage Azure

** : si vous disposez déjà des CALs RDS Par-Utilisateur (avec un programme /contrat active SA « Software Assurance »), celles-ci peuvent être installées et utilisées sur un Windows Server « 2008 R2 ou ultérieur » qui tourne sous forme de VM Azure.

Notez donc que les rôles suivants ne sont pas supportés (au moment de la rédaction du présent article) sur une VM Azure exécutant Windows Server 2008 R2 ou ultérieur :

  • DHCP Server
  • Hyper-V
  • Active Directory Rights Management Services (AD RMS)
  • Windows Deployment Services (WDS)

 

En ce qui concerne les fonctionnalités Windows, celles listées ci-dessous ne sont pas supportées au moment de la rédaction de cet article:

  • BitLocker (Chiffrement de disque OS non supporté, mais BitLocker peut être activé et utilisé sur des vDisks de données)
  • iSNS (Internet Storage Name Service)
  • Multipath I/O
  • Equilibrage de la charge réseau (Network Load Balancing)
  • Protocole PNRP (Peer Name Resolution Protocol)
  • Service Routage et accès distant (RRAS : Routing and Remote Access service)
  • DirectAccess
  • Services SNMP
  • Gestionnaire de stockage pour réseau SAN
  • WINS (Windows Internet Name Service)
  • Service de Réseau Local sans fil

 

Note importante : Si vous devez migrer des composants et/ou services d’infrastructure encore hébergés sur des VMs Windows Server 2003, je vous recommande la consultation de cet article pour prendre connaissances de certaines « Useful informations » concernant l’exécution de Windows Server 2003 sur une VM Azure

 

Logiciels & Composants Serveur supportés sur une VM Azure

Les logiciels et composants serveurs suivants peuvent être déployés et exécutés sur une VM Azure :

  • Microsoft BizTalk Server 2013 ou ultérieur (Notez que certaines fonctionnalités BizTalk 2013 ne sont pas supportées en mode VM Azure)
  • Microsoft Dynamics AX 2012 R3 ou ultérieur
  • Microsoft Dynamics CRM 2013 ou ultérieur (Nécessite de l’Azure Premium Storage)
  • Microsoft Dynamics GP 2013 ou ultérieur
  • Microsoft Dynamics NAV 2013
  • Exchange Server 2013 ou ultérieur
  • Forefront Identity Manager 2010 R2 SP1 ou ultérieur
  • Microsoft HPC Pack 2012 ou ultérieur
  • Project Server 2013 ou ultérieur
  • SharePoint Server 2010 ou ultérieur
  • SQL Server 2008 ou ultérieur (version 64-bit uniquement)
  • System Center 2012 Service Pack 1 (SP1) ou ultérieur
  • Team Foundation Server 2012 ou ultérieur

 

En outre, deux autres points « importants » sont à retenir :

L’Upgrade d’OS (Guest OS) d’une VM Azure n’est pas supporté : Si vous souhaitez migrer vos Workloads vers des VMs Azure et migrer (upgrader) ensuite le Guest OS exécuté au niveau celles-ci, sachez que cette option n’est pas supportée. Pensez donc à migrer vos Guest OS (OnPrem) avant toute migration vers Azure.

Seuls les logiciels « Serveur » respectant la politique de Support Microsoft peuvent être hébergés et exécutés sur une VM Azure. Je vous invite à consulter cette page avant toute migration ou déploiement de logiciel serveur sur une VM Azure;

 

Lien utile ! 

Je vous recommande de consulter régulièrement cette page avant tout projet de migration vers des VMs Azure ou déploiement de nouveaux services ou composants en mode IaaS. Si de nouveaux rôles, fonctionnalités ou encore composants /logiciels serveurs sont pris en charge sur une VM Azure, cet article est automatiquement updaté par l’équipe Azure Corp.

Vous aurez compris, cette page est à garder dans son Folder « Web Favoris ».

HK.

Note : si vous n’avez pas encore connecté votre interface Azure CLI 2.0 à votre abonnement Azure, suivez les instructions détaillées dans cet article.

Introduction

Toutes les ressources créés /provisionnées dans Microsoft Azure ont besoin d’être associées à des « Groupes de Ressources ». il s’agit ici d’une fonctionnalité de base du modèle ARM (Azure Resource Management).

Utiliser un groupe de ressource Azure vous permettra de grouper toutes vos ressources Cloud (VM, vNIC, stockage, IP Public..etc) dans une sorte de « Conteneur » et de les gérer de manière centraliser.

La création d’un groupe de ressource Azure peut se faire via :

Le nouveau portail Azure : portal.azure.com

Windows PowerShell : utilisation du module PS Azure

Azure CLI 2.0 : via l’utilisation de la commande az group

Nous allons découvrir à travers cet article la troisième méthode qu’est l’utilisation de l’interface Azure CLI 2.0

Now let’s create & manage our Azure Resource Group via Azure CLI 2.0__O

Comment ça marche ?
  • Ouvrez une Session Windows sur la machine d’administration sur laquelle Azure CLI 2.0 a été installé
  • Lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez az pour vérifier la disponibilité de l’interface Azure CLI 2.0
  • Après avoir saisi et exécuté la commande az, le Menu suivant vous est retourné :

  • La commande qui nous intéresse est Group. En effet, l’interface az dans le contexte group permet de créer et gérer les groupes de ressources Azure.
  • Pour afficher /lister les groupes de ressources existants, saisissez az group list

  • Pour créer un nouveau groupe de ressource, la commande az group create est utilisée. Dans l’exemple suivant, un groupe de ressource nommé « G2R_HK » sera créé. Le paramètre -l (comme location) permet de spécifier la région Azure dans laquelle le groupe de ressource sera placé /hébergé.

  • Le champ « ProvisioningState » vous indique le résultat de l’opération > Succeeded dans notre cas (groupe de ressource créé avec succès).
  • Si vous vous connectez sur le nouveau portail Azure (> portal.azure.com), vous pouvez constater l’existence du groupe G2R_HK créé précédemment

  • Nous allons maintenant afficher des informations sur notre groupe de ressource G2R_HK. La commande az group show G2R_HK est utilisée :

Notez que vous pouvez ajouter des « Tags » à vos groupes de ressources, cela devient vite pratique si vous devez créer plusieurs groupes de ressources pour des entités ou départements spécifiques > e.g : un groupe de ressource pour le département RH, un second groupe de ressource pour le département Compta …

  • Pour ce faire, le paramètre -Tags est utilisé. Dans l’exemple suivant, nous allons créer un nouveau groupe de ressource appelé G2R_RH et nous allons le « TagGer » > Depart-RH, la commande suivante est utilisée :
  • az group create -l WestEurope -n G2R_RH –tag « Depart-RH »

  • Vous pouvez mettre à jour un groupe de ressource existant pour ajouter des Tags si cela n’a pas été fait lors de la création. la commande update et le paramètre –set sont utilisés. Dans l’exemple suivant, les Tags « Depart-IT » « Env=PROD » seront ajoutés au groupe de ressource existant G2R_HK, la commande suivante est donc utilisée : az group update -n G2R_HK –set tags.Depart=IT tags.Env=PROD

  • Enfin, pour supprimer un groupe de ressource Azure, la commande az group dans le contexte « delete » est utilisée. Dans l’exemple suivant, le groupe de ressource G2R_RH sera supprimé : az group delete -n G2R_RH
  • Vous devez confirmer l’opération de suppression en saisissant y comme yes

Azure CLI Tip : pour une meilleure lisibilité du résultat retourné par une commande Az CLI, je vous recommande l’utilisation du paramètre –output suivi de table pour formater les informations retournées au format « Tableau », dans l’exemple suivant nous listons les groupes de ressources disponibles en spécifiant un format de sortie > « Tableau » :

az group list –output table

 

What Next ?

Maintenant que vous avez créé votre (ou vos) groupe(s) de ressource(s), découvrez comment créer votre premier réseau virtuel Azure (VNET Azure) en suivant le HowTo #N°3 Créer et gérer les réseaux virtuels Azure (VNET : Virtual Network)

 

 

 

 

 

 

 

 

===================================================================

Cet article un extrait de l’unique eBook (guide pas à pas en Français :)) sur Azure CLI 2.0. Il sera bientôt disponible sur BecomeITExpert.com  :), so stay in touch les copains.

HK.