Allocate licenses in bulk to your Office 365 users (Option 1 : Using PowerShell)

As an Office 365 IT professional, you may need to allocate license to users. There are several ways for doing that. Here, I will show you two ways to achieve your goal.

  • Option 1 : Allocate licenses in bulk to your Office 365 users using PowerShell
  • Option 2 : Allocate licenses in bulk to your Office 365 users using Azure Active Directory group membership

Option 1 : Allocate licenses in bulk to your Office 365 users using PowerShell

Below is the script I’m sharing with you.

Function Set-o365UsersLicense{

    [Parameter(mandatory=$true)]$upnPath,                                 #Path to the .csv file containing users UserPrincipalName
    [Parameter(mandatory=$false)]$LicensePlan = "E1",                     #Office 365 License Plan to be allocated to users
    [Parameter(mandatory=$false)]$DisabledOptions = "YAMMER_ENTERPRISE",  #Disabled Feature
    [Parameter(mandatory=$true)]$LogPath = "c:\"                          #Logs path

  $LicenseToAdd = $Null
  $DisableYammer = $False
  $LicenseOptions = @()

  #Finding License Plan to activate
    "E1" { 
        Write-host "You chosed Plan E1" -ForegroundColor Green
        $LicenseToAdd = "kingo:STANDARDPACK" 
        $LicenseToRemove = "kingo:ENTERPRISEPACK","kingo:WACONEDRIVESTANDARD" 
   "E3" {
        Write-host "You chosed Plan E3" -ForegroundColor Green
        $LicenseToAdd = "kingo:ENTERPRISEPACK" 
        $LicenseToRemove = "kingo:STANDARDPACK","kingo:WACONEDRIVESTANDARD" 
   "OD" {
        Write-host "You chosed To assign OneDrive" -ForegroundColor Green
        $LicenseToAdd = "kingo:WACONEDRIVESTANDARD" 
        $LicenseToRemove = "kingo:STANDARDPACK","kingo:ENTERPRISEPACK" 
    Default { 
        Write-Host "$LicensePlan is not a valid License Plan parameter !" -ForegroundColor Red

  #Importing users to be assigned License
  $upns = Import-Csv $upnPath

  #Checking Licenses availability
  $MsolAccountSku = Get-MsolAccountSku | ? {$_.AccountSkuId -ilike $LicenseToAdd}
  $AvailableLics = $MsolAccountSku.ActiveUnits - $MsolAccountSku.ConsumedUnits

  #Assigning License to user
  If($AvailableLics -ge $upns.Count){

    #Creating not existing upns log file
    "Not existing upn List" > $($LogPath + "Upns_Not_Exist.log.log")

    #Defining License options to disable
    if($DisabledOptions -in $MsolAccountSku.ServiceStatus.ServicePlan.ServiceName){
      $LicenseOptions = New-MsolLicenseOptions -AccountSkuId $LicenseToAdd -DisabledPlans $DisabledOptions

    #Enabling users Licenses
    $upns | % {

      #Checking if user exists before processing with licensing
      If($User = Get-MsolUser -UserPrincipalName $_.UserPrincipalName -ErrorAction SilentlyContinue){

        #Getting current user Licenses
        $CurrentUserLicenses = $User.Licenses.AccountSkuId

        #Removing unecessary Licenses
        $LicenseToRemove | %{
          if($CurrentUserLicenses -contains $_){ 
            Set-MsolUserLicense -UserPrincipalName $User.UserPrincipalName -RemoveLicenses $_

        #Assigning New License to user if not already enabled
        If($CurrentUserLicenses -notcontains $LicenseToAdd){

          #Disable YAMMER if License to add is plan E1, E3
            Set-MsolUserLicense -UserPrincipalName $User.UserPrincipalName -AddLicenses $LicenseToAdd -LicenseOptions $LicenseOptions -EA SilentlyContinue
            Set-MsolUserLicense -UserPrincipalName $User.UserPrincipalName -AddLicenses $LicenseToAdd
        #Logging inexisting user account
        $User.UserPrincipalName >> $($LogPath + "Upns_Not_Exist.log")
    Write-Host "There are $AvailableLics $LicensePlan Licenses available" -ForegroundColor Red
    Write-Host "Please reduce users list to match available Licenses or Increase available Licenses" -ForegroundColor Red

  #Exporting errors log
  $Error > $($LogPath + "Set_AzureUserLicense_Error.log")
  Write-Host "Script Logs Location : $LogPath " -ForegroundColor Yellow

A little description about the script parameters is necessary :

$upnPath : is the full path of the .csv file containing users upns

$LicensePlan : specify the license plan you want to configure

  • E1 : Office 365 Enterprise E1
  • E3 : Office 365 Enterprise E3
  • E5 : Office 365 Enterprise E5
  • OD : OneDrive Entreprise (Plan 1)

$DisabledOptions : specify the license feature you want to disable.  « YAMMER_ENTERPRISE » : designate Yammer as the feature to disable

$LogPath = designate the directory path where to save log files

« kingo » : refer to the name of my Office 365 tenant :

The upns (UserPrincipalName) csv file must be formated like below :


Prerequisites for running the script :

  • You will need Office 365 Module For PowerShell
  • Connect to your Office 365 tenant using the command : Connect-MsolService

How to run the script ?

  • With default parameters 
Set-o365UsersLicense -upnPath c:\upns.csv  -LogPath "d:\"

Users will be allocated License E1 with YAMMER disabled, and the log file saved in d:\ path.

  • With full parameters 

If the default parameters does not suit you, you can run a complete command by specifying full parameters like below :

Set-o365UsersLicense -upnPath "c:\upns.csv" -LicensePlan E3 -DisabledOptions "YAMMER_ENTERPRISE" -LogPath "d:\"

To check that users are well assigned licenses, use my previous post Show-LicensesMatrix.

Et voilà… 🙂

Option 2 : Allocate licenses in bulk to your Office 365 users using Azure Active Directory group membership  (coming soon…)

Get your Office 365 users licenses

Hi, here I’m sharing with you a PowerShell script that can help you if you are working on Office 365.

If ever, you asked yourself one day,  how to quickly view the Office 365 licenses configuration for a group of users in your organization, here is a script that can help you achieve that goal.

How does it work :

Step 1 : Connect to Office 365 PowerShell using your Office 365 Admin account. Here is a tuto for that :

Step 2 : Prepare the upns csv file

Open a .txt file and fill it with your users UserPrincipalNames like this :


Once you are done, save the content as a .csv file.

Step 3 : When your are connected, Copy and pass the below script in your console, and press Enter.

Function Show-LicensesMatrix {

    [Parameter(mandatory=$false)]$upnPath = "C:\Scripts\upns.csv"

  #License Plans correspondence table
  $LicensePlans = @{
    E1 = "kingo:STANDARDPACK" 
    E3 = "kingo:ENTERPRISEPACK" 

  $Us = @()
  $Users = Import-Csv $upnPath | % {Get-MsolUser -SearchString $_.userPrincipalName} 

  ForEach ($u in $Users) {
    #Initializing variables
    $E1 = $E3 = $E5 = $OD = $false

    #Getting user License Plans
    if ($u.Licenses.AccountSkuId -contains $LicensePlans.E1){$E1 = $true}
    if ($u.Licenses.AccountSkuId -contains $LicensePlans.E3){$E3 = $true}
    if ($u.Licenses.AccountSkuId -contains $LicensePlans.E5){$E5 = $true}
    if ($u.Licenses.AccountSkuId -contains $LicensePlans.OD){$OD = $true}

    $Us += New-Object -TypeName PSObject -Property @{ 
      UserPrincipalName = $u.userPrincipalName
      E1 = $E1
      E3 = $E3
      E5 = $E5
      OD = $OD
  $Us | ft userPrincipalName, E1,E3,E5,OD

You are ready, run the script now :

Run Show-LicenseMatrix1

The result will look like below :


The meaning of E1, E3, E5 and OD is :

  • E1 : Office 365 Enterprise E1
  • E3 : Office 365 Enterprise E3
  • E5 : Office 365 Enterprise E5
  • OD : OneDrive Entreprise (Plan 1)

« kingo » : refer to the name of my Office 365 tenant :

Et voilà… 🙂


Export Office 365 users and their Licenses configurations

Office 365 provides several ways to see user assigned license plans. You can use the admin portal, Azure Powershell or PowerShell for Office 365.

The biggest question is how to see both assigned license plans, enabled license and disabled license features for many users ? Not easy to reach your goal when using the admin portal. The best way is to use PowerShell.

Here, I provide you an Office 365 Powershell script for exporting all your licensed users, with their assigned license plans, their enabled and disabled licenses options.

Function Export-UsersLicensesConfig {

    #License Plans correspondence table with friendly name
    $LicensePlan = @{         
              ##<companyname>:<Licenseplan> = <license plan friendly name>          
                      "koaf365:AAD_PREMIUM" = "AzureAD Premium Plan 1"             
                   "koaf365:AX7_USER_TRIAL" = "Dynamics AX7.0 TRIAL"         
                     "koaf365:DESKLESSPACK" = "OFFICE 365 F1"       
          "koaf365:DYN365_ENTERPRISE_P1_IW" = "Dynamics 365 Enterprise Plan1"   
              "koaf365:DYN365_RETAIL_TRIAL" = "Dynamics 365 CRM TRIAL"               
                              "koaf365:EMS" = "EMS_E3"             
                       "koaf365:EMSPREMIUM" = "EMS_E5"        
                   "koaf365:ENTERPRISEPACK" = "E3"             
                "koaf365:ENTERPRISEPREMIUM" = "E5"          
                        "koaf365:FLOW_FREE" = "Microsoft Flow"            
                      "koaf365:INTUNE_A_VL" = "Intune Volume License"        
                       "koaf365:MCOMEETADV" = "Skype For Business PSTN Conferencing"   
        "koaf365:MICROSOFT_BUSINESS_CENTER" = "Microsoft Business Center"          
                     "koaf365:POWER_BI_PRO" = "Power BI PRO"         
                "koaf365:POWER_BI_STANDARD" = "Power BI Standard"    
        "koaf365:POWERAPPS_INDIVIDUAL_USER" = "Powerapps Individual User"           
                  "koaf365:POWERAPPS_VIRAL" = "Microsoft PowerApps and Logic flows"        
                   "koaf365:PROJECTPREMIUM" = "Project Online Premium"        
                     "koaf365:STANDARDPACK" = "E1"                
                           "koaf365:STREAM" = "Stream"         
                "koaf365:VISIOONLINE_PLAN1" = "Visio Online Plan 1"           
              "koaf365:WACONEDRIVESTANDARD" = "OneDrive For Business Plan 1"       
                      "koaf365:WIN_DEF_ATP" = "Windows Defender Avanced Threat Protection"
    #Initializing users licenses config table
    $Us = @()

    #Getting all users list    
    $Users = Get-MsolUser -All | ?{$_.isLicensed -eq $true}

    ForEach($u in $Users){          
        #Getting assigned user License Plans        
        $O365Licenses = @()        
        $u.Licenses.AccountSkuId | % {            
            $O365Licenses += $LicensePlan."$_"        
        $O365Licenses = [string]::Join(',',$O365Licenses)            
        #Getting user enabled license features        
        $EnabledFeature = ($u.Licenses | Select -ExpandProperty ServiceStatus | ?{($_.ProvisioningStatus -eq "Success")}).ServicePlan.ServiceName        
        If (($EnabledFeature -ne $null) -and ($EnabledFeature.GetType().BaseType.Name -eq "Array")){                       
            $EnabledFeature = [string]::Join(',',$EnabledFeature)        
        #Getting user license disabled features        
        $DisabledFeature = ($u.Licenses | Select -ExpandProperty ServiceStatus | ?{($_.ProvisioningStatus -eq "Disabled")}).ServicePlan.ServiceName        
        If (($DisabledFeature -ne $null) -and ($DisabledFeature.GetType().BaseType.Name -eq "Array")){                 
            $DisabledFeature = [string]::Join(',',$DisabledFeature)        

        #Updating users Licenses config table       
        $u | Add-Member -MemberType NoteProperty -Name EnabledFeature -Value $EnabledFeature -Force        
        $u | Add-Member -MemberType NoteProperty -Name DisabledFeature -Value $DisabledFeature -Force        
        $u | Add-Member -MemberType NoteProperty -Name O365Licenses -Value $O365Licenses -Force                 
        $Us += $u


    #Exporting user License config    
    $Us | Select userPrincipalName, O365Licenses, EnabledFeature, DisabledFeature | Export-Csv UserLicensesConfig.csv -NoTypeInformation -Delimiter ";" -Encoding UTF8

koaf365 : is the company name that I provided when I enrolled in Office 365, and is unique for my organization.

When you run the script :

> Export-UsersLicensesConfig

The generated UserLicensesConfig.csv file content should be like below.



There you go 🙂 !!!

Get Active Directory Schema Version

To get the schema version of your Active Directory, use the below powershell command line :

Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion


According to the objectVersion (47), we know that the schema is extended to Windows Server 2008 R2.

Find below a list of schema version with the matching Operating system.

Operating system Schema Version
Windows Server 2003 30
Windows Server 2003 R2 31
Windows Server 2008 44
Windows Server 2008 R2 47
Windows Server 2012 56
Windows Server 2012 R2 69
Windows Server 2016 87


Déployer Office 365 ProPlus 2016 – Partie 3 : Installation

Nous progressons avec la 3ème et dernière partie de ce poste. La préparation et l’installation des agents Intune étant terminées, nous pouvons maintenant déployer Office 365 ProPlus 2016. Ce déploiement se fera en deux étapes.

Etape 1: Ajouter une application


Indiquer le chemin d’accès du setup d’office 365 ProPlus téléchargé précédemment.


Dans la page suivante, indiquer le nom de l’éditeur, de l’application que vous installez ainsi qu’une description de cette dernière. Ces cases ont obligatoires.


Nous ajoutons ici la clé de détection de l’application, elle nous permet de savoir si Office 365 ProPlus 2016 est déjà installée. Dans lequel cas l’outil ne tentera pas une nouvelle installation.


Nous utilisons comme clé de détection :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\O365ProPlusRetail - fr-fr

Il vous faut maintenant spécifier l’argument de ligne de commande qui va permettre une installation basée sur le fichier internet.xml.


Pour le déploiement depuis le dépôt local, utiliser l’argument avec le fichier local.xml : /configure local.xml que nous avons vu dans l’article précédent.


Cliquer sur Télécharger pour terminer la configuration.

Etape 2 : Déployer l’application

Retourner dans la console de gestion intune, cliquer-droit sur l’application que vous venez de rajouter, sélectionner l’option Gérer le déploiement.


Rechercher le groupe de déploiement O365-PCS et Ajouter-le. L’objectif est d’installer l’application sur l’ensemble des postes qui sont membres de ce groupe.


Indiquer une échéance pour l’installation. Cela permet à l’agent Intune présent sur le poste de débuter l’installation, théoriquement, à l’échéance indiquée.


Cliquer sur Terminer.

L’installation débute dès que l’agent Intune présent sur le poste reçoit l’information, il tient compte bien entendu de l’échéance indiquée. Un processus OfficeClickToRun.exe s’exécute sur les PCs membres du groupe de déploiement O365-PCs. Vous pouvez l’observer dans le gestionnaire de tâches sous l’onglet Détails. Vous verrez les icônes d’Office apparaître au fur et à mesure que l’installation avance.

Déployer Office 365 ProPlus 2016 – Partie 2 : Préparation de l’installation

Nous poursuivons avec la deuxième partie de notre article. Dans l’article précédent, j’ai partagé avec vous l’installation de l’agent Intune, maintenant nous allons mettre en certains prérequis nécessaire à l’installation d’Office 365 ProPlus 2016 à l’aide de l’agent Intune.

Etape 1: Créer le groupe de déploiement

Je me connecte à mon portail d’administration Azure Active Directory et je crée un groupe qui va contenir les PCs sur lesquels je souhaite déployer la suite Office. Voici les paramètres que j’utilise :

  • Nom du groupe : O365-PCs
  • Description : Groupe Deploiement Office 365 ProPlus 2016
  • Type : Sécurité
  • Type d’appartenance : Affecté


J’ajoute dans le groupe tous les PCs sur lesquels je souhaite faire l’installation. Pour le faire manuellemnet, je clique sur le O365-PCs puis sur Membres.


On peut toutefois utiliser un petit script pour rajouter les PCs au groupe, surtout s’ils sont en quantité importante.

Constituer un fichier Computers.csv qui contient les PCs


Utiliser le script ci-dessous pour rajouter les PCs au groupe de déploiement O365-PCs.

Import-Module AzureAD
$Creds = Get-Credential
Connect-AzureAD -Credential $Creds

$Devices = Import-Csv "<mypath>\Computers.csv" -Delimiter ";" -Encoding UTF8
$GroupObjectID = "<ID du groupe>" #O365-PCs

ForEach ($Device in $Devices){ 
 $DeviceID = (Get-AzureADDevice -All $true | ?{$_.DisplayName -ilike "$($Device.Name)*"}).objectID
 $Device.Name >> "<mypath>\ComputersOnError.txt"
 Else {
 Add-AzureADGroupMember -ObjectId $GroupObjectID -RefObjectId $DeviceID


Etape 2: Préparer le package Office 365 ProPlus 2016

Télécharger l’outil de déploiement de la suite Office

Télécharger Office 2016 Deployment toolextraire le contenu, le copier ensuite sur un partage \\<myShare>\SetupO365ProPlus16\


Cet outil est un prérequis quel que soit le mode d’installation envisagé, depuis un partage réseau (local) ou à partir d’internet (en ligne). A cela s’ajoute les prérequis ci-dessous selon le mode d’installation choisi.

Pour une installation depuis un partage réseau (local)

Si vous souhaitez faire l’installation depuis un dépôt local, il est alors nécessaire de disposer des binaires d’installation sur ce dépôt.

Créer un fichier de téléchargement Download.xml comme ci-dessous:

    <Add OfficeClientEdition="32" Channel="Broad">
        <Product ID="O365ProPlusRetail">
            <Language ID="fr-fr"/>
    <Display Level="Full" AcceptEULA="TRUE"/>

Télécharger les binaires d’installation d’Office à l’aide de la commande ci-dessous

C:\SetupO365ProPlus16>setup.exe /download download.xml

Le téléchargement terminé, vous pouvez voir le répertoire Office qui contient les binaires d’installation de la suite Office.


Il nous reste le fichier .xml de configuration, nécessaire à l’installation. Copier le fichier configuration.xml et modifiez-le pour qu’il ressemble à :

    <Add OfficeClientEdition="32" Channel="Broad" SourcePath="\\<myShare>\SetupO365ProPlus16" DownloadPath="\\<myShare>\SetupO365ProPlus16">
        <Product ID="O365ProPlusRetail">
            <Language ID="fr-fr"/>
    <Display Level="None" AcceptEULA="TRUE"/>
    <Property Name="FORCEAPPSHUTDOWN" Value="FALSE"/>

Dans mon cas je l’enregistre sous le nom local.xml pour qu’il soit plus parlant.

En résumé, il y a trois éléments indispensables pour l’installation depuis un partage réseau (local):


Pour une installation depuis internet (en ligne)

Si vous souhaitez faire l’installation depuis internet, il n’est pas nécessaire de télécharger les binaires de la suite Office. Vous aurez besoin que de deux fichiers :


Ci-dessous le contenu que doit avoir votre fichier de configuration. Une fois encore je le nomme internet.xml pour qu’il soit plus parlant.

    <Add OfficeClientEdition="32" Channel="Broad">
        <Product ID="O365ProPlusRetail">
            <Language ID="fr-fr"/>
    <Display Level="None" AcceptEULA="TRUE"/>
    <Property Name="FORCEAPPSHUTDOWN" Value="FALSE"/>

Nous sommes fin prêts pour débuter l’installation: Déployer Office 365 ProPlus 2016 – Partie 3 : Installation

Déployer Office 365 ProPlus 2016 – Partie 1 : Installation de l’Agent Intune

Je partage avec vous ce retour d’expérience d’un projet de Migration Office 365. Dans ce projet l’une des phases essentielles était le déploiement de la suite Office 365 ProPlus 2016.

Nous nous sommes appuyés sur des agents Intune pour pousser l’installation d’Office depuis internet. Mais c’est quoi Intune ? 🙂

Microsoft Intune est un outil de gestion de périphériques depuis le Cloud Microsoft. Il permet entre autre de faire des installations d’applications sur des appareils et de gérer leurs configurations. L’Agent intune est un programme qui permet aux appareils de se connecter à la plateforme Microsfot Intune.

Dans notre cas, nous utilisons Intune pour faire l’installation de Microsoft Office 365 ProPlus 2016 sur les postes.

Disposer d’Office 365 en production ou en test est un pré requis pour ce déploiement car Intune est étroitement lié à votre abonnement Office 365.

Etape 1 : Téléchargement de l’agent Intune

Se connecter au portail de gestion de Microsoft Intune et télécharger l’agent.


Utiliser la commande ci-dessous pour extraire les .msi sur un partage réseau ou un répertoire de votre PC, ce format nous sera utile pour un déploiement par GPO. Pour un déploiement par GPO, vaut mieux le copier sur un share accessible par les PCs sur lesquels vous devez intaller l’agent.

Microsoft_Intune_Setup.exe/Extract "\\kingo.local\sysvol\kingo.local\scripts\"

Je choisi de faire l’extraction dans le répertoire Scripts du sysvol d’un de mes contrôleurs de domaine afin que ces fichiers soient répliqués et disponibles sur tous mes DCs.


Le fichier MicrosoftIntune.accountcert est le certificat qui lie l’agent intune à votre abonnement Microsoft Office 365. Il doit être présent dans le même répertoire que le fichier .msi d’installation et en aucun cas ne doit être modifié sinon l’installation échoue.

Bien entendu le x64 est destiné au architecture 64 bits et les x86 pour PCs à processeur 32 bits.

Etape 2 : Installer l’agent intune

Installation manuelle

Depuis le répertoire « \\kingo.local\sysvol\kingo.local\scripts\ », double-cliquer sur le fichier « .msi » selon l’architecture du processeur de votre PC.


Cliquer sur Next et poursuivre avec l’assistant pour l’installation, hyper intuitif 🙂 croyez-moi.


Cliquer sur « Finish » pour terminer l’installation. vous pouvez observer l’icône de l’agent Intune dans la barre des tâches.


Installation à l’aide d’une GPO

Créer et rattacher les GPOs à l’unité d’organisation qui comporte les PCs sur lesquels l’on souhaite déployer les agents intune.


Configuration des filtres WMI

J’ai rattaché un filtre wmi à chaque GPO pour cibler les postes selon leur processeur (x86 ou x64).

Le filtre win_32bits (x86)

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’32’

Le filtre win_64bits

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’64’

Ajout du .msi d’intallation de l’agent intune à la GPO

Configurer l’option de déploiement de la GPO avec le package .msi qu’on qui se trouve sur le sysvol de notre contrôleur de domaine.


Lors du rattachement du package, choisir « Assigner ».


L’installation débutera après récupération des paramètres de la GPO puis redémarrage du PC.

Paramètres de GPO optionnels

Les paramètres de GPO suivants peuvent être nécessaires pour garantir l’installation de l’agent :

Computer Configuration > Policies > Administrative Templates > Windows Components> Window Installer > Always install with elevated privileges
Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon
Computer Configuration > Policies > Administrative Templates > System > Group Policy > Software Installation policy processing (check « Allow processing across a slow network connection »)


Il est possible de modifier également l’intervalle mise à jour des GPOs à travers le paramètre:

Computer Configuration>Administrative Templates>System>Group Policy>Group Policy refresh interval 

Attention ce paramètre ne doit pas être configuré avec un temps trop réduit sinon il peut causer une surcharge du réseau.


Installer des Machines Virtuelles à l’aide d’Azure PowerShell

Objectif du lab: Déployer des machines virtuelles à l’aide de PowerShell pour Azure. Nous essayerons de mettre en place l’architecture ci-dessus.

Etape 1 : Créer votre compte azure gratuitement

Je vous invite à utiliser ce tuto pour créer votre compte azure.

Etape 2 : Connectez-vous à votre tenant Azure à l’aide d’Azure PowerShell

Si vous n’avez pas encore installé Azure PowerShell, visiter ce lien sinon lancer PowerShell depuis votre poste de travail (je préfère utiliser PowerShell ISE)



Saisir la commande suivante pour vous connecter


Entrer les informations d’authentifications à votre compte


Une fois la connexion réussie, les informations de votre tenant s’affichent en dessous


Vous voilà maintenant prêt pour la mise en place du lab 🙂 !

Etape 3 : Définition des variables pour le déploiement des serveurs

#################### Définition des variables ################
#Les variables du script
$SubscriptionName = "moncompteazure" #Nom de votre tenant Azure
$StorageAccountName = "strgaccnt0508" #Nom de votre compte de stockage qui contiendra les composants Azure que nous allons déployer
$ResourceGroupName = "rscgrp0508" #Regroupe toutes les ressources/composants de notre lab (VMs, NICs, IPs...)
$Location = "West Europe" #Emplacement géographique de notre tenant Azure
$SkuName = "Standard_LRS"
$vms = @("WAP01azlab0408","WAP02azlab0408","ADFS01azlab0408","ADFS02azlab0408") #Les noms de nos VMs
$VMSize = "Standard_A1" #Taille de la VM
$PublisherName = "MicrosoftWindowsServer"
$Offer = "WindowsServer" #Type de VMs
$Skus = "2016-Datacenter" #Système d'exploitation
$Version = "latest"

$nicIndex = 1
$intNicId = -1

#Network name
$vnetName = "az_demolab_network"

#Subnets Names
$int = "INT"
$lan = "LAN"
$subnets = @("int","lan")

#Subnets Address Prefixes
$vnet_Addr_Prefix = ""
$int_Addr_Prefix = ""
$lan_Addr_Prefix = ""

#Internet IP addresses
$wap_intIpName = @("","")

##WAP Network config
#NIC config
$nic_Lan_WAP01 = "nic_Lan_WAP01"
$nic_Lan_WAP02 = "nic_Lan_WAP02"
$nic_int_WAP01 = "nic_int_WAP01"
$nic_int_WAP02 = "nic_int_WAP02"

$lan_ip_WAP01 = ""
$lan_ip_WAP02 = ""

##FS Network Config
$nic_Lan_FS01 = "nic_Lan_FS01"
$nic_Lan_FS02 = "nic_Lan_FS02"

$lan_ip_FS01 = ""
$lan_ip_FS02 = ""

#Network security groups
$networkSecurityGroupName = "az_demolab$(Get-Random)"
$NetworkSecurityRuleConfig_RDP = "az_demolab_NSRCfg_RDP"
$NetworkSecurityRuleConfig_HTTP = "az_demolab_NSRCfg_HTTP"
[int]$DestinationPortRange_RDP = 3389
[int]$DestinationPortRange_HTTP = 80

Etape 4 : Configuration des composants réseaux

############################# Network Config ###########################
#Creating Resource group
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $Location

#Creating Resource storage
New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageAccountName -Location $Location -SkuName $SkuName

#Create two virtual subnets INT and LAN
$subnet_int_Addr_Pr = New-AzureRmVirtualNetworkSubnetConfig -Name $int -AddressPrefix $int_Addr_Prefix
$subnet_lan_Addr_Pr = New-AzureRmVirtualNetworkSubnetConfig -Name $lan -AddressPrefix $lan_Addr_Prefix

#Create virtual Networks
$vnet = New-AzureRmVirtualNetwork -ResourceGroupName $ResourceGroupName -Name $vnetName -AddressPrefix $vnet_Addr_Prefix -Location $Location -Subnet $subnet_int_Addr_Pr,$subnet_lan_Addr_Pr

#Create virtual public ips for the WAP Servers
$i = 0 
Do { $wap_intIpName[$i] = New-AzureRmPublicIpAddress -ResourceGroupName $ResourceGroupName -Location $Location -AllocationMethod Dynamic -IdleTimeoutInMinutes 4 -Name ("wap0" + ($i+1) + "_intIp")
 $i +=1
While ($i -lt 2)

Etape 5 : Création des groupes de sécurité

###################### Network Security Groups config ####################
# Create an inbound network security group rule for port 3389
$SecurityRulesRDP = New-AzureRmNetworkSecurityRuleConfig -Name $NetworkSecurityRuleConfig_RDP -Protocol Tcp -Direction Inbound -Priority 1000 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange $DestinationPortRange_RDP -Access Allow

# Create an inbound network security group rule for port 80
$SecurityRulesHTTP = New-AzureRmNetworkSecurityRuleConfig -Name $NetworkSecurityRuleConfig_HTTP -Protocol Tcp -Direction Inbound -Priority 1001 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange $DestinationPortRange_HTTP -Access Allow

# Create a network security group
$NetworkSecurityGroup = New-AzureRmNetworkSecurityGroup -ResourceGroupName $ResourceGroupName -Location $Location -Name $networkSecurityGroupName -SecurityRules $SecurityRulesRDP,$SecurityRulesHTTP

Etape 6: Création des Machines Virtuelles

#################### Creating NICs and VMs #########################
#Récupération des informations d'authentification du compte admin local des VMs
$cred = Get-Credential

ForEach ($vm in $vms) {
#Création des interfaces réseaux lan pour les WAP et les FS
 $lanNic = New-AzureRmNetworkInterface -Name ($vm + "_lanNic" + $nicIndex) -ResourceGroupName $ResourceGroupName -Location $Location -SubnetId $vnet.Subnets[1].Id -NetworkSecurityGroupId $NetworkSecurityGroup.Id

#Configuration des VMs WAP
 if ($vm -ilike "WAP*"){
 $intNicId += 1

 #Création des interfaces réseaux internet pour les WAP
 $intNic = New-AzureRmNetworkInterface -Name ($vm + "_intNic" + $nicIndex) -ResourceGroupName $ResourceGroupName -Location $Location -PublicIpAddressId $wap_intIpName[$intNicId].Id -SubnetId $vnet.Subnets[0].Id -NetworkSecurityGroupId $NetworkSecurityGroup.Id 
 $vmConfig = New-AzureRmVMConfig -VMName $vm -VMSize $VMSize | Set-AzureRmVMOperatingSystem -Windows -ComputerName $vm -Credential $cred | Set-AzureRmVMSourceImage -PublisherName $PublisherName -Offer $Offer -Skus $Skus -Version $Version | Add-AzureRmVMNetworkInterface -Id $intNic.Id -Primary $vmconfig = $vmConfig | Add-AzureRmVMNetworkInterface -Id $lanNic.Id

#Configuration des VMs FS
 else {
  $vmConfig = New-AzureRmVMConfig -VMName $vm -VMSize $VMSize | Set-AzureRmVMOperatingSystem -Windows -ComputerName $vm -Credential $cred | Set-AzureRmVMSourceImage -PublisherName $PublisherName -Offer $Offer -Skus $Skus -Version $Version | Add-AzureRmVMNetworkInterface -Id $lanNic.Id
 #Création de la Machine Virtuelle
 New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $Location -VM $vmConfig

…Ps: vous pouvez exécuter toutes ces étapes en une seule fois en collant les bouts de script les uns à la suite des autres 🙂

Etape 7 : Vérification du bon déploiement des serveurs et de leurs composants

#Le groupe de ressources


#Les Machines virtuelles créées


#Les composants réseaux



Nous sommes à la fin de notre déploiement… 🙂

Installer le module PowerShell pour Azure

Hello 🙂 , retrouvez dans ce post comment installer le Module Azure For PowerShell afin de pouvoir gérer vos machines virtuelles Azure à distance à l’aide de cmdlets.

Tout d’abord, il est important de savoir qu’il y a deux types de machines virtuelles dans Azure:

  • Les Machines virtuelles classiques
  • Les Machines virtuelles gérées (Remote Managed VM)

Pour installer les modules de gestions de machines virtuelles, suivre la procédure ci-dessous. Votre ordinateur doit être connecté à l’internet pour que les téléchargements se fassent automatiquement.

Ouvrir une console PowerShell,

Install-Module AzureRM # Pour les Machines virtuelles gérées
Install-Module Azure # Pour les Machines virtuelles classiques

Si vous procédez à l’installation depuis PowerShell ISE, vous observerez la progression comme ci-dessous:


L’installation terminée, utiliser la commande ci-dessous pour vérifier la présence du module Azure.

Get-Module -ListAvailable *Azure*


Et voilà 🙂 … Vous êtes presque prêt pour gérer vos machines virtuelles.

Dans le prochain post, je vous montrerai comment vous connecter à Azure et Créer un environnement de test.

Débuter avec PowerShell pour Office 365

Je vous présente par le biais de cet article un site très intéressant dédié à la gestion d’Office 365 à l’aide de PowerShell.

Déjà… Qu’est-ce qu’Office 365 ?

Avant d’aller plus loin, vous trouverez sur ce lien qui décrit de façon briève les différents Plans d’Office 365 : Il liste l’ensemble des produits qui composent Office 365 avec les coûts des licences.

Pour administrer Office 365, nous avons le choix d’utiliser soit la console graphique ou la ligne de commande.

Interface graphique


Tout en gardant à l’esprit que la ligne de commande est mieux indiquée pour des tâches en bloc comme la migration d’un grand lot de Boîtes Aux Lettres (BALs) vers Office 365.

Ligne de commande avec PowerShell for Office 365

Je vous invite à visiter ce site Il est structuré en cinq grandes rubriques utiles pour acquérir des connaissances sur PowerShell for Office 365. Je vous présente rapidement ces rubriques :



La page d’accueil nous explique l’intérêt d’utiliser PowerShell pour l’administration de votre tenant Office 365.



Get Started 

Cette partie vous explique comment installer les outils dont vous avez besoin pour le PowerShell. Voici un exemple pour l’installation du module Microsoft Online Services Sing-in Assitant pour se connecter à Office 365 et l’installation du module Azure Active Directory (AzureAD).


Installation des Outils indispensables

  1. Microsoft Online Services Sign-In Assistant for IT Professionals RTW (


  1. Installez la version 64 bits du Module Windows Azure Active Directory pour Windows PowerShell en suivant les étapes suivantes (



Cette rubrique nous montre comment nous connecter aux services en ligne d’Office 365.



Exemple de connexion à Azure Active Directory


Affichons par exemple les licences disponibles dans notre tenant Office 365 à l’aide de ligne de commande PowerShell



Script Samples

Vous trouverez dans cette rubrique, des exemples de scripts pour accomplir certaines tâches comme par exemple « Assigner une licence dans Office 365 à l’aide de PowerShell »




Dans cette dernière rubrique, vous pouvez partager votre point de vue sur les différents sujets traités ?



Et voilà 🙂

Générer un fichier .CSR à l’aide d’une MMC et faire une demande de certificat.

Dans cet article, je partage avec vous une méthode toute simple pour générer un fichier de demande de certificat (.CSR) à l’aide d’une MMC.

>>  Ouvrir une MMC sur votre serveur de certificat.



>> Fichier >> Ajouter/Supprimer un composant enfichable…


Certificats >> Ajouter


Cocher >> Un compte d’ordinateur (car on veut demander un certificat pour l’ordinateur)


>>  L’ordinateur local >> Terminer


>> OK


>> Cliquer-droit sur Certificats >> Toutes les tâches >> Opérations avancées >> Créer une demande personnalisée…


>> Suivant


>> Suivant


>> Suivant


>> Suivant


>> Cliquer sur Détails >> Propriétés


>> Dans l’onglet Général, entrer le nom convivial de votre certificat

Dans la fenêtre suivante, faire:

>> Objet >> Dans Nom du sujet > > Type : Nom commun >> Valeur : tosca.sibille.lan puis cliquer sur Ajouter


Répéter cette action pour Nom du sujet

Type Valeur
Nom commun mon.domaine.lan
Pays FR
Organisation Mon organisation
Unité d’organisation DSI
Etat IDF

Répéter cette action pour l’onglet Autre nom (seulement, si vous souhaitez que le certificat comporte des noms alternatifs pour vos serveurs)

Type Valeur
  • appli1.domaine.lan
  • serveur2.domaine.lan
  • fqdn03.domaine.lan
  • appli04.domaine.lan
  • appli05.domaine.lan


>> Appliquer >> OK



>> Suivant et en registrer le fichier CSR


Aller dans l’emplacement où est enregistrer le fichier CSR et l’ouvrir, puis copier son contenu.


Se connecter à l’URL de demande de certificats de votre autorité de délivrance de certificat. exemple: https://monserveur/certsrv


>> Coller le contenu du fichier copié précédemment dans « Demande enregistrée » puis sélectionner votre modèle de certificat dans « Modèle de certificat ».

>> Envoyer


>> Télécharger le certificat

Vous devrez observer ici le nom du sujet renseigné précédemment dans CN, on peut voir également les informations de validité du certificat. Je rappelle que cette information dépend du modèle de certificat que vous aurez auparavant choisi.


>> Détails


Et voilà, nous avons généré un fichier de demande de certificat, puis effectué la demande de certificat auprès de notre autorité de certificat. Je rappelle que le fichier CSR peut aussi servir à faire une demande auprès d’une autorité publique.

Dans ce billet, nous avons supposé qu’une autorité de certification était déjà en place dans votre organisation. Vous pouvez toutefois consulter l’une de mes publications précédentes qui montre comment mettre en place une autorité de certification si vous en avez pas : Déployer une PKI 3-tiers en entreprise.

A bientôt dans un prochain article 🙂 !


Déployer une PKI 3-tiers en entreprise


Dans cette rubrique, nous vous proposons de mettre en place une PKI 3-tiers, c’est-à-dire constituée par une chaîne de trois serveurs. Pour cela il nous faut :

  • Un serveur Root CA qui la plupart du temps restera hors tension pour des besoins de sécurité. Cela permet de protéger la clé privée de cette autorité qui est garant de l’intégrité de toute la PKI.
  • Un serveur Intermediate CA qui est subordonné au Root CA, il sera chargé de distribuer des certificats aux serveurs Issuing CA.
  • Un serveur Issuing CA, subordonné à l’Intermediate CA, il s’occupe de délivrer des certificats aux points terminaux et aux utilisateurs.

Pré requis matériels et logiciels

Pour la mise en oeuvre, nous allons utiliser 3 machines virtuelles Windows Server 2012 R2.

CA-ROOT-01 Autorité racine 4 GB RAM, DD 40GB, Windows Server 2012 R2
CA-INT-01 Autorité intermédiare 4 GB RAM, DD 40GB, Windows Server 2012 R2
CA-ISS-01 Autorité de délivrance de certificats aux points terminaux 4 GB RAM, DD 40GB, Windows Server 2012 R2

Installation de l’autorité racine CA-ROOT-01

Sur notre autorité racine, nous allons installer le rôle « Services de certificats Active Directory »


Dans la fenêtre suivante, accepter l’ajout des rôles et fonctionnalités requises pour le bon fonctionnement de la PKI


Veillez à ce que les trois services de rôle ci-dessous soient bien cochés


Dans la prochaine fenêtre, cliquer sur « Suivant »


Confirmer les modifications et cliquer sur « Suivant » pour installer le rôle.

Une fois l’installation terminée, nous pouvons maintenant configurer les services de certificats Active Directory en cliquant sur le lien dans la fenêtre ci-desssus.




Dans la fenêtre suivante, cocher la case « Autorité de certification autonome » car nous voulons que notre Root CA ne soit pas membre du domaine et soit hors ligne la majeur partie du temps à l’abri des cybercriminels. Cette configuration permet de le maintenir hors de danger.


Cocher la case « Autorité de certification racine » car nous installons ici notre premier serveur de notre PKI.



Choisir l’algorithme de hachage SHA256


Dans la fenêtre suivante, vous pouvez modifier les informations ou conserver celles qui y figurent par défaut.


Nous spécifions ici une période de validité de 10 ans pour le certificat généré par notre autorité racine.




Vérifier que la période de validité a bien été enregistrée dans le registre. La valeur est inscrite en Hexadécimal, donc vous devrez y voir « 16 »



La configuration de notre Root CA est terminée, passons maintenant à l’autorité intermédiaire. La procédure est la même sauf qu’ici nous allons requêter un certificat auprès de notre Root CA pour configurer notre autorité intermédiaire.

Installation de l’autorité intermadiaire CA-INT-01

Sur notre serveur CA-INT-01, nous allons installer dans un premier temps le rôle « Services de certificats Active Directory »



Une fois l’installation terminée, cliquer sur « Configurer les services de certificats Active Directory sur le serveur de destination ».


Dans la fenêtre suivante, choisir « Autorité de certification autonome »


Il s’agit de l’autorité intermédiaire de notre PKI, donc nous choisissons « Autorité de certification secondaire » dans la fenêtre suivante.



Il est conseillé d’utiliser le SHA256 comme algorithme de hachage




Dans la fenêtre suivante, veuillez à bien noter l’emplacement de votre fichier de requête de certificat, dans notre cas, nous il sera à la racine du disque système « C:\CA-INT-01.NomDuDomain.req« 


Copier le contenu du fichier « C:\CA-INT-01.NomDuDomain.req« , se connecter à http://CA-ROOT-01/certsrv pour requêter un certificat auprès du root pour notre autorité intermédiaire.





Cliquer sur Envoyer


Noter l’identificateur de la requête, puis se connecter à la console de gestion de l’Autorité de certificat CA-ROOT-01 et délivrer le certificat généré précédemment. Aller dans l’onglet Demandes en attente, identifier le certificat selon l’ID n°3 puis Délivrer le certificat comme ci-dessous:


Retourner ensuite dans sur http://CA-ROOT-01/certsrv


Cliquer sur « Afficher le statut d’une requête de certificat en attente » et télécharger le certificat selon le format qui vous convient.


Se connecter ensuite à la console de gestion de l’autorité CA-INT-01 et démarrer le service de certificat.



Cliquer sur Oui puis sur OK dans la fenêtre suivante pour terminer votre installation.


Pour vérifier la durée de validité du certificat de l’autorité intermédiaire, vous pouvez regarder la clé de Registre ci-dessous. Ici, nous avons choisi 5 ans, vous pouvez toujours l’augmenter cette valeur si vous le souhaitez mais attention, elle ne peut excéder celle de l’autorité racine CA-ROOT-01.


Installation de l’autorité émettrice de certificats aux terminaux

Se connecter au serveur CA-ISS-01 puis ajouter le rôle Autorité de certification ainsi que les paramètres ci-dessous:



Une fois l’installation du rôle terminée, nous passons à la configuration.


Nous choisissons dans la fenêtre suivante « Autorité de certification d’entreprise » comme type d’installation étant donné que notre serveur ici sera membre du domaine.


Notre serveur CA-ISS-01 est subordonné au serveur intermédiaire CA-INT-01, pour cela, nous choisissons « Autorité de certification secondaire ».


Veuillez à sélectionner le SHA256 ou plus pour l’algorithme de hachage


Cliquer deux fois sur « Suivant ». Dans la fenêtre suivante, noter l’emplacement du fichier de requête C:\CA-INT-01.NomDuDomaine.req et copier son contenu.


Cliquer sur « Fermer » pour terminer l’installation. Se connecter ensuite à http://CA-INT-01/certsrv.


Utiliser le contenu du fichier de requête généré un peu plus haut pour demander le certificat du serveur CA-ISS-01.


Cliquer sur « Envoyer » et suivre la même procédure que celle de l’autorité intermédiaire








Notre infrastructure de certificat est maintenant en place, nous allons nous intéresser à la configuration de l’inscription automatique pour les postes de travail, serveur ou comptes utilisateurs.

L’inscription automatique est une option sur les modèles de certificats, qui couplée aux GPOs, permet aux comptes d’ordinateurs/utilisateurs de récupérer et de renouveler automatiquement leurs certificats auprès d’une autorité de certification sous les plateformes Windows.


Configurer vos applications pour les connexions sécurisées LDAPs

Dans une entreprise, certaines applications peuvent avoir besoin de se connecter au serveur LDAP pour récupérer des information ou des droits d’accès pour les utilisateurs. Pour se faire, ces applications s’appuient sur un fichier de configuration, qui dans une configuration classique, peut ressembler à ceci :

#config  ldap
ldap.url=ldap://mondomaine.lan:389    # connexion non sécurisée
ldap.managerdn=CN=svc_ldapRdr,OU=Comptes services,DC=mondomaine,DC=lan #Compte de service d’accès au serveur LDAP
ldap.managerpassword= »MDP du compte svc_ldapRdr »

On peut remarquer que la connexion ici n’est pas sécurisée car utilise un simple bind (port 389), pas sécurité. cela veut dire qu’on peut récupérer les mots de passe si on place un sniffer (wireshark par exemple) entre l’application et le serveur LDAP.

Pour une connexion sécurisée, on aurait plutôt utilisé la configuration suivante:

#config  ldap
ldap.url=ldaps://mondomaine.lan:636      # connexion sécurisée à LDAP
ldap.managerdn=CN=svc_ldapRdr,OU=Comptes services,DC=mondomaine,DC=lan #Compte de service d’accès au serveur LDAP
ldap.managerpassword= »MDP du compte svc_ldapRdr »

Afin de réaliser une connexion sécurisée en SSL sur un serveur LDAP à a partir d’un serveur tomcat installé sous Windows. Il est nécessaire d’enregistrer les certificats SSL au niveau de la JVM du tomcat (keystore). Pour cela on va utiliser les outils suivants :

Keytool qui est un outil de gestion des certificats proposé dans les binaires de la JDK
Un programme JAVA : permettant de récupérer les certificats SSL sur un serveur donné et de les importer dans la JVM.

Notre serveur LDAP de domaine (Active Directory) et un point d’entrée qui redirige vers un de ces contrôleurs :

Point d’entrée :


Notre serveur LDAP :


L’applicatif se connectant sur le LDAP doit se connecter sur l’adresse suivante


Pour enregistrer les certificats SSL des serveurs LDAP dans le keystore de la JVM, il faut :
– Compiler le programme InstallCert en lançant la commande : javac InstallCert
– Lancer le programme InstallCert sur les 4 serveurs afin de récupérer les certificats :

java InstallCert DC01.mondomaine.lan:636

Après le lancement de ces programmes un fichier jssecacerts à été généré dans le répertoire courant
– Il faut maintenant exporter les certificats contenus dans le fichier jssecacerts pour chaque serveur en lançant les commandes suivantes :

« C:\Program Files\Java\jre7\bin\keytool.exe »  -exportcert -alias dc01.mondomaine.lan -keystore jssecacerts -storepass changeit -file DC01.mondomaine.lan.cer

– Une fois les exportations terminées, il faut importer les certificats générés dans le keystore de la JVM en lançant les commandes suivantes :

« C:\Program Files\Java\jre7\bin\keytool.exe » -keystore « C:\Program Files\Java\jre7\lib\security\cacerts » -importcert -alias DC01.mondomaine.lan -file dc01.mondomaine.lan.cer

Et voilà, j’espère que cet article vous aura été utile 🙂

Mettre en oeuvre la fédération d’identité avec AD FS

Le nom de notre serveur est SRVADFS01

1 – Ajout du rôle Active Directroy Federation Services

Ouvrir la session sur notre seveur Windows Server 2012 R2. Se connecter au Gestionnaire de serveur et ajouter un rôle


Add Roles and Features





Cocher la case « Active Directory Federation Services » puis cliquer sur Suivant




L’installation est terminée, fermer l’assistant d’installation.

2 – Demander un certificat pour notre serveur AD FS

Créer un fichier .CSR




3 -Terminer la configuration du serveur AD FS

Toujours sur notre serveur SRVADFS01







Et voilà, votre serveur ADFS est installé…

Gérer les mises à jour (MAJ) de sécurité avec WSUS dans un domaine AD

… parce qu’un peu de théorie avant la pratique n’a jamais fait de mal 🙂

Architecture :

  • Un serveur WSUS membre du domaine AD
  • Un accès internet pour le serveur WSUS
  • Configurer des GPOs pour cibler les ordinateurs qu’on souhaite patcher
  • Gérer les MAJ pour les ordinateurs non-membres du domaine
  • Mettre en place un planning de gestion des mises à jour (MAJ)

Petit rappel :

Windows Server Update Services (WSUS) permet aux administrateurs systèmes de déployer les dernières mises à jour de produits Microsoft sur les ordinateurs qui exécutent le système d’exploitation Windows. En utilisant WSUS, les administrateurs peuvent gérer entièrement la distribution des mises à jour publiées via Microsoft Update sur les ordinateurs de leur réseau. Pour plus d’information sur le produit, consulter le site dédié à WSUS.

Microsoft publie tous les deuxièmes mardis de chaque mois un bulletin de sécurité (Tuesday patch) pour ses applications et systèmes d’exploitation, consultable sur ici.

Gestion des MAJs en entreprise (retour d’expérience) :

Je vous propose dans cette rubrique, ce retour d’expérience sur la façon de gérer le patch management mensuel en environnement de production.

Semaines Plan de mise à jour
Semaine 1:

Ne pas déployer de mise à jour.

Les admins ont aussi droit à des journées tranquilles non? 🙂

En réalité, cette période doit servir à préparer le patch du mois en cours, s’assurer :

  • de l’état de santé du serveur WSUS
  • de ce que les ordinateurs à patcher communiquent bien avec le serveur WSUS
  • développer des scripts de reporting, reboot etc…
Semaine 2 :

Postes/Serveurs pilotes

  1. Sortie des mises à jour par Microsoft
  2. Appliquer les mises à jour de sécurité et les mises à jour critiques sur les postes/serveurs pilotes
  3. Redémarrer les postes/serveurs pilotes
  4. Surveiller les postes mis à jour
  5. Corriger les éventuels bugs/anomalies
Semaine 3 :

Postes/Serveurs de Production 1

  1. Appliquer sur un groupe de postes/serveurs en production
  2. Redémarrer les postes/serveurs de production
Semaine 4 :

Postes/Serveurs de Production 2

  1. Appliquer les mises à jour des serveurs critiques
  2. Redémarrer les serveurs critiques

NB: Pour les serveurs redondants c’est-à-dire en Load balancing ou en Cluster de basculement, éviter de patcher les deux dans la même vague de mises à jour.

Exemple: Mise à jour de serveurs Exchange membres d’un DAG à trois (03) noeuds. supposons qu’il y a des bases actives uniquement sur 2 noeuds (SRVEX01 et SRVEX02), le troisième (SRVEX03) étant dédié aux copies passives.

Dans le cadre d’un patch management, on pourra suivre l’ordre suivant:

  1. Mise à jour de SRVEX03 (semaine 2, dans le lot des serveurs pilotes)
  2. Ensuite, passer à la maj du serveur SRVEX01 (Semaine 3, dans la première vague de cette semaine)
  3. Terminer avec SRVEX02, toujours dans la semaine 3, vague 2 par exemple.

NB: les semaines étant composées de 5 jours ouvrés, je vous conseille les vagues horaires suivantes:

  1. Vague 1 : Nuit de Lundi à Mardi
  2. Vague 2 : Nuit de Mardi à Mercredi
  3. Vague 3 : Nuit de Mercredi à Jeudi

Attention !

Les journées de Jeudi et de vendredi peuvent être utiles à la résolution d’éventuels incidents liés au patch management. C’est pourquoi je vous conseille de ne surtout pas faire de maj durant cette période et aussi la veille des jours fériés au risque de les consacrer à la résolution d’incidents 🙂 …

…Dans une prochaine rubrique, je vous expliquerai comment installer WSUS pour la gestion des mises à jour.