PI Services

Parmis les nouveautés de la version 2007 R2 de SCOM, nous pouvons noter la possibilité de s'abonner directement à une alerte depuis la vue des alertes!

On se retrouve alors directement dans l'assistant d'abonnement aux notifications:

Les administrateurs SCOM le savent: la mise à jour des managements packs peut s'avérer longue et rébarbative.

Pour chaque management pack, il est en effet nécessaire:

1. de vérifier la version du management pack installée depuis la console d'administration en comparant avec la version du catalogue http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx
2. télécharger le management pack (s'il existe une version plus récente)
3. installer le management pack (.msi) à l'emplacement désiré (l'emplacement par défaut variant de temps à autres)*
4. consulter la documentation
5. effectuer les éventuelles tâches pré-installation (éventuellement une désinstallation de l'ancien management pack, export des overrides...)
6. importer le management pack dans SCOM
7. finaliser l'installation du management pack (personalisation, overrides...)

La 3ème étape* est une étape relativement consommatrice en temps et peu intéressante (d'autant plus que le nombre de management pack à mettre à jour est important).
Il est en effet nécessaire de suivre les étapes de l'assistant d'installation du management pack (Emplacement cible...), et surtout, l'installation laisse des traces sur la machine (dans Ajout/Suppression de programme) qui à mon sens, n'est pas justifié. Il s'agit ni plus ni moins que d'une extraction de fichier!
Pour palier à ce problème et réduire le temps nécessaire à la mise à jour des managements packs, j'ai développé un script (batch) permettant d'extraire le contenu des .msi sans avoir à les installer.
Il suffit de mettre les .msi des managements packs téléchargés au même emplacement que le script (fourni en pièce jointe) avant de l'exécuter:

Le script va alors, pour chaque .msi présent, extraire le contenu dans un sous dossier respectif, en supprimant les éventuelles sous arborescences que pourrait créer le .msi.

On se retrouve ainsi avec un seul niveau de sous arborescence par Management Pack, contenant chacun l'essentiel:

Il ne reste ensuite plus qu'à consulter les documentations et importer les Management Pack.

Pour télécharger le script, c'est ici: extract_MP_MSI.bat (868,00 bytes)

L'une des nouveautés non négligeable de la version SCOM 2007 R2 et sans aucun doute, l'implémentation du téléchargement de Management Pack directement depuis la console d'administration.

Il n'est en effet non seulement plus nécessaire d'aller faire un tour sur le site du catalogue des Managements Packs (http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx), mais aussi beaucoup plus simple de vérifier les mises à jours disponibles pour les Management Pack déjà installé:

Il y a cependant un "mais" pour ceux qui utilisent un proxy avec authentification: ce n'est pas supporté par la console d'administration SCOM (pas d'invite de saisie des identifiants).

Dans ce cas (ainsi que pour les versions antérieures à la version 2007 R2 de SCOM), il n'y a pas d'autre choix que de passer par le site du catalogue des Managements Pack!

Pour ceux que ça intéresse, j'ai développé un petit script permettant d'extraire rapidement le contenu des managements packs (.msi) sans avoir à les installer. Voir le post "N'installez plus les .msi des Managements Packs"

NB: Si quelqu'un a la solution pour utiliser un proxy avec authentification (sans mémoriser les identifiants, ou modifier le proxy en place), je suis preneur. (Sorte de run as pour l'authentification du proxy.)
 

SCOM 2007 R2 a introduit de nouveaux noms de services:

J'ai récemment rencontré une erreur lors d'un déplacement de boîtes aux lettres en environnement de maquette. La plateforme était composée de quatre machines virtuelles sous Hyper-V version 2 :

• Un contrôleur de domaine sous Windows Server 2008 R2
• Un serveur Exchange 2007 SP2
• Un serveur Exchange 2010 Release Candidate
• Un poste client sous Windows Seven / Office 2007

L'objectif de cette maquette était de tester le fonctionnement d'Exchange 2010 en environnement mixte (Exchange 2007 et Exchange 2010).

Lors du déplacement d'une boîte aux lettres depuis le serveur Exchange 2007 vers le serveur Exchange 2010 avec la commande New-MoveRequest l'erreur suivante s'est produite :

"Active Directory operation failed on PAR-DC-01.domain.lan. This error is not retriable. Additional information : Insufficient access rights to perform the operation."

Cette erreur se produit lorsque les autorisations positionnées sur le compte utilisateur associé à la boîte aux lettres sont erronnées. Dans le scénario rencontré ici, il a suffit de réactiver l'héritage des autorisations sur le compte utilisateur pour résoudre le problème !

Voici la procédure à suivre :

1/ Lancer la console Utilisateurs et ordinateurs Active Directory ("dsa.msc")

2/ Dans le menu View, côcher la case Advanced Features afin de rendre visible l'onglet Sécurité dans la console

3/ Aller dans les propriétés du compte utilisateur, afficher l'onglet Sécurité, cliquer sur le bouton Advanced, puis côcher la case Include inheritable permissions from this object's parent (cf. capture d'écran ci-dessous)

N.B. : Il est également possible d'utiliser la console ADSIEdit pour modifier les autorisations sur les comptes utilisateurs

Vous pouvez ensuite relancer le déplacement de la boîte aux lettres à l'aide d'une commande New-MoveRequest ou via la console MMC Exchange 2010.

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !

Le contexte :

A l'instar de son prédécesseur, Forefront Threat Management Gateway 2010 (TMG) intègre un assistant de publication pour Exchange 2007.

Cet assistant permet de publier les divers services Web intégrés à Exchange 2007 :

• Le Webmail Outlook Web Access
• Le push mail ActiveSync
• Le mode Outlook Anywhere (RPC over HTTP)
• Les services Web Outlook 2007 (OAB Web, Autodiscover...)

Cet assistant génère des règles "sécurisées" dans le sens où seuls les répertoires virtuels associés à ces services Web sont publiés (/OWA, /EWS, /Autodiscover...). Il vous est aussi possible de paramétrer une authentification au niveau du périmètre à l'aide du port d'écoute Web.

Il est possible d'augmenter encore plus le niveau de sécurité de la publication en utilisant le filtre HTTP intégré à ISA/ TMG. Cette fonctionnalité, méconnue ou du moins très peu mise en valeur au sein d'ISA/TMG, permet d'effectuer un filtrage plus fin sur les requêtes HTTP.

Fonctionnement du filtre HTTP

Le filtre HTTP permet d'agir à différents niveaux :

• Limitation de la longueur des URL, des en-têtes et du corps des requêtes HTTP
• Blocage de certaines méthodes HTTP / Webdav
• Blocage d'extensions de fichiers et de types MIME
• Blocage de certains en-têtes HTTP
• Modification à la volée de l'en-tête "Server" ou de l'en-tête "Via"
• Blocage de "signatures" (une signature correspond à une application cliente reconnue grâce au contenu de l'en-tête HTTP "User-Agent")
• Etc.

Le filtre HTTP se configure indépendamment au niveau de chaque règle d'accès ou de publication Web. Dans une règle de publication Web, il est possible de lancer l'interface de configuration via le bouton Filtering de l'onglet Traffic (cf. capture d'écran ci-dessous).

Sinon il est également possible d'effectuer un clic droit sur la règle, puis de cliquer sur Configure HTTP.

Règles de publication pour Exchange 2007

Les outils d'analyse des requêtes HTTP comme Fiddler ou HTTPWatch permettent de mettre en valeur les méthodes HTTP utilisées par chacun des services Web Exchange.

Ainsi le Webmail Outlook Web Access n'utilise que les méthodes GET et POST alors que le mode Outlook Anywhere d'Outlook 2003/2007 utilise les méthodes Webdav RPC_IN_DATA et RPC_OUT_DATA.

Pour autoriser de manière très fine les bonnes méthodes sur chacun des types d'accès Web, il suffit de créer plusieurs règles de publication Web.

Le tableau ci-dessous est un exemple dans lequel six règles sont définies (une règle par service Web). Pour chaque règle sont indiquées les méthodes HTTP et les répertoires virtuels à autoriser.

Remarque : La sécurisation de ces flux passant également par l'authentification des utilisateurs, il est également intéressant d'implémenter une authentification au niveau du serveur ISA / TMG avec une délégation des informations d'identification vers le serveur CAS.

Sauvegarde de la configuration

Attention, la configuration du filtre HTTP n'est pas sauvegardée lorsque l'on effectue un export ou une sauvegarde dans la console MMC !!!

Pour sauvegarder la configuration du filtre HTTP il faut utiliser le script HttpFilterConfig.vbs fournit dans le SDK du produit ! Ce script prend en paramètre l'action (backup ou restore) ainsi que le nom de la règle.

Cela signifie qu'il faudra exécuter le script six fois pour sauvegarder la configuration de six règles. Dans ces conditions la création d'un batch est appréciable ! (ce batch peut également sauvegarder le reste de la configuration à l'aide du script ImportExport.vbs lui aussi présent dans le SDK).

A titre informatif, les SDK d'ISA Server 2006 et de Forefront Threat Management Gateway 2010 Beta3 sont disponibles aux adresses suivantes :

• SDK ISA : http://www.microsoft.com/downloads/details.aspx?familyid=16682c4f-7645-4279-97e4-9a0c73c5162e&displaylang=en
• SDK TMG : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dff77975-84bf-484f-a3bd-9d8dd800e220#filelist

N'hésitez pas à laisser vos commentaires sur cette procédure !

Pour quoi ?

Pour exprimer nos opinions, publier des infos dont nous venons de prendre connaissance, pour être un peu plus Web 2.0 :-)

Pour qui ?

Pour tous les collaborateurs PI Services ! Vous voulez contribuer ? Demandez un accès à l'administrateur

Comment ?

Grace à BlogEngine.Net !