Archives de la catégorie ‘Microsoft Azure’

Si vous souhaitez démarrer avec Microsoft Azure, commencez par comprendre tous les composants et services disponibles sur celui-ci.

Je vous propose de consulter la version cliquable d’Azure Periodic Table, disponible à cet URL.

Il s’agit d’une « Big Picture » cliquable qui vous détaille chaque service disponible sur Azure.

C’est un bon point de départ si vous souhaitez vous former sur MS Azure.

 

MS a annoncé au « Ignite 2016″  la disponibilité générale de l’IPv6 pour les Machines Virtuelles (VMs) Azure.

La plupart des Régions Azure (voir liste ci-après) peuvent désormais héberger des VMs « Dual-Stack » : IPv4 + IPv6

Brazil South

Canada Central

Canada East

Central India

Central US

East Asia

East US

East US 2

Japan East

Japan West

North Europe

North Central US

South India

South Central US

Southeast Asia

UK North

UK South 2

West Central US

West Europe

West India

West US

West US 2

 

Notez qu’au moment de la rédaction de cet article, les Régions suivantes ne peuvent faire du hosting de VMs Dual-Stack (IPv4 + IPv6) :

Australia East, Australia Southeast

UK West, UK South

Germany Central, Germany Northeast

USGov Central, USGov East

China North, China East

 

1

Azure RemoteApp, qu’est-ce que c’est ?

Azure RemoteApp est un service Cloud qui vous permet de publier des Apps Windows (tel que Microsoft Office) mais aussi Non-Windows (tel que vos Apps métiers ou third-party) et proposer l’accès à celles-ci depuis n’importe ou et via n’importe quel périphérique.

En effet, l’accès aux Apps publiées se fait via un client lourd « RemoteApp » téléchargeable gratuitement et disponible pour toutes les plateformes, notamment :

  • Windows Client (x86 et x64) : Windows 7 > 10
  • Windows 8.1 RT
  • Windows Phone
  • Android
  • iPhone et iPad
  • Mac OS

Contrairement aux offres rivales comme celle d’Amazon (WorkSpaces), Azure RemoteApp ne permet pas l’accès à l’OS en entier, mais uniquement aux Applications publiées, voir image ci-après :

2

Collections Azure RemoteApp

Le service Azure RemoteApp s’appuye sur la solution RDS (Remote Desktop Services) et fonctionne avec les mêmes concepts que celle-ci : les Collections.

Deux types de Collection Azure RemoteApp existent :

  • Cloud
  • Hybride 

 

Azure RemoteApp : Collection Cloud

Une Collection Cloud est hébergée dans le Cloud Azure et stocke toutes les données des programmes qui y figurent. Les utilisateurs peuvent accéder aux applications en se connectant avec leur compte Microsoft ou leurs informations d’identification d’entreprise, synchronisées ou fédérées avec Azure Active Directory.

Choisissez une collection Cloud quand l’application que vous souhaitez publier ne nécessite pas de connexion à des ressources sur le réseau privé de votre société (par exemple, via un périphérique VPN). Si l’application utilise des ressources sur Internet, OneDrive ou Azure, une Collection Cloud peut répondre à votre besoin. C’est également l’option la plus simple et la rapide à mettre en place.

La « Big Picture » ci-après illuste l’architecture d’un déploiement Azure RemoteApp « Cloud » :

AzureRemoteApp_Cloud

Azure RemoteApp : Collection Hybride

Une Collection Hybride est hébergée dans le Cloud Azure et y stocke également les données, mais elle permet aussi aux utilisateurs d’accéder aux données et aux ressources stockées et hébergées sur des serveurs OnPremise. Les utilisateurs peuvent accéder aux applications en se connectant avec leurs informations d’identification d’entreprise, synchronisées ou fédérées avec Azure Active Directory.

Choisissez une Collection Hybride si vous avez besoin d’une connexion à des ressources sur le réseau privé de votre société. Par exemple, si l’application nécessite un accès à l’une des ressources (OnPrem) suivantes :

  • Serveurs de fichiers
  • Serveurs de base de données

