PI Services

Le blog des collaborateurs de PI Services

Powershell & Windows Server Backup

 

Windows Server Backup, le successeur de NT Backup est intéressant mais un peu déroutant, et en tout cas plus facile a administrer avec Powershell donc voici un script Powershell qui:

1/ Vérifie la présence de la feature Windows Server Backup et l’installe si ce n’est pas le cas

2/ Si le feature est présent il crée une Policy (au sens Windows server backup) qui effectuera un backup SystemState tout les jours a 1:00 AM.

Avant d’exécuter ce script il est nécessaire de permettre l’exécution de script avec la commande suivante dans une console powershell:

Set-executionpolicy –executionpolicy unrestricted

 

Import-Module servermanager

$module=Get-Module servermanager

$backfeat=Get-WindowsFeature backup-features

$backtools=Get-WindowsFeature backup-tools

if ($backfeat.Installed -eq $TRUE -AND $backtools.installed -eq $TRUE)

{

write-host "les features WINDOWS SERVER BACKUP sont déja installé - Le script va continuer"

}

else

{

add-WindowsFeature backup-features,backup-tools

write-host "Merci de redemarrer le serveur pour prendre en compte l'ajout du feature Windows Server Backup"

exit

}

####verification de la presence du snapin Windows.serverbackup####

Add-Pssnapin Windows.serverbackup -ErrorAction:SilentlyContinue

if ($errSnapin.count -eq 0)

{

Write-host "`No Windows.serverbackup PSSnapin initialized!";

Write-host "Windows.serverbackup PSSnapin failed initialize! Verifiez que le role Windows Server Backup est bien installé dans la console Server Manager";

}

elseif (Get-PSSnapin | where-object {$_.Name -eq "Windows.serverbackup"})

{

write-host "le snapin Windows.serverbackup est deja chargé - le script va continuer"

}

{

}

$SystemStatepolicy = New-WBPolicy

set-wbschedule -Policy $SystemStatepolicy -Schedule 1:00

Add-WBSystemState -Policy $SystemStatepolicy

$diskBackupLocation = New-WBBackupTarget -VolumePath D:

Add-WBBackupTarget -Policy $SystemStatepolicy -Target $diskBackupLocation

Set-WBPolicy -Policy $SystemStatepolicy -force

write-host "Une sauvegarde System State aura lieu tout les jours a 1:00 AM"

SMS – Erreur à l’installation de Symantec Mail Security 6.5 sur un serveur Exchange 2010 sous 2008 R2

La problématique

Lors de l’installation de Symantec Mail Security for Exchange 6.5 sur un serveur Exchange 2010, l’erreur suivante se produit :

Failed to enable ASP.NET web extensions. Installation will not continue.

image

L’explication

A l’heure actuelle Symantec Mail Security utilise encore des fonctionnalités héritées de IIS 6 (l’installeur à notamment besoin du script iisext.vbs).

Par défaut les composants de rétrocompatibilité IIS 6 suivants sont installés sur un serveur Exchange 2010 exécutant le rôle Hub, Mailbox, Cas ou Unified Messaging (seul le rôle Edge n’est pas concerné car il n’utilise pas IIS) :

  • IIS 6 Metabase Compatibility
  • IIS 6 Management Console

Cela n’est pas suffisant pour SMS qui nécessite également le composant IIS 6 Scripting Tools.

La Solution

La solution consiste tout simplement à installer les composants IIS 6 Scripting Tools et IIS 6 WMI Compatibility (le premier étant dépendant du second, les deux doivent être installés).

Cette opération peut être effectuée graphiquement via la console MMC Server Manager ou bien en console Powershell via la commande Add-WindowsFeature.

image

Pour plus d’informations sur les pré-requis nécessaires à Exchange 2010, vous pouvez consulter le lien suivant :

http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx

Cette solution est tirée de la note technique suivante, pour l’instant uniquement validée avec SMS 6.0 :

http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2008081210523154

SYSPREP – Erreur lors de l’exécution d’un SYSPREP sous Windows Seven ou Windows Server 2008 R2

La problématique

Lors de l’exécution de la commande Sysprep sur une machine virtuelle Windows Seven fraîchement installée, j’ai rencontré l’erreur suivante :

