FaqClientXP/2000

De Mediase3
Aller à : Navigation, rechercher

Sommaire

Bloquer (cacher) les lecteurs

Créer la clé avec [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion?\Policies\Explorer] "NoDrives"=dword:0000000x en remplaçant x Si x=1 pas de A: Si x=2 pas de B: si x=4 pas de C: si x=8 pas de D: etc ... Et on cumule x=5 ni A: ni C: pour annuler x=0.

Faudrait préciser ce que signifie le 00000005 !, je pense que ça peut être utile, c'est le prof qui parle, on ne se refait pas :-) . Si ma mémoire est bonne: 5 correspond donc aux lecteurs a: et c: , c'est à dire 101 en binaire.

Donc si je veux cacher les lecteurs a:, b:, c:, g:, h:, il me faut remplacer la valeur 00000005 par 00000199 c'est à dire par 2exp0 + 2exp1 + 2exp2 + 2exp6 + 2exp7 = 1 + 2 + 4 + 64 + 128 = 199 . Si je me trompe faut pas hésiter à me corriger, et pour utiliser cette clef y a qu'a simplement l'importer via l'interface se3 dans un fichier texte .reg .

J'ai enfin réussi (pas tout seul) à cacher des lecteurs sous XP en fonction des profils et en passant pas l'interface SambaEdu3?.

Pour ceux que ça intéresse, voici la méthode :

- En mode "confirmé" - Client Windows\Gestion des clés\ cliquer sur "Ajouter une clé" - Catégorie : "lecteurs" par ex - Intitulé de la clé : "lecteurs visibles" par ex. - Valeur par défaut : 67106854 sans indiquer dword ou quoique ce soit et en Décimal. Ici, ça cache B, C, F, L jusqu'à Z (c'est ma cuisine avec mes répertoires partagés) - Antidote : la même chose 67106854 - Genre : REG_DWORD - OS concerné : Windows XP - Chemin : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion?\Policies\Exp lorer\NoDrives? - Type de Clé : clé de restriction.

Voilà c'est fini, ensuite il "suffit" d'attribuer cette clé à base puis à tous les autres profils qui hériterons d'une autres configuration, car... Dans Windows\Gestion des clés\ dans "modifier la valeur" de la clé correspondante, indiquer la nouvelle valeur en décimal et cocher les templates concernés. Valider en "Modifier la valeur"

