Ignorer HOMEDRIVE et HOMEPATH en tant qu'utilisateur Windows 7

50

Mon employeur a une stratégie de groupe Active Directory qui définit mon ordinateur portable Windows 7 HOMEDRIVE sur "M:" (un lecteur réseau mappé) et mon HOMEPATH sur "\". Étant donné que je dispose d'autorisations en lecture seule pour la racine de ce lecteur partagé, je ne peux pas créer de fichiers ni de répertoires dans mon répertoire personnel Windows. Mes tentatives de collaboration avec le service informatique ont été infructueuses.

Existe-t-il un moyen pour moi de changer globalement ces envars au démarrage ou au moment de la connexion? J'ai besoin que toutes les applications utilisent des valeurs alternatives (telles que "C:" et "\ Users \ myname"). Certains utilitaires installés (tels que gvim et autres) stockent les fichiers de préférences dans le répertoire personnel de l'utilisateur.

IMPORTANT : La modification de ces paramètres sous "Propriétés système> Variables d'environnement" ne fonctionne pas . J'ai essayé de les définir en tant que variables utilisateur et système (y compris un redémarrage). Taper SET HOMEdans une fenêtre DOS indique clairement que mes paramètres sont ignorés. En outre, l'utilisation de "Démarrer dans" dans un raccourci Windows ne résoudra pas ce problème, car j'ai besoin d'éléments tels que des éléments de menu contextuel de l'Explorateur (tels que "Éditer avec Vim") pour fonctionner correctement.

J'ai des droits d'administrateur sur l'ordinateur portable de cette société, mais je ne suis pas un gourou de Win7. De retour dans la journée, un script de démarrage aurait résolu ce problème en une minute. Est-ce même possible aujourd'hui? Merci.

MykennaC
la source
2
Votre service informatique a défini ces stratégies pour une raison. Si vous avez essayé de vous en sortir avec eux et qu'ils ont refusé de le changer, c'est probablement une bonne raison. Si vous continuez alors à ignorer leurs conseils et à aller à l'encontre de ce qu'ils ont demandé, préparez-vous à une action disciplinaire si vous êtes pris.
Joe Taylor
29
Après plus de 30 ans dans ce secteur, j'ai appris que la politique informatique pour l'utilisateur moyen est souvent inadéquate (voire obstructive) pour les développeurs et les utilisateurs expérimentés. Le service informatique a souvent dû prendre en compte les besoins des développeurs différemment, et s'il s'agit là d'une autre expérience d'apprentissage pour eux, je suis ravi de pouvoir vous aider. J'aimerais entendre une raison professionnelle valable pour rendre le répertoire de base d'un utilisateur inutilisable.
MykennaC
2
Pourquoi ne pas esquiver le problème, montrer qu'il est impraticable pour certains utilisateurs et proposer un objet de stratégie de groupe distinct pour ces utilisateurs. Déplacer de cette manière constructive est beaucoup plus susceptible de fonctionner que d'essayer de contourner les stratégies de domaine avec des hacks.
Joe Taylor
6
Il est enfin revenu vers moi. Ils ne vont rien changer. Oui, la politique officielle de la société est de fournir un répertoire de départ utilisateur où je ne suis pas autorisé à créer des fichiers. Les applications Windows qui tentent d'utiliser le répertoire de base de l'utilisateur par défaut pour des tâches telles que les fichiers de préférences échouent. N'y a-t-il aucun sorcier ici qui peut m'offrir une solution de contournement à cela?
MykennaC
3
oui @ D0rf, il devrait se retourner et le prendre. Si l'informatique rend votre travail impossible, vous devez vous battre et faire des bêtises jusqu'à ce qu'il soit changé. Si vous êtes un développeur passif, vous méritez votre vie dans une entreprise terrible qui ne vous donne pas les outils dont vous avez besoin pour votre travail.
Scott

Réponses:

39

Ci-dessous quelques astuces que j'ai développées. Ils ne sont pas élégants, mais peuvent être fonctionnels dans votre environnement d'entreprise.

HOMEDRIVE seulement

Il semble que de nombreuses applications utilisent uniquement HOMEDRIVE / HOMEPATH. Dans ce cas, vous pouvez créer un script de démarrage qui réaffecte la lettre du lecteur de base à votre chemin d'utilisateur local via le chemin d'administration du lecteur UNC:

set HOME
HOMEDRIVE=G:
HOMEPATH=\
HOMESHARE=\\Server\Users\username

net use g: /delete
net use g: \\localhost\C$\Users\username

HOMEDRIVE Local Default

Si vous n'avez pas du tout besoin d'accéder à «Serveur» par son nom, vous pouvez provoquer l'échec du paramètre de stratégie de groupe et son retour sur votre ordinateur local. Pour ce faire, le moyen le plus simple consiste à ajouter une entrée à C: \ Windows \ System32 \ drivers \ etc \ hosts comme:

127.0.0.1   Server

Après le redémarrage, vous devriez voir quelque chose comme:

set HOME
HOMEDRIVE=C:
HOMEPATH=\Users\username

HOMEDRIVE / SHARE avec chemins UNC hybrides locaux / distants

