PI Services

Le blog des collaborateurs de PI Services

Création de tableaux dynamique en Powershell

Nous disposons d’une variable de type tableau avec comme informations des utilisateurs et leurs villes.

Nous allons ici créer dynamiquement une variable pour chaque site présent dans la variable $users et y affecter les utilisateurs.

 

image

Nous allons créer une variable de type tableau dans lesquels nous allons récupérer tous les sites disponibles dans notre variable $users.

$sites=@()

Nous alimentons maintenant la variable $sites.

 

foreach ($user in $users)

{

$sites+=$user.extensionAttribute8

}

$sites=$sites |sort | Get-Unique

 

Résultats :

image

 

Maintenant nous allons créer pour chacun des sites récupérés une variable avec pour nom la valeur récupéré dans la variable $sites

$sites | %{New-Variable -Name $_ -value @() -ErrorAction SilentlyContinue; if ($? -eq $true){write-host "variable créé : $_"}}

Résultats :

image

 

 

Maintenant nous allons alimenter dans les variables créés précédemment dynamiquement les utilisateurs présents dans les sites

foreach ($user in $users)

{

$VariableValue = $Null

$user.extensionAttribute8 |%{$VariableValue = @(((Get-Variable $_).Value)+$user);Set-Variable -name $_ -value $VariableValue}

}

Résultats :

image

image

image

image

image

image

image

 

 

 

Audit de droits administrateurs manquant sur une liste de fichiers

Nous allons pour l’exemple créer un fichier n’ayant pas le droit administrateurs.

 

image

 

Les autres fichiers ont bien le droit administrateurs dans leurs ACL.

Maintenant à l’aide d’un script, nous allons détecter le/les fichiers n’ayant pas l’identité “administrateurs”

Positionnons nous dans le répertoire nous intéressant et récupérons les différents éléments


cd "C:\Users\ato\Dropbox\Divers"
dirs=get-item *

 

maintenant on créer un tableau ou seront ajoutés les différents éléments n’ayant pas le droits administrateurs

Ensuite à l’aide du code ci dessous, nous allons être capable de récupérer dans le tableau $acl les éléments de notre recherche:

foreach ($d in $dirs)
{
    $ID=(get-acl $d).access | %{$_.identityreference}
    if ($ID -match "administrateurs"){}  #c’est ici que l’on définit l’acl manquant que l’on recherche
    else
    {
        $d.fullname
        $acl=$d.fullname
    }
}

 

Apres exécution du script, on peut voir que la variable $acl a bien été définis avec le fichier n’ayant pas le droit administrateur

image

Suppression d’items antérieurs à X jours en Powershell

Imaginons que vous devez supprimer à un emplacement donné des répertoires et/ou fichiers n’ayant pas été modifiés depuis 30 jours.

Ce petit script va permettre d’identifier les éléments correspondant à notre critère de recherche.

Positionnons nous dans le répertoire nous intéressant

cd "C:\Users\ato\Google Drive"

 

On obtient tous les items à notre emplacement

$items= get-item *

Un petit compteur pour identifier le nbre d’éléments qui nous sera retourné

$i=0

Nous allons maintenant récupérer le chemin absolu des items n’ayant pas été modifié depuis au moins 30 jours.

foreach ($item in $items)

{

$days=($item |New-TimeSpan).days

if ($days -ge 30) # c’est ici que nous définissons le nbre de jours

{

$i++

$item.fullname

}

}

echo "Nbres item $i"

Il y a donc 83 items n’ayant pas été modifié depuis au moins 30 jours.

 

image

 

Sur un total de 114 items

 

image

 

Il ne vous reste plus qu’à ajouter un remove-item dans la boucle de traitement si vous souhaitez supprimer les items renvoyés.

Réplication DFS-R & contraintes d’utilisation

Contexte

Lors de l’utilisation d’un partage réseau, les utilisateurs on souvent l’habitude de travailler directement sur les fichiers partagés.

Afin d’éviter toute corruption des données, un système de verrouillage est utilisé, il garantie que seul un unique utilisateur n’édite le fichier. Ce système fonctionne avec les fichiers temporaire/propriétaire.

Voici les étapes d’ouverture et d’enregistrement pour un fichier Word :

