Contrôle budgétaire dans Azure

Lors de mes formations sur Azure, il y a un sujet qui revient régulièrement : Est-on capable de répondre aux exigences d’un DAF qui demande un contrôle budgétaire stricte. Autant vous dire qu’essayer d’argumenter avec de la technique. Genre : Maintenant dans Azure on peut envoyer la facture au DAF par mail, ça ne va pas le faire du tout, …

clip_image001

 

Sans contrôle, le Cloud ne sera qu’une promesse non tenue. Problème, le DAF détient les cordons de la bourse. Si nous ne sommes pas capables de répondre à cette simple question, l’expérimentation Cloud va tourner court. Histoire de poser le décor, voilà une liste des risques auxquels nous devons répondre :

  • Comment limiter la consommation pour une population donnée ?
  • Pouvons-nous accorder un crédit à une population donnée ?
  • Comment suivre facilement l’évolution de la consommation ?

 

Malheureusement, il n’y a que dans le cadre d’une souscription de type Enterprise Agreement qu’on est capable de répondre à ces problématiques :

  • La segmentation en départements avec un budget permet de répartir le crédit Azure
  • Chaque département se voit affecté un crédit qu’il est libre de consommer, charge à l’administrateur de le suivre
  • Le suivi de la consommation est réalisable via l’intégration de Power BI : Microsoft Azure Enterprise content pack for Power BI

 

Voilà pour les grandes lignes d’une souscription de type Enterprise Agreement. Maintenant voyons les moyens dont on dispose pour tous les types de souscription.

Azure Spending Limit

Le premier et le plus ancien de tous est la fonctionnalité Azure Spending Limit. Pour les souscriptions autre que CSP & EA, la fonctionnalité est accessible via l’ancien portail https://account.windowsazure.com. Dans l’illustration ci-dessous, ma souscription « Pass Azure » disposait d’un crédit de 85€ de consommation. Arrivé à 0, la souscription sera automatiquement désactivée. C’est à moi, propriétaire de la souscription de venir supprimer la limite de consommation (et d’indiquer un moyen de paiement).

clip_image002

 

A noter que configurer un moyen de paiement n’est pas obligatoire pour les souscriptions de type « Pay-As you go ». Maintenant, charge au propriétaire de suivre sa consommation, … Pour une souscription de type CSP, c’est le partenaire qui propose ce service en configurant un indicateur qui va l’informer de la consommation de son client. Attention, c’est une limite soft, juste un avertissement.

clip_image003

 

Pour un Enterprise Agreement, c’est un suivi de l’administrateur du département. Une notification par mail lui est automatiquement envoyée chaque semaine.

clip_image004

 

Tagger les ressources

Le premier contact du DAF avec une facture Azure est plutôt violent. Sa première question, c’est comment effectuer un regroupement de ces coûts selon différents critères. Savoir qu’il a payé pour du compute c’est bien mais s’il est capable de le refacturer entre les équipes, on l’aide à définir quelle est la participation de chaque entité de l’entreprise pour le poste budgétaire de l’IT. Attention, on ne parle que de coût IT. Avec le IaaS, on peut assez facilement déduire le nombre d’exploitants nécessaires par rapport au nombre de machines virtuelles et l’utiliser comme clé de répartition pour les couts de personnel. Par contre, ce ne sera plus aussi vrai pour le PaaS, encore moins pour le SaaS.

clip_image005

 

Le simple fait de tagger les ressources ne permet pas de contrôler les coûts. Pour cela, il faut forcer l’usage des tags. C’est là que la fonctionnalité Azure Resource Policy. C’est un sujet que j’avais déjà abordé dans un précédent billet (Découverte d’Azure Resource Policy). Maintenant, la fonctionnalité est présente dans le portail au niveau de la souscription avec bonus en plus quelques policies « built-in » bien pensées :

  • Imposer l’utilisation de Tag (pas de tag, pas de déploiement)
  • Affecter un tag par défaut s’il n’est pas spécifié (Pas de code d’imputation comptable, alors c’est celui de l’IT qui sera utilisé, …)
  • Interdire le déploiement de ressources en dehors des régions Azure sélectionnées
  • Interdire l’usage de certains « Sku » de stockage / machines virtuelles

Après, rien ne vous interdit de développer vos propres policies.

clip_image006

 

Ce qui est bien, c’est que ces Policies peuvent être assignées aussi bien au niveau de la souscription que d’un groupe de ressources. Là on tient une fonctionnalité intéressante puisqu’on se positionne avant même de déployer les ressources. Si on a pensé à mettre en œuvre ce type de fonctionnalité avant même de déployer des ressources dans Azure, on a déjà fait un grand pas pour convaincre le DAF. Maintenant, il faut arriver à lui montrer qu’on est capable de réduire les coûts, …

 

Les Quotas

C’est un des premiers sujets qui remonte au près du support Microsoft, l’augmentation des quotas de votre souscription. Si on peut demander l’augmentation des quotas pour les ressources que nous consommons, nous pouvons aussi demander à en réduire la valeur en fonction de nos besoins.

clip_image007

 

Par contre, attention, c’est un type de contrôle « Soft ». Il suffit d’une demande au support pour faire relever la limite. Ce qui est bien, c’est que la demande est nécessairement tracée, on retrouve donc rapidement celui qui a formulé la demande.

 

La mesure des usages

Mettre en place des Azure Resource Policies ne nous protège pas de tout. En fait, à vouloir tout contrôler, on va perdre en agilité. En plus, on peut passer à côté du plus important : La ressource sera-elle décomptée sur ma consommation Azure ou considérée comme un achat externe ? Dans le portail Azure, lorsqu’on déploie une ressource, si on nous demande de valider un achat, c’est que c’est un achat externe, même si celui-ci coute 0€ comme pour Sendgrid :

clip_image008

J’ai bien pensé à utiliser les Azure Resources Policy pour bloquer les déploiements impliquant des achats externes mais j’ai vite trouvé cela très lourd à mettre en œuvre. Déployer des composants comme le système d’exploitation RedHat ou le composant SendGrid peuvent tout à fait être légitimes. Finalement, c’est en se reposant sur la mesure des usages qu’on sera capable d’adresser ce risque. La simple commande PowerShell ci-dessous nous remonte les déploiements de ressources impliquant une facturation tierce :

Get-AzureRMLog | Where {$_.OperationName -eq « Microsoft.Resources/marketplace/purchase/action »}

clip_image009

 

