Blog de Florent Appointaire

Blog sur les technologies Microsoft (Windows Server, System Center, Azure, Windows Azure Pack/Azure Stack, etc;)
    • 6/6/2017

    [Azure] Sauvegardez vos base de données SQL Server


    Si vous souhaitez sauvegarder vos serveur de base de données SQL Server, mais que vous êtes limité en terme de stockage ou que vous ne souhaitez pas investir dans du nouveau matériel ou simplement pour sauvegarder votre LAB, vous avez la solution du backup sur Azure. Pour ceci, c’est très simple, et vous ne payez que le stockage.

    Prérequis

    Commencez par créer un compte de stockage de type BLOB:

    Créez ensuite un conteneur à l’intérieur de ce compte de stockage:

    Backup

    Pour sauvegardez votre base de données, cliquez droit sur la base de donnée en question > Tasks > Back Up…:

    Changez la destination vers URL et cliquez sur Add:

    Dans la nouvel fenêtre qui apparait, sélectionnez New Container pour vous connecter à votre compte Azure:

    Connectez-vous ensuite à votre compte Azure en cliquant sur Sign In:


    Une fois connectez, sélectionnez la subscription Azure qui contient le compte de stockage créé au début, le compte de stockage, le conteneur et générez une nouvelle clé avec une date d’expiration en cliquant sur Create Credential:

    Vous avez maintenant la connexion qui est établie avec votre compte de stockage Azure:

    Choisissez le type de backup (FULL) et l’URL sera générée pour votre backup:

    Cliquez sur OK pour démarrer le backup:

    Suivant la taille de la base de donnée, après un certain temps, le backup s’est effectué correctement:

    Je vais maintenant créer une base de donnée vièrge, avec une table:

    Sauvegardez la via la procedure précédente et supprimez la:

    Vous pouvez également automatiser le backup en utilisant le script suivant: https://github.com/Flodu31/PowerShell-Scripts/blob/master/SQLServer/Backup_DB_To_Azure_v1.0.ps1

    Restauration

    Nous allons maintenant la restaurer. Cliquez droit sur Databases > Restore Database…:

    Choisissez la source Device et cliquez sur le bloc avec les … :

    Choisissez le media de type URL et cliquez sur Add:

    Choisissez le compte de stockage qui est déjà enregistré et cliquez sur Add:

    Choisissez la subscription Azure, le compte de stockage et le conteneur où la base de donnée a été sauvegardé. Créez une nouvelle clé:

    Vous êtes maintenant connecté au stockage qui contient le backup de votre base de donnée:

    Choisissez le backup à restaurer et cliquez sur OK:

    Choisissez le backup à restaurer et cliquez sur OK:

    Choisissez le nom de la database où vous souhaitez restaurer la base de donnée et cliquez sur OK:

    Après quelques instants, dépendant de la taille de la base, votre base de donnée a été restaurée correctement:

    Si vous refaites un select, les données sont de nouveau présentes:

    Cette solution a pour avantage d’être rapide, flexible et avec un coût moindre parce que le coût du stockage sur Azure n’est pas elevé compare au fait que vous deviez acheter du matériel, des disques et surtout, avoir quelqu’un pour maintenir l’infrastructure.

    • 29/5/2017

    [Azure] Découverte de KeyVault

    Depuis quelques mois déjà, Microsoft a déployé sur la plateforme Azure, Key Vault. Cette solution vous permet de stocker, directement sur Azure, vos mots de passes, certificats, et même, de gérer/utiliser directement ces valeurs, via des APIs. Les ressources que vous mettez à disposition dans un Key Vault, peuvent être accèder depuis Azure Automation, Azure AD, etc. mais aussi depuis vos applications personnalisées.

    Vous trouverez la documentation ici: https://docs.microsoft.com/en-us/azure/key-vault/

    Concernant le tarif de ce service, ceci dépend de l’utilisation. Les différents tarifs sont détaillés ici: https://azure.microsoft.com/en-us/pricing/details/key-vault/ 

    Création du premier vault

    Pour créer votre vault, allez dans le Market place et cherchez Key Vault. Créez en un nouveau:

    Ceci prend quelques secondes pour déployer le vault. Quand c’est terminé, vous devriez avoir ceci:

    Les Secrets dans Key Vault

    Commençons par utiliser la partie Secrets, qui vous permet de stocker des certificats, mais aussi des mots de passes. Pour enregistrer un nouveau mot de passe, allez dans Secrets > Add et choisissez comme option d’envoie Manual. Fournissez un nom (les espaces ne sont pas autorisés) et la valeur de ce mot de passe. Vous pouvez également dire de quand à quand ce mot de passe est disponible:

    Faites de même pour un certificat de type PFX et renseignez le mot de passe pour ouvrir ce certificate. Si le mot de passe n’est pas bon, vous aurez un message d’erreur:

    Et avec le bon mot de passe:

    Vos 2 ressources sont maintenant déployées:

    Si vous souhaitez voir le contenu des services, il vous suffit d’aller sur le service en question, et de cliquer sur Show secret value et la valeur sera disponible:

    Vous pouvez également avoir un historique avec les différentes versions:

    Les Keys dans Key Vault

    Pour la partie Key, vous pouvez créer une key qui vous permettra de: 

    • Encrypt
    • Sign
    • Wrap Key
    • Decrypt
    • Verify
    • Unwrap Key

     Une fois cette clé généré, elle vous permettra de faire les operations précédentes, en utilisant son Key identifier:

    Vous pouvez utiliser cette clé depuis des applications, via des calls REST API, ou en PowerShell par exemple.

    Vous pouvez également sauvegarder ces clés, directement depuis le portail Azure:

    Cette clé peut être restaurée depuis le portail Azure.

    Les permissions

    Parce que certains mots de passes peuvent être critique, il ne faut pas les mettre entre toutes les mains  C’est pourquoi vous pouvez gérer les permissions.

    Cliquez sur Add new:

    Sélectionnez un utilisateur pour appliquer certaines permissions. Attention, vous donnez l’accès à toute une section, et pas seulement à une seule Keys ou Secrets. Mon utilisateur aura seulement accès aux Keys:

    Cliquez sur Save et connectez-vous au portail Azure avec l’utilisateur en question. Attention de bien donner les permissions Read sur le groupe de ressource où est déployé le Key Vault, sinon l’utilisateur ne le verra pas.

    Ouvrez le Keyvault. Vous devriez avoir accès seulement à la partie Keys en Read/Write:

    C’est bien le cas. N’ayant pas les autorisations nécessaires pour la partie Secrets, j’ai le message d’erreur suivant:

    Et, j’ai un accès en Read sur les policies:

    Conclusion

    Pour conclure, ce service est la pour concurrencer des logiciels comme KeyPass, 1Password, etc. mais avec bien plus de fonctionnalité. En effet, vous pouvez appeler des mots de passes dans vos scripts PowerShell qui se trouvent dans le KeyVault, mais aussi dans vos applications .Net, Java, etc. Ce qui est très pratique pour les mises à jour régulières de mot de passe dans les entreprises (pour la sécurité) sans modifier le code des applications. Et le fait de pouvoir gérer les autorisations est un très gros atout. Et au prix du service, il ne faut surtout pas s’en priver 

    • 23/5/2017

    [PowerShell] Créer un serveur DSC sur Azure

    Aujourd’hui, je vais vous montrer comment déployer un serveur DSC sur Azure, qui aura pour fonction d’être le serveur de référence, et donc, de faire office de serveur PULL.

    Pour commencer, déployez un serveur sur Azure (Windows Server 2016 pour ma part) et autorisez dans le NSG, le port 8080 et 443. 

    Installez la feature suivante ainsi que le module DSC, avec les commandes suivantes:

    Install-WindowsFeature DSC-Service -IncludeManagementTools

    Install-Module xPsDesiredStateConfiguration

    winrm quickconfig

    Enregistrez ensuite le script suivant pour configurer votre serveur DSC: 

    https://github.com/Flodu31/PowerShellDSC/blob/master/DSCPullServer.ps1

    Vous pouvez bien sur ajouter un certificate et adapter les ports. Exécutez le pour générer la configuration MOF pour votre serveur:

    Lancez la configuration du serveur en exécutant cette commande:

    Start-DscConfiguration -Path C:\Users\florent\Desktop\PullDSC\NewPullServer\ -Wait

    Pour vérifier que la configuration a bien été effectuée, rendez-vous sur l’URL suivante sur votre serveur:

    http://localhost:8080/PSDSCPullServer.svc/

    Vous devriez avoir ceci:

    Nous allons maintenant créer la configuration pour notre serveur qui va recevoir l’installation des RSAT. Utilisez le script suivant, en remplaçant le Computername et l’OutputPath: 

    https://github.com/Flodu31/PowerShellDSC/blob/master/DeployRSATDSC.ps1

    Exécutez le:

    Un nouveau fichier MOF est apparu. Il contient la configuration pour votre serveur. Parceque nous allons utiliser ce fichier pour plusieurs serveurs, depuis notre serveur Pull, il faut le renommer. Utilisons un GUID pour que ce soit plus simple:

    Rename-Item -Path C:\Users\florent\Desktop\ClientDSC\dscclienteco01.westeurope.cloudapp.azure.com.mof -NewName "$([guid]::NewGuid()).mof"

    Pour que nos serveurs cibles puissant récupérer les fichiers de configurations, nous devons copier les fichiers dans C:\Program Files\WindowsPowerShell\DscService\Configuration. Utilisez la commande suivante pour faire ceci:

    Copy-Item .\8c3fd4c9-9166-45c1-8559-872e431d8902.mof "C:\Program Files\WindowsPowerShell\DscService\Configuration"

    ls "C:\Program Files\WindowsPowerShell\DscService\Configuration"

    Pour s’assurer de la provenance des fichiers de configurations, il faut générer un checksum associé à la configuration:

    New-DSCChecksum 'C:\Program Files\WindowsPowerShell\DscService\Configuration\8c3fd4c9-9166-45c1-8559-872e431d8902.mof'

    ls "C:\Program Files\WindowsPowerShell\DscService\Configuration"

    Nous allons maintenant appliquer la configuration à notre serveur cible, pour qu’il vienne automatiquement chercher des nouvelles configurations sur le serveurs PULL. Téléchargez le script suivant:

    https://github.com/Flodu31/PowerShellDSC/blob/master/DSCPullMode.ps1

    Adaptez le avec votre ServerUrl que vous pouvez accéder, l’adresse IP de votre serveur cible (connexion en WinRM, donc ça doit être configuré et autorisé) et le GUID qui a été généré pour le fichier de configuration. Executez ensuite le script:

    Un nouveau fichier MOF a été configuré.

    Allez maintenant sur le client et vérifiez avec les commandes suivantes, que la configuration a bien été appliquée:

    Get-DscLocalConfigurationManager

    (Get-DscLocalConfigurationManager).DownloadManagerCustomData

    Après 15 minutes, le client télécharge le fichier, et l’applique sans souci:

    Vous pouvez automatiser beaucoup de chose avec DSC, comme le déploiement de nouveaux serveurs IIS, Active Directory, SQL, etc.

    Beaucoup d’exemples sont disponibles sur Internet et sur Github. Bon courage 

    • 19/5/2017

    [Azure Automation] Migrer vos scripts vers Azure – Partie 2

    Je me suis récemment intéréssé à Azure Automation, de fond en comble. C’est pourquoi, dans les 2 prochains articles, nous allons voir comment utiliser cette outil, de A à Z:

    Aujourd'hui nous allons voir comment migrer les scripts qui sont On-Premises, vers Azure Automation. Dans mon environnement, j'ai 5 scripts PowerShell, qui tournent avec des tâches planifiées:

    • BackupOneDriveFolder: Backup mon dossier OneDrive vers mon Synology & vers un Blob Storage Azure
    • BackuppfSenseConfiguration: Backup la configuration de mon pfSense vers un Blob Storage Azure
    • CheckCertificateValidity: Vérifie la validité des certificats de mes sites web
    • GetHyperVReport: Génère un rapport de mes serveurs Hyper-V
    • UpdateS2SPublicIP: Met à jour mon IP publique, basé sur mon NoIP

    Le principe est simple: migrer ces 5 scripts vers Azure Automation. Je vais avoir besoin de Azure et d'un Hybrid Worker pour exécuter ces scripts. La première étapes est de créer vos Schedules, qui correspondent à ceux de vos tâches planifiées. Sur votre compte Azure Automation, allez dans Schedules et créez les schedules dont vous avez besoin:

    La prochaine étape est d'importer les modules dont vous avez besoin dans vos scripts, dans la partie Modules. Si vous utilisez des Hybrid Worker, installez également les bons modules sur le serveur qui aura la connexion Hybrid:

    Dans la partie Assets, créez les Variables dont vous avez besoin dans vos scripts. Créez également des Credentials:

    Quand les prérequis sont prêts, vous pouvez commencer la migration.

    Premièrement, créez un nouveau runbook, nommez le et choisissez comme type PowerShell. Collez le script PowerShell associé à votre script:

    Adaptez les variables que vous utilisez On-Prem, les utilisateurs/mots de passes ou les clés avec les variables que vous avez créé. Vous utiliserez Get-AutomationVariable pour récupérer les variable et Get-AutomationPSCredential pour récupérer les credentials. Normalement, c'est la seul chose que vous avez besoin de changer. Le script reste le même. Vous pouvez tester le script avec le Test Pane. Et parce que j'ai besoin de copier des fichiers sur mon Synology qui est On-Prem, je dois utiliser un connexion Hybrid Worker:

    Quand le script est terminé, vous devriez voir ceci dans la partie logs:

    Maintenant que vous avez vérifié que votre script fonctionnait correctement, sauvegardez le script en cliquant sur Save et publiez le en cliquant sur Publish. Vous pouvez lier un schedule à ce runbook, basé sur les schedules créés avant. N'oubliez pas de modifier les paramètres en choisissant si vous souhaitez exécuter le runbook On-Prem avec un Hybrid Worker ou sur Azure. Si votre script a besoin de paramètres, vous pouvez les compléter ici:

    Faites ceci pour chaque script que vous souhaitez migrer. Vous pouvez suivre l'exécution des scripts directement dans la partie Jobs de votre compte Azure Automation:

    Comme dans une session PowerShell, si des erreurs apparaissent, vous pouvez les consulter dans les logs:

    Le process est très simple. Après que vous ayez migré tous vos scripts, vous avez juste une console pour gérer les scripts, les logs, les variables, etc. Donc, n'hésitez pas à migrer

    • 11/5/2017

    [Azure AD] Domain Services

    En Octobre 2016, Microsoft a rendu disponible en GA Azure Active Directory Domain Services: https://blogs.technet.microsoft.com/enterprisemobility/2016/10/12/azuread-domain-services-is-now-ga-lift-and-shift-to-the-cloud-just-got-way-easier/

    Ce nouveau service vous permet d’avoir un domain controller sur Azure, géré par les équipes Microsoft. Vous aurez donc la possibilité de joindre des ordinateurs aux domains.

    Concernant le prix de ce service, tout depend du nombre d’objet qu’il y aura. Vous trouverez plus d’informations ici: https://azure.microsoft.com/en-us/pricing/details/active-directory-ds/

    Bien sur, ce service a des limitations, mais vous pourrez tout de même effectuer les operations suivantes:

    • Joindre des machines au domaine
    • Configurer des GPO
    • Gérer les DNS
    • Créer des OU
    • Donner des droits aux ordinateurs 

    Attention, si vous souhaitez installer des composants comme SCCM, Exchange, etc. ce ne sera pas possible car vous ne pouvez pas étendre le schema, etc.

    Nous allons voir comment activer cette fonctionnalité. Attention, à l’heure où ce billet est écrit, ceci est uniquement disponible en ASM (ancien portail). Nous allons voir comment l’utiliser avec des VMs qui ont été déployées en ARM. 

    Prerequis

    • Un Azure AD disponible
    • Par défaut, vous n’êtes pas administrateur du domaine. Il faut créer un groupe nommé AAD DC Administrators et qui vous donnera un accès Administrateur au domaine et aux machines qui y sont jointes. Ajoutez les utilisateurs qui doivent être administrateurs dedans:

    Activation du service

    Allez dans votre Azure AD, dans l’onglet Configure et cherchez domain service. Activez le et choisissez un nom DNS (vérifié ou non) puis choisissez votre VNet Classic où les serveurs vont être connectés:

    Le déploiement commence et peut prendre jusqu’à 30 minutes:

    Une fois le déploiement terminé, vous devriez avoir l’IP adresse de votre premier serveur Active Directory. La seconde arrivera plus tard (pour la haute disponibilité):

    Modifiez vos réseaux virtuels en précisant comme DNS, l’IP de votre ou vos AD:

    Déployez une VM sur ce réseau. 

    Comme vous le voyez, on a un message qui nous indique que pour le moment, nos utilisateurs ne peuvent pas se connecter au domaine, car il faut activer le synchronisation des mots de passes. Ici vous avez 2 choix: 

    • Cloud Only: si vous gérez vos utilisateurs depuis le Cloud
    • Synced: si vous utilisez Azure AD Connect pour gérer vos utilisateurs

    J’utilise la partie Cloud Only donc je vais expliquer cette dernière. Vous devez vous assurer que les utilisateurs peuvent remettre leur mot de passe à jour de façon autonome. Ceci est dans les configurations de l’Azure AD, Users enabled for password reset:

    Cette étape doit être effectué avant que les utilisateurs essayent de se connecter à une machine.

    Allez sur votre profile et mettez votre mot de passe à jour:

    https://account.activedirectory.windowsazure.com/r#/profile

    Ceci va metre à jour votre mot de passe dans l’Azure AD DS. 20 minutes après cette modification, vous pouvez vous servir de votre utilisateur pour joindre des ordinateurs au domaine.

    Rejoindre le domaine

    Maintenant que ma VM est déployée, je vais la joindre à mon domaine.

    Ceci est une étape classique que je ne vais pas décrire:

    Maintenant que la machine est jointe au domaine, je vais installer les outils d’administration du domaine, pour pouvoir gérer mes OUs, mes GPOs, etc…

    Avec les consoles lancées:

    Cette nouvelle fonctionnalité est très interéssante pour les entreprises qui ne veulent pas à avoir à gérer un AD mais qui en ont l’utilité. Seul petit bémol, le fait de devoir changer le mot de passe avant de pouvoir se connecter.

    • 9/5/2017

    [Azure Automation] Découverte de l’interface – Partie 1

    Je me suis récemment intéréssé à Azure Automation, de fond en comble. C’est pourquoi, dans les 2 prochains articles, nous allons voir comment utiliser cette outil, de A à Z:

    Commençons de suite avec le premier article.

    Azure Automation est un service d’orchestration qui est disponible sur Azure, et qui vous offre la possibilité d’avoir 500 minutes gratuites et 5 noeuds DSC gratuits. Après ça, la minute coûte 0.002€ et le noeud DSC coûte 5.06€ : https://azure.microsoft.com/en-us/pricing/details/automation/

    Azure automation va vous permettre d’avoir une seul et unique interface, pour gérez vos scripts. Par le passé, on utilisait le Task Scheduler de windows, sur plusieurs serveurs. Difficile de s’y retrouver après quelques années, et de savoir quel script tourne sur quell serveur. En rassemblant vos scripts sur Azure Automation, vous n’aurez plus ce problème, vous gererez vos scripts sur une seule et unique interface. Et pour les souci des scripts qui doivent accéder aux serveurs On-Premises, il y a la solution Hybrid Worker, qui, en installant un agent sur le serveur, vous permet d’exécuter les runbooks directement sur ce serveur.

    Vous pouvez créer un compte Azure Automation, depuis l’interface Azure. Une fois ce compte créé, vous arrivez sur une interface semblable à celle-ci:

    Plusieurs points sont importants ici:

    • Runbooks: ce sont vos scripts PowerShell, vos workflow que vous gérez ici.
    • Jobs: Historique des tâches qui ont tourné.
    • Assets: C’est ici que vous allez gérer vos variables, credentials, certificats, etc.
    • Hybrid Worker Groups: Gérez les connexions vers vos serveurs ici.
    • DSC Configurations: Gérez vos configurations DSC.
    • DSC Nodes: Gérez vos noeuds DSC. 

    Runbooks

    Commençons par la partie Runbooks. Vous allez créer vos runbooks directement ici. Vous avez la possibilité de créer des Runbook avec PowerShell ou en Graphique, en normal ou en workflow:

    Vous pouvez également importer des runbooks qui ont été créés sur un autre compte Azure Automation ou des scripts PowerShell qui existent déjà.

    Jobs

    Concernant la partie Jobs, c’est ici que vous allez avoir l’historique des runbooks qui ont été exécutés et si il y a des erreurs ou pas:

    Assets

    Passons à la partie Assets. Ici, vous allez pouvoir créer:

    • Des schedules
    • Importer des modules via la galerie ou que vous avez créé
    • Des certificats
    • Des connexions (vers Azure)
    • Des variables
    • Des Credentials

    Les schedules vont vous permettre d’automatiser le départ de vos runbooks à des heures/jours bien précis:

    Les modules sont très importants. En effet, si vous souhaitez  utiliser des commandes d’un module, ce module doit être importé. Si vous executez le runbook avec un Hybrid Worker, le module doit être installé sur le serveur en question. Vous pouvez importer vos propre modules ou utiliser la galerie:

    La partie Certificates contient les certificats qui peuvent être utilisés dans les scripts (les extensions cer et pfx sont autorisées):

    La partie Connections vous permet de faire des connexions directement vers Azure ou un autre service et de les utiliser par la suite dans des scripts:

    Explorons maintenant la partie Variables. Cette partie est très interéssante car c’est ici que vous allez créer des variables pour utiliser dans les scripts. L’utilisation de variables est pratique car vous avez juste à modifier la variable sans toucher au script. Vous avez plusieurs type pour les variables et vous pouvez les encrypter si jamais vous voulez stocker des mot de passes, etc.

    Pour terminer, explorons la partie Credentials. Ici, vous allez créer une combinaison utilisateur/mot de passe, comme si vous utilisiez un Get-Credential en PowerShell:

    Hybrid Workers

    La partie hybrid workers va vous permettre d’exécuter des scripts On-Premises. En effet, après avoir installé l’agent sur un serveur, quand vous exécutez un runbook, vous pouvez choisir de l’exéctuer sur Azure ou sur un groupe Hybrid Worker. Ceci à l’avantage de faire tourner des scripts directement sur votre réseau local.

    Pour faire ceci, vous devez disposer d’un workspace OMS: https://www.microsoft.com/oms

    Avec la solution Azure Automation installée. Une fois ceci terminé, déployez l’agent OMS sur le serveur qui sera utilisé dans le groupe Hybrid Worker. Vous pouvez avoir plusieurs serveurs dans un groupe. 

    Configuez ensuite l’agent pour qu’il communique avec Azure Automation: https://docs.microsoft.com/en-us/azure/automation/automation-hybrid-runbook-worker

    Une fois la connexion établit, celle-ci apparait dans Azure Automation:

    DSC Configuration

    Ici, vous allez pouvoir importer vos configurations DSC:

    Et les compiler:

    DSC Nodes

    Pour gérer les noeuds DSC, et appliquer les configurations, vous pouvez le faire directement depuis l’interface. Vous pouvez enregistrer des noeuds qui sont sur Azure (l’extension sera déployée automatiquement) ou enregistrer un serveur On-Premises:

    Une fois les noeuds sélectionnez, vous pouvez appliquer une première configuration:

    Après quelques minutes, l’agent est deployé, et les noeuds sont Compliant:

    Monitoring

    Pour avoir un aperçu rapide et complet, il y a sur la page d’accueil, les statistiques:

    Vous pouvez retrouver les clés si vous souhaitez appeler des runbooks depuis l’exterieur du compte Azure Automation:

    Mais aussi le détail sur les minutes gratuites restantes sur votre compte Azure Automation:

    Vous pouvez ensuite régler le controle des sources, avec Github, VSTS, etc:

    Enfin, pour terminer, vous pouvez utiliser des RunAs account vers votre Azure AD:

    C’est ainsi que se termine cette première découverte de Azure Automation. Dans la prochaine partie, nous allons voir par où commencer pour migrer vos scripts On-Premises vers Azure Automation.

    • 8/5/2017

    Synology, UPS et Hyper-V

    J’ai récemment acheté un UPS pour mes Hyper-V et mon Synology pour palier aux coupures de courant qu’il y a dans mon quartier.

    C’est un APC: https://www.amazon.fr/gp/product/B002TANS0I/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1

    Le problème est l’autonomie de la batterie comparée à la longueur des coupures de courant.

    J’ai donc regardé comment controler l’UPS, avec le Synology, étant donné qu’il y a qu’un port Ethernet/usb et que j’ai 2 Hyper-V, le plus simple reste de controler l’UPS via mon unique Synology.

    Pour commencer, branché le cable fourni avec votre UPS sur l’ethernet de votre UPS, vers un port USB du Synology:

     Allez maintenant dans votre interface d’administration de votre Synology, dans la partie Control Panel > Hardware & Power > UPS et cochez la case Enable UPS Support:

    Vous pouvez ensuite adapter les valeurs avec le temps au bout de combien de temps votre Synology doit entrer en Safe Mode, si on doit éteindre l’UPS quand le Synology rentre en Safe Mode et surtout, cochez la case Enable network UPS server. Et dans Pemitted DiskStation devices, rentrez les addresses IP de vos Hyper-V. Vous pouvez avoir des informations concernant votre UPS:

    Il faut maintenant installer le logiciel WinNUT que vous pouvez trouver ici:

    http://code.google.com/p/winnut/downloads/list

    Ce logiciel doit être installé sur les Hyper-V:

    Cochez la case Install As Service (Automatic Startup) et cliquez sur le bouton Edit pour modifier la configuration:

    C’est ici que nous allons renseigner les informations de connexion vers le Synology.

    Pour commencer, vous devez récupérer le nom d’utilisateur/mot de passe pour l’UPS sur le Synology. Connectez-vous en SSH sur votre Synology et faites:

    sudo cat /usr/syno/etc/ups/upsd.users

    Vous devriez avoir ceci:

    L’utilisateur pour se connecter l’UPS sera donc monuser et le mot de passe sera secret. Vous pouvez bien entendu modifier ces valeurs. 

    Maintenant, dans votre fichier de configuration sur votre Hyper-V, remplissez la chaine de connexion comme ceci: 

    MONITOR SynologyUser@IPSyno 1 UPSUser UPSPassword Slave

    Une fois terminé, sauvegardez la configuration et cliquez sur Apply and Start WinNUT. Vous pouvez vérifier que le service est bien démarré: 

    Get-Service WinNutUPSMon | Select *

    Votre Synology contrôle maintenant les Hyper-V et les éteindra avant de s’éteindre.

    • 2/5/2017

    [Azure] Citrix XenApp

    Aujourd'hui nous allons voir comment déployer une ferme Citrix XenApp sur Azure. Nous allons utiliser le déploiement de type Citrix Cloud Service. Ce modèle fait tourner votre workload sur Azure, mais il est géré par Citrix.

    Ceci a été rendu disponible en Mars 2017.

    Les prérequis sont les suivants pour déployer l'environnement: 

    • Une suscription Azure
    • Un compte sur le Citrix Cloud: https://onboarding.cloud.com
    • Un VPN S2S ou un Express Route pour contacter votre infrastructure Active Directory
    • Un groupe de ressource avec:
      • Virtual Network
      • Compte de stockage
      • Une VM Image avec les applications installées

    Toutes les ressources doivent être dans le même groupe de ressource.

    La VM Image est la VM avec vos applications personnalisées installées que vous souhaitez fournir à vos utilisateurs. Vous pouvez avoir un nombre illimité d'image sur Azure que vous allez déployer pour votre ferme Citrix.

    Déploiement de l'environnement Citrix sur Azure

    Pour commencer, ouvrez le Marketplace et cherchez Citrix XenApp Essentials. Cliquez sur Create:

    Donnez un nom à ce déploiement, la suscription où vous souhaitez déployer l'environnement et le groupe de ressource où vous avez déjà déployez votre VM, le réseau et le stockage:

    Cliquez sur Connect pour vous connecter au Citrix Cloud:

    Quand la connexion est terminée, vous devez renseigner le nombre d'utilisateur pour lesquels vous voulez une licence (minimum 25). Ce chiffre peut être changé plus tard, via le portail Azure. Ca prendra maximum 4 heures pour déployer l'environnement sur le Citrix Cloud:

    Quand c'est terminé (vous recevrez un email), cliquez sur Manage through Citrix Cloud:

    Deployez votre image personnalisée

    Vous allez arriver sur une nouvelle interface. C'est ici que nous allons déployer les nouvelles images, les gérer, etc. Cliquez sur I’m ready to start:

    Cliquez sur Subscriptions pour vous connecter à votre suscription Azure avec le compte qui est propriétaire et localisé sur l'Azure AD:

    Acceptez les permissions que Citrix a besoin:

    Choisissez la suscription où l'infrastructure Citrix sera déployée (doit être la même suscription qu'où vous avez déployé le Citrix XenApp du marketplace) et cliquez sur Link:

    Nous allons créer un nouvel objet dans le catalogue Citrix. Cliquez sur Create a catalog:

    Donnez un nom à ce catalogue et si les machines seront jointes au domaine ou pas:

    Sélectionnez la suscription Azure, le groupe de ressource où le réseau a été déployé (doit être le même qu'où vous avez déployé votre infrastructure sur Azure), choisissez le virtual network et le sous réseau qui sera utilisé (doit pouvoir contacter un domain controller):

    Fournissez le nom de votre domaine, l'OU où stocker les objets ordinateurs, un compte qui a les droit pour joindre les serveurs au domaine (format UPN) et le mot de passe associé:

    Choisissez si vous souhaitez lier votre image à cette collection (pas possible pour le moment car on n'a pas encore d'image sur notre Citrix Cloud) ou si vous voulez importer une nouvelle image (ce que l'on va faire) ou si vous voulez utiliser l'image par défaut fourni par Citrix (pour les tests).

    Choisissez la suscription, le groupe de ressource, le compte de stockage et le VHD de la VM où les applications sont installées. Donnez un nom à cette image et cliquez sur Save:

    Pour le déploiement des VMs sur Azure, choisissez si vous souhaitez utiliser un stocke de type HDD ou SSD. Choisissez la taille des VM si vous le souhaitez (Custom) ou utilisez une taille prédéfinie:

    Choisissez le nombre minimum d'instance qui doivent tourner et le maximum. J'ai 25 utilisateurs, et avec la taille que j'ai choisis (utilisation de Notepad++), je peux faire tourner 16 utilisateurs de façon simultané. Donc, je peux potentiellement accueillir 32 utilisateurs maximum avec mes 2 instances. Vous pouvez choisisr d'arrêter/démarrer les VMs, etc.

    En haut, cliquez sur Start Deployment pour démarrer le déploiement de la ferme Citrix avec votre image personnalisée: 

     Le déploiement peut prendre entre 1 et 2 heures:

     Après quelques instants, les premières ressources apparaissent dans Azure:

     Et les VMs sont jointes au domaine:

    Deployez les applications et donnez les droits

    Quand le déploiement est terminé, vous devez publier vos applications et ajouter un ou plusieurs utilisateurs/groupes:

    Sélectionnez les applications que vous voulez publier: 

      

    Et ajouter des utilisateurs/groupes. Quand c'est terminé, allez dans More Settings et renseignez le chemin vers un File Server pour stocker les profils. Renseignez le serveur de licence RDS pour valider les CAL: 

    Une URL pour accéder à votre déploiement sera disponible après quelques minutes dans la section Test and Share StoreFront Link

    Si vous allez dans Master Image, vous verrez votre image que vous pouvez déployer dans un autre catalogue:

    Connectez vous à votre environnement

    Allez sur votre URL et téléchargez le client Citrix Receiver. Quand le client est installé, connectez vous à votre URL:

    Fournissez un nom d'utilisateur/mot de passe que vous utilisez pour vous connecter aux ressources de l'entreprise, votre PC par exemple et qui a accès à la collection Citrix: 

    Si le nom d'utilisateur/mot de passe sont corrects, et que vous avez les autorisations nécessaires, vous allez voir les applications qui sont disponibles dans cette galerie: 

    Cliquez sur l'une d'elle pour l'ouvrir: 

    Grâce à ce nouveau type de déploiement, vous n'aurez plus besoin d'un environnement Citrix OnPrem. Attention au coût que cela peut engendrer, parce que vous devez payer la consommation Azure, la licence Citrix par utilisateur et les CAL RDS.

    Citrix calculator: https://costcalculator.azurewebsites.net/costCalculator

    • 27/4/2017

    [StarWind] Déployer Virtual SAN Free sur Azure

    Aujourd'hui, je vais vous montrer comment utiliser StarWind Virtual SAN Free sur Azure. Ceci vous permet de présenter des LUNs, à des VMs. vous utiliserez donc moins de disque que pour du Storage Space Direct par exemple, si vous n'utilisez pas le produit en HA bien sur.

    Vous pouvez télécharger le produit et la licence ici: https://www.starwindsoftware.com/starwind-virtual-san-free

    Le Quick Start guide se trouve ici: https://www.starwindsoftware.com/technical_papers/quick-start-guide-creating-ha-device-with-starwind-virtual-san-free.pdf 

    Pour commencer, j'ai déployé l'infrastructure suivante sur Azure:

    • Un groupe de ressource StarWind
    • Un réseau virtuel StarWindNetwork
    • 4 machines virtuelles:
      • Une machine VirtualSan avec 4 disques de 500GB
      • Une machine Node01 (jointe au domaine, avec le rôle File Server et la feature Failover Clustering)
      • Une machine Node02 (jointe au domaine, avec le rôle File Server et la feature Failover Clustering)
      • Une machine FLOAPP-DC02

    Je fais une configuration de base. Il faudrait bien entendu séparer les réseaux (Stockage, Cluster, Management).

    J'utilise des Managed Disks, comme ça, je n'ai pas besoin de me préoccuper de la localisation des disques (plus de LRS, GRS, ZRS, etc.).

    Pour commencer, initialisez les disques sur la machines qui va accueillir le logiciel StarWind Virtual SAN Free et créez un volume. J'ai pour ma part fait un miroir, sur 2 volumes différents, F: et G:.

    Démarrez l'installation du logiciel Starwind, après l'avoir téléchargé sur le serveur ainsi que la licence:

    Acceptez la licence:

    Relisez les informations concernant l'utilisation du produit:

    Choisissez où installer StarWind Virtual SAN:

    Ici, je vais choisir l'installation Full (avec le connecteur SMI-S, pour le connecter par la suite avec SCVMM):

    Choisissez où stocker le raccourci:

    Créez ou non un icône sur le bureau:

    Si vous vous êtes enregistré avec le lien au début de l'article, vous devez avoir une licence:

    Choisissez la licence que vous avez reçu:

    Les informations sur la licence sont disponibles:

    Voici le résumé de l'installation:

    L'installation est terminée, vous pouvez ouvrir la console:

    Au premier lancement, il va vous demander où stocker par défaut le storage pool. Dans mon cas, sur mon volume G: qui est en miroir:

    Cliquez droit sur le serveur, et choisissez Add Device (advanced):

    Choisissez d'ajouter un Hard Disk Device:

    Et choisissez le type Virtual Disk, car nous allons stocker ceci sur des disques virtuels:

    Choisissez où stocker votre virtual disk, ainsi que son nom et sa taille: 

    Choisissez le type de provisionnement: 

    Choisissez le paramètre de cache RAM: 

    Et si vous avez un Flash Cache ou pas: 

    Créez une nouvelle iSCSI target pour pouvoir vous connecter à ce serveur, depuis d'autres serveurs: 

    Cliquez sur Create pour créer votre premier disque: 

    Le disque a été créé avec succès: 

     La vue depuis la console StarWind:

    Et depuis l'explorer: 

    Sur chaque serveur du Cluster (Node01 et Node02 pour moi), lancez le logiciel iSCSI Initiator et cliquez sur Yes: 

    Renseignez l'IP de votre serveur StarWind et cliquez sur Quick Connect: 

    Une fois la connexion établie, vous devriez voir le statut Connected: 

      

    Si vous ouvrez l'explorer de management de disque, un nouveau disque est apparu:

    Initialisez le et créez un nouveau volume: 

    Une fois terminé, que vous avez les 2 serveurs connectés, vous devriez voir les 2 iSCSI connectés dans la console StarWind:

    Ajoutez le disque au Cluster.

    Si vous créez un SOFS, vous pouvez créer un nouveau partage, en stockant les données sur le disque:

    Vous pouvez vous connecter au share du SOFS et copier des données dedans:  

    Vous avez la même vu depuis le CSV ou depuis le Share: 

    Pour conclure, ce logiciel peut vous êtes utile si vous souhaitez faire des économies sur Azure, même si le stockage n'est pas la ressource la plus cher dans le cloud.

    • 10/4/2017

    [Windows Server 2016] Passer de Evaluation à Retail


    Si comme moi, vous n’avez pas pu attendre la sortie de la version retail pour installer Windows Server 2016 l’an dernier, il va falloir activer le serveur si vous souhaitez continuer à l’utiliser.

    Vous trouverez plus d’informations ici : https://technet.microsoft.com/en-us/windows-server-docs/get-started/supported-upgrade-paths?f=255&MSPPError=-2147217396

    Pour faire ceci, il faut que la version soit au moins 14393.0.161119-1705.RS1_REFRESH.

    Pour vérifier que vous êtes bien en version d’évaluation, utilisez la commande suivante :

    slmgr.vbs /dlv

    Vérifiez ensuite si votre serveur est en licence Standard ou Datacenter pour installer la clé qui correspond à votre version. Dans mon cas, c’est une licence Datacenter:

    DISM /online /Get-CurrentEdition

    Lancez l’installation ce la clé avec la commande suivante :

    DISM /online /Set-Edition:ServerDatacenterCor /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula

      

    Après quelques instants, le serveur va vous demander de redémarrer:

    Après le redémarrage, vous pouvez vérifier que la clé a bien été installé et que vous êtes maintenant en version retail avec la commande suivante :

    slmgr.vbs /dlv

    • 30/3/2017

    [GitHub Enterprise] Sauvegardez le contenu

    Si vous ne sauvegardez pas votre machine qui contient votre GitHub Enterprise, vous pouvez sauvegarder directement le contenu GitHub du serveyr. Mon serveur de backup est sous Debian 8. La première étape est d'installer rsync si il n'est pas encore installé:

    apt-get update && apt-get install rsync

    Maintenant, téléchargez l'utilitaire de backup et décompressez le. Copiez la configuration et modifiez la:

    wget https://github.com/github/backup-utils/releases/download/v2.9.0/github-backup-utils-v2.9.0.tar.gz
    sudo tar -xvzf github-backup-utils-v2.9.0.tar.gz
    cd /tmp/github-backup-utils-v2.9.0
    sudo cp backup.config-example backup.config
    sudo vi backup.config

    Ajoutez le nom de votre serveur GitHub (assurez-vous de pouvoir pinguer ce serveur) et sauvegardez la configuration:

    Maintenant; exécutez la commande suivante pour effectuer votre première sauvegarde:

    cd bin/
    sudo ./ghe-backup -v

    -v est pour le verbose.

    Acceptez le certificate. La sauvegarde démarre:

    Maintenant que votre serveur Github est sauvegardé, déployez un nouveau serveur GitHub ou utilisez celui ci.

    Si vous utilisez un nouveau serveur GitHub, importez le certificat, refaites la configuration de base, comme l'intégration SAML, etc.

    Maintenant, enregistrez la clé SSH de votre serveur de sauvegarde dans l'interface GitHub et placez votre serveur GitHub en mode maintenance:

    Vous pouvez démarrer la restauration avec la commande suivante:

    sudo ./ghe-restore IPADDRESS -v

    IPADDRESS est l'adresse ip du serveur qui contient le GitHub où vous souhaitez restaurer la dernière sauvegarde:

    C'est très simple à faire avec cet outil mais aussi très simple à automatiser avec un job cron.

    • 28/3/2017

    [GitHub Enterprise] Changer le certificat avec Lets Encrypt

    Par défaut, le certificat utilisé pas le serveur GitHub Enterprise est auto-signé. Si vous ne pouvez pas acheter de certificat, vous pouvez utiliser LetsEncrypt pour avoir un certificat trusté publiquement. Celui ci doit être renouvelé tous les 3 mois.

    Le serveur GitHub est comme une appliance, il ne faut rien installer dessus, c'est pourquoi, pour générer ce certificat, il faut utiliser un autre serveur. Je vais utiliser un serveur sous Debian 8 pour faire ceci. Nous allons utiliser le paquet certbot pour générer le certificat.

    La première étape est d'enregistrer le répertoire et installer le paquet:

    echo "deb http://ftp.debian.org/debian jessie-backports main" | sudo tee -a /etc/apt/sources.list
    sudo apt-get update
    sudo apt-get install certbot -t jessie-backports

    Quand c'est terminé, utilisez la commande suivante pour démarrer la génération du certificat public, avec le nom GitHub et les noms DNS inclus. Remplacez domaine.be par votre nom DNS:

    sudo certbot certonly --manual --preferred-challenges dns -d github.domain.be -d alambic.github.domain.be -d assets.github.domain.be -d avatars.github.domain.be -d codeload.github.domain.be -d gist.github.domain.be -d pages.github.domain.be -d render.github.domain.be -d reply.github.domain.be -d uploads.github.domain.be -d raw.github.domain.be -d media.github.domain.be

    Le script va vous demander de créer des enregistrement DNS, de type TXT, pour chaque sous-domaine, avec une valeur spécifique, pour vérifier que vous êtes bien le propriétaire du domaine:

    Quand c'est terminé, vous avez un message d'information:

    Sur le serveur, créez un répertoire temporaire, et copiez y le certificat fullchain.pem et privkey.pem dans ce dossier:

    sudo mkdir /tmp/certificates
    sudo cp /etc/letsencrypt/live/github.domain.be/fullchain.pem /tmp/certificates/fullchain.pem
    sudo cp /etc/letsencrypt/live/github.domain.be/privkey.pem /tmp/certificates/privkey.pem

    Quand c'est terminé, téléchargez ces certificats sur l'ordinateur depuis lequel vous allez faire la configuration GitHub. Connectez vous à l'interface d'administration, dans la partie Privacy et sélectionnez vos 2 certificats. Cliquez sur Save sur la gauche:

    Les services vont redémarrer:

    Les services ont redémarré correctement:

    Si vous rafraichissez votre page GitHub, vous allez avoir votre nouveau certificat, validé par votre navigateur:

    Et depuis l'interface d'administration GitHub, vous avez un certificat valide:

    C'est gratuit, rapide à mettre en place, donc oubliez les certificats auto signés et utilisez des certificats valides :)

    • 13/3/2017

    [GitHub Enterprise] Authentification avec Azure AD

    Avec les dernières versions de GitHub Enterprise, il est possible d'utiliser l'authentification via SAML, ce que propose Azure AD. Pour mettre en place ceci, il vous faut donc:

    • Un Azure AD
    • Un environnement GitHub Enterprise

    Pour commencer, il faut créer une application sur votre Azure AD. Depuis le nouveau portail, allez dans votre Azure AD, et créez une nouvelle application, de type WebApp / API. La partie SignOn URL correspond à l'URL de votre GitHub Enterprise:

    Vérifiez bien dans l'application que les permissions soient bien avec au moins Sign in and read user profile:

     

    Il faut maintenant récupérer le fichier FederationMetadata.xml. Pour ce faire il faut aller sur l'URL suivante, en remplaçant l'ID par l'ID de votre tenant, que vous pouvez retrouver dans votre Azure AD:

    https://login.windows.net/TENANTID/FederationMetadata/2007-06/FederationMetadata.xml

    Récupérez la valeur qui se trouve au niveau de la flèche, dans la balise X509Certificate:

    Copiez les données dans un fichier texte, puis, tous les 80 caractères, allez à la ligne:

    Enregistrez ce fichier avec l'extension .cert

    Allez maintenant sur la page d'administration de votre GitHub Enterprise, dans la partie Authentication. Ici, choisissez SAML et dans Single Sign On URL, fournissez l'URL suivante, en remplaçant TENANTID par l'ID de votre Azure AD. Fournissez le certificat que vous avez enregistré avant:

    https://login.microsoftonline.com/TENANTID/saml2 

    Sauvegardez. Vous devriez avoir ceci:

    Allez maintenant sur votre URL GitHub. Au moment de vous connecter, vous devriez être redirigé vers la page d'authentification de Microsoft. Connectez-vous avez votre compte Azure AD. Vous devriez ensuite arriver sur la page GitHub:

    Comme vous pouvez le voire, le . dans le nom d'utilisateur est remplacé par un -.

    Bon courage pour cette manipulation et n'hésitez pas si vous avez des questions :)

    • 23/2/2017

    [Azure] Migrer du portail Classic vers ARM


    Christophe Lams, Cloud Solution Architect, a publié une série d'article pour migrer depuis la version classic de Azure, vers ARM, en utilisant Azure Site Recovery. 

    Voici les différents articles qu'il propose:

    1. Création des VMs classic au travers du nouveau portail
    2. Création du vault ASR
    3. Configuration du réseau
    4. Installation de l'agent de mobilité
    5. Préparation de l'infrastructure ARM
    6. Création du Recovery Plan
    7. Failover
    8. Finalisation de la migration

    Cette série d'article est très intéressante pour vous aider à migrer rapidement de l'ancien mode Azure, vers le nouveau.

    • 22/2/2017

    [Azure] Azure Site Recovery avec ARM - Partie 2


     

    Voici donc la deuxième partie de l'implémentation de Azure Site Recovery avec ARM: 

    Réplication des premières VMs

    Maintenant que l’infrastructure est prête sur Azure, nous allons pouvoir répliquer les VMs/Applications. Choisissez de où vous souhaitez répliquer les VMs (On-Premises pour moi) et sélectionnez le site Hyper-V que vous avez créé dans le premier article :

    Sélectionnez le compte de stockage que vous avez créé au début pour stocker les réplications, mais aussi le réseau que vous avez créé et le sous-réseau associé :

    Sélectionnez enfin les VMs que vous souhaitez protéger avec la réplication :

      

    Choisissez le type d’OS ainsi que le disque OS. Choisissez enfin les disques que vous souhaitez répliquer :

    Appliquez la police créée précédemment :

      

    La réplication commence :

      

    Depuis la console Hyper-V, vous pouvez voir que la réplication a commencé :

    Modification de la VM avant Failover

    Avant de tester le failover, il faut choisir la taille de la VM qui sera déployée et aussi, paramétrer le réseau. En effet, vous pouvez décider de faire tourner la VM sur une taille plus petite en mode dégradé. Et ici, étant donné que mon application a été mal codé et que j’ai une IP fixe dans le code, je vais réattribuer la même IP que dans mon réseau local actuel à cette VM. Si vous ne précisez rien, le DHCP prendra la première IP disponible dans le pool :

    Test du Failover

    Il est maintenant temps de tester le failover. J’ai éteint mon infrastructure, et donc, plus personne ne peut travailler. Dans la console Azure, sur votre réplication de votre application, cliquez sur Unplanned Failover pour dire que votre application doit être déployé sur Azure.

    Choisissez le point de sauvegarde que vous souhaitez restaurer. Je n’ai pas synchronisé les derniers changements car mon infrastructure n’est plus disponible, et j’aurai donc perdu dans mon cas, maximum 15 minutes de données (délai de réplication des VMs vers Azure) :

    Le déploiement de ma VM sur Azure est en cours :

    10 minutes plus tard, ma VM a été déployé dans Azure :

    VNet Peering

    J'ai créé un VNet Peering entre le réseau qui contient mon DC et mon réseau ASR. Vous pouvez retrouver la procédure pour faire ceci ici. Vous pouvez également automatiser cette partie.

    Test de mon application

    En me connectant sur mon DC sur Azure, je peux voir que je ping directement la nouvelle machine ASR (grâce au network peering) et que je peux accéder au site web :

    Et en rajoutant un NLB et en créant une règle NAT, sur le port de l’application, vers la VM qui vient d’être déployé, mes utilisateurs peuvent continuer à travailler, juste en faisant pointer votre DNS, vers la nouvelle IP public du NLB :

      

    Maintenant que votre application est fonctionnelle, il faut faire un Commit du failover :

    Failback

    Votre datacenter est de nouveau opérationnel, il faut donc rapatrier les données avec les changements qu’il y a eu. Pour faire ceci, cliquez sur Planned Failover :

      

    Vous souhaitez faire le failover de Azure vers votre Datacenter. Si vous avez perdu vos données, vous pouvez décider de créer une nouvelle VM dans votre datacenter, sur un hôte bien précis :

    Une fois que le failback est terminé, vous devriez avoir ceci :

      

    Cliquez sur Commit pour valider le changement vers votre datacenter :

      

    Le dernier delta est envoyé :

    Enfin, le failback est terminé :

      

    Pour terminer, il faut réactiver la réplication de la VM vers Azure. Cliquez sur Reverse replicate :

    Si je refais le test, depuis ma VM qui est sur Azure, vers la même IP qui est dans mon datacenter, vous pouvez voir que maintenant, je passe de nouveau par mon VPN S2S et que le site Web n’a pas changé :

    Pour aller plus loin

    Si vous souhaitez aller plus loin, ici nous avons fait le failover pour une seule VM. Vous pouvez créer un groupe de VM, dans la partie Recovery Plan pour faire un failover sur plusieurs VM d’un seul coup :

    Vous pouvez également gérer directement les paramètres de l’infrastructure ASR dans la console Azure, sans passer par le Step-By-Step :)

    Conclusion 

    Cette fonctionnalité est très intéressante pour les sociétés qui ont des applications business critiques pour faire tourner l’entreprise. Même en mode dégradé, les employés peuvent continuer à travailler et donc, faire perdre un minimum d’argent à la société. Ne vous en passez donc pas :)

    • 21/2/2017

    [Azure] Azure Site Recovery avec ARM - Partie 1

    Aujourd’hui, nous allons voir comment implémenter une solution de DRP, avec Azure Site Recovery. Je vais déployer cette solution, basé sur ARM. ASR peut également servir pour des migrations de VM vers Azure mais aussi de VMWare vers Azure, etc.

    Dans mon plan de DRP, le service que j’ai défini comme critique est un site web. Je vais donc répliquer cette VM sur Azure, avec ASR. J’aurais pu faire de même avec une application multi tier.

    Dans mon architecture, j'ai une VPN Site-2-Site vers Azure. Attaché au réseau qui est connecté au 2ème VPN, se trouve mon deuxième contrôleur de domaine, qui fait également DNS.

    Il y aura 2 articles:

    • 1er article: Mise en place de la solution Azure Site Recovery
    • 2ème article: Replication des VMs et Failover/Failback

    Virtual Network et stockage

    Dans un premier temps, je vais préparer mon réseau qui accueillera mon DRP. Ce réseau aura le même sous-réseau que mon réseau dans mon datacenter. Pourquoi ? Car mon application web a été mal codé et qu’il y a des IPs en dur dans le code :)

    Vous pouvez également modifier les DNS, etc. de ce réseau.

    Créez également un compte de stockage qui contiendra les réplications.

    Nouveau Recovery Volt

    Maintenant que le réseau est prêt, créez un nouveau Recovery Volt en allant sur + > Storage > Backup and Site Recovery (OMS) :

    Donnez un nom à votre vault et choisissez la destination et le groupe de ressource associé :

    Après quelques instants, le vault a été créé :

    Configuration

    La première étape étant terminé, il est maintenant temps de commencer la configuration. Dans votre vault, cliquez sur Site Recovery > Step 1 : Prepare Infrastructure et choisissez où vous souhaitez répliquer vos machines (Azure dans mon cas, mais ça peut être sur un site secondaire), si les machines sont virtuelles et si oui, sur quel type d’hyperviseur (Hyper-V pour moi, mais ce peut être VMWare) et enfin, choisissez si vous utilisez SCVMM pour gérer vos hôtes :

    Il faut maintenant créer un site Hyper-V. Ce site contiendra tous les Hyper-V d’un site, par exemple Bruxelles. Vous pouvez par la suite ajouter d’autres sites. Cliquez sur + Hyper-V Site et donnez un nom à ce site :

      

    Sélectionnez-le et cliquez sur + Hyper-V Server pour installer l’agent sur le/les serveur(s) Hyper-V qui contient la/les VM à répliquer sur Azure pour le DRP :

    Dans les instructions, il est dit que l’Hyper-V doit au moins être sur Windows Server 2012 R2, que le proxy doit autoriser les URLs de ASR et ensuite, il vous propose de télécharger l’agent de ASR ainsi que la clé du vault pour le site que vous avez créé précédemment :

    Copiez l’agent et la clé sur l’Hyper-V. Pour l’installer, utilisant la partie Server Core pour mes Hyper-V, j’ai utilisé les lignes de commandes suivantes pour installer l’agent et installer la clé :

    .\AzureSiteRecoveryProvider.exe /x:. /q

    Cd ‘C:\Program Files\Microsoft Azure Site Recovery Provider\’

    .\DRConfigurator.exe /r /Friendlyname ‘FLOAPP-HPV02’ /Credentials ‘C:\Temp\ASRFLOAPP_HYPERVFLOAPP_Wed Feb 15 2017.VaultCredentials’

    Après quelques minutes, l’Hyper-V apparaît dans la console Azure :

    Choisissez maintenant sur quelques suscriptions Azure vous souhaitez répliquer la VM avec ASR (la suscription où vous avez créé le compte de stockage et le réseau) ainsi que le type de déploiement que vous souhaitez utiliser, Classic ou Resource Manager (ARM) :

    Nous allons maintenant créer une règle pour la réplication, pour définir la durée entre chaque point de réplication, le nombre de point de réplication que vous souhaitez conserver, etc. Cliquez sur Create and Associate :

    Et fournissez les valeurs suivants ce que vous souhaitez implémenter :

    Une fois la règle créée, sélectionnez la et cliquez sur OK:

    Exécutez le capacity planner (https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-capacity-planner ) et une fois que ceci est terminé, cliquez sur OK :

    Dans le prochain article, nous verrons comment répliquer les VMs et faire le failover/failback :)

    • 16/2/2017

    FALA Consulting

    Bonjour à tous,

    Je profite de ce billet pour vous annoncer que je viens d'ouvrir ma SPRL en Belgique, sous le nom de FALA Consulting SPRL: http://www.falaconsulting.be

    Je suis disponible pour vous aider à migrer vers Azure par exemple, mais aussi pour tout ce qui tourne autour des Technologies Microsoft, et plus particulièrement Azure Stack, WAP, System Center, Hyper-V.

    N'hésitez pas à me contacter si vous souhaitez avoir des renseignements à florent [at] falaconsulting.be

    Florent

    • 15/2/2017

    [Azure] SQL Server et .Net Core dans ACS

    Dans un billet précédent, nous avons vu comment déployer Azure Container Services. Microsoft a publié une suite de 3 billets pour le déploiement de SQL Server et .Net Core dans des containers sur ACS:

    Cette suite est très intéressante et montre bien le virage que prend Microsoft, en se lançant dans les containers. Et donc, pour les entreprises, la possibilité de faire tourner des applications Business développé en .Net, directement dans des containers :)

    • 8/2/2017

    [Azure] Ajouter plusieurs administrateurs d'un coup

    J'ai eu la demande d'ajouter plusieurs utilisateurs d'un Azure AD Administrateur de la suscription Azure, en ARM. Etant feignant et ne voulant pas ajouter les 10 utilisateurs à la main, j'ai décidé d'écrire un script PowerShell (au cas où on me demande de le refaire plus tard). Ce script est disponible sur Gallery Technet:

    https://gallery.technet.microsoft.com/Add-multiple-admins-in-an-07c7cf59

    Pour l'utiliser, créez un fichier CSV au même endroit que votre script, avec les 3 colonnes suivantes:

    • Email
    • FirstName
    • Lastname

    Sur mes 4 utilisateurs, je n'en ai que 1 qui est actuellement Owner. Le script ajoutera donc les 3 autres:

    Choisissez votre suscription Azure:

    Si il y a un souci pendant l'ajout, vous aurez un message d'erreur:

    Et si l'ajout se passe bien, vous aurez des messages d'informations:

    Et dans ma vue Azure:

    Si vous avez des questions, remarques ou suggestions, n'hésitez pas :)

    • 27/1/2017

    [Azure] Intégration continue / Déploiement continue avec Docker (ACS et ACR), Visual Studio Code, Visual Studio Team Services et GitHub

    Une des grandes forces des infrastructures de nos jours, est le fait de pouvoir réaliser, du CI/CD. Comprenez, Continous Integration et Continus Deployment.

    En résumé, ces techniques, permettent à vos développeurs, de créer/modifier leur code, de l’envoyer sur Github par exemple, de le compiler avec Visual Studio Team Services (VSTS), de l’enregistrer sur votre registry (Azure Container Registry dans mon cas), de gérer les versions, toujours avec VSTS, de l’envoyer comme container sur votre Docker Swarm et pour finir, d’y accéder par une simple interface web.

    Nous allons donc voir comment faire ceci (la documentation Microsoft est disponible ici). Pour commencer, vous devez être sûr d’avoir ceci :

    Avant de commencer, vous devez déployer sur votre ACS, le container Docker qui permettra d’installer l’agent VSTS. Le container et sa documentation sont disponibles ici : https://hub.docker.com/r/microsoft/vsts-agent/

    Il faut un token pour pouvoir installer cet agent. Allez dans votre VSTS > Votre Compte > Security :

    Cliquez sur Add pour créer un nouveau Token :

    Sélectionnez bien Agent Pools (read, manage) comme permission et créez le token :

    Sauvegardez bien la clé qu’il va vous donner car vous ne pourrez pas la récupérer ultérieurement. Connectez-vous sur un serveur qui a Docker pour installer l’agent VSTS (il est également possible de déployer cet agent sur un container Docker). Mon serveur tourne avec Ubuntu 16.04. Dans l’interface VSTS, cliquez sur Settings > Agent queues > Download Agent et sélectionnez votre OS :

    Téléchargez l’agent sur le serveur et exécutez la commande de configuration en remplaçant par l’URL de votre VSTS. Fournissez la clé que vous avez créé juste avant pour l’authentification :

    wget https://github.com/Microsoft/vsts-agent/releases/download/v2.111.1/vsts-agent-ubuntu.16.04-x64-2.111.1.tar.gz

    mkdir myagent && cd myagent

    tar zxvf /home/florent/vsts-agent-ubuntu.16.04-x64-2.111.1.tar.gz

    ./config.sh –url https://floapp.visualstudio.com –auth PAT



    L’agent est maintenant configurer. Pour le lancer, exécutez la commande ./run.sh :

    Pour que tout ce petit monde parle ensemble, il faut dans un premier temps, installer le composant docker, qui va permettre d’interagir entre VSTS et Docker. Sur le marketplace de Visual Studio ( https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.docker ) cliquez sur Install :

    Puis choisissez sur quel compte VSTS l’installer :

    Pour continuer, récupérez un token sur votre compte GitHub, qui a les permissions repo, user, admin:repo_hook :

    Il faut maintenant associer votre compte GitHub avec notre VSTS. Ouvrez votre projet, puis cliquez sur Settings > Services :

    Ici, cliquez sur New Service Endpoint > Github :

    Dans la nouvelle fenêtre, renseignez le token que vous avez généré avant, ainsi que le nom de votre compte associé à ce token :

    Il faut maintenant enregistrer la registry Docker, en cliquant sur New Service Endpoint > Docker Registry :

    Renseignez les informations de votre registry, que vous pouvez trouver sur Azure, dans la partie Container Registry > Access Key :

    Pour terminer cette partie-là, il faut ajouter un service de type SSH. Donnez un nom, l’URL de connexion que vous retrouvez sur Azure, dans la partie Container Service, le port (2200 par défaut), le nom d’utilisateur que vous avez renseigné lors de la création de ACS et enfin, la clé privée utilisé à la création :

    La partie configuration est maintenant terminée. Passons à la suite. Nous allons commencer par créer une build de base. Allez sur votre VSTS, puis dans Build & Release. Cliquez sur New > Empty :

    Cliquez ensuite sur Github, puis sélectionnez Continuous integration et enfin, choisissez l’agent de type Default :

    Sur votre nouvelle définition, cliquez sur Repository et sélectionnez le compte Github que vous avez configuré avant, ainsi que le repository que vous souhaitez utiliser pour le CD:

    Allez maintenant dans Triggers et sélectionnez Continuous Integration. Ceci aura pour effet de déclancher le trigger à chaque Commit de l’application :

    Puis cliquez sur Save :

    Mon application, que je souhaite déployer, contient une seule image, nginx. Je vais donc créer 2 Docker steps, une pour envoyer l’image sur ACS et l’autre sur ACR. Cliquez sur Add build step… dans Build :

    Choisissez Docker et cliquez sur Add 2 fois (pour ACS et ACR):

    Pour le premier build, sélectionnez la connexion vers votre registry, l’action Build an image, le chemin vers votre Dockerfile qui est sur Github, le chemin avec les sources et votre Dockerfile et pour finir, le nom de votre image, avec le chemin complet vers votre registry :

    Pour la partie push sur votre Registry, sélectionnez la connexion vers votre registry, l’action Push an image et enfin, le nom de votre image complète vers votre registry :

    Pour terminer, il faut ajouter la step suivante, uniquement si vous avez un docker-compose.yml, pour les applications multi-tiers. Sinon, passez à l’étape suivante :

    • Command Line ()
      • Tool : bash
      • Arguments: -c "sed -i 's/BuildNumber/$(Build.BuildId)/g' sources/docker-compose.yml"

    Et pour tout le monde, vous devez ajouter l’étape de publication de l’artifact, avec les sources :

    • Publish Build Artifacts
      • Path to publish: sources
      • Artifact Name: FloAppWebsite2
      • Artifact Type: Server

    Cliquez sur Save pour sauvegarder la configuration.

    Créez ensuite une nouvelle configuration pour la release, pour pousser le container sur votre ACS. Dans Releases, cliquez sur le + puis choisissez Empty et enfin, cliquez sur Next :

    Voici à quoi devrait ressembler votre release definition :

    Nous allons maintenant créer un articfact. Dans votre release, cliquez sur Artifacts, Link an artifact source et donnez un autre nom. Cliquez sur Link :

    Puis, passez le en tant que primaire :

    Cliquez maintenant sur Triggers et cochez la case Continuous Deployment, puis sélectionnez le nouvel artifact que vous avez créé juste avant :

    Sauvegardez. Cliquez sur Add tasks dans Environments dans votre nouvelle release, puis ajoutez une tache de type SSH avec la commande suivante et en décochant la case Fail on STDERR :

    docker login $(docker.registry) -u $(docker.username) -p $(docker.password) && export DOCKER_HOST=10.0.0.4:2375 && if docker inspect --format="{{ .State.Running }}" floappcicdwebsite >/dev/null 2>&1; then echo "Container floappcicdwebsite exist."; docker rm -f floappcicdwebsite; docker run --name floappcicdwebsite -d -p 80:80 floappregistry-on.azurecr.io/floappregistry/websitefloapp2:$(Build.BuildId); else echo "floappcicdwebsite does not exist, creation"; docker run --name floappcicdwebsite -d -p 80:80 floappregistry-on.azurecr.io/floappregistry/websitefloapp2:$(Build.BuildId); fi;

    La commande va se connecter à la registry, télécharger l’image et la déployer si elle n’existe pas déjà, ou la remplacer si elle est déjà existante, avec la dernière version publiée :

    Il faut ajouter 3 variables :

    • username : contient le nom d’utilisateur pour se connecter à la registry
    • password : contient le mot de passe associé à l’utilisateur pour se connecter à la registry
    • registry : contient l’url pour se connecter à la registry

    N’oubliez pas de sauvegarder.

    Il est maintenant temps de tester notre configuration. Pour commencer, modifiez votre code source, et envoyez-le sur Github. Après quelques secondes, sur votre VM où l’agent VSTS tourne, vous devriez voir ceci :

    Et depuis la console VSTS, je peux voir que l’étape de Build s’est bien déroulée :

    Tout comme la release :

    Et si j’essaye donc d’accéder à mon URL qui redistribue vers les agents Docker, j’ai ceci :

    Je vais maintenant modifier mon index.html, et l’envoyer sur mon GitHub. Voici du coté de l’agent VSTS ce qu’il se passe :

    Et du coté de VSTS, une nouvelle build, 35 (contre 34 avant), est disponible :

    Et la release :

    Voici ce que ça donne du côté de ma WebApp :

    Et en vidéo: