Reprise du message précédent :

 
Les best practices c'est de ne surtout pas bidouiller les clés de registre une par une pour obtenir un master    
C'est le meilleur moyen d'avoir un maximum d'emmerdes lors des migrations/mises à jour.
 
Quelques solutions :
- Centraliser au maximum la configuration via GPO/GPP pour faciliter la maintenance, le suivi des changements et l'audit.
A la rigueur passer par des GPO locales au niveau du master.
- utiliser des templates de sécurité
 
De même bricoler le registre pour avoir l'autocomplétion sur le cmd, ça me semble dangereux pour un intérêt dérisoire (à moins d'avoir des gens qui travaillent sous DOS toute la journée...)
 
Et le logiciel financier (donc très critique) bricolé car non supporté, c'est prendre de très gros risques (mais vous n'avez peut-être pas le choix...).
 
Je pense qu'il faudrait déjà vérifier la sécurité que vous pourriez mettre en place à un niveau global (par exemple personne n'a de droits administrateurs, stratégie de mot de passe pertinente, sécuriser les connexions NTLM...) avant de partir dans le détail.

Oui ça va aussi dans le sens que je pense, il y a eu trop d'ordinateurs qui ont disparu avant qu'on n'arrive, ce qui n'arrive plus depuis que je suis un inventaire mais les collaborateurs de cette société pensent que tout est freestyle ("vous pouvez m'installer ça, je m'en sers chez moi c'est pratique"...).
 

- Pour les GPO ça dépend, pour certains trucs je péfère m'en servir pour rattrapage de l'historiquen mais je préfère ne pas garder en trop d'anciennes pour savoir justement où j'en suis dans ce qui est pertinent ou pas à laisser. Remarque, c'est comme le fichier qu'on entretient sur les masters on pourrait faire la même liste pour les GPO.
 
- En quoi est-ce dangereux le truc de l'autocomplétion ? C'est juste un tip pratique.
 
- Pour le logiciel financier, effectivement, pas le choix (enfin pas le budget pour le moment pour passer à une version supportée...) et le risque est limité puisqu'on sait qu'elle valeur on met, où, comment c'est paramétré avant qu'on n'y touche etc... Enfin on a recetté un peu avant quand même.
 
- pour la politique de sécurité, on a déjà des fondamentaux pas trop pourris, on ne déclare personne en admin sauf les dev et les gars de l'infra/exploit, on a déjà une stratégie pour les mots de passe... Pour les connexions NTLM, jusqu'à quel point de détail tu pousses la sécurité ?

 
L'idée est de standardiser la sécurité, et pour cela il faut la centraliser, donc à mon sens utilisation de GPO/GPP pour la gestion de la configuration ordinateur et utilisateur au maximum.
 
Parsemer le master de clés de registre modifiées c'est bien trop difficile à gérer dans le temps.
 

 
L'idée derrière le thin master c'est d'avoir le minimum vital, pas plus. Donc chaque modification doit répondre à un vrai besoin, et la solution, si possible, doit passer par les outils adaptés de l'éditeur, sans bidouillage.
Donc quel est le besoin ici ? Travailler en ligne de commande ? Autant passer par du Powershell. Seulement auto-complétion ? Pareil Powershell le gère en natif. Du coup on s'orienterait ici vers l'utilisation d'un outil standardisé qui dispose en natif des fonctionnalités demandées, sans devoir bricolé un outil qui n'offre qu'une partie de ses fonctionnalités (par contre la je raisonne affranchi des contraintes).
 

Il faudra alors espérer que la recette n'ait rien oublié...et que la manipulation soit légale côté éditeur.
 
Pour NTLM : passer sur du NTLM v2 uniquement, et refuser le reste. Permet de renforcer sensiblement les mots de passe contre le crack, mais demande de vérifier la compatibilité des softs/OS.