A fatal error occurred while trying to sysprep the machine.

image

Le sysprep était exécuté avec les options suivantes :

  • /generalize
  • /oobe
  • /unattend

Suite à des recherches sur le site http://support.microsoft.com, j’ai localisé plusieurs articles traitant d’une problématique proche mais appliquées à Windows Vista. Aucune ne m’a été utile.

La solution

J’ai finalement trouvé la solution sur un forum Technet dont voici le lien :

http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/6208afb1-8f3e-4657-a618-0e4a52e9f546

Le problème semblerait venir du service “Windows Media Player Network Sharing Service” et à mon grand étonnement la désactivation de ce service (ou bien la suppression du processus associé : wmpnetwk.exe) a bel et bien résolu mon problème !

image

En proie au doute, j’ai ré-exécuté l’opération plusieurs fois sur la même machine (en utilisant un snapshot Hyper-V pour revenir en arrière) et ce tips semble bel et bien viable !

N’hésitez pas à laisser un commentaire ou un retour d’expérience si vous avez déjà été confronté à ce problème avec la commande sysprep de Windows 7 ou si ce billet vous a aidé !

Hyper-V V2 – Installation d’une machine virtuelle Red Hat Enterprise


Commencer par créer une machine virtuelle vierge.

Démarrer ensuite la machine virtuelle avec les sources d’installations (ici, Red Hat Enterprise Linux 5)

Pré-requis


Les drivers mentionnés dans cet article nécessitent une compilation. Pour cette raison et pour vous simplifier la tâche, cocher l’installation des outils de développement lors de l’installation du système d’exploitation:

image

Suivre l’assistant d’installation, puis, se loguer une fois l’installation terminée:

Redhat - Hyper-V - 1Redhat - Hyper-V - 2 

Installation des Linux Integrated Component


Une fois la session ouverte, insérer les composants d’intégrations d’Hyper-V dans la machine virtuelle. Il s’agit d’un fichier ISO (LinuxIC v2.iso) disponible ici:

Pour Hyper-V V2 (Windows 2008 R2): http://www.microsoft.com/downloads/details.aspx?familyid=C299D675-BB9F-41CF-B5EB-74D0595CCC5C&displaylang=en

(Le fichier téléchargé “Linux_IC_v2.exe” est auto-extractible)

Extraire le fichier téléchargé et monter le fichier ISO résultant (LinuxIC v2.iso) sur la machine virtuelle (cd-rom)

image

Le contenu doit alors apparaitre automatiquement dans la session ouverte:

Redhat - Hyper-V - 3 - LinuxIC

Sélectionner les fichiers/dossiers présents puis, faire un clic droit et ”copy”

image

Sur le “bureau”, ouvrir le “home” de l’utilisateur. Ici, le compte utilisateur est “Redhat”, il s’agit donc du raccourcit “Redhat’s home”:

image

Créer ensuite un nouveau dossier: (clic droit “Create Folder”)

image

Donner par exemple pour nom “LinuxIC”.

ATTENTION, éviter de choisir un nom avec des espaces. Le script d’installation en Perl risque de ne pas les gérer.

Coller ensuite les fichiers précédemment copiés dans le nouveau dossier: (clic droit, “Paste”)

image

Sur le script Perl (setup.pl), faire un clic droit puis “Properties”

image

Aller ensuite dans l’onglet Permissions et cocher la case “Allow executing file as program”:

image 

Pour installer les drivers, ouvrir un terminal. Pour cela, faire un clic droit sur le “bureau”, puis “Open Terminal”:

image

Aller dans le dossier précédemment créé (LinuxIC) à l’aide de la commande “cd LinuxIC/”:

image

Elever les droits d’exécution pour la suite des commandes. Pour cela, taper “su”, puis saisir le mot de passe root:

image

S’assurer ensuite que “/sbin” soit présent dans la “variable d’environnement” “$PATH”:

pour afficher le contenu de la variable d’environnement, saisir

echo $PATH

Pour ajouter un chemin, saisir “export PATH=$PATH:<nouveauChemin>”. Dans notre cas, il s’agit de:

