Discussion :

[hervebaron]

Bonjour,

je viens de développer un super script VBS qui marche à merveille sur mon WinXP. Malheureusement le parc informatique n'est pas composé uniquement de windows XP, mais il me reste encore pas mal de win2000.
le pb c'est que mon code ne fonctionne pas sous 2000.
netconnectionstatus est une variable de la classe Win32_NetworkAdapter issu de WMI CLASS
sous winXP je suis en WMI version 5.xx alors que sous win2000 j'ai une vieille version WMI 1.5, je suppose que mon pb vient de là.
je ne trouve pas de WMI CORE à télécharger plus récent que la V1.5

je suppose que je ne suis pas le premier à qui il arrive ce genre de mésaventure, comment procédez vous pour avoir un code "transportable".

ok tester la vesion de l'os pour executer tel ou tel bout de code, je veux bien, mais par quoi remplace t on le code manquant sous 2000 ?
existe t il d'autres class sous 2000 qui sont equivalente à celle de XP ?

merci pour votre retour d'expérience

[ThierryAIM]

en installant le .net framework SDK

http://msdn.microsoft.com/en-us/libr...82(VS.85).aspx

[hervebaron]

en installant le .net framework SDK

http://msdn.microsoft.com/en-us/libr...82(VS.85).aspx

quel réactivité ce forum, 44min. ouahou

j'ai installé :
windows installer 3.1
dotnet 2.0
dotnet 2.0 sdk (354Mo ouf )

et mon script ne marche toujours pas

comment doit je interpréter cette réponse ?
est ce que WMI par dotnet créé les memes classes ?
ou
est ce qu'il existe des classes similaires qui portent d'autres nom ?

[ThierryAIM]

