Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Grand fan de Windows To Go, je me suis lancé dans la préparation d'un disque externe avec Windows 10. Dans un élan de folie, j'ai voulu tenter l'opération à partir de mon Windows 8.1 Enterprise.

Bonne surprise, ça marche. Cela fait maintenant une semaine que j'utilise la Technical Preview Enterprise à partir d'un support Windows To Go.

Le déploiement a suivi les étapes classiques d'une installation Windows To Go à partir d'un PC Windows 8.1.

Il faut ouvrir son panneau de configuration. Utiliser le raccourci Windows To Go.

 

On sélectionne sa clé USB ou son disque externe.

 

On ajoute le chemin vers le disque (ici, j'ai monté l'iso sur F:\)

 

On fait suivant (hors mis si on veut tester BitLocker)

 

Et c'est parti

 

Ensuite il faut patienter

 

La dernière boite de dialogue propose de rebooter. On peut la fermer sans apporter de modification a sa machine et utiliser le disque.

 

Testé et approuvé ;)

Aujourd'hui, je vous propose un petit tour d'horizon des possibilités offertes par IIS et .net pour personnaliser ses pages d'erreurs.

Première chose à assimiler, il ne faut pas confondre les pages d'erreurs de nos applications .net et les pages d'erreur IIS :

  • La première catégorie sert principalement à afficher les erreurs internes à nos applications (exceptions diverses)
  • La seconde catégorie contient toutes les erreurs clients et applicatifs IIS qui peuvent être utilisée par des applications autres qu'ASP .net (erreurs 400-500 type : page introuvable, site indisponible, accès refusé …)

La première catégorie d'erreur se gère assez facilement via la section customErros du fichier web.config. Il n'y a pas grand-chose à dire. Vous pouvez gérer les erreurs dans vos applications web, et choisir sur quel client on veut ou non afficher les erreurs en détail. Dans certains cas, vous risquez d'être en grosse galère, car les pages d'erreur IIS peuvent prendre le dessus sur vos pages d'erreurs ASP.net. Un développeur .net doit donc avoir connaissance des possibilités offertes par la personnalisation des pages d'erreur IIS.

La seconde est bien plus intéressante car elle offre des possibilités de personnalisations aux hébergeurs et administrateurs système. Ceci de manière uniforme quelle que soit la technologie utilisée. Certes les pages ainsi personnalisées sont en général statiques (pour éviter de donner trop d'informations aux utilisateurs finaux), mais au moins elles sont chartes aux couleurs de la société.

Pour ceux qui n'auraient jamais fait attention, voici une capture du panneau IIS qui met en avant les deux zones de configurations :

 

Pour présenter correctement la chose, j'ai choisi d'utiliser le plan suivant :

  1. Activité les erreurs personnalisées IIS
  2. Scope de la configuration des pages d'erreurs
  3. Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs
  4. Possibilité 2 : Embarquer les pages dans son site
  5. Possibilité 3 : Hébergement sur un serveur dédié

Ma volonté étant de vulgariser les pages d'erreurs IIS pour les développeurs .net, j'omettrai volontairement un certain nombre de détails. Je n'aborderai donc pas des notions comme :

  • Les pages détaillées
  • Les redirections/réécritures de pages
  • La possibilité absolument diabolique d'empêcher les développeurs de personnaliser les pages d'erreurs (c'est méchant ça !)

Attaquons donc dans le vif !

 

1. Activité les erreurs personnalisées IIS

En soit, l'activation des pages personnalisées n'a rien de bien compliquer. Sur un poste client, il suffit d'aller dans le panneau de configuration t d'ajouter une fonctionnalité Windows.

Ici sur un Windows 8.1 en français : « Erreurs http » 

 

Sur un serveur, il faut ajouter une fonctionnalité au rôle IIS. Ici sur un Windows 2012 R2 qui a déjà cette fonctionnalité activé : « Erreurs HTTP (Installé) » 

Aucun reboot n'est utile.

 

2. Scope de la configuration des pages d'erreurs

La configuration des pages d'erreurs étant enregistrée dans un fichier *.config section system.webServer (nœud httpErrors). Voici ce à quoi ressemble la configuration par défaut :

Il est possible de la modifier à différents endroits :

  • applicationHost.config
  • web.config

Bien entendu, machine.config ne fait pas parti des possibilités envisageables. Imaginez une page d'erreur qui change en fonction de la CLR ou de la plateforme ciblée (32 ou 64bits). Ce serait un cauchemar !

 

En fonction de l'endroit où l'on configure la section system.webServer, il est donc possible de personnaliser les erreurs pour :

  • Tous les sites d'un même serveur (applicationHost.config)
  • Un site (web.config)
  • Une application (web.config)
  • Un répertoire virtuel ou non (web.config)

La configuration peut donc être très souple. Via la console IIS, on dispose même d'une interface très pratique. Celle-ci permet de changer une page d'erreur existante et d'ajouter/supprimer des erreurs.

 

Le formulaire de configuration d'une erreur reste simple, à condition de comprendre les trois possibilités de personnalisation offertes par IIS.

 

3. Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs

La première possibilité offerte consiste dans l'usage de pages statiques stockées sur le serveur. Il s'agit de la configuration par défaut de IIS. Les fichiers sont stockés dans le répertoire « %SystemDrive%\inetpub\custerr\ » (donc bien souvent dans C:\ inetpub\custerr\).

Si vous le souhaitez, vous pouvez choisir d'utiliser des pages qui diffèrent en fonction de la langue de l'utilisateur (pages localisées). Pour cela, il suffit de créer un répertoire par langue. Exemple : ici le français (fr-FR)

 

Lors de la saisie, si la case «Essayer de retourner le fichier d'erreur dans le langage client » est cochée, le bouton définir est disponible. Il permet d'accéder au formulaire suivant :

Dans le cas où cette case n'est pas cochée, vous ne pourrez pas avoir de pages d'erreurs localisées. Il faudra donc donner le lien complet vers la page d'erreur.

Voici par exemple, la configuration obtenue en personnalisant uniquement deux pages (401 localisée et 403 non localisée)

Notes :

  • errorMode doit être défini sur Custom pour que votre configuration soit prise en compte
  • On peut utiliser un noeaud <clear/> si on veut supprimer les autres pages.

 

4. Possibilité 2 : Embarquer les pages dans son site

Il s'agit là de l'approche préférée des développeurs. Les pages font partie du site. On peut en profiter pour avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).

 

5. Possibilité 3 : Hébergement sur un serveur dédié

Cette approche est très pratique dans le cas d'une ferme IIS. Les fichiers n'ont pas besoin d'être répliqués sur l'ensemble des serveurs de la ferme. Cette approche comme la précédente permet d'avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).

 

Voilà, j'espère que cet article vous donnera envie de considérer cette possibilité de personnalisation de IIS.

Aujourd'hui je suis toujours surpris pas la complexité mise en place pour sécurisées des informations (bases de données, partages de fichiers, FTP…). Pour une même application, il y a les développeurs qui vont stocker 50 comptes qui ne sont utilisés que par l'application (ou le groupe d'applications qu'ils gèrent). Pour ne pas distribuer les mots de passe sur les serveurs, ou les pc clients, on se retrouve souvent avec trois solutions qui parfois se complètent:

  • Le stockage de logins, mots de passe cryptés (dans l'application ou le fichier de configuration).
  • L'utilisation d'un API tiers de sécurité pour stocker logins et mots de passe (parfois avec un mot de passe ou token d'accès qui lui n'est pas sécurisé)
  • L'impersonation pour que le processus s'exécute avec des droits d'un autre utilisateur.

Il y a peut-être d'autres solutions que je n'ai pas croisées.

Dans tous les cas, on finira systématiquement avec un problème : « il y aura toujours un mot de passe qu'une personne devra conserver », ou « une personne qui aura accès à l'information sans restriction ».

Exemples absurdes, car l'utilisateur aura accès quoi qu'il soit décidé :

  • Ne pas vouloir donner accès à un site SharePoint alors que l'utilisateur est administrateur de la collection contenant le site.
  • Ne pas vouloir donner accès à un partage alors que l'utilisateur gère aussi le compte qui sert au backup de ce dossier (donc un compte qui lui aura accès quoi qu'il arrive)
  • … etc ….

Chacun a connu dans sa carrière l'une de ses situations absurdes. Je sais d'expérience qu'il y a des personnes qui préfèrent ne pas expliquer la situation : « c'est sécure ! ». Personnellement, j'ai toujours bataillé pour que la situation soit claire. Il n'y a pas de sécurité dans l'opacité.

La solution simple :

1. L'humain :

Ne pas prendre un responsable de votre société, car dans la plupart des cas, ils ne sont pas formés à la sécurité et risquent de compromettre l'information.

Exemple typique de ce type d'utilisateur :

  • Téléphone sans verrouillage d'accès posé sur une table.
  • PC laissé session ouverte lors de la pause pipi.
  • Lien vers les mots de passe sur le bureau Windows.
  • … etc…

Mettre en avant une personne « administrateur système » ou un « administrateur applicatif ». Cette personne a l'accès complet à l'outil et la sécurité fait partie de son métier. S'il faut conserver un mot de passe, c'est lui qui doit le faire.

 

2.  Le technique simple

La quasi-totalité des applicatifs peut utiliser une authentification Windows (aussi appelée authentification intégrée sur certaines applications comme SQL Server). Ce qui permet aussi la centraliser la gestion des comptes dans l'Active Directory. Notre administrateur aillant accès à l'AD, il pourra immédiatement couper un compte si besoin. Ceci est très pratique dans le cas d'applications compromises, ou changer le mot de passe rapidement.

A partir du moment où l'on utilise ce mode d'authentification, il n'est plus utile de stocker des chaines de connexion avec mot de passe dans l'applicatif ou le fichier de configuration. Ni même de stocker un mot de passe. Le ou les processus lancés se feront avec les droits de l'utilisateur qui a lancé le processus.

Pour chaque type d'application, il y a une solution simple qui s'appuie sur un compte Windows:

  • Application Windows classique : Le compte d'ouverture de session est utilisé
  • Site Web : Le compte du pool IIS est utilisé.
  • Planificateur de tâche : On peut déterminer un compte lors de la mise en place
  • Service Windows : On peut déterminer un compte lors de la mise en place
  • SharePoint : On a une liste de compte géré.

Note : On peut faire encore plus simple si l'on n'a pas besoin d'accéder aux ressources d'autres machines. On peut utiliser un compte système (ou un compte intégré à IIS par exemple)

 

3. Le technique un peu plus évolué

Si l'authentification Windows n'est pas disponible et qu'il faut sécuriser des données, on stocke les données cryptées dans un fichier de configuration. Mais avant de crypter les données, il faut commencer par extraire les clés machines qui serviront au cryptage.

Sans ces clés, votre fichier ne pourra pas être déployé hors de la machine qui a servi au cryptage. Ceci est très important pour une ferme IIS, ou pour un plan de reprise d'activité (PRA). Il s'agit là d'une erreur qui est malheureusement trop courante.

Il y a une documentation très claire que l'on peut trouver ici : http://msdn.microsoft.com/en-us/library/ff650304.aspx

Cette page date un peu, mais son contenu reste valable. Vous y trouverez le nécessaire pour sécuriser vos fichiers de configuration de manière fiable et portable.

 

Voilà. Vu que sécurité rime avec simplicité, j'espère que ces petites vous seront utiles et vous faciliterons la tâche.

Après avoir lu avec beaucoup d'attention l'annonce de S. Somasegar, j'ai été surpris de ne pas trouver de lien direct vers l'ISO de Visual Studio 2015.

Ce matin, une recherche sur Bing ou Google ne donnait pas grand-chose. Ce soir la donne a un peu changé et on peut enfin trouver facilement le lien vers la preview ici :

http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs

Petit avertissement pour les plus distraits : c'est le second lien qu'il faut utiliser pour obtenir l'ISO complète. Le premier pointe vers l'installer web.

Bons tests ;)