Si vous souhaitez accéder à "Serveur" par nom pour certains chemins UNC, mais en substituer d'autres aux chemins locaux, j'ai développé l'abomination suivante. Remarque: les connexions de serveur directes vers "Serveur" seront toujours résolues sur votre ordinateur local. Je recommande cette solution uniquement si "Serveur" est uniquement un serveur de fichiers:

  1. Modifiez C: \ Windows \ System32 \ drivers \ etc \ hosts pour rediriger "Serveur" vers votre ordinateur local:

    127.0.0.1   Server
    
  2. Ajoutez la valeur de Registre multi-chaînes suivante à HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ MSV1_0 pour autoriser la transmission des informations d'identification au chemin UNC local:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\
    BackConnectionHostNames = Server
    
  3. Créez un répertoire factice qui servira de racine du serveur:

    set DUMMY_LOC=C:\Server_Dummy
    
    mkdir %DUMMY_LOC%
    cd /D %DUMMY_LOC%
    
  4. Pour chaque chemin UNC que vous souhaitez diriger vers le vrai serveur:

    rem Alternatively you can use an IP below, but it is more likely to break if DNS changes
    set SERVER_FQDN=Server.network.blah.com
    
    rem Take a look at what's available...
    net view \\%SERVER_FQDN%\
    
    mklink /D Remote_Example \\%SERVER_FQDN%\Remote_Example
    net share Remote_Example=%DUMMY_LOC%\Remote_Example /grant:everyone,FULL
    
  5. Pour chaque partage UNC que vous souhaitez définir localement (par exemple, Utilisateurs):

    rem The link isn't really necessary for the share, I just find it easier to manage when all of these hacks are in the same directory
    
    mklink /D Users C:\Users
    net share Users=%DUMMY_LOC%\Users /grant:everyone,FULL
    
  6. Redémarrage

Pour l'exemple, cela permettrait de résoudre les chemins UNC suivants:

\\Server\Remote_Example => \\Server.network.blah.com\Remote_Example
\\Server\Users          => C:\Users

