Blog de Florent Appointaire

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

    [Starwind] Cloud VTL avec Amazon Web Services and Veeam

     Aujourd’hui nous allons voir comment déployer la solution Starwind VTL et l’utiliser avec Veeam, avec un backup dans Amazon Web Services.

    Pour commencer, vous devez avoir les prérequis suivants:

    • Un serveur Veeam Backup and Replication
    • Un compte Amazon Web Services: https://aws.amazon.com/
    • Un server Starwind VTL avec du stockage 

    Vous pouvez ensuite télécharger le logiciel Starwind Cloud VTL directement ici: https://www.starwindsoftware.com/starwind-cloud-vtl-for-veeam

    Commencez l’installation du logiciel Virtual Tape Library en cochant bien Cloud Replicator VTL pour active la function de replication vers le Cloud:

      

    Une fois le logiciel installé, créez un VTL et ajoutez une tape:

      

    Si vous souhaitez héberger vote fichier tape dans un dossier personnalisé, choisissez le:


    Choisissez le nombre de tape à créer, ainsi que le type et la taille (1500Gb par défaut):


    Notre tape a été créée correctement:

      

    Allez maintenant sur votre compte Amazon, et créez un bucket (compte de stockage) pour héberger vos backups tape.

    Allez ensuite dans la partie IAM pour gérer les utilisateurs:


    Ajoutez un nouvel utilisateur:


    Donnez lui un accès Programmatic:

    Puis donnez lui les permissions AmazonGlacierFullAccess et AmazonS3FullAccess:

     

    Quand l’utilisateur a été créé, récupérez les valeur Access key ID ainsi que Secret Access key:

      

    Dans la console Starwind VTL, cliquez sur Cloud Replication…:

      

    Renseignez l’access key ID que vous avez récupéré précédemment, ainsi que la clé secrète. Choisissez où le bucket a été créé, et renseignez son nom:


    Choisissez quand effectuer la replication vers le cloud, si vous conservez sur le disque le fichier qui a été envoyé vers le cloud et enfin, quand vous souhaitez déplacer les fichiers de Amazon S3 vers le Glacier:

      

    Sur votre serveur Veeam, connectez en iSCSI le serveur Starwind VTL:


    Installez les drivers HP pour le Tape, pour Windows Server:

    https://h20566.www2.hpe.com/hpsc/swd/public/detail?swItemId=MTX_7e9f343865d1445e92cfbaf0b1


    Après l’installation, si le driver Medium Changer Devices n’est pas à jour, mettez le à jour. Vous devriez avoir ceci:

      

    Ajoutez maintenant le serveur Tape dans Veeam:

      

    La tape est maintenant disponible dans Veeam:

      

    Choisissez ce que vous souhaitez mettre sur cette tape, des fichiers ou des backups:

    Dans mon cas, je vais backup les fichiers de backups, pour tester la fonctionnalité:

      

    Choisissez le dossier avec les fichiers à sauvegarder:

    Créez un nouveau Media Pool avec les tapes qui pourront être utilisées pour sauvegarder le contenu:

    Utilisez ce pool pour faire votre sauvegarde full:

    Et le pool pour la partie incrémentale:


    Adaptez les options avec votre configuration:


    Une fois la configuration terminée, lancez le job:


    A la fin du backup, la tape est directement sauvegardée vers Amazon S3:

      

    Une fois la copie vers le Cloud terminée, le media passe Offline:


    Du côté de notre bucket Amazon, les fichiers sont disponibles:

      

    Comme vous pouvez le voir, la tape n’est plus disponible localement car c’est ce que l’on avait demandé. Pour la réstaurer, cliquez sur Restore from Cloud…:


    Choisissez la tape à restaurer:


    Le téléchargement commence:

      

    Une fois le téléchargement terminé, vous pouvez voir que la tape est de nouveau disponible localement. Cliquez sur Insert Tape… pour la monter:


    Choisissez la tape que vous venez de télécharger:


    Ainsi qu’un slot pour la monter:


    La tape est montée:


    Dans Veeam, cliquez sur Catalog Library pour scanner de nouveau les tapes sur le serveur VTL:

      

    Après quelques instants, la tape apparait, avec le statut Online, dans son Media Pool d’origine:


    Vous pouvez restaurer des fichiers, directement depuis la tape restaurée:


    Choisissez le fichier à restaurer:


    Et où vous souhaitez le restaurer:


    Après quelques instants, la restauration est terminée.


    Ce logiciel est très intéréssant pour les entreprises qui souhaitent se séparer des tapes physiques (qui prennent des ressources, de la place, etc.) tout en conservant l’aspect fonctionnel de ce dernier. Le transfert des tapes vers le Cloud est devenu un moyen de faire des économies en conservant toujours la même quantité de stockage avec le même matériel et la même place, tout en conservant les backups sur le long terme.

    Encore un super produit fourni par les équipes de Starwind, et qui fonctionne très rapidement, sans bug.

    En attendant la même version , mais compatible avec Azure cette fois-ci.

    • 25/9/2017

    [Honolulu] Découverte de la preview

    Microsoft a rendu disponible la semaine dernière, avant Microsoft Ignite, la première preview publique de sa nouvelle interface de gestion de l'infrastructure Hyper-V, appelé Honolulu:

    https://docs.microsoft.com/en-us/windows-server/manage/honolulu/honolulu

    Pour commencer, téléchargez le fichier d'installation:

    https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-honolulu

    Une fois téléchargé, vous pouvez l'installer sur:

    • Windows 10
    • Windows Server 2016

    Que ce soit une VM dédié, ou un hôte Hyper-V, il n'y a pas d'importance. Lancez le fichier d'installation, et démarrez la:

    Choisissez d'autorisé l'interface à modifier les Trusted Hosts du serveur qui reçoit l'installation:

    Choisissez le port d'installation de l'interface, et choisissez le certificat SSL si vous en avez un, sinon ce sera un self-signed:

    L'installation commence:

    Après quelques minutes, l'installation est terminée:

    Quand ceci est terminé, il vous suffit, via Edge ou Chrome, d'aller sur le nom de votre serveur, suivi du port, en https. Vous devriez arriver sur une page similaire:

    Ajoutez un serveur Hyper-V, ou un cluster, ou un cluster S2D, en cliquant sur Add suivi de votre choix:

    Renseignez le nom du serveur ou cluster, et cliquez sur Submit:

    Vous pouvez maintenant gérer votre serveur/cluster directement depuis cette interface:

    Vous pouvez voir l'état des machines virtuelles sur l'hôte/cluster:

    Enfin, si des modules sont disponibles pour améliorer l'interface, ils se trouveront dans les Settings > Extension Manager:

    Cette nouvelle interface est très prometteuse et très simple d'utilisation. Vous pouvez, via une seule console, faire les mises à jour des serveurs, gérer les serveurs, et toutes les fonctionnalités du serveur/cluster. N'hésitez pas à donner votre feedback ici: https://windowsserver.uservoice.com/forums/295071-management-tools/category/319162-project-honolulu 

    • 21/9/2017

    [Azure Automation] Source Control avec Github

    Aujourd'hui je vais vous parler d'une nouvelle feature que j'ai découvert le week-end dernier, lors du PowerShell Saturday User Group à Paris, l'intégration entre Azure Automation et Github. Cette intégration vous permettra d'avoir le contrôle et le versionning de vos sources.

    Pour commencer, allez dans votre compte Azure Automation et allez dans Source Control:

    Cliquez sur Choose Source pour choisir votre source, Github (c'est la seule source disponible au moment où j'écris cet article):

    Après ça, dans la partie Authorization, connectez vous à votre compte Github:

    Dans la section Choose repository, sélectionnez le dossier où vos scripts Azure Automation sont ou seront sauvegardés:

    Dans la partie Choose Branch, choisissez votre branch, master dans mon cas:

    Dans la partie Runbook Folder Path, spécifiez si les scripts sont stockés dans un dossier spécifique. Dans mon cas, j'ai dédier un dossier pour ça dans mon compte Github, c'est pourquoi j'ai donné le chemin root:

    Quand la configuration est terminée, cliquez sur OK:

    Si un script exist dans votre dossier Github, cliquez sur Sync pour l'importer:

    Quand c'est terminé, le status passe à Completed:

    Et le script apparait comme nouveau Runbook si il n'existait pas:

    Personne n'a modifié ce Runbook car il vient d'être importé de Github:

    Si vous mettez localement à jour le script, l'uploadez sur Github et que vous faites une nouvelle synchronisation, le résultat est le même:

    Si vous modifiez votre script sur Azure Automation, vous pouvez le pousser sur Github en cliquant sur Check in:

    Dans l'interface Github, votre script a été mis à jour depuis Azure Automation, comme vous le voyez dans les commentaires:

    Comme vous pouvez le voir, c'est maintenant TO à la place de FROM pour Github:

    Cette feature est très intéréssante pour avoir un Source Control pour vos scripts Azure Automation, gratuitement. J'espère voir apparaître rapidement d'autres Source control rapidement.

    • 19/9/2017

    [Azure] Calculez le coût de votre data center dans Azure

    Pendant l'été, Microsoft a rendu disponible un outil pour calculer le TCO (Total Cost of Ownership). Cet outil est une plateforme en ligne, où vous pouvez y accéder depuis ici: https://www.tco.microsoft.com/

    Cet outil peut être utilisé de façon manuelle, en fournissant les informations des serveurs manuellement, ou de façon semi-automatiquen en utilisant l'outil MAP: https://www.microsoft.com/en-us/download/details.aspx?id=7826

    La dernière version date de Février 2017, et vous aidera à faire l'assessment, sur les serveurs qui sont Online.

    Pour commencer, lancez MAP sur un ordinateur ou serveur et choisissez de créer une base de donnée, pour l'inventaire:

    Cliquez sur Perform an inventory pour démarrer l'inventaire de vos serveurs:

    Une nouvelle fenêtre apparait. Choisissez quel type de serveur vous souhaitez évaluer. Ces serveurs seront évalués pour aller sur Azure:

    Sélectionnez la méthode que vous souhaitez utiliser pour découvrir les ordinateurs, par exemple Active Directory:

    Renseignez des credentials qui peuvent être utiliser pour lire les objets Computers dans l'Active Directory:

    Sélectionnez les OU que vous souhaitez scanner dans votre AD:

    Fournissez un utilisateur qui a les droits de se connecter aux ordinateurs qui seront scannés, avec WMI (administrateur local par exemple) ou autre, dépendant des ordinateurs que vous souhaitez scanner:

    Ajoutez chaque compte avec chaque technologie:

    Si vous utilisez des credentials spécifiques pour des groupes d'ordinateurs, modifiez l'ordre d'utilisation:

    Cliquez sur Finish pour démarrer l'évaluation:

    L'évaluation est en cours:

    Quand l'évaluation est terminée, vous pouvez fermer la fenêtre:

    Dans la fenêtre MAP, cliquez sur Environment:

    Double cliquez sur Inventory Results:

    Dans la nouvelle fenêtre, cliquez sur Generate Inventory Result Report:

    Le rapport Excel est généré, il nous servira pour le TCO:

    Ouvrez le fichier Excel et supprimez les 3 premières lignes:

    Si certains ordinateurs étaient éteint pendant l'évaluation, ceci a généré des lignes avec des valeurs Insufficient Data. Vous DEVEZ supprimer ces valeurs, en supprimant la ligne entière de l'ordinateur en question, sinon le calculateur TCO ne fonctionnera pas:

    Maintenant allez sur le calculateur TCO et cliquez sur Start Now:

    https://www.tco.microsoft.com/

    Cliquez sur Bulk Input pour importer votre fichier Excel, et modifiez la région, la devise ainsi que sur combien d'années vous souhaitez faire le calcul:

    Choisissez le fichier Excel que vous avez modifié, et choisissez votre capacité de stockage, SSD ou non. Cliquez sur Calculate:

    Après quelques secondes, vous aurez un aperçu du prix sur Azure par and, avec les serveurs qui ont été scannés, et le coût économisé en allant sur Azure:

    En haut du rapport, vous pouvez télécharger le Bulk Report avec chaque détail, pour chaque ordinateur. Vous aurez également l'équivalent OnPrem vers Azure:

    Cet outil est très interéssant pour faire une rapide évaluation et pour avoir un équivalent sur Azure. Mais, attention avec l'estimation du coût que vous allez économisé en allant sur Azure. En effet, ceci dépend des serveurs que vous utilisez, du pays où ils sont, etc. Dans mon exemple, mes VMs OnPrem tournent sur un Intel NUC, et je n'ai pas 1000€ d'électricité par an pour ce NUC. Donc utilisez cet outil pour avoir une rapide overview du prix sur Azure pour votre environnement, mais comparez les valeurs avec les valeurs réels de votre datacenter.

    • 18/9/2017

    [GitHub Enterprise] Renouveller le certificat rapidement avec Let's Encrypt

    Le problème du Github Enterprise est que c'est une black box. C'est à dire, que vous ne pouvez rien modifier sur la VM, sinon l'application ne fonctionnera plus.

    Du coup, si vous souhaitez utiliser un certificat signé publiquement, et ne pas payer (+/- 1500€ pour 2 ans avec tous les noms DNS à rajouter...), il reste la méthode Let's Encrypt. Seulement, le certificat est valable que 3 mois... et vous devez ajouter les enregistrements DNS de type TXT, à la main, sur votre hébergeur DNS. Pas très pratique, et pas très intéressant.

    Après quelques recherches, je suis tombé sur le projet Dehydrated, qui permet d'automatiser la chose:

    https://github.com/lukas2511/dehydrated

    Ce tool vous permet de mettre à jour vos DNS sur votre hébergeur, de façon automatique, avec Let's Encrypt, et le protocole ACME-Server. J'ai trouvé une liste qui supporte plusieurs hébergeurs, et qui fonctionne avec ce projet:

    https://github.com/lukas2511/dehydrated/wiki/Examples-for-DNS-01-hooks

    Pour ma part, mon hébergeur est Azure, j'ai donc utilisé ce projet: https://github.com/jangins101/letsencrypt-azuredns-hook

    Ce que je vais expliquer maintenant sera toujours pareil,pour n'importe quel hébergeur (il faudra juste adapter le nom). Utilisant Azure, je vais installer Azure CLI sur mon serveur Debian (étant donné que je ne peux rien installer sur mon serveur Github, j'utilise un serveur séparé), ainsi que le logiciel dehydrated, certbot (qui permet d'utiliser Let's Encrypt pour générer le certificat):

    echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ wheezy main" | sudo tee /etc/apt/sources.list.d/azure-cli.list
    curl -sL https://deb.nodesource.com/setup | sudo bash -
    sudo apt-key adv --keyserver packages.microsoft.com --recv-keys 417A0893
    sudo apt-get install apt-transport-https
    sudo apt-get update && sudo apt-get install nodejs-legacy git dehydrated letsencrypt certbot jq
    sudo apt-get install libssl1.0.0=1.0.1t-1+deb8u6 libssl-dev nodejs-dev node-gyp npm
    sudo npm install -g azure-cli

    Nous allons ensuite récupérer les sources de notre hébergeur (Azure pour moi):

    sudo mkdir /var/scripts/letsencrypt
    cd /var/scripts/letsencrypt
    sudo git clone https://github.com/jangins101/letsencrypt-azuredns-hook.git

    Si vous n'avez pas créé de SPN pour vous connecter à Azure, éditez le fichier createSPN.sh et créez ce dernier ou utilisez la version manuel

    Une fois ceci terminé, éditez le fichier config.sh pour utiliser la CA de production, et non de staging et modifiez le chemin BASEDIR avec le chemin où sera stocké les certificats:

    sudo vi /var/scripts/letsencrypt/letsencrypt-azuredns-hook/config.sh

    Il faut maintenant modifier le fichier azure.hook.sh avec les informations que vous avez récupéré lors de la création du SPN (nom de votre Azure AD, le nom d'utilisateur SPN et le mot de passe, le groupe de resource où est stocker la zone DNS, le nom de la zone DNS et la TTL):

    sudo vi /var/scripts/letsencrypt/letsencrypt-azuredns-hook/azure.hook.sh

    Le script va se connecter et mettre à jour les DNS avec la valeur TXT qu'il aura récupéré de Let's Encrypt. J'ai ensuite fait un petit script, qui va faire la demande du certificat, et mettre à jour le certificat automatiquement, via l'API Github Enterprise. Vous devez adapter la valeur où se trouve le script, ainsi que le nom DNS de votre Github Enterprise. Le script est disponible ici:

    https://github.com/Flodu31/Bash/blob/master/GithubRenewCert.sh

    Pour l'exécuter, utilisez la commande suivante, et fournissez le mot de passe de l'administration du Github:

    sudo bash /var/scripts/GithubRenewCert.sh

    Comme vous le voyez, le script va tout faire de façon automatique et après quelques minutes, votre certificat sera à jour:

      

    Si vous avez des questions, n'hésitez pas 

    • 14/9/2017

    [OMS] Récupérer des informations avec PowerShell

    Voulant automatiser la classification des agents OMS qui sont connectés à mon workspace, j'ai cherché différentes options pour récupérer le nom des serveurs avec des agents installés. Il y a 2 possibilités:

    • PowerShell
    • API

    J'ai choisi la méthode PowerShell, la plus simple pour moi. Ceci fonctionne avec les version 1 et 2 de OMS. Pour commencer, vous avez besoin des informations suivantes:

    • Le nom du workspace
    • Le groupe de ressource où le workspace OMS est
    • Le module AzureRM.OperationalInsights avec la version 3.3.1 minimum

    Vous pouvez effectuer vos requêtes suivant 2 types:

    • Nouvelle requête
    • Requête qui est sauvegardée sur votre workspace OMS

    Afin de faire des requêtes, nous allons importer le module et nous connecter à notre suscription Azure, qui a les droits sur le groupe de ressource OMS:

    Import-Module AzureRM.OperationalInsights -MinimumVersion 3.3.1
    Login-AzureRmAccount
    Select-AzureRmSubscription -SubscriptionId SubscriptionID

    Quand ceci est terminé, adaptez les variables suivantes avec vos informations:

    $rgName = "oms"
    $WorkSpaceName = "florentappointaire"
    $dynamicQuery = "Heartbeat | distinct Computer"

    Ici, je vais récupérer la liste de mes serveurs qui sont connectés à OMS:

    Exécutez maintenant la commande suivante, pour obtenir, en PowerShell, le résultat:

    $result = Get-AzureRmOperationalInsightsSearchResults -ResourceGroupName $rgName -WorkspaceName $WorkSpaceName -Query $dynamicQuery -Top 1000

    Comme vous le voyez, ceci n'est pas très parlant. Mais la bonne nouvelle est que ceci est formaté en JSON. Donc, avec la commande suivante, on obtient quelque chose de plus joli et utilisable:

    $result.Value | ConvertFrom-Json

    Si vous souhaitez utiliser une query qui est sauvegardée sur votre workspace OMS, utilisez la commande suivante, pour la V1:

    $savedSearchId = "General Exploration|DistinctComputer"
    Get-AzureRmOperationalInsightsSavedSearchResults -ResourceGroupName $rgName -WorkspaceName $WorkSpaceName -SavedSearchId $savedSearchId

    Où $savedSearchId est le nom de la catégorie où la recherche se trouve, suivi du nom de la recherche.

    Seulement, si vous utilisez la V2 de OMS, il faudra utiliser d'autres commande, car vous aurez l'erreur suivante:

    Get-AzureRmOperationalInsightsSavedSearchResults : Saved search result not supported for the new query language
    At line:1 char:1
    + Get-AzureRmOperationalInsightsSavedSearchResults -ResourceGroupName $ ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Get-AzureRmOper...edSearchResults], CloudException
    + FullyQualifiedErrorId : Microsoft.Rest.Azure.CloudException,Microsoft.Azure.Commands.OperationalInsights.GetAzureOperationalInsightsSavedSearchResultsCommand

    Utilisez alors le script suivant:

    $savedSearchId = "General Exploration|DistinctComputer"
    $query = Get-AzureRmOperationalInsightsSavedSearch -ResourceGroupName $rgName -WorkspaceName $WorkSpaceName -SavedSearchId $savedSearchId

    $result2 = Get-AzureRmOperationalInsightsSearchResults -ResourceGroupName $rgName -WorkspaceName $WorkSpaceName -Query $query.Properties.Query -Top 1000
    $result2.value | ConvertFrom-Json

     Comme vous pouvez le voir, ceci est très pratique pour automatiser vos différents workloads.

    • 19/7/2017

    [AzureStack] Déploiement dans Azure

    Avec la sortie récente des machines V3 sur Azure, il est maintenant possible de faire du Nested Hyper-V, comprenez donc de faire tourner des VMs dans un VM Azure.

    Azure Stack Development Kit venant de sortir, c'est l'occasion pour moi de déployer cette dernière version dans Azure, n'ayant pas le matériel nécessaire pour le faire tourner chez moi. Attention, ce type de déploiement n'est pas supportée par Microsoft et ne peut être utilisé qu'en test.

    Daniel Neumann, TSP Azure chez Microsoft a fourni une version de son installation, en L2: http://www.danielstechblog.info/running-azure-stack-development-kit-azure/

    J'utiliserai certaines parties de ce billet pour mon installation. La différence est qu'il déploie Azure Stack dans une VM qui est sur la VM sur Azure. Alors que dans mon cas, on va déployer Azure Stack directement sur la VM Azure.

    Avant de commencer, créez un compte Azure AD qui est Global Admin. Ce compte sera utilisé pour connecter votre Azure Stack à Azure AD.

    Pour commencer, déployez une VM Windows Server 2016 sur Azure, de taille minimum E16s v3 (16 cores, 128 GB memory). Ce sont en effet les prérequis pour faire tourner Azure Stack: https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-deploy

    Une fois que la VM est deployée, connectez vous dessus et n'appliquez surtout pas les mises à jour, puis nous allons renommer le compte administrateur local pour ne pas à avoir à modifier tous les scripts:

    Rename-LocalUser -Name Florent -NewName Administrator

    Eteignez la VM via l'interface Azure, puis allez dans la partie disque. Agrandissez le disque OS à 256GB et ajoutez 4 disques pour la partie Storage Space Direct, de 256GB chacun minimum:

    Rallumez la VM et initialisez les disques, sans oublier d'étendre le disque OS. Adaptez la time zone en fonction de votre fuseau horaire, et désactivez le IE Enhanced Security Configuration. Vous pouvez maintenant installer des prérequis pour gagner du temps par la suite:

    Add-WindowsFeature Hyper-V, Failover-Clustering, Web-Server -IncludeManagementTools
    Add-WindowsFeature RSAT-AD-PowerShell, RSAT-ADDS -IncludeAllSubFeature
    Install-PackageProvider nuget -Verbose

    Redémarrez le serveur:

    Restart-Computer

    Vous pouvez maintenant télécharger Azure Stack: https://azure.microsoft.com/en-us/overview/azure-stack/development-kit/

    Une fois extrait, montez le disque CloudBuilder.vhdx et copiez les dossiers CloudDeployment, fwupdate et tools dans votre disque C. Vous pouvez éjecter le disque CloudBuiler. Ouvrez une console PowerShell puis faite:

    cd C:\CloudDeployment\Setup
    .\InstallAzureStackPOC.ps1 -InfraAzureDirectoryTenantName yourdirectory.onmicrosoft.com -NATIPv4Subnet 172.16.0.0/24 -NATIPv4Address 172.16.0.2 -NATIPv4DefaultGateway 172.16.0.1 -Verbose

    Pour les IPs adresses, utilisez des IPs qui ne sont pas utilisées sur votre VNet Azure ni pas Azure Stack. Vous allez avoir une première erreur qui vous dit que votre serveur n'est pas un serveur physique. Pas de panique. Il suffit de modifier le fichier C:\CloudDeployment\Roles\PhysicalMachines\Tests\BareMetal.Tests.ps1 et de rechercher $isVirtualizedDeployment. Cette variable est présente 3 fois dans le fichier. Retirez le -not devant chaque variable. Relancez l'installation avec la commande suivante:

    .\InstallAzureStackPOC.ps1 -Rerun -Verbose

    Si vous avez une erreur avec CredSSP au moment de la modification du nombre maximum d'objet, effectuez ceci. Sur le serveur DC, exécutez la commande suivante:

    Enable-WSManCredSSP -Role Server

    Sur le serveur Hyper-V, exécutez les commandes suivantes:

    Set-Item wsman:localhost\client\trustedhosts -Value *
    Enable-WSManCredSSP -Role Client -DelegateComputer *

    Puis, ouvrez la console gpedit.msc, allez dans Local Computer Policy > Computer Configuration > Administrative Templates > System > Credential Delegation.

    Activez Allow Delegating Fresh Credentials with NTLM-only Server Authentication et ajoutez la valeur WSMAN/*. Relancez le script.

    Une fois la VM BGPNAT déployée, exécutez le script suivant pour créer un nouveau virtual switch qui donne accès à Internet à la VM, en adaptant avec l'adresse IP que vous avez utilisé lors du lancement du script:

    New-VMSwitch -Name "NATSwitch" -SwitchType Internal -Verbose
    $NIC=Get-NetAdapter|Out-GridView -PassThru
    New-NetIPAddress -IPAddress 172.16.0.1 -PrefixLength 24 -InterfaceIndex $NIC.ifIndex
    New-NetNat -Name "NATSwitch" -InternalIPInterfaceAddressPrefix "172.16.0.0/24" -Verbose

    Allez dans les paramètres de la VM BGPNAT et changez le virtual switch de la carte NAT de PublicSwitch vers NATSwitch:


    Vous pouvez maintenant pinger les IPs externes:

    Le déploiement de l'infrastructure continue:

    Après quelques heures, le déploiement est terminé, et vous pouvez vous connecter à l'interface utilisateur et d'administration:

    • 18/7/2017

    [OMS] Créer des rapports dans PowerBI

    Aujourd'hui nous allons découvrir comment connecté votre workspace OMS à PowerBI. Ceci est actuellement en Preview.

    Pour commencer, connectez vous à votre workspace OMS et allez dans Settings > Preview Features et activez PowerBI Integration:

    Rafraichissez la page web. Dans Settings, vous avez un nouvel onglet, Power BI. Allez dans Accounts > Workspace Information et cliquez sur Connect to Power BI Account. Ce compte doit être un compte d'entreprise, connecté à Office 365 par exemple:

    Le compte est maintenant connecté:

    Si vous allez dans la partie Log Search, vous avez un nouvel icône, Power BI. Exécutez la recherche que vous souhaitez envoyer dans votre dashboard PowerBI et cliquez sur l'icône:

    Renseignez le nom de cette recherche et modifiez le temps d'execution de cette recherche. Donnez un nom au Dataset. Ce nom sera utilisé dans PowerBI.

    Si vous allez dans vos Settings, vous verrez votre recherche:

    Maintenant, allez sur https://app.powerbi.com et connectez vous avez le compte que vous avez utilisé dans OMS. Après quelques minutes, le dataset apparait:

    Vous pouvez maintenant créer un rapport. Dans mon exemple, il correspond aux OS qu'il y a dans mon environnement:

    Vous avez les résultats directement sur le dashboard:

    Cliquez sur Save pour sauvegarder ce rapport pour y accéder plus facilement plus tard:

    Donnez lui un nom:

    Vous pouvez maintenant accéder au rapport rapidement:

    Cette nouvelle fonctionnalité est très intéressante, notamment pour les membres d'une équipe de management, qui doit avoir des rapport de façon régulière, etc.

    Vous pouvez créer rapidement des dashboards dynamiques, sans connaissances dans OMS 

    • 17/7/2017

    [PowerShell] Utiliser des APIs

    Voulant utiliser une API GitHub avec Azure Automation, j’ai du me lancer dans la découverte de l’utilisation des APIs avec PowerShell.

    Le première chose est de trouver la documentation pour l’API Github: https://developer.github.com/v3/ 

    La deuxième a été de trouver la cmdlet PowerShell pour utiliser les APIs, Invoke-RestMethod: https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.utility/invoke-restmethod

    Une fois que vous avez ceci, vous pouvez commencer à travailler 

    Pour pouvoir vous authentifier via une API, nous devons passer un token dans le header. Pour Github, vous pouvez générer un token ici: https://github.com/settings/tokens

    Assurez vous de bien copier le token car vous ne pourrez pas le récupérer par la suite.

    Si vous allez sur l’URL suivante, https://api.github.com/, vous pourrez voir les actions que vous pouvez effectuer via l’API:

    A savoir, vous avez plusieurs méthodes pour utiliser une API:

    • GET
    • POST
    • PUT
    • DELETE
    • Etc.

    Nous allons voir comment utiliser quelques méthodes, en manipulant les répertoires ( https://developer.github.com/v3/repos/ ).

    Les URLs commençeront toujours par https://api.github.com et à la suite, nous ajouterons les options, suivant ce que l’on souhaite faire, et sur quoi.

    Commençons avec la méthode GET. Nous allons récupérer maintenant la liste de nos répertoires qui existent pour notre compte Github:

    $token = "yourtoken"
    $
    tokenAuth = "token $token"                                                                                           
    $headers = @{ Authorization = $tokenAuth }                                                                  
    $basedURL = 'https://api.github.com'                                                                       
    $uri = $basedURL + "/user/repos"                                                                                      
    $req = Invoke-RestMethod -Uri $uri -Headers $headers
    foreach ($r in $req){

                Write-Output $r.Name
                Write-Output $r.url

    }

    Passons maintenant à la méthode POST. Grace à cette méthode, nous allons pouvoir créer des repositories par exemple.

    $token = "token"                                                                       
    $tokenAuth = "token $token"                                                                                            
    $headers = @{ Authorization = $tokenAuth }
    $body = '{

      "name": "FlorentAppointairePowerShell",
      "description": "This is a test :)",
      "homepage": "https://microsofttouch.fr",
      "private": false,
      "has_issues": true,
      "has_projects": true,
      "has_wiki": true

    }'                          

    $basedURL = 'https://api.github.com'                                                                       
    $uri = $basedURL + "/user/repos"
                                                                                         
    Invoke-RestMethod -Uri $uri -Headers $headers -Method POST -Body $body

    Et l'interface web:

    Nous allons maintenant supprimer ce répertoire avec la méthode DELETE:

    $token = "token"                                                                 
    $tokenAuth = "token $token"                                                                                           
    $headers = @{ Authorization = $tokenAuth }                                      
    $basedURL = 'https://api.github.com'
    $uri = $basedURL + "/repos/flodu31/FlorentAppointairePowerShell"                                                                                       
    Invoke-RestMethod -Uri $uri -Headers $headers -Method DELETE

    Depuis l'interface, le répertoire a disparu:

    Cette nouvelle méthode que j'ai découvert est très intéressante pour la partie automatisation, parce que vous pouvez faire ce que vous voulez, si l'API le permet bien sur 

    N'hésitez pas à me contacter si vous avez des questions  

    • 7/7/2017

    [OMS] Créer des Customs Fields

    Une nouvelle fonctionnalité vient d'apparaître depuis quelques mois sur OMS, la possibilité de créer des champs personnalisés (Custom Field). Ceci vous permet de classifier des recherches de façon plus simple et plus rapide que d'effectuer des longues recherches.

    Pour commencer, assurez-vous d'avoir un workspace OMS et de récupérer des logs:

    Vérifiez également que dans la recherche, vous avez des logs disponibles:

    Sélectionnez un log qui vous intéresse et pour qui, vous souhaitez créer des customs fields. Je vais sélectionner un log de redémarrage de service:

    Puis cliquez sur les ... qui se trouvent à côté de ParameterXml (vous pouvez le faire sur une autre catégorie si vous le souhaitez) et choisissez Extract fields from 'Event' (Preview):

    Vous devriez arriver sur une page de sélection, comme celle-ci:

    Sélectionnez la partie qui vous intéresse, donnez lui un nom et cliquez sur Extract:

    De façon automatique, OMS va chercher dans les logs actuels si il y a des correspondances. Si il y en a, il va automatiquement les passer en bleu. Si ce n'est pas fait de façon automatique, ou si il manque une partie du texte, cliquez sur les 3 petits points suivants et choisissez Modify this highlight:

    Sélectionnez le texte et associez le au custom field créé précédemment:

    Quand tous résultats de la recherche sont associés au custom filed, cliquez sur Save Extraction:

    Faites de même avec le status du service, stopped ou running:

    A partir de maintenant, chaque service qui sera redémarré appliquera les customs fields que l'on a créé. Malheureusement, ça ne s'applique pas sur les logs créés avant d'avoir fait ceci.

    Une fois ceci terminé, vous pouvez utiliser ces customs fields dans la recherche:

    Et les utiliser dans une vue personnalisée:

    Cette fonctionnalité est très intéressante pour classer des logs et avoir un aperçu rapide et automatisé sans utiliser de scripts PowerShell ou autre qui sont lourds à déployer.

    Si vous avez des questions, n'hésitez pas 

    • 3/7/2017

    Microsoft MVP pour la 2ème année

    Bonjour à tous,

    Je suis heureux de vous annoncer que j'ai été, pour la deuxième année consécutive, nominé en tant que MVP Cloud and Datacenter Management.

    Je remercie tous les gens qui contribuent à mon évolution de près ou de loin, et surtout, à ma famille, mes amis et le petit dernier, mon enfant qui me donne la motivation d'aller toujours plus loin.

    Pour cette année qui arrive, je vais continuer d'écrire des articles sur les différents produits avec lesquels je travaille, mais aussi faire quelques sessions si elles sont retenues (PowerShell Saturday à Paris, aOS Luxembourg, etc.) sans oublier le MVP Summit en Mars 2018 à Seattle

    Le travail paye, ne renoncez jamais...

    Encore merci à tous

    Florent

    • 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.

    • 26/4/2017

    [StarWind] Virtual SAN Free sur Linux sous forme d'appliance

     

    StarWind a rendu disponible StarWind Virtual SAN Free sur Linux le 25 Avril 2017. Celle ci est sous forme d'appliance (VSA pour Virtual Storage Appliance) et vous propose d'utiliser la console directement depuis un navigateur web.

    Pour commencer, il faut vous inscrire pour pouvoir télécharger l'appliance pré installée et qui est disponible pour VMWare ESX, Hyper-V et KVM:

    https://www.starwindsoftware.com/download-starwind-virtual-san-vsa

    Je vais parler de la partie Hyper-V. Téléchargez l'image pour Hyper-V.

    Une fois que vous avez extrait l'image, vous devriez avoir un VDHX de 10GB environ.

    Créez une VM, de type Generation 1 avec plusieurs cartes réseaux si vous souhaitez séparer le traffic, plusieurs disques, etc:

    Une fois terminé, si vous lancez la console, vous devriez vois l'interface de management de StarWind:

    Connectez-vous au serveur et fermez le message de configuration en cliquant sur la croit en haut à droite de la fenêtre.

    Vous avez 2 possibilités pour connecter votre VM:

    • Avec un réservation DHCP (mon cas)
    • En allant dans Configuration > Network > YouManagementCard > Modify

    Connectez vous via un navigateur à la console StarWind (utilisateur et mot de passe par défaut: starwind):

    Vous devriez avoir tous les disques que vous avez déjà lié à la VM. Si vous en ajoutez un par la suite, cliquez sur Scan Storage:

    Le nouveau disque devrait apparaitre:

    Choisissez un disque et créez un volume en cliquant sur Create Volume:

    Maintenant, vous avez votre nouveau volume:

    Vous pouvez modifiez l'IP adresse directement depuis la partie VSA Network Settings, si vous avez plusieurs carte, pour isoler le trafic:

     Vous êtes maintenant prêt pour créer votre premier volume. Cliquez sur Add Device (advanced) et suivez les étapes pour créer le volume:

    Le volume a été créé correctement et il peut être présenté à une ou plusieurs machines: 

    Sur le serveur windows, ajoutez comme target iSCSI l'adresse IP du serveur Starwind (l'interface réseau du stockage, pas du management):

    Après quelques instants, vous pouvez voir dans la console le nouveau serveur qui est connecté:

    Vous pouvez initialiser le disque, et le formater: 

    Une fois de plus, StarWind facilite l'accès au stockage partagé en proposant directement une version pré-installé et pré-configuré, idéal pour les petites/moyennes entreprises, qui n'utilisent pas Windows Server et qui souhaite utiliser facilement du storage qui se trouve dans un seul serveur, pour plusieurs serveurs :)

    • 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 :)