Un petit bug existe sur le package Oracle Database Client (12.1.0.2.0) for Microsoft Windows (32-bit) qui se trouve sur la page de téléchargement suivante : http://www.oracle.com/technetwork/database/enterprise-edition/downloads/database12c-win64-download-2297732.html

Le fichier oranfsodm12.dll est manquant, ce qui empêche l'utilisation de SQL*Loader.

En recherchant dans la documentation, on découvre qu'il s'agit d'une version modifiée de la librairie oraodm.

https://docs.oracle.com/database/121/NTDBI/postcfg.htm

 

En copiant oraodm12.dll et en la renommant oranfsodm12.dll on obtient une dll de remplacement utilisable sans NFS. On peut donc l'utiliser sur un poste client, mais on ne profitera pas de fonctionnalités du client direct NFS documenté ici (en version 11) :

http://www.oracle.com/technetwork/articles/directnfsclient-11gr1-twp-129785.pdf

 

Si la solution est acceptable dans un environnement, de développement, sur un environnement de production, il sera préférable de se procurer la DLL présente dans le package DataBase. Seul hic, ce package n'existe pas en 32 bits L

 

Derrière ce titre étrange se cachent quelques conseils sur l'utilisation de dépendance externes à vos projets. Que ce soit dans le cadre d'une maintenance, de la migration d'une application ou tout simplement dans l'évolution d'une application, des dépendances mal gérées peuvent faire capoter votre projet.

1. Lister ses dépendances

