Dépannage des erreurs de licence de Terminal Server 1003 et 1004

Résumé

Cet article contient des informations sur le dépannage des erreurs de licence de Terminal Server 1003 et 1004. Les utilisateurs qui tentent de se connecter à un serveur XenApp peuvent rencontrer les erreurs liées aux Services de terminal suivantes dans le journal des événements :

ID d’événement : 1003
Source : TermService
Type : Information
Le client de service de terminal a fourni une licence non valide.

ID D’événement: 1004
Source: TermService
Description : Impossible d’acquérir une licence pour le nom d’utilisateur, le nom de domaine.

Pour plus d’informations, consultez les articles Microsoft TechNet – Guide Étape par étape sur les licences TS et Dépannage des licences Terminal Server.

Contexte

Avec les licences Microsoft (CAL (regular Client Access License) et CAL Terminal Services), avant qu’une connexion ICA ne soit établie (la fenêtre contextuelle d’ouverture de session GINA), la licence client doit être confirmée pour exister et être valide.

Remarque : Les stations de travail professionnelles Windows XP ne disposent pas de CALs intégrées par rapport aux serveurs de licences Terminal Server Windows 2003.

Lorsqu’il n’y a pas suffisamment d’autorisations pour la clé de registre suivante, des échecs de connexion se produisent. Examinez le gestionnaire de licences Microsoft Terminal Services pour voir si le poste de travail est énuméré. Si le poste de travail n’est pas énuméré, ce problème se situe au niveau du système d’exploitation Windows. Pour plus d’informations, contactez le support technique Microsoft et vérifiez que vos licences de terminal Windows 2003 sont activées.

Symptôme-1

Lors de la connexion avec un client Citrix ICA après avoir téléchargé un client Web RDP (Remote Desktop Protocol), le client RDP peut ne présenter aucun problème et continuer à se connecter.

Cause-1

Le journal des événements ne spécifie pas le périphérique client qui a fourni la licence non valide. Des autorisations insuffisantes sont appliquées à la clé de licence Microsoft dans le registre du groupe d’utilisateurs authentifiés. Lors du test, essayez de créer une connexion RDP après avoir supprimé la clé MSLicense dans le registre en tant qu’utilisateur (pas d’administrateur de domaine ou de groupe d’utilisateurs expérimentés); la connexion RDP échoue également.

Solution-1

Il peut être utile d’étudier les clés de registre de cryptographie dans HKEY_LOCAL_MACHINE et HKEY_CURRENT_USER sur le serveur et le poste de travail. Voir Microsoft TechNet et l’utilisation de RegMon et FileMon pour plus d’informations. De plus, voir Sysinternals Windows. Ces modifications seront reflétées à partir de l’appareil client.

Si vous établissez une connexion de bureau, l’ouverture de la connexion ICA à l’intérieur de la session de bureau (passage) et la connexion ICA suivante échoueront. Le poste de travail concerné dans ce cas est le serveur.

Suivez la procédure suivante si vous rencontrez des erreurs de licence mentionnées précédemment :
Attention ! Reportez-vous à la clause de non-responsabilité à la fin de cet article avant d’utiliser l’éditeur de registre.

  1. Ouvrez l’éditeur de registre via regedit32.commande exe.

  2. Accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing.

  3. Mettez en surbrillance cette clé, sélectionnez Sécurité dans la barre d’outils et sélectionnez Autorisations.

  4. Cliquez sur la touche Avancée.

  5. Vérifiez que le groupe d’utilisateurs authentifiés se trouve dans les entrées d’autorisations.

    Remarque: Si ce groupe n’est pas trouvé, cliquez sur Ajouter, sélectionnez le groupe d’utilisateurs et cliquez sur OK.

    – Dans l’entrée d’autorisation pour MSLicensing, fournissez un contrôle total au groupe d’utilisateurs et cliquez sur OK.
    – Dans les paramètres de contrôle d’accès pour MSLicensing, cliquez sur Appliquer et sur OK.
    – Dans l’entrée d’autorisation pour MSLicensing, cliquez sur Appliquer et OK.

  6. Essayez de vous connecter à l’aide du client ICA 32 bits pour Windows.

