Inventaire BlackBerry:

Toutes les informations de configuration de votre solution BES sont stockées dans la base SQL BESMGMT, vous trouverez donc entre autres toutes les informations concernant les mobiles BlackBerry. Pour cela trois tables sont intéressantes:

• UserConfig: Contient entre autres l’adresse Email de l’utilisateur (MailboxSMTPAddr).
• SyncDeviceMgmtSummary: Modèle du blackberry et version d’OS (ModelName et AppsVer).
• UserStats: Date du dernier Email reçu (LastFwdTime).

En utilisant SQL Management Studio vous pouvez naviguer dans les tables pour retrouver les informations utiles:

Il ne vous reste plus qu’à utiliser PowerShell pour vous connecter à la base SQL et récupérer les informations qui vous sont utiles. La clef commune entre les trois tables est la valeur ID. Nous ne prenons en compte que les BlackBerry ayant reçu un Email au cours des 60 derniers jours.

$days = 60
$dbServer = "SQLBES-SRV"
$db = "BESMgmt"
 
#If you use SA account to connect database, change pwd=XXXXXX!, or use Windows Authentication, see below
$connString = "Server=$dbServer;Database=$db;uid=sa;pwd=XXXXXX"
 
#If you use Windows Authentication to connect BESMGMT SQL Database, need setup the database
#$connString = "Server=$dbServer;Database=$db;Integrated Security=True"
 
#SQL Query to retrieve BB devices Info (only devices who recieved mail in the last $days)
$Query = "Select UserConfig.DisplayName,MailboxSMTPAddr,ModelName,LastFwdTime,AppsVer from UserConfig,SyncDeviceMgmtSummary,UserStats where UserConfig.ID=SyncDeviceMgmtSummary.UserConfigID AND UserConfig.ID=UserStats.UserConfigID AND DeviceType <> 0 AND ModelName <> '' AND DateDiff(dd,LastFwdTime,GETDATE()) < "+$days
 
#Connect to Database, run Query, Disconnect
 
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = $connString
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $Query
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
$bbs = $DataSet.Tables[0]

Si vous voulez plus d’exemples de requêtes SQL sur BES vous pouvez lire ce post ou bien ce forum qui nécessite l’utilisation des Cmdlets SQL 2008. Le script ci dessus fait appel directement au Namespace System.Data.SqlClient et ne nécessite que PowerShell v2.

Il ne vous reste plus qu’à parcourir $bbs pour avoir les informations sur vos clients BlackBerry.

Inventaire ActiveSync:

En ce qui concerne l’inventaire de vos autres mobiles se connectant via ActiveSync c’est plus simple, car l’information est stockée dans Active Directory. En effet comme l’indique Florian’s blog ces données sont un sous objet de votre compte utilisateur: Pour vous en convaincre, ouvrez une console dsa.msc:

Grâce à l’Exchange Management Shell (2007 et 2010), le cmdlet Get-ActiveSyncDeviceStatistics permet de fournir très facilement des statistiques sur vos mobiles utilisant ActiveSync: Pour des exemples lire ce post de Ben Lye sur le sujet. Les valeurs suivantes sont particulièrement intéressantes:

• DeviceType: Le type de mobile (ex: Iphone, WP, Android…)
• DeviceModel: Le modèle de mobile (ex: HTC, LG, Samsung, Iphone…)
• DeviceUserAgent: Figure la build de l’OS (Iphone, WP, Android…)
• LastSuccessSync: Dernière synchronisation ActiveSync réussie, nous filtrons tout comme les BlackBerry, les mobiles ayant répondu au cours des 60 derniers jours.

Nous retrouvons donc à peu près les mêmes informations que celles obtenues sur les BlackBerry via notre requête SQL.

Fonctionnement général du script:

Nous commençons donc par faire un inventaire BlackBerry en requêtant la base SQL BESMGMT. Pour chaque adresse Email MailboxSMTPAddr nous vérifions si il possède aussi un mobile utilisant le protocole ActiveSync (et oui quand on est vraiment VIP on a un BlackBerry et un Ipad ), ceci via la commande:

$acts = Get-ActiveSyncDeviceStatistics -Mailbox $bb.MailboxSMTPAddr
 
if (($acts | Measure-object).count -eq 0) {User has just one BB no ActiveSync device}
 
else {User has one ActiveSync device in addition to BB}

Une fois l’inventaire BlackBerry terminé nous chargeons l’ensemble des boites aux lettres utilisateur Exchange via la commande:

$Mailboxes = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited

Puis nous comparons leur PrimarySmtpAddress (récupéré via le cmdlet Get-Mailbox) avec les MailboxSMTPAddr ($BESsmtpArray) afin d’exclure les utilisateurs déjà traités dans l’inventaire BlackBerry. Pour ces utilisateurs restants nous vérifions si ils possèdent un mobile utilisant ActiveSync.

Le résultat sort sous la forme d’un fichier CSV avec les informations suivantes:

• Adresse Email de l’utilisateur.
• Nombre de mobiles (ActiveSync + BlackBerry).
• Type de mobile: BlackBerry, IPhone, WP, Android…
• Modèle du mobile: Modèle de BlackBerry, Samsung, HTC, LG…
• Version d’OS.
• Dernière connexion: Dernier Email reçu sur BlackBerry, dernière synchronisation ActiveSync.

Voici un exemple de résultat obtenu:

Il vous faudra modifier les paramètres suivants dans le script et le lancer à partir de l’Exchange Management Shell:

• $days: Si vous souhaitez alonger ou réduire le seuil d’inactivité (60 jours par défaut).
• $dbServer: Nom de votre serveur SQL BES.
• La variable $connString: Selon le type d’authentification à la base SQL que vous utilisez.

Pour télécharger le script complet, c’est ici:

PS: Le script n’a été testé que sous Exchange 2010 et BES 5.02, merci de vos retours sur les autres versions. A valider sous Exchange 2007, le cmdlet utilisé étant le même.

Nous allons parler DNS (dnsmgmt.msc), GPOs (rsop.msc et gpmc.msc) et finalement utilisateurs et ordinateurs AD (dsa.msc) et voir quels problèmes nous avons pu rencontrer lors de l’utilisation de ces consoles, que ce soit sous AD 2000/2003 et AD 2008.

DNS

