3 votes

profil nom d'utilisateur.domaine dans l'environnement AD

Environnement : un domaine AD (niveau W2K8) avec des postes de travail Vista et des serveurs W2K8 et un domaine AD (niveau W2K3) avec des postes de travail XP sur des serveurs W2K3.

De temps en temps, je remarque un utilisateur dont le profil local se trouve sous C:\Users\username.domain au lieu de C:\Users\username

Je sais que cela peut se produire lorsque les utilisateurs se connectent au domaine A à partir d'une station de travail située dans le domaine B, mais j'ai vu cela se produire un grand nombre de fois lorsque le domaine .est le même que le domaine de la station de travail.

Lorsque cela devient un problème, nous supprimons habituellement le profil local et demandons à l'utilisateur de se reconnecter, après quoi le profil est chargé correctement.

J'ai vérifié l'eventviewer plusieurs fois mais je n'ai trouvé aucune entrée relative à ce problème.

La question est la suivante : qu'est-ce qui provoque ce comportement ?

0 votes

En quoi cela pose-t-il un problème ? Si vous faites référence au chemin dans scripts, vous devriez faire référence à %userprofile% au lieu du chemin complet.

0 votes

Nous avons quelques applications qui ne sont pas compatibles avec ce système... Ce n'est pas toujours un problème, mais j'aimerais savoir ce qui en est la cause.

0 votes

Vous avez de bonnes informations de base, mais quelle est exactement votre question ?

1voto

mqatrombone Points 99

Si un profil d'utilisateur est créé à C:\Users\username.domain (o C:\users\username.domain001 ), c'est qu'il y avait déjà un dossier ou un profil à l'adresse C:\users\username (ou du moins Windows le pense).

1voto

EGHDK Points 189

La raison la plus courante dans mon environnement est que la connectivité réseau a été interrompue (dans la plupart des cas, l'utilisateur a mis le PC sous tension) pendant le chargement d'un profil d'itinérance, et que des fichiers critiques (notamment le registre) ont été corrompus, rendant le profil incapable de se charger lors des tentatives suivantes.

Une ACL le fera, si l'utilisateur ne peut pas charger le profil dans ce répertoire (accès refusé).

A mon avis, la corruption est le candidat le plus probable.

Dans tous les cas : cela ne devrait pas poser de problème. Si vous avez des scripts ou des applications qui dépendent du profil de l'utilisateur résidant à un emplacement spécifique, ils sont brisé et doivent être réparés. Je comprends la mise en place d'une solution de contournement, mais essayez quand même de résoudre le problème.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X