Mapper une partion d'un disque

xenapp
1

SLT,



ET BRAVO pour cette nouvelle mouture du site 5forum)



Bon apres ca voici ma question:



Est-il possible de mapper uniquement une partion d’un disque du client???



Merci pour vos repones

2

Merci :wink:

Bien sur si tu connais la lettre du lecteur.



dans ta conf tu demande la remonter des disque locaux mais pas leur connections. et avec le usrlogn2.cmd tu fais ton net use perso, genre: 

net use p: \clientc$






ps: Pense a t’inscrire :roll:
3

Bonjour,



J’étais deja inscrit mais pas logué.



Donc dans le cas de figure suivant:



1 DD avec 3 partition (C,D,E) coté client. je souhaite uniqument mapper pour le client sa partion E.



D’apres toi cela est possible??





Je n’ai pas compris le usrlogn2.cmd…



MErci pour les reponses

4

oui si tu es sur que tous tes client ont un disque E: Sinon bonjour les script avec des IFMEMBERS.

5

Dans ton system32 il y a un fichier: usrlogon.cmd Ce fichier (depuis nt4) charge quelque variable utilent au logon script puis si besoin monte le route drive. il peux (si les fichiers sont present) executer quelque commande avant et apres le rootdrive. pour ce faire il faut crer deux fichiers: usrlogn1.cmd et usrlogn2.cmd. dans le 1 tu places test script avant rootdrive et dans le 2 les script post rootdrive. les scripts finaux sont eux places dans "%systemroot%application compatibility scriptlogon"



ex:



%systemroot%system32usrlogn2.cmd



malone_script.cmd


%systemroot%application compatibility scriptlogonmalone_script.cmd


@echo off

net use /d e:

subst /d e:

net use e: \cliente$
6

MERCIIIIIIIIIIII



je test et si probleme je reviens vers toi



PS: EFFICACE CE FORUM

7

Techniquement, à quoi sert de définir un rootdrive ? Je sais que c’est nécessaire mais pourquoi ?

8

Deux cas:



Pour les users:

cela permet de libérer les lecteurs c:, d: … comme ca quand un utilisateur se connecte ses propre lecteur ne sont pas en c: -> v: d: -> u: … mais bien c: -> c: … c’est moins perturbant pour certain user :roll: et donc tu peux ne pas remonter les lecteurs client mais faire un rootdrive sur c:. donc le c: sera le homedrive de l’utilisateur.



Pour les applications:

Certaines (veille ?) applications sont hardcoded. cad par exemple qu’elles cherchent leur fichier de conf dans c:windowsapplidemerde.ini. Si ce fichier ini doit etre unique pour chaque user, tu remappes les lecteurs du serveur puis tu pose ton rootdrive sur c:, comme ca chaque session aura un c:windowsapplidemerde.ini perso et unique, qui sera physiquement dans le home du user.

9
"chavers" wrote:
Deux cas:
Pour les applications:
Certaines (veille ?) applications sont hardcoded. cad par exemple qu'elles cherchent leur fichier de conf dans c:windowsapplidemerde.ini. Si ce fichier ini doit etre unique pour chaque user, tu remappes les lecteurs du serveur puis tu pose ton rootdrive sur c:, comme ca chaque session aura un c:windowsapplidemerde.ini perso et unique, qui sera physiquement dans le home du user.

Ou alors tu utilises l'environnement d'isolation de CPS 4.0 :wink:
10

oui tu as raison (encore …)

11
"chavers" wrote:
comme ca chaque session aura un c:windowsapplidemerde.ini perso et unique

Je sens comme un brin d'énervement quand tu parles des vieilles applis qui passent sous Citrix hein ?

:lol:

Qu'est-ce que vous mettez dans votre fichier RootDrv2.Cmd ?

Set RootDrive=... ? Y-a t'il une raison particulière ?
12

pour un pb appli c:, pour office97 w: sinon rien :wink: