IACA

Version 10. Auteur A. Sayer


Dépannage


Cliaca2kp bavard

Sur une station à problème, vous pouvez remplacer provisoirement le programme Cliaca2kp et le service IACA local SvCliaca.exe par les versions bavardes de ces programmes. Ces versions ajouteront des lignes dans le fichier IACA.LOG de la station.

- Installez le client bavard sur une station. Choisissez par exemple 15 minutes.
- Avant la fin des 15 minutes, ouvrez la session avec un compte IACA afin de rencontrer le problème.
- Vous pourrez alors m'envoyer le fichier IACA.LOG pour que je l'analyse.

Les autres stations du réseau ne sont pas affectées par ce changement et le retour à la version normale se fera automatiquement sur cette station au bout d'un temps donné.

N'utilisez le client bavard que si vous êtes en version 10 de IACA sur votre serveur.

Télécharger CreerClientBavard si vous voulez rechercher un disfonctionnement du client IACA.

Attention si votre version de IACA est inférieure à la 34 téléchargez CreerClientBavard1033R


Surveillance des services IACA

Le programme SurveilleService permet de vérifier que le service IACA est fonctionnel sur les serveurs. Il vérifie en permanence que chaque service répond correctement et au cas où un service ne donnerait pas de réponse (par exemple serveur arrêté ou déconnecté ou service arrêté) indique l'erreur et le temps de non fonctionnement du service.

Si le serveur est fonctionnel et que le service est arrêté, alors SurveilleService est capable de redémarrer automatiquement le service.

Un fichier LOG est créé afin de conserver une trace des anomalies rencontrées.

Ce programme peut être exécuté sur un serveur DC, sur un serveur membre ou sur une station. La surveillance ne nécessite pas de droits particuliers mais le redémarrage des services ne réussira que si ce programme est exécuté par un administrateur du domaine.

Si vous n'exécutez pas ce programme sur un serveur DC alors vous devez indiquer en paramètre le chemin complet pour accéder au fichier Domaines.xml.
SurveilleService  \\UnServeur\Netlogon\Domaines.xml

Si vous exécutez ce programme sur une station, pensez que les XP SP2 et XP SP3 (TCPIP.SYS non patchés) ne permettent pas de surveiller un grand nombre de serveurs.

Il n'est pas nécessaire que IACA soit installé sur l'ordinateur qui utilise ce programme.


TestService

TestService.zip contient TestService.exe

Date : 03/12/2012 Version 2.00
Nécessite au moins IACA version 10.06.

Ce programme permet de vérifier que le service IACA fonctionne sur les serveurs IACA.

Exécutez ce programme sur une station avec les droits d'administrateur de la station.

Mettez le nom du serveur IACA ou son adresse IP et utilisez les boutons "Test'.


InfoApi

InfoApi.zip contient InfoApi.exe

Date 30/03/2017 Version 1.06

Permet d'afficher quelques variables systèmes.


Quick Launch et Windows 7

Vous obtenez des icônes (à droite du bouton démarrer) qui sont blanches ou qui ne fonctionnent pas. Vous avez certainement fait "Appliquer" afin de "Copier les raccourcis du lancement rapide" alors que vous étiez encore en version 9. Il faudrait le refaire maintenant, cela aura pour effet de créer dans le dossier Parciaca\nomsousparc\nommodele un fichier Taskband.iac nécessaire à ces raccourcis.

Icônes du bureau et Windows 7

Depuis la version 10.20 de IACA il est possible que le bureau comporte des icônes non souhaitées, comme "Ordinateur" ou "Réseau" ou une icône au nom de l'utilisateur... Cela est dû à une meilleure prise en compte des icônes du bureau par IACA.

Voici deux solutions au choix. Quelle que soit la solution choisie, vous devez avec Modèles cocher "Appliquer le thème".

Solution 1

Ouvrir la session sur un ordinateur du sous parc avec l'administrateur de modèles. Allez dans "Panneau de configuration > Apparence et personnalisation > Personnalisation > Changer les icônes du bureau". Cochez toutes les cases situées dans la zone "Icônes du bureau", faites "Appliquer" puis décochez les cases que vous ne souhaitez pas (on pourra ne laisser que la coche devant "Corbeille"), faites à nouveau "Appliquer".

Utilisez ensuite l'icône IACA et faites "Appliquer", lorsque le fichier themepack vous est demandé vous devez en choisir un (même si c'est celui qui est déjà utilisé) et utiliser le bouton "Copier ce fichier vers le serveur". Cela aura pour effet de copier vers le serveur en plus du thème un fichier nommé "Paramtheme.iac".

Solution 2 :

Téléchargez : Paramtheme.zip il contient Paramtheme.iac

Mettez le fichier Paramtheme.iac sur le serveur IACA dans le dossier \PARCIACA\nom du sous-parc contenant des W7\nom du modèle
Cela aura pour effet de montrer l'icône "Corbeille" et de ne pas montrer les icônes "Ordinateur", "Fichier de l'utilisateur", "Réseau" et "Panneau de configuraion". 


Changement de nom des groupes

Les groupes de premier niveau n'ont pas changé de nom lors du passage de la version 9 à la version 10. ADMINMOD, ELEVES, PROFS... correspondent aux groupes de même nom.

Les groupes de deuxième niveau sont maintenant nommés avec un nom composé. Par exemple le groupe de la classe TERM1 placé dans ELEVES aura pour nom de groupe ELEVES-TERM1. Ce nom peut être vu dans la partie en haut à droite de la fenêtre IACA lorsque vous êtes placé sur un groupe.

Cela signifie que dans Modeles, vous aurez peut-être quelques corrections à faire si vous avez indiqué des groupes de deuxième niveau dans le volet "Concernés".

Les dossiers situés dans CLASSES utilisent le nom du groupe. Si vous avez paramétré des lecteurs réseaux vers des sous-dossiers de classes, vous aurez à corriger le chemin. Si par exemple vous avez connecté un lecteur réseau en utilisant la variable %REPBASE% pour accéder à un sous-dossier de classes, il faudra corriger le chemin en utilisant la nouvelle variable %REPCLASSE%
Le chemin \\%SERVCLASSES%\CLASSES convient en version 9 et en version 10
Le chemin \\%SERVCLASSES%\CLASSES\%REPBASE% convient en version 9 mais pas en version 10.
Le chemin \\%SERVCLASSES%\CLASSES\%REPCLASSES% convient en version 10 mais pas en version 9.


