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:

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

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)

Le contenu doit alors apparaitre automatiquement dans la session ouverte:

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

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

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

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”)

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

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

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

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

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

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

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

./setup.pl drivers

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 ;-)

Patienter pendant l’arrêt…

puis le redémarrage…

Ouvrir une session au redémarrage:

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)

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:

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…

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

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:

Cliquer sur “Apply”

Patienter pendant l’installation du package…

et cliquer sur OK en fin d’installation:

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…

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

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

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

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:

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

puis “Operations” et “Diagnostic Logging”:

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

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”

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!

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.

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:

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

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)

Renseigner les informations de connexion au Data Warehouse de SCOM:

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

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

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

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:

Utilisation

Création d’un Service Level Tracking

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

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

Saisir un nom pour ce niveau de service

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

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

Cliquer sur Ok

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”

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

Cliquer sur OK

Cliquer sur Next

et sur Finish

Fermer la fenêtre.

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

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

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

}

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.

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.

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.

Si une base de données est configurée en mode de récupération complet, son journal de transaction ne sera tronqué que suite à la sauvegarde de celui-ci. La réalisation d’un grand nombre de transactions volumineuse peut augmenter indéfiniment la taille du journal des transactions ce qui impliquera un suivi permanent et une charge administratif en plus.

Avec les alertes et les travaux SQL Server on peut automatiser les tâches de sauvegarde du journal de transactions afin d’éviter que le disque hébergeant le journal ne soit rempli.

Pour cela il faudra procéder comme suit :

Créer une unité de sauvegarde

Depuis l’explorateur des objets, développer Server Objects puis cliquer avec le bouton droit de la souris sur Backup Devices et cliquer sur New Backup Device.

Donnez un nom et préciser le chemin du fichier à utiliser pour votre unité de sauvegarde

Cliquer sur Ok

Créer un opérateur pour recevoir les notifications

Créez un opérateur en cliquant sur New Operator

Précisez le nom de l’opérateur, son adresse email si vous voulez utiliser la notification par messagerie électronique et le nom de sa machine en cas de notification par message console.

Cliquer sur Ok

Créer un travail de sauvegarde du journal de transaction

Créer un nouveau Travail en cliquant sur New Job…

Au niveau de l’onglet Général tapez le nom du travail et ensuite passez à l’onglet Etapes.

Créer une étape de Type Script Transact-SQL (T-SQL) avec le script BACKUP LOG NomBase TO BackupDevice avec BackupDevice le nom de l’unité de sauvegarde crée auparavant.

Au niveau de l’onglet Notification choisissez l’opérateur qui doit recevoir une notification et quand.

Créer une alerte relative au compteur de performance (Pourcentage du journal utilisé)

Créez une alerte en cliquant sur New Alerte

Au niveau de l’onglet Général donner un nom à votre alerte de type Alerte de condition de performance SQL Server et configurez la comme illustré au niveau de l’image

Au niveau de l’onglet Réponse choisissez l’exécution du Job de sauvegarde comme réponse et cochez le mode de notification à utiliser.

La configuration de cette alerte qui déclenche le travail de sauvegarde permettra d’éviter que les disques soient remplis et que les journaux de transactions ne grandissent indéfiniment.

Eh bien, il vous est déjà arrivé, en tant qu’utilisateur Outlook d’avoir un message du type :

Pendant l’apparition de ce message, si vous n’êtes pas en mode cache, Outlook ne répond pas.

Le client interroge le client régulièrement le serveur pour avoir des modifications, comme par exemple l’arrivée d’un nouveau message.

Ce message est généré par une requête du client vers le serveur Exchange. Et si au bout de 5 seconds, la réponse ne parvient pas au client, ce fameux message s’affiche.

Le Wrapper est le process générateur de ce message.

Dans les anciennes versions d’Exchange, il y avait des plantages des clients Outlook de manière intempestive et non expliquée. Les développeurs ont donc ajouté ce message de manière à distinguer un plantage lié au fonctionnement d’Outlook d’un autre plantage.

C’est un moyen de debug.

Les causes d’apparition de ce message peuvent être nombreuses. Il peut s’agit :

· Des problèmes liés à l’accès à Exchange à l’Active Directory (DSAccess)

· Des problèmes réseaux

· Des problèmes d’accès aux dossiers Freebusy pour les versions antérieures à Exchange 2007.

Pour plus d’information, merci de se référer à la Kb suivante :

http://support.microsoft.com/kb/892764/fr

Voici le schéma des principaux flux induits par l’utilisation d’Enterprise Vault