WinRT ou le retour en force du COM+

J’ai voulu ajouter « Lol » à la fin du titre de ce lien, mais il paraît que ça ne se fait pas.

On retrouve plein d’articles sur le NET nous parlant de WinRT, des incidences lorsqu’on doit développer en C#.
Je vous propose donc ce petit post, non pas pour vous parler de WinRT mais plutôt pour vous parler de COM(+) et vous expliquer ce choix, qui semble hasardeux, de Microsoft.

Tout d’abord, un petit rappel.

Observez le schéma de l’article, il a fait le tour du monde. Avec Windows 8, il y a deux façon de considérer Windows. La première en mode WinRT (partie de gauche), l’autre en mode desktop (partie de droite).

En mode WinRT, on vise un nouveau type d’application dites « Metro style Apps », dénomination valable jusqu’en août 2012 date où l’on appris que le terme était déposé et sujet à copyright. On parle désormais d’application ModernUI (ou Windows 8 style)
En mode Desktop, on développe classiquement, C++, C#, VB.NET, Assembleur

Beaucoup de développeurs .NET ont espéré, comme Java en son époque, que Windows allait devenir « CLR ». En d’autres termes, l’OS serait une grande machine virtuelle, on gagnerait en simplicité tout en se débarrassant de ces bonnes vieilles API Win32.

Mais que faire alors des anciennes applications justement Win32 ? Il aurait suffit de les virtualiser ! On le fait déjà quelque part pour faire fonctionner les applications 32bits (et même 16 bits!) sur du Windows 64 bits (merci WoW64^^). Développer une application tournant dans l’OS/CLR, qui émulerait les API Win32 et ferait fonctionner toute application non .NET dans cette Sandbox ! Simple ,non ?

Oui mais voilà, ce n’est absolument pas ce que Microsoft a fait ! Mais allons donc ? Pourquoi ? C’était si simple !

Disons que ce n’est pas parce qu’une chose a l’air simple en apparence qu’elle l’est dans les fait. Tout d’abord, au risque de passer pour un dinosaure, il faut savoir que depuis fort longtemps tout Windows est COM… ou DCOM… Enfin COM+. De quoi je parle ? Du fait que peut après l’apparition de la base de registre (Windows 95), Microsoft a planché sur des vrais soucis de communication inter logiciel : faire en sorte qu’un copier/coller fonctionne entre un Word et un Excel et mieux, que les logiciels échangent des comportements en temps réel (exporter un tableau Excel dans Word par Exemple). Microsoft a commencé par une technologie type OLE (Object Linking and Embedding) qu’ils ont rapidement muté en composant ActiveX et composant COM : les composants ActiveX étant « visuel » (comme une applet Java), les composants COM étant eux des composants sans interface.

Il faut imaginer dès l’époque que tout était bien pensé. On parlait de composants comme au sens moderne. Car à la différence de l’objet qui tourne dans un processus, le composant a une sorte d’existence propre, des entrées et des sorties (je vous passe les histoires de surrogate chez Microsoft^^). Vous avez bien lu ! J’ai fait un raccourci, mais un objet est une représentation binaire qui n’a de sens que dans son process ! Le composant, lui, existe en dehors !
Pour ces raisons, lorsque vous faites du WCF, vos objets exposés peuvent et même doivent prendre la dénomination de composants. Idem pour COM+, ce bon vieux CORBA (certes, on parle d’IOR pour des références d’objets interopérable à distance, mais la vision externe est un « composant »), CCM (pour ceux qui connaissent) et surtout les EJB !

OLE/COM date des années 1995… Et fut transformé en DCOM vers 1998 (Le D signifiant Distributed), technologie permettant d’appeler les composants COM à partir d’un autre ordinateur puis renommé COM+ dès les années 2000. COM+ est le mix de DCOM et d’une technologie transactionnelle (MTS – Microsoft Transaction Server) développée par Microsoft dans l’optique de concurrencer CORBA et ses service OTS (Object Transaction Service). Il faut imaginer MTS comme le service JTS de JEE, où la partie transactionnelle des EJB stateless (avec un peu de stateful mais avec des limitations beaucoup plus forte), où bien encore du WCF avec des TransactionFlow et autres TransactionScopeRequired configurés.

