Ce site dans votre langue

French English Afrikaans Albanian Amharic Arab Armenian Azerbaijan Basque 
Belarusian Bengali Bosnian Bulgarian Burmese Catalan Cebuano Chichewa Chinese (Simplified) 
Chinese (Traditional) Cingalais Corsica Croatian Czech Danish Dutch Esperanto Estonian 
Finnish Gaelic (Scotland) Georgian German Greek Haitian creole Hawaiian Hebrew Hindi 
Hungarian Icelandic Igbo Indonesian Irish Italian Japanese Kazakhstan Khmer 
Kirghiz Korean Kurdish Laotian Latvian Lithuanian Luxemburgish Macedonian Malaysian 
Maltese Mongolian Nepalese Norwegian Polish Portuguese Romanian Russian Serbian 
Slovak Slovenian Spanish Swahili Swedish Tagalog Tajikistan Thai Turkish 
Ukrainian Uzbek Vietnamese 

Plugin TranslatorBox par Dipisoft
Merci à Google Traduction

Traductions des logiciels

Les logiciels proposés sur ce site
sont nativement en français...

... certains (identifiés par le picto multilingue.png),
sont fournis avec des fichiers
de langues supplémentaires.

Apportez votre pierre à l'édifice en
améliorant des traductions existantes...

... ou en ajoutant des nouvelles
traductions à certains logiciels.

Pour ce faire, rendez-vous sur la page
des fichiers de langues et
rejoignez la liste des contributeurs !

Dons / Contributions

A titre d'information, l'hébergement et le nom de domaine de ce site me coûtent 87€/an, montant non atteint en dons ces 2 dernières années.

Alors si vous souhaitez participer...

... vous rejoindrez ainsi la

Visites

 1817791 visites

 21 visiteurs en ligne

Newsletter
Pour avoir des nouvelles de ce site, inscrivez-vous à notre Newsletter.
GZrR
Recopier le code :
480 Abonnés
Recherche sur ce site
Recherche sur ce site
Réseaux sociaux
FAQ
Déplier Fermer  Dipiscan/IPScan32

Alors pour commencer, ce n'est pas un bug de l'appli ! IPScan32 en son temps tout comme Dipiscan à présent tentent de récupérer cette information via NetBIOS. Si le login de l'utilisateur de la machine distante ne s'affiche pas, c'est que l'utilisateur ne faisait pas partie des informations contenues dans la réponse à la requête envoyée. Il se peut que la machine soit allumée sans qu'aucune session ne soit ouverte mais c'est plus souvent dû au fait que la machine ne délivre tout simplement pas cette information...

Jusqu'à Windows XP (côté machine distante)

C'est l'activation du service "Affichage des messages" qui permet d'enrichir les informations NetBIOS avec le login d'ouverture de session. Mais attention, cette information semble "volatile", il faut parfois arrêter/redémarrer le service pour que l'info soit de nouveau fournie par la machine distante.

A partir de Vista (toujours côté machine distante)

L'information n'est plus retournée par NetBIOS. Il faut donc passer à une autre méthode de récupération, ce que ne permet pas IPScan32 (encore une bonne raison pour abandonner ce dernier). Mais Dipiscan oui ! Alors rendez-vous dans la fenêtre de configuration de l'application et choisissez dans la liste déroulante correspondante ("Méthode de récupération de l'utilisateur distant") une des méthodes utilisant WMI.

Mais malgré ça il est possible que l'info ne remonte encore pas. Il vous faudra peut-être modifier quelques paramètres de Windows (toujours côté machine distante), jettez un coup d’œil à cet autre article de la FAQ.


Date de création :17/11/2007 @ 13:51 Dernière modification :19/01/2017 @ 19:04 Hyperlien  Prévisualiser...  Imprimer... 

Voir la FAQ "Dipiscan/IPScan32/WakeOnLan/WmiSysInfos - Accéder aux informations et/ou agir sur une machine à distance".


