Compte de stockage Azure, il y a beaucoup à dire (Part 2/5).

Niveau : ★★★☆☆

Suite de cette série en 5 parties. La première partie est à retrouver à cet endroit : https://thierrybtblog.wordpress.com/2023/05/26/compte-de-stockage-azure-il-y-a-beaucoup-a-dire-part-1-5/

Dans cette seconde partie, direction la bulle Général.

Ici, quelques unes des fonctionnalités les plus marquantes attachées aux comptes de stockage.

Premier point, la redondance du compte de stockage. Stocker, c’est bien, savoir que les données stockées sont redondées, c’est encore mieux. Ce qu’il faut retenir du stockage Azure, c’est que même dans sa version la plus économique, LRS ( Locally redundant storage), les données sont redondées. Dans un seul et même Datacenter mais dans des baies différentes. Il y a donc par défaut 3 copies (synchronisation) de vos données.

Vient ensuite la redondance de Zone ou ZRS. Les données sont synchronisées sur 3 Datacenter d’une même Zone. Par exemple, 3 Datacenter de la Zone France Central. La perte d’un Datacenter n’impactera pas l’accès aux données.

C’est ensuite une redondance Géographique GRS qui est proposée. Cette fois, les données sont présentes 3 fois sur un premier Datacenter (donc dans un modèle LRS) puis sont synchronisées dans la région paire sur un autre Datacenter dans un modèle LRS également. Ces paires de régions sont pré établies et sont disponibles ici : https://learn.microsoft.com/fr-fr/azure/reliability/cross-region-replication-azure/?WT.mc_id=AZ-MVP-5003759#azure-cross-region-replication-pairings-for-all-geographies

La région géographique France est composée de la région France Centre appairée avec la région France Sud.

Dernier niveau de redondance, un mix de la Zone et de la région appelé GZRS. SLA annoncé à … 99.99999999999999%. Pour atteindre ce niveau de disponibilité, les données sont de Zone sur la première région (ZRS) et locale sur la région appairées (LRS). La différence entre le GRS et les GZRS est donc un passage d’une paire LRS <=> LRS à une paire ZRS <=> LRS. Voici pour bien comprendre ce point une image éditeur :

Autre fonctionnalité, le Cycle de vie de la données. Toutes les données n’ont pas le même besoin de « durée » dans le temps. Mieux même, toutes n’ont pas besoin d’être accédées immédiatement (données chaudes), ou ont besoin de l’être pour une certaine durée avant de devenir des données froides ou données d’archives. C’est à dire des données pour lesquelles ont tolère un temps d’attente avant de pouvoir les consulter. Ce point est intéressant car les coûts de stockage sont différents. Et les différences sont assez conséquentes. Dans le tableau suivant, le Go stocké dans un formule Premium a un coût de 0.15$, ce même Go à un coût de 0.00099$ dans une formule Archive.

Attention, tout de même, il faut prendre en compte les coûts de réhydratation des données. C’est à dire le mécanisme qui permet à une donnée d’archive d’être « récupérée (réhydratée) pour des besoins de consultation.

Tous ces points sont automatiquement gérés par les options de Data management du compte de stockage avec la fonctionnalité Lifecycle management.

L’utilisation est simple et constituée de règles de gestion appliquées à l’échelle des blobs (tous) ou sur certains blobs seulement. Ces règles peuvent être des déplacements entre les différents niveaux de stockage, par exemple un passage de Hot à Archive ou même de la suppression pour des données qui ne sont plus nécessaires. Un exemple en image ci-dessous.

Il serait dommage de se priver de cette gestion automatique !

Avec l’option suivante, l’Immutabilité, ce sont les contraintes de sécurité ou des contraintes légales qui sont couvertes. Rendre une donnée immuable, c’est s’assurer qu’elle ne peut être supprimée / modifiée pendant un intervalle spécifié par l’administrateur. Attention, cette immutabilité est (beaucoup) plus complexe à comprendre qu’il n’y parait. Parce qu’il y a en fait deux types bien différents de données immuables.

La première est appelée Stratégie de rétention de données définie verrouillée, la seconde, Stratégie de conservation légale. Mais il y a aussi une notion d’étendue. L’immutabilité peut s’étendre à une version de blob ou à un conteneur. Tous les scénarios ne se valent pas et doivent être adaptés aux besoin.

Je liste ici quelques points clefs et je renvois à la (très) copieuse documentation éditeur sur le sujet pour une compréhension étendue : https://learn.microsoft.com/fr-fr/azure/storage/blobs/immutable-storage-overview/?WT.mc_id=AZ-MVP-5003759

