FAQ
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...
Ou sinon vous pouvez aussi prendre le temps de consulter le manuel (présent dans l'archive de l'appli) que je me suis enquiquiné à rédiger ! 
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 dossier %programdata%\dipisoft\DipiLanAlert\Icones
- 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).
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.
Dipiscan envoi ces messages en utilisant la commande MSG.EXE présente dans Windows depuis Vista (sauf erreur de ma part), mais uniquement à partir de la version pro donc absente des versions familiales et starter (toujours sauf erreur de ma part). Si l'option est grisée, cela signifie que l'exécutable est absent...
Si en revanche l'option est active et qu'en l'utilisant vous obtenez systématiquement le message d'erreur susmentionné (et ce même si vous êtes admin de la machine distante), voici un contournement :
Mais d'abord les prérequis :
- Etre admin de la ou des machines distantes auxquelles vous souhaitez envoyer des messages
- Avoir renseigné le compte qui va bien dans la zone "Configuration de l'accès aux postes distants" de l'onglet "Général"
- Avoir récupéré l'outil PSEXEC (ou PAEXEC), à placer dans le dossier de Dipiscan
Ce qu'il faut faire :
- créer une commande personnalisée via l'onglet correspondant de la fenêtre de configuration
- Nom : ce que vous voulez, "Envoyer un message..." par exemple
- Commande : psexec \\%ip% msg.exe * "{{Veuillez saisir le message à envoyer}}"
- Cocher la case "Nécessite une authentification sur la machine distante"
- c'est tout !
La mise en œuvre est simple : quand vous voulez envoyer un message, utilisez cette nouvelle commande personnalisée (située dans le menu contextuel, en dessous de la double barre horizontale) plutôt que la commande intégrée à l'outil. Une fenêtre s'ouvrira et vous invitera à saisir le message à envoyer ; en principe le message devrait s'afficher sur la machine distante. La première utilisation de PSEXEC nécessite en principe l'acceptation des conditions d'utilisation.
Si vous le souhaitez, vous pouvez-même ajouter des paramètres à la commande MSG.EXE qui permet, par exemple, de faire disparaître le message automatiquement au bout d'un certain délai...
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...
Attention : le mot de passe ne doit pas être vide sinon cela ne fonctionnera pas à moins de devoir modifier un réglage dans les stratégies locales de sécurité.
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 ### Configuration du firewall pour activer la réponse au ping et la réponse aux requêtes NetBIOS echo ### Activation de l'administration à distance echo ### Désactivation de l'UAC pour les appels distants :fin |
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.
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 !
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...
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 ! 
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.
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...
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.
Bien sûr, 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.
Même si je n'ai jamais eu l'occasion de tester, il semblerait même que certaines imprimantes (Konica-Minolta) soient dotées d'une compatibilité WakeOnLan.
Oui et non.
L'outil WakeOnLan n'offre pas la possibilité de planifier une opération; il permet uniquement d'agir de façon immédiate.
Mais il ne vous aura probablement pas échappé que le dossier d'installation de l'appli contient un second exécutable en plus de WakeOnLan.exe : il s'agit de WakeOnLanBatch.exe. Ce dernier permet d'exécuter les mêmes actions que l'application principale dotée d'une interface graphique, mais en mode ligne de commande.
Il est dès lors très facile de programmer le réveil ou l'extinction (mais également les autres types d'actions) d'une ou plusieurs machines en invoquant ledit WakeOnLanBatch.exe depuis le planificateur de tâches de Windows.
Pour en savoir plus sur la syntaxe à utiliser pour mettre en œuvre cet outil complémentaire, il suffit de lancer WakeOnLanBatch depuis une fenêtre d'invite de commande, sans aucun paramètre.
L'emplacement dépend de plusieurs facteurs : le type d'installation (portable ou installeur), la version de l'outil et éventuellement la façon dont il est exécuté ainsi que la configuration de l'UAC.
- si l'appli est installée et exécutée "normalement", son dossier n'est pas accessible en écriture à l'utilisateur, celui-ci se trouvant dans l'arborescence "Program Files" ou "Program Files (x86)". En conséquence, le fichier de configuration (qui porte le nom de l'appli avec une extension ".ini") est placé dans le dossier "%userprofile%\appdata\roaming\dipisoft\nom_de_l'appli".
Du moins si la version est de l'appli est récente. Dans les anciennes versions le fichier était placé dans "%userprofile%\appdata\local\virtualstore\program files\dipisoft\nom_de_l'appli" (remplacer "program files" par "program files (x86)" s'il s'agit d'un Windows 64 bits).
- si l'utilisateur a des droits d'écriture dans le dossier de l'exécutable, alors le fichier de configuration (qui porte le nom de l'appli avec une extension ".ini") doit s'y trouver. Ceci est en principe le cas pour la version "portable" (excepté si l'archive a été extraite dans "Program Files", "Program Files (x86)" ou n'importe quel dossier/lecteur dans lequel l'utilisateur n'a pas le droit d'écrire) OU si l'UAC a été désactivé OU si l'appli a été lancée "en tant qu'administrateur". Dans le cas contraire, se reporter au cas précédent.
- dans mes applis les plus récentes (identifiées par l'icone
), ce n'est pas un fichier .ini mais un fichier .json qui est utilisé pour conserver la configuration. Généralement il se trouve dans le dossier qui contient l'exécutable. Une exception toutefois : la configuration de DipiLanAlert est constituée de plusieurs fichiers .json et ils se trouvent dans le dossier "%programdata%/dipisoft/DipiLanAlert".
N'hésitez pas à me contacter en cas de problème.
Ç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 l'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.
Si ce n'est pas le cas, cliquez sur ledit icone ou sélectionnez l'application en faisant autant de ALT+TAB que nécessaire.
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).
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 "collera" au pointeur et se déplacera avec lui... Faites un clic-gauche pour fixer sa nouvelle position, le tour est joué !
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 au lieu de "Déplacer". 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...
