Question Joindre les membres issus de deux commandes

Quel pb rencontres-tu ?

Hé bien en fait j'avais vraiment besoin de comprendre comment fonctionnait les types génériques. Mais maintenant que tu me donnes la solution ça va sûrement aller mieux.

Tu parles de VB ou de PowerShell ?

Je parle de VB.NET. En fait je dois faire un service qui va tourner sur mon serveur Exchange et qui va, tous les jours, aller récupérer des statistiques concernant l'utilisation des boîtes mail.

Comme c'est très simple à récupérer avec PowerShell je m'oriente vers une solution qui consisterait à exécuter un script PowerShell depuis mon application (mon service) écrite en VB.NET, d'en récupérer les résultats et de les enregistrer dans une base de données. Ainsi je pourrai avoir des statistiques au jour le jour.

Donc au final je veux utiliser PowerShell pour me remonter les données sous la forme d'un objet exploitable avec VB.NET dans mon appli.

[code:1]

#Crée une hastable vide

$Dict = @{}

#Crée une entré non typé

$Dict.Clé=10

$Dict.Nom=Get-date

$Dict

$Dict.Clé

[/code:1]

Et justement il faut que je vérifie si les objets créés avec cette méthode que tu viens de me donner peuvent être exploités facilement en VB.NET.<br><br>Message édité par: Legabs, à: 1/07/08 18:11

Tu peux consulter ce post.

Merci, je vois maintenant comment récupérer proprement les objets retournés par les commandes Get-Mailbox ou Get-MailboxStatistics.

étudier les API PowerShell

Je ne vois pas trop ce que tu veux dire par là. Il existe un autre moyen d'utiliser PowerShell que d'écrire un script, qu'il soit lancé à partir d'une console ou directement d'une appli .NET ?

Je crois que je vais pas mal avancer aujourd'hui. On verra le résultat en fin de journée.<br><br>Message édité par: Legabs, à: 2/07/08 11:03

Je parlais de ceci

channel9.msdn.com/shows/The+DFO+Show/The...s-PowerShell-Part-1/

Oui, oui, j'avais bien vu et c'est d'ailleurs cette vidéo, mais aussi et surtout la Part-2 qui m'a aidé à faire ce qui suit.

Donc tout d'abord j'ai écrit ce petit script :

[code:1]
$mbs = Get-mailbox -Server myServer

$dict = @{}

foreach ($mb in $mbs) {
if ($mb.UserPrincipalName) {
if ($stats = Get-Mailboxstatistics -Identity $mb.UserPrincipalName) {
$dict.($mb.UserPrincipalName) = $stats
}
}
}

return $dict
[/code:1]

Il permet d'obtenir, pour chaque utilisateur (identifié par son UserPrincipalName (unique)) les statistiques de la boîte mail qui lui est affectée.

Et j'exploite ce script depuis un programme VB.NET :

[code:1]
Dim sr As StreamReader = New StreamReader(\&quot;..\\..\\script.ps1\&quot;«»)
Dim scriptText As String = sr.ReadToEnd()

Dim snapinException As PSSnapInException = Nothing
Dim EMSConfig As RunspaceConfiguration = RunspaceConfiguration.Create()
Dim info As PSSnapInInfo = EMSConfig.AddPSSnapIn(\&quot;Microsoft.Exchange.Management.PowerShell.Admin\&quot;, snapinException)
Dim runSpace As Runspace = RunspaceFactory.CreateRunspace(EMSConfig)

Dim resultsStats As New Collection(Of System.Management.Automation.PSObject)

Dim pipeStats As Pipeline = runSpace.CreatePipeline(scriptText)

resultsStats = pipeStats.Invoke()

Dim ht As Hashtable = CType(resultsStats.Item(0).BaseObject, Hashtable)

For Each dictEntry As DictionaryEntry In ht
Dim mbs As MailboxStatistics = CType(CType(dictEntry.Value, PSObject).BaseObject, MailboxStatistics)
WriteConsole(dictEntry.Key + \&quot; \&quot; + mbs.ItemCount.ToString() + \&quot; \&quot; + mbs.TotalItemSize.ToString(), ConsoleColor.Green)
Next
[/code:1]

L'intérêt c'est donc de ne se servir de PowerShell que pour aller chercher les données. Une fois ceci fait, on les manipule tranquillement avec .NET. C'est souple, c'est puissant, et c'est finalement assez simple.

Toutefois peut-être serait-il possible d'optimiser un peu le script. A savoir que pour l'instant je mets en gros 5 secondes pour aller récupérer les données de 65 boîtes.

Ce qui est embêtant (ce qui prend du temps) c'est la boucle foreach et le fait de devoir, à chaque fois, ré-exécuter une commande Get-MailboxStatistics je pense, mais pour tout dire je ne suis pas parvenu à faire autrement.

Le temps n'est pas une grosse contrainte puisque le programme .NET sera un service qui s'exécutera une fois par jour à heure fixe. Mais bon, autant essayer de faire le travail le plus propre possible...