Date de création :17/11/2007 @ 16:52 Dernière modification :21/12/2016 @ 11:35 Hyperlien  Prévisualiser...  Imprimer... 

Déplier Fermer  Dipiscan/IPScan32/LanAlertCenter/WakeOnLan/WmiSysInfos

L'accès aux informations, le redémarrage, l'extinction, la fermeture de session, le verrouillage de session et la mise en veille prolongée d'une machine distante requièrent des droits. Mais attention, vous pouvez être administrateur sur la machine où vous avez ouvert votre session, cela ne vous permet pas pour autant de faire la pluie et le beau temps sur les autres machines : il faut que celles-ci reconnaissent votre compte comme étant admin...

Pour accéder à une machine appartenant à un "domaine" depuis votre poste appartenant au même domaine, cela ne posera pas de problème dès lors que votre compte est admin du domaine ou des machines concernées.

En revanche, pour accéder à une machine en "workgroup" depuis votre poste (que celui-ci soit également en "workgroup" ou dans un domaine), il faut que vous vous "présentiez" à la "cible" avec un compte/mot de passe reconnu par elle comme étant admin. Le plus simple est d'avoir créé un compte admin avec le même login/password sur toutes vos machines. Mais cela ne suffit pas car certains réglages natifs de Windows et de son pare-feu font barrière : administration à distance désactivée, accès WMI à distance soumis à l'UAC, pare-feu, etc...

Pour lever ces barrières, je vous propose un petit "script" que je lance systématiquement sur les machines auxquelles je veux pouvoir accéder à distance avec mes outils.

Attention, celui-ci n'est fonctionnel qu'à partir de Windows Vista (désolé pour ceux qui utilisent encore du XP). Et la configuration du firewall concerne le firewall intégré à Windows. Si vous l'avez remplacé par un logiciel tiers, il faudra adapter les règles.

Script à lancer "en tant qu'admin" sur les machines "cibles" (pas celle depuis laquelle vous opérez) :

conf_acces_a_distance.bat (télécharger)

@echo off
echo ### Vérification de l'exécution en tant qu'admin
net session >nul 2>&1
if %ERRORLEVEL% NEQ 0 (
    echo Echec.
    echo.
    echo /!\ Ce script doit être executé en tant qu'administrateur ! /!\
    goto fin
)
echo Ok.
echo.

echo ### Configuration du firewall pour activer la réponse au ping et la réponse aux requêtes NetBIOS
netsh advfirewall firewall add rule name="_ICMPv4" protocol=icmpv4:any,any dir=in action=allow
netsh advfirewall firewall add rule name="_NetBIOS UDP Port 137" dir=in action=allow protocol=UDP localport=137
netsh advfirewall firewall add rule name="_NetBIOS UDP Port 137" dir=out action=allow protocol=UDP localport=137
netsh advfirewall firewall add rule name="_NetBIOS UDP Port 138" dir=in action=allow protocol=UDP localport=138
netsh advfirewall firewall add rule name="_NetBIOS UDP Port 138" dir=out action=allow protocol=UDP localport=138
netsh advfirewall firewall add rule name="_NetBIOS TCP Port 139" dir=in action=allow protocol=TCP localport=139
netsh advfirewall firewall add rule name="_NetBIOS TCP Port 139" dir=out action=allow protocol=TCP localport=139
netsh advfirewall firewall add rule name="_NetBIOS TCP Port 445" dir=in action=allow protocol=TCP localport=445
netsh advfirewall firewall add rule name="_RPC" dir=in action=allow protocol=TCP localport=RPC
echo.

echo ### Activation de l'administration à distance
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v AllowRemoteRPC /t reg_dword /d 1 /f
echo.

echo ### Désactivation de l'UAC pour les appels distants
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t reg_dword /d 1 /f

:fin
echo.
pause

Un redémarrage est généralement nécessaire pour que certains réglages soient appliqués. Après ceci vous ne devriez plus rencontrer de problème... du moins je l'espère.

