Question pb : runspacepool et wmi connectserver

Bonjour,

Veuillez m'excuser pour mon manque de considération.

J'utilise le script suivant :
mspowershell.blogspot.fr/2013/01/executi...-in-parallel-in.html
J'ai modifié le scriptblock pour l'adapter à mon besoin qui est : lancer un process sur plusieurs milliers de machines XP SP3 distantes en workgroup ( pas de domaine ) en fournissant un compte et un mot de passe différent pour chaque machine.
Je n'ai trouvé que WMI pour faire cela. Du code VBS adapté.
Le runspacepool permet de lancer des \"thread\" ( des vrais ou des faux je ne sais pas ) en parallèle. Si je dois faire les connexions WMI l'une après l'autre il me faut la semaine. Avec mon portable 4Go de ram, je lance des \"net use ip user mdp/copy\" vers 2000 machines en moins de 2 heures avec 200 threads en parallèle en utilisant le script cité.
Tout va bien donc.
Sauf que dans le cas où je remplace les \"net use\" par des connectserver et createprocess de wmi, si je dépasse 20 threads en parallèle, alors le PS se plante.
La partie wmi du scriptblock des threads:
[code:1]$cmd='c:\winnt\system32\cmd.exe /c c:\test.cmd'
$locator = New-Object -ComObject \"WbemScripting.SWbemLocator\"
$oRemoteWmi = $locator.ConnectServer($computer,\"root\cimv2\",$user,$mdp)
$oRemoteClassProcess=$oRemoteWmi.Get(\"Win32_Process\"«»)
$oPS=$oRemoteWmi.Get(\"Win32_ProcessStartup\"«»)
$oMethodeCreate=$oRemoteClassProcess.Methods_|?{$_.name -eq 'create'}
$oInParam=$oMethodeCreate.inParameters.SpawnInstance_()
($oInParam.Properties_ | where {$_.name -eq \"CommandLine\"}).Value = $cmd
($oInParam.Properties_ | where {$_.name -eq \"CurrentDirectory\"}).Value = \"c:\\"
($oInParam.Properties_ | where {$_.name -eq \"ProcessStartupInformation\"}).Value = $oPS
$outParam = $oRemoteClassProcess.ExecMethod_(\"Create\", $oInParam)
#lecture code du pid
$remotePid = ($outParam.Properties_ | ?{$_.name -eq \"ProcessId\"}).Value
Write-Host \"remotePid = $remotePid\"[/code:1]
Ce qui manque à ce bout de code, c'est le passage des paramètres qui ne sert pas au problème. Le \"main\" lit un fichier contenant \"ip,user,mdp\" des machines distantes.

Ma question : avez vous une idée de l'origine du plantage dans le contexte wmi si $trottlelimit du runspacepool est plus grand que 30 pour un ensemble de 2000 machines?
Et pourquoi tout marche bien avec les connexions (\"net use \\ip\c$\" puis copy \\ip\c$\toto.txt c:\toto.txt\" puis \"net use \\ip /d\") avec $trottlelimit = 200 pour un ensemble de 2000 machines?

Au passage pourquoi 200? parce que la charge cpu est importante mais il y encore de la marge sur mon pc pour que je puis travailler.
Attention : si vous faites le test avec beaucoup de machines et avec un routeur sur un réseau \"naté\", selon la configuration de votre routeur, il se peut qu'il ne reste plus de ports pour sortir pour les autres usagers.

Il paraît qu'avec \"foreach -parallele\" de PS V3 je pourrais faire mieux comme administration distante. Mais il me semble que la phase connexion de \"winrm\" est très très lente en comparaison à celle de WMI qui est déjà bien plus longue que celle d'un agent comme \"vnc\" indisponible pour moi.

J'ai éliminé la piste des job car trop lents et trop \"complexes\" à gérer. Voir learn-powershell.net/2012/05/13/using-ba...-better-performance/

Et aujourd'hui, j'ai fait un test rapide, mais sans tout vérifier malheureusement, avec la modification suivante lors de la création du pool :
[code:1]$sessionState = [system.management.automation.runspaces.initialsessionstate]::CreateDefault()
$runspacePool = [runspacefactory]::CreateRunspacePool(1, $throttleLimit, $sessionState, $host)
$runspacePool.ApartmentState = \"STA\"
$runspacePool.Open()[/code:1]
Ca ressemble à une recette de cuisine que j'ai trouvé ici : newsqlblog.com/2012/05/22/concurrency-in...ding-with-runspaces/

Si quelqu'un peut m'en dire plus sur, d'une part le rôle de ce paramètre et, d'autre part sur le lien avec le plantage avec les requêtes WMI connectserver...

Je sais que l'on est à la frontière de la programmation et du scripting avec ce genre de chose comme les runspacepool. Pourtant, c'est spectaculaire de rapidité.
Au fait il y a plein d'autres trucs pour accélérer son script comme dit sur

La présentation dit :

In this webcast, MVP Dr. Tobias Weltner illustrates how you can spawn lightweight threads to execute multiple things at the same time. Unlike background jobs, this technique uses fewer resources and allows threads to communicate with each other, which not only enables you to considerably speed up scripts, but also enables you to open multiple GUI windows and keep them open while other PowerShell threads update the window content.

Comme je ne comprends que la moitié de ce je lis et rien de ce que j'entends, si une âme charitable veut bien me faire un résumé des astuces...ou le déposer sur ce site...

Merci d'avance.
Noël

Ps : toutes mes excuses à ceux qui ont répondu à mes questions précédentes ( en 2012 ) et à qui, en retour, je n'ai pu répondre...

Message édité par: noel, à: 28/08/13 22:40<br><br>Message édité par: noel, à: 28/08/13 22:43

Bonjour,

Une mise en page de ton post s'impose, notamment si tu souhaites qu'une personne bienveillante un jour te réponde.

A faire :

Clique sur le lien \&quot;Editer\&quot; pour éditer ton message puis, pour chaque partie de code, surligne la et clique sur le bouton \&quot;Code\&quot;. Enregistre enfin ton message.

Aussi, pour chaque partie qui est un extrait ou une citation, tu peux utiliser le bouton \&quot;Quote\&quot;.

Pour le moment et en ce qui me concerne, j'ai du mal à lire ton message et à aller jusqu'au bout.

@ +

Matthew BETTON<br><br>Message édité par: Matthew BETTON, à: 28/08/13 12:17

Bonjour,
Aujourd'hui j'ai pu faire le test sur 7800 machines distantes XPSP3. Avec le paramètre STA, j'ai pu copier un script sur ces 7800 machines et le lancer en 5h30 avec trottlelimite = 500. Alors qu'il fallait plus de 14H pour faire la même chose avec trottlelimite = 20.
L'ajout de STA :
[code:1]$sessionState = [system.management.automation.runspaces.initialsessionstate]::CreateDefault()
$runspacePool = [runspacefactory]::CreateRunspacePool(1, $throttleLimit, $sessionState, $host)
$runspacePool.ApartmentState=\&quot;STA\&quot;
$runspacePool.Open()[/code:1]
Je ne peux pas expliquer, simplement constater.

Si vous avez une idée sur le rôle de ce paramètre, voire si vous êtes capables de faire un tutorial sur non pas la mise en oeuvre mais les coulisses de ce monde des runspacepool, ce serait super. C'est vrai que cela ne rejoint pas l'administration normale en domaine avec GPO et que cet \&quot;objet\&quot; reste anecdotique.

J'aurais bien une autre question concernant les tables de hashage synchronisées qui sembleraient servir à échanger des variables entre thread d'un pool et qui rentre dans le cadre de la philosophie des runspace mais une chose à la fois.
[code:1]$sharedData = [HashTable]::«»Synchronized(@{})[/code:1]
Respectueusement.
Noël