1. A l’ouverture du fichier, Word crée un fichier temporaire où les modifications seront enregistrés. Si un autre utilisateur tente de modifier le fichier, le message d’erreur suivant lui apparait :

Ce fichier est déjà ouvert par <nom_utilisateur>. Souhaitez-vous en faire une copie ?

2.  Lors de l’enregistrement du fichier, Word supprime la version d’origine, et la remplace par le fichier temporaire qu’il a renommé comme le fichier d’origine.

Ainsi, plusieurs utilisateurs auront accès au même fichier sans que celui-ci ne soit corrompu.

Contraintes en mode répliqué

Dans le cas d’un partage de fichiers répliqué, l’intégrité des fichiers n’est plus assurée.

Prenons le scénario suivant :

image

Dans ce cas de figure les utilisateurs sont redirigés depuis le namespace vers l’un des deux serveurs de données. En fonction de l’ordre “Refferal Ordering” qui par défaut dirige les clients entre les deux serveurs de manière égale.

Or si un utilisateur modifie le fichier work.docx sur le serveur FILE01, le serveur FILE02 n’en seras pas avisé (la fonction de verrouillage de fichier étant locale) et un autre utilisateur seras en mesure de modifier le même fichier causant une perte d’intégrité où le dernier fichier enregistré sera celui gardé par les deux serveurs.

Afin d’éviter ce type de comportement dangereux, il est possible de modifier le fonctionnement des deux serveurs, tout en gardant un minimum de répartition de charge.

Contournement

Imaginons que les serveurs FILE01 et FILE02 hébergent chacun deux fichiers répliqués indépendamment, Commerce et Administratif.

La première chose à faire est de forcer les clients à n’accéder qu’à un seul des deux serveurs, le serveur secondaire seras utilisé dans le cas où le premier venait à ne plus fonctionner.

Pour ce faire il faut dans la partie “Folder Targets” du namespace Commerce choisir le dossier hébergé par le serveur secondaire (FILE02), ouvrir la fenêtre des propriété puis choisir l’onglet “Advanced” et affecter à ce dossier la priorité “Last among all targets” :

image

Ainsi les utilisateurs souhaitant accéder au partage Commerce, seront toujours dirigé vers FILE01 en priorité.

On peut également aller plus loin et interdire la modification des fichiers sur l’un des serveurs le rendant membre “Read-Only”. La réplication ne fonctionneras alors que dans un sens et le serveur Read-Only, comme son nom l’indique ne pourras qu’afficher les fichiers hébergé en lecture seule.

Pour appliquer le Read-Only sur le serveur secondaire, choisir dans la partie “Replication” le lien de réplication, et dans l’onglet “Membership” sélectionner le serveur membre secondaire comme ceci :

image

Conclusion

A l’aide de ce contournement les utilisateurs Administratif utiliserons un serveurs tandis que les utilisateurs Commerciaux en utiliseront un autre.

Les deux serveurs sont malgré tout répliqués donc en cas de défaillance de l’un, l’autre pourras prendre le relais, cependant, il ne faut pas oublier – en cas de défaillance du serveur principal – de retirer l’option “Read-Only” si celle-ci a été mise en place.

Lync Server 2013 – Mise en place de statuts personnalisés

Contexte

Lync Server 2013 propose différents statuts par défaut pour son client (disponible, occupé(e), de retour dans quelques minutes…). Afin d’améliorer l’expérience utilisateur, il est possible d’ajouter des statuts personnalisés.

Ces statuts se basent sur un fichier XML. Il est possible d’ajouter au maximum quatre statuts personnalisés, d’une longueur maximale de 64 caractères.

Création et syntaxe du fichier XML

Le fichier XML doit se trouver à l’emplacement : https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Ce chemin correspond à deux dossiers (site interne et externe) qui sont par défaut :

C:\Program Files\Microsoft Lync Server 2013\Web Components\Internal Website\ClientConfigFolder

C:\Program Files\Microsoft Lync Server 2013\Web Components\External Website\ClientConfigFolder