Note: Si vous utilisez un client Windows non natif (Macintosh, Linux ou un terminal mince) sans registre local, les modifications d’autorisation doivent être apportées à la clé de registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\MSLicensing

Symptom-2

Après avoir déplacé le serveur de licences Terminal Services, les clients RDP ne présentent aucun problème et continuent à se connecter.

Cause-2

Une condition de concurrence potentielle entre l’Icaapi.dll et le Rdpwsx.la dll peut entraîner la désynchronisation de la clé de certificat privée sur le serveur Terminal Services.

Solution-2

Pour Windows 2003 Terminal Server, suivez l’article Microsoft TechNet Comment remplacer le processus de découverte du serveur de licences dans Windows Server 2003 Terminal Services pour ajouter le serveur de licences Terminal Server. Pour le serveur Windows 2008, suivez le guide Étape par étape de l’article Microsoft TechNet – Licence TS.

  1. Cliquez sur Démarrer > Exécuter, tapez regedit et cliquez sur OK.

  2. Localisez et cliquez sur la clé suivante dans le registre:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Paramètres

  3. Dans le menu Édition, accédez à Nouveau et cliquez sur Touche.

  4. Nommez les nouveaux serveurs de licences clés.

  5. Localisez et cliquez sur la touche suivante dans le registry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers

  6. Dans le menu Édition, accédez à Nouveau et cliquez sur Touche.

  7. Nommez la nouvelle clé ServerName où ServerName est le nom NetBIOS du serveur de licences que vous souhaitez utiliser, puis appuyez sur Entrée.

  8. Redémarrez l’ordinateur.

    Remarques : Le nouveau nom de clé peut être l’une des désignations suivantes qui représentent le serveur de licences:

    • Le nom NetBIOS du serveur.

    • Le nom de domaine complet (FQDN) du serveur.

    • L’adresse IP du serveur.

      Si vous utilisez Windows Server 2003 SP1 et versions ultérieures ou Windows Server 2008, vous pouvez le définir dans l’outil d’administration de configuration de Terminal Services. La capture d’écran suivante montre l’interface dans Windows Server 2003:

      Image ajoutée par l'utilisateur

  9. Dans Paramètres du serveur, double-cliquez sur le mode de découverte du serveur de licences et saisissez le nom NetBIOS du serveur ou l’adresse IP.

  10. Redémarrez le serveur pour appliquer les modifications.

    Remarque: Dans Windows Server 2008, ouvrez Modifier les paramètres, double-cliquez sur mode de découverte du serveur de licences, sélectionnez l’onglet Licences, sélectionnez l’option Utiliser les serveurs de licences spécifiés et entrez le nom du serveur de licences (ou l’adresse IP) dans le champ fourni. La capture d’écran suivante montre l’interface dans Windows Server 2008:

    Image ajoutée par l'utilisateur

    Utilisez l’article Microsoft TechNet – Les clients Windows XP ne peuvent pas se connecter à un serveur Windows 2000 Terminal Services pour réparer les clés de certificat sur le serveur Terminal.

Symptôme-3

Lors de la connexion d’un client ICA à l’aide d’un Wyse WT1200LE version 4.2.terminal x, il existe un problème connu avec le micrologiciel livré avec le périphérique client léger.

Un poste de travail individuel peut se connecter au serveur A mais pas au serveur B.

Certains postes de travail clients peuvent se connecter à tous les serveurs tandis que d’autres sont refusés à certains serveurs.

Dans les deux cas, la connexion client RDP du même poste de travail peut se connecter aux serveurs A et B.

Résolution-3

Mise à niveau vers la dernière version du micrologiciel 4.4.079 pour le modèle Winterm 1200LE abandonné.

Dépannage pour les Clients Non Windows