Avec un peu d’industrialisation avec Azure Automation, on devrait être capable d’envoyer un mail au DSI et agir en conséquence. S’il avait demandé à utiliser du Kemp et qu’il se retrouve avec du F5 à la place, il devrait agir rapidement. Le risque est ainsi mieux maitrisé. Si le sujet vous intéresse, je vous renvoie vers un de mes billets sur le sujet : Mais qui est le Dédé qui a fumé 3k dans ma souscription Azure ?

La fonctionnalité Devtest Labs

La fonctionnalité DevTest est vaste. Simplement, c’est un conteneur qu’on met à disposition des développeurs pour générer leurs environnements de dev/test. L’intérêt de la fonctionnalité est de pouvoir rendre le développeur autonome dans ses activités quotidiennes tout en étant assuré qu’on ne va pas exploser les budgets (tout du moins sans en être préalablement notifié). Globalement, cela passe par un certain nombre de fonctionnalités :

  • Limitation fine des machines virtuelles que le développeur peut déployer (limitation des SKU, limitation du nombre d’instance par développeur, …)
  • Capacité à limiter les choix du développeur pour le déploiement de ressources en provenance du Marketplace
  • Capacité à proposer une liste de Custom Images prêtes à être utilisées
  • Mise à disposition d’un coffre-fort numérique pour stocker les secrets utilisés dans l’environnement de développement.
  • Création de « formules de déploiement » pour faciliter la mise en place d’environnements de tests. Ces « formules » peuvent exploiter les secrets du développeur
  • Capacité à fixer une date d’expiration à une machine virtuelle
  • Capacité à réaliser un « auto-shutdown » (ainsi qu’un « auto-Start ») des ressources pour éviter de facturer du compute inutilement.
  • Capacité à limiter les Virtual Networks sur lequel les développeurs peuvent déployer

Ce qui nous intéresse dans la fonctionnalité DevTest, c’est la possibilité de sélectionner les SKU des machines virtuelles mais aussi le contenu issu du Marketplace, aussi bien dans la SKU sélectionnée que le nombre des instances. Un bon argument pour le contrôle budgétaire.

 

Voilà pour les fonctionnalités techniques, maintenant, celle qui trait à la maitrise de la facturation. Pour chaque instance du service DevTest que l’on met en place, on peut définir des seuils de consommation avec pour chaque seuil, la possibilité de notifier mais aussi de déclencher un WebHook.

clip_image010

 

Avec cela, on peut facilement déclencher des actions avec Azure Automation pour éviter les dépassements de consommation. Exemple, arrivé à 95% du montant fixé, on arrête toutes les ressources. Par contre attention, DevTest ne limite pas la consommation. Il se contente de nous indiquer notre consommation actuelle. La mise en place d’une limite de consommation nécessite déjà d’avoir une harmonisation des API de Facturation entre les différents types de souscription.

En jouant avec les fonctions « Auto-Shutdown » et « Auto-Start », on arrive à limiter la facturation des machines virtuelles. Les environnements de développement n’ont pas besoin de fonctionner pendant les week-ends et les nuits en semaine. On peut ainsi économiser jusqu’à 40% de la facture de compute par machine virtuelle.

clip_image011

 

Azure Advisor

Azure Advisor a pour objectif de nous faire des propositions pour optimiser notre usage d’Azure. Les recommandations peuvent porter sur la disponibilité des ressources, la sécurité, la performance ainsi que les coûts.

clip_image012

 

Si Azure Advisor identifie une ou plusieurs ressources (machines virtuelles par exemples) pour lesquelles notre consommation est bien en dessous des capacités mises à disposition, nous serons informés de la possibilité de revoir le sizing de l’instance de la ressource.

 

Les outils tiers

Plusieurs partenaires de Microsoft se sont positionnés sur le marché des outils de suivi budgétaire sur le Cloud. Dans la liste, on peut citer :

La solution proposée par Microsoft est disponible sur Github. Elle n’est pas aussi complète que les autres solutions qui sont-elles payantes mais elle a le mérite d’exister.

clip_image013

 

La solution Azure usage and Billing portal permet à un client de s’enregistrer auprès de la solution pour autoriser la collecte des données de facturation pour ensuite leur permettre d’y accéder via Power BI. A ce jour, le support des souscriptions de type CSP n’est pas encore généralisé chez tous les éditeurs. CSP utilise actuellement une API de facturation bien spécifique qui nécessite des développements additionnels.

 

Conclusion

Pour conclure, la maîtrise de la facturation passera aussi par la capacité à votre organisation d’adopter la plateforme Cloud de Microsoft. On peut continuer à déployer des machines virtuelles pour héberger des applications mais on ne tire pas pleinement des capacités de la plateforme Azure. C’est l’automatisation et l’utilisation des solutions PaaS et SaaS (plutôt que IaaS) qui feront que le coût de revient dans Azure baissera. L’exploitation implique des coûts humains incompressibles. Cela ne veut pas dire que dans un futur proche nous n’aurons plus d’IT-Pro pour gérer nos ressources dans Azure mais qu’ils deviendront plus efficaces dans la gestion d’un plus grand nombre de ressources.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Certification Azure 70-534 : Architecting Microsoft Azure Solutions

Après la certification 70-533, je suis passé à la certification 70-534 : Architecting Microsoft Azure Solutions, avec succès.

clip_image001

 

Ma préparation

Comme base de travail, j’ai utilisé le workshop MOC40442A-Architecting Microsoft Azure Solutions. Je devais donner le cours pour des clients, ça tombait très bien. Avec cette certification, l’objectif n’est pas de savoir mettre en œuvre telle ou telle fonctionnalité d’Azure mais bien de les assembler. Ca implique de se pencher sur les Cloud Design Patterns et comprendre les principales architectures de références. La bonne compréhension des Cloud Design Patterns est essentielle car de là découlent les principales architectures de référence. Il faut prendre un peu de recul par rapport à la technique pure. Rapidement, on va vite s’éloigner de sa zone de confort (la découverte de DocumentDB dans mon cas) et la liste s’allonge rapidement. Ci-dessous quelques sujets que j’ai étudiés et qui peuvent tomber à l’examen :

  • Azure Storage queue versus Service bus queue, lequel choisir ?
  • Service bus topic versus Service bus relay, lequel choisir ?
  • Scénarios autour de Mobile Services & Push Notification
  • Notification hub, quelles sont les limitations de chaque SKU pour bien choisir ?
  • Azure Batch versus Azure HPC, lequel choisir ?
  • Azure HPC : Quelles SKU pour du RDMA ?
  • Redis Cache dans quels scénarios l’utiliser ?
  • Availability Set : Comment assurer la disponibilité d’une application dans Azure (avec contraintes imposées)
  • Haute disponibilité des WebApp dans Azure
  • Une vision générale des limites de chaque service (VM, WebApp, SQL, Event-Hub, Service Bus) pour savoir quelle édition utiliser
  • Media services, comment encore des flux comment les uploader et les diffuser
  • Connaître ses commandes PowerShell voire un peu d’Azure CLI

 