Quand .NET est apparu, il fut vanté par rapport à COM+ pour sa simplicité. Il ressemblait à Java, finit les DLL Hells (ou l’enfer des DLL car COM+ exigeaient des inscriptions en base de registre, le versioning était très compliqué).

Sauf que COM+, tandis que .NET évoluait, a énormément évolué de son côté… notamment en se débarrassant de l’obligation d’aller en base de registre… mais également en améliorant le versionning, la possibilité de faire du side-by-side, etc.

Le choix de faire du WinRT en « COM-like » est beaucoup plus logique qu’il n’y parait. Contrairement aux apparences, C++ ne peut pas être concurrencé par des technologies à base de VM sur un ordinateur. Tout simplement parce que, même si pour bon nombre de projets de gestion c’est suffisant, la performance ultime ne peut être atteinte qu’en se calant le plus possible à la machine : RAM, disques, processeurs, CPU et registres.
Pour ces raisons, Microsoft a fait évoluer son OS dans le bon sens, le rendant multiplateforme (bienvenue aux processeurs ARM) tout en faisant évoluer C++ !

Mais il ne faut pas se tromper. Quand on cible WinRT en C++, on développe en C++/CX (Component Extensions) comme l’on développait en C++/CLI (Common Language Infrastructure) lorsqu’on ciblait la CLR. Ca c’est la façon qui arrange tout le monde. C++ dans le même sac que C#, VB.NET, Javascript, etc… car c’est juste un autre langage, on ne gagne rien.

Demeure pour le puriste, que l’on peut faire du WRL (Windows Runtime C++ Library) ! WRL c’est l’équivalent d’ATL (Active Template Library) en COM+ ! Débarrassé de pratiquement tout, on attaque les choses sérieuses et on a latitude pour réaliser des appels à l’OS… d’un autre monde ;-)

Toutefois, même si je suis un aficionados d’ATL, et donc de WRL, je ne le recommande absolument pas en situation projet, à moins d’y être fortement contraint (pour des raisons de performances notamment, ou bien parce que vous développer un composant hyper technique). Car cela demande énormément de compétence et s’avère très difficile à la maintenance !

Message bizarre sur Winrm

Bizarre ? Vous avez dit bizarre ?
Effectivement, après plusieurs années d’expérience, c’est la normalité qui est bizarre en informatique.

Plus sérieusement, un petit message sérieux aujourd’hui sur Team System en lançant plusieurs tâche Winrm. Je vous laisse en apprécier la teneur.

The WS-Management service cannot process the request. The maximum number of concurrent operations for this user has been exceeded. Close existing operations for this user, or raise the quota for this user (0x803381A6)

Le message est clair mais pourtant surprenant, mes scripts TFS s’occupant certes du déploiement (les workflows ont été personnalisés sous Worfklow Foundation, ils nécessitent des assemblies complémentaires et mieux, au niveau du Build Definition, des Custom Editors sont fournis^^), mais pas pour occuper les 200 connexions autorisées par défaut !

Bien que je cherche encore le comment du pourquoi… Voici un petit « quick and dirty » workaround !!

A partir de Windows 2008 R2, il faut exécuter les commandes suivantes :

winrm set winrm/config/Service @{MaxConcurrentOperationsPerUser="400"}
net stop winrm
net start winrm
net start vmmagent

En deçà, voici les commandes

winrm set winrm/config/Service @{MaxConcurrentOperations ="400"}
net stop winrm
net start winrm

Visual Studio 2012 et C++ 11 (C++0x)

C++0x a mis du temps a sortir puis l’année dernière en août, grande nouvelle, approuvé unanimement. Portant désormais le nom de C++11 il apporte de grand changement par rapport à l’ancienne norme (datant de 2003).

Nouveautés dans le langage, nouveautés dans la bibliothèque standard mais également  les bibliothèques du technical report 1 (Kisako ? Le technical report 1 est un document proposant des additions à la bibliothèque standard : has tables, expressions régulières, smart pointers, etc. Sorti en 2003, nombre de ces additions ont été implémentées par les vendeurs au point où la plupart font désormais partis du standard officiel C++11).

Pourquoi ce post ? Parce ce que Visual Studio 2012 (anciennement nommé VS 2011) est en release candidate et qu’il apporte des nouveautés à l’implémentation partielle de C++11  sous VS2010 !!