Il n'y a rien de pire qu'un projet dont on ne connait pas les dépendances. Savoir quelles dépendances on a, s'est déjà connaitre une partie de ce que l'on a besoin pour faire fonctionner son application. Dans certains cas, si vous connaissez les dépendances, vous pouvez même anticiper certains problèmes.

Si l'on ne connait pas ses dépendances, il est possible que l'on ne puisse pas déployer l'application.

Dans le cadre d'une migration, c'est une étape primordiale. Cette liste vous permettra de savoir quelles dépendances pourront être conservées, mises à jour, ou devront être supprimés. Si trop de dépendances n'existent pas sur la plateforme cible, il est possible que cela change complètement la philosophie de votre projet de migration en le transformant en projet de réécriture complète (pas de chance).

2. Ne garder que des dépendances utiles

Cette remarque vous fait sourire ? Si oui, avez-vous déjà listé les dépendances utilisées par le Template d'application web de Visual Studio ? Êtes-vous certain d'avoir besoin de toutes celles-ci pour votre projet ?

Il y a trop de projets qui incluent des dépendances pour effectuer des opérations déjà possibles avec les Frameworks. Exemple : sur un projet .net on peut déjà faire de la compression ou du cryptage sans utiliser de dépendances supplémentaires (et ça n'est pas très compliqué).

Parfois, il y a de dépendances que l'on garde par habitue. Il faut être vigilant avec celles-ci et régulièrement se tenir informé sur les évolutions de son Framework pour vérifier que celles-ci ne sont pas devenues inutiles. Exemple : avec le passage de Windows 8.0 à 8.1, j'ai supprimé plus de la moitié de mes dépendances, car j'ai presque trouvé tout ce dont j'avais besoin dans WinRT et les évolutions de Xaml.

3. Bien choisir ses dépendances

On a vite fait de lancer une recherche sur CodePlex, Nuget…etc… pour aller chercher des dépendances censées nous simplifier la vie. Certain préfèrerons acheter des composants aux près de fournisseurs bien connus comme DevExpress, Telerik… etc…

Quelle que soit la source des dépendances, il faut s'assurer de :

  • La viabilité de la source : un projet maintenu par un seul développeur très actif peut être parfaitement viable. Mais qu'en est-il d'un projet dont il n'y a toujours eu qu'une version ?
  • La fraicheur de la dépendance : un produit qui n'a pas été mis à jour depuis longtemps est un produit qui est peut-être mort. Il n'a donc pas d'avenir. Un bon indicateur pour identifier un projet mort, c'est de vérifier qu'il utilise un Framework récent. Exemple : une dépendance qui cible .net 2 en 2014… c'est risqué.
  • La maintenance corrective et évolutive : Un produit acheté doit toujours l'être avec ses mises à jour. Cela vous permettra de profiter des correctifs de celui-ci. Ce surcout doit être considéré avant tout achat pour éviter des débordements sur votre budget. J'ai déjà vu des projets en galère, car les bugs induits par les dépendances ne peuvent être résolus.
  • Regarder les breacking change : toujours vérifier si une dépendance est habituée à induire des breackin change suite à ses mises à jour. S'il y en a beaucoup, vous aurez beaucoup de travail à fournir lors des mises à jour.

4. Les dépendances ont des dépendances

On l'oublie souvent, mais une dépendance peut induire l'utilisation d'autres dépendances. Rien de pire que le message disant : «  la dépendance X où l'une de ses dépendances ne peut être résolue…. ».

À ce titre, vous devez appliquer les mêmes précautions sur celles-ci que sur vos dépendances directes. Il faut aussi être très prudent sur le fait qu'une dépendance n'aille pas à contrario des contraintes qui vous sont imposées. Exemple : Dépendance indirecte qui dépend de .net 4.5 alors que vous ciblez .net 4.0.

5. Garder un œil sur ses dépendances

Comme votre application, les dépendances évoluent. Ceci peut être pour votre plus grand bonheur. Mais ceci peut aussi être un véritable casse-tête à gérer.

Les problèmes pouvant être anticipés si on suit l'actualité de ses dépendances :

  • Breaking changes
  • Classes/Méthodes obsolètes
  • Classes/Méthodes abandonnées
  • Classes/Méthodes remplacées par d'autres
  • Ajout/suppression de dépendances indirectes
  • Abandon du projet par l'éditeur
  • .. etc…

Outre le fait de suivre ses informations, il faut aussi mettre à jour régulièrement ses dépendances. Ceci permet de réduire le travail à fournir. Si on espace les mises à jour de plusieurs mois ou années, on s'expose à de grands risques. Exemple : perte de temps, delta trop important entre deux versions et donc situation difficilement gérable.

6. Garder ses dépendances au chaud

Il faut toujours stocker les dépendances et/ou les fichiers qui ont servi à leur déploiement. Que ce soit sur un TFS, un SharePoint ou un simple partage. Ces fichiers vous seront indispensables pour remonter un environnement. Que ce soit un environnement de développement ou de production.

Même si aujourd'hui des dispositifs types Nuget sont devenus fréquents, j'ai toujours pris l'habitude de conserver les fichiers téléchargés par ceux-ci. Qui sait, la source sera peut-être coupée un jour.

Stocker, c'est bien, mais il faut aussi penser à noter clairement la plateforme cible. Il n'y a rien de pire que d'avoir deux DLL avec le même nom, le même numéro de version et ne plus savoir laquelle est destinée au 32 bits ou au 64 bits.

 

Il est fort probable que j'oublie une ou deux petites choses, mais l'essentiel est là.

Et vous, auriez-vous d'autres conseils à donner sur la gestion des dépendances ?

Depuis ce début d'après-midi, on peut aussi profiter des Minidrones de Parrot avec une tablette Windows 8.1 !

Contrairement à la version Windows Phone, cette version n'est pas en beta.

L'ensemble des fonctionnalités déjà présentes sur iOS, Androïd et Windows Phone sont disponibles, exception faite de la partie sociale. L'application a exactement la même ergonomie que sur les autres plateformes. On peut donc passer de la tablette au téléphone sans se poser de questions.

Je viens de tester avec un Rolling Spider et ma tablette Asus Vivota. On retrouve les mêmes comportements qu'avec un Windows Phone. C'est aussi bon. J'ai tout de même préféré utiliser le mode de pilotage dit « manette » , car utiliser le gyroscope de la tablette pour déplacer le drone m'a semblé trop étrange (voir inutilisable du fait de la taille de la tablette 10pouces). Il y a une option associée à bing map, mais cela ne semble pas marché comme convenu. Il y a un petit problème de compte développeur Bing Map ;) (en tout cas, c'est ce que j'ai constaté sur ma tablette)