fais voir ton script (à moins qu'il ne soit confidentiel), qu'on puisse voir les classes utilisés (j'ai un poste en W2k SP4 + Framework 2.0 pour tester, si tu veux)

[hervebaron]

ah oui avec plaisir, mon code n'a rien de confidentiel

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
strComputer = "."
Set objShell = Wscript.CreateObject("Wscript.Shell")
set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
set colNAs = objWMI.InstancesOf("Win32_NetworkAdapter")
for each objNA in colNAs
	if not IsNull(objNA.NetConnectionStatus) and _	
	   not objNA.Name="Cisco Systems VPN Adapter" and _
	   InStr(1,objNA.Name,"Wireless")=0 and _
	   InStr(1,objNA.Name,"1394")=0 and _
	   InStr(1,objNA.Name,"Bluetooth")=0 _
	then 
		Err = objShell.Run ("netsh interface ip set address name="& chr(34) & objNA.NetConnectionID & chr(34) & " source=static addr=192.168.1.12 mask=255.255.0.0" ,0,True)
	end if
next

le message d'erreur que j'ai en retour est "cet objet ne gere pas cette propriété ou cette méthode : 'objNA.NetConnectionStatus'

le but de ce script est de mettre en IP static la carte reseau filaire (pas la ciso, pas la wireless, pas la 1394, pas la bluetooth)

objNA.NetConnectionStatus me sert filtrer les cartes physiquement présentes.

[omen999]

bonjour,
http://www.issociate.de/board/index....88&goto=447028
(le dernier message...)

[hervebaron]

apparement, NetConnectionStatus n'existe pas sous win2000 mais IpEnabled existe et prend la valeur VRAI en meme temps que NetConnectionStatus.
comme j'utilise que le protocol TCP/IP, ça devrait pouvoir faire l'affaire.

par curiosité, on ne peut pas avoir : NetConnectionStatus ?
j'ai eu pas de bol à ce point pour tomber sur le seul attribut manquant de la class ?

merci omen999, même si ce n'est pas la réponse que je souhaitais, mais c'est un bon contournement si ça marche

EDIT:

Bon ça marche, même sous win2000, mais ça coince plus loin, avec NetConnectionID, WMI avec DOTNET n'est pas très complet ....

NetConnectionID me sert à récupérer le nom de la carte réseau, exemple "connexion au reseau local", pour le passer en param. à netsh

bon je sens que c'est pas gagné

[omen999]

pour NetConnectionID:
http://msdn.microsoft.com/en-us/libr...95(VS.85).aspx

[hervebaron]

yeh elle est bien détaillée cette page, merci pour le lien.

bon je n'ai pas trouvé exactement la réponse à ma question, mais j'ai trouvé une autre façon de faire.
du coup, je n'ai plus besoin de faire appel à NETSH et c'est 1000x plus rapide qu'avant en temps d'exécution, c'est presque instantané !!

par contre, la bonne nouvelle, c'est que je n'ai pas besoin d'installer DOTNET DOTNET SDK ni WINDOWS INSTALLER...

merci à tous, et voici le script final :

activation IP STATIC

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
strIPAddress = Array("192.168.1.12")
strSubnetMask = Array("255.255.0.0")
strGateway = Array(0) 'array("192.168.1.12")
strGatewayMetric = Array(1)
 
 
'Stop Service
strServiceName = "OfficeScanNT Personal Firewall"
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colListOfServices = objWMIService.ExecQuery("Select * from Win32_Service Where DisplayName ='" & strServiceName & "'")
For Each objService in colListOfServices
    objService.StopService()
Next
 
strComputer = "."
Set objShell = Wscript.CreateObject("Wscript.Shell")
set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
set colNAs = objWMI.InstancesOf("Win32_NetworkAdapter")
for each objNA in colNAs
	if not objNA.Name="Cisco Systems VPN Adapter" and _
	   InStr(1,objNA.Name,"Wireless")=0 and _
	   InStr(1,objNA.Name,"1394")=0 and _
	   InStr(1,objNA.Name,"Bluetooth")=0 _
	then
		set colNACs = objWMI.ExecQuery(" select * from " & " Win32_NetworkAdapterConfiguration " & " where Index = " & objNA.Index)
		for each objNAC in colNACs
			if objNAC.IpEnabled then 
				errEnable = objNac.EnableStatic(strIPAddress, strSubnetMask)
				errGateways = objNac.SetGateways(strGateway, strGatewaymetric)
			end if
		next
	end if
next

activation IP DHCP

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
'Start Service
strServiceName = "OfficeScanNT Personal Firewall"
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colListOfServices = objWMIService.ExecQuery ("Select * from Win32_Service Where DisplayName ='" & strServiceName & "'")
For Each objService in colListOfServices
    objService.StartService()
Next
 
 
strComputer = "."
Set objShell = Wscript.CreateObject("Wscript.Shell")
set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
set colNAs = objWMI.InstancesOf("Win32_NetworkAdapter")
for each objNA in colNAs
	set colNACs = objWMI.ExecQuery(" select * from " & " Win32_NetworkAdapterConfiguration " & " where Index = " & objNA.Index)
	for each objNAC in colNACs
		if objNAC.IpEnabled and _	
		   not objNA.Name="Cisco Systems VPN Adapter" and _
		   InStr(1,objNA.Name,"Wireless")=0 and _
		   InStr(1,objNA.Name,"1394")=0 and _
		   InStr(1,objNA.Name,"Bluetooth")=0 _
		then 
			objNAC.EnableDHCP()
		end if
	next
next

ThierryAIM :

je pense que la proposition DOTNET avait elle aussi du sens pour le topic "portabilité", même si j'ai réussi à adapter mon code pour cette fois, le sujet reste entier, et je ne marque pas le sujet comme résolu pour creuser cette piste.

[ced600]

je ne marque pas le sujet comme résolu pour creuser cette piste

C'est à dire ?

[hervebaron]

c'est à dire que omen999 m'a apporté de belles solutions de contournement et répond donc parfaitement à la question de l'exemple de code non portable qu'est netconnectionstatus
mais il ne m'a pas répondu sur "comment gérer la portabilité" quelque soit le code.

thierryAIM lui a commencé à répondre à la question générale de la portabilité de code WMI par l'ajout de DOTNET SDK.
Cependant ça n'a pas marché dans mon cas.
donc je souhaiterais creuser cette réponse, comment mettre à jour un poste windows pour qu'il puisse avoir les mêmes classes methodes et attributs quelque soit ça version Win2000 WinXP WinVista ....
dotnet
dotnet SDK
ou tout autre réponse ...

soit la réponse est "c'est impossible", soit il y a une/des réponse(s) possible(s) et je suis curieux de la(les) connaitre

[ced600]

Tout faire avec les classes uniquement disponible sur Win2000 et vérifier que celle-ci existe toujours sur les nouveaux systèmes d'exploitations.

WMI est disponible sur Win2000, sous XP avec des nouvells classes, et de même pour Vista.
Donc tu ne dois utiliser que les classes disponibles sur les trois systèmes.

La doc en ligne MSDN fournis un descriptif de toutes les classes WMI et spécifie en fin de page dans les Requirements, les systèmes compatibles avec cette classe.

Un exemple : http://msdn.microsoft.com/en-us/libr...99(VS.85).aspx

Bah il ne me reste plus qu'à dire bon courage. Sinon il ne reste plus qu'à passer au VB.Net et en installant le framework sur tout tes postes ton code sera compatibles sur tous les postes.

[hervebaron]

...WMI est disponible sur Win2000, sous XP avec des nouvells classes, et de même pour Vista.
Donc tu ne dois utiliser que les classes disponibles sur les trois systèmes.

La doc en ligne MSDN fournis un descriptif de toutes les classes WMI et spécifie en fin de page dans les Requirements, les systèmes compatibles avec cette classe.

je prend souvent du code exemple sur le net pour trouver un support car je ne connais pas les classes existantes.
malheureusement il n'y a pas de convention d'écriture qui permette de déterminer rapidement leur plateforme minimum. (lorsque je télécharge un programme _x86 ou _x64 je sais à quoi cela correspond instantanément)

donc si il faut se référer au MSDN à chaque instruction, l'écriture du code va être beaucoup plus lente ...

j'esperais un upgrade pour rester ISO lorsque de nouvelles fonctions apparaissent, je revais peut etre un peu ?

[ced600]

Une mise à jour du WMI sur les anciens systèmes ?
Hum... cela peut vouloir le coup de regarder. Tu trouveras l'info sur le site de msdn ou de MS.

[hervebaron]

hum j'ai déjà creusé les MAJ WMI, s'arretent à v1.5
et j'ignore comment marche WMI via DOTNET, je ne connaissais pas son existance il y a quelques jours encore.
le lien de thierry nous apporte une piste que j'ai du mal à exploiter

"WMI functionality introduced in the Windows 2000 Professional Service Pack 2 (SP2) operating system is also available to earlier operating systems by downloading the .NET Framework SDK, and the .NET Framework Redistributable"

si .net apporte à xp et vista des fonctions type WMI avec de nouvelles classes, alors mettre à jour .NET sur W2000 devrait me donner les même classes !!!

mais concretement ça n'a pas marché pour moi.
Effectuer une liste exhaustive des classes , attributs et autres méthodes par type d'OS et d'ADD ON est une tache difficile...voir impossible

[ced600]

Ce n'est pas ce que la phrase dit :
"Les functionnalité introduite dans le service pack 2 de windows2000 peuvent être obtenu pour de système d'exploitation via le framework .Net"

Bref en gros cela te dit que dans .Net tu as au moins les méthode de Win2000 mais pas forcement celle de XP et/ou vista. C'est surtout utile pour ceux qui travaillent sous Win98 ou NT4, si si ils y a encore des personnes qui travaillent sur ces systèmes.

Peut être que l'on peut installer WMI sur une machine qui ne le possède pas nativement (Win98/95/3.11 (quoique à vérifier l'installation possible sous 3.11) et NT4) mais que la mise à jour d'une collection WMI n'est pas possible.
Peut être trop intégré au coeur du système.