Dans mes révisions j’avais fait le choix de faire l’impasse sur un certain nombre de sujets :

  • Machine Learning : Bonne pioche, je n »ai pas eu de question sur le sujet
  • HD Insight : Bonne pioche, je n’ai pas eu de question sur le sujet
  • Cloud Services : Mauvaise pioche, ça parle encore beaucoup de Cloud Services, donc ne pas le négliger
  • System Center : Mauvaise pioche, avec une unique question sur DPM

Enfin, pour préparer cet examen, j’ai fait le choix d’utiliser les outils de préparation de measureup.com et j’ai été très surpris. Le niveau des questions est très élevé. En fait, les questions du test de préparation de Measureup.com sont bien plus élevées que celles que j’ai eu à l’examen. C’est donc une excellente préparation. Pour information, aucune des questions de Measureup.com ne se retrouve dans l’examen officiel. Donc pour le bachotage, passez votre chemin.

L’examen en lui même

L’examen est organisé de la manière suivante :

  • Une série de questions individuelles (24 de mémoire), un peu comme pour 70-533
  • Trois ou quatre scénarios pour lesquels il faudra élaborer les réponses les plus adaptées en fonction des contraintes exprimées.

 

Pour les questions individuelles, il n’y a pas de mystère, c’est la pratique d’Azure qui fera la différence ainsi que votre logique. Il y a nécessairement des réponses illogiques, à vous de bien lire les questions.

Pour les scénarios, c’est avant tout beaucoup de lecture avant de se précipiter sur les questions, ça permet de bien cadrer le sujet et les contraintes imposées (Business & Sécurité). Point d’attention, les scénarios sont indépendants les uns des autres. Même si on peut marquer les questions pour revenir dessus ultérieurement, rappelez-vous qu’une fois un scénario clos, on ne peut plus revenir dessus.

 

Même si l’examen est aujourd’hui disponible en français, je le déconseille. Toute votre littérature de préparation est en langue anglaise, y compris les tests de préparation. En plus passer l’examen en langue anglaise vous crédite de 30 minutes de plus donc 180 minutes au total.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Azure – Découverte de l’API de Billing

Une habitude que j’ai prise avec Azure, c’est de décortiquer la Release note du module Azure PowerShell tous les mois. C’est le meilleur moyen de détecter les nouvelles fonctionnalités mises à disposition. Donc dans la livraison de Mars 2017, j’ai découvert le module AzureRM.Billing qui contient la commande Get-AzureRMBillingInvoice :

clip_image001

 

Ça vient compléter la capacité à envoyer la facture par mail mise à disposition en Janvier 2017. C’est le prémices d’une API nous permettant d’accéder à la facturation d’Azure. C’est un bon début car lorsqu’on creuse un peu la partie Billing d’Azure, on découvre que cela fonctionne bien différemment pour les souscriptions de type EA ou CSP. Si on tente d’utiliser la commande immédiatement, ça nous répond que nous ne sommes pas autorisés.

Get-AzureRMBillingInvoice -Latest

clip_image002

 

En fait, la fonctionnalité doit être activée au niveau de la souscription dans le nœud « Invoice ».

clip_image003

 

Dès lors que la fonctionnalité est activée et que nous disposons d’un niveau de privilège souscription, nous pouvons extraire les informations de la dernière facture.

Get-AzureRMBillingInvoice -Latest

clip_image004

 

Ceux qui lisent mon blog reconnaissent un Shared Access Signature dans l’URL de téléchargement. On note aussi la présence d’une date d’expiration fixée à une journée. Nous avons là un parfait exemple de mécanisme de type « Key Valet » qui a mis à disposition une clé d’accès pour chaque fichier PDF avec une durée de vie d’une journée. Le contenu de la facture contenant des informations personnelles, il est logique que la date d’expiration soit aussi courte. Pensez juste à préciser ce point à votre DAF lorsque vous lui communiquerez l’URL.

Pour finir, on constatera la présence du rôle Billing Reader qui autorise ceux qui y sont associés d’accéder à la facture. C’est très utile pour votre DAF.

clip_image005

 

Attention : Au moment où j’écris ce billet, la nouvelle API de facturation n’est pas encore utilisable dans tous les types de souscriptions. Techniquement, le rôle Billing Reader est bien disponible en EA/CSP, par contre, vu qu’il n’est pas possible d’activer la fonctionnalité dans le portail, la seule réponse que l’on obtient est Bad Request avec la commande PowerShell. C’est un sujet qui évoluera certainement dans le temps.

Maintenant le DAF n’a plus besoin d’être Owner de vos souscription pour accéder à la facture.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Pourquoi ADCS ne délivre des certificats que de deux ans maximum?

Lorsqu’on une installe une PKI même pour un usage purement technique, on a la tentation de réaliser l’installation via l’interface graphique, en se passant de fichiers CAPolicy.Inf et Policy.Inf. C’est ce que j’ai encore fait cette semaine et c’était une erreur. Dans mon cas, le besoin semblait simple, pourtant, je suis tombé sur un os : Pourquoi ma PKI refuse de me délivrer des certificats d’une durée de vie de plus de deux ans ? Il m’a fallu quelques minutes pour réaliser mon erreur. En l’absence de précision, une installation « Quick/Next/Finish » utilise les valeurs par défaut. Donc sans expression de besoin, il nous faut aller explorer la base de registre :

Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

clip_image001

En creusant, la configuration, j’ai retrouvé les deux paramètres en relation avec mon problème :

  • ValidityPeriod
  • ValidityPeriodUnits

Le besoin exprimé étant de pouvoir délivrer des certificats d’une durée de vie de trois ans, une petite reconfiguration s’impose. Réalisé à l’ancienne, cela donne cela :

CertUtil.Exe -SetReg CA\ValidityPeriodUnits 3

CertUtil.Exe -GetReg CA\ValidityPeriodUnits

clip_image002

Après un redémarrage du service de l’autorité de certification, mon problème était corrigé. Conclusion, même pour une PKI à usage technique, il faut toujours préparer la mise en œuvre d’une autorité de certification. Une bonne lecture sur le sujet : The DOs and DON’Ts of PKI – Microsoft ADCS.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Multiples adresses IP par carte réseau dans Azure