Là on est au delà de la question du master, c'est le cadre de travail en général.
Si avant il n'y avait pas d'inventaire ce n'est pas de ta faute mais de ton/tes prédécesseur/s. Après quand il faut par contre passer derrière et rechercher où se trouve telle ou telle machine, j'ai connu aussi (et c'est très bouffeur de temps)
 
Idem pour le "tiens j'utilise ça c'est gratuit", le dernier gars qui m'a dit ça j'ai bien ri quand il m'a apporté ensuite sa machine perso car justement ce "très bon logiciel" lui avait perdu plusieurs semaines de travail (déjà machine perso pour du boulot faut le vouloir )
 
Bref, il faut s'en tenir à l'essentiel. Si c'est pour se la péter avec le master de 80Go compressé top moumoute avec 50.000 "améliorations" et 40 logiciels pour convenir à tout le monde, autant changer de métier.

Suivant le budget, il existe d'autres solutions qui se combinent ou remplacent MDT et co... J'en parle dans une présentation :
https://conf-ng.jres.org/2011/docum [...] l?download

Ta présentation résume plutôt bien les scénarios de déploiements actuel .
Le choix s'imposera en fonction des différentes contraintes , budget , matériel , infrastructure etc...
Pour l'instant nous nous sommes orientés sur du LTI/Virtualisation d'APP, entièrement automatiser, ça fonctionne très bien et le coût reste modéré dés lors que l'on possède une infra virtuel afin de baisser le coût des licences serveurs.
Sur ta présentation, il faut pas oublier que du MDT/LTI ou SCCM/ZTI permet de faciliter la migration de données via USMT, et l'air de rien c'est très pratique pour refresh un poste sans perdre certaines données de l'utilisateur.C'est aussi pour cette raison que la solution est plus flexible qu'un bête master.

Merci !
Concernant VDI, je pense que c'est inadapté dans 90% des cas... est qu'un solution autre et à la fois bien moins chère et plus efficace.
 
Pour LTI/APP-V/AD, c'est effectivement une solution particulièrement viable selon moi. Vous virtualisez quelles appli. ?
 
Pour Usmt, je n'ai pas trop explorer cette piste, car les data et préférences utilisateurs sont souvent redirigées vers un stockage centrale.

 
VDI , il faut y penser quand on part de ZÉRO . Dans le cas d'une infrastructure déjà en place , c'est très compliqué . Et ça coûte cher
Pour APP-V , Office 2010 PRO, Firefox , Adobe Reader, JRE , Appli Maison pour en citer quelques unes que nous avons séquencé.

Tu utilises quel procédé pour la diffusion ? Le streaming ? Tu as un bon retour d'app-v ?

Pour APPV , la diffusion est bien sur en streaming (RTSP) avec génération des block features lors du séquencement.
Pour les utilisateurs, le plus souvent ils ne s’aperçoivent même pas qu'office n'est pas installé sur le poste ^^. Pour de simples applications,ça reste très simple et rapide à diffuser. La mise à jour des applis est transparente pour tous les utilisateurs.  
Par contre question mise en place de bout en bout , c'est pas simple .  
*Bonne connaissance en SQLServer nécessaire pour la mise en place de la base de donnée déportée.
*Déploiement du client APPV , alors là c'est super amusant , j'ai du utilisé un bundle de 4-5 dépendances pour installer le package complet sous MDT , entre les Visual C++ redistribuables 2005 et 2008 , le Microsoft Reporting ,le kit de deploiement office et le Package APPV , c'est vraiment pas simple. Pour le reste c'est gérable en GPO , connexion au serveur de Streaming par exemple.
* Certains Séquencements sont assez lourd , ex office qui doit utiliser les proxys de composant fonctionnel pour permettre l'activation, la recherche dans les mails,l'indexation des fichiers etc..
* Avoir un bon serveur de Streaming , on fait pas tourner ça sur un P2 et sur un réseau 100Mb/s.
 
+Par contre , quel bonheur de ne plus avoir à installer certaines applis.
+Gain au niveau des temps de déploiement de postes, une installation office peut prendre 20-25minutes en installation réseau.
+Facilité d'update des applis sur tous les postes.