export PATH=$PATH:/sbin

image

Lancer ensuite l’installation des drivers à l’aide de la commande

./setup.pl drivers

image

patienter pendant l’installation.

Redémarrer la machine virtuelle à l’aide de la commande “shutdown –r now” ou à l’aide du menu “System”, ”Shut down…” puis “Restart” pour les allergiques aux terminaux ;-)

image

Patienter pendant l’arrêt…

image

puis le redémarrage…

image

Ouvrir une session au redémarrage:

image

puis, ouvrir un terminal de manière à vérifier la présence des services en saisissant la commande:

/sbin/lsmod | grep vsc

NB: “| grep vsc” n’est pas obligatoire. Cela permet de restreindre l’affichage aux lignes contenants la chaine “vsc” (équivalent de la commande “find” sous dos)

clip_image002

et en vérifiant la présence de:

netvsc, storvsc, blkvsc et vmbus

netvsc” permet le support du driver synthétique* pour la carte réseau.
storvsc” permet le support des drivers synthétiques* pour les contrôleurs SCSI et disques.
blkvsc” permet le support des drivers synthétiques* IDE et améliore le démarrage.
vmbus” permet la communication entre la machine virtuelle et le serveur Hyper-V hôte.

* également appelé générique

ça y est, les Linux IC (Lunix Integrated Component) sont installés.

Cependant, vous avez du vous apercevoir que la souris n’est pas encore gérée, autrement dit elle n’est pas capable de sortir du contexte de la machine virtuelle lorsque le curseur est déplacé au delà de la zone!

C’est normal, les Linux IC n’intègrent pas les drivers souris. Il faut les installer manuellement en commençant par les télécharger chez Xen…

Installation des drivers souris


ATTENTION: L’installation des drivers souris (InputVSC) nécessitent au préalable l’installation des Linux Integrated Component (Linux IC) détaillé ci-dessus.

Aller sur le site du projet “Satori” de “Xen”:

http://www.xen.org/download/satori.html

Télécharger le fichier “inputvsc.iso” puis le « monter » dans la machine virtuelle:

image

image

Le contenu du fichier ISO doit alors s’afficher dans la machine virtuelle.

Reproduire les étapes précédentes, à savoir, copier les sources d’installations en local, modifier les droits pour l’exécution sur le script Perl local…

image

image

Ouvrir ensuite un terminal (si le précédent est fermé), se rendre dans le dossier où vient d’être copié le contenu du CD-ROM (fichier ISO) et effectuer une élévation de droit (su):

image

ATTENTION: Avant de procéder à l’installation, vous devez procéder à l’installation du package RPM suivant (le plus récent et pour la plateforme en question):

xorg-x11-server-sdk-xxxx.rpm

Si vous disposez du fichier RPM, simplement double cliquer dessus pour l’installer et saisir le mot de passe du compte root pour l’installer:

image

Cliquer sur “Apply”

image

Patienter pendant l’installation du package…

image

et cliquer sur OK en fin d’installation:

image

Retourner dans le terminal, et s’assurer que /sbin soit présent dans la “variable d’environnement” PATH à l’aide de la commande

echo $PATH

Le cas échéant, l’ajouter:

export PATH=$PATH:/sbin

 

Installer ensuite les drivers souris à l’aide de la commande:

./setup.pl inputdriver

et patienter pendant l’installation du driver de la souris…

image

L’installation est terminée. La souris est maintenant synchronisée avec celle du serveur hôte Hyper-V:

image

A noter qu’au stade actuel du développement du driver, j’ai constaté une désynchronisation entre le curseur du serveur hôte et celui de la machine virtuelle. En effet, ce dernier se déplace plus rapidement que celui du serveur hôte!

Ce comportement rappel certaine carte iLo de certains serveurs et peu s’avérer gênant, surtout dans le cas inverse (curseur hôte plus rapide).

En attendant une version plus aboutie des drivers souris, j’espère que cet article vous aura aidé.

Je tiens à préciser que cet article a été orienté pour les personnes ayant peu ou pas de connaissance en environnement Unix/Linux.

Compatibilité des applications serveur avec Windows 2008 R2