Cette option s’avère généralement plus utile pour les entreprises de taille importante qui possèdent beaucoup de ressources sur leurs réseaux privés qu’elles ne peuvent pas déplacer vers Azure.

La « Big Picture » ci-après illuste l’architecture d’un déploiement Azure RemoteApp « Hybrid » :

AzureRemoteApp_Hybrid

Prérequis

Microsoft Azure est plateforme basée sur une souscription, vous pouvez vous souscrive à Microsoft Azure et bénéficier d’un mois d’essaie de cette plateforme (incluant 150€ offerte par Microsoft) ainsi que tous ses services Cloud associés, y compris Azure RemoteApp.

Comment ça marche ?

Rendez-vous ici.

Niveaux de service & Pricing

4 Niveaux de service sont disponibles pour Azure RemoteApp :

  • Basic
  • Standard
  • Premium
  • Premium Plus

Notez qu’Azure RemoteApp est un service facturé par utilisateur et par mois.

Les informations sur les prix /options /limitations pour chaque Niveau de service sont détaillées dans le tableau ci-après :

7

Note importante : 

Pour les niveaux « Basic et Standard« , chaque Collection RemoteApp requiert au minimum 20 utilisateurs. Pour les niveaux « Premium et Premium Plus« , chaque Collection RemoteApp requiert au minimum 5 utilisateurs. Si le nombre d’utilisateurs est inférieur au nombre requis, vous êtes tout de même facturé pour le nombre minimal d’utilisateurs requis pour cette référence SKU.

Enfin, vous pouvez visionner la vidéo ci-après pour en savoir plus :

Remise exceptionnelles

Au moment de l’écriture de cet article, Microsoft propose une remise jusqu’à 80 % sur les niveaux Azure RemoteApp « Basic et Standard » avec les abonnements admissibles Software Assurance (SA) aux Services Bureau à distance > Offre valable jusqu’au 30 septembre 2016

Estimez vos frais mensuels

Une calculatrice Azure qui vous permet de calculer /estimer rapidement vos factures mensuelles pour votre future déploiement Azure RemoteApp est mise à votre disponible ici.

Il suffit de cliquer sur « Compute » > « RemoteApp » et renseignez les informations demandées :

8

Dans l’exemple suivant, une estimation pour 5 utilisateurs avec 50 heures (d’utilisation par mois /utilisateur) a été réalisée :

9

Comme indiqué dans l’image ci-dessus, l’utilisation du service Azure RemoteApp par 5 utilisateurs  avec 50H d’utilisation /mois s’élève à ~50€ /mois.

Deux nouveaux articles sur la création des deux Collections « Cloud & Hybrid » sont en cours de rédaction (PART 2 et 3), So stay in touch :).

Dans le cadre d’un projet de migration, de réorganisation ou simplement changement de plan d’adressage IP, vous pouvez être amenés à changer le Subnet voire le VNetwork sur lequel une VM ou plusieurs VMs Azure sont placées.

J’aimerais quand même rappeler certaines dépendances entre le réseau Azure et les deux modèles de déploiement disponibles actuellement avec Azure :

Avec ARM (Azure Resource Manager) : chaque VM Azure doit obligatoirement être attachée à un VNET, cela ne peut être évité ni contourné.

Avec ASM (Azure Service Management) : dans ce mode « Legacy », les VMs Azure peuvent bypasser ce prérequis et ne faire parties d’aucun VNET.

Je vous expliquerai à travers cet article comment changer (via Windows PowerShell) le Subnet ou VNET d’une VM Azure existante et ce pour les deux modes « ARM & ASM ».

De plus, les effets de bord et impacts post-changement de VNET y seront également expliquées.

Il est important de comprendre que le modèle Réseau sous ARM est très différent d’ASM.

La « Big Picture » ci-après illustre cette différence entre les deux modèles :

1

Changer de Subnet sous ASM

