PI Services

Le blog des collaborateurs de PI Services

Active Directory – Gestion des photos d’identités

L’annuaire “Active Directory” permet d’ajouter une photo afin d’identifier un utilisateur

via des clients tel que Outlook ou Lync.

Pour la gestion des photos on peut s’aider d’utilitaire tel que CodeTwo Active Directory Photos.

On peut récupérer cet outils ici :

https://www.codetwo.com/freeware/active-directory-photos/

L’installation est très simple:

clip_image002

clip_image004

clip_image006

clip_image008

clip_image010

L’utilisation est très simple également.

clip_image012

La photo est “stockée” dans l’attribut “thumbnailPhoto”

clip_image013

Il est important que cet attribut soit répliqué.

A vérifier selon la version d’Exchange.

clip_image015

Ajoutez les photos des collaborateurs.

clip_image017

clip_image019

L’attribut “thumbnailPhoto” est renseigné.

clip_image021

Et voilà le résultat sous Outlook.

clip_image022

Template VHD pour HYPER-V

Lors de la mise au point d’une maquette sur un poste portable, il est pratique d’avoir en local des templates au format VHD. Dans ce post nous verrons comment créer des templates au format VHD ainsi que comment les déployer à l’aide d’HYPER-V.

Créer un template au format VHD

Tout d’abords il faut créer une machine virtuelle avec l’OS désiré pour le template, il est également pertinent de passer les derniers patchs ainsi que d’installer la dernière version des services d’intégrations HYPER-V. Il est également possible d’installer des applications qui seront utiles au master.

    • Un fois la VM prête pour être transformée en template, il serait judicieux d’éteindre la VM et d’en copier le VHD (avant l’exécution du sysprep) afin de pouvoir recréer le Template si celui-ci venait à être mis à jour.
    • Après avoir démarré la VM, il faut maintenant exécuter le sysprep sur celle ci en prenant bien soir de cocher la case generalize afin de générer un nouvel SSID lors de l’utilisation du template.

image

  • Une fois la VM éteinte, il faut en copier le VHD vers l’emplacement souhaité, il est par ailleurs préférable d’ ajouter l’attribut Read-Only au VHD généré.

Utiliser un template VHD dans HYPER-V

En utilisant HYPER-V, il est très simple de déployer un OS à l’aide d’un VHD, pour ce faire il suffit de suivre l’assistant de création d’une machine virtuelle et une fois arrivé à la page Connect Virtual Hard Disk il faut utiliser un VHD existant et ne pas laisser HYPER-V en créer un automatiquement :

image

Windows – Powershell Gestion des groupes d’un ordinateur.

 

Dans la gestion des groupes dont est un ordinateur est membre un administrateur doit parfois ajouter les groupes de cet ordinateur vers un second.

Voici une ligne de commande réalisée avec l’outil Quest Activeroles qui permet de réaliser cette action.

Get-QADComputer SRVPROD -searchroot 'DC=source,DC=com' | Get-QADMemberOf | where name -ne 'Domain Computers ' | Add-QADGroupMember -Member 'TESTSERV' -Service DCSYS001.target.com

Dans cet exemple on extrait les groupes dont le serveur SRVPROD est membre du domaine source.com .On exclu le groupe « Domain Computers » et pour finir on ajoute les groupes au serveur TESTPROD du domaine target.com.

On peut également avoir besoin d’exporter les groupes dans un fichier CSV.

L’attribute ‘MemberOf’ est de type « multivalued »

Get-QADComputer SRVPROD -searchroot 'DC=source,DC=com' | select-object @{n='memberOf';e={$_.MemberOf -join ';'}} | export-csv d:\"$server"_2.csv -NoTypeInformation -Force -Delimiter ";"

Afin d’extraire tous les groupes on doit utiliser une syntaxe particulière on utilisant la fonction JOIN : @{n='memberOf';e={$_.MemberOf -join ';'}} .

Windows – Changement de domaine Active directory d’un poste connecté en VPN.

 

Comme toute migration ou changement de domaine d’un poste de travail cette opération doit rester la plus transparente possible pour l’utilisateur final.

Cet article aborde la migration d’un poste connecté au réseau d’entreprise par un VPN.