Pour le téléchargement, cela diffère d'une machine à l'autre. Par exemple mon PC portable n'a pas accès à l'application (Dell XPS 17)

Belle exemple d'application universelle adaptée ;)

Maintenant, il me reste à m'acheter une seconde batterie pour mon drone. 10 minutes de jeux, c'est court quand on reste un grand gamin..

Depuis ce matin, on peut enfin profiter des Minidrones de Parrot avec un Windows Phone !

L'application est en beta pour le moment, mais l'ensemble des fonctionnalités déjà présentes sur iOS et Androïd semblent disponibles. D'ailleurs l'application a exactement la même ergonomie.

Je viens de tester avec un Rolling Spider et mon Lumia 1520 (Windows Phone 8.1 Cyan) et c'est bon, c'est même très bon ;)

Pour le téléchargement, cela se passe par ici.

Heureux propriétaire de SSD Samsung 840 EVO, j'ai une bonne nouvelle pour vous. Disposant moi-même de deux de ces SSD pour mes serveurs de test, j'ai testé l'utilitaire « Samsung SSD 840 EVO Performance Restoration Software » destiné à résoudre les récents problèmes de performance découverts sur ce modèle.

http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/support/downloads.html

 

L'utilitaire fonctionne parfaitement sur Windows 2012 R2 en version Core. Je l'ai exécuté sur mes deux serveurs Core sans la moindre difficulté. Il faut cependant noter que le processus nous oblige dans un premier temps à arrêter le serveur pour appliquer la mise à jour. Il faudra donc être près de la machine pour pouvoir la relancer. Après redémarrage, l'utilitaire se relance de lui-même et termine les opérations d'optimisation. Rien à redire, cela fonctionne parfaitement bien et depuis je n'ai pas constaté le moindre problème.

Juste un petit mot pour partager avec vous la joie de m'être vu décerner un nouveau MVP Award dans la spécialité Microsoft Integration.

 

L'information date du 1er octobre, mais ce n'est qu'aujourd'hui que j'ai enfin pris le temps de déposer le dernier disque reçu. Cela commence à avoir de l'allure.

 

Merci à Microsoft pour cette reconnaissance et bravo à tous les nouveaux MVP et à tous les MVP renouvelés ;)

Depuis l'arrivée des rubans dans SharePoint, il m'a de nombreuses fois été remonté des difficultés pour naviguer dans une librairie utilisant des dossiers. Avec le temps, je me suis rendu compte qu'il y avait une commande que les utilisateurs ne trouvaient pas naturellement « Naviguer vers le haut ».