• Vous ne pouvez pas gérer de serveurs DNS Windows 2008R2 avec une console d’administration DNS (dnsmgmt.msc) sous Windows 2003/XP et versions inférieures, car le niveau de sécurité a été augmenté au niveau RPC, pour plus de détails vous pouvez lire cette KB. La version 2003/XP de dnscmd.exe n’est pas compatible non plus: Attention lors de vos migrations de DCs vers 2008R2, vos anciens scripts utilisant la version 2003/XP de dnscmd.exe seront à mettre à jour.

• L’effacement de glue records fait freezer la console dnsmgmt.msc sous Windows 2008R2, il vous faudra faire cette manipulation avec dnscmd.exe.

GPOs

• Les paramètres de préférences de stratégies de groupe (GPP) n’apparaissent pas quand vous faites un rsop.msc sur une machine cliente: Par contre, si vous utilisez la GPMC pour obtenir les paramètres de GPOs appliqués à une machine vous aurez cette information. Pour cela utiliser le Group Policy Results Wizard:

• Vous ne pouvez pas installer la console gpmc.msc sur Windows 2003 x64, pour y arriver il vous faut modifier le package MSI avec un éditeur comme Orca. Les scripts vbs pour manipuler les GPOs ne fonctionneront pas (si quelqu’un a un solution ?), l’appel CreateObject(“GPMGMT.GPM”) vous retournera l’erreur:

Microsoft VBScript runtime error: ActiveX component can’t create object: ‘GPMGMT.GPM’

L’enregistrement de la DLL gpmgmt.dll ne résout pas le problème.

Utilisateurs et ordinateurs AD (ADUC ou DSA.MSC)

Lorsque vous utilisez la console dsa.msc avec les RSAT vous avez l’onglet attribute editor qui vous permet de vous séparer de votre console adsiedit.msc:

• Si vous gérez un AD 2000/2003 avec les RSAT vous ne verrez pas l’onglet attribute editor apparaitre sans réaliser cette manipulation.

 

• Sous AD 2008 cet onglet apparait dans l’ADUC, mais lorsque vous éditez un objet suite à une recherche, cet onglet n’est pas disponible. Par contre si vous utilisez la console ADAC (disponible nativement sous 2008R2), cet onglet apparaît bien dans la section “Extensions” quand vous faites une recherche sur un objet.

Malgré ces quelques comportements bizarres on continue a se servir de nos MMC qui nous facilitent bien la vie, sinon on aurait plus que du Windows Server Core , ce qui nous ferait gagner un peu de stockage… (voir chapitre Less disk space required)

Nous allons considérer que le SP1 de Windows Vista n’est plus supporté, car le support MS se termine le  12 juillet 2011. Dans un premier temps nous allons donc inventorier avec Powershell les machines qui ne peuvent plus recevoir des patchs de sécurité du fait de leur obsolescence, ceci en s’inspirant de cet article de AskDS.

$base = 'OU=Servers,DC=ldap389,DC=info'
$d = [DateTime]::Today.AddDays(-30)
 
$computers = Get-ADComputer -Filter 'PasswordLastSet -ge $d' -Searchbase $base -Properties OperatingSystemVersion,OperatingSystemServicePack,dNSHostName,OperatingSystem
 
foreach($computer in $computers) {
 
if (($computer.OperatingSystemVersion -lt "5.1") -or (($computer.OperatingSystemVersion -like "5.1*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 3")) -or (($computer.OperatingSystemVersion -like "5.2*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 2")) -or (($computer.OperatingSystemVersion -like "6.0*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 2")))
{$computer.Name + ';' + $computer.OperatingSystem + ';' + $computer.OperatingSystemServicePack  | Out-file NOK-OSVersion.csv -append}
}

Nous cherchons donc les machines actives, i.e. qui ont renouvelé leur mot de passe avec un DC au cours des 30 derniers jours, situées dans l’OU “Servers” et dont la version d’OS et de Service Pack n’est plus supportée par Microsoft. Ces machines listés dans le fichier NOK-OSVersion.csv ne peuvent plus recevoir des mises à jour de sécurité via WSUS, il faudra les mettre à jour.

Nous allons dans un second temps chercher les machines qui sont éligibles à recevoir des mises à jour mais qui ne remontent pas dans votre serveur WSUS. Il existe alors un problème au niveau du client WSUS de la machine où celui ci n’est pas configuré et elles téléchargent directement les patchs de sécurité sur Internet, ce qui n’est pas conseillé dans un environnement d’entreprise, car vous n’avez aucun contrôle quant à leur déploiement.

A partir de WSUS 3.0 SP2 il est possible d’utiliser PowerShell pour gérer vos mises à jour comme nous montre ce tutoriel de Boe Prox, ceci à l’aide du Namespace Microsoft.UpdateServices.Administration. Nous allons donc lister toutes les machines contenues dans nos groupes WSUS (sauf le groupe All Computers qui est un groupe qui contient au fait tous les groupes) et les comparer aux ordinateurs issus de notre requête faite sur l’annuaire Active Directory ($computer):

$wsusserver = "WSUS-server"
 
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($wsusserver,$False)
$groups = $wsus.GetComputerTargetGroups()
 
foreach($group in $groups) {
if ($group.Name -ne "All Computers"){
($wsus.getcomputertargetgroup($group.Id)).GetComputerTargets() |%{if ($_.FullDomainName -eq $computer.dNSHostName){ ....}}
}
}

Le FQDN de la machine est la clef commune entre l’objet ordinateur sous WSUS (attribut FullDomainName) et celui sous Active Directory (attribut DNSHostName). Les objets dont le matching est trouvé seront inscrits dans un fichier $file portant le nom du groupe WSUS auxquels ils appartiennent. Les ordinateurs pour lesquels il n’y a pas de matching, qui donc ne sont pas remontés sur votre serveur WSUS, sont indiqués dans un fichier NOK-wsus.csv. Pour ces derniers il faudra donc voir si vous les avez configurés pour pointer sur votre serveur WSUS, ou si le client WSUS a un problème.

Pour télécharger le script complet c’est ici:

Il vous faudra modifier les variables suivantes:

• $wsusserver: Nom de votre serveur WSUS.
• $base: DistingushedName de la base de vôtre recherche sur l’annuaire AD.

