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 ClientBavard si vous voulez rechercher un dysfonctionnement 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. Pour cela, ce programme teste les communications TCP 5010 ansi que UDP 5010 et 5011 entre la station et le service IACA du serveur.

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 22/03/2022 Version 2.01

Permet d'afficher quelques variables systèmes.


Station ou utilisateur non reconnu par le client IACA

Cache.ldap

Vérifiiez que dans Netlogon du serveur, le fichier Cache.ldap a une date de modification récente. Si ce n'est pas le cas, il est probable que l'antivirus soit le responsable. Paramétrez votre antivirus pour que sur le ou les serveurs, les fichiers suivants soient en zone de confiance :

C:\Windows\SysWOW64\CacheLdap.exe     (il s'agit d'un fichier caché)
C:\Windows\SysWOW64\Srviaca.exe      (il s'agit du service IACA)

Le fichier Cache.ldap est mis à jour automatiquement au maximum 5 minutes après un changement dans Active Directory. Cette mise à jour se fait par CacheLdap.exe qui est appelé par le service IACA toutes les 5 minutes.

Réplication

Si vous avez plusieurs contrôleurs (avec ou sans iaca) dans votre domaine, vérifiez que dans tous les Netlogon le fichier Cache.lap a la même date. Si ce n'est pas le cas, corrigez la réplication entre vos serveurs.

Sous-parc

Peut-être que la station n'est pas dans le sous-parc que vous pensez. Sur cette station, exécutez le programme Modeles.exe qui se trouve dans Netlogon et cliquez sur le bouton "Sélectionner le sous-parc de mon ordinateur". Si ce n'est pas le sous-parc attendu, vous pouvez renommer votre station ou modifier la définition du sous-parc avec IACA sur le serveur.

Modèle

Si le client afficher qu'aucun modèle ne peut vous êtes appliqué, vérifiez avec le programme Modèles les groupes et utilisateurs indiqués dans "Concernés".


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". 


Icônes du bureau qui se replacent à gauche

Problème :

Vous êtes administrateur de modèles et lorsque vous cliquez sur l'icône iaca, les icônes du bureau se replacent à gauche. Peut se produire à partir de Windows 7.

Explications :

La réorganisation se fait lorsque la place des icônes n'est pas encore mémorisée dans la base de registre ou que ce qui est mémorisé comporte des anomalies.

Solution 

Faites un clic droit sur l'icône IACA afin de replacer les icônes. Vérifiez avec F5 que les icônes restent en place. Si ce n'est pas le cas, faites à nouveau un clic droit sur l'icône IACA afin de replacer les icônes puis déplacez une icône. F5 ne devrait plus remettre les icônes à gauche. Vous pouvez remettre l'icône déplacée à sa place habituelle.

Changement de nom des groupes entre version 9 et 10

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.


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 dysfonctionnements.


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

Voir une méthode décrite ici :

https://docs.microsoft.com/fr-FR/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization

Une autre solution consiste à rétrograder puis à promouvoir le serveur en panne. 

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.

Avant de commencer

Repérez le serveur qui a le rôle PDC. Normalement si vous exécutez la commande 

netdom query pdc

sur tous les contrôleurs de domaine vous devriez avoir le même résultat. Si ce n'est pas le cas, reportez-vous au paragraphe précédent.

Vérifiez que le répertoire NETLOGON de votre PDC correspond à ce que vous voulez. Il est conseillé, avant de continuer de faire une copie de sauvegarde de ce répertoire.

Vérifiez que l'outils "Gestion du système de fichier distribué (DFS)" est installé sur chaque contrôleur de domaine. Si ce n'est pas le cas, vous pouvez ajouter le rôle "Réplication DFS" que vous trouverez dans"Service de fichier et de stockage > Service de fichiers et iSCSI"

Arrêter la réplication sur tous les contrôleurs de domaine

Sur tous les contrôleurs de domaine arrêtez le service DFSR. Pour cela dans une fenêtre DOS ou Powershell exécutez

NET STOP DFSR

Placez-vous sur le PDC

Sur le PDC désactivez la réplication. Pour cela exécutez ADSIEDIT.MSC afin d'obtenir "Modification ADSI". Si vous utilisez Adsiedit.msc pour le première fois connectez-vous au "Contexte d'attribution de noms par défaut".

Dans le "Contexte d'attribution de noms par défaut" recherchez "OU=Domain Controllers". Choisissez "CN=(le nom du PDC)" puis "CN=DFSR-LocalSettings" puis "CN=Domain System Volume". Allez dans les propriétés de "CN=SYSVOL Subscription"

Dans l'éditeur d'attributs mettez 

msDFSR-Enabled =FALSE

msDFSR-Options=1

Toujours sur le PDC avec ADSIEDIT.MSC reprenez le même chemin mais avec CN=(le nom de chaque autre contrôleur de domaine)

Dans l'éditeur d'attributs mettez 

msDFSR-Enabled =FALSE

La réplication est maintenant désactivée, il reste à effectuer une synchronisation d'active directory en tapant 

REPADMIN  /SYNCALL  (le nom du PDC)   /APed

Respectez majuscules et minusucles pour le paramètre /APed

Remarque : Comme la commande est exécutée sur le PDC, il n'est pas nécessaire d'indiquer le nom du PDC. La commande suivante serait suffisante :
Repadmin  /syncall  /APed

Dans les journaux des applications et service de l'observateur d'événements, vous devez obtenir l'information 4114. Attendez éventuellement quelques minutes.

Sur les autres contrôleurs de domaine

Videz les dossiers C:\Windows\SYSVOL\Domain\Policies et C:\Windows\SYSVOL\Domain\Scripts. Il peut être nécessaire au préalable de devenir le propriétaire de ces dossiers et de ce qu'ils contiennent.

Placez-vous à nouveau sur le PDC

Redémarrez DFSR sur le PDC

NET  START  DFSR

A l'aide de ADSIEDIT.MSC reprenez le chemin contenant "CN=(le nom du PDC)" et mettez 

msDFSR-Enabled =TRUE

Prendre en compte les changements :

DFSRDIAG  POLLAD

Propagez à l'aide de :

REPADMIN  /SYNCALL  (le nom du PDC)   /APED

A l'aide de ADSIEDIT.MSC reprenez les chemins avec "CN=(le nom de chaque autre contrôleur de domaine)" et mettez

msDFSR-Enabled =TRUE

Propagez à l'aide de :

REPADMIN  /SYNCALL  (le nom du PDC)   /APED

Sur les autres contrôleurs de domaine

Prendre en compte les changements :

DFSRDIAG  POLLAD

Résultat

La réplication doit à nouveau fonctionner et la valeur de msDFSR-Options pour le PDC doit automatiquement revenir à 0. En cas de dysfonctionnement, vous pouvez regarder l'observateur d'événements.

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.

Pour connaître les serveurs qui possèdent les rôles vous pouvez utiliser la commande :

netdom query fsmo

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
A partir de 2008 : 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

Il est possible que des programmes de IACA soient vus par votre antivirus comme un virus. Heureusement, les programmes antivirus permettent en général d'exclure certains fichiers ou dossiers lors de la recherche de virus.

Si un programme de IACA est détecté comme un virus, commencez par vérifier que ce programme n'a pas été modifié en vérifiant qu'il est signé numériquement : Clic droit sur le fichier, puis "Propriétés" et "Signatures numériques". Vous devez y voir mon nom.

Demandez ensuite à votre antivirus de ne pas vérifier sur les stations les programmes qui composent le client  IACA. Suivant les antivirus, ce sera "Ignorer ces fichiers lors du scan en temps réel" ou "Liste des programmes en zone de confiance"...

Voici les programmes qui composent le client IACA

Programmes utilisés sur les stations

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.

C:\Windows\TLots.exe Exécuté au démarrage du client IACA puis utilisé par GPO lors de la fermeture de session.
C:\Windows\Redirect.exe
C:\Windows\IACA\Appelindirect.exe
Appelindirect.exe n'est utilisé que si vous appelez Redirect.exe avec Niv=2.

Recherche panne ou dysfonctionnement 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".

Station ou utilisateur non trouvé dans Active Directory

Problèmes

Vous installez le client IACA sur une station et vous êtes informé que la station n'a pas été trouvée dans Active Directory alors qu'elle est présente.

Un nouvel utilisateur vient d'être créé dans IACA et lorsqu'il ouvre une session sur une station, le chemin LDAP de l'utilisateur n'est pas trouvé.

Cause

Certainement que le fichier Cache.ldap qui est dans Netlogon n'est pas à jour.

Solutions

Si vous avez plusieurs contrôleurs de domaine dans votre domaine, vérifiez que le fichier Cache.ldap est bien le même dans tous les Netlogon (même pour les serveurs qui n'utilisent pas IACA). S'il y a des différences, vous devez corriger votre problème de réplication.

Si le fichier Cache.ldap est ancien alors il est fort probable que sur votre serveur le programme C:\Windows\SysWOW64\CacheLdap.exe est bloqué par votre antivirus. CacheLdap.exe est un fichier caché.

Pour information : Le programme CacheLdap.exe est appelé toutes les 5 minutes par le service IACA et s'il y a eu des changements dans Active Directory, CacheLdap.exe met à jour Cache.ldap. Cette mise à jour ne se fait pas si l'antivirus empêche le service IACA d'appeler CacheLdap.exe.

Chemin des programmes :

C:\Windows\SysWOW64\Srviaca.exe

C:\Windows\SysWOW64\CacheLdap.exe


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

logiciel KACE de chez Quest

Description du problème

Le client IACA démarre deux fois

Explications

Ce programme modifie la clé Userinit et entre en conflit avec IACA.

Solution

La solution consiste à ajouter une valeur dans la base de registre des stations (minimum IACA 10.73)

Créez un fichier texte contenant :

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Sayer\IACA]

"AppelUserinit"="C:\\Windows\\system32\\KUsrInit.exe"

Et renommez-le en .REG

Utilisez ce fichier pour modifier la base de registre des stations.

L'équivalent peut être fait par GPO.

Si vous mettez cette valeur et que la station ne possède pas le programme KUsrInit.exe alors la valeur sera ignorée par le client IACA.

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"

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

Si Windows ne parvient pas à charger le profil de l'utilisateur alors on peut avoir essentiellement deux cas :

Il peut aussi être intéressant de savoir si le problème se pose sur une station ou sur l'ensemble des stations d'un sous-parc.

Est-ce que le problème se pose pour un utilisateur IACA sur plusieurs stations.

Recherche progressive

Nous allons faire simple et progressivement arriver à la configuration normale.

Sur le serveur avec IACA vérifiez pour un utilisateur à problème que le champ "Chemin du profil itinérant" est vide. Si ce n'est pas le cas choisissez "Sans profil itinérant"

Avec Modèles, vérifiez que le modèle qui s'applique à cet ordinateur et à cet utilisateur a dans "Système" "AppData normal" et "Local AppData normal". Si ce n'est pas le cas, corrigez.

Sur une station à problème, supprimer le profil de l'utilisateur à problème (En étant administrateur local et en passant par les "Propriétés système avancées", et "Profil des utilisateurs").

Ouvrez ensuite la session sur cette station avec l'utilisateur à problème.

Si l'erreur existe encore, cela peut venir du répertoire C:\Users\Default de la station.

Si l'erreur n'existe plus, et que vous utilisez les profils IACA locaux alors remettez sur le serveur avec IACA "Profil iaca local" pour cet utilisateur.

Ouvrez la session. Si le problème arrive, il faut certainement recréer le profil comme indiqué ci-après;

Si le problème n'existe plus et que vous utilisez avec Modèles "AppData du dossier personnel" ou "Synchronisez AppData avec celui du dossier personnel" alors remettez ce paramétrage et ouvrez à nouveau la session avec l'utilisateur à problème.

Si la session ne s'ouvre pas, il est possible que le répertoire de l'utilisateur sur le serveur contienne des défauts. Supprimez le répertoire AppDataV6 qui se trouve dans le dossier System de l'utilisateur. Le chemin pour accéder à ce dossier est de la forme D:\IACA\Perso\Le_Groupe\Le_Sous_Groupe_ou_la_classe\le_nom_de_login\System (ce répertoire est caché)

Recréer le profil si 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 le profil de l'utilisateur à problème.

Recréer le profil si 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


IACA fonctionne en lecture seule

Si vous démarrez le programme IACA sur un serveur RODC, il est normal que IACA fonctionne en lecture seule.

En 10.56 (et seulement cette version) de IACA, si vous démarrez votre serveur avec un compte du groupe administrateurs qui n'est pas le compte intégré Administrateur, vous devez exécuter IACA en tant qu'administrateur (clic droit et "Exécuter en tant qu'administrateur") afin d'avoir les mêmes droits que le compte Administrateur intégré.

Il est également possible dans le cas d'un domaine contenant plusieurs contrôleurs de domaine, que votre serveur soit passé en lecture seule (les autres serveurs du domaine n'ont plus confiance par exemple parce qu'ils n'ont pas vu votre serveur depuis trop longtemps). Vous pouvez exécuter InfoApi (qui se trouve à la rubrique "Dépannage") pour voir si votre serveur est "DC modifiable".