Auto_Inter, Observe et XP SP2 ou SP3

Le SP2 et le SP3 de XP limitent à 10 le nombre de connexions ayant échoué (Microsoft à fait cette limite pour réduire les risques de propagation des vers comme sasser et autres). Auto_Inter et Observe essaient d'établir des connexions avec les stations en utilisant des adresses IP. Certaines connexions échouent (station arrêtée ou absente) et XP compte cette tentative de connexion comme une attaque potentielle (il est vrai qu'un virus utilise une méthode semblable pour trouver d'autres ordinateurs afin de se propager).

Il existe un correctif qui modifie très légèrement le fichier tcpip.sys afin de modifier cette limite. Ce correctif ne vient pas de Microsoft, il semble cependant donner toute satisfaction.
Vous pouvez le trouver à l'adresse
http://www.lvllord.de

Le fichier que j'ai testé s'appelle EvID4226Patch223d-en et correspond à la version 2.23d. La version actuellement proposée est peut-être plus récente (existe en anglais et allemand).

Exemple d'utilisation dans une fenêtre dos afin d'augmenter la limite de 10 à 10000 :
EvID4226Patch223d-en   /L=10000

À effectuer sur les ordinateurs XP SP2 ou SP3 sur lesquels vous voulez exécuter le programme Auto_Inter ou le programme Observe. Inutile de l'exécuter sur les stations des élèves.


Vérifier les réplications

Sites et Services Active Directory

Afin de vérifier que vos serveurs communiquent correctement, il est important de vérifier de temps en temps le fonctionnement de la réplication.

Supposons que vous avez deux serveurs SERVA et SERVB. Les dernières modifications que vous avez faites ont été faites sur SERVA. On peut donc considérer que l'Active Directory de SERVA est à jour et que l'Active Directory de SERVB devrait être identique. Nous allons vérifier que la réplication fonctionne correctement.

Placez-vous par exemple sur SERVA et allez dans "Outils d'administration" et "Sites et Services Active Directory". Déployez l'arborescence comme dans la copie d'écran :

Pour répliquer SERVA vers SERVB, on se place sur SERVB puis sur "NTDS Settings" et on clic droit sur "Généré automatiquement à partir de SERVA".

Si la réplication a réussi vous pouvez la vérifier en cliquant sur SERVA, puis "NTDS Settings" et en effectuant une réplication de SERVB vers SERVA.

Si la réplication a échoué ne la faites pas de SERVB vers SERVA car vous risqueriez de copier des données qui ne sont pas à jour. Vous devez commencer par corriger le problème en vous aidant du paragraphe suivant.

Netlogon

Vérifiez qu'un fichier ou dossier créé dans le Netlogon d'un serveur se réplique immédiatement (quelques secondes) vers les netlogon des autres serveurs. Supprimez ensuite ce fichier ou dossier, il doit se supprimer également dans les autres netlogon.

Avec IACA

Si vous utilisez DFS, vous pouvez avec IACA vous placer sur "Servers" et utilisez les boutons "Vérifier DFS..."

Observateur d'événements

L'observateur d'événements permet également de voir les disfonctionnements.


La réplication ne fonctionne plus entre vos contrôleurs de domaine

Active Directory ne se réplique plus

Vous avez au moins deux contrôleurs de domaine dans votre domaine et vous constatez qu'une modification dans Utilisateurs et Ordinateurs Active Directory sur un contrôleur de domaine ne se retrouve pas sur un ou plusieurs autres contrôleurs du domaine.

Ce problème peut également se voir en allant dans "Sites et Services Active Directory". Lorsque vous voulez faire "Répliquer maintenant" vous obtenez une erreur de réplication.

Déterminez le mauvais serveur. Si l'un des serveurs n'est pas à jour, ce sera lui. Si tous les serveurs sont à jour, vous choisirez de préférence un serveur qui ne possède pas les rôles. Sauf modification de votre part, le serveur qui possède les rôles est le serveur sur lequel Active Directory a été installé en premier.

Jusqu'à Windows 2003, une solution simple existe cependant elle ne fonctionne pas toujours. Essayez-la et si elle ne fonctionne pas, vous pourrez utiliser l'autre solution.

Solution simple avec la base de registre (Windows 2000 ou 2003)

Téléchargez Replication.zip. Il contient ForceReplication.reg et RetablitReplication.reg.

Si avec "Sites et Services Active Directory", en vous plaçant sur Servers > SERVA > NTDS Settings > Généré automatiquement depuis le serveur SERVB" donne une erreur de durée de désactivation alors c'est que SERVA ne fait plus confiance à SERVB. Agissez alors sur SERVA.

Exécutez ForceReplication.reg sur le serveur qui ne fait plus confiance. Il n'est pas nécessaire de redémarrer le serveur.
C'est en général immédiat, cependant attendez quelques minutes. Si au bout d'une demi-heure la réplication ne fonctionne toujours pas, essayez la deuxième solution.

Dans tous les cas, exécutez RetablitReplication.reg afin de rétablir la base de registre et permettre le fonctionnement normal de la réplication.

Solution en rétrogradant puis en promouvant le serveur en panne.

Jusqu'à Windows 2008 : Placez-vous sur le mauvais serveur et exécutez DCPROMO. Indiquez que votre serveur n'est pas le dernier contrôleur de votre domaine. A la fin de l'opération le serveur redémarre. 

A partir de Windows 2012 : Supprimez le rôle "Services AD DS". Vous serez alors informé que vous devez déjà "Rétrograder le contrôleur de domaine". Rétrogradez-le. A la fin de l'opération le serveur redémarre. Il ne sera pas nécessaire de supprimer complètement le rôle.