Remarque : Si vous utilisez un client Windows non natif (Macintosh, Linux ou un terminal mince) sans registre local, les autorisations précédentes (décrites dans le numéro 1) doivent être vérifiées sur la clé de registre suivante sur le serveur XenApp/Serveur de présentation :
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\MSLicensing

  1. Vérifiez le nombre de serveurs TSCAL installés et leur emplacement d’installation. Si vos serveurs de terminaux sont membres d’un domaine Active Directory, vous devez installer le serveur de licences TS sur un contrôleur de domaine dans le domaine racine de la forêt. Il ne peut y avoir qu’un seul serveur de licences Enterprise TS par site Active Directory. Installez un serveur de licences Enterprise TS pour chaque site de la forêt Active Directory.Pour que l’objet Active Directory soit créé correctement, installez TS Licensing en tant qu’administrateur d’entreprise ou administrateur appartenant au domaine racine. Si un domaine racine vide est créé, l’objet Active Directory pour le serveur de licences TS-Enterprise peut ne pas être créé correctement.L’objet ressemble-t-il aux sites et services Active Directory et peut-il être interrogé à l’aide d’une requête LDAP ? Si vous suivez ce processus, tous les serveurs Windows 2000 exécutant Terminal Services découvriront leur serveur de licences Enterprise TS à l’échelle du site par recherche LDAP.L’utilisation ou non d’Active Directory est très importante en ce qui concerne le processus de découverte du serveur de licences TS. Pour plus d’informations sur le processus de découverte du serveur de licences TS, consultez Découverte du service de licence Terminal Services.

  2. Vérifiez combien de serveurs de terminaux génèrent les erreurs et vérifiez également si les serveurs de terminaux se trouvent sur le même sous-réseau/domaine que le serveur TSCAL. Lorsque les serveurs étaient sur le même sous-réseau, en changeant la configuration TCP/IP sur les serveurs en nœud h pour WINS, en ajoutant un serveur WINS au mixage et en utilisant la clé de registre DefaultLicenseServer, tous les serveurs de l’Active Directory ont pu trouver le serveur de licences TS. Pour plus d’informations, voir Symptôme-2. Par conséquent, vérifiez si vous spécifiez le nom NetBIOS du serveur de licences TS en modifiant la valeur de registre suivante help:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\DefaultLicenseServer
    Note : Le nom NetBIOS doit être résoluble.

  3. Vérifiez si cela fait une différence que l’utilisateur du poste de travail est un administrateur ou possède un compte de classe utilisateur.Il est également important de savoir quand le serveur agit en tant que client en mode pass-through.

  4. Vérifiez la version du client ICA.

  5. Mise à jour vers le dernier Service Pack Microsoft.

  6. Vérifiez si, dans le panneau de configuration, MSLicensing est défini sur par serveur ou par siège.

  7. Reportez-vous aux articles Microsoft TechNet – Guide Étape par étape de dépannage des licences Terminal Server et des licences TS.

Remarque : L’option de purge peut être utilisée pour nettoyer les licences des licences d’accès client stockées attribuées aux clients exécutant des systèmes d’exploitation non Windows. Pour plus d’informations, consultez CTX137608 – Assistant de maintenance DSCheck.

Étapes d’isolement

  1. Isolez le serveur à problème dans un groupe de travail et/ou promouvez-le auprès d’un contrôleur de domaine.

  2. Activez ce serveur en tant que serveur TSCAL.

  3. Créez au moins deux sessions ICA sur ce serveur.

  4. Désactivez le serveur TSCAL à partir de ce serveur.

  5. Le cas échéant, rétrogradez le serveur.

  6. Rejoignez le domaine d’origine.

  7. Essayez de créer une session ICA.

Remarques: Ces étapes sont connues pour corriger le problème précédent. Les mesures d’action précédentes, si elles sont terminées avec succès, se terminent:

  • Aucune modification n’a été apportée au serveur XenApp/serveur de présentation.

  • Les modifications se sont produites au niveau du système d’exploitation.

Write a Comment

Votre adresse e-mail ne sera pas publiée.