Pour finir, après de longues recherches et de nombreux tests, il s'avère que l'accès WMI à distance est impossible sous WindowsXP Home : après retour d'expérience utilisateur, ce n'est pas visiblement pas le cas pour les éditions "Home/Familiale" des versions supérieures.


Date de création :21/12/2016 @ 11:25 Dernière modification :21/12/2016 @ 11:25 Hyperlien  Prévisualiser...  Imprimer... 

Déplier Fermer  IPScan32

Certains rencontrent effectivement ce problème avec WakeOnLan ou IPScan32 (qui utilisent tous deux des outils du DOS) sur des versions 64 bits de Windows et Windows server.

Ceci est dû au binaire NBTSTAT qui n'est pas, sur certains systèmes 64 bits, présent dans le répertoire où il devrait se trouver (avec les autres utilitaires). Ceci ne se voit pas via l'explorateur mais cela peut se vérifier avec cet outil par exemple. Pourquoi ? Parce que le système "n'expose" pas le même dossier System32 aux processes 32 bits et 64 bits. Lorsqu'il essaye d'accéder à System32, un process 32 bits voit en réalité le contenu de c:\Windows\SysWOW64 (et c:\Windows\sysnative, ce dernier n'apparaissant d'ailleurs pas aux applis 64 bits). Ce mécanisme est expliqué ici notamment.

Pour régler le problème, j'ai trouvé une petite astuce. Je ne suis pas persuadé que des puristes Microsoft valideraient la manip, mais il s'avère que cela semble fonctionner. La voici :

  • récupérer l'exécutable NBTSTAT.EXE sur un OS de préférence équivalent mais en version 32 bits
  • le rapatrier sur le poste qui pose problème en le collant sur le bureau par exemple
  • double-cliquer sur l'icone de NBTSTAT pour l'exécuter. Une fenêtre DOS va s'ouvrir et se refermer très rapidement mais cette manip devrait être suffisante pour que le système récupère le binaire et le place dans c:\Windows\sysnative. Dès lors, vous ne devriez plus avoir le message d'erreur au lancement de l'outil.
  • si la manip précédente n'a pas fonctionné, déplacer manuellement le fichier récupéré vers c:\Windows\SysWOW64. Cette foi-ci vous ne devriez plus rencontrer le message d'erreur en lançant WakeOnLan ou IPScan32.

Date de création :06/06/2016 @ 14:44 Dernière modification :06/06/2016 @ 14:44 Hyperlien  Prévisualiser...  Imprimer... 

Déplier Fermer  LanAlertCenter
Inutile de chercher dans les menus ou d'essayer d'utiliser le module d'importation : pour commencer il suffit de faire un clic droit sur le fond de l'espace de travail. Un menu contextuel s'ouvre alors, il contient diverses items qui vous permettront d'ajouter machines et dossiers.

Le meilleur apprentissage passant par la pratique, manipulez quelques minutes et vous devriez vous en sortir rapidement...

Date de création :17/11/2007 @ 17:15 Dernière modification :17/11/2007 @ 17:27 Hyperlien  Prévisualiser...  Imprimer... 

Oui, c'est tout à fait possible en respectant les règles suivantes :

  • les icones doivent être au format .ico, de préférence en 32x32 pixels et de 2 bits (16 couleurs) à 24 bits (16,7M de couleurs sans canal alpha) ; les icones en 32 bits ne sont pas reconnus
  • les icones sont à placer dans le sous-dossier Icones de l'appli (C:\Program Files (x86)\Dipisoft\LanAlertCenter\Icones, par défaut)
  • la prise en compte des icones s'effectue au démarrage de l'application, la redémarrer si les icones ont été placés dans le dossier alors que celle-ci était en cours d'exécution

Bref, rien de bien complexe.

Pour créer ou convertir vos icones au bon format je vous conseille le logiciel IcoFX (ancienne version en freeware sur filehippo.com).


Date de création :18/01/2017 @ 23:48 Dernière modification :18/01/2017 @ 23:48 Hyperlien  Prévisualiser...  Imprimer... 