Le fichier se présente ainsi :

   1: <?xml version="1.0"?>
   2: <customStates xmlns="http://schemas.microsoft.com/09/2009/communicator/customStates">
   3: <customState ID="1" availability="online">
   4: <activity LCID="1036">En client&#232;le</activity>
   5: </customState>
   6: <customState ID="2" availability="busy">
   7: <activity LCID="1036">En conversation t&#233;l&#233;phonique</activity>
   8: </customState>
   9: <customState ID="3" availability="do-not-disturb">
  10: <activity LCID="1036">En r&#233;union</activity>
  11: </customState>
  12: </customStates>

Les trois indicateurs de présence possible sont online (Disponible), busy (Occupé(e)) et do-not-disturb (Ne pas déranger).

Le code LCID correspond à la localisation du pays et donc à sa langue. Le code 1336 correspond à la France. Tous les codes sont disponibles sur le site de Microsoft http://msdn.microsoft.com/fr-fr/goglobal/bb964664.aspx.

Les caractères spéciaux doivent être spécifiés selon la norme ISO-8859-1.La liste des différents caractères est disponible via le lien http://www.w3schools.com/tags/ref_entities.asp.

Ajout des statuts à une règle utilisateur

Pour que le client Lync prenne en compte les statuts personnalisés, il faut ajouter le paramètre CustomStateURL à une règle utilisateur. Pour cela utiliser la commande suivante :

Set-CsClientPolicy –Identity <Nom de la règle> –CustomStateURL https://nomdupool.domaine.fr/ClientConfigFolder/CustomPresence.xml

Remarque : Il est possible de faire deux fichiers XML afin d’avoir des statuts personnalisés différents en fonction de la connexion (réseau interne ou réseau externe).

imageimage8

Config Mgr 2012 R2 - Erreur de connexion au portail d’application

Contexte

Dans le produit System Center Configuration Manager 2012 R2 il est possible de mettre à disposition un catalogue d’applications pour les utilisateurs finaux. L'implémentation de ce portail « Self-Service » repose sur un service web et nécessite la mise en place des rôles Config Mgr suivants :

  • Application Catalog web service point
  • Application Catalog website point

L’ajout des deux rôles ne pose aucun problème, cependant il est possible que vous rencontriez le problème ci-dessous lors de l’accès à votre catalogue d’application.

2013-12-06_155211_3

Explication

Bien que l’assistant d’installation des rôles ne vous ait pas remonté de problème, il est possible que les choses ne se soient pas passées comme prévu. Si vous rencontrer le message d’erreur « Cannot connect to the application server », c’est qu’il manque très certainement un composant pour rentre votre portail d’application disponible.

Résolution

Pour identifier la source du problème je vous invite à vous rendre dans le répertoire contenant les logs de Config Mgr 2012 R2. Par défaut les logs se trouvent dans le chemin suivant :
[Program Files]\Microsoft Configuration Manager\Logs

Le fichier qui nous intéresse est nommé SMSAWEBSVCSetup.log. Celui-ci est dédié à l’installation du Web-Service du catalogue d’application.

2013-12-06_155255_2

Lors de l’installation du rôle, une analyse de l’ensemble des éléments prérequis pour la mise en service du Web Services est réalisée. En parcourant le fichier, je découvre que composant Windows Communication Foundation (WCF) n’est pas activé : « WCF is not activated ».

Pour remédier à ce problème, je vous invite à prendre connaissance aux prérequis spécifiques à l’implémentation du rôle « Application Catalog web service point ». http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_Win2k12SiteSystemPrereqs.

Rendez-vous dans votre console Server Manager pour installer la ou les fonctionnalités manquantes pour l’installation du rôle. Il est probable que l’option HTTP Activation ne soit pas activée et qu’elle soit à l’origine de l’erreur. Vous trouverez ci-dessous une capture du lien Technet proposé plus haut et qui détaille les éléments nécessaires pour le bon fonctionnement du portail d’application.

2013-12-10_164313

2013-12-10_165700

Après avoir ajouté les composants manquants, réinstaller le rôle « Application Catalog web service point ».

L’accès à votre portail d’application devrait être à présent fonctionnel.

2013-12-06_163851_3

Desired State Configuration (Partie 2) : LocalConfigurationManager et Mode Push

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Il s’agit de la seconde partie qui traite de la configuration du mode Push. Pour rappel, il existe deux modes d’application d’une configuration avec la technologie DSC :

  • Push
  • Pull