Regarde dans les contributions, j'ai posté un sujet sur WMI Code Creator. C'est un outil qui aide à générer du code VB ou VBS ou C# juste en sélectionnant une classe WMI, ses méthodes et ses propriétés.
Si je ne me trompe pas, le programme dans le choix des classes t'offrent uniquement celles diponibles sur la machine.
Donc si tu le mets sur un poste Win2000 et que tu l'utilises pour générer le code (et que je ne me suis pas trompé) tu pourrais peut être même gagné du temps

[hervebaron]

Ce n'est pas ce que la phrase dit :
"Les functionnalité introduite dans le service pack 2 de windows2000 peuvent être obtenu pour de système d'exploitation via le framework .Net"

j'ai peut etre compris ce qui m'arrangeait

Bref en gros cela te dit que dans .Net tu as au moins les méthode de Win2000 mais pas forcement celle de XP et/ou vista. C'est surtout utile pour ceux qui travaillent sous Win98 ou NT4, si si ils y a encore des personnes qui travaillent sur ces systèmes.

Peut être que l'on peut installer WMI sur une machine qui ne le possède pas nativement (Win98/95/3.11 (quoique à vérifier l'installation possible sous 3.11) et NT4) mais que la mise à jour d'une collection WMI n'est pas possible.
Peut être trop intégré au coeur du système.