Déplier Fermer  QuickUserInfos

Bien sûr que non, ce serait quand même une grosse régression et ôterait un grand intérêt à l'outil !

Petit retour en arrière : avant la version v2.5 de l'outil, on pouvait simplement (via une case à cocher placée sous la zone de texte "Occurrence à rechercher"), choisir d'afficher ou non la liste des groupes. Pourquoi ce mode de fonctionnement simple n'a-t-il pas été reconduit me direz-vous ?!

Tout simplement parce qu'un jour j'ai eu besoin de savoir à quels groupes j'appartenais de façon "indirecte", par "héritage" (principe : je suis membre du groupe A, celui-ci se trouve dans un groupe B, lui même placé dans un groupe C : par héritage je suis aussi membre des groupes B et C).

Je me suis dit que cette information pouvait aussi être utile à d'autres, donc qu'elle avait toute légitimité de se retrouver dans QuickUserInfos. Mais cette recherche étant plus longue (et pas forcément utile dans la majeure partie des cas), je n'ai pas voulu "l'imposer". D'où le besoin de la rendre "optionnelle" comme l'était déjà l'affichage de l'appartenance aux groupes. J'aurais pu remplacer la case à cocher déjà présente par des boutons radios permettant de choisir entre la "recherche simple" (juste les infos du compte), la recherche "avec groupes" et enfin la petite nouvelle "avec groupes y compris hérités". Mais la longueur des libellés aurait engendré une grosse surcharge de l'interface, ce que je voulais éviter.

J'ai donc opté pour quelque chose de plus "léger" pour l'interface, en m'inspirant du "SplitButton" (un bouton "coupé en deux" où un clic sur la partie gauche lance une action alors qu'un clic sur la partie droite fait apparaître d'autres options) proposé par certains outils de développement modernes. Comme certains utilisateurs sont "conditionnés" à appuyer sur le bouton "Go!" depuis les toutes premières versions mais ne sont pas assez curieux pour cliquer sur l'espèce de truc situé juste à sa droite, voici une petite capture de ce qu'ils y découvriraient !

quickuserinfos03.png

Lorsque l’appli est fraîchement installée, la configuration initiale de la recherche par défaut est "Informations du compte", donc quand on clique sur "Go !", la recherche rapatrie uniquement les principales informations du compte, pas les groupes dont il est membre. Pour accéder à une des 2 autres recherches, au lieu de cliquer sur le bouton "Go !", il faut cliquer sur le bouton situé juste à sa droite : un menu popup apparaît contenant les 2 autres modes de recherche. Il suffit de cliquer sur un des items pour obtenir les infos souhaitées.

Mais pour éviter de régulièrement avoir à "jouer" avec ce menu popup quand la recherche "Informations du compte" n'est pas la plus utilisée, QuickUserInfos permet de modifier le mode de recherche par défaut, donc l'action du bouton "Go !". Il suffit pour cela de se rendre dans la fenêtre de configuration de l’outil et d'y sélectionner le mode que l'on préfère...

quickuserinfos04.png

Bien entendu, le contenu du menu popup sera lui-aussi impacté par ce changement puisqu'il propose les 2 modes complémentaires à celui affecté au bouton "Go !".

Voilà, j'espère que cette information vous sera utile ! smile


Date de création :14/08/2012 @ 08:45 Dernière modification :23/01/2013 @ 08:51 Hyperlien  Prévisualiser...  Imprimer... 

Déplier Fermer  Tous les logiciels (y compris les "non-Dipisoft")

Ça peut arriver avec mes applis, par exemple lorsque vous avez coché l'option "Mémoriser la position de la fenêtre" et que vous avez changé de résolution ou débranché votre écran secondaire (sur lequel l'appli était positionnée).

Pour vous sortir de ce mauvais pas, c'est généralement assez simple. Non, vous n'allez pas devoir bidouiller ou supprimer le fichier de configuration, il y a bien une solution.