Dans cette situation ce n’est pas la migration du poste qui pose une difficulté, mais l’impossibilité pour l’utilisateur de pouvoir ouvrir une session sur son poste.

Les informations d’authentification du compte (en cache) du domaine Active Directory qu’on peut utiliser même si le domaine n’est pas disponible, ce qu’on décrit comme le mode hors connexion, ne sont plus disponibles après le changement du domaine.

Par défaut Windows 7 cache jusqu’à dix comptes.

Le cache est enregistré dans la ruche suivante : HKEY_LOCAL_MACHINE\SECURITY\Cache.

clip_image002

Pour accéder à cette ruche il faut utiliser un outil tel que PsExec de SysInternal afin de débloquer l’accès.

La ligne de commande est la suivante : psexec -i -d -s c:\windows\regedit.exe

Après le changement de domaine les données mentionnées dans les valeurs NL$ seront supprimées (remises à zéro).

L’utilisateur ne peut donc plus ouvrir de session !

Pour ma part j’ai eu à traiter des utilisateurs travaillant dans des coins très reculés.J’ai eu part exemple le cas d’un VIP travaillant en Australie à plus de 3000 kms d’une agence disposant d’un réseau connecté à l’entreprise. La marge de manœuvre est quasiment nulle…

Pour contourner ce problème je propose deux techniques.

La première technique consiste à démarrer la connexion VPN donc l’authentification avant l’authentification Windows.

Il faut donc avant la migration configurer le client VPN afin qu’il se lance avant l’authentification Windows.

Sur les clients VPN récents de CheckPoint l’option Enable Secure Domain Logon permet ce mécanisme.

clip_image004

Vous verrez un icône supplémentaire dans la fenêtre d’authentification Windows.

Pour information cette option pour le client CheckPoint sur Windows XP n’est pas fonctionnelle.

La seconde technique si l’on ne souhaite pas ou si l’on ne peut pas démarrer la connexion VPN avant l’authentification Windows, consiste à ouvrir une session locale puis à lancer une application qu’on exécute en tant que avec son compte de domaine. Bien entendu la connexion VPN doit être démarrée.

En résumé :

· Création d’un compte local (admin si possible, bien utile pour se sortir de situation délicate) avant la migration.

· Après migration, authentification avec ce compte local.

· Lancer le VPN.

· Lancer une application. Exécuter en tant que (ex Notepad) avec son compte de domaine. (Pour information le RunAS ne fonctionne pas sous XP).

· Fermer la session et ouvrir une session avec son compte de domaine Active Directory.

Le VPN n’étant pas démarré, les informations mis en cache lors du lancement de Notepad exécuté « En tant que » précédemment seront utilisées.

La migration sous un VPN étant très délicate il faut bien entendu bien valider son processus avant de passer au concret.

Je conseille fortement quel que soit le scénario, de créer un compte local admin et de faire installer un outil tel que Team Viewer qui s’affranchit de l’adresse IP pour l’aide à distance.

Lync Server 2013 – Erreur 0x80090331 SEC_E_ALGORITHM_MISMATCH sur un serveur Front-End

Problématique

Lors du déploiement d’une nouvelle infrastructure Lync Server 2013 (sur un socle Windows Server 2012), le problème suivant peut apparaître sur les clients Lync :

Can’t sign in to Lync
We’re having trouble connecting to the server. If this continue, please contact your support team.

 image

En lançant une analyse du composant SIPStack sur les serveurs front-End Lync via les outils Lync Server Diagnostic Tool et Snooper pendant la connexion d’un client, on observe l’erreur suivante :

0x80090331 SEC_E_ALGORITHM_MISMATCH

image

Remarque : Dans Lync Server 2013, l’outil de logging n’est plus intégré au déploiement. Pour l’installer, il faut déployer le pack d’outil Lync Server 2013 Debugging Tools disponible à l’adresse suivante : http://www.microsoft.com/en-us/download/details.aspx?id=35453

Explication

L’erreur SEC_E_ALGORITHM_MISMATCH se produit durant la phase de négociation du protocole TLS (le flux client –> serveur étant sécurisé en SIP over TLS).