Avant de procéder à la mise à niveau de vos systèmes d’exploitation il faudra vérifier la compatibilité des applications serveur avec Windows 2008 R2.

  1. SQL Server
    1. SQL Server 2005 Service Pack 3 et plus
    2. SQL Server 2008 Service Pack 1 et plus
    3. SQL Server 2005 Express Edition Service Pack 2
    4. SQL Server 2008 Express RTM
    5. SQL Server 2008 R2 sera supporté H1 2010

  1. Exchange
    1. Exchange 2010 version est supporté depuis Q4 2009

  1. Office Servers
    1. Forms Server 2007 Service Pack 2 et plus
    2. Groove Server 2007 Service Pack 2 et plus
    3. PerformancePoint Server 2007 Service Pack 2 et plus sera supporté Q1 2010
    4. Project Server 2007 Service Pack 2 et plus
    5. SharePoint Server 2007 Service Pack 2 et plus
    6. Search Server 2008 Service Pack 2 et plus
    7. Search Server 2008 Express Service Pack 2 et plus

 

Pour la liste complète des applications voir Microsoft Server Applications Supported on Windows Server 2008 R2

SCOM – SLD 2.0: attention aux fichiers de logs!

Si vous avez installé récemment le SLD 2.0 et que vous n’êtes pas très familier avec Sharepoint (comme moi), vous allez rapidement vous apercevoir d’une consommation “anormale” de l’espace disque sur le disque système.

Cette consommation est due à la génération un peu trop fréquente de fichiers de logs.

On peut le constater en se rendant dans le dossier c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS:

image

Je vous conseille donc de réduire la génération des fichiers de logs en allant dans la console centrale d’administration Sharepoint,

image

puis “Operations” et “Diagnostic Logging”:

image

Modifier la section “Event Throttling” de manière à restreindre l’enregistrement des événements aux erreurs inattendues uniquement:

image

Si besoin, aller dans l’emplacement des fichiers de logs pour supprimer manuellement les fichiers obsolètes.

L’emplacement est mentionné sur la même page d’administration (Trace Log). Par défaut, il s’agit de “c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS”

image

SCOM – Service Level Dashboard 2.0 (SLD 2.0)

image

La nouvelle version du Service Level Dashboard (version 2.0), qui rappelons-le sert à effectuer des mesures de qualité de service (SLA), s’appuie désormais sur Sharepoint!

 

Voici quelques une des subtilités liées à son installation:

Installation des pré-requis

Installation de Windows Sharepoint Services

Si vous en êtes au stade ci-dessous, arrêtez-vous tout de suite!

image 

En effet, le SLD 2.0 nécessite en pré-requis la version 3.0 de Windows Sharepoint Services.

Il ne s’agit donc pas de la version 2.0 intégrée à Windows Server 2003 (comme le montre la description de la capture ci-dessous) mais d’une version à télécharger ici, ou avec SP2 intégré ici.

image

Pour information: La version 3.0 n’est pas intégrée dans les services pack de Windows Server 2003.

Après avoir téléchargé Windows Sharepoint Services 3.0, lancer l’exécutable:

image

C’est mieux :-)

Suivre alors les instructions d’installation de Windows Sharepoint Services. Dans mon cas, il s’agit d’une installation en mode “Advanced” pour un serveur autonome (Stand Alone).

image

Une fois l’installation terminée, installer le “Service Level Dashboard 2.0”

Installation du Service Level Dashboard 2.0

Le “Service Level Dashboard 2.0” est téléchargeable ici. (ServiceLevelDashboard_x86.msi pour la version 32 bits ou x64 pour la version 64 bits)

image

Renseigner les informations de connexion au Data Warehouse de SCOM:

image

Spécifier les informations nécessaires à Sharepoint (propriétaire du site qui sera créé, nom de la base de données et serveur…)

image

NB: Nous allons conserver le port d’écoute par défaut: 51918

Cliquer sur “Next” puis patienter pendant la création du site web sharepoint dédié au “reporting”:

image

image

=> Cette partie de l’installation peut prendre quelques minutes.

image

image

