Publier une application sous Windows Server 2008 (deuxième partie)

Avant toute chose, je vous invite à lire la première partie de cet article.

Il existe trois moyens d’accéder à une application publiée via Windows Server 2008 :

• Accès via un portail web
• Accès via un fichier .rdp déposé sur le bureau du client
• Accès via un package .msi installé sur l’ordinateur client

Accéder à une application publiée via un portail web

Afin de pouvoir joindre le portail web qui hébergera votre application, vous devrez autoriser vos utilisateurs en les ajoutant dans le groupe Ordinateurs Accès Web TS. Vu qu’il s’agit d’une démonstration, on garde seulement l’utilisateur Administrateur. Dans un cadre de production, vous utiliserez probablement un groupe de sécurité Active Directory.

Dans la première partie de cet article, je vous parlais du service Accès Bureau à distance par le Web. Comme son nom l’indique, c’est un service de rôle essentiel pour accéder au portail de vos applications publiées. Nous allons donc l’installer.

Depuis le Gestionnaire de serveur, cliquez droit sur les Services Bureau à distance et sélectionnez Ajouter des services de rôle.

Ensuite, cochez la case Accès Bureau à distance par le Web. Une fenêtre apparaît et vous indique alors qu’il faut notamment installer le Serveur Web (IIS), un classique chez Microsoft.

Au besoin, vous pourrez personnaliser l’installation du serveur web. Par défaut, les réglages proposés conviendront.

Passez enfin à l’installation du service de rôle, du serveur web ainsi que des Outils d’administration de serveur distant.

Une fois l’installation effectuée, vous découvrirez la présence du serveur IIS.

Après redémarrage, l’assistant de validation des Services Bureau à distance reflètera la nouvelle configuration. Toutefois, il est probable que vous rencontriez un message indiquant qu’une connexion Bureau à distance pour ce serveur n’est pas visible dans l’accès Bureau à distance par le Web.

Modifiez alors les paramètres de l’application et cochez la case Afficher une connexion Bureau à distance sur ce serveur hôte de session Bureau à distance dans l’accès Bureau à distance par le Web. Vous pourrez également en profiter pour changer le nom du serveur et éventuellement le port RDP afin de sécuriser votre installation.

Une fois les réglages effectués, rendez-vous à l’adresse https://<votre serveur>/rdweb sur laquelle vous devriez trouver la mire de connexion aux services Bureau à distance. Identifiez-vous.

Si la connexion est validée, vous trouverez enfin votre application publiée.

Lors du premier lancement, vous aurez probablement une alerte de sécurité Windows. Ne vous en inquiétez pas et validez.

L’application peut démarrer.

Si vous n’avez pas produit de certificat valide pour l’application, un message apparaîtra. Même opération, passez outre pour le moment. Il sera bien assez temps de régler ce point avant un passage en production.

Dès que la connexion est établie, un message s’affiche dans la barre de notifications. Vous pouvez commencer à utiliser l’application.

Si vous ouvrez le Gestionnaire des tâches de Windows, vous pourrez dès lors valider que l’application lancée s’exécute bien via un serveur distant.

Accéder à une application publiée via fichier .rdp ou package .msi

Parmi les options de publications que nous avons à disposition, existe donc la possibilité de créer un fichier .rdp ou un package .msi.  Vous pourrez commencer les opérations à partir de la page d’accueil des Services Bureau à distance.

Les réglages de publication par fichier .rdp sont très simples. Choisissez un emplacement de destination où enregistrer les packages, un serveur et un port associé, comme nous l’avons déjà étudié. Vous pourrez également charger un certificat valide à ce stade.

En navigant dans le répertoire de dépôt des packages, vous retrouverez vos applications publiées avec l’extension qui correspond à vos préférences.

La publication par package .msi varie sensiblement de celle par fichier .rdp. En effet, la seule différence notable concerne la configuration du package de distribution pour laquelle vous aurez la possibilité de créer des raccourcis sur le Bureau de l’utilisateur ainsi que dans le dossier menu Démarrer (par défaut Applications distantes).

Sur le Bureau utilisateur, les deux applications déployées à la main ou par exemple par GPO prendront pour le package .rdp la forme d’une connexion à distance classique alors que le package .msi installé ressemblera plus à une application publiée Citrix, bref, probablement plus défendable pour une utilisation d’entreprise.

Publier une application sous Windows Server 2008 (première partie)

Pour ceux qui sont familiers des publications d’applications sous Citrix, Windows Server 2008 propose une solution alternative avec les Services Bureau à distance (anciennement Terminal Server) qui semblent arriver enfin à maturité pour sortir du cadre habituel d’administration connu des techniciens. L’objectif est simple, vous désirez publiez une application à vos utilisateurs et vous voulez surtout que l’intégration se fasse de la façon la plus transparente qui soit, sans tous les tracas des couches superposées qui vous polluent la vie au quotidien (qui a parlé des problèmes de mappages d’imprimantes ?)