Il semble que le service Lync Server Front-End ou bien le client Lync 2013 ne gère pas correctement les certificats signés numériquement en SHA512.

 image

Résolution

Dans ce cas la résolution a consisté à déployer sur les serveurs Lync 2013 front-end un nouveau certificat signé avec les algorithmes SHA1/RSA en remplacement de l’ancien certificat signé en SHA512/RSA.

Ce comportement est assez étrange car le protocole SHA512 est intégré au système depuis Windows Vista pour les postes de travail et Windows Server 2008 pour les serveurs.

Windows Server 2012 – Création d’un fichier “unattend.xml” pour automatiser le déploiement post-SYSPREP (pas-à-pas)

Les fichiers de réponses permettant d’automatiser l’assistant mini-installation post-SYSPREP doivent être créés avec l’outil Windows System Image Manager.

Cet outil est l’un des composants du kit WADK (pour Windows Assessment and Deployment Kit). Le kit WADK de Windows 8 est disponible en téléchargement à l’adresse suivante :

http://www.microsoft.com/en-us/download/details.aspx?id=30652

Durant l’installation, il faut sélectionner à minima le composant Deployment Tools pour que la console Windows System Image Manager soit disponible.

image

Une fois le kit installé, il faut lancer la console Windows System Image Manager, puis créer un nouveau fichier de réponse dans la section Answer file de la console.

image

Le fichier de réponse est composé de 7 sections correspondant chacune à une étape distincte du processus d’installation. Dans le cas d’un fichier de réponse destiné à automatiser l’installation du système (partitionnement, choix de la version du système…) la majorité des paramètres se configurent dans la section 1 windowsPE.

Dans notre cas (création d’un fichier de réponse destiné à automatiser la phase post-SYSPREP), la majorité des paramètres se configurent dans les étapes  4 (specialize) et 7 (oobe System).

image

Dans la section Windows Image de la console il faut aller sélectionner le fichier install.wim présent dans le répertoire Sources du média d’installation de Windows Server 2012.

image

Attention : Vous devez extraire les sources de Windows Server 2012 dans un dossier stocké sur un disque dur (la création des fichiers de catalogue ne pouvant être réalisée que sur un support en lecture / écriture)

Choisissez ensuite l’édition de Windows Server 2012 correspondant au système d’exploitation dont vous souhaitez automatiser le SYSPREP (dans cet exemple il s’agit d’une installation FULL de Windows Server 2012 Standard).

image

Une fois l’image sélectionnée, la phase de génération des fichiers de catalogue se lance. Attention cette phase peut être longue (environ 2 minutes sur un SSD mais jusqu’à 10/15 minutes sur un disque dur mécanique 5400 tours.min ou 7200 tours.min).

image

Une fois les fichiers de catalogue généré, l’ensemble des packages inclut dans le média doivent s’afficher dans la section Windows Image. Chaque package contient un ou plusieurs paramètres pouvant être configuré. Chaque package possède son propre périmètre d’application (certains s’appliquent à la phase 1 du déploiement uniquement, d’autres aux phases 3 et 4, etc…).

image