Le changement de Subnet d’une VM sous ASM est assez simple. Il existe en effet une Cmd-let PowerShell pour Azure qui permet de réaliser cette action facilement : Set-AzureSubnet

Pour en savoir plus : https://msdn.microsoft.com/en-us/library/mt589103.aspx

Le code PowerShell suivant est à utiliser pour changer le Subnet d’une VM Azure existante :

Get-AzureVM –Name $NomVM –ServiceName $NomServiceCloud | Set-AzureSubnet -SubnetNames $NomNouveauSubnet | Update-AzureVM

Note importante : le nouveau Subnet spécifié DOIT FAIRE PARTIE DU MEME VNET que l’ancien Subnet.

Astuce : Vous pouvez exécuter la commande en bypassant le paramètre -Name. Voir l’exemple suivant ou la VM (dont le nom du service cloud est « NNSRV01 ») sera placé sur un nouveau Subnet nommé « Subnet-2 »:

Get-AzureVM NNSRV01 | Set-AzureSubnet -SubnetNames Subnet-2 | Update-AzureVM

2

Changer de Subnet sous ARM

La Cmd-Let utilisée précédemment n’existe plus sous ARM, mais le changement de Subnet reste aussi assez simple dans ce mode, enfin à partir du moment ou vous connaissez l’endroit qui vous permet de le faire.

Il faut noter que sous ARM, ce changement de Subnet s’effectue au niveau de l’objet NIC (Network Interface Card) et non pas au niveau de la VM (cf Big Picture ci-dessus).

Donc pour commencer, il faut d’abord collecter toutes les informations de références de votre VM {VNET /Subnet /NIC), ceci peut se faire via l’utilisation du code ci-après :

 

# Obtenir les informations de références de la VM et vérifier l’Availability Set #
$NomVM = “NNSRV01”
$VirtualMachine = Get-AzureRmVM -ResourceGroupName $NomGdeR -Name $NomVM

# VM Créée dans l’Availability Set
$VirtualMachine.AvailabilitySetReference

# Obtenir les informations de références sur la NIC /Subnet /VNET #
$NIC = Get-AzureRmNetworkInterface -Name $NomNIC -ResourceGroupName $NomGdeR
$NIC.IpConfigurations[0].PrivateIpAddress # ‘10.0.0.4’
$VNET = Get-AzureRmVirtualNetwork -Name $NomVNET -ResourceGroupName $NomGdeR
$Subnet2 = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $VNET -Name $NomSubnet2

Le paramètre de Subnet que vous avez besoin de changer est situé au niveau de la propriété « IPConfigurations ».
Il suffit d’y accéder avec l’index [0] et changer directement la valeur « Subnet.Id » avec l’ID du nouveau Subnet:

$NIC.IpConfigurations[0].Subnet.Id = $Subnet2.Id
Set-AzureRmNetworkInterface -NetworkInterface $NIC

Après avoir effectué cette opération, vous devez confirmer la modification à l’aide d’Azure ARM Network Provider en utilisant la Cmd-Let “Set-AzureRmNetworkInterface”. Notez que l’exécution de cette Cmd-Let prend quelques minutes. Ce temps est requis car Azure redémarre automatiquement la VM et donc un « downtime » sur la VM (et les services hébergés associés) est à prévoir.

Changer de VNET sous ARM & ASM

Au moment de l’écriture de cet article, le changement de VNET d’une VM existante est une opération impossible /non supportée sur Azure (pour les deux modes : ARM & ASM).

Cependant, une technique qui permet de réaliser cette opération existe :

  • Exporter la configuration de la VM
  • Supprimer la VM et garder ses vDisques (fichiers VHDs)
  • Recréer une nouvelle VM avec les mêmes paramètres en prenant en compte les deux éléments suivants :
    • Spécifier le nouveau VNET
    • Réattacher les anciens disques VHDs

MS_Azure