Malheureusement la rétrogradation ne fonctionne pas toujours, surtout que ce travail est en général effectué lorsque les serveurs ne communiquent plus. Le mauvais serveur n'est alors pas capable d'informer les autres serveurs qu'il souhaite ne plus être contrôleur de domaine. Heureusement il y a une solution. Il est cependant vivement conseillé d'effectuer cette rétrogradation sur un serveur qui ne possède pas les rôles FSMO.

Jusqu'à Windows 2008 : Remplacez DCPROMO par DCPROMO  /FORCEREMOVAL

A partir de Windows 2012 : La procédure de rétrogradation vous donne la possibilité de forcer.

ATTENTION : Si vous avez été obligé de forcer, un "nettoyage" s'impose :

- Sur un bon serveur, dans Utilisateurs et Ordinateurs Active Directory, allez dans "Domain Controllers" et supprimez le mauvais serveur. Vous aurez à préciser que le serveur en question est définitivement hors service.
- Sur un bon serveur, dans "Sites et Services Active Directory", placez-vous sur "Servers" puis ouvrez le mauvais serveur, ouvrez "NTDS Settings" et supprimez le "généré automatiquement". Supprimez ensuite le "NTDS Settings" puis supprimez le mauvais serveur. Il ne doit plus y avoir de référence à ce mauvais serveur.
- Revenez sur le mauvais serveur et supprimer le dossier SYSVOL qui se trouve dans Windows. La suppression risque d'échouer, si c'est le cas allez dans "Sécurité" et forcez la sécurité pour que votre compte "Administrateur" soit propriétaire et ait tous les droits sur ce dossier ainsi que sur ce qu'il contient. Supprimez ensuite SYSVOL.
- Si le mauvais serveur possédait un ou des rôles FSMO, il est nécessaire de forcer ce ou ces rôles sur un bon serveur. Cela se fait en se plaçant sur un bon serveur et en utilisant NTDSUTIL.

Vous pouvez maintenant ajouter ce serveur comme contrôleur supplémentaire pour votre domaine, pour cela :

Jusqu'à Windows 2008 : Utilisez à nouveau DCPROMO et indiquez qu'il s'agit d'un contrôleur supplémentaire pour votre domaine.

A partir de Windows 2012 : Faites "Promouvoir ce serveur en contrôleur de domaine"  et indiquez qu'il s'agit d'un contrôleur supplémentaire pour votre domaine.

Si tout s'est bien passé, vérifiez que la réplication fonctionne à nouveau correctement par exemple en créant un utilisateur dans "Utilisateurs et Ordinateurs Active Directory" ou en utilisant "Sites et Services Active Directory".

Il est possible que tout fonctionne à nouveau correctement à l'exeption des partages SYSVOL et NETLOGON.

SYSVOL et NETLOGON ne se répliquent pas ou plus.