Voilà, ça marche avec deux templates. Je vais essayer avec trois ou quatre (j'aime la cuisine).

Remarque sur la solution : Tu utilises la clé comme clé de configuration dans ce cas. Il est possible également ( mais bon c'est comme tu préfères), de définir cette clé comme clé de restriction ( donc antidote à zéro) et d'appliquer cette clé à base et de lever la restriction quand tu as besoin. L'avantage de ton choix est que tu peux choisir quels sont les lecteurs cachés templates par templates. Dans le cas d'une clé de restriction, tu pourras poser la restrction ou la lever simplement, ce qui est moins souple.


Problèmes d'intégration XP au domaine pour SE3 en version 1.18.6 (ou antérieure)

Il arrive que l'intégration de machines XP au domaine SambaEdu3? échoue et laisse la station connectée en adminse3 après un rebot au lieu de deux.

Voici quelques causes d'échec de l'intégtration de machines XP au domaine SambaEdu3?.

1) WINS non renseigné (le rejoin_se3_XP.vbs prévient que cela risque d'échouer)

2) Le mot de passe root pour Samba n'est pas correct. Plusieurs situations peuvent se présenter:

  • Vous avez plusieurs entrées pour uid=root dans votre annuaire LDAP.

Du coup, la définition d'un mot de passe root pour samba s'est mal passé (smbpasswd n'a pas su dans quel entrée uid=root il fallait mettre le mot de passe). Cela arrive avec des installations du LDAP sur le SLIS. Les versions de SE3 supérieures à 0.96-1 (ou DiglooSE3? >= 2.12) intègrent un correctif qui permet de régler le problème. Pour contrôler, logué en root sur le SE3:

ldapsearch -xLLL uid=root

Si tout est OK, vous devriez n'obtenir qu'une entrée cn=root,$BASE_DN Si vous obtenez deux entrées, c'est une de trop. Cela risque alors d'être uid=root,ou=People,$BASE_DN ou uid=root,ou=Trash,$BASE_DN (il peut être arrivé dans 'Trash' après un nettoyage des comptes orphelins) Dans ce cas supprimer l'entrée en trop à l'aide l'Explorateur LDAP (pour cela il faut passer la valeur de yala_bind à 1 dans 'Configuration générale/Paramètres LDAP'). Avant de supprimer l'entrée, faite par précaution un export LDIF en ne mettant rien dans le champ filtre, pour exporter tout l'annuaire (cela vous fait une sauvegarde).


  • Aucune raison identifiée, mais le test suivant est un échec:

Logué en root sur le serveur SE3 et en fournissant le mot de passe root pour samba que l'on trouve dans le fichier /var/se3/Progs/install/installdll/confse3.ini, on se voit répondre "NT_LOGON Failure" à la commande:

     smbclient -L 127.0.0.1 -U root

Dans ce cas, réinitialiser le mot de passe root avec la valeur indiquée dans le /var/se3/Progs/install/installdll/confse3.ini:

     smbpasswd -a root


  • Autre problème rencontré avec des machines qui avaient déjà intégré le domaine auparavant.

Les entrées pour uid=NOM_MACHINE$ comportent un attribut [ D] (D pour désactivé) pour AccountFlag? ou SambaAccountFlag?. Pour contrôler, en se loguant en root sur le SE3, taper:

ldapsearch -xLLL cn=nom_poste$

Rechercher les lignes AccountFlag? et/ou SambaAccountFlag?. Si la valeur de l'attribut comporte un 'D', la solution consiste à supprimer l'entrée NOM_MACHINE$ via l'Explorateur LDAP dans la branche ou=Computers (pour cela il faut passer la valeur de yala_bind à 1 dans 'Configuration générale/Paramètres LDAP'). L'entrée NOM_MACHINE$ est correctement recréée lors de l'intégration suivante. Avant de supprimer l'entrée, faite par précaution un export LDIF en ne mettant rien dans le champ filtre, pour exporter tout l'annuaire (cela vous fait une sauvegarde).

  • Une situation qui ne s'est produite que dans un établissement à ma connaissance (salut François;o).

Aucun des points précédents ne convenait. En tentant de créer le compte machine à la main sur le serveur, en lançant le script /usr/share/se3/sbin/machineAdd.pl, le collègue obtenait:

"stg_202_17 (10.127.89.82) closed connection to service Progs Erreur LDAP : Already exists. Erreur lors de l'ajoût de l'utilisateur. at /usr/share/se3/sbin/machineAdd.pl line 98."

De façon mystérieuse, le script /usr/share/se3/sbin/machineAdd.pl avait été dénaturé. La constatation a été faite en comparant le script avec celui d'un SE3 de test fraichement installé. Remettre le bon script a réglé le problème.

  • Après une première tentative

Je rencontre des problèmes d'intégration d'une machine xp pro ; je ne comprends pas vraiment où çà coince ! J'ai utilisé le script rejoins se3 xp.vbs ! J'ai un message d'erreur au redémarrage comme quoi il ne trouve pas le fichier rejoins_se3_xp.vbs à l'emplacement C:\netinst\logs Je vous joins le fichier de rapport de l'install !

Exact... J'ai eu ce message récemment... Après étude du script rejoin_se3_xp.vbs, j'en ai trouvé la cause. Il faut faire attention au point suivant:

Si tu as tenté une intégration (qui a échoué) tu restes dans le groupe de travail TEST: normalement, le script vbs doit intégrer la machine au domaine puis redémarrer et, au reboot, supprimer le script (devenu inutile) via une clé runonce de la base de registre...

Si tu tentes immédiatemment une nouvelle intégration après une autre qui a échoué, tu as effectivement le message cité ci-dessus: en effet, le script rejoin_se3_xp.vbs relancé force la machine à rebooter pour ensuite l'intégrer au domaine SE3. MAIS , au reboot, la clé runonce inscrite par la première tentative supprime le script qui est utile pour la deuxième tentative... Je ne sais pas si je suis clair.

MORALITE: faire au moins un redémarrage avant toute nouvelle tentative qui a échoué sinon c'est l'échec assuré!!!!


divers : un poste précédemment connecté sur un ancien se3 ne voit pas le nouveau dans les raccourcis réseau : - éteindre switch et hub dans la périphérie, les rallumer (ils gardent des trucs en mémoire. - sur un autre poste le problème venant du slis, un changement de la carte réseau a résolu l'affaire.

Raccourcis indésirables à la première connexion

J'ai des raccourcis indésirables qui apparaissent sur le bureau et le menus démarrer à la première connexion d'un utilisateur sous XP (lecteur windows multimédia Outlook et un desktop visible). De même, il y a des répertoires indésirables qui s'inscrustent dans K:\Docs (raccourcis vers échantillons d'images, etc...).

Sous Wxp, il faut exécuter dans une console 'cmd': Pour cacher OutlookExpre?$$:

"%SystemRoot?%\System32?\shmgrate.exe" OCInstallHideOE

Pour cacher InternetExploser?:

"%SystemRoot?%\System32?\shmgrate.exe" OCInstallHideIE

Pour Window$ Media Player, Johann Etienne a trouvé la solution suivante:

C:\WINDOWS\INF\unregmp2.exe /HideWMP? /SetShowState?

Changement du nom d'ordinateur après déploiement

En version SE3 1.50 (ou ultérieure) :

Si vous utilisez le DHCP du SE3, un renommage à distance est possible dans le menu DHCP, puis "réservations actives" : choisir l'action "renommer".


En version SE3 1.18.6 (ou antérieure) :

j'envisage de faire des déploiements à partir d'un master pour mes nouveaux XP, et de changer le nom des ordinateur pas la suite. Mais, j'ai remarqué que SambaEdu? ne veux pas changer le nom. J'ai tenté de relancer rejoins_samba, mais il ne me propose pas de changer le nom. J'ai réussi en changeant le nom en passant par le domaine Workgroup et en relançant rejoins_samba ensuite. L'application a un peu "ralé" (le msi, je crois), et le redémarrage n'a pas été automatique, mais c'est quand même passé.

Est-ce une bonne solution ? ça ne me parait pas très propre. Je suis preneur de quelque chose de plus "beau"


le script rejoin_se3_xp réponds effectivement à ta demande, il demande le nom de la machine , change ce nom et prend en charge la sortie et l'entrée du domaine proprement. Mais dans le cadre de déploiements massifs, la saisie du nom peut être un fardeau ( erreur de typo d'un poste à l'autre). Il existe une option de fonctionnement au script qui peut t'être utile, en effet si le client est déjà présent dans client.ini ( soit parce que rejoin_se3_xp y a déjà été passé soit parce que le fichier a été rempli à la main ) alors le nom choisi par défaut est le nom présent dans clients.ini , ce qui permet de préparer ton fichier tranquillement ( constitué de adresses mac et du nom) puis de passer rejoin_se3_XP, il ne te demandera que de comfirmer et indiquera automatiquement le nom que tu auras indiqué dans clients.ini

Tu n'auras donc plus a vérifier chaque nom au démarrage, la typo et la syntaxe seront celle déterminées dans ton fichier clients.ini . Seule contrainte, il faut connaitre les adresses mac de tes postes.

Il est inutile d'effacer le nom du master dans clients.ini puisque le test de lecture du nom dans clients.ini se fait sur l'adresse mac !!

Changer le mot de passe d'adminse3 automatiquement sur toutes les machines

Le seul impératif est de disposer d'un compte du groupe Administrateurs locaux présent sur toutes les machines avec le même mot de passe : le compte "Administrateur" est proposé par défaut...

Procédure pour changer le mot de passe adminse3 (se3 toutes versions)

Le contexte est le suivant : Il faut changer un mot de passe sur tout un réseau. Par exemple de adminse3

Prérequis : Les machines sont toutes intégrées au domaine Les machines sont allumées Les pare feu ne sont pas fermés

Il faut télécharger les pstools chez microsoft : http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Marche à suivre :

  1. On construit un fichier texte tout bête qui contient le nom de toutes

les machines, une par ligne.

  1. On se connecte comme administrateur du domaine "admin" sur un poste XP, on ouvre

une fenêtre de commande

  1. On execute la commande suivant : "psexec @liste.txt net user adminse3 JoliMotDePassNouveau"
  2. psexec va se connecter comme admin à toutes les machines les une après les autres et changer le mot de passe.


Après avoir imposé le "JoliMotDePassNouveau" sur chaque machine, vous devez effectuer des opérations sur le serveur :

  • Changer le mot de passe d'adminse3 via http://se3:909/setup (il s'appelle "xppass").
  • Changer le mot de passe d'adminse3 dans Y:\Progs\install\ocs-config.bat a la ligne 8:
Set PassAdminSE3=JoliMotDePassNouveau
  • Lancer ce dernier script: Y:\Progs\install\ocs-config.bat.
  • Lancer en root : /var/cache/se3_install/wpkg-install.sh (Patience: ça peut être long)
  • Changer le mot de passe d'adminse3 dans l'interface Annuaire, rechercher "adminse" ; puis "modifier le compte" ; compléter le prénom en "3local", changer le mot de passe en "nouveaumotdepasse" puis valider.
  • Après avoir changé le mot de passe de adminse3 sur le serveur, il faut recréer les différents fichiers *.job du répertoire "domscripts" en vue de l'intégration potentielle de nouvelles machines. Utiliser pour cela le script "update-domscripts.sh"

Ancienne procédure ne fonctionnant que sur un se3 1.18.6 (ou antérieur)

AVERTISSEMENT : tant qu'un utilisateur ne se sera pas identifié sur une machine, celle-ci ne se mettra plus à jour avec wpkg, ne pourra plus être éteinte à distance, etc...

Vérifier la présence de L:\install\chg_mdp_adminse3-config.bat. Si celui-ci est absent, il vous faudra télécharger les fichiers suivants :

  1. Placer dans L:\install\ le script [chg_mdp_adminse3-config.bat]
  2. Placer dans Y:\unattended\install\packages\chgmdpadminse3\ le script [chg_mdp_adminse3.bat]
  3. Placer dans Y:\unattended\install\scripts\registrese3\ (dossier à créer si absent) le script [msi-unattended.vbs]

Après avoir choisi un "nouveaumotdepasse", vous devez effectuer les opérations suivantes dans l'ordre :

  • Changer le mot de passe d'adminse3 via http://se3:909/setup
  • Dans L:\install\installdll\confse3.ini, remplacer le mot de passe a la ligne :
password_admin_local=nouveaumotdepasse
  • SI ET SEULEMENT SI le compte_ldap_domain est adminse3 dans L:\install\installdll\confse3.ini alors changer la ligne (Ceci sera le cas à partir des versions de se3 à venir...) :
password_ldap_domain=nouveaumotdepasse
  • Changer le mot de passe d'adminse3 dans ocs-config.bat a la ligne 8:
Set PassAdminSE3=nouveaumotdepasse
  • Lancer en root : /var/cache/se3_install/wpkg-install.sh (Patience: ça peut être long)
  • Changer le mot de passe d'adminse3 dans l'interface Annuaire, rechercher "adminse" ; puis "modifier le compte" ; compléter le prénom en "3local", changer le mot de passe en "nouveaumotdepasse" puis valider.
  • Lancer le script L:\install\chg_mdp_adminse3-config.bat et répondre aux questions.

Erreur 85 dans les scripts de connexion

j'ai des erreurs 85 dans le script de connections des profs. qui plus est, je n'ai pas de regroupement "matières" . les 2 sont ils liés? comment résoudre ces pbs: réimportation? un des fichiers gep est il corrompu?


Il y a un net use vers un partage qui a planté, parce que le lecteur est déjà pris ou que le nom est érroné.


L'erreur 85 est souvent présente parce que SaveConnections? est à Yes dans le ntuser.dat

Cela signifie que les connexions sont conservées lorsque l'utilisateur se déconnecte. Lorsque que quelqu'un passe ensuite pour se connecter, les lecteurs sont déjà pris. C'est ce que Micro$oft appelle une fonctionnalité.

Je te conseillerais de commencer par nettoyer les profiles concernés (quelques uns pour commencer (et tous plus tard si il n'y a pas de surprises)).

Logué en admin, vide le /home/toto/profile/ puis supprime les connexions: net use * /delete /yes

Arrête la station (W$ risque de râler parce qu'il ne peut pas rapatrier le profil, mais ce n'est pas dramatique (c'est ponctuel)). Redémarre la station et logue toi en toto. Si tu n'as pas de problème d'erreur 85, c'est probablement le SaveConnections?.

Il faudrait alors vider les /home/<user>/profile/ pour tous les utilisateurs et contrôler si le /home/netlogon/Default User/user.dat est correct. Logué en admin (ou peut-être en administrateur local), lancer regedit. Se placer dans HKU. Effectuer "Fichier/Charger la ruche" aller rechercher /home/netlogon/Default User/user.dat par exemple en AAA (c'est comme le nom d'un point de montage pour regarder dans le ntuser.dat d'un autre utilisateur) Et voir ce qu'il en est de:

[HKEY_USERS\AAA\Software\Microsoft\Windows
NT\CurrentVersion?\Network\Persistent Connections]
"SaveConnections?"="no"

Si c'est "no", c'est bon. Sinon, il faut passer à "no".

Pour tous les nouveaux profiles créés l'erreur 85 devrait disparaitre.

Pour nettoyer les profiles, voir les scripts sous SambaEdu dans la Documentation.


Connexions aléatoires

il y a déjà un problème récurrent sur les XP : tous les 10 ou 15 jours, certains XP (jamais les mêmes) refusent la connexion samba. Il faut alors manuellement se connecter en tant qu'administrateur de la machine et exécuter à nouveau le "rejoinssambaedu" pour récupérer la connexion... Remède ?


le remède dépend de la cause:) il faut donc chercher la cause. Cela doit apparaitre dans /var/log/samba/log.nomachine sinon, peut-etre y a t-il un doublon d'uidNumber entre la machine et un utilisateur; le refus de connexions peut etre lié a un pb sur le compte machine$. Pöur cela ldapsearch -xLLL uid=machine$ uidNumber puis ldapsearch -xLLL uidNumber=XXXXX dn cela doit retourner uniquement l'entrée de la machine en question. il est intéressant de faire ce test au moment du dysfonctionnement.


Seul admin peut se connecter sur le client

J'ai enfin trouvé quelque chose!! En fait tout fonctionne correctement.

Pour provoquer la panne voici la marche suivie:

   * Redemarrer la machine
   * se connecter en admin
   * se déconnecter
   * se connecter comme utilisateur


A chaque fois cela se plante. Pouvez-vous svp essayer pour voir si je suis le seul à avoir ce pb? Le remède c'est de ne pas se connecter en admin dès le démarrage semble-t-il.

Bingo, t'as trouvé, j'ai le même fonctionnement : si admin se connecte en premier, c'est foiré. Et forcément quaand on teste une machine, on se logue en admin la première fois... Je croise les doigts, mais il semble que cette fois la machine s'est vraiment intégré au domaine.

Autre explication possible :

Seul admin parvenait à se loguer sur un XP

Je me suis rappelé un fil de discussion récent et j'ai jeté un oeil au compte adminse3 (dans Clic-droit Poste de travail/Gérer). La case "L'utilisateur doit changer son mot de passe au prochain login était cochée". Je l'ai décochée et j'ai coché: "Le mot de passe n'expire jamais". Au reboot, j'ai récupéré l'accès pour d'autres utilisateurs qu'admin.

C'est un problème qui est réglé dans le nouvel "Intégrateur VBS", il me semble.


Changement du nom d'ordinateur après déploiement

j'envisage de faire des déploiements à partir d'un master pour mes nouveaux XP, et de changer le nom des ordinateur pas la suite. Mais, j'ai remarqué que SambaEdu? ne veux pas changer le nom. J'ai tenté de relancer rejoins_samba, mais il ne me propose pas de changer le nom. J'ai réussi en changeant le nom en passant par le domaine Workgroup et en relançant rejoins_samba ensuite. L'application a un peu "ralé" (le msi, je crois), et le redémarrage n'a pas été automatique, mais c'est quand même passé.

Est-ce une bonne solution ? ça ne me parait pas très propre. Je suis preneur de quelque chose de plus "beau"


le script rejoin_se3_xp réponds effectivement à ta demande, il demande le nom de la machine , change ce nom et prend en charge la sortie et l'entrée du domaine proprement. Mais dans le cadre de déploiements massifs, la saisie du nom peut être un fardeau ( erreur de typo d'un poste à l'autre). Il existe une option de fonctionnement au script qui peut t'être utile, en effet si le client est déjà présent dans client.ini ( soit parce que rejoin_se3_xp y a déjà été passé soit parce que le fichier a été rempli à la main ) alors le nom choisi par défaut est le nom présent dans clients.ini , ce qui permet de préparer ton fichier tranquillement ( constitué de adresses mac et du nom) puis de passer rejoin_se3_XP, il ne te demandera que de comfirmer et indiquera automatiquement le nom que tu auras indiqué dans clients.ini

Tu n'auras donc plus a vérifier chaque nom au démarrage, la typo et la syntaxe seront celle déterminées dans ton fichier clients.ini . Seule contrainte, il faut connaitre les adresses mac de tes postes.

Il est inutile d'effacer le nom du master dans clients.ini puisque le test de lecture du nom dans clients.ini se fait sur l'adresse mac !!


Ou trouver le mot de passe pour faire rejoindre une machine au domaine

Le nouveau mot de passe d'integration des postes, on le trouve ou, svp ? Car rejoint samba ne fonctionne plus depuis ce changement et manuellement le mot de passe root est refusé logique.

Voir dans le confse3.ini (qui se trouve dans le répertoire /var/se3/Progs/install/installdll). Ce mot de passe ne doit pas être changé au risque de devoir repasser sur toutes les machines. Donc une sauvegarde doit en être réalisé, surtout si vous deviez changer le serveur.

Si ça merdouille, vérifie le mot de passe comme suit: Tente un:

smbclient -L IP_DU_SE3 -U root

Et fournis en mot de passe celui trouvé dans confse3.ini Si tu obtiens une erreur, effectue:

smbpasswd -a root

Et réaffecte le mot de passe indiqué dans confse3.ini

Tu devrais ensuite pouvoir utiliser rejoinsambaedu3.vbs sans problème.

NOTE: Tu peux lancer le smbclient sur le SE3 lui-même.


A quoi sert Regénérer/Vérrouiller le profil windows disponible dans l'interface de Se3?

A quoi correspondent les choix: Regénérer/Verrouiller le profil windows? disponibles dans l'interface web SE3?

pour 2K/XP seulement :


Verrouiller : passage en profil obligatoire (ntuser.man) : la config de l'utilisateur est figée : aucune modif de la session ou des parametres n'est enregistrée à la fermeture de session. Bien commode quand tout est bien paramétré !

Regenerer : efface le répertoire profile, et force donc le rechargement du profil par défaut. Attention, à cause de la persistance des connexions, attendre deux-trois minutes avant de réouvrir la session.


Ouverture de fichiers

Pourquoi dans les documents sous un compte (élève ou profs ) apparaient tous les documents récemment ouverts ( même ceux de admin quand il s'est connecté sur la machine en question ) ??


s'il s'agit des documents qui apparaissent dans le menu demarrer pour les postes win98, voici la clé de base de registre qui te permettra de resoudre ton pb:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion?\Policies\Explorer] "NoRecentDocsHistory?"=dword:00000001


A la connexion certains élèves n'ont pas les répertoires Classe, Doc ... de montés

Les remarques suivantes sont obsolètes à partir de la version 1.50 de SE3 : en effet, dans cette version, le script de login est exécuté en arrière plan et ne peut être fermé par l'utilisateur.

Problème : sur certains postes avec certains identifiants, les partage classe, home, doc, ... ne sont pas montés à la connexion. Ceci est complètement aléatoire et aussi assez rare. Je n'ai jamais eu l'occasion de le constater par moi meme(ne travaillant pas dans l'établissement).

Si l'utilisateur ne laisse pas la fenêtre dos d'ouverture se dérouler jusqu'à la fin, lordinateur n'a pas le temps de crér tous les lecteurs réseaux (un seul a été créé au début : K à priori)

Autre possibilité la cause est le script login_user.sh qui demeure dans /tmp. Il suffit de l'effacer ( cd /tmp puis rm login_user.sh ) pour que le problème disparaisse.

elle ne veut pas utiliser le profil distant car celui ci n'est pas sécurisé

J'ai un problème avec une station XP pro

Lorsque l'on se connecte au réseau, elle identifie l'utilisateur (login+mot de passe) puis elle affiche un message disant qu'elle ne veut pas utiliser le profil distant car celui ci n'est pas sécurisé. Il devrait d'après le message appartenir à l'utilisateur et/ou au groupe administrateur.

Après vérification, le répertoire /home/<user-name>/profile/ appartient bien à l'utilisateur, qui a des droits rwx dessus (replacé les droits avec chmod et setfacl récursivement même pour voir...)

La station ne veut toutjours pas accepter le profil... Comment faire? Y a t'il une façon de désactiver cette vérifiaction du propriétaire? Pourquoi La vérification est elle erronée?


Vois avec ces valeurs là de BdR? des postes XP si ça règle ton souci (les 2 lignes ci-dessous peuvent être recopiées telles quelles pour former un ".reg" ; il restera à ajouter l'en-tête

"Windows Registry Editor Version 5.00") :
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"CompatibleRUPSecurity?"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion?\Winlogon]
"CompatibleRUPSecurity?"=dword:00000001

Les XP avec SP >=1 et Win2000Pro? avec SP4 testent la propriété "Propriétaire" du répertoire distant contenant le profil utilisateur. Pour que ce test ne soit pas effectué - comportement des versions antérieures - il faut ajouter les valeurs ci-dessous qui par défaut valent 0 et n'apparaissent pas dans la BdR?.



Problème avec rejoin_Se3_XP et restrictions (valable uniquement pour un SE3 en version 1.18.6 (ou antérieure)

by misterphi

Problème rencontré sur une soixantaine de PC dell

  • Symptômes
    1. rejoin_Se3_XP.vbs ne s'exécute pas.
    2. rejoinsambaedu.vbs fonctionne et l'intégration réussit en forçant le reboot
    3. Les restrictions ne s'appliquent pas.
    4. Le fichier C:\netinst\logs\logsregistrese3.txt ne contient que des lignes du genre :
      • VBS 23VBS 9 Cas XP 10: AdddllDLL 0:DLL Debut du passage dans la dllUtilisation interdite 1
    5. Sur le XP, les informations système ne s'affichent pas


  • Diagnostic :
    • Le logiciel Windows Management Instrumentation (WMI) est absent. Pour résumé, WMI est une interface qui permet aux scripts d'accéder aux ressources système


  • Remède
    1. Sur le Xp, dans une console DOS exécuter les trois commandes suivantes
      • cd /d %windir%\system32\wbem
      • for %i in (*.dll) do RegSvr32 -s %i
      • for %i in (*.exe) do %i /RegServer
    2. Fermer la fenêtre testeur qui peut apparaître
    3. Redémarrer le XP


  • Autre problème possible
    • lors de l'éxécution de la troisième commande, on obtient parfois le message :
Analyse du fichier MOF : C:\WINDOWS\system32\wbem\Cli.mof (Erreur de phase - 3)
Le compilateur a renvoyé l'erreur 0x80041002
  • Dans ce cas
    1. renommer ou supprimer le fichier C:\windows\system32\wbem\Repository.xxx
    2. Arrêter le service "Infrastructure de gestion" ( clic droit sur poste de travail, gérer, services et applications, services)
    3. Redémarrer le XP et relancer les 3 commandes indiquées au paragraphe Remède

Problèmes de connexion avec les postes Fujitsu sous XP avec carte graphique intégrée ATI

Symptômes :

En se connectant en tant qu'admin, la connexion finit par se faire malgré les messages d'erreurs de windows. Mais une connexion "prof" et "élèves" est impossible sans redémarrage de la station.

Origine du problème :

Le problème vient de la carte graphique intégrée (une Ati). Il ne faut pas utiliser ceux livrés avec les machines par fujitsu mais en télécharger des génériques sur le site d'Ati (ou ailleurs).

Solution :

Conserver la version xp livrée par fujitsu et installer d'autres drivers (Ati catalyst, je crois) récupérés sur le net.


Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Support
Téléchargements
Développement
Outils logiciels
Boîte à outils