Par défaut, quand vous créez une Machine Virtuelle (VM) depuis le portail de gestion Microsoft Azure ou depuis Microsoft Azure PowerShell, vous n’avez pas besoin de lui attribuer une adresse IP, en effet, celle-ci se voit automatiquement attribuer une configuration TCP/IP incluant une adresse IP faisant parti de la plage d’adresse IP (disponible et attribuable) du réseau virtuel interne.

1

En outre, si vous auriez le même reflex que moi 😀 et tenteriez de configurer manuellement une adresse IP statique sur votre VM, celle-ci n’est conservée que temporairement, en effet, une fois votre VM éteinte ou redémarrée, sa configuration TCP/IP est mise à nouveau en mode « Automatique »

2

Le fait de redémarrer ou d’éteindre la VM implique également la perte de la configuration TCP/IP automatique, ce qui peut être problématique dans certains scénarios, comme par exemple une VM qui fait office de :

Contrôleur de domaine (DC)

Serveur d’Application

Serveur de fichiers

Serveur de base de données

et dont l’adresse IP doit être attribuée d’une manière permanente.

Heureusement que le module « Azure PowerShell » inclut une Cmd-let nous permettant de configurer (réserver) une adresse IP statique sur une VM mais aussi de vérifier sa disponibilité pour éviter tout conflit sur le réseau virtuel interne Azure, il s’agit des Cmd-lets :

Test-AzureStaticVNetIP

Set-AzureStaticVNetIP

Dans l’exemple suivant, je vais simplement utiliser la Cmd-let Get-AzureVM suivie du nom de service Cloud de ma VM (DomainController01) pour obtenir des informations sur mon DC et notamment son adresse IP :

8

Comme vous pouvez le constater, la VM « DC01 » est configurée actuellement avec l’adresse IP > 10.0.0.4, nous pouvons d’ailleurs le confirmer en vérifiant sa disponibilité et ce en utilisant la Cmd-let Test-AzureStaticVNetIP suivie du nom du réseau virtuel (vLABNet dans l’exemple suivant) et de l’adresse IP en question (10.0.0.4 dans notre exemple) :

Test-AzureStaticVNetIP -VNetName « vLABNet » -IPAddress 10.0.0.4

4

Le résultat retourné indique « False ===> Faux » devant l’attribut « IsAvailable ==> EstDisponible » ce qui confirme l’indisponibilité de l’adresse IP 10.0.0.4

Nous allons maintenant réserver cette adresse IP (d’une manière permanente) pour la VM « DC01 ».

How it Works ?

  1. Tout d’abord, il faut éteindre la VM « DC01 » pour libérer son adresse IP :

Saisir la commande suivante en renseignant le nom de service pour cette VM (DomainController01 dans l’exemple suivant)

Stop-AzureVM -ServiceName DomainController01 -Name DC01

Confirmer l’arrêt de la VM en saisissant O comme Oui

5

Dès que la VM est arrêtée, son adresse IP est libérée, nous allons donc vérifier de nouveau la disponibilité de l’adresse IP 10.0.0.4 :

Test-AzureStaticVNetIP -VNetName « vLABNet » -IPAddress 10.0.0.4

6

La valeur de l’attribut « IsAvailable » est cette fois-ci « True » ce qui signifie que l’adresse IP 10.0.0.4 est désormais disponible.

  1. La deuxième étape consiste à réserver cette adresse IP pour la VM « DC01 » pour ce faire, lancez les deux commandes suivantes depuis Microsoft Azure PowerShell :

$VM = Get-AzureVM -ServiceName DomainController01 -Name DC01

Set-AzureStaticVNetIP -VM $VM -IPAddress 10.0.0.4 | Update-AzureVM

7

L’adresse IP 10.0.0.4 est désormais réservée pour la VM « DC01 » et ce, quelque soit son statut : Éteinte, Allumée …

D’ailleurs, il suffit de vérifier la disponibilité de l’adresse IP 10.0.0.4 pour le constater

4

N’oubliez pas de démarrer votre VM via l’utilisation de la Cmd-let Start-AzureVM, voir l’exemple suivant (démarrage de la VM DC01) :