Assurez-vous que l'application "a le focus", c'est à dire que c'est elle - même si cela ne se voit pas forcément - qui est application active au vu du système. On peut le voir car son icone dans la barre des tâches est en légère surbrillance.

fenetre_masquee01.png

Si ce n'est pas le cas, cliquez sur ledit icone ou sélectionner l'application en faisant autant de ALT+TAB que nécessaire.

fenetre_masquee02.png

Une fois l'appli sélectionnée, pressez ALT+Espace ; un menu contextuel va apparaître collé à un des bords de l'écran (celui dont la position actuelle de la fenêtre est la plus proche).

fenetre_masquee03.png

Sélectionnez ensuite l'option "Déplacer" dudit menu contextuel, puis pressez une des 4 touches fléchées du clavier.

Enfin, déplacez votre souris ; la fenêtre se déplacera, accrochée au pointeur... Faites un clic-gauche pour fixer sa nouvelle position, le tour est joué !

fenetre_masquee04.png

Dans le même genre, vous pouvez modifier la taille d'une fenêtre qui dépasse celle de l'écran. Pour ce faire, adoptez la même technique mais sélectionnez l'option "Taille" du menu contextuel. Pressez ensuite la touche fléchée correspondant au bord de la fenêtre que vous souhaitez déplacer et déplacez votre souris jusqu'à la position souhaitée. Cliquez pour fixer la nouvelle position...


Date de création :22/12/2016 @ 11:30 Dernière modification :22/12/2016 @ 11:30 Hyperlien  Prévisualiser...  Imprimer... 

Déplier Fermer  WakeOnLan

Certains rencontrent effectivement ce problème avec WakeOnLan ou IPScan32 (qui utilisent tous deux des outils du DOS) sur des versions 64 bits de Windows et Windows server.

Ceci est dû au binaire NBTSTAT qui n'est pas, sur certains systèmes 64 bits, présent dans le répertoire où il devrait se trouver (avec les autres utilitaires). Ceci ne se voit pas via l'explorateur mais cela peut se vérifier avec cet outil par exemple. Pourquoi ? Parce que le système "n'expose" pas le même dossier System32 aux processes 32 bits et 64 bits. Lorsqu'il essaye d'accéder à System32, un process 32 bits voit en réalité le contenu de c:\Windows\SysWOW64 (et c:\Windows\sysnative, ce dernier n'apparaissant d'ailleurs pas aux applis 64 bits). Ce mécanisme est expliqué ici notamment.

Pour régler le problème, j'ai trouvé une petite astuce. Je ne suis pas persuadé que des puristes Microsoft valideraient la manip, mais il s'avère que cela semble fonctionner. La voici :

  • récupérer l'exécutable NBTSTAT.EXE sur un OS de préférence équivalent mais en version 32 bits
  • le rapatrier sur le poste qui pose problème en le collant sur le bureau par exemple
  • double-cliquer sur l'icone de NBTSTAT pour l'exécuter. Une fenêtre DOS va s'ouvrir et se refermer très rapidement mais cette manip devrait être suffisante pour que le système récupère le binaire et le place dans c:\Windows\sysnative. Dès lors, vous ne devriez plus avoir le message d'erreur au lancement de l'outil.
  • si la manip précédente n'a pas fonctionné, déplacer manuellement le fichier récupéré vers c:\Windows\SysWOW64. Cette foi-ci vous ne devriez plus rencontrer le message d'erreur en lançant WakeOnLan ou IPScan32.

Date de création :06/06/2016 @ 14:48 Dernière modification :06/06/2016 @ 14:48 Hyperlien  Prévisualiser...  Imprimer... 

Prérequis matériels

Pour réveiller une machine à distance, celle-ci doit posséder une carte réseau filaire (le réveil ne fonctionne pas en WIFI) et d'un BIOS tous deux "compatibles" WOL, ce qui est le cas de la quasi totalité des machines récentes. Peu importe s'il s'agit d'un chip intégré à la carte-mère ou d'une carte additionnelle.

