Bonjour à tous,
Cela maintenant quelques mois que je fais tourner un PDC samba avec profiles itinérants et j'utilise le module "recycled" de Samba qui permet de garder une trace des fichiers ou/et dossiers éliminés sur les clients. Cela fonctionne plutot bien mais cela grossit très vite c'est pourquoi il faut absolument que je trouve une solution qui me permette d'éliminer ces fichiers périodiquement.
J'ai d'abord pensé agir directement sur le server en utilisant cron et un petit script qui m'élimine régulièrement /%user/.deleted. Le problème est qu'en procédant ainsi ce dossier .deleted est automatiquement recréé à chaque fois que le user se déconnecte sur le client puisque les profiles sont itinérants et que les clients ont une trace en local du "home" de l'user (c:/documentandsetting/user/.deleted).
J'ai donc essayé de l'effacer directement à partir du client à travers un script DOS dans le fichier logon.bat (script executé à chaque connection du client)... et çà marche, mais quand vous allez lire ce script, vous allez comprendre que si le test tombe sur un dimanche ou un jour férié, çà ne marchera pas... :
SET JOUR=%DATE:~0,2%
IF %JOUR%==01 (RMDIR /S/Q "C:\Documents and Settings\%USERNAME%\.deleted\%USERNAME%")
Alors voilà... je ne sais plus comment procéder. Quelqu'un pourrait-il me donner un coup de main?
Merci d'avance...
# et alors ?
Posté par NeoX . Évalué à 1.
parce que tu as beaucoup d'utilisateurs qui se connectent les dimanches et jours feriés ?
je connais le chemin
==>[]
[^] # Re: et alors ?
Posté par Troudball . Évalué à 1.
[^] # Re: et alors ?
Posté par NeoX . Évalué à 1.
c'est bien ce que je dis
c'est pas grave, cela se mettra en marche le lundi ou le mardi
ensuite pourquoi ne pas faire plus "violent"
ne pas remonter ce qui se trouve sur le PC (en gros des profils bloqués)
1°) tu forces les utilisateurs à utiliser les lecteurs reseaux pour enregistrer leur document
2°) tes machines restent "propres" car ils ne peuvent rien stocker sur le poste (par contre c'est genant avec des portables)
3°) tu peux faire la purge depuis le serveur puisqu'il n'y a pas "resynchronisation" lors de la connexion
[^] # Re: et alors ?
Posté par Troudball . Évalué à 1.
c'est pas grave, cela se mettra en marche le lundi ou le mardi
---> Non puisque le test execute une commande pour un jour donné, si le dimanche est 01, le lundi sera 02! et la commande n'est executée
ensuite pourquoi ne pas faire plus "violent"
ne pas remonter ce qui se trouve sur le PC (en gros des profils bloqués)
---> qu'est-ce que tu entends par "des profils bloqués"?
1°) tu forces les utilisateurs à utiliser les lecteurs reseaux pour enregistrer leur document
---> Comment les forcer? s'ils veulent sauver sur leur Desktop, je ne peux pas faire grand chose...
2°) tes machines restent "propres" car ils ne peuvent rien stocker sur le poste (par contre c'est genant avec des portables)
---> et je perd l'avantage des profiles itinérants....
3°) tu peux faire la purge depuis le serveur puisqu'il n'y a pas "resynchronisation" lors de la connexion
---> Encore une fois, cette solution équivaut à laisser tomber les profiles itinérants... ce que je ne souhaite pas...
Il faut que je trouve une solution coté serveur qui agisse sur les machines clientes de manière périodique et qui sache que si le test n'est pas vérifié au jour J (pour non-connection du client), elle le fait dès que le client se connecte la fois d'après. Le concept est là... mais je ne sais pas comment faire :-P
[^] # Re: et alors ?
Posté par NeoX . Évalué à 1.
2°) 3°) ca sert à quoi pour toi un profil itinerant ?
pour moi le profil itinerant ca permet d'avoir des raccourcis vers des applis specifiques à chaque utilisateur. si lu'tilisateur se deplace, les raccourcis le suivent d'un poste à l'autre.
ensuite les données personnelles elles sont sur des lecteurs reseaux.
tu economises ainsi les transferts de profils trop volumineux.
pour finir, il te faut faire un script (dos ou wsh) qui se lancera à la connexion (logon.bat).
mais là du coup tu n'es pas sur le bon forum.
perso au boulot on a laissé tomber, c'etait trop "complexe" à gerer (meme en 100% windows)
[^] # Re: et alors ?
Posté par Troudball . Évalué à 1.
Mes profiles itinérants servent entre autre à sauvegarder les documents des utilisateurs présents sur leur "desktop et mes documents". Ils ont aussi à disposition des lecteurs réseaux, mais parlons clairement, c'est une utopie d'imaginer que les users vont travailler comme tu leur dis de travailler (Malheuresement pour nous les administrateurs), j'ai beau leur dire de travailler en sauvegardant à un endroit, ils continuerons à travailler sur un autre. Ils utilisent l'ordinateur comme on utilise un micro-onde, ils ont une façcon de faire qui a toujours marché et se trouvent trop destabilisés s'il doivent changer leur habitude. D'autre part, les profiles itinérants me permettent de sauvegarder des données d'application comme celles d'outlook et çà peut toujours servir...
Bref, en proposant profiles itinérants + module "delete de samba" + lecteurs réseaux, j'ai une sauvegarde de tout sur le serveur, j'anticipe les conneries des users et je me pars les fesses! Alors c'est vrai et je l'ai déjà vérifié qu'avec le temps la connection au server est de plus en plus longue, mais si les users sauvegardait là ou je leur dis (ce que je ne manque pas de leur faire remarquer) et si j'automatise l'élimination périodique de certaines directory en local, çà marche très bien...
[^] # Re: et alors ?
Posté par NeoX . Évalué à 1.
si les utilisateurs n'utilisent leur machine QUE de maniere connectée (pas de portable qu'ils utiliseraient chez eux)
alors tu peux peut-etre simplement faire pointer le "mes documents"
directement vers le lecteur reseau.
il ne resterait plus qu'a "synchroniser" le desktop (en ommetant "mes documents" car deja sur le reseau)
ne pas oublier qu'il y a plein d'outil pour gerer les politiques de securité et bloquer tout ou partie de la machine.
(figer le menu demarrer, le fond d'ecran, le bureau et plus si affinité)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.