Celle-ci se trouve dans le ruban « Bibliothèque » groupe « Gérer les affichages ». Bien entendu la commande est grisée si l'on ne se trouve pas dans un dossier.

Petite perle constatée lors du déploiement de IIS8, la Technical Preview de Windows Server conserve la compatibilité avec IIS6. Au vu du nombre de produits qui en ont encore besoin aujourd'hui pour la MetaBase, WMI ou les scripts, il n'y a pas de quoi être surpris. La petite bizarrerie vient du fait de garder la console de gestion II6. Pourquoi supporter une console pour un serveur IIS6 (donc 2003R2) qui n'est plus supporté ? Cela sent la feature qui n'a pas encore été revisitée.

Cela devrait en réjouir plus d'un. Mais gardon tout de même à l'esprit qu'il ne s'agit pas là de la version finale du produit, et que tout peut changer d'ici là.

En voulant activer l'interface de gestion de Windows Defender sur un Windows Server Technical Preview, je suis tombé sur une petite perle : un feature nommé « Soft Restart ».

Qui n'a jamais rêvé rebooter un serveur sans avoir à étendre le reboot du bios et de tous ses contrôleurs ?!!!

Si le titre ne vous dit rien ou que l'affirmation vous semble étrange, il y a des chances que le contenu qui suit vous concerne.

De manière générale, pour les services ou un site web on utilise des certificats pour sécuriser des échanges ou authentifier un tiers. À plusieurs reprises déjà, j'ai été confronté à de mauvais usages de certificats, mais très récemment j'ai été confronté à un cas qui dépasse tout. Cela n'est pas la première fois que j'observe cette situation. Je profite donc de cet article pour tenter d'endiguer cette pratique qui compromet la sécurité de vos applications.

  1. L'objectif visé (mais non atteint) consiste à vouloir authentifier les applications autorisées à se connecter à un service. Pour se faire, les applications clientes doivent disposer de certificats signés par une autorité de certificat (CA).
  2. Dans le cas présent, les certificats sont fournis par les administrateurs en charge de l'hébergement des services.
  3. Chaque équipe de développeurs reçoit le certificat public du CA pour le reconnaitre comme une autorité de certificat de confiance + un certificat qui lui est propre.
  4. Les développeurs de l'application cliente 1 doivent utiliser le certificat 1
  5. Les développeurs de l'application cliente 2 doivent utiliser le certificat 2
  6. … etc…

En soi, la chose est classique.

Note : Je ne sais pas pourquoi, cette démarche est confondue avec l'utilisation de certificats d'authentification mutuelle. Pour rappel, dans le cas de certificats d'authentification mutuelle, il faut que chaque partie (client et serveur) fournisse un certificat pour s'identifier. Rien à voir donc avec ce cas. Une présentation propre du sujet peut se trouver ici.

Là où le bât blesse, c'est que les développeurs n'arrivent pas à s'authentifier quand ils utilisent leurs certificats d'applications. Et là on me sort la solution folle qui marche : « utiliser le certificat de l'autorité de certificat »… oui, le certificat public que tout le monde connait et qui sert à dire « en tant que client je fais confiance aux certificats fournis par ce serveur », (oui, le fameux certificat avec CA dans son nom !)…. Mais cela ne choque personne… (hors mis moi...peut être...)

Une erreur de configuration a certainement été opérée sur le serveur.

Les conséquences sont énormes :

  • On ne peut plus interdire une application ou une autre.
  • Il suffit de fournir le certificat du CA pour se connecter.

À partir du moment que quelqu'un connait l'autorité de certificat, il a le droit de se connecter. C'est fou !

Certains défendront la chose en disant « oui, mais il faut déjà connaitre le certificat ». À ceux-ci je répondrai :

  • Imaginer dans le cas d'une autorité de certificat d'entreprise, toutes les machines d'un AD peuvent utiliser le service !
  • Pour faciliter l'administration, le certificat du CA est généralement public et fourni via un site web (que ce soit sous Apache ou IIS)

D'autre diront, « il y a peu de chance que quelqu'un essai d'utiliser ce certificat comme cela ». Pour ceux-ci mes réponses seront basées sur l'expérience.

  • Une chance de contourner la sécurité, c'est une chance de trop.
  • Cela fait déjà 3 fois que je suis confronté à ce cas et qu'aucun développeur n'est choqué par ce qu'il fait en utilisant un certificat CA comme ClientCredential.

Moralité : Attention lors de vos développements, ce qui fonctionne n'est pas forcément bon. Et une information publique comme ce certificat public de CA ne doit surtout pas être utilisée de la sorte. On doit toujours utiliser une information « privée, valide », et donc un certificat non révoqué généré par une autorité de certificat de confiance.