Start-AzureVM -ServiceName DomainController01 -Name DC01

Conclusion

La réservation d’adresse IP pour vos VMs (DC, Files Server, DB Server…) est une tâche à ajouter dans la « ToDoList » si vous envisagez par exemple de promouvoir des DCs /Files Server … sur des VMs Azure.

Lors de la [PART1], nous avons découvert le nouveau mode de déploiement introduit avec RDS 2016 : Personal Session Desktops

Now let’s setup notre infrastructure RDS (VDI) sur MS Azure :).

Comme illustré dans l’image ci-après, 3 VMs dédiées à mon future infra RDS 2016 ont été créées :

1

Note : depuis Windows Server 2012 et 2012 R2, le déploiement d’une infrastructure RDS requiert un domaine AD. une infrastructure AD (vLAB.com) est donc déjà en place, celle-ci est hébergée /gérée par l’unique DC nommé « DC01 ».

Les services de rôles RDS vont être répartis de la manière suivante :

  • VM « RDCB01 » : fait office de Serveur Broker et Web Access Server (RDWA)
  • VM « RDSH01 » : premier serveur Hôte de Session du déploiement
  • VM « RDSH02 » : second serveur Hôte de Session du déploiement

Toutes mes VMs hébergées sur Azure tournent sous Windows Server 2016 Technical Preview 5

Tous les serveurs de déploiement RDS doivent être joint au domaine AD, de plus la gestion à distance (via PowerShell Windows) doit être activée sur chacun des serveurs.

HowTo : Setup(er) votre infrastructure RDS (VDI) 2016 TP 5

-Ouvrez une Session sur le serveur RDCB01 avec un compte « Domain Admin » ou équivalent (Session bureau à distance forcement vu que le serveur est dans le Cloud xD)

-Lancez Windows PowerShell en tant qu’Administrateur et saisissez les commandes suivantes :

#Pour importer le module PowerShell RemoteDesktop

Import-Module RemoteDesktop

#Pour déployer RDS sur les deux serveurs listés ci-haut

New-RDSessionDeployment -ConnectionBroker RDCB01.vLAB.com -WebAccessServer RDCB01.vLAB.com -SessionHost RDSH01.vLAB.com

#Pour ajouter le deuxième serveur RDSH « RDSH02 » au déploiement

Add-RDServer -Server RDSH02.vLAB.com -Role « RDS-RD-Server » -ConnectionBroker RDCB01.vLAB.com

#Pour créer une nouvelle Collection RDS nommée « MyVDICollection » et y ajouter les deux serveurs RDSH

Note : le paramètre –PersonalUnmanaged permet de spécifier le mode « Personal Session Desktops », quant au paramètre -GrantAdministrativePrivilege, il permet d’attribuer le droit « Administrateur local » aux utilisateurs Bureau à distance sur leur Serveur Hôte de Session Personnel.

New-RDSessionCollection -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -SessionHost RDSH01.vLAB.com,RDSH02.vLAB.com –PersonalUnmanaged -GrantAdministrativePrivilege

#Enfin, pour assigner (dédier) des Serveurs Hôtes de Session « Personnels » à vos users, les commandes suivantes sont utilisées. Notez que dans l’exemple suivant, le serveur RDSH01 sera assigné à l’utilisateur ‘dlanoizeley’ (David LANOIZELEY) et le serveur RDSH02 à l’utilisateur ‘hkadiri’ (Hicham KADIRI). Imaginez ça comme une infrastructure VDI « Personnelle » sur Azure :). 

Set-RDPersonalSessionDesktopAssignment -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -User « hkadiri » -Name RDSH01.vLAB.com
Set-RDPersonalSessionDesktopAssignment -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -User « dlanoizeley » -Name RDSH02.vLAB.com

What Next ?

Let’s test our VDI infrastructure 🙂

Le test suivant consiste simplement à lancer le client RDC (Remote Desktop Connection) > outil MSTSC.exe depuis ma machine locale (ou depuis n’importe quel terminal d’ailleurs : Smartphone /Tablette .. App ‘Remote Desktop’) et se connecter à mon RDSH Server dédié, disponible via le service cloud RDSH02.cloudapp.net