Pendant longtemps, Azure nous a limité dans le nombre d’adresses IP que l’on pouvait associer à une seule interface réseau : Une adresse IP publique et une adresse IP privée. La seule solution pour avoir plusieurs adresses IP publiques sur une même machine virtuelle était d’avoir plusieurs adresses IP publiques. Quand on travaille avec des Virtual Appliances dans Azure, c’était une limitation majeure dans le cas de Kemp, ma VLM Kemp ne pouvait avoir qu’une seule VIP. Il n’était pas possible de cumuler plusieurs Virtual Services utilisant chacun une adresse IP publique distincte. La fonctionnalité est GA depuis un peu plus d’un mois, voyons concrètement comment la mettre en œuvre avec la création d’une interface réseau dans les règles de l’art :

Je pars du principe que le Virtual Network existe. On va récupérer les informations le concernant avec la commande « Get-AzureRmVirtualNetwork » :

$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName Network -Name AdatumVnet

$vnet

clip_image001

 

Dans ce Virtual Network, je sais qu’il y a un Subnet nommé « Adatumsubnet ». On va en avoir besoin car c’est à un subnet qu’une interface réseau est lié :

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name Adatumsubnet -VirtualNetwork $vnet

$subnet

clip_image002

 

Pour que notre interface réseau puisse avoir plusieurs adresses IP, nous devons mettre en place plusieurs configurations IP. Chaque configuration IP étant composée d’une adresse IP privée voire d’une adresse IP publique. Commençons par créer notre première adresse IP publique :

$publicIP1 = New-AzureRMPublicIpAddress -name « MyPublicIP1 » -ResourceGroupName Network -Location « West Europe » -AllocationMethod static

$publicIP1

clip_image003

 

Nous avons une adresse IP publique, passons à l’adresse IP privée. Par défaut, le DHCP d’Azure nous fournirait la première adresse IP disponible sur le subnet. J’ai fait le choix d’avoir une adresse IP privée statique. La commande « New-AzureRmNetworkInterfaceIpConfig » permet de créer notre première configuration IP dans la variable $Ipconfig1.

$IpConfig1 = New-AzureRmNetworkInterfaceIpConfig -Name « Ipconfig1 » -Subnet $subnet -PrivateIpAddress ‘192.168.1.10’ -PublicIpAddress $PublicIP1 -Primary

$IpConfig1

clip_image004

 

La seconde configuration IP sera beaucoup plus simple, avec uniquement une adresse IP privée allouée en mode dynamique :

$IpConfig2 = New-AzureRmNetworkInterfaceIpConfig -Name « Ipconfig2 » -Subnet $subnet

$IpConfig2

clip_image005

 

Note : On voir bien la différence avec la première configuration IP. La propriété « PrivateIpAllocationMethod » est ici configurée à « Dynamic » alors que pour la première interface, elle était configurée à « Static ».

 

Nous avons tous les éléments pour créer notre interface réseau comprenant nos deux configurations IP. Nous connaissons déjà la commande « New-AzureRMNetworkInterface ».

$NIC = New-AzureRMNetworkInterface -Name « NetworkInterface » -ResourceGroupName Network -Location ‘West Europe’ -IpConfiguration $IpConfig1, $IpConfig2

$NIC

clip_image006

 

Une fois la création terminée, on doit pouvoir constater les résultat suivant dans le portail :

  • Notre interface réseau dispose bien de deux configurations IP
  • La première comprend une adresse IP privée statique et une adresse IP publique elle aussi en statique
  • La seconde comprend uniquement une adresse IP privée allouée dynamiquement

 

clip_image007

 

Dans mon exemple, nous avons simplement illustré le fait d’avoir plusieurs configuration IP. Si nous voulions avoir plusieurs adresses IP publiques associées à une seule interface réseau, il aurait juste fallu avoir plusieurs configuration IP, chacune ayant une adresse IP publique associée.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Configurer sa première Appliance Kemp dans Azure

J’avais déjà utilisé Kemp par le passé pour DirectAccess : Monitoring DirectAccess with Kemp. Vu que sous certains aspects ça ressemble beaucoup à ce que j’ai connu avec du TMG ou de l’UAG, j’ai décidé de passer un peu de temps avec. Vu que je passe beaucoup de temps dans Azure, cela impliquait de pouvoir monter des labs de manière industrielle. Tout de suite on pense à développer un template ARM. Sur le principe, je suis d’accord, cependant, c’est développer beaucoup d’énergie pour un sujet qui n’apportera pas beaucoup de gain. On ne déploie pas autant de machines virtuelles que d’Appliances virtuelles Kemp.

C’est pour cette raison que j’ai décidé d’explorer la création d’une Appliance virtuelle Kemp en PowerShell. Sur le papier, cela ressemble beaucoup à une machine virtuelle pour un quelconque Linux. Pourtant, il y a quelques subtilités à prendre en compte :

  • Kemp est un fournisseur du MarketPlace, ça change un peu les choses pour la déclaration de l’image source à utiliser (notion de plan)
  • L’Appliance virtuelle aura deux interfaces réseau (les templates mis à disposition sont tous mono-carte)
  • Un peu de sécurité (Network Security Group) est nécessaire pour faire les choses dans les règles de l’art

 

Pour les prérequis, je considère que les éléments existent préalablement :

  • Resource Group
  • Storage Account
  • Virtual Network avec ses deux Subnets

 

Mon objectif est de déployer un Load Balancer Kemp avec deux interface réseau. Ci-dessous les prérequis techniques de mon déploiement :

$LocationIPR = ‘<Azure Region Name>’

$ResourceGN = ‘<Resource Group Name>’

$VnetName = ‘<Virtual Network Name>’

$subscriptionname = ‘<Subscription Name>’

$StorageAccountName = « <storage account name> »

$storageAccountResourceGroupName = « <Storage Account Resource Group> »

$FWName = « <Virtual Machine Name> »

$instanceSize = « Standard_D3_v2 »

$subnetFrontName = « Front »

$frontIP = « 10.1.0.4 »

$subnetBackName = « Back »

$backIP = « 10.2.0.4 »

$reservedIPName = « FrontReservedIP »

$publicNICName = $FWName + « _ » +$subnetFrontName + « NIC »

$privateNICName = $FWName + « _ » + $subnetBackName + « NIC »

$FWPublicIPName = $FWName + « _ »+ « PublicIP »

$diskName = $FWName + « _OSDisk »;

clip_image001

Première subtilité Kemp, le nom du compte « root » de l’Appliance, ce sera « BAL ». On peut spécifier ce que l’on veut, ce sera toujours « BAL » pour le compte par défaut. On ne va donc pas le contrarier et générer un objet de type « SecureString » pour personnaliser le mot de passe initial.

$FWAdminUser = « bal »

$FWPassword = « LeMotDePasseIlaChangé! »

$SecurePassword = ConvertTo-SecureString -String $FWPassword -AsPlainText -Force