Voici la liste, probablement non exhaustive de ces nouveautés conformes à C++ 11 :

*       rvalue references en version 2.1 <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1138>  par rapport à la 2.0
*       lambdas en version 1.1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf>  par rapport à la 1.0.
*       decltype en version 1.1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf>  par rapport à la 1.0

*       Amélioration d’Alignment (mais non complet) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf>
*       Enumérateurs fortement typés <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf>
*       Forward declared enums <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf>
*       Standard layout and trivial types <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm>
*       Atomics <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html>
*       Strong compare and exchange <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2748.html>
*       Bi-directional fences <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2752.htm>
*       Data-dependency ordering <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm>
*       Range-based for loop <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html>

Kill de plusieurs tâches sous Windows


Un programme est bloqué sur votre machine Windows ? Facile, task explorer, on sélectionne l’application ou le process, bouton droit « End Task « et tout s’arrête.
Mais comment faire lorsque plusieurs instances du même programme sont lancés ?


J’ai récemment aidé un développeur dont le programme lançait plusieurs tâches net.exe ; ceci afin de déploiement des composants réseaux et nombre de ces process (tous ?) restaient en mémoire.
Afin de tuer toutes ses tâches d’un coup, il existe une commande simple « taskkil » qui accepte un filtre en option (/fi) ; lequel permet par exemple d’indiquer de killer tous les process dont l’image porte un nom comme dans l’exemple suivant.
taskkill /f /fi « IMAGENAME eq net.exe »

Dans la même idée, on peut via une seule instruction mettre une fin à tous les programmes qui ne répondent pas

taskkill /f /fi « status eq not responding »

D’autres options sont disponibles en tapant taskkill / ?

Connaissez-vous le pattern CQRS ?

A l’heure du Cloud, le CQRS est un des patterns absolument connaître.

Le Command Query Responsibility Segregation est un pattern simple qui dissocie les opérations d’écritures des opérations de lecture.
Fondamentalement parlant, le CQRS est un pattern qui dissocie les opérations de commandes (les opérations d’écritures) des opérations d’interrogation (les lectures). Ainsi codé, par un système d’évènement et de synchronisation optimiste des locks, on peut gagner énormément en throughput car on limite les opérations de verrouillage (lock)  dans le système sous-jacent (souvent une base de données).

Conceptuellement parlant, le CQRS repose sur une logique où la donnée qu’on manipule existe sous 2 visions. Une vision informative, d’affichage, de requête, qui ne reflète pas forcément le réel (par exemple, le nombre de places disponibles dans un théâtre) et une vision de commande, de transaction, d’écriture, qui exige de travailler avec des données réelles (le moment où l’on réserve vraiment)
Le CQRS prend tout son sens dans des architectures demandant de la performance ou de grandes montées en charge. On choisit d’impacter le fonctionnel, le perçu client (le client qui réserve une place de théâtre, ne sera sûr de l’avoir qu’au moment du paiement) au profit des performances et de la simplicité du système (le CQRS est un pattern simple qui n’exige pas des mécanismes compliqués de synchronisation. Dans notre exemple du théâtre, bloquer des places pendant les commandes d’un utilisateur impliquent des mécanismes de synchronisation en base de données, session, etc.).

http://code.msdn.microsoft.com/windowsazure/CQRS-on-Windows-Azure-125d11d1
http://martinfowler.com/bliki/CQRS.html

Gérer les hiérarchies de branches dans Visual Studio

Afin de gérer les hiérarchies de branches dans Visual Studio, après toute opération de Branch, il faut penser à convertir le dossier.

Imaginons un Team Project ARCHITECTURE ayant une application dénommée Magma ayant un répertoire Main contenant le tronc commun de développement.

Imaginons par ailleurs que vous ayez un autre répertoire Magma/Branches et que vous souhaitiez créer la branche v5.7.0 à partir du Main et l’apercevoir sous forme de hiérarchie.

Il suffit d’appliquer la méthode suivante :

1 – A partir du Source Control Explorer, aller sur $/ ARCHITECTURE/MAGMA/Main, bouton droit -> Branching and Merging -> Branch

2 – Dans Target indiquer $/ARCHITECTURE/MAGMA/Branches/v5.7.0, cliquer sur OK