Ainsi, nous verrons comment le mode Push fonctionne. Nous nous attarderons ensuite sur la configuration du mode push via une ressource. Enfin, j’expliquerai comment appliquer une configuration en mode Push à distance.

Fonctionnement

Le mode Push est le mode par défaut dans Desired State Configuration. Chaque configuration est poussé par l’utilisateur via ligne de commande ou script directement depuis le serveur concerné ou à distance depuis un autre serveur. L’intérêt de la deuxième option est de centraliser les fichiers “.mof” sur un seul serveur. Pour appliquer la configuration il faut utiliser la commande Start-DscConfiguration (comme vu dans la partie 1).

Ressource LocalConfigurationManager

L’une des nombreuses ressources disponibles lors d’une configuration est nommée : LocalConfigurationManager. Cette dernière permet de définir quand et comment seront appliquées les configurations. Elle est décrite dans le lien ci-dessous :

http://technet.microsoft.com/en-us/library/dn249922.aspx

NB : Au 16/12/2013, le lien comporte des erreurs. Nous allons donc voir ici les différents attributs qui peuvent nous intéresser pour le mode Push.

La ressource LocalConfigurationManager s’utilise comme toutes les autres ressources de DSC. Il va donc être nécessaire de générer un “.mof” contenant cette ressource, puis l’appliquer. Pour récupérer la configuration actuelle  du LocalConfigurationManager  du serveur, il faut utiliser la commande :

001
Get-DscLocalConfigurationManager

 

Le résultat par défaut est le suivant :image Les attributs intéressants pour le mode Push sont :

  • RefreshMode : La valeur doit être à PUSH.
  • ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect sont les valeurs possibles. Apply définit qu’il faut simplement appliquer la configuration. ApplyAndMonitor ajoute une phase de contrôle et loguera les éventuelles dérives de configuration (dans l’observateur d’événements). ApplyAndAutoCorrect réapplique la configuration après chaque nouveau test, s’il y a une dérive.
  • RefreshFrequencyMins : Il s’agit de l’intervalle de temps pour l’actualisation du fichier de configuration. La valeur minimal est 15 minutes.
  • ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
  • RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.

    Voici un exemple de script configurant la ressource LocalConfigurationManager :

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    Configuration SetPushMode
    {
        Node WEBSRV01 {
           
            LocalConfigurationManager {
                ConfigurationMode = "ApplyandMonitor" 
                RefreshMode = "Push"
                RefreshFrequencyMins = 30
            }
        }
    }

    On invoque ensuite le bloc Configuration (ligne 1) et on l’applique (ligne 2) afin que la configuration soit prise en compte.

    001
    002
    SetPushMode -OutputPath C:\DSCConfig
    Set-DscLocalConfigurationManager -Path C:\dscconfig\ -ComputerName WEBSRV01 -Credential "WEBSRV01\Administrator" -Verbose

    Ici, les paramètres Credendial et ComputerName sont renseignés permettant d’appliquer la configuration de la ressource à distance.

    Pour que la connexion à distance fonctionne, il est nécessaire de pouvoir se connecter en WMI à distance à “root/Microsoft/Windows/DesiredStateConfiguration”. Pour configurer ce pré-requis, il faut se référer à l’article suivant : http://blog.piservices.fr/post/Powershell-Gestion-a-distance.aspx.

Application d’une configuration à distance

Nous avons vu l’application d’une configuration en mode Push lors de la partie 1. Nous verrons donc ici simplement un complément permettant d’appliquer une configuration à distance. On peut ainsi imaginer un script s’exécutant sur un serveur central possédant tout les fichiers “.mof”. Ce script bouclera sur l’ensemble des serveurs d’une liste et lance les commandes de configuration. Dans cet exemple, on considère qu’un fichier “.mof” a été généré dans “C:\DSCConfig”.

001
Start-DscConfiguration -ComputerName WEBSRV01 -Path C:\dscconfig -Verbose -Wait

Les paramètres utilisés ainsi que les pré requis sont les mêmes que précédemment, seul la cmdlet utilisée change.

SCOM et alertes WMI: Script de redémarrage du service wmi et de ses dépendances

 

