Applet de commande PowerShell distant échoue dans un environnement Exchange Server 2013

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3067263
Symptômes
Supposons qu'un administrateur ouvre une session sur un serveur dans un environnement Microsoft Exchange Server 2013 et essaie ensuite torun une applet de commande Windows PowerShell qui nécessite un proxy vers un serveur de boîtes aux lettres différentes de back-end. (Par exemple, l'administrateur tente d'exécuterset-userphoto.) Dans ce cas, l'opération échoue, et l'administrateur reçoit une erreur semblable à la suivante :
Erreur de commande du proxy ' Set-Mailbox - Type: « Shared » - identité :<ID>
-Confirmer: $False-Force: $True' au serveur </ID>Exchange_Server: Version du serveur <version number="">, procédé de Proxy RPS :
Le client WinRM ne peut pas traiter la demande. La chaîne de connexion doit être de la forme
[</version>transport://]hôte[:port][/suffixe] où transport a pour valeur « http » ou « https ». Transport, port et suffixe sont facultatifs. L'hôte peut être un nom d'hôte ou une adresse IP. Pour les adresses IPv6, placez l'adresse entre crochets - par exemple, « http://[1::2]:80/wsman ». Modifiez la chaîne de connexion et renouvelez la demande.
Cause
Ce problème se produit parce que le jeton d'accès de l'administrateur Exchange actuel est tellement grand qu'il dépasse la limite de longueur de chaîne de connexion dans le composant Windows Remote Management (WinRM). La limitation de longueur de chaîne de connexion est codée en dur à 2 048 octets.
Contournement
Pour contourner ce problème, appliquez une ou plusieurs des méthodes suivantes.

Méthode 1: Installation d'Exchange Server 2013 Cumulative Update 2 ou une version ultérieure mise à jour cumulative

Avec Exchange Server 2013 Cumulative 2, une fonctionnalité a été ajoutée pour compresser le jeton d'accès. Toutefois, si le jeton est toujours supérieur à la limite de WinRM, même une fois que le fichier est compressé, l'erreur continue à se produire. Dans ce cas, useeithermethod 2or méthode 3 pour contourner le problème.

Méthode 2: Réduire le nombre de groupes dont est membre l'administrateur Exchange

Méthode 3: créer un nouveau compte d'administrateur Exchange

Créer un nouveau compte pour une utilisation d'administration de Exchange et assurez-vous que ce compte est membre du nombre minimal de groupes requis.
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3067263 - Dernière mise à jour : 07/13/2015 21:05:00 - Révision : 3.0

Microsoft Exchange Server 2013 Enterprise, Microsoft Exchange Server 2013 Standard

  • kbsurveynew kbprb kbexpertiseadvanced kbtshoot kbmt KB3067263 KbMtfr
Commentaires