Reprise du message précédent :

Bien sûr vous êtes blancs comme neige.  

Ca manque d'infos et de contexte pour savoir si quelqu'un fait mal son boulot ou est de mauvaise foi...

On est en train de migrer de Windows XP à Windows 7.  
L'immense majorité des salariés sont des non-informaticiens qui ne servent que de Office et d'un navigateur web.
 
La migration se contrefiche complétement des spécificités du travail des informaticiens qui ont besoin de pas mal de logiciels spécifiques. Dans mon cas, le principal logiciel dont je m'occupe est embarqué sur un serveur d'application bien connu, et on a des outils d'administration / paramétrages utilisant pas mal de scripts.  
 
Jusqu'ici, j'avais tout les logiciels bien proprement rangé dans ma partition E:\  . Maintenant sous Windows7 tout doit etre mis dans C:\My Program Fils sinon AppLocker bloque.  
Donc, je vais devoir changer tout une palanquée de chemins en dur dans des fichiers de config. et de .bat  .  Et niveau clarté du rangement, ca va être à chier.
 
Et toute mon équipe va devoir se taper les mêmes conneries. Et je sens venir d'ici toutes les appels à l'aide des membres de l'équipe qui ne connaissent pas par coeur les logiciels qu'on utilise  (c'est moi l'expert...)  et que je vais devoir dépanner.
 
Bref, je vais perdre un temps fou.

 
Oui?

Tu comptes vraiment éplucher tes collègues ?  

Les chemins en dur c'est le Mal
Y'a eu une discussion entre vous et "la migration" ?

 
+1 dans mes script je définis les variables de ce genre au début
Sinon si c'est que du fichier texte, avec un notepad++ tu dois pouvoir faire une recherche avec remplacement sur tout un dossier.

 
Oui mais j'ai pas le choix, c est comme ça dans le serveur d'application que j'utilise. Et ça serait encore plus lourd de tout réinstaller.
En dehors du serveur d'app en question, il y a une flopée de .bat ou de .config dans des petits outils développés à coté où les chemins sont pas forcément répétés à 10 endroit différents en dur, mais vas y pour trouver tous les fichiers en question    
 
Entre nous et les gens qui ont piloté la migration, euh, moi pas personellement, une autre grosse équipe de développeurs utilisant d'autres technos a servir de "cobayes", et en gros, on leur a dit : "discutez pas, on va pas s'embéter à gérer vos trucs".  
 
Dans la meme migration, je viens de perdre 3h à essayer de faire marcher chez un collègue un pilote ODBC Oracle et toujours pas réussi. La migration a laissé des infos dans le registre de partout, qui visiblement entrent en conflit avec la réinstallation du pilote sur le Windows 7  

 
Oui je sais ça... et coup de bol, notepad++ est autorisé au boulot    
Je pense que ça va finir effectivement comme ça : on copie tout l'ancien E: dans My Program Files ( y compris des trucs qui ont rien à voir ) et remplacer massif de E:\ par C:\My Program Files  .  

Bah voilà. Donc rien d'insurmontable. Après standardiser les dossier d'installation d'applis, pour l'administration c'est quand même bien pratique.
Par contre ça prend pas en compte les sous-dossier dans ton "My Program Files" ?

franchement les mecs de la migration sont autant fondés que toi à venir poster sur ce topic. "on essaie de migrer des gens qui ont codés des chemins en dur dans des centaines de scripts. Les variables ils connaissent pas."

 
Dans la centaine de scripts, la moitié sont livrés avec des logiciels que j'utilise....
C'est bête, hein?
 
 
Et les remarques que je fais, une autre équipe qui utilise absolument pas les mêmes logiciels de dév que moi les a faites avant, et qui a une réputation de travailler de manière hyper clean et structuré.
 
Pourquoi les admin ne peuvent pas prévoir de pouvoir autoriser certains utilisateurs privilégiés à faire comme bon leur semble? Ca fait 10 ans qu'on le fait et ca n'a jamais posé de problème à ma connaissance.

Le soft en sortie de la boite considère que tout doit être posé à la racine d'un disque e: et puis c'est tout ?

Ouais enfin gérer l'existant c'est un peu pour ça que tu fais un projet de migration, sinon t'appelles pas ça une migration

SUBST E: "C:\my program files"
 
 

 
Yep j y ai pensé aussi mais pas eu le temps de tester. Ca leurrait le AppLocker ?

jpense pas, ca serait trop beau
 
les softs cherchent "E:\toto.exe", applocker va pas s'amuser a traduire le chemin pour voir si c'est bon...

 
Non par défaut ils s'installent dans C:\ProgramFile mais comme je bosse avec 4 version différentes, et autant de version de JRE et JDK, c'est beaucoup plus efficace d’aller tout mettre dans des dossiers bien propres dans E: .

Un dev java! Sortez les fourches!!  
 
A+,

Et pourquoi pas sur des VM histoire d'avoir vraiment 4 versions différentes propres ?