$FWSecureCredential = New-Object -TypeName « System.Management.Automation.PSCredential » -ArgumentList $FWAdminUser, $SecurePassword

clip_image002

 

No-Comment, …

$cred = Get-Credential

Login-AzureRmAccount -Credential $cred -SubscriptionName $subscriptionname

clip_image003

 

La première étape, c’est d’identifier le fournisseur nommé « Kemp Technologies » dans la région qui nous intéresse : West Europe :

$publisher = « kemptech »

$publishername = Get-AzureRmVMImagePublisher -Location $LocationIPR | Where {$_.Publishername -eq $publisher}

clip_image004

 

Puis d’identifier la ou les offres proposées par ce fournisseur. Avec Kemp, nous avons deux offres. La solution Kemp 360 Central est une Appliance destinée à centraliser l’administration d’un ensemble d’Appliances Kemp, l’offre qui nous intéresse est donc « VLM-Azure ».

Get-AzureRmVMImageOffer -Location $LocationIPR -PublisherName $publishername.PublisherName

clip_image005

 

$Offer = « vlm-azure »

$ImageOffer = Get-AzureRmVMImageOffer -Location $LocationIPR -PublisherName $publishername.PublisherName | Where {$_.Offer -eq $Offer}

clip_image006

 

Prochaine étape, la SKU ou l’édition en français.

Get-AzureRmVMImageSku -Location $LocationIPR -PublisherName $publishername.PublisherName -Offer $ImageOffer.Offer

clip_image007

 

Celui qui va m’intéresser est l’édition « FreeLoadMaster », c’est pour du test :

$skuname = « freeloadmaster »

$sku = Get-AzureRmVMImageSku -Location $LocationIPR -PublisherName $publishername.PublisherName -Offer $ImageOffer.Offer | Where {$_.Skus -eq $skuname}

$sku

clip_image008

 

Le Marketplace propose toujours les trois dernières versions d’une solution. Il est donc logique de trouver cela :

Get-AzureRmVMImage -Location « West Europe » -PublisherName $publishername.PublisherName -Offer $offer -Skus $sku.skus

$image = Get-AzureRmVMImage -Location « West Europe » -PublisherName $publishername.PublisherName -Offer $offer -Skus $sku.skus | Select -Last 1

$image

clip_image009

 

Seconde subtilité, celle du Marketplace et la manière de référencer l’image à utiliser. Celle-ci vient du Marketplace Azure. Pour un déploiement automatisé, il nous faudra deux choses :

  • Définir la notion de plan (quelle ressource déployer)
  • Autoriser le déploiement automatique pour cette ressource

Pour la notion de plan cela se présente ainsi :

$vm1 = New-AzureRmVMConfig -VMName $FWName -VMSize $instanceSize

Set-AzureRMVMOperatingSystem -VM $vm1 -Linux -Credential $FWSecureCredential -ComputerName $FWName

Set-AzureRMVMSourceImage -VM $vm1 -PublisherName $image[0].PublisherName -Offer $image[0].Offer -Skus $image[0].Skus -Version $image[0].Version

$vm1.Plan = @{« name »= $sku.skus; « publisher »= $image.PublisherName; « product » = $image.Offer}

clip_image010

 

Note : Depuis la version 1.2.2 du module AzureRM, on dispose de la commande Set-AzureRmVMPlan.

Pour le second, cela se passera dans le portail, au niveau de la souscription. Nous avons un menu nommé « Programatic Deployment ». On remarque qu’il n’y a pas de menu pour ajouter / supprimer les fournisseurs du MarketPlace. Pour ajouter le fournisseur Kemp Technologies, j’ai dû réaliser un déploiement en utilisant le portail. Attention, le modèle d’autorisation ne considère pas que le fournisseur mais aussi la solution déployée.

clip_image011

Les bases sont posées. On revient maintenant sur du classique avec la déclaration du disque OS de notre future machine virtuelle.

$storageAccount = Get-AzureRmStorageAccount -ResourceGroupName $storageAccountResourceGroupName -Name $StorageAccountName

$osDiskURI = ($storageAccount.PrimaryEndpoints.Blob.ToString() + $FWName + « / » + $diskName + « .vhd »).ToLower()

Set-AzureRMVMOSDisk -VM $vm1 -Name $diskName -VhdUri $osDiskURI -CreateOption fromImage

$osDiskURI

clip_image012

Ma machine virtuelle devra avoir deux interfaces réseau, dont une avec une adresse IP publique et un nom DNS associé.

$vnet = Get-AzureRMVirtualNetwork -Name $VnetName -ResourceGroupName $ResourceGN

$subnetFront = Get-AzureRMVirtualNetworkSubnetConfig -Name $subnetFrontName -VirtualNetwork $vnet

$subnetBack = Get-AzureRMVirtualNetworkSubnetConfig -Name $subnetBackName -VirtualNetwork $vnet

$publicIP = New-AzureRMPublicIpAddress -name $FWPublicIPName -ResourceGroupName $ResourceGN -Location $LocationIPR -AllocationMethod Dynamic -domainNameLabel ($FWName.ToLower() + (Get-Random -Minimum 1 -Maximum 100))

$PublicIP

clip_image013

 

Déployer une machine virtuelle avec une adresse IP publique sans Network Security Group est criminel. Vu que ça coute pas grand-chose et que cela ne nécessite que quelques lignes de PowerShell, nous allons faire l’effort pour filtrer le trafic réseau entrant pour uniquement deux protocoles :

  • Le portail d’administration de l’Appliance (8443 en HTTPS)
  • Le port SSH d’administration de l’Appliance

 

$NSGrule1 = New-AzureRmNetworkSecurityRuleConfig -Name « KempWebConsole » -Description « Allow Kemp web console Access » -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 8443

$NSGrule2 = New-AzureRmNetworkSecurityRuleConfig -Name « KempSSHConsole » -Description « Allow Kemp SSH Access » -Access Allow -Protocol Tcp -Direction Inbound -Priority 101 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 22

$NSG = New-AzureRmNetworkSecurityGroup -ResourceGroupName $ResourceGN -Location $LocationIPR -Name ($FWName.ToUpper() + « _NSG ») -SecurityRules $NSGrule1, $NSGrule2

$NSG

clip_image014

 

Nous avons maintenant tout ce qu’il nous faut pour créer la première interface réseau et l’associer à notre objet machine virtuelle en cours de construction :

$frontNIC = New-AzureRMNetworkInterface -Name $publicNICName -ResourceGroupName $ResourceGN -Location $LocationIPR -PrivateIpAddress $frontIP -SubnetId $subnetFront.Id -PublicIpAddressId $publicIP.Id