IMPORTANT:
Lors de ma première tentative d’installation du SLD 2.0, je me suis retrouvé sans site Web dédié au SLD de créé!
Après un nouveau test, je me suis aperçu que le site était créé au moment de l’apparition de la fenêtre MS-DOS ci-dessus, mais qu’il était supprimé en fin d’installation!

Un dernier test m’a permis de découvrir que la cause du problème venait d’Internet Explorer 8! Il m’a donc fallu le désinstaller (et revenir à IE6. IE7 devrait également fonctionner) pour que l’installation se déroule sans problème (et que le site reste).

Donc si vous avez installé les dernières mises à jours Windows update sur votre serveur, vous savez ce qu’il vous reste à faire. (du moins en attendant une compatibilité du SLD 2.0 avec IE8).

Import du management pack dans SCOM

 

Ouvrir la console d’administration de SCOM 2007 R2

Importer le Management Pack du Service Level Dashboard présent dans les sources d’installation:

image

image 

image

Utilisation

Création d’un Service Level Tracking

 

Aller ensuite dans la vue Authoring de la console d’administration:

image

Faire un clic droit dans la section droite, puis “Create”

image

Saisir un nom pour ce niveau de service

image

Spécifier ensuite quel est l’objet mesurer pour ce SLA

image

En cliquant sur Select, on obtient la liste des objets. Dans mon exemple, je sélectionne Active Directory Topology Root:

image

Cliquer sur Ok

image

Sélectionner dans quel management pack mémoriser ce Service Level et cliquer sur Next

Il faut maintenant définir le(s) seuil(s) correspondant aux engagements:

Cliquer sur Add, puis “Monitor state SLO”

image

Saisir un nom pour cet objectif, ainsi que l’objectif fixé et les critères de disponibilité. Exemple: 99% de disponibilité

image

Cliquer sur OK

image

Cliquer sur Next

image

et sur Finish

image

Fermer la fenêtre.

Le “Service Level” apparait dans la console d’administration:

image

Après quelques instant, se rendre sur le site Web du “Service Level Dashboard 2.0”:

Affichage du résultat