Dans ce paragraphe il est supposé que la réplication Active Directory fonctionne (si ce n'est pas le cas, reportez-vous au paragraphe précédent).

Problème

Vous avez deux contrôleurs de domaine ou plus et la réplication des dossiers SYSVOL et NETLOGON ne fonctionne plus.
Vous pouvez également être dans le cas où vous venez d'ajouter un contrôleur de domaine à votre domaine et sur ce contrôleur de domaine le dossier partagé sous le nom NETLGON n'apparaît pas.

Principe

Le principe consiste à choisir un contrôleur de domaine ayant un bon NETLOGON (si possible celui qui a le rôle PDC) qui va servir de référence pour les autres.

Si le contrôleur de domaine ayant un bon NETLOGON n'est pas celui qui a le rôle PDC et que le PDC possède NETLOGON, vous pouvez copier le contenu du bon NETLOGON dans le NETLOGON du PDC puis utiliser le PDC comme contrôleur de domaine de référence.

Si vous n'avez que deux contrôleurs de domaine, l'un est "le contrôleur de référence" et l'autre est "le contrôleur en panne". Si vous avez plus que deux contrôleurs de domaine, les autres seront appelés dans la suite "les autres contrôleurs de domaine".

Seuls les serveurs ayant le rôle contrôleur de domaine sont concernés par ce travail.

Quelle solution adopter ? Cela dépend du service utilisé pour la réplication SYSVOL. Si vous avec le service "Réplication DFS" c'est la solution avec DFS-R qui convient sinon c'est la solution avec FRS. Vous pouvez également déterminer quelle solution choisir en tapant NET STOP DFSR

Si vous avez l'erreur 1060, c'est que le service n'est pas installé. Choisissez "Solution avec FRS"
Si le service s'arrête, alors tapez NET START DFSR pour le redémarrer et choisissez "Solution avec DFS-R"

Solution avec FRS

Sur tous les contrôleurs de domaine de votre domaine, arrêtez le service "Service de réplication de fichiers" par exemple en tapant NET STOP NTFRS.

Placez-vous sur le serveur de référence. Il s'agit de le configurer pour que la réplication de SYSVOL soit définie comme autoritaire. Pour cela avec Regedit placez-vous à la clé :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx

xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx est une chaîne qui dépend de votre serveur.

Si la clé "Cumulative Replica Sets" n'existe pas, c'est certainement que vos serveurs n'utilisent pas FRS et que c'est la solution avec DFS-R que vous devriez utiliser.

Modifiez la variable BurFlags (qui contient normalement 0) en lui mettant la valeur hexadécimale D4

Important : La valeur D4 sera comprise par NTFRS comme autoritaire alors que la valeur D2 sera comprise comme non autoritaire.

Les autres serveurs doivent maintenant être configurés pour que la réplication de SYSVOL soit définie comme non autoritaire pour cela, sur chaque autre serveur utilisez Regedit et allez à la clé 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\yyyyyyyy-yyyy-yyyy-yyyyyyyyyyyyyyyy

yyyyyyyy-yyyy-yyyy-yyyyyyyyyyyyyyyy est une chaîne qui dépend de votre serveur.

Modifiez la valeur de la variable BurFlags  (qui contient normalement 0) en lui mettant la valeur hexadécimale D2.

Sur tous les serveurs démarrez le service "Service de réplication de fichiers" par exemple en tapant NET START NTFRS

La réplication doit à nouveau fonctionner et les variables BurFlags sont automatiquement remises à 0.

Source (décembre 2015) : https://support.microsoft.com/en-us/kb/290762

Solution avec DFS-R

Placez-vous sur le contrôleur en panne.

Il s'agit de définir la réplication SYSVOL comme non autoritaire. Démarrez ADSIEDIT.MSC afin de démarrer le programme  "Modification ADSI".

Ouvrez "OU=Domain Controllers" puis "CN=(le nom du serveur en panne) puis "CN=DFSR-LocalSettings" puis " CN=Domain System Volume". Allez dans les propriétés de " CN=SYSVOL Subscription".

Modifiez la variable "msDFSR-Enabled" (qui est par défaut "non définie") pour la mettre à FALSE et validez.

Forcer la réplication AD vers les autres serveurs. Cela peut se faire avec " Sites et Services Active Directory".

Pour informer le service DFS-R qu'il doit prendre en compte cette valeur, tapez (dans une fenêtre dos avec les droits Administrateur) : DFSRDIAG POLLAD

Modifiez à nouveau la variable "msDFSR-Enabled" pour la mettre maintenant à TRUE et validez.

Forcer la réplication AD vers les autres serveurs. Cela peut se faire avec " Sites et Services Active Directory".

Pour informer le service DFS-R qu'il doit prendre en compte cette nouvelle valeur, tapez comme précédemment : DFSRDIAG POLLAD

Placez-vous sur le serveur de référence.

Il s'agit de définir la réplication SYSVOL comme autoritaire. Démarrez ADSIEDIT.MSC afin de démarrer le programme "Modification ADSI".

Ouvrez "OU=Domain Controllers" puis "CN=(le nom du serveur de référence) puis "CN=DFSR-LocalSettings" puis " CN=Domain System Volume". Allez dans les propriétés de " CN=SYSVOL Subscription".

Modifiez la variable "msDFSR-Enabled" (qui est par défaut "non définie") pour la mettre à FALSE. Modifiez également  msDFSR-Options (qui contient par défaut 0) pour la mettre à 1 et validez.

C'est la valeur 1 mise dans msDFSR-Options qui va activer le mode autoritaire pour ce serveur de référence.

Tout en restant sur ce serveur, nous allons en profiter pour modifier les "Autres contrôleurs de domaine" (si bien sûr vous avez plus de deux contrôleurs de domaine)

Pour chaque autre contrôleur de domaine, ouvrez "OU=Domain Controllers" puis "CN=(le nom d'un autre contrôleur) puis "CN=DFSR-LocalSettings" puis " CN=Domain System Volume". Allez dans les propriétés de " CN=SYSVOL Subscription".

Modifiez la variable "msDFSR-Enabled" (qui est par défaut "non définie") pour la mettre à FALSE et validez.

Forcer la réplication AD vers les autres serveurs. Cela peut se faire avec " Sites et Services Active Directory".

Pour chaque serveur autre que le serveur en panne, mettez "msDFSR-Enabled" à TRUE et validez.

Sur le serveur de référence ouvrez une fenêtre DOS en tant qu'administateur. Redémarrez le service DFSR par exemple en tapant NET STOP DFSR puis NET START DFSR puis demandez au service de prendre en compte les changements en tapant DFSRDIAG POLLAD

La réplication doit à nouveau fonctionner et la valeur de msDFSR-Options doit automatiquement revenir à 0.

Source (décembre 2015) : https://support.microsoft.com/fr-fr/kb/2218556


Forcer les rôles FSMO sur un contrôleur de domaine

N'utilisez cette procédure que si un contrôleur de domaine est en panne et que celui-ci possédait au moins un des 5 rôles.

Dans un fonctionnement normal, les rôles peuvent être passés d'un contrôleur à un autre en utilisant les outils graphiques (Utilisateurs et Ordinateurs Active Directory, Domaines et Approbation Active Directory...).

Dans un fonctionnement normal, si vous rétrogradez un contrôleur alors qu'il possédait au moins un rôle alors le ou les rôles sont automatiquement attribués à un autre contrôleur du domaine.

Si vous avez été obligé de rétrograder un contrôleur en forçant et que ce contrôleur possédait au moins un rôle alors il sera nécessaire de forcer des rôles.

Les lignes suivantes permettent de donner les 5 rôles au serveur "serva" dans le domaine "dom.priv" (à faire sur un bon serveur en remplaçant serva.dom.priv par ce qui convient) :

ntdsutil
roles
connections
connect to server serva.dom.priv
quit
seize infrastructure master
Sur 2000 et 2003 : seize domain naming master
Sur 2008, 2012 et 2016 : seize naming master
seize schema master
seize PDC
seize RID master
quit
quit


Messages d'erreur

Les messages peuvent être affichés sous la forme d'un numéro ou sous la forme d'une phrase. Voici une liste de numéros avec leur signification : Messages d'erreur


Ports utilisés par IACA

Si vous constatez une mauvaise communication entre les stations et les serveurs, peut-être qu'un pare-feu bloque des ports nécessaires à IACA.

Voici la liste des ports utilisés par IACA : Liste des ports


Pare-feu des Antivirus

IACA ouvre les ports dont il a besoin dans le pare-feu de Windows mais n'agit pas sur les pare-feux des différents logiciels antivirus.

Si vous n'utilisez pas le pare-feu de l'antivirus et que vous laissez le pare-feu de Windows, vous n'avez rien à faire.

Si vous tenez tout de même à utiliser le pare-feu de votre antivirus, vous devez vous même ouvrir les ports nécessaires en vous aidant du paragraphe "Ports utilisés par IACA"


Client IACA et Antivirus

OfficeScan de Trend

Depuis juin 2013 OfficeScan détecte le client IACA comme un virus et supprime Cliaca2kp.exe sur le serveur et sur les stations. Il est donc nécessaire d'indiquer à OfficeScan qu'il doit exclure Cliaca2kp.exe dans le scan en temps réel.

 

Sur le serveur, dans la console OfficeScan, allez dans "Ordinateurs en réseau > Gestion des clients > Paramètres > Paramètres de scan en temps réel."

Dans la partie "Liste d'exclusion de scan (fichiers)" cochez "Ajout des chemins d'accès à la liste d'exclusion de l'ordinateur client" et ajoutez les chemins comme sur la copie d'écran ci-contre.

Faites "Appliquer à tous les clients".

 

Faire le même travail pour les autres paramètres de scan

Kaspersky et Avast

Certains antivirus comme Kaspersky et Avast bloquent le client IACA. Il est en général possible de paramétrer l'antivirus afin de mettre des programmes en zone de confiance.

Voici les programmes utilisés par le client IACA et qu'il est peut-être nécessaire de mettre en zone de confiance :

Programmes utilisés

Détails

C:\Windows\System32\Cliaca2kp.exe

Première partie du client IACA qui correspond à la fenêtre récapitulative

Si Windows est en 64 bits :
C:\Windows\SysWow64\Svcliaca.exe

Si Windows est en 32 bits :
C:\Windows\System32\Svcliaca.exe

Service qui tourne en permanence sur la station.

C:\Windows\CliacaPro.exe

Deuxième partie du client IACA qui correspond à l'icône de la barre des tâches.

\\serv\NETLOGON\Cliaca2kp.exe

Utilisé lorsque le client est en version 9 et qu'il doit se mettre à jour vers la nouvelle version. Remplacez serv par le nom du serveur du domaine de la station. Si ce domaine possède plusieurs serveurs AD, mettez une ligne par serveur.

\\serv.dom.priv\NETLOGON\Cliaca2kp.exe

Utilisé lorsque le client doit se mettre à jour vers une nouvelle version. Remplacez serv.dom.priv par le nom complet du serveur du domaine de la station. Si ce domaine possède plusieurs serveurs AD, mettez une ligne par serveur.

C:\Windows\iaca\MajSrv.exe

Utilisé lorsque le client doit se mettre à jour vers une nouvelle version.


Recherche panne ou disfonctionnement du client IACA

Lorsque le client IACA rencontre une erreur, il ajoute une ligne dans le fichier iaca.log qui se trouve dans C:\Windows\IACA de la station.
Si, avec IACA sur le serveur, vous avez dans "Outils" choisi de "Faire remonter la config des stations" alors vous retrouver le fichier iaca.log de chaque station (en plus d'autres informations) dans le dossier C:\StationsIACA du serveur choisi.

Il faut distinguer l'ouverture de session proprement dite du chargement du client IACA.

Lenteur à l'ouverture de session proprement dite

Dès que le nom et le mot de passe de l'utilisateur ont été saisis, l'ouverture de session commence. Une communication avec un contrôleur du domaine permet de vérifier le nom et le mot de passe. Cette phase peut être longue voire très longue en cas de mauvais paramétrage DNS.

Le profil de l'utilisateur est alors utilisé ou créé sur la station. Le profil se compose de certaines entrées dans la base de registre et du dossier en général au nom de l'utilisateur situé dans C:\Users (à partir de Vista) ou C:\Documents and Settings (avant Vista).

Si l'utilisateur est paramétré pour utiliser le profil iaca local et que le dossier C:\Profils\IACA ou C:\Profils\IACA.V2 ou C:\Profils\IACA.V5 ou C:\Profils\IACA.V6 (suivant les versions de WIndows) existe, alors l'utilisateur reçoit une copie de ce répertoire dans son profil. Si le profil de l'utilisateur existait déjà sur la station, il est écrasé par le profil iaca local.

Si l'utilisateur est paramétré pour ne pas utiliser de profil itinérant (pas de profil iaca local par exemple) alors deux cas peuvent se produire :
Si le profil de l'utilisateur existe déjà sur la station alors il est utilisé.
Si le profil de l'utilisateur n'existe pas encore sur la station, l'utilisateur reçoit une copie du profil par défaut (Default user). La création d'un nouveau profil peut durer assez longtemps. Par exemple plus de 30 secondes avec Windows 7 et souvent plus de deux minutes avec Windows 10.

Lenteur ou erreur lors du chargement du client IACA

Lorsque le profil est chargé ou créé, le client IACA démarre. En fonctionnement normal, la durée d'exécution du client IACA est entre 2 et 8 secondes et peut éventuellement atteindre une quinzaine de secondes. Vous pouvez connaître cette durée en utilisant le client Bavard. Après avoir ouvert une session, regardez le fichier iaca.log sur la station. Il se termine en indiquant la durée d'exécution du client IACA. Par exemple :

... Cliaca2kp.exe (Bavard) Arrêt de C:\Windows\system32\Cliaca2kp.exe Durée totale=2434ms

Qui montre que le client IACA a durer environ 2 secondes et demi.

Cas particulier : A partir de Vista, si le client IACA a besoin de proposer plusieurs modèles (c'est en général le cas pour les administrateurs de modèles qui ont les modèles définis en plus du modèle Windows Normal) alors le client IACA mettra au minimum 30 secondes pour démarrer. Il s'agit d'une nouvelle contrainte de sécurité de Microsoft.
Si vous avez ouvert la session en étant administrateur de modèles, que vous avez choisi un modèle autre que Windows Normal et que vous voulez ouvrir à nouveau la session alors vous pouvez éviter les 30 secondes en utilisant la petite icône IACA et en utilisant "Futur Modèle".
Vous pouvez ne pas attendre les 30 secondes mais ce sera toujours le premier modèle qui s'appliquera. Pour choisir un autre modèle vous pourrez utiliser "Futur Modèle". Ce paramétrage se fait dans la définition du parc, volet "Divers".

Lenteur anormale du client IACA

Le client peut mettre plus de temps, voire beaucoup plus de temps. Il faut alors essayer de trouver la cause et la corriger. La plupart des erreurs seront signalées dans le fichier iaca.log qui se trouve dans C:\Windows\IACA sur la station. Différents cas sont envisagés ci-après.

Lenteur à cause d'un serveur absent

Si le fichier iaca.log contient une ligne ressemblant à celle-ci :

... Cliaca2kp.exe (ERREUR) Impossible de connecter V: à \\SERV3\public Erreur : Nom de réseau introuvable

Cela montre que le client IACA a demandé à Windows de rechercher SERV3 et ce serveur n'a pas été trouvé. Windows peut mettre plusieurs secondes avant d'indiquer au client IACA que ce serveur n'a pas été trouvé, ce qui ralentit le client IACA. Si vous utilisez IACA Pro et que vous avez plusieurs serveurs, il serait intéressant de ne pas utiliser le nom du serveur mais de profiter des variables de IACA. Par exemple \\%servperso%\Public (avec Public lié par DFS) fonctionnera même si un des serveurs est arrêté.

Au lieu de connecter un lecteur réseau, vous pouvez avoir le même type d'erreur avec une imprimante réseau (avec chemin commençant par \\ ).

Lenteur à cause d'un partage absent ou non autorisé

Si le fichier iaca.log contient une ligne ressemblant à celle-ci :

...  Cliaca2kp.exe (ERREUR) Impossible de connecter V: à \\SERV-PEDA\XYZ Erreur : L’opération demandée n’a pas été effectuée car l’utilisateur n’a pas été authentifié

Cela montre que le serveur SERV-PEDA a été trouvé mais qu'il ne comporte pas de dossier partagé sous le nom XYZ ou, s'il en contient un, que l'utilisateur n'a pas de droit sur ce dossier.

Au lieu de connecter un lecteur réseau, vous pouvez avoir le même type d'erreur avec une imprimante réseau (avec chemin commençant par \\ ).

Lenteur à cause du service iaca local

Si vous voyez ce type de lignes dans iaca.log :

... Cliaca2kp.exe (ERREUR) Le service local IACA n'a toujours pas répondu au bout de 60 secondes.
... Cliaca2kp.exe (ERREUR) Le service iaca de la station ne semble par répondre. Il faudrait réinstaller le client IACA. Le fichier spécifié est introuvable
... Cliaca2kp.exe (ERREUR) Erreur (Le fichier spécifié est introuvable) en corrigeant la sécurité de C:\Windows\Cacheiac

Cela montre que le service IACA local de la station est arrêté (ce qui ne devrait pas se produire).

Lenteur avec "Time out" ou "Dépassement du délai d'attente"

Voici un exemple de ligne dans iaca.log montrant qu'une action a pris trop de temps :

... Cliaca2kp.exe (ERREUR) Erreur (Dépassement du délai d'attente) en corrigeant la sécurité de C:\Windows\Cacheiac

Le client IACA a demandé au service iaca local de la station de vérifier (et corriger si nécessaire) la sécurité du dossier Cacheiac et le service n'a pas répondu dans un temps raisonnable. Ceci peut se produire si le service iaca local est très occupé (mais cela ne devrait pas se produire) ou s'il est bloqué par exemple par un antivirus. Voir le paragraphe "Client IACA et antivirus"

D'autres erreurs peuvent correspondent à la même cause, comme par exemple :

... Cliaca2kp.exe (ERREUR) Erreur dans limiter aux applications autorisées : Dépassement du délai d'attente
... Cliaca2kp.exe (ERREUR) Erreur en modifiant la clé Run pour appel de CliacaPro

Le client IACA indique qu'il s'agit d'une version de démonstration

Si votre version n'est pas une version de démonstration, ce message ne devrait pas apparaître. Vous pouvez vérifier que votre version n'est pas une version de démonstration à l'aide IACA sur le serveur en utilisant le menu "?" et "A propos..."

Cette erreur se produit lorsque le client IACA n'est pas parvenu pendant au moins 8 jours à lire le fichier Cliaca.dat qui est dans Netlogon du serveur alors que le serveur est présent. D'une façon générale, l'accès en lecture à Netlogon doit toujours être possible pour tous les utilisateurs.

Erreur en accédant à Netlogon

Plusieurs causes sont possibles :

- Les autorisations de partage ou de sécurité ont été changées sur le dossier Netlogon du serveur. Certains administrateurs débutants pensent bien faire en modifiant les autorisations sur Netlogon alors que celles-ci ont été établies finement par Windows et ne doivent pas être modifiées.

- La découverte du réseau est désactivée sur la station. Cela peut gêner l'accès aux dossiers partagés des serveurs. Avec Windows 7, allez dans "Panneau de configuration > Réseau et Internet > Centre Réseau et partage > Paramètres de partage avancés" Dans la partie "Domaine" vérifiez que "Activer la découverte de réseau" est cochée.

- La commander exécuter a été interdite à l'aide du programme "Modeles". L'utilisateur peut alors recevoir le message "L'accès à la ressource \\serveur\netlogon n'est pas autorisé".

Le chemin \\ nom complet du domaine \ netlogon donne l'erreur 53 qui correspond à "Le chemin réseau n'a pas été trouvé"

Avec XP dans "Démarrer" et "Exécuter", vous saisissez une adresse ressemblant à \\domaine.priv\netlogon et vous avez l'erreur ci-dessus. Cela peut venir du service "Assistance TCP/IP Netbios" qui n'est pas démarré. Exécutez "Services.msc", recherchez ce service et mettez ce service en "Automatique", faites "Appliquer" et démarrez ce service.

Erreur en accédant au dossier du sous-parc

...Cliaca2kp.exe (ERREUR) Erreur (Échec d’ouverture de session : nom d’utilisateur inconnu ou mot de passe incorrect) en rapatriant le dossier du sous-parc XXXX

La station a peut-être besoin d'être réinscrite dans le domaine. Cela peut se produire par exemple si vous venez de restaurer votre station, elle est alors revenue dans l'état qu'elle avait à une date antérieure et n'est plus reconnue par le domaine.

Lenteur lors du rapatriement du dossier AppData ou Local AppData

Si vous avez choisi dans le modèle de Synchroniser au moins un de ces dossiers, il est possible que le client IACA mettre du temps à le rapatrier. Le client IACA ne rapatrie que ce qui manque ou ce qui n'est pas à jour afin de réduire au maximum le trafic réseau. Cependant, si le dossier est anormalement volumineux, la durée peut être grande.

Certains programmes d'installation se décompressent dans un de ces dossiers (au lieu d'utiliser le dossier temporaire). Vérifiez donc la taille de ces dossiers et supprimez les fichiers qui ne servent plus.

A partir de Vista, il est possible que plusieurs thèmes soient retenus dans Local AppData. Si c'est le cas, l'administrateur de modèles devrait commencer par supprimer les thèmes inutiles avant de copier le profil. Pour supprimer les thèmes inutiles, faire un clic droit sur le bureau et choisir "Personnaliser". Dans la zone "Mes thèmes" faites un clic droit sur les thèmes inutilisés et faites "Supprimer le thème".


Le menu démarrer s'affiche en anglais

Description du problème

Depuis Vista, les noms des dossiers du menu démarrer sont en anglais mais Windows les affiche en français à condition que le fichier Desktop.ini soit présent, avec les attributs caché et système. De plus ce fichier doit contenir les informations nécessaires (LocalizedResourceName et / ou LocalizedFileNames).

Remède

Si par exemple vous constatez que pour un modèle donné, le dossier "Accessoires" ou "Jeux" apparaît sous le noms réel "Accessories" ou "Games" alors, voici un moyen de rétablir les noms français :

Ouvrez la session avec le compte administrateur de modèles et choisissez le modèle à corriger. utilisez la petite icône IACA de la barre des tâches. Utilisez le bouton "Information" puis "Aide raccourcis". Cliquez sur "Menu dém. normal". L'exploreur s'ouvre en montrant le dossier "Menu démarrer". Ouvrez "Programmes", ouvrez "Accessoires".

Comme le fichier que l'on cherche est caché et système, vous devez afficher les fichiers cachés et ne pas masquer les fichiers protégés par le système. Vous devez maintenant voir dans ce dossier le fichier Desktop.ini. Ce fichier contient les informations relatives au dossier Accessoires. Faites un "Copier" sur ce fichier.

Reprenez la petite icône IACA, "Information", "Aide raccourcis" et cliquez sur "Menu dém actuel". Ouvrez "Programmes" puis "Accessories" et collez le fichier dans ce dossier. Attention, ne copiez pas ce fichier dans un autre dossier, il convient seulement au dossier Accessoires.

Vous pouvez procéder de façon analogue pour "Accessibility" afin qu'il s'affiche "Options d'ergonomie" etc.

Pour "Games" qui devrait s'afficher "Jeux", vous pouvez utiliser la même méthode mais il faudra ouvrir le dossier "Menu dém commun normal" et copier le fichier Desktop.ini qui est dans le sous-dossier "Jeux" vers le dossier "Games" que vous trouverez en ouvrant le "Menu dém commun actuel".

Il est possible d'effectuer ce travail à l'aide d'un fichier batch. Ce fichier pourra contenir ces trois lignes :

attrib "C:\Windows\AllUsers\Start Menu\Programs\Games\Desktop.ini" -h -s
copy "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Games\Desktop.ini" "C:\Windows\AllUsers\Start Menu\Programs\Games\Desktop.ini"
attrib "C:\Windows\AllUsers\Start Menu\Programs\Games\Desktop.ini" +h +s

La première ligne risque de donner une erreur si le fichier Desktop.ini n'est pas présent. S'il est présent, cette ligne enlèvera les attributs cachés et système afin de permettre la copie.
La troisième ligne remet les attributs nécessaires.


Logiciels à problème

Microsoft Office 2007 et 2010 avec Windows 7

Description du problème

L'installation de Microsoft Office 2007 et 2010 sur Windows 7 donne une erreur d'accès au lecteur U:\

Explications

Le programme d'installation de Microsoft Office est gêné lorsque AppData, Favoris et Recent sont redirigés vers U:

Solution

1 - Installer ce programme en étant Administrateur local ou en ouvrant la session avec l'administrateur de modèles et en choisissant "Windows normal"

Le choix "Windows normal" peut se faire de deux façons, dans la fenêtre du client IACA qui apparaît lors de l'ouverture de session ou à l'aide de la petite icône IACA en choisissant "Futur modèle".

2 - Fermez la session et ouvrez la session en tant qu'administrateur de modèles en choisissant un modèle. Il est normal de ne pas voir Microsoft Office dans le menu démarrer.

3 - Afin d'ajouter l'entrée "Microsoft Office" dans le menu démarrer, allez dans le dossier

C:\ProgramData\Microsoft\Windows\Start Menu\Programs

Faites un "Copier" du dossier "Microsoft Office".

Ouvrez l'un des deux dossiers suivant que vous voulez utiliser le menu démarrer de l'utilisateur ou le menu démarrer commun.

C:\Windows\MenuProv\Programs

C:\Windows\AllUsers\Start Menu\Programs

Et faites "Coller". Vous devez voir l'entrée "Microsoft Office" dans "Démarrer > Tous les programmes". Vous pouvez éventuellement supprimer les raccourcis que vous n'utilisez pas, par exemple "Microsoft Office Outlook".

4 - Avec la petite icône IACA faites "Appliquer".

123 schéma

Logiciel qui permet de réaliser le schéma électrique d'un tableau d'abonné.

Description du problème

Si un utilisateur standard exécute le programme 123 Schéma, il obtient "Impossible d'ouvrir la bibliothèque de symboles !" puis "Erreur d'initialisation du moteur, erreur SQL : -82"

Explications

Le programme a besoin d'écrire dans une partie du dossier d'installation.

Solution

Je suppose que l'installation a été faite en conservant les choix par défaut. Le répertoire d'installation est donc C:\Hager

Allez dans le dossier C:\Hager\Taloha faites un clic droit sur le dossier Data et allez dans le volet "Sécurité" afin de modifier la sécurité.

Ajoutez au groupe "Utilisateurs" le droit "Modification".

Dans le dossier C:\Hager\Taloha faites un clic droit sur le fichier Taloha.html et faites de même (il est normal que la case devant "Écriture" se coche automatiquement)

Il reste encore un défaut. En effet le logiciel ne propose pas "Mes documents" (ou Documents) lorsque l'utilisateur enregistre son travail. L'enregistrement par défaut se fait dans C:\Hager\Taloha\Project

L'utilisateur ne retrouvera donc pas son travail s'il va sur un autre ordinateur. Vous pouvez interdire à l'utilisateur d'enregistrer dans le dossier Project, il sera alors amené à enregistrer dans son dossier personnel. Pour cela il suffit de changer la sécurité sur le dossier Project.

Faites un clic droit sur le dossier Project et allez dans le volet "Sécurité". Dans la sécurité avancée utilisez le bouton "Modifier" et décochez "Inclure les autorisations pouvant être héritées du parent". Répondez que vous souhaitez copier les sécurités. Supprimez ensuite les lignes pour ne laisser que celles-ci :

Administrateurs avec Contrôle total
SYSTEM  avec Contrôle total
Utilisateurs avec Lecture et exécution

Autres solutions

Il aurait été possible de donner le droit "Modification" au groupe "Utilisateurs" pour le dossier C:\Hager comme le conseille le programme d'installation. Ce n'est cependant pas la meilleure solution.

Il aurait également été possible d'utiliser Redirect mais là encore cela donne trop de droits inutilement.

Pour information le fichier à utiliser avec redirect pourrait ressembler à ceci :

<Redirect>
[123 schema]
Pgm=C:\Hager\Taloha\Apps\WinLauncher.exe
Params="LCTaloha.xml"
CD=C:\Hager\Taloha\Apps
Niv=2

Internet Explorer 9

Lorsque vous voulez effectuer un téléchargement, vous êtes invité à choisir le dossier de destination. Rien ne se passe lorsque le dossier de destination est un chemin réseau ou un lecteur réseau. Pas de message d'erreur et pas d'enregistrement du fichier.

Vous pouvez choisir une destination local puis, hors de Internet Explorer effectuer le déplacement du fichier par exemple vers U:\Downloads

Ce défaut n'existait pas dans la version 8.


Problème de profil

Vous n'utilisez pas de profil itinérant

Le profil de l'utilisateur n'existe pas encore

Lorsque l'utilisateur ouvre la session, son profil est créé en prenant comme modèle le profil par défaut. A partir de Vista, c'est le dossier C:\Users\Default qui correspondant au dossier du profil par défaut. Ce dossier a l'attribut caché.

Si le dossier du profil par défaut est absent ou défectueux alors tout utilisateur qui vient pour la première fois sur la station ne pourra pas obtenir un profil. Si vous avez par erreur supprimé ce dossier, il est en général possible de le récupérer à partir d'une autre station ayant une configuration semblable.

La création du profil est assez longue avec les versions récentes de Windows. Par exemple avec Windows 7 sans client IACA et peu de programmes installés, la création du profil prend une quarantaine de secondes.

Le profil de l'utilisateur existe déjà

Lorsque l'utilisateur ouvre la session, le profil présent est utilisé. L'ouverture de session est assez rapide.

Si le profil de l'utilisateur est défectueux alors Windows attribue un profil temporaire à l'utilisateur. Les modifications que l'utilisateur effectue seront perdues à la fermeture de session.

La suppression du profil de l'utilisateur règle en général ce problème. Ouvrez la session avec un compte ayant les droits d'administrateur sur la station et allez dans les "Propriétés système avancées". Dans la partie "Profil des utilisateurs" vous pouvez supprimer de l'utilisateur à problème.

Vous utilisez le profil iaca local

Le profil iaca local est peut-être défectueux. Voici comment le recréer :

Si Admin1 n'a pas de profil iaca local

Si Admin1 (ou le compte utilisé comme administrateur de modèles) est paramétré sans profil iaca local alors :

1) Ouvrez la session avec Admin1 et choisissez un modèle (de préférence le modèle le plus utilisé dans ce sous-parc)
2) Vérifiez que les programmes installés fonctionnent correctement
3) Faites "Appliquer" afin de copier le profil vers le serveur.