Sur certaines machines moins récentes - quand la carte-mère ou la carte réseau additionnelle ne sont pas en PCI 2.2, en fait - il peut être nécessaire de relier la carte réseau au connecteur WOL de la carte-mère via un petit cordon spécifique.

Configuration

En principe, l'activation du WOL se fait uniquement via le BIOS de la machine (consulter la doc de la carte-mère pour savoir comment y accéder). Selon les machines, l'option peut se nommer différemment : Power On by PCI device, Power On by LAN, WakeUp by LAN, WakeUp by PCI généralement présente dans la rubrique Power Management ou Gestion de l'Energie, in french.

Après activation dans le BIOS, si l'adaptateur réseau est dotée de leds (orange et/ou verte généralement, situées au niveau de la prise ethernet), celles-ci doivent être allumées fixes ou clignotantes lorsque le PC est éteint. Si elles restent éteintes, c'est que la carte-mère n'alimente pas ledit adaptateur réseau électriquement, donc que le réveil ne sera pas possible.

Si, malgré le réglage effectué au niveau du BIOS, la machine ne daigne toujours pas s'allumer (et que vous êtes sûr d'avoir spécifié la bonne adresse MAC et  les bons paramètres d'adresse IP, de masque et de port), sachez que certaines cartes réseau peuvent nécessiter une modification de leurs paramètres. Cette fois-ci, cela ne se passe plus dans le BIOS mais directement dans l'OS : rendez-vous dans la fenêtre des Propriétés de l'adaptateur réseau, onglet Avancé... il suffit généralement d'activer Wake on Magic Packet et de désactiver Wake on Pattern Match. Attention, ces noms peuvent changer d'un matériel à un autre...


Date de création :17/11/2007 @ 11:48 Dernière modification :13/03/2016 @ 11:48 Hyperlien  Prévisualiser...  Imprimer... 

Tout simplement en vous rendant dans les propriétés de votre carte réseau, onglet "Gestion de l'alimentation" : cocher la case "Autoriser ce périphérique à sortir cet ordinateur de la mise en veille"...


Date de création :17/11/2007 @ 11:53 Dernière modification :13/03/2016 @ 12:21 Hyperlien  Prévisualiser...  Imprimer... 

Cela signifie que la machine en question, lorsqu'elle est arrêtée, cesse d'alimenter la carte réseau. Pour le confirmer, vérifiez si les leds généralement présentes sur la prise réseau sont allumées (l'une d'elles doit d'ailleurs clignoter en principe).

Si les leds sont effectivement éteintes, regardez si le BIOS permet d'éteindre la machine dans un mode de "sommeil moins profond" , ou utilisez la veille prolongée.

Je vous invite à jeter un coup d’œil à ceci pour en savoir un peu plus sur les différents mode d'alimentation. Vous y verrez notamment que le réveil à distance :

  • est pris en charge pour les modes de veille (S3) et de veille prolongée (S4)
  • n'est pas pris en charge pour les modes arrêt (S5) et "Démarrage rapide" (à partir de Windows 8)

Toutefois, il est précisé que le réveil depuis le mode S5 peut fonctionner avec certains adaptateurs réseau, mais sans garantie.


Date de création :13/03/2016 @ 11:49 Dernière modification :13/03/2016 @ 11:49 Hyperlien  Prévisualiser...  Imprimer... 

Bien sur, le système WOL est normalisé. A partir du moment où la machine à réveiller est configurée pour, qu'importe s'il s'agit d'un PC, d'un MAC ou autre, et qu'importe son système d'exploitation.

Date de création :17/11/2007 @ 11:59 Dernière modification :17/11/2007 @ 17:26 Hyperlien  Prévisualiser...  Imprimer... 

Voir la FAQ "Dipiscan/IPScan32/WakeOnLan/WmiSysInfos - Accéder aux informations et/ou agir sur une machine à distance".


Date de création :17/11/2007 @ 12:19 Dernière modification :21/12/2016 @ 11:33 Hyperlien  Prévisualiser...  Imprimer... 

Déplier Fermer  WmiSysInfos