PI Services

Etapes principales de mise en place de certificats pour les agents SCOM en workgroup et pour le serveur SCOM sans utiliser de gateway server.

1) Installer une authorité de certification de type « stand alone server » sur une machine (cette machine peut etre physique ou virtuelle)

2) Exporter le certificat racine de l’authorité (nom par defaut : certnew.p7b) vers un dossier partagé

3) Depuis le serveur en workgroup ou le serveur SCOM, lancer une mmc et ajouter le composant enfichable « Certificates »
Dans la console « Certificates » faites un clic droit sur le dossier « Authorite de certification racine de confiance » (en anglais : Trusted Root Certification Authorities) et selectionner Importer. Allez Rechercher le fichier certnew.p7b crée plus haut. Laissez l’assistant placer le fichier dans le magasin « Authorite de certification racine de confiance ».

4) Toujours depuis le serveur en workgroup ou le serveur SCOM, ouvrez votre navigateur et allez a l’adresse http://nom_du_serveur_hebergeant_authorite_certif/certsrv


Cliquez sur "Request a certificate" (Demander un certificat)



Cliquez sur "advanced certificate request"



Cliquez sur Create and submit a request to this CA

Renseignez le formulaire de creation de certificate de la manière ci-dessus, c’est a dire:
Name : le nom de votre serveur en workgroup (Doit etre identique au champ Friendly Name au bas du formulaire)
Company : le nom de la société
Type of certificate needed : selectionnez Other... et renseignez les OID suivant:
1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2   (pas d’espace autour de la virgule!)

Cochez les cases “Mark Key as Exportable” et “Store certificate in the local computer certificate store”

Renseignez le friendly name (I.E : Doit etre identique au champ Name)

Cliquez Submit

Cliquez Yes si le message ci-dessus apparait

5) Depuis le serveur hébergeant l’autorité de certification, ouvrez la console mmc « Autorité de certification »

Ouvrez le dossier «　Pending Request　». le certificat demandé plus haut doit apparaitre. Il est en attente d’approbation

Cliquez droit dessus et selectionnez « Issue »



Le certificat doit apparaitre désormais dans le dossier Issued Certificates

6) Depuis le serveur en workgroup ou le serveur SCOM, retournez sur l’adresse http://nom_du_serveur_hebergeant_authorite_certif/certsrv

Selectionnez Afficher le statut d’une requete de certificat en attente

Selectionnez le certificat

Installez le certificat



Il apparait désormais dans le dossier Personal/Certificates de la console mmc «　Certificates　» du serveur en workgroup ou du serveur SCOM

7) Depuis la console « Certificates » du serveur en workgroup, faites un clic droit sur le fichier de certificat present sous le dossier Personal et selectionnez « Export ». Exportez le vers le dossier partagé crée en etape 2.








Selectionnez Yes Export the private key



Laissez les options par défaut



Renseignez un mot de passe pour le certificat

Renseignez le dossier partagé vers lequel exporter le certificat

8) Sur le serveur en workgroup si l’agent SCOM est déjà installé passez a l’étape 9, sinon effectuez une installation manuelle de l’agent SCOM

9) Sur le serveur en workgroup ou sur le serveur SCOM, ouvrez une ligne de commande vers l’outil MOMCertimport.exe
Tapez la ligne de commande suivante :

Momcertimport.exe <chemin_du_certificat_exporté> /password <password_du_certificat>

Cette commande ajoute une valeur dans le registre de SCOM  représentant le certificat :

10) Redémarrez le service de l’agent sur le serveur en workgroup.

Le nouvel agent doit à présent apparaitre dans la vue Pending de la console SCOM.

Il ne reste plus qu’a l’approuver.

Très important changement de comportement dans la R2 de SCOM :

http://support.microsoft.com/kb/967537

l’état de l’agrégat de moniteur le plus élevé (top level monitor) d’une machine (availability, performance etc..) se répercute sur le groupe contenant la machine.
Ceci était désactivé par défaut dans la SP1.
Le lien donne des infos pour tracer d’éventuels changement trop fréquent et désactiver ce rollup.

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 !