Le but de notre script va être d’analyser la réplication entrante de chacun de nos DCs grâce à la commande “repadmin /replsum /bydest” puis d’analyser son contenu. Dans le cas où vous avez des RODC dans vôtre infrastructure ils apparaitront dans le résultat de la commande, contrairement au commutateur /bysrc, pour plus de détails lire ce post. Si pour un DC donné la valeur “largest delta” dépasse un seuil à définir ou que des échecs de réplication sont constatés, alors nous analyserons l’attribut msDS-ReplAllInboundNeighbors de l’objet RootDSE de ce contrôleur de domaine. Nous pourrons ainsi avoir le détail du partenaire de réplication qui pose problème et le “Naming Context” qui n’a pas bien répliqué. Il est aussi possible d’obtenir cette information avec la commande “replsum /showrepl %dc_name% /csv“, mais l’information contenue dans l’attribut msDS-ReplAllInboundNeighbors est au format XML et est donc aussi sympathique à manipuler via script.

Il existe déjà sur la toile un script qui fait à peu près la même chose et utilise la commande “repadmin.exe /showrepl * /csv”, vous pouvez le trouver sur le blog Technodrone, je propose dans ce post une autre méthode et une présentation des résultats différente.

Dans un premier temps nous allons donc analyser les informations renvoyées par notre commande repadmin et parser les résultats à l’aide des expressions régulières. Voici le résultat d’une commande “repadmin /replsum /bydest”.

Dans le résultat de cette commande seules les valeurs de “Destination DSA” (<DC>), “largest delta” (<Delta>) et “fails” (<fail>) qui est un nombre composé de deux chiffres nous intéresse. L’expression régulière qui va nous permettre de parser ces valeurs est donc:

[regex]$regex = '\s+(?<DC>\S+)\s+(?<Delta>\S+)\s+(?<fail>\d{1,2}\s)'

Dans le cas où un DC est non joignable une erreur nous est renvoyée à la dernière ligne, l’expression régulière qui va nous permettre de trouver nos données est:

[regex]$regex2 = '\s+(?<FAIL>\d{1,2}\S+)\s\-\s+(?<DC>\S+)'

Nous reste ensuite à parcourir le résultat de notre commande est utiliser $matches pour extraire l’information désirée. Pour un exemple détaillé de cette méthode vous pouvez lire cet article qui traite le cas de la commande “route print” ou bien celui ci qui traite la commande “netstat”.

Le code utilisé pour récupérer nos informations est donc le suivant:

$repadmin = repadmin /replsum /bydest
$repadmin | ForEach-Object {
 
if ( $_ -match $regex ) {
$process = "" | Select-Object DC, Delta, fail
$process.dc = $matches.dc
$process.Delta = $matches.Delta
$process.fail = [int]($matches.fail)
$process
}
 
Elseif ( $_ -match $regex2 ) {
$process2 = "" | Select-Object DC,fail
$process2.fail = $matches.fail
$process2.DC = $matches.DC
$process2
}
}

Le résultat retourné par “largest delta” est au format XXd:XXh:XXm:XXs il nous suffit donc de parser ce résultat et d’utiliser le cmdlet New-Timespan pour avoir le résultat en minutes. Si cette valeur excède un seuil en minutes à définir ou que le nombre d’échecs est supérieur à 0 ($process.fail) alors l’attribut msDS-ReplAllInboundNeighbors du DC concerné est lu.

La méthode utilisée est la même que celle décrite sur le blog Active Directory Powershell pour lire l’attribut ms-DS-Repl-AttributeMetaData qui est aussi au format XML. Afin de pouvoir lire l’attribut msDS-ReplAllInboundNeighbors de l’objet RootDSE sur tous les DCs de votre forêt via Powershell il faut que Active Directory Web Services (inclus dans 2008R2) soit installé sur ceux ci.

Voici donc le resultat obtenu lorsque l’on lance le script repl-status.ps1 la valeur $LargestDeltaTreshold exprimée en minutes est égale à 20:

Pour télécharger le script complet c’est ici:

Afin de voir quelle requête est lancée par la GPMC lors de la recherche d’un paramètre de GPO nous allons activer le mode verbose de log de la console. Réalisons maintenant une recherche de toutes les GPOs ayant le paramètre “redirection de dossiers” de configuré dans la partie utilisateur de la stratégie.

Puis nous allons consulter le fichier %TEMP%\gpmgmt.log afin de voir quelle opération a été tracée:

[VERBOSE] CGPMSearch::DumpCriteria(): Dumping 1 criteria ================
[VERBOSE] CGPMSearch::DumpCriteria(): Property: “gpoUserExtensions”
[VERBOSE] CGPMSearch::DumpCriteria():    Operation – Contains
[VERBOSE] CGPMSearch::DumpCriteria():     Value (string) “{25537BA6-77A8-11D2-9B6C-0000F8080861}“.
[VERBOSE] CGPMSearch::DumpCriteria(): End criteria dump ==================

Le filtre de recherche se fait via un simple attribut LDAP de l’objet de GPO situé dans le container “CN=System,CN=Policies,DC=%domain%“. Utilisons adsiedit.msc afin de voir plus en détails les attributs d’un objet de stratégie de groupes:

On remarque que l’attribut gPCUserExtensionNames est de la forme [%GUID1% %GUID2% ....], Le GUID est une valeur fixe qui correspond au type de critère recherché: {25537BA6-77A8-11D2-9B6C-0000F8080861} pour la redirection de dossiers dans la partie utilisateur de la GPO. Une GPO pouvant avoir plusieurs types de paramètres d’activés, par exemple “script de logon” et “redirection de dossiers”, les GUIDs sont mis simplement les uns à la suite des autres dans cet attribut.

Pour la partie des paramètres ordinateur de la GPO c’est le même principe sauf qu’il s’agit de l’attribut gPCMachineExtensionNames de la GPO. Il nous reste donc à inventorier les différents GUID correspondant aux paramètres de GPOs proposés dans la liste déroulante en effectuant une recherche via la GPMC et en analysant le fichier de log. Vu le nombre de paramètres de recherche possibles, 30 pour la configuration utilisateur et 35 pour la configuration ordinateur, les résultats sont disponibles dans ce fichier Excel à télécharger:

En Powershell il nous suffit de faire une simple recherche avec Get-ADObject pour rechercher les GPOs contenant une redirection de dossiers, le filtre recherche les objets de type GPO (ObjectClass=GroupPolicyContainer) et ayant l’attribut gPCUserExtensionNames qui contient le GUID correspondant à la redirection de dossiers:

$ObjGPOs = Get-ADObject -Filter {(ObjectClass -eq "groupPolicyContainer") -and (gPCUserExtensionNames -like *{25537BA6-77A8-11D2-9B6C-0000F8080861}*)}

Si le résultat retourné par $ObjGPOs n’est pas nul, nous pouvons grâce au CmdLet Get-GPOReport (ne pas oublier d’importer le module Grouppolicy)  exporter le rapport des GPOs trouvées au format HTML, pour cela nous avons besoin d’entrer en paramètre de la commande (-guid) le GUID de la GPO, mais sans les caractères “{}”:

Import-Module GroupPolicy;
if ($ObjGPOs -ne $Null) {
foreach($ObjGPO in $ObjGPOs)
    {      $guid = [System.Text.RegularExpressions.Regex]::Replace($ObjGPO.Name,"[{}]","")
    $pathtosavef = "C:\export\" +  (get-GPO -guid $guid).DisplayName + ".html"
    get-GPOReport -guid $guid -ReportType html -Path $pathtosavef
    }
}

L’exemple ci dessus exporte les rapports de GPO au format %Nom_GPO%.html dans le dossier c:\export. Nous allons donc faire un script qui demande si nous recherchons un configuration ordinateur ou utilisateur puis le type de paramètre de GPO à chercher, nous lançons donc le script search_GPO_2008.ps1 avec comme paramètre optionnel -report qui indique le chemin de destination des fichiers html:

Dans l’exemple ci dessus nous recherchons une GPO ordinateur pour lequel un paramètre de service est configuré à travers les préférences de stratégie de groupe , nous indiquons donc 2 puis 20. Si vous n’indiquez pas de paramètre -report, aucun rapport html n’est généré mais les informations sur le nom de la GPO, son GUID et sa date de création sont tout de même affichés.Pour télécharger le script c’est ici:

Pour ceux qui ne sont pas encore sous Active Directory 2008, voici un script équivalent pour la version 2003, réalisé à l’aide des Quest AD Cmdlets, la fonction d’export au format HTML n’est pas disponible car il n’y a pas (à ce jour), de CmdLets pouvant réaliser cette opération. Ci dessous le lien pour télécharger search_GPO_2003.ps1:

Le principe de fonctionnement est le même:

Vous pouvez adapter le script search_GPO_2008.ps1 afin de faire d’autres types de manipulations sur les GPOs issues de vôtre filtre de recherche, par exemple les sauvegarder dans un dossier particulier avec le CmdLet Backup-GPO etc…

Pour pouvoir enregistrer les modifications dans le journal de sécurité de chaque DC vous devez opter pour des solutions payantes type Snare et/ou Kiwi, ou bien mettre en place un système maison pour effectuer de la surveillance de journaux d’événements sur plusieurs DCs en utilisant la redirection de ceux ci sous 2008, vous pouvez aussi voir si on peut surveiller ce journal de sécurité par un script, mais cela risque de trop solliciter votre DC.

Comme nous l’avons vu dans le post précédent l’attribut GPLink est audité par défaut. Nous allons voir la structure de cet attribut de chaque OU/Site/Domaine avec adsiedit.msc:

Il se présente de la forme [LDAP://CN={31F5F311-013D-11D2-125F-00D04F0E84F9},CN=Policies,CN=System,DC=ldap389,DC=info;0][LDAP://CN={31F5F311-0187-EFD2-345F-BED04F1284F9},CN=Policies,CN=System,DC=ldap389,DC=info;2], chaque GPO liée à l’objet est séparée des “[]“, chaque valeur possède deux parties: Le Distinguished Name de la GPO et comment celle ci est appliquée et liée à notre objet, se sont les chiffres de 0 à 3 indiqués après le “;”:

• 0: GPO avec lien activé, pas de mode appliqué (enforced)
• 1: GPO avec lien désactivé, pas de mode appliqué (enforced)
• 2: GPO avec lien activé, mode appliqué (enforced)
• 3: GPO avec lien désactivé, mode appliqué (enforced)

Vous pouvez lire toutes ces informations par script avec des requêtes LDAP comme montré sur cette page. Il nous faut maintenant lire dans le journal de sécurité de chaque DC les modifications de cet attribut GPLink:

Sous Windows 2003 vous n’êtes que notifié d’un changement de valeur de cet attribut, vous n’avez pas la valeur avant/après indiquée dans le journal de sécurité. L’ID 566 est généré dans le journal d’événements:

,

Nous n’avons donc d’indiqué que l’attribut GPLink a été modifié, le nom du compte ayant effectué la modification, sur quel DC, et le Distinguished Name de votre OU/Site/Domaine. A partir de cette dernière information, pour lire la nouvelle valeur il vous faut juste faire une requête LDAP sur le DC sur lequel la valeur a été modifiée. Pour lire l’ancienne valeur, il vous faut un site de LAG, ce type de DC à réplication retardée n’est pas supporté par Microsoft si l’on s’en sert dans le cadre d’un PRA, mais rien ne nous empêche de nous en servir afin de faire une requête LDAP qui nous donnera la valeur avant modification du GPLink. Restera ensuite à comparer la nouvelle valeur (prise sur le DC sur lequel la modification a eu lieu) à l’ancienne valeur (obtenue à partir du site de lag).

Sous Windows 2008 vous n’avez pas besoin de site de lag, nous pouvons directement à partir du journal de sécurité d’un DC avoir la valeur “avant” et “après” du GPLink. Pour cela il vous suffit d’activer l’audit AD sur vos DCs. Si nous filtrons le journal de sécurité sur l’ID 5136, nous pouvons avoir l’ancienne valeur (event de suppression de GPLink) et la nouvelle valeur (event de création de GPLink)

Si vous liez votre première GPO sur un objet alors la valeur avant sera nulle et la valeur après égale au nouveau GPLink. Inversement si vous supprimez le dernier lien sur un objet alors la valeur avant sera le GPLink et la valeur après sera nulle. Afin de gérer ce cas de figure sous 2003 c’est un peu plus complexe: Il faudra gérer les codes d’erreur de la requête LDAP, si vous créez le premier lien de GPO sur une OU, la requête LDAP pour obtenir la valeur de GPLink sur le DC sur lequel a été créé le lien fonctionnera, si vous interrogez la même valeur sur le DC de lag elle est à <not set>, donc la requête LDAP sortira en erreur, il faudra donc gérer ces différents cas de figure.

Vous devez donc selon la version d’OS de votre DC paramétrer l’agent SNARE pour enregistrer les événements 566 ou 5136 de votre journal de sécurité, vous pouvez bien entendu utiliser d’autres outils. Comme serveur collectant les informations nous utilisons Kiwi. A ce propos nous avons constaté que certaines valeurs ne remontaient pas avec un friendly name, c’était le cas pour le Distinguished Name de l’objet (OU,Site,domaine) sur lequel le GPLink était modifié, le nom remonté était son GUID au format chaine de caractère, afin de pouvoir retrouver l’objet utilisez cette fonction de conversion fournie par MS. On a noté d’ailleurs une erreur dans cette KB sur le nom de la fonction, l’avant dernière ligne est à remplacer par “ConvertStringGUIDToHexStringGUID = octetStr”.

Nous allons maintenant voir comment comparer les valeurs “avant/après” de GPLink afin de connaître les modifications de liens de GPOs. Comme déjà expliqué le lien d’une GPO sur une OU/Site/Domaine comporte deux parties, le DN de la GPO et une valeur indiquant l’état du lien. Voici donc les différents cas de figure possible.

• GPLink avant [DNGPO1;0][DNGPO2;3] et GPLink après [DNGPO1;0][DNGPO2;3][DNGPO3;2] alors un nouveau lien activé et appliqué vient d’être créé.
• GPLink avant [DNGPO1;0][DNGPO2;3] et GPLink après [DNGPO1;0] alors le lien de la GPO DNGPO2 vient d’être effacé sur notre OU/Site/Domaine.
• GPLink avant [DNGPO1;0][DNGPO2;3] et GPLink après [DNGPO1;1][DNGPO2;3] alors le lien de la GPO DNGPO1 a été désactivé (mais pas supprimé).
• GPLink avant [DNGPO1;0][DNGPO2;3] et GPLink après [DNGPO1;0][DNGPO2;2] alors le lien de la GPO DNGPO2 a été activé et est toujours appliqué.
• etc…

Nous allons pour effectuer nos comparaisons utiliser les dictionnary objects. Nous aurons donc deux dictionnaires à comparer, un avec les GPLinks avant et l’autre après. Les clefs de chaque dictionnaire seront les Distinguished Name de GPOs et les valeurs les chiffres de 0 à 3 indiquant le statut du lien de GPO. Voici comment créer vos deux dictionnaires:

'After modification GPLink dicitonnary
Set GPLinkdict = CreateObject("Scripting.Dictionary")
'Before modification GPLink dicitonnary
Set GPLinkdictLAG = CreateObject("Scripting.Dictionary")
 
'strGPLinkAfter is the GPLink value after modification, you retrieved it with the event log
'under Windows 2008 and with an LDAP request on the where DC the modification occurred under Windows 2003

if instr(strGPLinkAfter,"]") <> 0 then
OUModifiedGPLINK = split(strGPLinkAfter,"]")
For i = UBound(OUModifiedGPLINK) -1 to LBound(OUModifiedGPLINK) Step -1
GPOLinkstatus = split(OUModifiedGPLINK(i),";")
GPLinkdict.add GPOLinkstatus(0),GPOLinkstatus(1)
Next
End if
 
 
'strGPLinkBefore is the GPLink value before modification, you retrieved it with the event log
'under Windows 2008 and with an LDAP request on the LAG DC under Windows 2003

 
if instr(strGPLinkBefore,"]") <> 0 then
OUModifiedGPLINKLAG = split(strGPLinkBefore,"]")
For j = UBound(OUModifiedGPLINKLAG)-1 to LBound(OUModifiedGPLINKLAG) Step -1
GPOLinkstatusLAG = split(OUModifiedGPLINKLAG(j),";")
GPLinkdictLAG.add GPOLinkstatusLAG(0),GPOLinkstatusLAG(1)
Next
End if

Pour télécharger l’exemple de code c’est ici:

Maintenant nous allons parcourir le dictionnaire GPLinkdict contenant les clefs et valeurs après modification et les comparer aux clefs et valeurs de l’autre dictionnaire. Si nous voyons qu’une des clefs parcourue n’existe pas dans le dictionnaire GPLinkdictLAG (avant modification) alors un lien de GPO vient d’être créé. Si pour une clef identique la valeur a changé alors l’état du lien de GPO à changé, si l’on passe de 0 ou 2 à 1 ou 3 alors la GPO a été désactivée. Avec ce script nous allons pouvoir avoir la création de nouveau lien de GPO et la modification d’état d’un lien:

 
'The DC where the modification was recorded, retrieved with eventlog
dcsource = "DCSOURCENAME"
 
'OU/Site/Domain name where GPO Link was modified, retrieved with eventlog
OUName = "OUName"
 
'User who made the modication, retrieved with eventlog
Username = "UsernName"
 
For Each oGPLinkdict in GPLinkdict
	If Not GPLinkdictLAG.Exists(oGPLinkdict) Then
 
	Set objGPOd = GetObject(split(replace(oGPLinkdict,"LDAP://","LDAP://"&dcsource&"/"),"[")(1))
	DNobjGPOd = objGPOd.Get("DisplayName")
	Msgbox Username&" created a link on this object: "& OUName &"  / GPOName: "&DNobjGPOd & "  / Link Value: "&GPLinkdict.Item(oGPLinkdict)
 
	Else 
		If GPLinkdictLAG.Item(oGPLinkdict) <> GPLinkdict.Item(oGPLinkdict) then
 
			if (GPLinkdictLAG.Item(oGPLinkdict) = 0 OR GPLinkdictLAG.Item(oGPLinkdict) = 2) AND (GPLinkdict.Item(oGPLinkdict) =1 OR GPLinkdict.Item(oGPLinkdict) = 3) then
 
			Set objGPOd = GetObject(split(replace(oGPLinkdict,"LDAP://","LDAP://"&dcsource&"/"),"[")(1))
			DNobjGPOd = objGPOd.Get("DisplayName")
			Msgbox Username&" disabled a link on this object: "& OUName &"  / GPOName: "&DNobjGPOd & "  / Link Value Before: "&GPLinkdictLAG.Item(oGPLinkdict)&"  / Link Value After: "&GPLinkdict.Item(oGPLinkdict)
 
			Else
 
			Set objGPOd = GetObject(split(replace(oGPLinkdict,"LDAP://","LDAP://"&dcsource&"/"),"[")(1))
			DNobjGPOd = objGPOd.Get("DisplayName")
			Msgbox Username&" enabled a link on this object: "& OUName &"  / GPOName: "&DNobjGPOd & "  / Link Value Before: "&GPLinkdictLAG.Item(oGPLinkdict)&"  / Link Value After: "&GPLinkdict.Item(oGPLinkdict)
 
			End if
 
 
		End if 
	End if
Next

Pour télécharger l’exemple de code c’est ici:

Maintenant il ne nous reste plus qu’à identifier les liens de GPOs supprimés, pour cela nous allons parcourir le dictionnaire GPLinkdictLAG qui contient les valeurs avant modification et voir si une clef n’existe pas dans le dictionnaire GPLinkdict, si c’est le cas alors un lien de GPO a été supprimé.

'Enter LAGDC if you have one, it will be usefull only in this case : if a Link is deleted and the GPO is deleted from the domain as well in the same time
'In that case we can not retrieve GPO Display Name if we do not have lag site.
'If no lag site then LAGDC = ""
LAGDC = "LAGDCNAME"
 
For Each oGPLinkdictLAG in GPLinkdictLAG
  If Not GPLinkdict.Exists(oGPLinkdictLAG) Then
	err.clear
	Set objGPOd = GetObject(split(replace(oGPLinkdictLAG,"LDAP://","LDAP://"&dcsource&"/"),"[")(1))
	if err.number <> 0 then
		if LAGDC <> "" then
		Set objGPOd = GetObject(split(replace(oGPLinkdict,"LDAP://","LDAP://"&dcsource&"/"),"[")(1))
		DNobjGPOd = objGPOd.Get("DisplayName")
		Else
		DNobjGPOd = split(oGPLinkdictLAG,"[")(1)
	Else 
	DNobjGPOd = objGPOd.Get("DisplayName")
	End if
	Msgbox Username&" deleted a link on this object: "& OUName &"  / GPOName: "&DNobjGPOd & "  / Link Value was: "&GPLinkdictLAG.Item(oGPLinkdict)
  End if
Next

Pour télécharger l’exemple de code c’est ici:

Avec ce post et le précédent vous pouvez maintenant construire un outil de surveillance des modifications de GPOs sur votre domaine. Vous pouvez, en plus de générer des rapports, lancer une sauvegarde de la GPO modifié via les scripts fournis avec GPMC.

Lors de la création/suppression d’une GPO dans votre domaine le dossier \\domainname\sysvol\domainfqdn\Policies\{%GPO_GUID%} est créé ou effacé. Lors de la modification des paramètres ordinateur/utilisateur le fichier \\domainname\sysvol\domainfqdn\Policies\{%GPO_GUID%}\gpt.ini est modifié comme l’indique ce post. Le but de notre script est donc de notifier en presque temps réel les modifications sur ce dossier et fichier sur un DC.

Quels sont les avantages/inconvénients par rapport à la méthode de notification via le journal de sécurité?

• Inconvénients: Un seul DC est sollicité, une charge CPU/Mémoire est à prévoir pour ce serveur, de plus un site de LAG est à prévoir pour obtenir des informations sur la suppression de GPOs sous Windows 2003. Nous n’avons pas le nom de compte de la personne ayant effectué la modification. Nous sommes notifiés une fois la réplication du SYSVOL survenue sur le DC sur lequel tourne le script, nous n’avons donc pas une remontée des événements en temps réel qui sont enregistrés dans le journal de sécurité de chaque DC via l’audit de fichiers.
• Avantages: Afin d’avoir un enregistrement en temps réel des événements du journal de sécurité de chaque DC un logiciel payant de Syslog est necessaire (Kiwi et Snare par ex), ma méthode est gratuite. Un seul DC est sollicité et vous n’avez pas besoin d’activer l’audit du système de fichiers sur le SYSVOL de tous les DCs et d’y installer l’agent Snare, ce qui limite la charge CPU/Mémoire de l’ensemble des DCs.

Le but de cet article est de montrer comment installer sur un seul DC de votre domaine un service (script) qui détecte les changements de GPOs. Pour réaliser ce script nous allons utiliser WMI code creator pour monitorer les créations/effacements de dossiers {%GPO_GUID%} et modifications des fichiers {%GPO_GUID%}gpt.ini sur le SYSVOL.

Voici comment générer le script pour surveiller la création d’un dossier {%GPO_GUID%}:

Lors de l’étape 5 le nom des sous-dossier à surveiller sont dans le dossier ‘Win32_Directory.Name=”"F:\WINDOWS\SYSVOL\domain\Policies”"‘”, ce qui correspond à l’emplacement de tous les sous répertoires {%GPO_GUID%} du dossier incluant les politiques du SYSVOL.

Ce qui nous donne la requête WMI suivante:

Pour plus d’information concernant les requêtes asynchrones en WMI vous pouvez lire cet article. Nous pouvons avec ce type de requête enregistrer plusieurs événements accessibles via le WMI arrivant en même temps sur une machine. Avec le script suivant nous allons pouvoir enregistrer la création/suppression de dossiers {%GPO_GUID%} sur le SYSVOL:

On error resume next
strComputer = "."
DomainDN = "DC=ldap389,DC=info"
DomainDNSFQDN = "ldap389.info"
LAGDC = "LAG_DC"
BackupLocationTool = "G:\Tool"
Const ForAppending = 8
Set FSO = CreateObject("Scripting.FileSystemObject")
 
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
Set MySink = WScript.CreateObject( _
    "WbemScripting.SWbemSink","SINK_")
 
Set MySink2 = WScript.CreateObject( _
    "WbemScripting.SWbemSink","SINK2_")
 
objWMIservice.ExecNotificationQueryAsync MySink, _
    "SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE " & _
                    "TargetInstance ISA 'Win32_SubDirectory'" & _
                    " AND TargetInstance.GroupComponent = 'Win32_Directory.Name=""F:\\\\WINDOWS\\\\SYSVOL\\\\domain\\\\Policies""'"
 
objWMIservice.ExecNotificationQueryAsync MySink2, _
    "SELECT * FROM __InstanceDeletionEvent WITHIN 10 WHERE " & _
                    "TargetInstance ISA 'Win32_SubDirectory'" & _
                    " AND TargetInstance.GroupComponent = 'Win32_Directory.Name=""F:\\\\WINDOWS\\\\SYSVOL\\\\domain\\\\Policies""'"
 
While (True)
    Wscript.Sleep(1000)
Wend
 
Sub SINK_OnObjectReady(objObject, objAsyncContext)
	gpofullpath = objObject.TargetInstance.Properties_.item("PartComponent").value
	gpoid1 = split(lcase(gpofullpath),"policies\\")
	gpouid = replace(gpoid1(1),chr(34),"")
 
	strGPODN = "CN="&gpouid&",CN=Policies,CN=System,"&DomainDN
 
		Set objGPO = GetObject("LDAP://" & strGPODN)
		StrGPOName = objGPO.DisplayName
 
	Set df80 = FSO.OpenTextFile(BackupLocationTool&"\GPM-Modified.log",ForAppending)
	df80.writeline(now&";CREATED;"&gpouid&";"&StrGPOName)
	df80.close
End Sub
 
Sub SINK2_OnObjectReady(objObject, objAsyncContext)
    gpofullpath = objObject.TargetInstance.Properties_.item("PartComponent").value
StrGPOName = "N/A"
	gpoid1 = split(lcase(gpofullpath),"policies\\")
	gpouid = replace(gpoid1(1),chr(34),"")
		if LAGDC <> "" then
		strGPODN = "CN="&gpouid&",CN=Policies,CN=System,"&DomainDN
		err.clear
		Set objGPO = GetObject("LDAP://" &LAGDC&"/"&strGPODN)
		if err.number <> 0 then
		StrGPOName = "N/A"
		else
		StrGPOName = objGPO.DisplayName
		End if
		End if
	Set df80 = FSO.OpenTextFile(BackupLocationTool&"\GPM-Modified.log",ForAppending)
df80.writeline(now&";DELETED;"&gpouid&";"&StrGPOName)
df80.close
End Sub
 
Sub SINK_OnCompleted(objObject, objAsyncContext)
End Sub

Pour télécharger le script c’est ici:

Il faudra changer en début de script les valeurs suivantes:

• DomainDN = “DC=ldap389,DC=info”, le Distinguished Name de votre domaine.
• DomainDNSFQDN = “ldap389.info”, le FQDN de votre domaine.
• BackupLocationTool = “G:Tool”, Le dossier se trouvant votre script.
• LAGDC = “LAG_DC”, Si vous voulez le connaître le nom de la GPO supprimée et pas seulement son GUID, il vous faudra un site de LAG, le DC sur le LAG SITE va vous permettre de connaître le displayname de la GPO supprimée. Si vous n’avez pas de DC avec une replication retardée mettre LAGDC = “”

Il ne vous reste plus qu’a surveiller les fichiers GPT.INI modifiés sur la partition hébergeant le SYSVOL, pour cela utiliser le code suivant:

objWMIservice.ExecNotificationQueryAsync MySink3, _
    "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE " & _
                    "TargetInstance ISA 'CIM_DataFile'" & _
                    " AND TargetInstance.Drive = 'F:'" & _
                    " AND TargetInstance.Extension = 'ini'" & _
                    " AND TargetInstance.FileName = 'gpt'"
 
Sub SINK3_OnObjectReady(objObject, objAsyncContext)
 
if objObject.TargetInstance.Properties_.item("LastModified").value <> objObject.PreviousInstance.Properties_.item("LastModified").value then
	gpofullpath = objObject.TargetInstance.Properties_.item("Name").value
 
	if instr(gpofullpath,DomainDNSFQDN) = 0 then
 
		gpoid1 = split(lcase(gpofullpath),"policies\")
 
		gpoid2 = split(lcase(gpoid1(1)),"\gpt.ini")
		gpouid = gpoid2(0)
 
		strGPODN = "CN="&gpouid&",CN=Policies,CN=System,"&DomainDN
		Set objGPO = GetObject("LDAP://" & strGPODN)
		StrGPOName = objGPO.DisplayName
 
	End if
End if
 
End Sub

Pour télécharger c’est ici:

Si vous monitorez avec WMI les modifications d’un système de fichiers vous pouvez lire ce post des scripting guy’s. Nous avons donc maintenant notre script de monitoring des GPOs, ce script une fois adapté fonctionne si vous n’avez pas un SYSVOL trop conséquent.

Si vous avez beaucoup de GPOs dans votre domaine il se peut que vous soyez limité par les quotas WMI dans votre requête. L’erreur est du type wmi quota violation 0x8004106C ( pour les codes d’erreur WMI c’est ici). Sur notre SYSVOL nous avons plus de 3500 GPOs, le script WMI crashait au bout de quelques minutes, nous avons donc utilisé wbemtest.exe pour changer les valeurs de la super classe __ArbitratorConfiguration de la manière suivante: %Total = %PerUser de façon à lancer ce script en tant que service avec un compte dédié, sans limitations de quota utilisateur liées à WMI, seul un quota total est respecté. Attendez vous donc à avoir une charge CPU/Mémoire supplémentaire sur ce DC si vous avez un nombre conséquent d’objets de stratégie de groupe à surveiller. Graph CPU pour un Dual Core 2,5GHz surveillant 3500 GPOs:

Nous allons voir maintenant voir comment créer un service à partir d’un script VBS, pour cela lire cet article très bien expliqué. Voici ce que cela donne pour notre outil:

Ajoutez une dépendance au service WMI:

Et voila, votre service de surveillance du SYSVOL est en place.

Vous savez maintenant comment surveiller les principaux changements d’objets de stratégie de groupe au niveau GPT sur votre infrascture. L’objet du prochain post est le monitoring des liens de GPOs, ce qui veut dire sur quels containers s’appliquent vos GPOs, pour cela nous surveillerons l’attribut GPLink audité par défaut, au niveau unité d’organisation et site, sur votre AD . Voir le tableau suivant:

Une fois les changements de GPLinks sur une OU/site/domaine détectés, vous pourrez connaitre les modifications importantes de GPOs sur votre domaine:

• Création de GPO
• Suppression de GPO
• Modification de paramètre Ordinateur/Utilisateur de la GPO.
• Modification/suppression/création d’un lien de GPO.

La suite bientot.

On voit que le DC est particulièrement sollicité aux horaires de bureau, la piste d’une application utilisée par les postes clients nuisant aux performances du DC semble donc la plus plausible. Nous laçons donc une analyse avec SPA sur le DC impacté dont voici le résultat:

La requête SamEnumUsersInDomain nous prend 42% de CPU, l’IP des clients provoquant ces requêtes n’est malheureusement pas remontée de manière claire via l’outil, nous allons donc utiliser WireShark  pour analyser l’activité réseau de notre DC et identifier les clients:

Après un peu d’analyse des trames nous voyons que le protocole de communication Windows (MCPP) utilisé par ces requêtes est MS-SAMR, il nous suffit d’utiliser le filtre Wireshark correspondant (SAMR) pour identifier les clients. Après avoir envoyé la liste de ces derniers au service informatique du site impacté il s’est avéré que ce sont des portables avec le logiciel HP ProtectTools security manager installé. Celui ci a été retiré de la plupart des postes, car les SMART cards n’étaient pas utilisées, et le résultat a été immédiat sur la courbe CPU des DCs:

Afin de d’identifier sur la partie cliente le processus émettant via un protocole particulier vers une autre machine vous pouvez utiliser le logiciel TCPview ou bien CurrPorts que mon collègue de CTXBlog présente dans cet article.

Le problème concernant l’application HP ProtectTools a été discutée sur un des forums HP, la solution serait de passer le Sp41408 de l’application, cependant nous avons fait le choix de désinstaller cette application, car elle était inutile pour nous.

Cliquer sur l’icône ci dessous pour télécharger l’outil, si vous avez des demandes d’évolution ou des bugs constatés n’hesitez pas à me les faire parvenir, il s’agit d’une v1.0.

Une fois l’outil lancé, entrez le nom du poste distant:

Puis le login utilisateur au format domainelogin:

Une fenêtre composée de cinq onglets s’affiche:

General info:

Cet onglet est découpé en deux sections, la première n’a rien d’extraordinaire, se sont des requêtes WMI de base:

La seconde “Network info” est plus intéressante: Si nous parcourons la classe WMI Win32_NetworkAdapterConfiguration sur un serveur possédant des cartes en Teaming, ou bien sur un portable alors un nombre élevé de cartes nous est retourné, alors que l’information de seulement une voir deux cartes réseau nous intéresse généralement. Un post des scripting guys m’a donné la solution: Il nous faut filter tout d’abord les cartes réseau qui sont connectées à un réseau via la valeur “NetConnectionStatus” de la classe WMI Win32_NetworkAdapter, puis énumérer les informations de Win32_NetworkAdapterConfiguration pour les cartes qui ont une IP d’activée (valeur IPEnabled). La valeur commune entre ses deux classes est “caption”. Ce qui nous donne les deux requêtes suivantes que vous retrouverez dans le code du fichier HTA.

1
2
3
4
5
6
7
8

Set colItems = objWMIService.ExecQuery("SELECT caption FROM Win32_NetworkAdapter WHERE NetConnectionStatus = 2")
For Each objItem in colItems
caption1 = objItem.caption
Set colNicConfigs = objWMIService.ExecQuery("SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True AND caption = '"&caption1&"'")
For Each objNicConfig In colNicConfigs
'Retrieve IP adress, DNS servers....
Next
Next

Passons aux informations du second onglet.

Printers:

Pour cet onglet nous utilisons toujours WMI pour lister les imprimantes, le nom de driver est indiqué ainsi que le type: Imprimante réseau ou locale. L’imprimante par défaut est surlignée en bleu.

Afin de déterminer si il s’agit d’une imprimante réseau ou locale voir un autre post des scripting guys, l’outil est compatible avec Windows2000 et versions d’après, en utilisant la méthodologie mentionnée dans le lien. Malgré tout il a été constaté que parfois les imprimantes réseau ne sont pas remontées par une requête WMI à distance, dans ce cas nous nous basons sur la clef de registre HKCU\Printers\Connections (HKUSERS\%SID_Utilisateur%\Printers\Connections), l’imprimante par défaut ne peut alors être découverte, ni le driver. L’impossibilité d’énumérer les imprimantes réseau à distance est lié au fait que votre compte n’a pas les droits de lecture pour interroger ce “namespace” WMI car elles sont déclarées au niveau utilisateur, il faudrait alors exécuter notre script avec les credentials de l’utilisateur connecté, pour faire cela via WMI voir cet article.

Active Directory:

La première information indique le DC de logon utilisé par la session de l’utilisateur distant. Puis le résultat d’un RSOP est affiché, nous avons listé les GPO appliquées sur la partie ordinateur, puis utilisateur:

La classe WMI rootrsopcomputer est utilisée pour obtenir la configuration ordinateur des GPOs, pour la configuration utilisateur c’est un peu moins évident. En effet il faut faire appel à la classe root\rsop\user\%SID_Utilisateur% mais il faut remplacer les “-” de votre SID par des “_”. Ce qui donne le code suivant:

1
2
3
4
5
6
7
8
9
10
11
12

Set objAccount = objWMIService.Get("Win32_UserAccount.Name='"&usser&"',Domain='"&domaine&"'")
SID=replace(objAccount.SID,"-","_")
Set objWMIGPO = GetObject("winmgmts:" & strComputer & "root\rsop\user"&SID)
 
Set colGPO = objWMIGPO.ExecQuery("Select * from RSOP_GPO")
 
For Each objGPO in colGPO
version = hex(objGPO.Version)
version = right(version,4)
version = CLng("&H" & version)
'Collect other information
Next

Comme vous pouvez le voir ci dessus la version de la GPO n’est aussi pas évidente à obtenir car il s’agit d’une combinaison de la version GPT et du GPC, dans notre script nous nous basons sur le GPC. Pour plus d’informations sur la classe root\rsop c’est ici.

Hotfixes:

Sur cet onglet nous indiquons si Windows Update est activé et si un serveur WSUS est utilisé pour les mise à jour, toutes ces informations sont accessibles via le registre, la liste des KB est récupérée via WMI.

Citrix:

Nous avons la version du client ICA installée, voir cette vieille CTX pour la méthode. Puis l’URL du PN Agent est indiquée si celle ci est configurée.