$frontNIC.NetworkSecurityGroup = $NSG

$frontNIC | Set-AzurermNetworkInterface

Add-AzureRMVMNetworkInterface -VM $vm1 -Id $frontNIC.id -Primary

clip_image015

Note : C’est à cette première interface réseau qu’a été associé notre Network Security Group. Une fois la configuration de notre Appliance Terminée, je recommande vivement de reconfigurer les règles pour limiter l’accès à ces protocoles.

Il y a un sujet que je n’aborde pas dans cet article, c’est comment notre Kemp va-t-il pouvoir porter des VIP? Jusqu’à il y a peu, l’utilisation des adresses IP publiques sur les machines virtuelles étaient limitées en deux points :

  • Seule l’interface réseau « primaire » d’une machine virtuelle peut disposer d’adresse IP publique
  • Une interface réseau « primaire » ne peut avoir qu’une seule adresse IP publique

Au moment où j’écris ce billet, ces limitations sont encore d’actualité mais de nouvelles fonctionnalités actuellement en Preview vont permettre d’oublier ces limitations : Step-by-Step: Setup Multiple Public IPs on a VM in Azure.

La démarche pour la seconde carte réseau est identique à deux subtilités près. La première est que cette seconde interface ne sera pas considérée comme « primaire » mais comme « secondaire » et qu’aucune adresse IP publique n’est associée à cette interface.

$backNIC = New-AzureRMNetworkInterface -Name $privateNICName -ResourceGroupName $ResourceGN -Location $LocationIPR -PrivateIpAddress $backIP -SubnetId $subnetBack.Id

Add-AzureRMVMNetworkInterface -VM $vm1 -Id $backNIC.id

clip_image016

Nous en arrivons à la fin. La construction de notre objet machine virtuelle est terminée. Il ne nous reste plus qu’à ordonner son déploiement avec une dernière commande PowerShell :

New-AzureRMVM -ResourceGroup $ResourceGN -VM $vm1 -Location $LocationIPR

clip_image017

 

Après quelques minutes de déploiement, on devrait être en mesure de joindre le portail d’administration de notre Appliance pour s’authentifier. Dans mon cas, il est accessible à l’URL suivante : https://kempwaf0126.westeurope.cloudapp.azure.com:8443. Lors de la première connexion authentifiée, on arrive immédiatement à la configuration de la licence. Munissez-vous de votre Kemp-ID pour réaliser l’activation en ligne et vous pourrez commencer à configurer votre Appliance virtuelle Kemp

clip_image018

 

Maintenant, quelques détails purement Kemp :

  • Ne cherchez pas à déployer une quelconque VM Extension dans la machine virtuelle, le Linux VMAgent ne s’installera pas
  • Ne cherchez pas à activer le mode Transparency dans la configuration vos virtual services.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Shared Access Signature with stored Access Policy

Pendant mes cours Azure, lorsqu’on en arrive au stockage on parle rapidement des Shared Access Signatures. C’est le seul mécanisme qui est visible depuis de portail Azure pour gérer plus finement l’accès au stockage.

clip_image001

Le problème, c’est que ce mécanisme présente un certain nombre de contraintes :

  • SAS est une URL publique. Toute personne qui détient cette URL peut l’utiliser tant que les conditions exprimées lors de sa création restent valides.
  • Tant que l’URL est valable, on peut l’utiliser. En fait le seul réel moyen de la révoquer une clé SAS consiste à renouveler la clé primaire / secondaire qui a été utilisée pour délivrer la clé SAS.

C’est là que le mécanisme SAS with Stored Access Policy prend tout son sens :

  • Ce n’est pas une URL mais uniquement une clé d’accès pour un conteneur donné. Il faut donc disposer des deux informations pour exercer le niveau de privilège accordé
  • C’est une politique référencée que l’on peut mettre à jour ou même révoquer

Bref, cela n’a que des avantages par rapport aux clé SAS classiques telles que présentées dans le portail. Le seul truc, c’est que c’est un peu plus compliqué à mettre en œuvre car même en PowerShell, ce n’est pas nativement implémenté.

Histoire d’illustrer un peu la chose, nous allons mettre à disposition un fichier nommé secret.txt dans un conteneur lui-même nommé « topsecret » pour lequel la politique d’accès a été maintenu à « Private ». Le tout est dans un storage Account dont l’existence est-elle publique : . Objectif, se faire délivrer une clé d’accès pour le conteneur.

Pas la peine de présenter la première partie, c’est de l’initialisation Azure tout ce qu’il y a de classique, oups ARM devrais-je dire.

$cred = Get-Credential

Login-AzureRmAccount -Credential $Cred -SubscriptionName ‘Services de la plateforme Windows Azure pour Visual Studio Profe’

$storageaccount = Get-AzureRmStorageAccount -StorageAccountName tpstockage01 -ResourceGroupName ‘tpstockage’

clip_image002

 

On a besoin des clés primaires / secondaires pour travailler.

$accountKeys = Get-AzureRmStorageAccountKey -ResourceGroupName ‘TPStockage’ -Name ‘tpstockage01’

$accountKeys

clip_image003

 

On va utiliser la clé primaire pour se créer un contexte qui va nous permettre de manipuler le Storage Account.

$StorageContext = New-AzureStorageContext -StorageAccountName ‘tpstockage01’ -StorageAccountKey $accountKeys[0].Value

$StorageContext

clip_image003[1]

 

Dans notre Storage Account, nous allons mettre en place un Container. C’est obligatoire car c’est le seul niveau de délégation possible.

$container = New-AzureStorageContainer -Context $storageContext -Name ‘topsecret’

$container

$cbc = $container.CloudBlobContainer

$cbc

clip_image004

 

On notera que l’attribut PublicAccess est bien à « Off » pour le conteneur nouvellement créé. Au passage, nous avons créé un objet CloudBlobContainer que nous allons utiliser ultérieurement. Au passage, on retiendra l’URL d’accès à ce conteneur car c’est à cet emplacement que nous allons venir déposer un fichier avec la commande PowerShell suivante :

Set-AzureStorageBlobContent -File ‘C:\Users\bsaut\Desktop\Secret.txt’ -Container ‘topsecret’ -Blob ‘tpstorage01’ -Context $StorageContext

clip_image005

 

C’est maintenant que cela devient intéressant. On va commencer par récupérer la liste des permissions applicables au conteneur et créer une nouvelle policy. Pas encore de Shared Access Policies et le niveau d’accès au conteneur est bien « Private ».

$permissions = $cbc.Getpermissions()

$permissions

$policy = new-object ‘Microsoft.WindowsAzure.Storage.Blob.SharedAccessBlobPolicy’