Le “Service Level” apparait dans le site (http://<nomDuServeur>:<Port d’écoute>):

image

image

SCOM 2007 : Script de résolution d’alertes

Il peut arriver de devoir passer par un script de résolution d’alertes pour pouvoir nettoyer régulièrement certaines alertes de la console tel que les alertes d’échec de script. Le script suivant est fait pour cela.

Remplacez le nom FQDN_DU_SERVEUR_SCOM  par le fqdn de votre serveur SCOM

Créez une tache planifiée et faites exécuter la commande toutes les heures par exemple en fonction de la fréquence de ces alertes:

“powershell.exe –noninteractive –file chemin_du _script

 

#ce script est executé par tache planifiée tout les jours a 00:00 et clos les

#alertes de nommées 'Script or Executable Failed to run'

#ou 'Discovery Probe Module Failed Execution'dont la date de #modification est superieur a #maintenant moins 24 heures.

#Initialisation du provider Ops Mgr 2007 

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin;

set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;

new-managementGroupConnection -ConnectionString:FQDN_DU_SERVEUR_SCOM -ErrorVariable errSnapin;

set-location FQDN_DU_SERVEUR_SCOM -ErrorVariable errSnapin;

#Checks to see if it failed or succedded in loading the provider

if ($errSnapin.count -eq 0)

{

Write-host "`nOpsMgr 2007 PSSnapin initialized!";

}

else

{

Write-host "OpsMgr 2007 PSSnapin failed initialize! Please verify you are running this script on a OpsMgr 2007 Management Server";

}

$alerttoclose = get-alert | where-object {$_.Name -eq "Script or Executable Failed to run" -or $_.Name -match "^.*Discovery Probe Module Failed Execution"} | where-object {$_.resolutionstate -ne '255'} | where-object {$_.LastModified -gt [DateTime]::Now.Addhours(-24) }

foreach ($alert in $alerttoclose)

{

$alert | resolve-alert

}

SQL Server 2008 : Types de sauvegardes et choix du mode de récupération d’une base de données

Introduction

Lors de la création d’une base de données SQL Server 2008 on peut choisir le mode de récupération à appliquer pour cette base de données. Ce choix ne doit pas être fait au hasard mais il doit répondre aux besoins de l’entreprise en termes de stratégie de sauvegarde et de récupération.

Types de sauvegardes

SQL Server 2008 offre une multitude de types de sauvegarde pour une base de données sauf que ces types de sauvegarde dépendent du mode de récupération choisi pour celle-ci.

Les types de sauvegarde qu’on peut réaliser sur une base de données sont :

  1. Sauvegarde de données
  2. Sauvegarde des journaux de transactions
  3. Sauvegarde de type copie seule

 

L’étendu d’une sauvegarde peut être soit une base de données complète, une base de données partielle ou un ensemble de fichiers ou groupes de fichiers. Pour chacun de ces étendues on peut faire soit des sauvegardes complètes soit des sauvegardes différentielles.

Une sauvegarde différentielle dépend de la dernière sauvegarde complète réalisée avant celle-ci, la perte de la sauvegarde complète implique la perte de toutes les sauvegardes différentielles réalisées après.

Chaque sauvegarde de base de données contient la portion du journal de transaction qui permet de remettre la base de données à la fin de l’opération de sauvegarde.

Une sauvegarde de type copie seule (Copy Only) nous permet de réaliser des sauvegardes sans affecter la stratégie de sauvegarde mise en place, ce qui veut dire qu’une sauvegarde en copie seule même si c’est une sauvegarde complète n’affecte pas le chainage entre les sauvegardes différentielles réalisées après celle-ci et la sauvegarde complète normale réalisée avant elle.

Mode de récupération

Si le mode de récupération d’une base de données est Simple, la sauvegarde des journaux de transaction est désactivée pour celle-ci, en effet SQL Server prendra en charge la gestion des fichiers journaux et à chaque point de contrôle les parties inactives du journal seront tronquées.

clip_image002

Le mode de récupération Journalisé en bloc est un mode complémentaire au mode complet qui permet d’optimiser les opérations en bloc mais n’offre pas le même niveau de protection que le mode complet, en effet ce mode ne prend pas en charge la récupération de la base de données à une date et heure précise.

Meilleures pratiques

  • Choisir le mode de récupération Simple pour les bases de données de développement et de test
  • Si votre base de données est configurée avec un mode de récupération complet ou journalisé en bloc il ne faut pas oublier de réaliser des sauvegardes des journaux de transaction.
  • Une sauvegarde différentielle d’une base de données contient toutes les pages de données modifiées depuis la dernière sauvegarde complète, sans la sauvegarde complète de référence une sauvegarde différentielle ne peut pas être restaurée ; dans le cas où on met en place une stratégie de sauvegarde à base de sauvegarde complète et différentielles il faut bien faire attention à ne pas perdre la sauvegarde complète.
  • L’application d’une mise à jour ou d’un patch de sécurité qui change le numéro de version de votre serveur SQL doit être suivi immédiatement d’une sauvegarde des bases de données système, en fait les anciennes sauvegardes seront obsolètes dans ce cas.

SQL Server 2008 : Meilleures Pratiques pour le stockage

L’optimisation des performances des serveurs SQL Server passe obligatoirement par la mise en place d’une infrastructure de stockage adéquate. Les consignes suivantes permettent d’améliorer les performances de vos serveurs de bases de données SQL Server.

  1. Placer les fichiers de données, les fichiers journaux et la base de données TempDB sur des disques dédiés
  2. Aligner les partitions de vos disques (Windows Server 2003 et antérieurs)
  3. Aligner le nombre de fichiers de données de vos bases de données et principalement la base de données TempDB au nombre de processeurs du serveur.
  4. Formater les disques qui hébergent les fichiers de données avec une taille de cluster adéquate (8, 16, 32 ou 64 Ko), le choix de la taille doit se faire suite à une analyse et des tests qui prendront en compte le contexte d’exploitation de votre base de données et les caractéristiques techniques de votre équipement de stockage.
  5. Favoriser les systèmes RAID 1+0 pour les disques qui hébergeront les journaux de transaction et la base de données TempDB
  6. Planifier convenablement la taille des fichiers de données, des fichiers journaux ainsi que la taille des fichiers de la base de données TempDB.