L'annonce de Windows 10 a déjà fait couler beaucoup d'encre. Ce qui ferait presque croire qu'il n'y a pas de version Server de l'OS. Heureusement, il n'en est rien.

Il y a même une liste de nouveautés très alléchante What's New in the Windows Server Technical Preview :

Pour le moment, seuls les heureux détenteurs d'un abonnement MSDN peuvent en profiter. Pour y accéder, il leur faudra taper les mots magiques «Windows Server Technical Preview » ou cliquer sur le premier lien de la section Server. 

Petite surprise si vous utilisez le premier lien : en plus des habituelles ISOs, on peut télécharger un VHD de la bête.

Faites chauffer les routeurs, ça va télécharger dur !

Supprimer un projet créé dans Visual Studio Online n'a rien de bien compliqué. L'opération est la même pour une TFS on premise. Il faut juste se souvenir que la collection de projets porte le nom « DefaultCollection ».habituellement, celui-ci n'est pas visible dans nos URL Visual Studio Online.

À partir du moment où l'on utiliser l'option /collection:"https://VotreNomPerso.visualstudio.com/defaultcollection", presque toutes les commandes passent.

Pour supprimer un site il faut donc aller dans le répertoire contenant les exécutables pour piloter TFS :

cd "%programfiles(x86)%\Microsoft Visual Studio 12.0\Common7\IDE"

On demande ensuite la suppression via la commande suivante :

TFSDeleteproject /force /collection:"https://VotreNomPerso.visualstudio.com/defaultcollection" "LeNomDuProjetASupprimer"

On confirme, et le tour est joué.

Dans le cadre de démos TFS et SharePoint, j'ai souvent besoin de reproduire des environnements complet (ou presque). Forcément, toute bonne démo n'a pas toujours lieu dans un contexte réel. À force de galère avec SharePoint Foundation 2013 (même avec le SP1), j'en suis arrivé à avoir une liste de problèmes qui varient en fonction des versions d'OS, de SQL Server, des langues des packages, maque de ressources … etc …

Pire : dans un certain nombre de cas, j'ai utilisé des VM sans domaine. (On ne peut pas tous avoir un portable avec 32Go de RAM)

Aujourd'hui pour un petit lab/démo minimaliste avec un seul serveur incluant TFS 2013 / SharePoint Foundation 2013 / Reporting, je suis arrivé à un déploiement fiable à 100% et des performances acceptables dans le contexte suivant :

  • 2 CPU
  • 8Go de RAM (on peut descendre à 4Go lors du déploiement SQL+TFS, 6Go lors du déploiement SharePoint, mais pas lors des démos)
  • Tous les produits sont des packages et ISO anglais (en-US)
  • Windows 2012 R2 en workgroup
  • SharePoint Foundation 2013 avec SP1
  • SQL 2012 pour l'instance TFS et le Reporting
  • SQL 2008 R2 pour l'instance SharePoint (en workgroup, malheureusement, il faut laisser SharePoint le déployer)

Je garde deux instances SQL pour ne pas mélanger les bases TFS et SP. Cela me permet aussi de garder les collations conseillées pour chaque produit (oui cenne sont pas les mêmes). Je ne fais pas la migration de l'instance SQL SharePoint vers 2012, car je n'en ai pas l'utilité ici.

Note pour les petits malins : Quand on ne dispose que d'un seul serveur avec très peu de ressources, il ne faut pas espérer déployer celui-ci comme contrôleur de domaine, SharePoint Foundation n'aime pas (mais alors pas du tout).

 

Pour un déploiement en workgroup qui fonctionne à tous les coups, je ne fais aucune configuration durant le déploiement.

L'ordre du déploiement a lui aussi un impact sur le résultat final (théoriquement, on peut installer SP avant TFS mais j'ai eu des surprises il y a quelques mois en faisant dans cet ordre):

  • Installation de l'OS.
  • Changement de nom de la machine (pas de configuration IP car la machine va peut-être passer d'un réseau à l'autre pour les démos).
  • Application de toutes les updates Windows critiques disponibles jusqu'à ne plus en avoir (surtout pas d'optionnelles, cela peut briser le fonctionnement de SharePoint Foundation… entre autres la recherche).
  • Reboot obligatoire
  • Installer SQL 2012 avec Service pack.
  • Appliquer les updates Windows critiques
  • Reboot obligatoire
  • Installer TFS 2013 avec Update 3
  • Appliquer les updates Windows critiques
  • Reboot obligatoire
  • Installer les prérequis SharePoint 2013
  • Reboot obligatoire
  • Important : Vérifier que tous les prérequis sont déployés
  • Important : Appliquer les updates Windows critiques
  • Reboot obligatoire
  • Installer SharePoint Foundation 2013+SP1
  • Appliquer les updates Windows critiques
  • Reboot obligatoire