$policy

clip_image006

 

Nous venons de créer un nouvel objet pour décrire notre politique d’accès. Nous allons peupler cet objet Policy avec quelques restrictions :

  • Date de début de la permission
  • Date de fin de la permission
  • Le niveau de permission que l’on veut accorder
  • Le nom de notre permission

 

$policy.SharedAccessStartTime = $(Get-Date).ToUniversalTime().AddMinutes(-5)
$policy.SharedAccessExpiryTime = $(Get-Date).ToUniversalTime().AddMinutes(10)
$policy.Permissions = « Read »
$permissions.SharedAccessPolicies.Add(‘SASPolicy02’, $policy)

$cbc.SetPermissions($permissions)

$permissions

$cbc

clip_image007

 

La nouvelle politique d’accès est en place. Au passage, attention sur le nommage des policy, elles doivent être uniques, sinon on actualise une policy existante. La policy est maintenant en place, on peut communiquer la clé d’accès qui s’appliquera au conteneur.

$policy = new-object ‘Microsoft.WindowsAzure.Storage.Blob.SharedAccessBlobPolicy’
$policy

$sas = $cbc.GetSharedAccessSignature($policy, ‘SASPolicy02’)

$sas.Substring(1)

clip_image008

 

La clé d’accès au conteneur (limitée dans le temps) a été révélée, il ne reste plus qu’à la consommer en accolant l’URL d’accès de notre fichier secret.txt avec la clé d’accès. Il faut juste ne pas oublier le séparateur : « ? ». On obtient la clé suivante :

 

Et effectivement, lorsqu’on consomme cela avec un Invoke-WebRequest -Uri « https://tpstockage01.blob.core.windows.net/topsecret/Secret.txt?sv=2015-04-05&sr=c&si=SASPolicy02&sig=1bJvOnNeeLgm1zDGgA9v41KkdgW2K5%2FcSBsE3s8Ottg%3D », on arrive bien à accéder au fichier en question. Pourtant, le conteneur a bien « Private » comme niveau de permission.

clip_image009

 

Si on a pu positionner une stratégie d’accès, on peut aussi la révoquer. Pour cela, on a juste besoin de connaitre son nom :

$permissions = $cbc.GetPermissions()

$permissions

$permissions.SharedAccessPolicies.remove(‘SASPolicy02’)

$Permissions

$cbc.SetPermissions($permissions)

clip_image010

 

Maintenant, vous n’avez plus d’excuse pour ne plus utiliser les Shared Access Signatures with Stored Access Policy.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Débridez la version de PowerShell dans Orchestrator

Dans une autre vie, j’ai fait du Cloud Privé (je sais par les temps qui cours, c’est mal) et donc j’ai passé pas mal de temps avec Orchestrator. On aime, on n’aime pas mais quand on code en PowerShell toute la journée avec Orchestrator, ce qui était très contraignant, c’était d’utiliser uniquement PowerShell 2/3 en version X86. A l’époque j’avais même écrit un billet sur le sujet : « Ne présumez pas de la version de Powershell avec Orchestrator« . J’avais même développé un arsenal de techniques pour contourner le problème.

Mais ça c’était avant que je découvre ce billet : « Run the PowerShell Version of Windows Server Executing the Orchestrator Runbook Service in « Run .Net Script » Activity« . Cette configuration est très intéressante pour exploiter les dernières fonctionnalités de PowerShell. Maintenant, c’est no-limit.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Séance de Cluedo avec ADFS : Authentification ADFS en boucle sur Office 365

On est quelques un à s’être cassé les dents dessus. Le fameux cas ou quoi que l’on fasse nos utilisateurs de services fédérés avec la solution ADFS ne peuvent pas s’authentifier sur Office 365. C’est un cas que l’on peut reproduire avec toutes les versions d’ADFS. En fait, nos utilisateurs peuvent s’authentifier autant qu’ils le veulent, ça les ramène toujours à la mire d’authentification.

clip_image001

Sur ce sujet, Microsoft a écrit de beaux articles :

J’ai eu beau retourner ces articles dans tous les sens, impossible de trouver le pourquoi. J’avais juste quelques premières constatations. Quelque chose me disait qu’il y avait un coupable mais impossible de savoir comment le colonel moutarde avait tué dans la bibliothèque. Voilà quelles étaient mes premières constatations :

  • Si on s’authentifie avec un compte qui n’existe pas ou un mot de passe faux, tout se déroule normalement
  • Du point de vue ADFS, cela fonctionne, j’ai bien un Event qui m’indique qu’un ticket Kerberos a été délivré
  • Ça ne concerne pas tous les comptes (sinon c’est pas drôle)

Après quelques heures de recherche, j’ai exclus Office 365 de la liste des suspects, tout comme les F5 BIG-IP et même les serveurs Web Application Proxy. En procédant par élimination, il ne restait donc que les deux serveurs ADFS de ma ferme. Vu que j’arrivais toujours à reproduire le problème en bloquant l’un ou l’autre de mes serveurs ADFS, j’en ai donc conclus que le problème était partagé par les deux serveurs de la ferme. Plus la peine de descendre plus bas, le coupable est nécessairement à cet étage. C’est en observant le fonctionnement de la ferme ADFS avec des comptes pour lesquels cela fonctionne et d’autres pour lesquels cela ne fonctionne pas que j’ai mis le doigt dessus.

Lorsqu’on reprend le processus de fonctionnement d’ADFS de bout en bout, notre serveur ADFS doit interroger l’annuaire Active Directory. Dans mon contexte, mon infrastructure ADFS utilise un compte de service GMSA. Voyant un token ADFS généré, je me disais qu’il n’y avait pas de problème. Erreur de ma part. J’ai fini par comparer les ACL sur les comptes différents comptes et finir par m’apercevoir d’un détail qui me choquait :

clip_image002

Ça a l’air de rien mais cette permission change tout lorsqu’on regarde un utilisateur, ou même un device :

clip_image003

C’est étrange mais quand elle est là (et que le compte de service de votre ferme ADFS n’est pas membre du groupe Admin du domaine), c’est tout de suite beaucoup plus facile pour ADFS de fonctionner normalement. Avec ces quatre permissions magiques, l’authentification ADFS fonctionne comme un charme. Maintenant qui m’a mis sur la voie ? Une fonctionnalité méconnue d’Active Directory : Effective Permissions, un vieux truc introduit avec Windows Server 2008 R2 !

clip_image004

En comparant les permissions effectives entre un compte pour lequel ADFS fonctionnait et un pour lequel la même infrastructure ADFS ne fonctionnait pas, j’ai fini par comprendre qu’il y avait une différence entre mes deux comptes et trouver les permissions manquantes. Accessoirement, ces permissions sont décrites dans le schéma comme on peut le voir ci-dessous :

