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

L’offline Vaut est la fonction qui permet de disposer de tout ou partie des archives Enterprise Vault en local sur un poste de travail, à des fins d’utilisation en mode déconnecté.

La localisation par défaut du cache est dans le profil utilisateur :

C:\Document and settings\%username%\local settings\application Data\KVS\Enterprise Vault\id du cache\

Le mécanisme peut globalement être présenté comme suivant :

Pour bénéficier de l’Offline Vault, le cache Exchange doit, au préalable être configuré (.ost).

En fonction des raccourcis contenus dans le fichier ost, le client Enterprise Vault fait une demande au serveur pour le téléchargement des archives correspondantes.

Voici le contenu du cache Enterprise Vault :

■ Les fichiers db : ce sont les fichiers qui contiennent les archives.

■ downloadTask.xml : fichier contenant la liste des éléments à télécharger dans le cache

■ oae_l*.xml : fichier qui répertorie les noms des dossiers et leur arborescence

■ oae_c*.xml : fichier qui présente la vue des archives dans l’explorateur des archives

■ storeIDMap.xml : fichier de paramètres de l’Offline Vault

Mécanisme de fonctionnement

L’Offline Vault est un ensemble de fichier au format db localisé sur le poste de travail. Ces fichiers sont par défaut dans le profil utilisateur à l’emplacement suivant :

Pour activer l’Offline Vault d’Enterprise Vault se base sur le contenu du cache Outlook pour fonctionner (fichier OST).

■ Enterprise Vault, par le biais du client installé sur le poste, vérifie le contenu du fichier Ost d’Outlook pour identifier les nouveaux raccourcis, donc des éléments éligibles au titre de l’Offline Vault. Sont identifiés lors de cette opération les noms des dossiers contenant les raccourcis et leur hiérarchie de manière à faire la mise à jour de l’Explorateur des archives, seul moyen de recherche des archives en mode déconnecté, les fonctions de recherche habituelles étant non opérationnelles.

Cette opération génère une fenêtre de mise à jour de l’explorateur des archives

Cette opération est généralement longue. Elle fait, en effet, la mise à jour des différents fichiers XML, enregistre les modifications de la boîte aux lettres depuis le dernier téléchargement. Etant donné qu’elle ne se produit qu’au lancement d’Outlook le matin, elle fait un point précis de la boîte aux lettres depuis 24 heures.

■ Le téléchargement se lance à la fin de la fenêtre précédente. Elle se manifeste habituellement par une 2^e fenêtre qui peut ne pas être vue si le volume des données à synchroniser n’est pas très important.

Durant les phases de POC ou de pilote il peut s'avérer intéressant de générer des messages reconnus comme étant des SPAM par Brightmail.

Cela permet notamment de valider le bon fonctionnement des règles antispam et/ou des règles de conformité positionnées dans l'environnement du client.

Pour cela il est tout à fait possible d'envoyer un email contenant dans l'objet ou dans le corps du message quelques mots ou expressions savamment choisies.

Il est également possible d'utiliser un en-tête SMTP prévu à cet effet dans le moteur antispam des Appliances SBG !

L'astuce consiste à ajouter l'expression X-Advertisement:spam lorsque vous envoyez un email de test sur une invite de commande en telnet (NB : Cette expression doit être saisie après la commande DATA).

Dans l'exemple ci-dessus, l'email est bel et bien reconnu comme SPAM et l'action prise consiste à modifier l'objet du message, puis à envoyer le message dans la quarantaine.

Ce tips est tiré de la note technique suivante :

Testing mail flow and spam detection in Symantec Brightmail products and Symantec Mail Security appliances.

Introduction

Les boitiers Symantec Brightmail Gateway (anciennement SMS 8300) sont des Appliances antispam et antivirus commercialisées par Symantec. Ces Appliances sont également capables d'appliquer des règles de conformité voir de s'intégrer à des solutions DLP.

On distingue plusieurs types de mises à jour sur les boitiers SBG :

• Les mises à jour des définitions antispam sont appliquées automatiquement par le service Conduit (les mises à jour ont lieu toutes les 10 minutes environ)
• Les mises à jour des définitions antivirus sont appliquées automatiquement par le service LiveUpdate en fonction de la planification définie par l'administrateur
• Les mises à jour du logiciel (software) qui sont appliquées manuellement à l'initiative de l'administrateur

C'est bien entendu la troisième catégorie qui nous intéresse ici ! Symantec ne fournit par de roadmap publique précise en ce qui concerne les mises à jour du logiciel. Néanmoins on peut considérer que des mises à jour mineures sont disponibles de manière trimestrielle et que des mises à jour majeures sont effectuées tous les 1 à 2 ans.

A titre informatif, voici la liste des mises à jour du software de ces deux dernières années en ordre chronologique :

• Août 2007 - 7.5
• Mars 2008 - 7.6.1-7
• Août 2008 - 7.6.1-14
• Septembre 2008 - 7.7.0-17
• Janvier 2009 - 8.0.0-24
• Mars 2009 - 8.0.1
• Mai 2009 - 8.0.2
• Octobre 2009 - 8.0.3  

Pour être averti instantanément lors de la disponibilité d'une nouvelle version du logiciel, le plus simple reste d'utiliser les alertes par emails intégrées au sein du produit (cf. capture d'écran ci-dessous).

Les Best Practices

Voici les best practices en ce qui concerne les mises à jour du logiciel d'une Appliance Symantec Brightmail Gateway :

• Effectuer une sauvegarde de la configuration du "control center"
• Vérifier que le "control center" n'est pas en train d'effectuer une synchronisation avec un serveur d'annuaire
• Vérifier que les "scanner" ne sont pas en train d'effectuer une réplication des données LDAP à partir du "control center"
• Configurer la pile MTA des boitiers "scanner" sur "Do not accept incoming messages"
• Mettre à jour les boitiers "scanner" avec le "control center"

Procédure

Pour lancer la mise à jour d'une Appliance via l'interface Web, il faut suivre la procédure suivante :

1. Cliquer sur Version dans l'onglet Administration
2. Aller dans l'onglet Updates

Il faut ensuite sélectionner la mise à jour, afficher la description (les "release notes"), puis cliquer sur le bouton Update.

L'interface Web affiche ensuite la barre de progression ci-dessous :

Aucune précision supplémentaire n'est ensuite affichée dans l'interface Web. Pour suivre de manière plus précise les différentes étapes de l'installation (téléchargement des différents modules, installation...), il faut se connecter en SSH sur l'Appliance avec un client tel que putty et utiliser la commande watch update.log (cf. capture d'écran ci-dessous).

A l'issue de l'installation, il est possible de vérifier la version installée sur le boitier à l'aide de la commande version.