Raté, le serveur d'application tourne en Java, mais la programmation du "code embarqué" ne l'est pas
(bon y a un peu de code en Java par moment mais c'est minoritaire)

 
Je les fiste avec des XServe maintenant.
En plus, ça fait plaisir à caudacien  

 
Qu'est ce qui te fait dire que c'est pas propre comme ça? Enfin j'ai jamais ressenti le besoin de faire autrement en tout cas.
 

Et bien, plutôt que d'avoir X installs sur une autre partition, tu auras une VM avec tout au bon endroit par version et en plus tu ne serais pas impacté par les migrations du SI

Surtout si les bords sont aiguisés ou rouillés

Perso je trouve que les admins ont bien fait le boulot, ils ont pas plié devant des devs.  

 
ou encore mieux, virtualisation d'applications avec tout le package applicatif.

 
Si c'est comme chez nous: un gus de la bureautique fait des planning de remplacement, puis envoie un presta qui vient pour la première fois dans la boitepour migrer les postes, alors qu'il n'y a presque que du spécifiques avec des trucs à la con ..
 
Forcément ça génère de l'incident et fait perdre du temps à tous le monde  
 
Dans ce cas là je dirais que s'il n'ont pas prévenu, c'est qu'ils ne savent pas comment s'installent tes outils; Et donc qu'il manque des procédures quelque part ?
 

Ca me parait la solution la plus réaliste à court terme en étant quand même efficace.
 
Après il est vrai que java suffit d'avoir un JRE dans un dossier et de lancer l'appli en la passant param

 
Dans ce genre de cas je me demande ce qui coute le plus à la boite.  
Coté équipe de migration, ca doit bien réduire le coup du "logiciel" de migration.
 
Par contre, le temps hallucinant que ca fait perdre au 5% d'informaticiens de la boite, plus le taux de plaintes à gerer que ca doit génerer, ca doit faire bezef.
 
 
Reste que là, j'avoue que je comprends vraiment pas le bien fondé de ce truc : quel avantage en terme d'admin/sécurité ca à ce que toutes les install soient dans un dossier MY Program Files plutot qu'ailleurs?  

 
Bah j ai survécu à 2 migrations déjà sans avoir de probleme... là c est juste le délire de forcer à tout mettre dans un dossier qui fait coincer le truc.

 
Dans de grands environnements, pouvoir gérer des applications dans un seul endroit, c'est juste du bon sens, pour aller vers de l'industrialisation par exemple.
Perdre un peu de temps pour tout mettre d'aplomb, et ensuite gagner vraiment du temps, tu te rends compte que tes 5% de mécontents, osef
 
En terme de sécurité ? Déjà program files n'a pas les mêmes droits NTFS que ton répertoire créé à la main on ne sait où.
Après il y a des solutions de sécurité qui vérifie le lancement d'executable sur les postes, selon un hash autorisé, et en vérifiant où l’exécutable accède... si l’exécutable n'est pas autorisé, mal installé, dans un endroits mal autorisé, ton appli ne fonctionne pas.
 
Quant aux nombreux développeurs qui te pondent des applications qui ne fonctionnent qu'en mettant des droits particuliers et obscurs de la machine parce qu'ils ne connaissent pas le minimum des concepts des droits des différents répertoires applicatifs d'un OS... On en a tous connu au moins un cas ici

J'aimerai comprendre pourquoi du jour au lendemain, ca devient indispensable et incontournable.

Je ne vois pas le temps que ca va me faire gagner une fois tout migré proprement?

J'ai bossé avec un paquet d'autres informaticiens depuis que je suis dans la boite, j'ai une très bonne mémoire, le seul qui a mis en vrac une machine, c est en donnant un coup de pied sur l'UC accidentellement.
Et pas connu de cas de virus ayant tout dézingué.

 
les admins profitent de la migration pour tout remettre à plat et industrialiser un peu les choses, c'est une très bonne chose qu'il le fasse.  
 
 
 

Je ne vois pas ce que ca industrialise, en fait, là?
Qu est ce qui m empeche de recréer une arborescence à l'identique de celle de mon ancien E:\  dans My Program Files ?
 
Si vous pouvez ( witjet , LaTeX ) donner un cas illustré de ce que vous entendez par là?  

 
Car avec uac cela oblige un peu un bestpractice.
 
Maintenant certains repertoire sont des sanctuaires, donc autant deplacé tous les prog interne dans un endroit controlé, qui ne touche pas au systeme, comme cela uac restera couché.
 

Moi j'ai pas compris.

Tu as un serveur d'application sur ton poste de travail et tu te plains que la migration le prend pas en compte c'est ça ?

Et il n'est venu a l'idée de personne qu'un serveur d'appli ça devait s'installer sur un server de développement ?

Mais bordel, pourquoi on met des serveurs si ce n'est pour s'affranchir des contraintes des postes de travail ?
C'est pas le boulot des équipes poste de travail de gérer ce genre de truc normalement    

Non mais les gars, on est vendredi hein
Soft avec plein de chemins en dur, visiblement à réecrire de partout, des scripts en .bat en pagaille. Manquerait plus qu'une gestion des versions du soft avec des .zip nommés 4.34_min_gégé_modif_variable_y.zip dans des dossiers partagés.
 
Et après c'est aux admins de se justifier d'avoir une politique de contrôle des postes utilisateurs

Bon, grosse coupure électrique ce matin et l'onduleur de la baie en a profité pour crever en même temps.
Pratique.
 
J'ai tout remonté, sauf le trunk entre nos 2 switchs (Catalyst 2950 - port G1/G2 et DLkink 12616T - ports Go 15/16).
La config est bien en place, mais quand je branche les câbles entre les ports (G1 -> 15 et G2 -> 16), les ports du cisco se mettent en erreur.
 
Je regarde en telnet, erreur mais pas moyen de savoir quelle erreur.
Quand au dlink (de merde je sais), aucun accès console, juste du web et ras.

 
Tu as vérifié s'ils étaient en autoneg   ?
(oui, bon, ça va, on est vendredi, j'ai le droit )

J'espère que le coup du dev au-dessus c'est vraiment un troll bien gros bien gras, mais je ne fais pas trop d'illusions  

Je dois exploiter une appli locale développées localement en java par des développeurs locaux.
On m’appelle parce que "ça marche pas". Je regarde la log: en 1h j'ai plus de 40 000 (quarante milles) JAVA NULL POINTER EXCEPTION.
J'envoie un extrait de la log au dev, il me répond "ce sont des erreurs normales, c'est autre chose qui pose pblm"