2

A bientôt

Keep in touch

Hicham.K

ScriptGuyPic

Avec Windows Server 2016 (encore sous Technical Preview 5 au moment où j’ai écrit cet article), un nouveau mode de déploiement RDS verra le jour.

Actuellement avec Windows Server 2012 et 2012 R2, deux modes de déploiement sont disponibles :

Déploiement de Bureaux basé sur une Session : mode basé sur le serveur Hôte de Session (RDSH : Remote Desktop Session Host) où chaque utilisateur distant exécute une Session sur un OS serveur partagé. Il s’agit du modèle traditionnel {Terminal Server}.

Déploiement de Bureaux basé sur une Machine Virtuelle (VM) : modèle basé sur le serveur Hôte de Virtualisation (RDVH : Remote Desktop Virtualization Host) où chaque utilisateur distant exécute un poste de travail virtuel dédié (VM dédiée : VM Personnelle ou dans un Pool de VM) qui héberge un OS Client. Il s’agit ici de l’infrastructure de poste de travail virtuel, connue aussi sous le nom VDI (Virtual Desktop Infrastructure)

1

Avec la sortie de Windows Server 2016 Technical Preview 2, Microsoft a introduit un nouveau mode de déploiement : Personal Session Desktops ou Server Based Personal Desktop (le nom final n’est pas encore décidé !).

Ce nouveau mode de déploiement RDS combine les deux modes de déploiement disponibles actuellement avec RDS 2012 /2012 R2 (Déploiement basé sur une Session & VM), ce qui signifie qu’avec un déploiement RDS 2016 en mode Personal Session Desktops (ou Server Based Personal Desktop), vous pouvez mettre en place une infrastructure VDI sans utilisation d’OS Client :). ce n’est pas magique ça ?

Le principe est simple, chaque utilisateur distant disposera d’un Serveur Hôte de Session dédié, ce dernier fera office d’un poste de travail virtuel comme dans une infrastructure VDI classique.

Pourquoi dédier un Serveur RDSH pour un utilisateur Bureau à distance ? la réponse est Azure (Offre Cloud de Microsoft pour la partie DaaS {Desktop-as-aService})

En effet, quelque soit le type /niveau d’abonnement sur Microsoft Azure, vous ne pouvez actuellement souscrire à une offre VDI dans Microsoft Azure, vu qu’aucun contrôle /gestion de l’Hyperviseur n’est possible, de plus vous ne pouvez installer /attribuer des Licences aux VMs Clients utilisées dans un scénario VDI dans Azure.

Le nouveau mode de déploiement « Personal Session Desktops » permettra donc d’utiliser une solution VDI dans Microsoft Azure via l’attribution des Serveurs Hôtes de Sessions dédiés sous forme de Poste de travail virtuels.

De plus, de nouvelles améliorations ont été apportées à la fonctionnalité « Expérience utilisateur » (Desktop-experience pour les OS en anglais).

Pour en savoir plus sur la fonctionnalité « Expérience utilisateur », consultez cet article.
Cette fonctionnalité vous permet d’avoir la couche graphique de Windows 10 ainsi que les outils de poste de travail tel que l’Outil de capture, la Table des matières, l’outil de Nettoyage de disque ou encore le Lecteur Windows Media sur vos serveurs RDSH hébergés dans le Cloud.

Notez que depuis Windows Server 2016 (TP*), la fonctionnalité « Expérience utilisateur » est installée /fournie par défaut avec l’OS Server.

Utilisée dans un scénario de déploiement « Personal Session Desktops », vous pouvez proposer à vos end users un environnement VDI (Serveur Hôte de Session dédié sous forme de poste de travail avec un look Windows 10) hébergé chez Microsoft.


La deuxième partie de cet article détaille la « Mise en place d’une infrastructure VDI RDS 2016 sur Microsoft Azure ».