Pour information :
Sur la station sur laquelle vous venez de copier le profil, le dossier C:\Profils est tout de suite recréé avec le nouveau profil.
Sur chacune des autres stations du sous-parc, la mise à jour de ce dossier se fera au plus tard dans 5 minutes à condition qu'un utilisateur IACA ait une session ouverte sur la station. Si la mise à jour n'a pas été faite elle le sera juste après l'ouverture de session par un client IACA (lorsque la petite icône IACA est présente dans la barre des tâches).

Remarque : Il est donc possible que l'erreur de profil se produire encore une fois sur les autres stations du sous-parc.

Si admin1 est en profil iaca local

Si Admin1 (ou le compte utilisé comme administrateur de modèles) est paramétré avec un profil iaca local alors :

1) Ouvrez la session sur une station du sous-parc avec l'administrateur local
2) Supprimez le dossier C:\Profils

Le profil n'étant maintenant plus présent sur la station, suivez les instructions décrites au paragraphe précédent "Si Admin1 n'a pas de profil iaca local".

Attention : n'ouvrez pas la session avec un autre compte iaca après suppression du dossier C:\Profils car celui-ci serait recréé. Vous devez ouvrir la session avec le compte administrateur de modèles.


Problème avec les programmes signés numériquement

Les programmes IACA qui sont dans netlogon ne démarrent pas

Les programmes de IACA sont signés numériquement, cela permet d'être certain que ces programmes n'ont pas été modifiés à votre insu.

Cependant dans certains cas rares, il peut arriver que la signature empêche le lancement des programmes IACA qui sont dans netlogon lorsqu'on utilise un chemin UNC

Si vous constatez que les chemins suivants ne fonctionnent pas :
\\localhost\netlogon\modeles.exe
\\nom_serveur\netlogon\modeles.exe
\\nom_domaine\netlogon\modeles.exe

alors qu'en appelant le même programme par un chemin direct tel que
C:\Windows\SYSVOL\domain\scripts\Modeles.exe
le programme se lance normalement, votre serveur est dans ce cas.

Je n'ai pas trouvé la cause. Si vous êtes dans ce cas, vous pouvez installer la version non signée de IACA que vous trouverez à la rubrique "Téléchargement" sur le site iacasoft.fr