3 – Faire un check-in:commit

4 – Une fois l’opération effectuée, aller sur $/ ARCHITECTURE/MAGMA/Branches/v5.7.0, bouton droit -> Branching and Merging -> Convert to Branch

Idéalement, faire cette opération également sur $/ ARCHITECTURE/MAGMA/Main.

Désormais lors d’un bouton droit-> Branching and Merging, on a désormais le menu View Hierarchy ; -)

Debogage à distance avec VS 2010

Les fonctionnalités de Débogage à distance sont véritablement pratiques pour savoir ce qui se passe sur un poste distant. Microsoft fournit l’installation d’un Remote Debuger (http://www.microsoft.com/downloads/fr-fr/details.aspx?familyid=60ec9d08-439b-4986-ae43-0487eb83c09e), une version « light » de ce que propose Visual Studio, pour permettre de déboguer des machines distantes, notamment des serveurs.

L’installation est on ne peut plus simple; on a le choix d’exécuter le Remote Debugger sous la forme d’un service (tournant sur un compte et pouvant aller jusqu’à accepter tout type d’utilisateur distant. Dans ce dernier mode, on ne peut toutefois que faire du debugage natif) ou sous la forme d’un programme.

Nous conseillons vivement cette dernière option pour du debugage sur des serveurs car cela ne devrait être que très occasionnel.

 

Configuration du Remote Debuger

 

Lors de l’installation/configuration, une seule option est disponible: configurer ou non le Remote Debugger en tant que service. Dans ce mode, le Remote Debugger est toujours actif et accessible à distance.

Le compte par défaut proposé est LocalSystem, ce qui est judicieux mais en même temps très ouvert.

Local System est un compte Built-In donnant des privilèges élevés sur l’ordinateur local et qui permet d’agir sur le réseau comme s’il s’agissait de l’ordinateur lui-même. Il n’y a pas besoin de mot de passe.

Lors de la configuration, il vous est possible de configurer un autre compte mais ses privilèges doivent avoir « Ouvrir une session en tant que service ». Microsoft propose par ailleurs que ce compte soit membre du groupe Administrateurs.

 

Options du Remote Debuger

Lancer le programme manuellement, puis allez dans Options. Le serveur porte un nom de la forme user@machine, plus précisément le user précise un domaine.

En mode Authentification Windows, on peut se permettre n’importe quel type de débugage ; le bouton « Autorisations » permet d’indiquer les comptes ayant le droit de deboguer.

Vous noterez l’option « Aucune authentification (natif uniquement) » et « Permettre à tous les utilisateurs de déboguer » qui permet à n’importe qui se connecter et deboguer, mais des applications natives seulement. Ce mode est à proscrire, d’autant plus que votre machine peut se trouver, pardonnez l’expression, en milieu « hostile » et soumise à attaque (en clair, faîtes cela chez vous, pas dans votre entreprise).

Par ailleurs, comme son nom l’indique, le debogage en mode natif

Classiquement, le compte qui debug sur une machine A en remote sur la machine B doit être le même… si possible. Malheureusement, ce n’est absolument pas le cas si A est dans un domaine et B dans un autre.

 

Debogage en interdomaine

Les choses se compliquent lorsque l’on veut déboguer à distance une machine hébergée dans un différent domaine. Rajoutons une contrainte qui a son importance, lorsque les deux domaines en question ne sont pas approuvés. Ce cas de figure qui peut vous sembler bizarre arrive bien plus fréquemment qu’on ne le croit.

Imaginons un environnement de test ou recette possédant son propre domaine, son propre AD, ses propres contraintes de sécurité ; ceci afin d’éviter tout télescopage possible. Il n’y a aucune raison de faire un domaine de production approuver un domaine de test/recette. Mais il est en revanche possible d’imaginer un développeur sur son réseau de développement (donc un environement réel, d’entreprise) nécessitant un débugage sur le domaine test/recette car un bug ne se produit que dans cet environement. Sans cette capacité de débogage, son bug ne peut être résolu et son application ne vas pas en prod.

Bref, lorsque les domaines ne sont pas approuvés, on peut choisir le débogage natif (non intéressant pour du débogage managé) mais celui-ci exige, pour des actions interdomaines de permettre à tout le monde de pouvoir se connecter à machine créant ainsi un trou de sécurité.

Il existe néanmoins une solution, ou plutôt 2 solutions.

Option 1

La première exige de jouer avec les Local Security Policy (Stratégie de sécurité locale). Dans le panneau de configuration, outils d’administration, si on lance l’application, il nous est possible (pour peu que l’on possède les droits suffisants) de changer la façon dont un compte local s’expose à l’extérieur en terme de sécurité.

Dans la section « Local Policies », « Security Options », changer la clé « Network access: sharing and security model for local accounts » de « Guest only – local users authentivcate as Guest » à « Classic – local users authenticate as themselves ».

En faisant ce réglage, on indique qu’un compte local à la machine sur un réseau se présente en tant que lui-même. Cette option est classique lorsque vous faite un Workgroup de machine et non pas un domaine. Pour permettre à un compte d’accéder à un partage par exemple, il suffit de dupliquer ce compte ; même user, même password; pour que l’accès soit autorisé

Le Remote Debuging exigeant une communication dans les deux sens, il vous faut faire ce réglage sur les 2 machines impliquées dans la communication.

Cette option fonctionne bien mais souffre d’une grosse limitation… On se retrouve à modifier des réglages de sécurité sur les 2 machines impliquées. Lorsque l’une d’en être elle est une serveur, c’est une sacré limitation car on augmente la surface d’attaque. Des problèmes peuvent surgir au niveau partage et DCOM et quelqu’un à distance peut s’authentifier avec votre compte plutôt qu’en Guest. Par ailleurs, il faut se soucier d’avoir un compte en double avec un mot de passe similaire pour que cela fonctionne (on peut faire correspondre un compte de domaine, même user/password, à un compte local).

Option 2

L’option 2 est beacoup plus belle… Et beaucoup plus simple aussi (sauf si l’on se met à déplacer le répertoire utilisateur AppData sur le réseau. Nous préciseronts ce point par la suite).

L’astuce consiste à utiliser une seule et unique commande : un runas ! Mais attention, ce runas est lancé dans un mode spécial.

Pour rappel, le runas permet l’exécution d’un programme sous le compte d’un autre utilisateur. Il suffirait a priori de faire un runas en précisant Visual Studio et banco, le remote debugger et VS 2010 se retrouve dans le même domaine et, comme dirait Dora, c’est gagné !!

Malheureusement, ce n’est pas aussi simple. Si on effectue un runas classique en précisant un user sur un autre domaine, malheureusement l’application que l’on lance va s’exécuter avec un compte… d’un autre domaine… et ceci en local .

Bref, vous l’aurez compris, ce n’est pas possible puisque votre machine locale respectera les contraintes de son propre domaine et n’autorisera pas un compte extérieur d’un autre domaine à lancer un programme sur votre machine.

Nous souhaiterions non seulement pourvoir utiliser notre poste local, dans son domaine et ses crédentials, tout en faisant en sorte que les communications réseaux s’effectuent sous l’identité d’un autre compte.

Si nous vous disions que la commande runas a été modifiée en ce sens par Microsoft en lui attribuant l’option netonly ?

Pour preuve, notez l’appel suivant (ligne de commande) qui permet de lancer Visual Studio sous le compte local de l’utilisateur et qui fait en sorte que les appels réseaux s’effectuent avec un autre compte sous un autre domaine.

 

runas /netonly /user:domain\user « C:\localapp\Apps\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe »

Le programme vous lancera une invite de commande vous permettant d’indiquer le mot de passe.

Votre Visual Studio va se lancer sous votre propre compte, mais tout appel réseau se déroulera sous le compte/domaine ayant été précisé via la balise netonly.

 

Attention, un bug peut se produire.

Ce bug peut se produire si votre ordinateur local, un ordinateur d’entreprise, a été configuré pour que votre profil soit sauvegardé sur le réseau. Dans ce cas de figure spécifique, Visual Studio se connectera au partage réseau avec le compte fourni par /netonly et pas votre compte de domaine.

Il en résultera l’erreur suivante :

 

Don’t panic… Là aussi il y a une astuce, modifier dans la registry le répertoire AppData

Dans « HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders », il suffit de renseigner un répertoire local temporaire de votre machine. Pensez bien à modifier cette clé de registre après coup….

Pourquoi choisir l’option 2 vis-à-vis de l’option 1 ? Ou l’inverse ?

Parce que vous ne créez pas un deuxième compte et parce que vous ne modifiez pas les stratégies de sécurité locale des machines que vous souhaitez déboguer, l’option 2 est nettement plus intéressante que l’option 1. Une simple ligne de commande…

Toutefois, dans le cas d’un répertoire AppData sauvegardé sur le réseau, c’est une histoire de préférence car les 2 solutions ont leurs inconvénients et avantages. L’option 2 reste locale mais exige des modifications de clé de registre (ce qui est sensible pour un non averti). L’option 1 demande des modifications de part et d’autre, augmente le risque de sécurité, mais aucune action sensible en base de registre n’est requise… A vous de juger.

 

Comment deboguer à distance

Toute les possibilités de debug à distance sont maintenant activées.

Lancez Visual Studio, puis vous pouvez par exemple cliquer sur Debug, puis Attach To Process

 

 

Noter le qualifier. Il correspond au compte et à l’adresse de la machine sur laquelle on souhaite se connecter.

Plus précisément, on notera qu’il s’agit de l’adresse proposée par le msvmon (le remote debugger).

 

WinRM /WsManagement sans Powershell

WinRM est l’implémentation WS-Management de Microsoft.

Fonctionnant sur SOAP, cette technologie permet l’administration de machine à distance. WinRM est en version 2 pour le moment, fonctionne sur les derniers OS de Microsoft, fonctionne sur du Windows 2003 mais possède une limitation, il faut le SP2. C’est une sévère limitation si vous souhaitez utiliser Powershell v2 qui nécessite WinRM 2.0.

Il est classique dans l’écosystème d’un SI que des serveurs Windows ne soit pas dans les derniers services pack… Heureusement, Microsoft fournit depuis peu WS-Management 1.1 spécifiquement pour cet OS et pour Windows XP.
Il y a toutefois une limitation concernant Powershell. En effet, l’avantage de WinRM ne réside pas tant dans WS-Management que dans PowerShell qui vient directement s’interfacer à lui.
PowerShell 2 couplé à WinRM 2 permet l’administration de machine distante dans le nouveau langage de shell extensible de Microsoft.

Outils
L’installation de WinRM fournit 2 outils :
– winrm pour la configuration, le traitement de tâche WS-Management y compris à distance
– winrs, un client sur winrm

Astuces d’installation

L’installation de WinRM 2 et PowerShell 2 est très aisé sur des postes configurés classiquement, de simples clics et tout y est. Idem pour WS-Management 1.1.
Toutefois, un problème de taille peut subvenir lors de l’installation. En effet, WS-Management/WinRM impose l’activation du Firewall Windows sur les machines. C’est en soi une très bonne idée, mais en même temps un très gros problème pour les machines qui ne l’active pas ; reposant sur d’autres mécanismes.

Sur une machine où le firewall est activé, il suffit de lancer la commande 1 du tableau ci-dessous. Pour information, sur une machine Windows 2008 où WinRM est installé, cela se passera sans encombre. Dans le cas de figure où il n’y a pas de firewall, il faut exécuter les commandes de la ligne 2 du tableau ci-dessous (à l’exeption de la dernière).
Information cruciale, entre WinRM 1.1 (à comprendre WS-Management 1.1) et WinRM 2.0, il y a eu des changements de ports.
Dans la première version, tout s’effectuait sur le sports standard HTTP et HTTPS, à savoir 80 et 443. Dans la seconde version, les nouveaux ports sont 5985 et 5986. Dans une communication WinRM 2 vers WinRM 1.1 (ou dans l’autre sens), il faut penser à préciser les ports

Voici donc quelques commandes à connaître :

1 winrm quickconfig Permet la configuration de WinRM en ligne de commande. Démarre le service et créé les listeners associés. Démarre le firewall windows nécessaire au fonctionnement de WinrM
2 sc config « Windows Remote Management » start=auto
net start WinRM
winrm create winrm/config/listener?Address=*+Transport=HTTP
netsh firewall add portopening TCP 80 « Windows Remote Management »
Les commandes suivantes reproduisent plus ou moins à l’identique le fonctionnement de WinRM quickconfig (en pratique winrm quickconfig ouvre le port TCP 80 et 443, je ne l’ai pas détaillé ici) .
Si la commande WinRM quickconfig ne fonctionne pas, il y a de grandes chance que le Firewall Windows ne soit pas démarré.
On pourrait lancer ce dernier mais avec le risque suivant. Nous accédons aux machines distantes via RDP (mstsc).
Le démarrage du firewall pourrait couper la connection. Les commandes suivantes indiquent précisément ce que fait winrm quickconfig.Vous remarquerez la dernière ligne de nos commandes.
Avec winrm quickconfig, si elle plante, c’est comme si les autres n’avaient pas été exécutées.
Faite une à une en ligne de commande(à l’exception de la dernière si vous n’activer pas le firewall) , vous pouvez reproduire le comportement de winrm quickconfig ^^
3 winrs -r: http://machine76:80 -u:OtherDomain\JEAN-FRANCOIS -p:password ipconfig Lance la commande ipconfig sur la machine machine76. Dans notre exemple l’appel à lieu sur le port 80 car ladite machine est installé avec WinRM 1.1 (WS-Management 1.1).
Le port est ici précisé car le client winrs a été lancé à partir de la machine machine313 équipée de WinRM2.0. Sur une machine cliente WinRM 1.1, aucune précision n’aurait été nécessaire.
4 winrm set winrm/config/client @ {TrustedHosts= »machine313, foo,bar »} Ajoute les machines machine313 , foo et bar dans la liste des TrustedHosts (pas besoin d’authentification. Pratique pour de la communication inter domaine)
5 winrs -r: http://machine76:80 -u:OtherDomain\JEAN-FRANCOIS -p:password iisweb /start MONSITE Démarre le site web MONSITE sur la machine machine76 (Pour arrêter le site web, mettre /stop à la place de /start)
6 winrm enumerate winrm/config/listener Enumère les listeners sur WinRM. Cette commande permet de vérifier l’accessibilité à distance de la machine sur laquelle on l’exécute.
7 Winrm get wmicimv2/Win32_Service?Name=spooler Cette commande permet de vérifier que WinRm fonctionne en local. On demande l’état du spooler d’impression
8 winrm get winrm/config Cette commande permet de savoir la configuration de WinRM sur la machine sur laquelle il est lancé
9 winrs -r: http://machine313:5985 -u:Domain\user -p:password ipconfig Lance la commande ipconfig sur la machine machine313. Dans notre exemple l’appel à lieu sur le port 5985 car ladite machine est installé avec WinRM 2.
Le port est ici précisé car le client winrs a été lancé à partir de la machine machine76 équipé de WinRM1.1. Sur une machine cliente WinRM 2.0, aucune précision n’aurait été nécessaire.

En cas de problème
– Essayer de configurer le TrusteHosts sur les 2 machines devant communiquer

Monitorer la santé d’un site ASP.NET

Peu connu des développeurs et architectes ASP.NET, il est possible de monitorer son site web en production sans n’avoir rien à faire.
Quand je parle de monitorer, je ne parle pas ici de regarder les performances (il y a le perfMon et les compteurs de performances pour cela) mais de monitorer la santé de votre site web !

Je ne parle pas non plus de la santé du pool IIS dans lequel votre application est hébergée ; non, je parle de vérifier s’il n’y a pas des erreurs en production !
Des erreurs sérieuses, des messages qui ne devraient pas être présentés à l’utilisateur… Et s’ils apparaissent vous devriez être les premiers prévenus.

Après tout, c’est vrai, les erreurs arrivent dans l’observateur d’évènement, mais lorsque l’on a à faire à des équipes de production en intermédiaire (en gros, quand la structure à une certaine taille et qu’on ne fait pas n’importe quoi en laissant des accès à un développeur en prod), on ne peut pas voir cet observateur d’évènement.

Idéalement, on aimerait bien être prévenu par mail (si possible bien entendu, et s’il n’y a pas des firewalls quelque part qui bloquent et s’il y a un serveur mail d’accssible). Mieux, on aimerait bien tout mettre en base de données, histoire de pouvoir analyser tout cela à posteriori.

Et si je vous disais que tout cela est disponible !!! En standard !!!

Allez, je vous file une configuration pour les mails et je vous laisse farfouiller la documentation MSDN ;-)