clip_image005

Vu que le schéma n’avait pas altéré, j’en ait déduit qu’il y a eu modification des permissions au niveau de la racine du domaine (pas glop). Ne restait donc plus qu’à propager les bonnes permissions.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Certification Azure 70-533 : Implementing Microsoft Azure Infrastructure Solutions

ça c’est fait !

clip_image001

ça faisait longtemps que je devais la passer. J’avais une appréhension car ceux qui l’ont passé avant moi me disaient : Ça parle beaucoup d’ASM, très peu d’ARM. La certification n’était pas à jour par rapport Azure. Pour moi ça posait deux problèmes :

  • Premièrement, je ne fais que du CSP ces jours-ci dont pas possible de pratiquer autre chose que de l’ARM
  • Azure est en perpétuelle évolution. Rien que l’année dernière, Azure c’est plus de 500 nouveaux services ou nouvelles fonctionnalités pour services existants. Si cela se confirmait, cela signifierait que la certification serait totalement déconnectée de la réalité

Heureusement, en préparant ma certification, j’ai découvert plusieurs indices qui m’ont amené à penser que ce n’était pas les cas :

Par contre, cela ne veut pas dire qu’il faille faire l’impasse sur l’ancien Azure (ASM). Même si on ne déploie plus beaucoup de Cloud Services, faut au moins comprendre de quoi on parle. Ce n’est pas encore demain la veille qu’ASM rendra son dernier souffle. Avec les souscriptions Azure CSP, on va clairement dans cette direction.

Comment se préparer

On ne va pas faire de mystères. Il existe bien des outils pour se préparer à la certification. C’est effectivement un accélérateur mais je n’ai jamais été un grand fan. Ce n’est pas par ce qu’on est certifié Azure qu’on sait gérer une infrastructure en production en « Zero Downtime » ni même de concevoir une infrastructure hautement disponible. ça implique de l’expérience et donc de la pratique. Mon premier conseil sera donc de pratiquer pour se préparer à la certification.

Le second, sera de passer par la case formation. Là on dispose de plusieurs options :

  • La formation classique
  • L’auto-formation
  • Microsoft MOOCs

La formation « Classique » que je défends chez ABC-Systèmes. Nous pensons que cette approche est la plus enrichissante car elle permet l’échange entre les stagiaires et surtout la confrontation avec le monde réel. Autre avantage de la formation, pendant sa durée, les stagiaires sont uniquement focalisés sur un seul sujet. Les cours Azure que je délivre sont basés sur les cours Officiel Microsoft que j’enrichi avec mon expérience terrain. Si votre objectif n’est pas nécessairement la certification, c’est la méthode la plus appropriée. Fin de l’autopromotion.

La seconde option en auto-formation implique de la discipline et du temps. Une initiative intéressante en ce moment de la part de Microsoft est ce bundle. Celui-ci propose :

  • L’inscription à l’examen 70-533
  • L’accès à un outil en ligne pour se préparer à la certification 70-533 pendant 30 jours

Dans cette seconde approche, il manque un peu de contenu pour l’auto-formation. Pas de problème, les équipes de DX France ont passé un peu de temps pour concocter plein de contenu dans la Microsoft Virtual Academy :

La dernière option et la plus récente, ce sont les Microsoft MOOCs. L’initiative est intéressante mais implique beaucoup plus de travail. Déjà il n’y a pas de cours MOOC pour préparer l’examen 70-533. Il faudra donc couvrir plusieurs MOOCs pour couvrir tous les sujets de l’examen. Si vous êtes allergiques à l’anglais, passez votre chemin.

 

Quelques sujets à réviser

C’est posé en vrac, je ne donne pas les questions précise de l’examen mais plutôt le thème général :

  • Sachez identifier un workload supporté / non supporté dans Azure. Et oui, DirectAccess n’est pas supporté dans Azure
  • Sachez comment ajouter un disque de données en PowerShell, que ce soit en ASM ou en ARM. Si vous connaissez l’un, l’autre ressemble beaucoup, c’est de la logique
  • Sachez clairement comment uploader un VHD dans Azure et comment le rendre utilisable comme OS utilisable pour créer une machine virtuelle
  • Un Cloud Service, c’est deux fichiers. Sachez clairement à quoi sert chaque fichier même si vous n’allez plus en déployer
  • Sachez mettre en place un CDN. Pour comprendre faites-le au moins une fois
  • Bien connaître les fonctionnalités offertes par chaque édition de App-Services/ Azure SQL
  • Sachez comment activer le chiffrement de disque avec le Key Vault : Découverte d’Azure Disk Encryption (Preview)
  • Sachez à quoi cela sert de locker des ressources dans Azure : A quoi ça sert de locker ses ressources dans Azure?
  • Sachez comment empêcher le déploiement des certains services / SKU de services : Découverte d’Azure Resource Policy
  • Sachez comment mettre en œuvre Azure Site Recovery avec Hyper-V : Azure Site Recovery avec Hyper-V 1/3

 

Quelques tips pour le jour de l’examen

  • Anglais et rien qu’anglais. Le peu de fois que j’ai passé un examen Microsoft en Français j’ai clairement eu l’impression que la traduction était faite par les mêmes équipes qui ont fait la localisation de SCVMM. 120 minutes c’est le temps accordé pour répondre aux questions. En choisissant anglais, ce temps passe à 150 minutes vu que ce n’est pas notre langue natale. De plus, si vous avez utilisé les tests d’entrainement, ils sont en anglais, …
  • L’examen est organisé en section, passer à la section suivante implique qu’on ne peut plus revenir en arrière donc penser bien à clore chaque section individuellement.
  • Un doute, on marque la question. En marquant la question, on a une chance de pouvoir revenir dessus. Qui sait, dans les questions suivantes une autre va pouvoir nous orienter. Un des grands jeux de ce qui écrivent ces questions, c’est de poser deux voire trois fois la question, y a juste un détail qui change, à vous de l’identifier.
  • Quand on sait pas on procède par élimination pour ne conserver que les choix les plus logiques.
  • Utilisez la tablette. Certains sont capables de se faire une représentation mentale, d’autres comme moi doivent dessiner. Moi je dessine.
  • Question Hardcore : On reste calme. L’examen est adaptatif. De temps en temps, une question « hardcore » est incluse histoire de voir comment on se comporte. L’idée est de voir comment on réagit pour savoir si on est au-dessus du niveau général ou en dessous.

 

Voilà pour mon Feedback sur cet examen. Next move : 70-534 : Architecting Microsoft Azure Solutions.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)