PI Services

En termes de monitoring, une des nouveautés de SCOM 2012 est la présence de 4 nouveaux types de vues (Dashboard) orientées réseau.

Network Summary, Network Node, Network Interfaces et Vicinity view.

• La vue Network Summary est la seule des quatre à s’afficher par défaut dans la hiérarchie des vues de la partie Navigation, les autres étant disponible via un lien sur la vue Network Summary, via les taches a exécuter ou encore dans le menu contextuel des objets (clic-droit)

Cette vue sert essentiellement a voir l’état générale des équipements et interfaces associés de votre réseau.

• La vue Network Node fourni des détails sur l’état de santé d’un équipement particulier. Cette vue est constitué de :

- la vue des liens connectés à l’équipement sélectionné

- des jauges sur la disponibilité de l’équipement dans le temps

- la liste des interfaces de l’équipement, avec la possibilité d’activer/désactiver directement la supervision de l’interface par override.

• La vue Network Interface est la plus détaillé des vues sur une interface particulière d’un équipement. Il est important de noter que par défaut SCOM 2012 supervise uniquement les interfaces d’équipements supervisés et celles connectées a des ordinateurs Windows également supervisés.

• La vue Network Vicinity (Littéralement « Voisinage Réseau ») est la vue qui traduit le plus l’orientation donné a SCOM 2012, à savoir une vue 360 ° de l’objet.

Cette vue affiche un nœud réseau et tous les ordinateurs Windows et autres équipements réseau connecté à ce nœud.

La possibilité est donnée de basculer entre 5 niveaux de détails de connexion et de visualiser les machines connectés ou non.

En sélectionnant une connexion particulière il est possible d’identifier quelle ports d’équipement réseau est impliqué dans l’état d’une liaison.

La principale limitation dans cette première version des vues Network Vicinity est qu’elle fonctionne uniquement avec des ordinateurs Windows et non les agents Linux, qu’elle ne visualise pas la relation entre un hôte Hyper-V et ses machines virtuelles hébergées, et qu’elle n’affiche pas les interfaces réseaux configurés en « Teaming » comme étant « Teamés ».

Ces limitations devraient disparaitre avec l’évolution de SCOM 2012, notamment à travers le premier service pack.

A noter que l’ensemble de ces 4 types de vues sont visualisable a la fois dans la console native et dans la console web de SCOM 2012.

Contexte

Il arrive souvent lors de l’installation de certains produits ou fonctionnalitée de devoir réaliser des opérations de vérification des pré-requis. Le premier pré-requis a satisfaire concerne souvent le réseau:

• Suis-je en capacité de joindre ma passerelle?
• Le ou les contrôleurs hébergeant les rôles FSMO sont-ils joignable?
• Mes serveurs DNS sont-ils joignable?

Pour réaliser ces opérations sur quelques serveurs cela peut être réalisé manuellement, mais lorsque le nombre de serveur est conséquent, cela peut s’avéré fastidieux. Je vous propose de travailler en powerShell pour simplifier/automatiser cette opération.

Etape 1: récupérer la configuration de machine

Pour cela rien de bien compliquer, la commande ipconfig /all nous retourne l’ensemble des éléments nécessaire:

Maintenant il faut pouvoir isolé chaque paramètre de réponse (ici identifiés de 1 a 6). Pour cela un traitement sur le retour d’ipconfig est nécessaire:

1. 1. Adresse IPv4:  ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]
2. 2. Masque : ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]
3. 3 Passerelle : ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]
4. 4 Serveur DHCP : ((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]
5. 5 DNS Principal : ((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]
6. 6 DNS Secondaire ((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]

Etape 2: Exécuter un ping en powershell

Pour réaliser cette opération les commandes suivante nous retourne un résultat contenant les valeur attendu:

• new-object System.Net.NetworkInformation.ping
• $reply = $ping.Send("192.168.0.254")

Nous savons donc que le ping a fonctionné au travers du status. qu’il reste a isoler puis a traiter. Pour l’isolation, l’utilisation des variables nous simplifie la tache:

Etape 3: Automatisation des résultats

Afin de valider le bon fonctionnement des pré-requis lié au réseau, nous pouvons traiter les retours au travers de différents moyens, pour ma part, je préfère utilisé les conditions au travers du If – Else

   1: #***** Stockage des parametre dans une variable*****#

   2:     $IP= ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]

   3:     $IPMask= ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]

   4:     $IPgtw= ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]

   5:     $IPDHCP=((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]

   6:     $DNS1=((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]

   7:     $DNS2=((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]

   8:  

   9: #**Test passerelle**#

  10:     $reply = ""

  11:     $status =""

  12:     $ping = new-object System.Net.NetworkInformation.ping

  13:     $reply = $ping.Send($IPgtw)

  14:  

  15: if ($reply.status -eq "success")

  16:     {

  17:     write-host "Passerelle joignable" -foregroundColor green

  18:     }

  19:     Else

  20:     {

  21:     write-host "Passerelle injoignable" -foregroundColor red

  22:     }

  23:  

  24: #**Test DHCP**#

  25:     $reply = ""

  26:     $status =""

  27:     $ping = new-object System.Net.NetworkInformation.ping

  28:     $reply = $ping.Send($IPDHCP)

  29:  

  30: if ($reply.status -eq "success")

  31:     {

  32:     write-host "DHCP joignable" -foregroundColor green

  33:     }

  34:     Else

  35:     {

  36:     write-host "DHCP injoignable" -foregroundColor red

  37:     }

  38: #**Test passerelle**#

  39:     $reply = ""

  40:     $status =""

  41:     $ping = new-object System.Net.NetworkInformation.ping

  42:     $reply = $ping.Send($DNS1)

  43:  

  44: if ($reply.status -eq "success")

  45:     {

  46:     write-host "DNS joignable" -foregroundColor green

  47:     }

  48:     Else

  49:     {

  50:         $reply = ""

  51:         $status =""

  52:         $ping = new-object System.Net.NetworkInformation.ping

  53:         $reply = $ping.Send($DNS2)

  54:         if ($reply.status -eq "success")

  55:             {

  56:             write-host "DNS joignable" -foregroundColor green

  57:             }

  58:             Else

  59:             {

  60:             write-host "DNS injoignable" -foregroundColor red

  61:             }        

  62:     }

  63:  

Le résultat positif retourne:

Le résultat négatif retourne:

Conclusion

Cette vérification permet de réaliser un enchainement de script ou d’action si et seulement si les paramètres réseaux sont correct. Par exemple en créant un flag si les résultats sont positif !

Trop souvent, les souscriptions d’alertes ne sont pas utilisées à leur plein potentiel : une seule souscription est créée, ce qui peut bien entendu suffire dans certains cas mais pourraient être largement optimisé dans d’autres.

On peut ainsi définir de vrais scénarios d’escalade : par exemple si aucune action n’a été effectuée pour résoudre une alerte après un délai imparti, on peut décider d’envoyer un SMS à un responsable ou bien de transférer l’alerte à un autre service.

Prenons l’exemple de la souscription suivante, nommée « Alerte Linux » :

Il s’agit d’une souscription des plus classique, où toutes les nouvelles alertes (resolution state 0) concernant les serveurs membres du groupe Unix Computers (donc tous les ordinateur Unix/Linux monitorés par SCOM) et de priorité moyenne ou haute seront adressées par mail à l’utilisateur « Support_Linux ».

Imaginons maintenant que nous souhaitons que cette alerte soit automatiquement transmise par SMS à un responsable si elle n’est pas prise en charge au bout d’une heure.
Il suffit pour ce faire de créer une alerte avec des conditions de déclenchement identiques en tous points à la précédente, que nous nommerons par exemple « Alerte Linux (+1h) » et qui sera cette fois destinée à l’utilisateur « Manager_Linux » avec un délai (alert aging) d’une heure :

En se basant sur ce système, il devient très simple de créer des scénarios d’escalade en fonction du niveau de résolution, de l’heure de la journée (en créant des subscribers valables uniquement la nuit pour les astreintes par exemple) ; ou bien de n’envoyer l’alerte par mail que si elle n’a pas été prise en compte directement dans la console… les possibilités sont vastes !

Et comme il peut être fastidieux de recopier à l’identique les conditions de déclenchement d’une subscription (sans parler du risque de se tromper), Timothy McFadden (PFE chez Microsoft) a developpé un outil très pratique, Subscription Copier :

Il permet de sélectionner une subscription initialement créée avec les bons paramètres de la copier autant de fois que vous en aurez besoin pour votre scénario d’escalade. Il permet également de prédéfinir un délai (alert aging) qui s’incrémente de copie en copie.
Disponible sur son blog : http://www.scom2k7.com/subscription-copier/

Contexte

Lors de la préparation de déploiement de contrôleurs de domaine virtualisés, j’ai souhaité embarquer dans un Template déjà existant un export média d’Active Directory, le tout dans le but de réaliser une “Install From Media” (IFM) afin de réduire le temps de la première réplication et aussi économiser de la bande passante.

Les étapes

Pour réaliser cette opération, j’ai suivi les grandes étapes suivante:

1. Export de l’AD de production dans un répertoire
2. Déploiement du Template OS (déjà utilisé pour d’autres services)
3. Copie de l’export dans le répertoire souhaité de la VM
4. Arrêt de la machine Virtuel
5. Tentative de création du Template

Création du Template

Une fois la machine arrêter, il est possible de générer le Template, cependant la création du Template au travers de SCVMM échoue a 49%:

En analysant le statuts de création du Template on remarque que ce dernier échoue a 99% de la partie Sysprep:

et ce même après plusieurs tentatives sur différents hôtes et différentes librairies:

La cause

Dans le cas présent, le mécanisme sysprep exécute la commande sysprep /generalize.

Pour rappel, il n’existe aucune limite au nombre d’exécutions de Sysprep sur un ordinateur. Cependant, l’horloge de l’Activation de produit Windows commence son décompte la première fois que Windows est lancé. Vous pouvez utiliser la commande sysprep /generalize pour réinitialiser l’activation du produit Windows à trois reprises maximum. Après trois exécutions de la commande sysprep /generalize, l’horloge ne peut plus être réinitialisée.

Les solutions

Afin de palier a ce type de problème, vous pouvez:

• Recréer une machine virtuel et refaire le Template
• Modifier le comportement de “Microsoft-Windows-Security-Licensing-SLC” via le paramètre SkipRearm positionner sur la valeur 1
• Utiliser les fonctionnalités de déploiement de machine virtuelle pour y ajouter la copie de fichier a la première ouverture de session.

Pour rappel, il existe un outils permettant de réaliser les mises a jours des Vhd offline, des Templates ainsi que des machines Offline des librairie VMM. Virtual Machine Servicing Tool (VMST). Pour plus d’information http://technet.microsoft.com/en-us/library/cc501231.aspx .

Introduction

Les vues dans SharePoint 2010 permettent la visualisation des éléments des bibliothèques et des listes; par défaut toute bibliothèque dispose d’un affichage (View) nommé Tous les documents, pour les liste cette affichage par défaut s’appelle Tous les éléments.

SharePoint nous permet aussi de créer nos propres affichage et de les personnaliser   

L’affichage par défaut permet d’afficher les éléments sous forme d’une liste comme le montre la figure suivante :

Lors de la création de nouveaux affichage nous avons la possibilité d’appliquer des filtres, de changer l’apparence des lignes et aussi de regrouper les éléments sauf que la personnalisation offerte au niveau de l’explorateur par SharePoint ne nous permet pas de regrouper les données par plus de deux colonnes

Problématique 

Le regroupement des éléments d’une liste ou une bibliothèque avec plus de deux colonnes ne nous ai pas permis via l’interface web de SharePoint, par contre nous pouvons répondre à ce besoin en utilisant SharePoint Designer, cet article et au niveau de la section suivante va détailler cette procédure.                     

Comment faire ?

• Créer un nouvel affichage basé sur l’affichage standard pour la bibliothèque de document ( dans notre exemple nous allons l’appeler Regroupement Personnalisé)

• Ouvrir le site avec SharePoint Designer et procéder à la modification de la vue Regroupement Personnalisé en double cliquant sur celle-ci depuis la liste des Vues   

• Au niveau de la page supprimer le composant WebPartPages:XsltListViewWebPart

• A la place du composant WebPart supprimé insérer une vue de données vide

• Cliquer sur Click here to select a data source

• Sélectionner la bibliothèque comme source de données 

• Sélectionner les champs à afficher depuis la fenêtre Data Source Details

• Insérer les champs sélectionner en choisissant Multiple Item View

• Depuis l’onglet Options cliquer sur Sort & Group

• Ajouter les colonnes que vous voulez utiliser pour le regroupement
 

• Pour personnaliser l’entête des groupes cliquer sur Edit Sort Expression  et tapez la formule qui permettra d’afficher l’entête souhaité, par exemple nous voulons que l’entête du regroupement par Version du produit affiche aussi le nom du produit il suffit de taper la formule concat(@Produit , " - ", @Version_x0020_Produit) 

Faire la même chose pour les autres groupements pour personnaliser les entêtes   

• Ainsi nous avons une vue de la bibliothèque avec des regroupements de plus de deux niveaux 

Autre actions de personnalisation

Changer le nom du document en lien

• Avec le bouton droit de la souris cliquer dans la case du nom du fichier et ensuite cliquer sur le menu Format item as ==> Hyperlink 

• Au niveau de la cas Adresse cliquer sur le bouton fx

•  Sélectionner Chemin d’URL depuis la liste des éléments puis cliquer sur Ok

1. Vérifier que la champ Text to display {@FileLeafRef.Name} et l’Adresse  {@FileRef}

Microsoft met à disposition un outil qui permet de vérifier la configuration du

client Outlook et de détecter un potentiel problème, Microsoft Outlook Analyzer Configuration Tool.

Cet outil est de la même famille que l’outil  Microsoft Exchange Best Practices Analyzer.

L’interface sera donc familière aux administrateurs d’Exchange 2010.

Télécharger l’outil depuis ce lien:

http://www.microsoft.com/download/en/details.aspx?id=28806

Après avoir installé l’outil, exécutez une analyse (outlook doit être démarré).

Après quelques clics vous obtiendrez un rapport:

Analysez et corrigez éventuellement les problèmes.

Symptôme

Suite à la migration d’une boîte aux lettres Exchange Server 2003 SP2 vers un DAG Exchange 2010 SP1 RU6 (en environnement intra-organisationnel),  l’utilisateur ne peut plus synchroniser ses emails via ActiveSync et l’erreur suivante se produit régulièrement dans le journal Application du serveur CAS :

Voici le détail de l’erreur rencontrée :

De plus l’utilisateur ne peut pas voir son téléphone lorsqu’il accède à l’interface ECP (Exchange Control Panel) dans le menu Phone, puis Mobile Phone.

Explication

Avec Exchange Server 2003 les partenariats ActiveSync sont stockés dans un dossier caché au sein de la boîte aux lettres de l’utilisateur.

Ce dossier se nomme Microsoft-Server-ActiveSync et est visualisable à l’aide d’un outil tel que MFCMAPI (http://mfcmapi.codeplex.com/).

Avec Exchange Server 2010 les partenariats ActiveSync sont stockés directement dans l’annuaire Active Directory sous la forme d’un objet de type msexchangeActiveSyncDevice.

Lors de la migration de la boîte aux lettres vers Exchange Server 2010 le serveur Exchange possédant le rôle CAS doit donc créer un conteneur nommé CN=ExchangeActiveSyncDevices dans le compte utilisateur. Le serveur CAS créé ensuite un objet de type msexchangeActiveSyncDevice dans ce conteneur pour chaque partenariat ActiveSync établit.

Voici un exemple d’objet msexchangeActiveSyncDevice généré dans un environnement Exchange Server 2010 :

Dans notre exemple l’héritage des autorisations étaient désactivé sur le compte utilisateur. Cela a empêché la descente des ACL nécessaires au bon fonctionnement d’Exchange et donc a provoqué le message d’erreur 1053 Access is Denied sur le serveur CAS.

Cette désactivation était engendrée dans notre cas à cause de l’appartenance du compte utilisateur au groupe “Server Operators” qui est l’un des groupes protégé par le mécanisme AdminSDHolder.

Pour mémoire ce mécanisme a pour but de contrôler les ACL appliquées sur les objets (comptes utilisateurs, comptes ordinateurs…) membres des groupes protégés.

La liste des groupes protégés par le mécanisme AdminSDHolder dans les différentes versions de Windows (de Windows 2000 Server à Windows Server 2008 R2) est disponible sur le site de Microsoft à l’adresse suivante :

http://technet.microsoft.com/en-us/query/ee361593

Remarque : Dans notre cas le téléphone touché était un Sony Ericsson sous Symbian avec l’application RoadSync. Cependant ce problème étant dû à une configuration au niveau du compte Active Directory tout autre téléphone pourrait en être victime.

Résolution

Pour résoudre ce problème il faut se connecter à l’ADUC (Console “Utilisateurs et ordinateurs Active Directory”), puis dans les propriétés de l’utilisateur concerné choisir “Security”, “Advanced” puis cocher la case “Include inheritable permissions from this object’s parent”.

Suite à cette manipulation la synchronisation “initiale” (comprendre celle engendrant la génération des objets dans l’annuaire Active Directory) du téléphone fonctionnera ainsi que toutes les synchronisations ultérieures.

Une fois la première synchronisation effectuée l’utilisateur pourra visualiser et gérer ses partenariats ActiveSync dans l’interface ECP (la capture d’écran ci-dessous est un exemple).

Remarque : Il est intéressant de noter que le mécanisme AdminSDHolder remodifiera automatiquement les ACL (et donc re-désactivera l’héritage des autorisations) dans un délai d’une heure maximum (en effet le processus s’exécute toutes les 60 minutes par défaut).

Le passage du SP2 apporte une correction à certains problèmes mais apporte

également son lot de disfonctionnement tel que celui-ci.

Pour certains besoins il est parfois nécessaire de reconnecter une boîte aux

lettres à un compte. Avant le passage du SP2 la boite est fonctionnelle dès

sa reconnexion à un compte utilisateur.

Après le passage du SP2 vous pourrez obtenir cette erreur détectable

lorsqu’on envoie un message à la boite présente dans la GAL:

Échec de la remise pour ces destinataires ou groupes :
Dupont Jean (jean.dupont@bug.fr) <mailto:jean.dupont@bug.fr>
La boîte aux lettres du destinataire pose un problème. Essayez de renvoyer ce message. Si le problème persiste, contactez le support technique de votre organisation.
Informations de diagnostic pour les administrateurs :
Serveur de génération : SERV01.bug.fr
jean.dupont@bug.fr
#554-5.2.1 mailbox disabled 554 5.2.1 STOREDRV.Deliver.Exception:AccountDisabledException.MapiExceptionMailboxDisabled; Failed to process message due to a permanent exception with message Cannot open mailbox /o=MSG/ou=Exchange Administrative Group

On ne peut pas également déplacer la boîte de banque !

On constate également que la boite a toujours le statut “disabled”

PS C:\Windows\system32> Get-MailboxStatistics JDUP | fl

AssociatedItemCount     : 67

DeletedItemCount        : 2010

DisconnectDate          : 16/02/2012 08:54:26

DisconnectReason        : Disabled

Réalisez les mêmes tests le lendemain matin et vous observerez que tout est

rentré dans l’ordre. La nuit porte conseille…..

Par défaut Exchange effectue une maintenance nocturne planifiée.

Les processus réalisés diffèrent de la maintenance de type “background”.

Durant cette maintenance nocturne une vérification des banques d’informations et

particulièrement des objets supprimés est réalisée.

C’est cette mécanique qui rend de nouveau la boîte opérationnelle.

Microsoft apportera cette correction dans le RU3 pour Exchange 2010 SP2, il faut

donc patienter quelques mois, incident mineure pour Microsoft….

Dans l’attente de ce correctif il faut donc réaliser un nettoyage de la banque

après avoir reconnecté la boite (clean-mailboxdatabase).

Une alerte courante est issue du moniteur “Active Directory Bind Monitor” du management pack AD:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

En ouvrant les propriétés de l’alerte (double-clic) et l’onglet Alert Context, on peut voir dans l’exemple ci-dessous le compte incréminé, dans le champ User:

l’execution d’une GPO a échoué pour ce compte.

Independement de la solution proposé dans la description de l’alerte, une premiere piste consiste a verifier si le compte en question n’a pas une session restée ouverte sur la machine (ceci meme si le compte est désactivé dans Active Directory). Si c’est le cas, fermez cette session, reseter le moniteur dans SCOM (il s’agit d’un moniteur de type “Manual Reset”), et verifiez par la suite que le problème ne se reproduit pas.

Symptômes

Lors de l’exécution de la commande Get-OwaVirtualDirectory l’erreur “800706ba” apparait :

Et ce malgré la bonne configuration des Client Access Servers et le lancement du service IIS sur ces derniers.

On remarque également que désactiver le pare-feu sur les serveurs CAS résout le problème rencontré.

Cause

Cette erreur est causée par le blocage du pare-feu Windows.

Résolution

Afin de résoudre cette erreur tout en gardant le pare-feu actifs il faut créer une nouvelle règle au niveau pare-feu :

1. Selectionner “new inbound rule”
2. Choisir comme type "custom"
3. Choisir "All Programs"
4. Protocol type: "TCP",  Local port: "Dynamic RPC",  Remote ports: "All ports"
5. Adresses IP : “Any to Any”
6. Action : “Allow connection”
7. Profil : "Domain"
8. Nom : "Dynamic TCP incoming" (le nom n’importe pas).

Cette règle doit être créée sur le pare-feu de tous les serveurs CAS.

A noter que Rollup Update 6 ne résout pas ce problème.