Stratégies de rétention limitée dans le temps :

  • Durée de conservation maximale = 400 ans
  • Deux stratégies : déverrouillées, ou de tests et donc sans conformité réglementaire. Verrouillées, donc conformes, mais beaucoup plus contraignantes. Par exemple, la stratégie de conservation ne peut être revue à la baisse (possible à la hausse).
  • Inclue un journal d’audit (Utilisateur, le type de commande, horodatages…etc).

Stratégies de conservation légale des données :

  • Inclue un journal d’audit
  • La durée de conservation légale peut être explicitement désactivée. C’est un scénario qui s’applique généralement à des fins d’investigation légale ou archivage juridique. La donnée de conservation n’est pas forcément connue par avance.

Point suivant, Soft Delete / Blob Versioning. Ou comment se sortir d’une suppression accidentelle de données.
Le Soft Delete, c’est un peu la corbeille du compte de stockage. C’est une période de rétention pendant laquelle les objets supprimés sont encore en ligne et peuvent être récupérés . Cette protection s’applique au niveau du conteneur ou au niveau de l’objet Blob. Ci-dessous, un même compte de stockage avec et sans l’affichage des blobs supprimés.

L’activation du filtre de vue (Show deleted blobs) permet d’afficher les fichiers encore retenus par la fonctionnalité. Il est ainsi possible d’exécuter un Undelete pour retrouver le fichier supprimé par erreur. Par défaut, la rétention est fixée à 7 jours mais peut s’étendre à 365 jours.

Le Blob Versioning est complémentaire du Soft Delete. Il est cette fois question de récupérer un fichier encore présent mais dans une version antérieure. Deux options … indispensables à mes yeux.
Si le Soft Delete est l’option cochée par défaut lors de la création d’un compte de stockage, ce n’est pas (encore ?) le cas pour le versioning.

Ce qu’il faut prendre en compte avec ces (belles) options, c’est qu’elles vont tout de même venir augmenter les coûts du compte de stockage. Conserver X versions d’un même fichier ou conserver un fichier supprimé pour une certain durée ne se fera évidement pas sans un coût supplémentaire.

Cette précaution apparait très clairement dans la documentation éditeur, ce ne sera donc une surprise pour personne.

Dernière fonctionnalité (dernière dans celle que j’ai choisi de présenter, il y en a tellement…), le Backup des comptes de stockage dans des coffres de type Backup Vault. J’ai volontairement déplacé cette partie en toute fin de sujet.

Parce que… je ne sais pas encore placer cette fonctionnalité comme un « vrai » besoin.
C’est un sujet « grattage » de tête pour moi. Le couple Soft Delete / Blob Versioning ne rend t-il pas la fonctionnalité de Backup des comptes de stockage « inutile ». Quels cas d’usages ne sont pas couverts, quels cas d’usages pourraient nécessiter une sauvegarde ? C’est une question ouverte à laquelle je n’ai pas la réponse. Les commentaires pour partager votre expérience sur le sujet sont les bienvenus.

Dans la prochaine partie (3/5) de cet article, il sera question de l’accès réseau et de l’exposition des comptes de stockage.

Foreach versus Foreach-Object

Il m’arrive d’animer des formations Powershell, et j’aborde toujours dans ces moments la différence entre le Foreach et le Foreach-Object. C’est une vraie source de confusion, pour différentes raisons.

Je vais essayer dans ce sujet d’apporter un peu d’explications sur ce qui pose vraiment un si gros problème de compréhension.

A mon avis, le plus … « confusant », c’est ce que propose l’IDE intégré aux OS Windows, j’ai nommé Windows Powershell ISE.

Puisque si je cherche à comprendre depuis l’IDE ce qu’est la différence entre Foreach et Foreach-Object … je pars sur de très très mauvaises bases.
La commande d’affichage des alias est formelle, foreach est un simple alias de Foreach-Object.

