Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

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

par Florian Alikoff | 16 Déc 2013 | Déploiement (MDT, WDS, AIK, SCCM), PowerShell, Windows Server 2012, Windows Server 2012 R2

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

par Christophe Jourdan | 15 Déc 2013 | Supervision (SCOM, NAGIOS)

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.

  
$scomms="scom2k12sp1srv1"
$targetcomputer="scom2k12sp1dc1"
$repeatcountthreshold="1"
$wmi="WinMgmt"
  
$scomcred=Get-Credential -Credential "scom2k12sp1maq1\administrator"
$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",
"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")
  
Import-Module operationsmanager
  
New-SCOMManagementGroupConnection -ComputerName $scomms -Credential $scomcred
  
$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
$arrcomputernewalerts=Get-SCOMAlert | Where-Object {$_.Resolutionstate -eq "0" -and $_.NetbiosComputerName -eq $targetcomputer -and $_.RepeatCount -gt $repeatcountthreshold -and $_.IsMonitorAlert -eq $false }
  
  
  
$matchingalerts=0
foreach ($wmialert in $arrwmialerts)
{
  if ($arrcomputernewalertnames -contains $wmialert)
    {
    Write-Host -ForegroundColor Red -BackgroundColor White "L'alerte "$wmialert.ToUpper()" a été répétée plus de $repeatcountthreshold fois sur $targetcomputer"
    Write-Host -ForegroundColor Yellow "Fermeture de l'alerte "$wmialert.ToUpper()" avant redemarrage du service $wmi et de ses dependances"
    $matchingalerts= ($matchingalerts + 1)
    $arrcomputernewalerts | Where-Object {$_.Name -like "$wmialert*"} | foreach {Set-SCOMAlert -ResolutionState 255 -Alert $_ }
    }
}
  
  
###FUNCTIONS###
Function Restart-Wmi ($targetcomputer)
{
Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
$winmgmt=Get-Service -Name Winmgmt
$winmgmtrundep=$winmgmt.DependentServices | Where-Object {$_.Status -eq "Running"}
Stop-Service -Name Winmgmt -Force -ErrorAction SilentlyContinue
Start-Sleep -Seconds 5
Start-Service -Name Winmgmt -ErrorAction silentlycontinue
Start-Sleep -Seconds 5
 
foreach ($dep in $winmgmtrundep) 
    {
    if (Get-WmiObject win32_service | Where-Object {$_.Name -eq $dep.Name -AND $_.state -ne "running" -AND $_.startmode -eq "Auto"}) 
        {
        write-host -ForegroundColor Green "demarrage de la dependance "$dep.Name.ToUpper()""
        Start-Service -Name $dep.Name -erroraction SilentlyContinue -ErrorVariable ("start_"+$dep.Name+"_error").ToString()
        }
    }
  
}
}
  
  
Function NewEventSource
{
    if(!(Test-Path 'HKLM:\SYSTEM\CurrentControlSet\services\eventlog\Operations Manager\RestartWMIScript'))
    {
    New-EventLog -LogName "Operations Manager" -Source RestartWMIScript
    }
}
###FUNCTIONS###
  
  
  
  
  
  
if ($matchingalerts -gt 0)
{
write-host -ForegroundColor Yellow "Redemarrage du service WinMgmt et de ses dependances"
Restart-Wmi $targetcomputer
}
else
{
write-host -ForegroundColor Green "Pas d'alertes correspondantes trouvées"
Write-Host -ForegroundColor Green "Pas de redemarrage du service WinMgmt et de ses dependances"
exit
}
  
  
  
  
  
###VERIFICATION ET LOG D'ERREURS
  
  
Invoke-Command -ComputerName $targetcomputer -Credential $scomcred -ScriptBlock {
param($targetcomputer)
$wmi=Get-Service -Name WinMgmt -ComputerName $targetcomputer
if ($wmi.Status -ne "Running")
{
$function:NewEventSource
Write-EventLog -LogName 'Operations Manager' -Source RestartWMIScript -EntryType Error -EventId 1002 -Message "erreur de demarrage du service winmgmt"
}
  
} -Argumentlist $targetcomputer
  
###VERIFICATION ET LOG D'ERREURS
  
  
  

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

par Alexis Bernard | 10 Déc 2013 | Infrastructure

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.

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.

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…

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

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.

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

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.

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

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

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.

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

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.

Derniers articles

Aucun résultat

La page demandée est introuvable. Essayez d'affiner votre recherche ou utilisez le panneau de navigation ci-dessus pour localiser l'article.

TOUS LES ARTICLES