Pour ajouter un package (dans notre exemple il s’agit du package nommé amd64_Microsoft-Windows-IE-ESC_10.0.9200.16384_neutral qui permet de configuré les options de mode de sécurité renforcé Internet Explorer), il faut faire un clic droit, puis choisir dans quelle étape on souhaite intégrer les paramètres (dans notre exemple ce package s’applique uniquement à la phase 4 Specialize.

image

Une fois le package ajouté, il apparaît ensuite dans la section Answer File avec tous ses paramètres (ici le package dispose de deux paramètres). Une liste déroulante est disponible pour configurer chaque paramètre.

En passant les paramètres IEHardenAdmin et IEHardenUser à la valeur False, le mode de sécurité renforcé d’Internet Explorer sera désactivé durant la phase de SYSPREP.

image

La difficulté dans ce processus consiste à identifier tous les packages les plus intéressant pour réaliser une configuration automatisée de Windows Server 2012.

Le tableau ci-dessous énumère les paramètres les plus intéressants pour un déploiement standard. Les paramètres obligatoires pour automatiser le déploiement sont indiqués en bleu dans le tableau.

Les paramètres indiqués en vert sont optionnels mais peuvent être intéressant pour optimiser le déploiement (par exemple fixer une page par défaut dans le navigateur ou ne pas charger au logon la console Server Manager).

Step Nom du package Paramètre Valeur
4 amd64_Microsoft-Windows-IE-ESC_Neutral IEHardenLimit false
4 amd64_Microsoft-Windows-IE-ESC_Neutral IEUserLimit false
4 amd64_Microsoft-Windows-IE-InternetExplorer_neutral DisableFirst RunWizard true
4 amd64_Microsoft-Windows-IE-InternetExplorer_neutral Home_Page http://www.google.fr
4 amd64_Microsoft-Windows-International-Core_neutral InputLocale fr-FR
4 amd64_Microsoft-Windows-International-Core_neutral SystemLocale fr-FR
4 amd64_Microsoft-Windows-International-Core_neutral UILanguage en-US
4 amd64_Microsoft-Windows-International-Core_neutral UserLocale fr-FR
4 amd64_Microsoft-Windows-ServerManager-SrvMgrNc_neutral DoNotOpenServer ManagerAtLogon true
4 amd64_Microsoft-Windows-Shell-Setup_neutral ComputerName *
4 amd64_Microsoft-Windows-Shell-Setup_neutral ProductKey AAAAA-BBBBB-CCCCC-DDDDD-FFFFF
4 amd64_Microsoft-Windows-Shell-Setup_neutral RegisteredOrganization LAB
4 amd64_Microsoft-Windows-Shell-Setup_neutral RegisterezOwner Windows User
4 amd64_Microsoft-Windows-Shell-Setup_neutral TimeZone Romance Standard Time
7 amd64_Microsoft-Windows-Shell-Setup_neutral / Display ColorDepth 16
7 amd64_Microsoft-Windows-Shell-Setup_neutral / Display HorizontalResolution 1024
7 amd64_Microsoft-Windows-Shell-Setup_neutral / Display VerticalResolution 768
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE HideEULAPage true
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE HideLocalAccount Screen true
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE HideOnlineAccount Screens true
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE NetworkLocation work
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE ProtectYourPC 1
7 amd64_Microsoft-Windows-Shell-Setup_neutral / UserAccounts / AdministratorPassword value Pa$$w0rd

Au final vous devez obtenir un fichier de réponse proche de celui ci-dessous.

image

Le fichier de réponse peut ensuite être utilisé. Pour cela il faut le copier dans le répertoire C:\Windows\System32\SYSPREP, puis utiliser la ligne de commande suivante lorsque vous exécuterez la commande SYSPREP :

sysprep.exe /generalize /oobe /shutdown /unattend:"C:\Windows\System32\sysprep\monfichier.xml"

Avec ce fichier de réponse l’ordinateur / le master doit pouvoir démarrer après le sysprep sans qu’aucun paramètre ne soit demandé (aucune action entre le moment où le master est déployé et le moment où l’écran de logon s’affiche).

image

Windows Server 2012 – Optimiser la taille du dossier WinSXS

Rappels

Depuis la sortie de Windows Vista / Windows Server 2008, l’ensemble des composants Windows sont hébergés dans le répertoire C:\Windows\WinSXS.

Cela permet de pouvoir déployer l’ensemble des composants Windows Server (DNS, DHCP, Desktop Experience…) sans jamais avoir recours au média d’installation (DVD, clé USB…).

En revanche, le dossier WinSXS occupe beaucoup de place (entre 5 et 15 Go) et a tendance à occuper de plus en plus de volume avec le temps.

Cela s’explique facilement car ce dossier conserve une copie des anciennes versions des fichiers (.dll, .inf, .exe…) lorsqu’un service pack, mais aussi lorsqu’une simple mise à jour est déployée.

La conservation des anciennes versions des fichiers permet de revenir à l’état antérieur en cas de désinstallation du service pack ou bien de la mise à jour.

Dans certains scénarii, notamment lorsqu’un disque SSD de petite capacité est installé, il peut être nécessaire de réduire la taille du dossier afin de regagner de l’espace.

Optimisation du dossier

Pour réduire la taille du dossier WinSXS il est possible de supprimer les fichiers système antérieurs à l’application d’un service pack avec la commande suivante :

dism.exe /online /cleanup-image /spsuperseded

Cette commande existait déjà sous Windows 7 / Windows Server 2008 R2. Néanmoins dans Windows 8 / Windows Server 2012, il n’existe pas encore de Service Pack.

Windows 8 et Windows Server 2012 apportent une nouvelle option, nommée startcomponentcleanup, qui permet de retirer les anciennes versions de fichiers pour les composants Windows suite à l’application des simples mises à jour (patch KB). Voici la commande à saisir pour retirer ces anciens fichiers :

dism.exe /online /cleanup-image /startcomponentcleanup

image 

Exécutée sur une nouvelle installation de Windows Server 2012 (sans aucun composant déployé mais avec l’ensemble des mises à jour au 12/07/2013), cette commande a permis de réduire la taille du dossier de 700 Mo environ (passage de 11.8 Go à 11.1 Go occupés sur le disque), soit un gain de 7% environ.

image image

Il est possible d’aller encore plus en compressant le dossier, néanmoins cette action est non supportée (contrairement à l’usage de la commande dism.exe qui est une commande standard du système) et également fortement déconseillée dans le cas d’un serveur de production.

Pour ceux qui souhaitent optimiser un environnement de maquettage ou bien un poste de travail non critique, la compression permet tout de même un gain non négligeable (sur le même exemple il est possible de réduire la taille occupée sur le disque de 11.1 Go à 7.3 Go).

image

Pour réaliser la compression du dossier WinSXS (à vos risques et périls !), je vous conseille la procédure suivante qui a le mérite de faire revenir les ACL et l’attribut propriétaire à leur valeur d’origine en fin d’opération.

http://dandar3.blogspot.fr/2013/01/how-to-ntfs-compress-windows-winsxs.html

SCOM 2012 : Erreur « PSRemotingTransportException Job Failure » lors de l’utilisation de sessions powershell distantes

Certains contextes peuvent nécessiter l’utilisation de cmdlet SCOM depuis un ordinateur ne permettant pas l’installation de la console, et donc ne permettant pas d’exécuter ces cmdlet localement ; par exemple en cas de centralisation des scripts de l’entreprise sur un serveur Windows 2003.

Dans ce cas, une des solutions les plus évidentes est le recours aux Remote Sessions Powershell : les cmdlet sont bien appelés par le serveur ne bénéficiant pas de la console SCOM, mais ils sont en réalité exécutés par un serveur où elle est cette fois installée.

Le but de ce billet n’est pas de détailler ce fonctionnement, qui n’a d’ailleurs rien de spécifique à SCOM ; mais ce dernier peut par contre être responsable de certains dysfonctionnements des Remote Sessions.

C’est notamment le cas lors de l’exécution de scripts nécessitant des traitements coûteux en mémoire, qui peuvent provoquer l’erreur suivante :

Processing data for a remote command failed with the following error message: The WSMan provider host process did not return a proper response.  A provider in the host process may have behaved improperly. For more information, see the about_Remote_Troubleshooting Help topic.

    + CategoryInfo          : OperationStopped: (System.Manageme…pressionSyncJob:PSInvokeExpressionSyncJob) [], PSRemotingTransportException

+ FullyQualifiedErrorId : JobFailure

Ce message, assez peu explicite, indique en réalité que la session powershell distante utilise trop de mémoire par rapport à ce qui est alloué : en effet, cette allocation est limitée par défaut à 150Mo, comme le confirme le Powershell suivant (à exécuter sur le serveur où se trouve la console SCOM) :

winrm get winrm/config

clip_image002

En partant de ce constant, deux solutions s’offrent à nous : optimiser le script pour qu’il utilise moins de mémoire, ou augmenter la mémoire allouée à chaque Remote Session Powershell.

Libre à vous de choisir la quantité de mémoire allouée qui vous semblera en adéquation avec les besoins de votre script, en gardant en tête qu’une valeur excessive peut entraîner la saturation du serveur et compromettre sa stabilité.

winrm set winrm/config/winrs `@`{MaxMemoryPerShellMB=`"1024`"`}

Le problème devrait désormais être corrigé.

SCOM 2012 : Alimenter un groupe depuis une source SQL

Imaginons une entreprise qui, pour ses besoins propres d’administration, détermine dans une base de données de référence (CMDB) des ensembles de serveurs sans lien apparent les uns avec les autres, et donc sans possibilité de créer une Discovery basée sur une clé de registre ou une requête WMI.

clip_image002

Le besoin de retrouver cette organisation logique dans SCOM pour positionner des overrides ou cibler des vues peut vite se faire sentir, et il semble alors évident d’intégrer ces serveurs dans un même groupe SCOM.

SCOM ne permet malheureusement pas par défaut d’utiliser une source externe pour peupler un groupe, il faudra donc en passer par la manipulation du code source XML du management pack contenant le groupe afin d’arriver à nos fins. Prêts ? Suivez le guide !

Exportez le management pack contenant le groupe à modifier, et ouvrez le fichier XML dans un éditeur de texte.

Partie 1 : Manifest

Ici, il est nécessaire d’incrémenter la version afin de pouvoir importer le management pack par la suite.

Il faut également s’assurer que les librairies Microsoft.Windows.Library et Microsoft.SystemCenter.InstanceGroup.Library sont référencées :

<ManagementPack ContentReadable="true" SchemaVersion="2.0" OriginalSchemaVersion="1.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<Manifest>

<Identity>

<ID>TEST</ID>

<Version>1.0.0.1</Version>

</Identity>

<Name>TEST</Name>

<References>

<Reference Alias="MicrosoftWindowsLibrary7585010">

<ID>Microsoft.Windows.Library</ID>

<Version>7.5.8501.0</Version>

<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>

</Reference>

<Reference Alias="MicrosoftSystemCenterInstanceGroupLibrary7585010">

<ID>Microsoft.SystemCenter.InstanceGroup.Library</ID>

<Version>7.5.8501.0</Version>

<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>

</Reference>

</References>

</Manifest>

Partie 2 : TypeDefinitions

Nous allons maintenant définir le groupe qui sera peuplé via la base SQL, ainsi que sa relation.

Pour le groupe, il n’y a rien de très spécial, il y a de fortes chances que votre MP contienne déjà une classe de ce type s’il contient déjà un groupe ; sinon rajoutez la ligne <ClassTypeID …. /> entre les balises <ClassTypes> </ClassTypes> et remplacez Test.Group par un ID correspondant à votre groupe.

Il est, par contre, plus probable qu’il vous faille rajouter la relation. Reprenez le bloc <RelationshipTypes> </RelationshipTypes> et modifiez les parties en rouge pour les adapter à votre contexte.

<TypeDefinitions>

<EntityTypes>

<ClassTypes>

<ClassType ID="Test.Group" Accessibility="Public" Abstract="false" Base="MicrosoftSystemCenterInstanceGroupLibrary7585010!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" Extension="false" />

</ClassTypes>

<RelationshipTypes>

<RelationshipType ID="GroupPopulation.TESTGroupContainsWindowsComputers" Accessibility="Internal" Abstract="false" Base="System!System.Containment">

<Source ID="Source" MinCardinality="0" MaxCardinality="2147483647" Type="Test.Group" />

<Target ID="Target" MinCardinality="0" MaxCardinality="2147483647" Type="MicrosoftWindowsLibrary7585010!Microsoft.Windows.Computer" />

</RelationshipType>

</RelationshipTypes>

</EntityTypes>

</TypeDefinitions>

Section 3: <Monitoring>

Cette section est normalement déjà présente dans votre management pack ; c’est elle qui contient les différents moniteurs et règles, en particulier celle qui nous intéresse ici : la règle de découverte liée à la classe du groupe.

C’est elle qu’il va vous falloir identifier (elle est reconnaissable à sa ligne <Discovery=…. Qui doit contenir la mention Target="TEST.Group"), puis modifier de façon à intégrer un script VBS qui se connectera au serveur SQL et récupérera la liste des serveurs à intégrer au groupe.

Attention : il est nécessaire que le compte SCOM ait accès à la base de données SQL de référence qui contient la liste de vos serveurs !
L’extrait ci-dessous montre l’ensemble de la Discovery que vous devez réutiliser à la place de votre actuelle, en surlignant les parties à adapter à votre contexte :

<Discovery ID="TEST.Group.DiscoveryRule" Enabled="true" Target="TEST.Group" ConfirmDelivery="false" Remotable="true" Priority="Normal">

<Category>Discovery</Category>

<DiscoveryTypes>

<DiscoveryClass TypeID="TEST.Group" />

</DiscoveryTypes>

<DataSource ID="DS" TypeID="MicrosoftWindowsLibrary7585010!Microsoft.Windows.TimedScript.DiscoveryProvider">

<IntervalSeconds>300</IntervalSeconds>

<SyncTime />

<ScriptName>TESTGroupDiscovery.vbs</ScriptName>

<Arguments>$MPElement$ $Target/Id$</Arguments>

<ScriptBody>Dim SourceId

Dim ManagedEntityId

Dim oAPI

Dim oDiscoveryData

Dim objConnection,objConnection2

Dim oRS,oRS2

Dim sConnectString,sConnectStringOPSMGR

SourceId = WScript.Arguments(0)

ManagedEntityId = WScript.Arguments(1)

Set oAPI = CreateObject("MOM.ScriptAPI")

Set oDiscoveryData = oAPI.CreateDiscoveryData(0,SourceId,ManagedEntityId)

sConnectString = "Driver={SQL Server}; Server=REFERENCESQLSERVER\INSTANCE; Database=REFERENCEDATABASE;"

sConnectStringOPSMGR = "Driver={SQL Server}; Server=SCOMSQLSERVER; Database=OperationsManager;"

Set objConnection = CreateObject("ADODB.Connection")

objConnection.Open sConnectString

Set objConnection2 = CreateObject("ADODB.Connection")

objConnection2.Open sConnectStringOPSMGR

Set oRS = CreateObject("ADODB.Recordset")

oRS.Open "SELECT ServerName FROM VServers ", objConnection

Set groupInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='TEST.Group']$")

While Not oRS.EOF

Set oRS2 = CreateObject("ADODB.Recordset")

oRS2.Open "SELECT DISTINCT Id,Path FROM [OperationsManager].[dbo].[ManagedEntityGenericView] WHERE FullName LIKE 'Microsoft.SystemCenter.HealthService:" + LTRIM(RTRIM(oRS.Fields("ServerName"))) + "%'",objConnection2

If Not oRS2.BOF Then

oRS2.MoveFirst

End If

If Not oRS2.EOF Then

Set serverInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='MicrosoftWindowsLibrary7585010!Microsoft.Windows.Computer']$")