Pour rappel, un alias de commande Powershell est (source éditeur : https://learn.microsoft.com/fr-fr/powershell/scripting/learn/shell/using-aliases?WT.mc_id=AZ-MVP-5003759&view=powershell-7.3)

Un alias est un nom alternatif ou un nom abrégé pour une cmdlet ou pour un élément de commande, comme une fonction, un script, un fichier ou un fichier exécutable. Vous pouvez exécuter la commande en utilisant l’alias au lieu du nom de l’exécutable.

Oui, mais non. Mais oui, mais finalement, non.

Ce qui est écrit n’est pas faux, mais il faut être très précis sur les termes utilisés.
pour une cmdlet ou pour un élément de commande, comme une fonction, un script, un fichier ou un fichier exécutable

Pas pour une instruction.

Retour sur l’ISE pour profiter de la colorimétrie intégrée et pour commencer à mieux comprendre le sujet. La colorimétrie est une aide précieuse lors de l’écriture de code, elle va rendre le code beaucoup plus lisible, c’est un indispensable. Sur l’écran suivant, test de couleurs avec une variable, une cmdlet ou commande et une instruction.

3 couleurs différentes qui facilitent l’identification. En rouge, la variable $a, en bleu, la cmdlet Get-Command et en bleu très foncé, l’instruction switch.
Même test avec le Foreach.

Saisie du texte Foreac, sans la dernière lettre de la commande, l’IDE à cet instant est sur une couleur de type commande :

Ajout de la dernière lettre (le h), l’IDE à cet instant est sur sur une couleur de type instruction comme le montre la changement de colorimétrie et l’erreur syntaxique en rouge qui attend les informations complémentaires pour cette instruction.

Dernier test avec l’utilisation de la tabulation qui permet de compléter la commande et ainsi d’éviter la saisie complète. L’IDE saute d’une couleur de type instruction à une couleur de type commande.

Il n’en faut pas bien plus pour que la commande et l’instruction soient régulièrement source de confusion.

Ainsi, on n’utilise pas ces deux Foreach dans les mêmes cas.

Foreach-Object attend un « collection » en entrée de commande. Un exemple (colorimétrie = bleu = cmdlet) :

10, 20, 30 | ForEach-Object {write-host "Mon chiffre $($_)"}

Foreach exploite du contenu ligne à ligne depuis des valeurs d’entrées (lists, variables…etc). C’est une instruction d’itération. Un exemple (colorimétrie = bleu foncé = instruction) :

Pour l’aide de la Cmdlet, c’est ici : https://learn.microsoft.com/fr-fr/powershell/module/microsoft.powershell.core/foreach-object?WT.mc_id=AZ-MVP-5003759&view=powershell-7.3

Pour l’instruction, c’est ici : https://learn.microsoft.com/fr-fr/powershell/module/microsoft.powershell.core/about/about_foreach?WT.mc_id=AZ-MVP-5003759&view=powershell-7.3

J’espère que ce court article permettra à certaines / certains d’entre vous de mieux appréhender le Foreach.

Crescendo, inarrêtable Powershell 3/3

Niveau : ★★★★☆

3 ème et dernière partie pour cet article sur Powershell Crescendo.
Partie 1 : https://thierrybtblog.wordpress.com/2023/02/24/crescendo-inarretable-powershell-1-2/
Partie 2 : https://thierrybtblog.wordpress.com/2023/03/17/crescendo-inarretable-powershell-2-3/

Si dans la seconde partie, la commande choisie présentait peu de paramètres, c’est une commande plus complète qui est utilisée dans cette dernière partie. Je n’ai pas trouvé mieux que l’outil Azcmagent (pour AzureConnectedMachineAgent) qui est présenté dans la doc officielle Powershell Crescendo (https://learn.microsoft.com/fr-fr/powershell/utility-modules/crescendo/get-started/research-tool?view=ps-modules/?WT.mc_id=AZ-MVP-5003759).

Voici quelques exemples un peu plus avancés pour « porter » cette commande et en faire une nouvelle commande Powershell. Avec des sous commandes sans paramètres puis des sous commandes avec paramètres.

Une fois l’outil installé, il est lancé dans sa version originale pour afficher les commandes dont il dispose.

Voilà un outil très intéressant puisqu’il propose un ensemble de commandes (Check, Config, Connect …etc). Et que ces commandes sont exploitées pour certaines avec des paramètres de sous commandes.

Je ne reviens pas sur la façon dont est traitée la commande pour être transformée en Applet Powershell, c’est à revoir dans la partie deux de l’article.

L’outil Azcmagent est plus complet que la commande PS de la partie précédente, il est donc possible d’aller plus loin.
Le fichier Json qui a permis de générer le nouveau module est disponible dans la documentation à cette adresse : https://learn.microsoft.com/fr-fr/powershell/utility-modules/crescendo/get-started/create-new-cmdlet?view=ps-modules#completing-the-crescendo-command-configuration/?WT.mc_id=AZ-MVP-5003759
Cette page est utilisée pour tous les exemples de cette 3 ème partie.
Attention, le Json fourni pour la création du premier module comporte une coquille, le code ne fonctionnera pas en l’état. Il faut retirer la « , » en jaune qui ferme le bloc Platform.



Et pour rappel, toutes les commandes de création se feront dans une fenêtre avec élévation de privilèges, sans cela, la création du module fonctionne mais avec des erreurs qui empêcheront de faire fonctionner le module.

Cette nouvelle commande affiche donc les informations demandées. J’utilise ici sur un poste de travail, il n’y a donc rien de concret à afficher au travers d’un agent qui n’est pas présent. Cela ne change rien à l’esprit de la démo.


Le module suivant est encore un peu plus complet puisqu’il comporte des paramètres de sous commandes et c’est donc une nouvelle fois le code de la documentation qui est utilisé.

Cette partie de paramètres est en jaune dans l’exemple.

Une remarque, il y a deux Get dans ce fichier de configuration.
Mais ce sont deux choses très très différentes. Ci-dessus, en rouge, le verbe utilisé par Powershell, en jaune, le paramètre de la commande originale qu’il faut convertir en paramètre Powershell.
Pour bien comprendre cette différence, retour à la commande de départ, non Powershell, azcmagent.exe config --help.

C’est donc bien le paramètre get de la commande azcmagent.exe config qui va être porté sur Powershell.

Il faut utiliser le Json de la doc, mais … attention, il y a … une nouvelle coquille dans cette doc 😉
Le bloc Parameters est déclaré deux fois ce qui n’est pas possible… Il faut retirer dans le Json la partie en rouge.

Puis créer et importer ce nouveau module avec paramètre Get. Il est rendu obligatoire dans le Json ("Mandatory": true,) et attend une propriété lorsqu’il est utilisé.

Reste à renseigner un propriété (ici proxy.url) pour avoir un retour pour cette toute nouvelle commande Powershell.

Il reste un petit soucis d’affichage pour lequel je ne passe pas trop de temps à trouver de quoi il vient. Peut-être la langue Française ou ma version de Powershell.

Dernière modification pour le Json, l’ajout d’exemples dans la commande d’aide. Cette partie n’est pas traitée dans la doc. Je trouve que cet ajout est particulièrement intéressant et peut simplifier l’utilisation de commandes complexes ou mal documentées. Je vais même aller plus loin, je pense que cet ajout peut même justifier de porter certaines commandes uniquement pour cette raison !
Voici le code à ajouter avant de supprimer et de régénérer le module (suppression des fichiers PSM1 et PSD1).

"Examples": [
                {
                "Command": "Get-AzCmAgentConfigProperty -Property proxy.url",
                "Description": "Affiche la propriétés proxy.url",
                "OriginalCommand": "azcmagent.exe config get proxy.url"
                }
            ]

Puis voici la façon dont cette aide est appelée par la commande Powershell. Rien de spécifique ici, toutes les commandes d’aide Powershell se traite de la même façon, l’ajout du paramètre -Examples filtre le retour d’affichage.

Get-Help Get-AzCmAgentConfigProperty -Examples

Voilà qui termine cette troisième partie de documentation Powershell Crescendo. Encore un peu jeune avec notamment quelques coquilles de documentation, le module peut se révéler utile dans certains cas.
Si vous avez des exemples ou des remarques sur cette série d’articles, n’hésitez pas à commenter pour venir discuter de ce sujet !

PS : Pour un schéma exhaustif du Crescendo, direction le Git du projet à cette adresse : https://github.com/PowerShell/Crescendo/blob/master/Microsoft.PowerShell.Crescendo/schemas/2022-06/?WT.mc_id=AZ-MVP-5003759

Profitez gratuitement d’Azure ? Lancez-vous !

Même si cette possibilité d’abonnement gratuit est (très) connue, il y a très souvent de questions sur le sujet lorsque je participe en tant que modérateur aux présentations Microsoft Azure (dont vous trouverez les planning ici => https://azure.microsoft.com/fr-fr/community/events/?WT.mc_id=AZ-MVP-5003759) A noter que ces journées sont gratuites.
Et beaucoup d’hésitations (?), ce qui freine un peu les futurs utilisatrices / utilisateurs. Ainsi, une petit rappel sur les points essentiels est toujours utile.

Quelques liens importants avant de se lancer :
– La FAQ très complète à cette adresse : https://azure.microsoft.com/fr-fr/free/free-account-faq/?WT.mc_id=AZ-MVP-5003759
– Le lien vers l’inscription à l’offre gratuite : https://azure.microsoft.com/fr-fr/free/?WT.mc_id=AZ-MVP-5003759
– Et en bas de page, le chat pour discuter avec l’équipe commerciale, un numéro d’appel et même la possibilité d’une prise de RDV avec un spécialiste Azure.

Sur le lien de l’abonnement, tout est clairement expliqué. Avec par exemple deux types de produits gratuit.
Quels sont les produits gratuits pendant un an ?
Quels sont les produits toujours gratuits ?

Il y a donc une petite distinction sur ces 2 offres.

Mais alors ? Tout est gratuit ou presque sur Azure ?
La devise est => Lancez-vous avec 12 mois de services gratuits. C’est donc bien un offre de découverte dont il est question même si les services sont très nombreux.
Pour cette offre d’essai, il faut bien comprendre que les services sont proposés avec des limitations.

Par exemple, un nombre d’heures d’utilisation pour un VM (Machine virtuelle) ou des versions de services dans un mode standard. Exemple ici d’une machine virtuelle avec 750 heures de compute (calcul) pour un modèle B1S ou du service Form Recognizer (service d’extraction de texte et de structure des documents) limité à 500 pages et avec un niveau de service basique de type niveau S0.


Mais il y a de tout. De la machine virtuelle aux services d’IA / Machine Learning en passant par les services de type « Serverless » comme Functions proposé en bas de page.

Pourtant, pour ne pas… « gâcher » cette offre, quelques consignes et conseils.

Règle numéro 1 : Assistez avant de valider l’inscription à une journée de découverte des fondamentaux Azure. Voir le lien en début d’article. Privilégiez les journées de type Microsoft Azure Virtual Training Day. Excellente introduction aux services et à la console Azure, journées GRATUITES dispensées par les équipes d’experts Azure chez Microsoft.

Règle numéro 2 : Ne pas se précipiter et planifier l’utilisation de l’offre. Il est préférable d’attendre d’avoir du temps, de la dispo, avant de créer son abonnement. Une raison toute simple pour cette règle => Si vous 30 prochaines journées sont occupées … vous allez perdre les 170 € offerts mais limités au 30 premiers jours qui suivent la création du compte gratuit. Ce serait dommage !


Règle numéro 3 : S’appuyer sur les architectures de références pour créer et déployer de manière structurée en respectant les bonnes pratiques et les modèles existants. https://docs.microsoft.com/fr-fr/azure/architecture/browse/?WT.mc_id=AZ-MVP-5003759. Ce lien est un source inépuisable de bonnes pratiques ! A classer dans vos favoris au plus haut de la pile. C’est le lien sur lequel on reviendra encore et toujours.

Alors ? Prêtes / prêt à vous lancer ??

Sécuriser ses WebApp avec un KeyVault (2/3)

La partie 1 de cet article est disponible sur le site à cet endroit :

https://thierrybtblog.wordpress.com/2020/05/15/securiser-ses-webapp-avec-un-keyvault-1-3/

Dans cette seconde partie, le KeyVault et ses accès sont préparés. Le but étant de permettre à l’application de stocker ses informations de manière sécurisé. Mais également d’utiliser si nécessaire des informations d’accès stockés dans son coffre.  Les étapes sont les suivantes :
– Créer un KeyVault
– Donner accès à ce coffre au compte applicatif de la WebApp.
– Créer le secret pour le compte de la WebApp.

La création du KeyVault se fera via Powershell dans le portail (dans RG créé en partie 1).

### Création KeyVault
New-AzKeyVault -Name KeyforApp -ResourceGroupName RG_Grafana -Location ‘West Europe’

Il y a plusieurs points intéressants lors du retour de cette commande :
KV2_1

Le Soft delete est activé par défaut. Pour rappel, ce mécanisme permet de récupérer des données supprimées. On parle de suppression réversible. Dans le cadre d’un coffre de clefs (et de secrets), c’est évidemment très intéressant.

Seconde information importante, l’accès à un coffre de clef est une opération complémentaire à sa création.

KV2_2

Dans le cadre de cet article, il faut donner des droits fins à l’application. Par défaut, la stratégie d’accès n’est pas définie. Le coffre est vierge d’information. Ici, la vue du menu  Stratégies d’accès :

KV2_3
Gestion des accès au coffre.

Ces accès se positionnent en ligne de commande mais également depuis l’interface du portail. Pour faciliter les explications, le portail sera utilisé un peu plus loin dans cet exemple.
Avant de pouvoir positionner ces droits, la WebApp doit  avoir une identité. C’est à dire être inscrite dans l’Active Directory pour se voir attribuer des ressources.
Depuis le menu, sélectionnez Identité, Activé puis sauvegardez les paramètres.

KV2_4
Activation de l’identité de l’application.

La ressource possède maintenant son identité.

KV2_5
Identité de la ressource, vue tronquée.

Comme expliqué plus haut, les règles d’accès au coffre sont paramétrables très finement avec Azure KeyVault. L’accès n’est pas forcément donné dans son ensemble. On peut aller beaucoup plus loin dans ces accès. Depuis le menu du coffre, créez une nouvelle stratégie d’accès. Les droits sont Obtenir et Lister uniquement les secrets pour la ressource GrafanaBlog.

KV2_6
Lister, Obtenir pour le scope Secrets.

Attention à bien sauvegarder les modifications…

Reste à créer un secret dans le coffre pour que l’application puisse l’utiliser. Facile ? Oui ! Mais pas n’importe comment. Avoir les droits sur un coffre que vous venez de créer est une évidence. Mais voir le coffre n’est pas voir les secrets ou les certificats qui y sont stockés. Il faut là aussi créer une stratégie d’accès pour votre compte.

Répétez le opérations de stratégie avec cette fois un peu plus de droits que pour le compte de la WebApp.

KV2_8
Droits complémentaires pour un compte opérateur de haut niveau.

Les accès au coffre en création sont effectifs, créez un secret pour la WepApp. Pour l’instant, avant la partie 3 de cet article, créez deux enregistrements. Un enregistrement qui porte le nom du compte admin de l’application Grafana suffixé -Identifiant. La valeur clé secrète n’a pas d’importance pour l’identifiant (elle en aura plus tard pour la clef secrète). Il est possible d’utiliser la commande Powershell New-Guid pour générer et copier / coller une valeur aléatoire.

KV2_9

Répéter cette opération et créez un enregistrement qui porte le nom du compte admin de l’application Grafana suffixé -Secret. Cette fois, la valeur clé secrète est le mot de passe du compte d’administration Grafana. Sauvegarder les modification. La valeur définie est protégée et n’est accessible qu’aux ayants droits.

KV2_10
La valeur du secret est masquée.

Cette opération termine la seconde partie de l’article. Rendez-vous dans la partie 3 pour utiliser ces informations secrète depuis l’application.

Attention
Attention, les exercices de ce chapitre donnent lieu à facturation pour certains composants. Ne pas oublier de stopper ou détruire les ressources créées si nécessaire.

Attention

Mise à jour Azure Stack 2002, que du bon !

La dernière mise à jour de l’Azure Stack avait quelques mois puisqu’il s’agissait de la version 1910 (Octobre 2019). Voici venue une toute nouvelle version, la 2002 (Février 2020).

Comme d’habitude, une précision très importante, cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack Hub. N’appliquez pas ce package de mise à jour au Kit de développement Azure Stack (ASDK). Au mieux, sur la version ASDK, le portail remontera des erreurs qu’il ne sera pas possible de corriger, au pire … ce sera pire !

Autre information importante à connaitre avant de se lancer dans une mise à jour, il s’agit d’une mise à jour dite Full. Ce type de mise à jour est impactant puisque les durées annoncées sont assez conséquentes.

20021

Attention donc à la planification.

Voici quelques unes des nouveautés, liste exhaustive à consulter sur ce lien :

https://docs.microsoft.com/en-us/azure-stack/operator/release-notes?view=azs-2002#whats-new

  • Nouvelle version du module Powershell Azure Stack Hub admin
  • Amélioration de l’outil de syndication qui permet de télécharger les images de la place de marché depuis une autre machine que le socle Azure Stack. Pour celles et ceux qui utilisaient l’ancienne version, c’est une très bonne excellent nouvelle !
  • Nombreux ajouts sur la collecte des logs et l’amélioration de la supervision et de l’alerting.
  • Fermeture des alertes si elles ne sont plus d’actualité (si j’ai bien compris…).Pour rappel, les versions précédentes conservaient à l’affichage des alertes qui n’étaient plus en cours.
  • 14 fixes et donc un amélioration de la fiabilité dont la liste est disponible sur ce lien : Fixed an issue that caused an alert to not automatically close. The alert indicated that the Azure AD home directory must be configured, but did not close even after the issue was mitigated.
  • Amélioration de la sécurité avec + de 120 CVE mis à jour, liste disponible sur ce lien : https://docs.microsoft.com/en-us/azure-stack/operator/release-notes-security-updates?view=azs-2002
  • Affichage des opérations en cours en arrière plan depuis le portail opérateur. Par exemple, les opérations liées aux sauvegardes qui se déroulaient auparavant sans contrôle visuel possible. Il était même possible de lancer une sauvegarde de l’environnement sans savoir qu’une sauvegarde était déjà en cours…
  • Dans le même esprit, la progression du téléchargement d’un package de mise à jour Azure Stack Hub est désormais visible dans le panneau de mise à jour après le lancement d’une mise à jour.

Ce ne sont que quelques unes des améliorations apportées par cette version 2002.

Dernière information d’importance :

20022

Comme d’habitude, le téléchargement pour une nouvelle installation est à lancer depuis l’outil AzureStackUpdate.exe disponiblesur ce lien : https://aka.ms/azurestackupdatedownload

Besoin d’aide pour comprendre, installer et paramétrer un Azure Stack Hub ASDK (version GRATUITE et mono nœud) ? C’est à lire ici, https://thierrybtblog.wordpress.com/2020/03/11/microsoft-azure-stack-premier-livre-en-francais-chez-eni/, pour le premier et le seul livre dédié au sujet en langue Française.

EPAZSTA_lkn_552x288-publication

Bon ASDK !

Azure Stack ASDK, pourquoi conserver d’anciennes sources ?

L’ASDK Azure Stack est la version non commerciale d’Azure Stack. ASDK pour Azure Stack Development Kit.
Elle est présentée ici :

https://docs.microsoft.com/en-us/azure-stack/asdk/

Pour résumer, de l’Azure On-Premise en mode déconnecté, connecté, ou hybride. Un très beau produit ! Mais qui demande une machine assez puissante pour être testé. A ce sujet, une machine seulement, la version « Development Kit » ne supporte pas l’ajout de nœuds supplémentaires pour augmenter les capacités du Datacenter.

Pour ma part, la partie de la configuration minimale la plus difficile à respecter est la taille de la mémoire. Pour la version actuelle, la configuration demandée peut doucher quelques bonnes volontés …

StackNew2

192 Go, pas toujours facile à trouver pour des tests. Même en entreprise.

Voilà pour le titre de ce sujet. Un exemple de la version -2 de l’ASDK que j’ai précieusement conservé.

Stack1

96 Go, une configuration tout de même plus abordable.

Il existe même des astuces sur les versions les plus anciennes pour installer sur des systèmes ne répondant pas à la configuration minimale. Voir par exemple ce sujet :

https://www.danielstechblog.io/microsoft-azure-stack-technical-preview-3-lower-hardware-specifications/

Je ne pense pas que cette méthode soit toujours applicable sur les versions récentes, mais je n’ai pas testé. Attention, les checks d’installation se font parfois après quelques heures de déploiement, toujours frustrant d’avoir l’impression que finalement, il n’y a pas de blocage … avant de devoir détruire la machine pour redémarrer de zéro (Oui, j’ai testé 🙂 ).

Alors même si l’utilisation de vieilles sources n’est pas toujours recommandée et ne permet pas de profiter des dernières nouveautés, conserver une version -1, -2 ou -3 du produit peut être une bonne opportunité de découvrir le produit sans casser sa tirelire !

Bons tests !

Azure Quickstart Center, How do you want to start ?

En preview, Azure QuickStart Center est un portail d’accueil qui propose des guides de bonnes pratiques pour démarrer son environnement Cloud Azure.

QC1

Réfléchir son environnement Azure ? C’est à voir dans la rubrique « Set up your Azure environnement« .
En détail, ce qui doit être connu avant de se lancer.
-Before you start
-Manage Access
-Organize your resources
-Governance, security, and compliance
-Monitoring and reporting

Ici, l’organisation des ressources.
C’est à connaitre AVANT de se lancer, et c’est très clair dans cet exemple.

QC5

Créer ses premiers services Azure ?
C’est très bien fait, très détaillé, il n’y a vraiment qu’à se laisser guider. Dans l’exemple suivant, un guide « Pas à pas » pour créer ses premières VM. En images, les 3 premières étapes, c’est clair, simple, et efficace !

Étape 1, Deploy or migrate virtual machines.

QC2

Étape 2, Create a Windows virtual machine

QC3

Étape 3, les informations détaillées, avec en bas de page le bouton Create.

QC4

Et le déroulement des étapes suivantes et expliqué sur le même principe.
Voilà de quoi débuter très sereinement.
Indispensable ? Certainement si vous débutez avec le Cloud Azure.

La rubrique « Set up your Azure environnement » permet également même (et surtout ?) si votre environnement est déjà en place de revoir quelques règles élémentaires de bonnes pratiques pour vérifier que tout est conforme au modèle …

Formations Vidéo Azure gratuites

Comment monter en compétence Azure accompagné par des experts ??

En suivant cette série de vidéos très complètes (en Anglais) proposée par Jeffrey Richter (11 livres sur la programmation pour Windows et .NET et plus de 35 000 développeurs Microsoft formés), expert et Architecte logiciel Azure.

Au menu :

– Fondamentaux
– Mise en réseau
– Messagerie avec files d’attente
– Configuration et mise à niveau du service
– Élection du responsable
– Stockage de données

C’est à suivre ici

Avec une mise en pratique possible en profitant de l’offre de 170 € pour découvrir le produit
https://azure.microsoft.com/fr-fr/free/

 

 

LAPS, sécurisation Active Directory (2/3)

Après l’installation de LAPS (https://thierrybtblog.wordpress.com/2018/04/22/laps-securisation-active-directory-1-3/), cet article présente la mise en œuvre de la solution.

Il y a quelques prérequis pour permettre à une machine d’être éligible LAPS.
– La DLL AdmPwd.dll (présente dans le répertoire C:\Program Files\LAPS).
– Les droits de modification de mot de passe pour le compte de la machine (droit de modifier le mot de passe de son compte administrateur).
– Une GPO positionnée sur la machine.

L’installation de la DLL se fait depuis les sources d’installation utilisées dans la partie 1/3 (https://thierrybtblog.wordpress.com/2018/04/22/laps-securisation-active-directory-1-3/).
Double-cliquez sur le MSI pour installer en mode graphique.
Les machines clientes de la solution ne doivent pas installer les outils d’administrations. Seul l’ajout de la DLL AdmPwd.dll  est nécessaire.

Dans les options d’installations, choisir « AdmPwd GPO Extension ».
10

Validez les options par défaut pour le reste de l’installation. La DLL est ajoutée dans le répertoire « C:\Programmes\LAP\CSE ».
11

Une machine de test est créée dans l’OU « OU=LABOLAPS,DC=DSC,DC=Lan ».
Nom de la machine : DSC1

Les machines de cette OU doivent avoir les droits pour modifier leur mot de passe administrateur local. Cette permission est appliquée à l’aide de la commande Powershell suivante :
Set-AdmPwdComputerSelfPermission -OrgUnit « OU=LABOLAPS,DC=DSC,DC=Lan »
Le statut des machines de cette OU devient « Delegated ».
12

Sur un contrôleur de domaine, lancez la console Gpmc.msc. Se positionner sur l’OU cible et choisir « Créer un objet GPO dans ce domaine, et le lier ici… »
13

Nommez la GPO et choisir « Modifier ».
1415

Le modèle d’administration a été enrichi, les paramètres LAPS sont disponibles.
16
17

Pour une mise en œuvre simple de la solution, activez le local admin password et activez puis paramétrez les password settings.
Password Settings :
18

Enable local admin password management:
19

Sur la machine de test DSC1, rafraichir l’application des GPO.
Gpudate /force

Les opérations sont terminées. Pour vérifier le bon fonctionnement, se connecter sur le contrôleur de domaine choisi dans la première partie (1/3), dans cet exemple, DC1.
Lancez l’exécutable AdmPwd.UI présent dans le répertoire C:\Program Files\LAPS.
Renseignez le nom de la machine DSC1, puis « Search » (Le compte utilisé doit avoir les droits nécessaires).
20

La GPO a été appliquée (complexité du mot de passe + 12 caractères). Une connexion sur la machine avec le compte administrateur est possible avec le mot de passe généré. La gestion du mot de passe administrateur local est bien assurée par la machine.

La mise en œuvre présentée est une mise en œuvre simple de LAPS.
La documentation éditeur présente en détail une utilisation avancée de la solution (document LAPS_OperationsGuide.docx).
http://www.microsoft.com/en-us/download/details.aspx?id=46899

Le chapitre 2.2.1 du document (Removing Extended Rights) explique notamment comment restreindre les droits à quelques utilisateurs uniquement.
Le chapitre 5 (Troubleshooting) présente en détail les erreurs courantes.

La partie 3/3 de cet article (à venir) présentera la mise en œuvre de LAPS au travers de DSC.

PS : la mise en oeuvre de la solution LAPS peut aider à la préparation de l’examen Microsoft 70-744, Securing Windows Server 2016.
https://www.microsoft.com/en-us/learning/exam-70-744.aspx