Le script suivant récupère les alertes ouvertes pour une machine, qui correspondent a des erreurs de requetage wmi. Si il en trouve au moins une dont le repeatcount est supérieur a une valeur donnée en variable, il redémarre le service wmi et ses dépendances et clos les alertes correspondantes.

   1:  
   2: $scomms="scom2k12sp1srv1"
   3: $targetcomputer="scom2k12sp1dc1"
   4: $repeatcountthreshold="1"
   5: $wmi="WinMgmt"
   6:  
   7: $scomcred=Get-Credential -Credential "scom2k12sp1maq1\administrator"
   8: $arrwmialerts=@(“Operations Manager failed to run a WMI query","Workflow Initialization: Failed to start a workflow that queries WMI for performance data","Workflow Initialization: Failed to start a workflow that queries WMI for WMI events","Operations Manager failed to run a WMI query for WMI events",
   9: "Operations Manager failed to run a performance data WMI query","Workflow Initialization: Failed to start a workflow that queries WMI","Script Based Test Failed to Complete")
  10:  
  11: Import-Module operationsmanager
  12:  
  13: New-SCOMManagementGroupConnection -ComputerName $scomms -Credential $scomcred
  14:  
  15: $arrcomputernewalertnames=Get-SCOMAlert | Where-Object {$_.Resolutionstate -eq "0" -and $_.NetbiosComputerName -eq $targetcomputer -and $_.RepeatCount -gt $repeatcountthreshold -and $_.IsMonitorAlert -eq $false } | Select-Object -Property name -ExpandProperty name
  16: $arrcomputernewalerts=Get-SCOMAlert | Where-Object {$_.Resolutionstate -eq "0" -and $_.NetbiosComputerName -eq $targetcomputer -and $_.RepeatCount -gt $repeatcountthreshold -and $_.IsMonitorAlert -eq $false }
  17:  
  18:  
  19:  
  20: $matchingalerts=0
  21: foreach ($wmialert in $arrwmialerts)
  22: {
  23:   if ($arrcomputernewalertnames -contains $wmialert)
  24:     {
  25:     Write-Host -ForegroundColor Red -BackgroundColor White "L'alerte "$wmialert.ToUpper()" a été répétée plus de $repeatcountthreshold fois sur $targetcomputer"
  26:     Write-Host -ForegroundColor Yellow "Fermeture de l'alerte "$wmialert.ToUpper()" avant redemarrage du service $wmi et de ses dependances"
  27:     $matchingalerts= ($matchingalerts + 1)
  28:     $arrcomputernewalerts | Where-Object {$_.Name -like "$wmialert*"} | foreach {Set-SCOMAlert -ResolutionState 255 -Alert $_ }
  29:     }
  30: }
  31:  
  32:  
  33: ###FUNCTIONS###
  34: Function Restart-Wmi ($targetcomputer)
  35: {
  36: Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
  37: $winmgmt=Get-Service -Name Winmgmt
  38: $winmgmtrundep=$winmgmt.DependentServices | Where-Object {$_.Status -eq "Running"}
  39: Stop-Service -Name Winmgmt -Force -ErrorAction SilentlyContinue
  40: Start-Sleep -Seconds 5
  41: Start-Service -Name Winmgmt -ErrorAction silentlycontinue
  42: Start-Sleep -Seconds 5
  43:  
  44: foreach ($dep in $winmgmtrundep) 
  45:     {
  46:     if (Get-WmiObject win32_service | Where-Object {$_.Name -eq $dep.Name -AND $_.state -ne "running" -AND $_.startmode -eq "Auto"}) 
  47:         {
  48:         write-host -ForegroundColor Green "demarrage de la dependance "$dep.Name.ToUpper()""
  49:         Start-Service -Name $dep.Name -erroraction SilentlyContinue -ErrorVariable ("start_"+$dep.Name+"_error").ToString()
  50:         }
  51:     }
  52:  
  53: }
  54: }
  55:  
  56:  
  57: Function NewEventSource
  58: {
  59:     if(!(Test-Path 'HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\RestartWMIScript'))
  60:     {
  61:     New-EventLog -LogName "Operations Manager" -Source RestartWMIScript
  62:     }
  63: }
  64: ###FUNCTIONS###
  65:  
  66:  
  67:  
  68:  
  69:  
  70:  
  71: if ($matchingalerts -gt 0)
  72: {
  73: write-host -ForegroundColor Yellow "Redemarrage du service WinMgmt et de ses dependances"
  74: Restart-Wmi $targetcomputer
  75: }
  76: else
  77: {
  78: write-host -ForegroundColor Green "Pas d'alertes correspondantes trouvées"
  79: Write-Host -ForegroundColor Green "Pas de redemarrage du service WinMgmt et de ses dependances"
  80: exit
  81: }
  82:  
  83:  
  84:  
  85:  
  86:  
  87: ###VERIFICATION ET LOG D'ERREURS
  88:  
  89:  
  90: Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
  91: param($targetcomputer)
  92: $wmi=Get-Service -Name WinMgmt -ComputerName $targetcomputer
  93: if ($wmi.Status -ne "Running")
  94: {
  95: $function:NewEventSource
  96: Write-EventLog -LogName 'Operations Manager' -Source RestartWMIScript -EntryType Error -EventId 1002 -Message "erreur de demarrage du service winmgmt"
  97: }
  98:  
  99: } -Argumentlist $targetcomputer
 100:  
 101: ###VERIFICATION ET LOG D'ERREURS
 102:  
 103:  
 104:  