Cette résolution de chemin doit avoir lieu avant les mappages de lecteurs. Tant que les chemins UNC associés aux mappages sont valides (qu'ils soient locaux ou distants), les lettres de lecteur doivent se comporter comme prévu.

Par exemple, dans ma configuration, les variables suivantes sont forcées par le domaine:

set HOME
HOMEDRIVE=G:
HOMEPATH=\
HOMESHARE=\\Server\Users\username

Mais à cause de mes correspondances, le résultat est:

G: => \\Server\Users\username => C:\Users\username
Terrance
la source
Ces suggestions semblent pouvoir aider SI SI je travaillais en ligne de commande. Pour affecter une application (comme gvim), il me faudrait probablement créer un wrapper. Itérer sur toutes les applications concernées ressemble à beaucoup de travail, sans parler de la modification des associations de fichiers, etc. Remapper mon lecteur M: au démarrage est une suggestion judicieuse, mais comment le faire globalement au démarrage de Windows (afin de applications / coques)? J'espère que ces suggestions aideront les autres, mais je ne pense pas qu'elles résolvent mon OP
MykennaC.
3
Je n'avais pas eu besoin de ces méthodes depuis un moment, mais je me souviens de les avoir développées spécifiquement pour gvim, qui, je crois, utilisait HOMEDRIVE et HOMEPATH. Ces méthodes ne nécessitent pas que vous exécutiez à partir de la ligne de commande; toutes les applications utilisant les variables ou la lettre de lecteur seront toutes affectées. Les méthodes n ° 2 et n ° 3 sont "permanentes" et ne doivent être exécutées qu'une seule fois pour que les modifications soient conservées. La méthode n ° 1 peut être exécutée automatiquement au démarrage en plaçant un raccourci dans le menu C: \ Utilisateurs \ <Vous> \ AppData \ Roaming \ Microsoft \ Windows \ Démarrer \ Programmes \ Démarrage ou en configurant une tâche dans le Planificateur de tâches. J'espère que ça aide!
Terrance
@terrance Ahhh, la beauté des abominations bien conçues. LMAO. Merci pour l'info ici - et il y a des tonnes ici ...
David I. McIntosh
3

La meilleure solution que j'ai trouvée était de définir des variables lors de la connexion et avant userinit.exe.

C'est ce que j'ai fait. D'abord créé un fichier de commandes C:\Windows\System32\userinit.cmdcontenant

@ECHO OFF
SET HOMEDRIVE=C:
SET HOMEPATH=\Users\%USERNAME%
SET HOMESHARE=\\localhost\C$\Users\%USERNAME%
@START C:\Windows\system32\userinit.exe

puis changé de valeur de HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinità C:\Windows\System32\userinit.cmddans le Registre.

Plus d'informations sur: https://technet.microsoft.com/en-us/library/cc939862.aspx

Ali Malekpour
la source
Travaillé dans Win7, mais pas dans Win10.
Fourmis
1

Je l'ai utilisé SETXdans un script de démarrage et cela a fonctionné pour moi. Voir ma réponse .

Mark Mikofski
la source
0

Je pense que ces chemins sont automatiquement définis à l'endroit où se trouve votre profil d'utilisateur. Le lecteur d’accueil auquel vous faites référence est l’endroit où se trouvent votre ntuser.dat, vos données d’application et d’autres dossiers de profils d’utilisateur, correct? De retour avec NT3.x, le "profil utilisateur" était simplement votre ruche de registre d’utilisateurs avec des paramètres et vous pouviez définir un chemin de base distinct pour chaque utilisateur. Ceux-ci ont été unifiés dans NT4 en tant que profil utilisateur avec un bureau, mes documents, un menu Démarrer, etc.

Les emplacements de tous les profils sont stockés dans des clés de registre sous

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Vous trouverez des valeurs pour les profils spéciaux et des sous-clés: une pour chaque profil actif du système. Ils sont configurés par le SID du compte d'utilisateur auquel ils appartiennent. Le moyen le plus simple de trouver le vôtre serait de faire défiler chacun d'eux à la recherche du bon chemin (sous la ProfileImagePathvaleur). Vous devriez pouvoir changer cette valeur en choisissant le chemin que vous voulez; cela prendra effet la prochaine fois que vous vous connecterez. Veillez à copier d'abord vos fichiers dans le nouveau chemin.

Si vous devez déplacer le profil du compte sur lequel vous êtes connecté (c'est-à-dire connecté en tant que MikeC et que vous essayez de copier le profil pour MikeC), le fichier ntuser.dat (contenant la ruche de registre HKEY_CURRENT_USER) sera verrouillé par le noyau. Vous pouvez toujours copier la ruche: allez dans regedit, cliquez avec le bouton droit de la souris sur HKEY_CURRENT_USER, sélectionnez Exporter, modifiez le type en fichiers ruche du registre et enregistrez-le sous le nom ntuser.dat à votre nouvel emplacement.

D'après mon expérience, si winlogon rencontre un problème lors du chargement d'un profil en raison d'une configuration incorrecte, il crée une nouvelle copie à partir du profil par défaut ou vous en fournit une copie temporaire à utiliser pour cette session. Vous pourrez toujours vous connecter. Cependant, je vous recommanderais d’utiliser un autre identifiant d’administrateur à utiliser sur le système en cas de problème.

Chris Smith
la source
Eh bien, le seul élément de ma liste de profils qui semble pertinent est ProfileImagePath, qui indique C: \ Users \ mcepek. Cela correspond à ce que SET USERPROFILE me montre, mais ce n’est pas mon objectif ici. J'ai besoin d'affecter HOMEPATH et HOMEDRIVE. Juste pour le plaisir, j'ai cherché dans mon registre des éléments avec des valeurs ou des données définies sur "M:" (ne correspond qu'à la chaîne entière = cochée) et je n'ai obtenu que Computer / HKEY_USERS / xxxx / Volatile Environment / HOMEDRIVE. Le changer en C: ne semble pas avoir d’incidence sur ma session de connexion actuelle. Après un redémarrage, la valeur était revenue à M: (pas une surprise).
MykennaC
0

Je publie ceci au cas où quelqu'un d'autre viendrait à cette question via google. Au lieu de changer mon répertoire personnel et de mettre en colère mon équipe informatique, j'ai configuré et exécuté mon développement sur une machine virtuelle. Microsoft propose Widows XP en mode virtuel. http://www.microsoft.com/windows/virtual-pc/download.aspx

Christine Gregory Nicholls
la source
0

Une alternative un peu plus simple serait d'exécuter le script ci-dessous (env-reset.vbs) en tant que tâche planifiée à l'ouverture de session, le déverrouillage et peut-être toutes les quelques minutes également.

Set shell = WScript.CreateObject("WScript.Shell")  
Set venv = shell.Environment("Volatile")  

scriptingHost = LCase(Right(Wscript.FullName,Len("cscript.exe")))
interactive = Wscript.Interactive And (scriptingHost = "cscript.exe")

If interactive Then 
  Wscript.Echo "WSCRIPT"
  Wscript.Echo "  ScriptingHost = " & scriptingHost
  Wscript.Echo "  FullName = " & Wscript.FullName
  Wscript.Echo "  ScriptFullName = " & Wscript.ScriptFullName
End If  

If interactive Then Call showVolatile()

homedrive = Left(venv("USERPROFILE"),2)
homepath = Mid(venv("USERPROFILE"),3)
If interactive Then 
  Wscript.Echo "COMPUTED"
  Wscript.Echo "  homedrive = " & homedrive
  Wscript.Echo "  homepath = " & homepath
End If  
venv("HOMEDRIVE") = homedrive
venv("HOMEPATH")  = homepath

If interactive Then Call showVolatile()

Wscript.Quit(0)

Sub showVolatile()
  Wscript.Echo "VOLATILE"
  Wscript.Echo "  USERPROFILE = " & venv("USERPROFILE")  
  Wscript.Echo "  HOMEDRIVE = " & venv("HOMEDRIVE")  
  Wscript.Echo "  HOMEPATH = " & venv("HOMEPATH")  
  Wscript.Echo "  HOMESHARE = " & venv("HOMESHARE")  
End Sub
camilohe
la source