Installation des Services Bureau à distance

A la manière d’une promotion en contrôleur de domaine ou en serveur de fichiers, installez les Services Bureau à distance en cochant la croix prévue à cet effet. Pensez simplement à toujours installer les applications à publier après avoir installé le rôle.

Pour l’instant, nous ne cocherons que le service de rôle Hôte de session Bureau à distance. En production, vous pourrez au besoin installer le Gestionnaire de licences Bureau à distance ou l’Accès Bureau à distance par le Web (nous l’ajouterons  d’ailleurs plus tard dans cet article).

Windows Server 2008 amène une amélioration de la sécurité et propose désormais une authentification plus forte. A vous de juger ce qui vous ira le mieux en production. Pour l’exemple une nouvelle fois, nous choisirons l’option Ne nécessite pas l’authentification au niveau du réseau à des fins de rétro-compatibilité.

Idem pour les licences, nous choisissons Configurer ultérieurement alors que votre installation, pour être pérenne, devra nécessairement passer à terme par un mode de licence Par périphérique ou Par utilisateur (lisez d’ailleurs cet article pour obtenir des détails sur le sujet).

Enfin, vous pourrez d’ores et déjà ajouter les utilisateurs ou les groupes autorisés à administrer ce serveur Hôte de session Bureau à distance.

L’assistant vous proposera d’améliorer l’expérience utilisateur au moyen de fonctionnalités d’affichage avancées (thème Aero notamment). Dans la plupart des cas vous n’en tiendrez pas compte pour préférer les performances au confort visuel.

Une fois l’installation terminée, vous devrez redémarrer le serveur. Au prochain boot, vous verrez un message qui vous récapitulera les opérations effectuées.

Préparer la publication d’application

Nous arrivons enfin à la publication d’application. Rendez-vous pour cela dans le Gestionnaire de serveur et dans les Rôles, dépliez Service de Bureau à distance, repérez Gestionnaire RemoteApp (Nom de votre serveur) puis faites un clic droit > Ajouter des programmes RemoteApp.

L’Assistant RemoteApp s’ouvre et vous permet de sélectionner le ou les programme(s) déjà intallés possibles à publier par simple case à cocher.

Si vous cliquez sur le bouton Propriétés… vous aurez également la possibilité de personnaliser le nom du programme, de passer des arguments ou encore de changer l’alias de l’application.

Dans la fenêtre Programmes RemoteApp, vous retrouverez ainsi toutes vos applications candidates à la publication.

Dans le prochain article en ligne le 23/04, vous découvrirez trois manières de publier une application à vos utilisateurs.

Régler les problèmes de réplication de licence Terminal Server sous Windows Server 2003

Un message d’avertissement bénin que vous pouvez rencontrer sur un serveur Windows Server 2000 ou 2003 concerne la réplication des informations de licence Terminal Server vers votre serveur de licence faisant autorité sur le domaine. Bénin, certes, mais embêtant car il se reproduira toutes les 15 mn jusqu’à ce que vous l’ayez réglé. Non seulement cela remplit inutilement le journal des événements mais on peut légitimement se demander si (et quand) un problème plus grave pourra résulter de cette première alerte. On peut par exemple penser à une impossibilité d’accès au serveur en TSE puisque les licences n’auront plus été répliquées par le serveur maître. Quoi qu’il en soit, avant qu’une conséquence fâcheuse soit susceptible de vous handicaper, pensez à dépanner cette erreur.

Le problème est connu et vous pourrez obtenir toutes les informations supplémentaires dessus en lisant le KB Microsoft 198132 (bien que l’article soit écrit pour Windows Server 2000, il est également valable pour 2003).

En substance, l’ID 213 est à surveiller et le descriptif vous mettra sur la piste de résolution.

ID événement : 213
Source: LicenseService
Description: La réplication des informations de licence a échoué car le service
d'enregistrement de licence sur le serveur \<serveur> n'a pas pu être contacté.

Voici un exemple concret de l’erreur :

Faites les vérifications d’usage suivantes :

• Votre serveur est rattaché au domaine
• Vous pouvez joindre le serveur de licence (ping, tracert…)
• Le service Appel de procédure distance (RPC) est bien démarré
• Le service Service d’enregistrement de licences est bien démarré

Si toutes ces vérifications sont validées, il n’y a à priori aucune raison valable à la présence de cette erreur. Pourtant, elle continue à apparaître. Plutôt que de chercher une cause abstraite, tentez de redémarrer le service Service d’enregistrement de licences.

Jusqu’à présent, cela m’a toujours résolu le problème. On peut supposer que le service est devenu instable comme cela peut arriver sous Windows. Pourtant, le service ne semble pas planté et accepte volontiers de redémarrer contrairement au comportement connu (aucune action possible sur le service).

Si quelqu’un a une explication affinée, elle est la bienvenue !

Pour connaître toutes les erreurs Terminal Server possibles inscrites dans le journal des événements, consultez la page Microsoft Technet dédiée.