KEMP – Déploiement d’une mise à jour sur deux boitiers en mode HA

Contexte

Les boitiers KEMP sont des Appliances de load-balancing. Ces boitiers permettent de répartir la charge des flux entrants.

La mise à jour de ces boitiers s’effectue en plusieurs étapes. L’opération de mise à jour sur deux boitiers (en mode High Availability) prend entre 15 minutes et 30 minutes.

Remarque : La mise à jour de boitiers KEMP implique une légère interruption de service.

Récupérer la mise à jour

Afin de récupérer une mise à jour KEMP il faut contacter l’éditeur via le formulaire suivant :

http://kemptechnologies.com/en/load-balancing-support/contact-support

Sauvegarde de la configuration

Avant de mettre à jour les boitiers, il est important de sauvegarder la configuration actuelle. Il sera ainsi rapide de remettre en place la configuration en cas d’échec de la mise à jour.

Pour se faire, se connecter à la shared IP et se rendre dans la partie System Configuration puis System Administration et enfin Backup / Restore. Cliquer sur Create Backup File. Le navigateur va alors télécharger le fichier de sauvegarde.

1

Sauvegarde des certificats

Il est important de sauvegarder également les certificats en place sur les boitiers.

Depuis l’interface d’administration (sur la Shared IP), aller dans la partie Certificates, Backup / Restore Certs. Insérer un mot de passe puis cliquer sur Create Backup File.

2

Mise à jours des boitiers

La mise à jour se fera ici sur deux boitiers KEMP en HA.

La mise à jour s’effectue dans un premier sur le boitier actif, puis sur le boitier passif (qui sera alors en mode actif).

Depuis l’interface d’administration (sur la Shared IP), aller dans System Configuration, System Administration, Update Software. Cliquer sur Browse…

3

Récupérer le fichier de mise à jour. Cliquer sur Update Machine pour lancer la mise à jour.

45

Un message informe que l’opération peut prendre du temps, cliquer sur OK pour passer à l’étape suivante. Le fichier est alors transféré vers le boitier.

67

Une fois le fichier transféré, une confirmation est demandée, cliquer sur OK.

8

La mise à jour s’installe puis un reboot est demandé. Ce reboot ne concerne que le boitier actif. Il y aura, à ce moment, une petite interruption du service le temps que le boitier passif prenne le relais.

91011

A ce moment de la mise à jour, le boitier est indisponible comme le montre les deux icônes.

12

Une fois l’icône redevenu vert, se connecter sur l’adresse IP du boitier pour vérifier que tout fonctionne correctement.

13

Remarque : Il est préférable de vider la cache du navigateur afin de ne pas voir de fausses informations. Pour cela depuis les options internet, dans l’onglet General, cliquer sur Delete… puis cocher les cases Temporary Internet files, Cookies et History.

1415

Une fois connecté sur le boitier mis à jour, vérifier que la version est bien celle voulue.

16

Refaire les mêmes actions une seconde fois pour mettre à jour le deuxième boitier. Le boitier premier boitier redeviendra ainsi l’actif.

Une fois les deux boitiers mis à jour, depuis l’interface d’administration (sur la Shared IP), vérifier la version.