Question accés wmi distant avec credential

Salut,
noel écrit:

Comment arrive-t-on à écrire un code comme celui ci pris sur divers site?

En lisant les doc, en testant, en copiant, ...
Ici,on ne peut pas inventer.
noel écrit:

où trouve-t-on des explications sur le pourquoi de cette formulation surprenante avec le -list et le where qui retourne la méthode ?

[code:1]
get-help Get-WmiObject -parameter List
[/code:1]
Dans la doc de PowerShell et sur MSDN.

Le where filtre les objets émit dans le pipeline par le premier cmdlet Get-WmiObject.
L'objet récupéré est une instance de la classe StdRegProv .
C'est celle-ci qui porte la méthode EnumKey .
noel écrit:

C'est pas enseigné dans le cours PS de l'ENI que je viens de suivre...

Difficile d'aborder dans un seul ouvrage tout ce qui à trait à l'automatisation de tâches.
Tu peux consulter ce tuto sur WMI .
noel écrit:

mais sans pouvoir passer de credential.

Là tu utilises les API win32, par défaut celle-ci s'appuient sur le compte que tu utilises.
L'authentification est donc transparente, là où WMI nécessite de le préciser.
noel écrit:

Pourquoi tout est aussi compliqué?

Il est parfois difficile de faire les choses simplement, ce n'est pas 'compliqué', à la rigueur tu n'as pas été formé ou tu ne possédes pas l'information, ce qui n'est pas la même chose.
En même temps d'adresser une machine distante sans avoir à coder les trames réseaux, c'est tout de même appréciable

noel écrit:

Avec le cours, le livre,de nombreuses heures d'écriture (ou de tatonnement pour être plus exact), et beaucoup de recherches sur internet

Pareil, mais j'ai commencé en 2006, j'ai un peu d'avance
noel écrit:

dont les lectures de tous ou presque des tutorials de Laurent Dardenne (mais j'ai décroché dans bien des cas !)

Oui, je suis conscient que qq uns ne sont pas facile d'accès.
J'ai relu hier celui sur les runspaces, j'ai effectivement indiqué le niveau \"Confirmé\" sans définir ce qu'il définit dans ce contexte.
Dans ce cas, c'est vrai que j'ai chargé la mûle !
Sans retour des lecteurs, sachant que parler est une prise de risque, difficile de corriger \"le tir\".
Si tu me donnes qq infos sur le pourquoi de ce décrochage je ne vais pas te mordre
noel écrit:

j'ai été surpris de constater que l'accès aux classes de stdRegProv ne se font pas aussi \"naturellement\" qu'avec d'autres objects wmi
comme ceux des classes win32_... (namespace différents).

Le code que tu cites t'induis en erreur
noel écrit:

Mais pourquoi ce passage par le -list et le where et non pas par quelque chose comme...

Il n'est peut être pas le plus pertinent pour étayer tes propos :
[code:1]
...
#Pour le détail voir la signature
#de ce constructeur : msdn.microsoft.com/fr-fr/library/8wzwcace.aspx
$stdReg= [wmiclass]\"\\MachineName\ROOT\default:«»StdRegProv\"
$RegKeys = $RegObject.EnumKey($HKLM, \"SoftwareMicrosoft\"«»)
...
[/code:1]
On se rapproche du \"naturel\", PowerShell est là pour nous aider à manipuler des données, issues de différentes sources (cf. les providers).
Mais pour être efficient il faut connaître comment fonctionne le fournisseur, le \"pouvoir\", tout relatif, n'est donc pas dans le shell, mais dans la connaissance que l'on a du fournisseur que l'on interroge.
[code:1]
$RegObject.__path
#\\MachineName\ROOT\default:«»StdRegProv
[/code:1]
Je ne connais pas Exchange, Powershell ne comblera pas ce manque, mais les cmdlets qu'il met à disposition m'aideront à masquer cette méconnaissance.
D'où le nom initial du produit, Monad .
Si tu décroches t'inquiéte pas, c'est normal ça me fait le même effet .
noel écrit:

merci de toujours positiver.

Tjr, je ne pense pas, souvent

noel écrit:

on ne peut pas passer de credential.

Il faut utiliser un autre constructeur :
[code:1]
$MyCredential=Get-Credential
$MachineName=\"test\"
$WmiNameSpace=\"\\$MachineName\ROOT\default\"
$scope =New-Object System.Management.ManagementScope $WmiNameSpace
$scope.options.Username = $MyCredential.GetNetworkCredential().Username
$scope.options.Password = $MyCredential.GetNetworkCredential().Password
$stdReg= new-object System.Management.ManagementClass($Scope,\"\\$MachineName\ROOT\default:«»StdRegProv\",$null)
[/code:1]
Pour le premier exemple, voir page 8 du tuto WMI.
noel écrit:

Au passage, je suis surpris que :

Tu interroges une classe, tu obtients donc des infos sur cette classe. La méthode Create renvoi un entier pas un objet Win32_Share.
Ensuite GWMI renvoi par défaut des instances, c'est le besoin le + courant.
noel écrit:

J'ai lu pas mal de \"recettes de cuisine\" et il me semble que je ne suis pas le seul à les employer, à obtenir le résultat souhaité mais au final ne pas pouvoir faire seul quelque chose.

Cela dépend de l'approche que chacun adopte par rapport à la résolution d'un problème ou face à la nouveauté.
Pour un pb, si seul le résultat compte, pas besoin de comprendre comment il se produit ni comment l'éviter.
Cuisiner un plat ne peut être réduit à suivre une recette, il y a un savoir/expérience préalable.
noel écrit:

Je rêve d'un didacticiel très court (mais pas que le niveau \"recette pour les nuls\") sur la registry, locale et distante,

Bha, tu peux le rédiger, c'est un excellent exercice d'apprentissage.

noel écrit:

un peu sans queue ni tête comme celui ci.

Si, les deux sont là