Ensuite, on peut procéder à la configuration

  • Lancement le Wizard de configuration SharePoint
  • Lancement de la configuration du Reporting Services
  • Lancement de la configuration du tiers applicatif TFS uniquement sans collection par défaut (si non, il faudra reconfigurer les parties SP et Reporting ultérieurement)
  • Déploiement des compléments TFS pour SharePoint via la console TFS (webparts, dahsbords)
  • Configuration de la connexion TFS / Reporting
  • Configuration de la connexion TFS / SharePoint via la console TFS.
  • Créer une première collection TFS

Profiter de l'environnement, il devrait être ok pour faire des démos !

Et pour ceux qui ne verraient pas pourquoi je décris cette méthode ainsi, vois l'écran que vous révérez d'avoir si vous installez votre environnement à l'arrache :

Dans le cadre d'une ferme SharePoint 2013 + Office Web Apps, j'ai été obligé de changer la DNS de la ferme Office Web Apps. Dans la MSDN, il n'existe pas de page décrivant la procédure, j'ai donc été obligé d'improviser.

Pour commencer, sur le serveur qui a les Office Web Apps, il faut mettre à jour l'URL interne

Set-OfficeWebAppsFarm –InternalURL "http://ma-nouvelle-url.lan"

 

Sur l'un des serveurs de la ferme SharePoint, il faut mettre à jour l'URL de la ferme Office Web Apps. J'ai été un peu surpris de découvrir qu'il n'existait pas une commande unique pour cela.

Soit un change les types de documents un à un, soit on supprime le binding et on l'ajoute ensuite. Je n'avais pas trop avait de me taper l'ensemble des types de fichiers un à un, j'ai donc opté pour la suppression puis l'ajout. Ce qui donne :

Remove-SPWOPIBinding -All:$true

New-SPWOPIBinding -ServerName " ma-nouvelle-url.lan" -AllowHTTP

 

Le reste de la configuration n'a pas besoin d'être changée. Il ne faut donc pas reprendre toute la configuration du SharePoint et de son Binding.

Ça y est enfin, mon projet « KISS Workflow Foundation » est lancé ! Celui-ci a pour vocation de vous faire partager un maximum d'échantillons de codes.

Pour le moment, il contient une bonne vingtaine de solutions. Celles-ci reprennent les bases de Workflow Foundation, de la création d'activités à l'update dynamique en passant par des joyeusetés comme le rehosting et le versionning. Je ne manquerai pas de faire évoluer les codes.

En gros, « il y a tout ce qu'il faut pour ce lancer ».

Prochaine étape : La création de scénarios d'usages évolués ;)

Mon dernier article pour MSDN est disponible : "Utiliser l'approche Contract First avec Workflow Foundation 4.5".

Vous pourrez y trouver tout le nécessaire pour utiliser les contrats WCF avec WF4 (implémentations, astuces, limites…)

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- Créer un périphérique Windows To Go 10 ! par Blog de Jérémy Jeanson le 11-21-2014, 04:54

- RDV à Genève le 12 décembre pour l’évènement “SharePoint–Office 365 : des pratiques pour une meilleure productivité !” par Le blog de Patrick [MVP Office 365] le 11-19-2014, 10:40

- [IIS] Erreurs web personnalisées par Blog de Jérémy Jeanson le 11-19-2014, 00:00

- BDD/TDD + Javascript par Fathi Bellahcene le 11-16-2014, 16:57

- Sécuriser sans stocker de mots de passe par Blog de Jérémy Jeanson le 11-15-2014, 08:58

- Où télécharger la preview de Visual Studio 2015 ? par Blog de Jérémy Jeanson le 11-13-2014, 21:33

- Les cartes sont partout ! par Le blog de Patrick [MVP Office 365] le 11-13-2014, 17:26

- [ #Office365 ] Courrier basse priorité ! par Le blog de Patrick [MVP Office 365] le 11-12-2014, 08:56

- [Oracle] Fichier oranfsodm12.dll absent du package client par Blog de Jérémy Jeanson le 11-10-2014, 20:44

- [ #Office365 ] Le chapitre 1 des Groupes est écrit, et alors ? par Le blog de Patrick [MVP Office 365] le 11-10-2014, 20:23