serverInstance.AddProperty "$MPElement[Name='MicrosoftWindowsLibrary7585010!Microsoft.Windows.Computer']/PrincipalName$",oRS2.Fields("Path")

Set relationshipInstance = oDiscoveryData.CreateRelationshipInstance("$MPElement[Name='GroupPopulation.TESTGroupContainsWindowsComputers']$")

relationshipInstance.Source = groupInstance

relationshipInstance.Target = serverInstance

oDiscoveryData.AddInstance relationshipInstance

End If

oRS.MoveNext

Wend

objConnection.Close

objConnection2.Close

Call oAPI.Return(oDiscoveryData)

</ScriptBody>

<TimeoutSeconds>120</TimeoutSeconds>

</DataSource>

</Discovery>

Section 4: <LanguagePacks>

Il s’agit simplement ici de rajouter les DisplayString pour les classes nouvellement créées, par exemple :

<DisplayStrings>

<DisplayString ElementID="GroupPopulation.TESTGroupContainsWindowsComputers">

<Name>TEST_from_SQL</Name>

</DisplayString>

</DisplayStrings>

Il ne reste plus ensuite qu’à réimporter ce management pack, et au bout de quelques minutes votre groupe devrait être peuplé par les serveurs contenus dans votre table SQL (à condition bien sûr que ces serveurs soient déjà connus par SCOM, et donc qu’un agent soit déployé dessus !).

image