j'utilise Microsoft SMS depuis longtemps, et celui ci s'appuie sur WMI, et j'ai eu l'occasion de faire une monter de version des WMI pour W98 et NT4 pour adapter face a un upgrade du serveur SMS.
donc c'est dommage que microsoft n'est pas poursuivi le dev. des WMI en upgrade !

Regarde dans les contributions, j'ai posté un sujet sur WMI Code Creator. C'est un outil qui aide à générer du code VB ou VBS ou C# juste en sélectionnant une classe WMI, ses méthodes et ses propriétés.
Si je ne me trompe pas, le programme dans le choix des classes t'offrent uniquement celles diponibles sur la machine.
Donc si tu le mets sur un poste Win2000 et que tu l'utilises pour générer le code (et que je ne me suis pas trompé) tu pourrais peut être même gagné du temps

ok je regarde ça, ça peut m'aider sinon j'utilise VBSEDIT pour avoir le debug et un frame à droite avec les classes, mais c'est perfectible comme outil ...

[ThierryAIM]

si .net apporte à xp et vista des fonctions type WMI avec de nouvelles classes, alors mettre à jour .NET sur W2000 devrait me donner les même classes !!!

oui et non...
sur mon poste W2K SP4 + framework 2.0, j'ai une version 5 de wmi
Or, malgré cela, certaines classes ne sont pas dispos, car non compatibles avec l'OS
J'ai testé ton code, sur xp et w2k, et devine quoi ?

Effectuer une liste exhaustive des classes , attributs et autres méthodes par type d'OS et d'ADD ON est une tache difficile...voir impossible

c'est bien là tous les problèmes de compatibilité descendante !!

Soit, comme te le dit ced, tu conçois ton script sur l'OS le plus bas et il sera forcement compatible avec le plus haut, soit tu acceptes que tu ne puisses pas le faire fonctionner sur tous les OS

[ced600]

et il sera forcement compatible avec le plus haut

Je n'ai jamais vérifié, mais n'y a t'il pas des classes, des méthodes, disponibles sous 2000 qui ont dispasrus dans les nouvelles versions ?

Si c'est le cas, il faudra faire le code avec la MSDN en vérifiant à chaque fois que la classe, la méthode ou l'attribut désiré soit compatible avec 2000.

Après cela dépend aussi de ton parc informatique.

Si tu as une seule machine sous Win2000, alors gère là indépendement des autres, et conserve ton script originale pour les autres.

Si tu en as une centaine -> Bon courage pour le nouveau script.

[hervebaron]

oui et non...
sur mon poste W2K SP4 + framework 2.0, j'ai une version 5 de wmi
Or, malgré cela, certaines classes ne sont pas dispos, car non compatibles avec l'OS
J'ai testé ton code, sur xp et w2k, et devine quoi ?

quoi ?

c'est bien là tous les problèmes de compatibilité descendante !!

Soit, comme te le dit ced, tu conçois ton script sur l'OS le plus bas et il sera forcement compatible avec le plus haut, soit tu acceptes que tu ne puisses pas le faire fonctionner sur tous les OS

oui le souci est effectivement d'avoir la connaissance de l'ancienneté du code.
lorsque l'on est débutant, comme moi, il n'est pas facile de connaitre une le code pour réaliser telle ou telle opération, donc on surf, on pompe du code à droite à gauche, on adapte un peu, ... et là surprise ça ne marche pas.
donc il faut trouver la partie du code non portable, et trouver comment faire la même chose mais autrement , galère ....

donc dot net ne repond que partiellement à ce besoin, c'est déjà ça, et c'est bon à savoir



merci à tous pour vos contributions, que ce soit avec du code ou des explications