“L'accès Est Refusé” erreur lors de la tentative de télécommande pour Exchange server sur localhost

Je suis en train d'essayer d'établir une session PowerShell pour exécuter plusieurs commandes Exchange sur un serveur Exchange sur le localhost. Je reçois l'erreur suivante:

New-PSSession : [<HOSTNAME>] Connecting to remote server <HOSTNAME> failed with the following error message
: Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:12
+ $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'h ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed

Mon code est un copier coller à partir de la Microsoft Article Technet. Il fonctionne sur la machine distante, mais à chaque fois que je cible la machine que je suis en cours d'exécution à partir d', j'obtiens l'erreur ci-dessus.

Ce que j'ai essayé jusqu'à présent:

Vérifié le about_remote_troubleshooting rubrique d'aide. Rien là-dedans relatives à l'Accès des erreurs de refus travaillé.
Ciblées machines distantes en utilisant les mêmes informations d'identification que reçu le erreur d'Accès Refusé. (Connecté sans problème)
Vérifié que ma session PowerShell est en cours d'exécution en tant qu'Administrateur. (Il est)
Vérifié que l'Exchange Management Shell est en mesure de lancer avec succès. (Il est)
Essayé sans les informations d'identification pour voir si cela fonctionnerait. (Il n'a pas)
Vérifié net use et net session pour m'assurer que je n'ai pas eu une drôle de multiples connexions avec les mêmes informations d'identification question. (Je n'ai rien vu pour indiquer qu')
Essayé cette fois à partir du script qui est à l'origine de problèmes et en tapant les commandes dans une console powershell à la main. (obtenu les mêmes résultats dans les deux sens. Yay pour la consistance)
Essayé sur plusieurs systèmes. (Même résultat partout)

Des notes rapides:

C'est Exchange 2013 en cours d'exécution sur Windows Server 2012. C'est une installation de base, juste un environnement de test qui a très peu de données et de la configuration minimale, au-delà de l'installation et l'activation de l'accès distant.
Les informations d'Identification ont été utilisés pour l'administrateur de domaine, qui a également l'obligation d'Échanger des autorisations de faire ce que je dois faire. I. e, aussi longtemps que je cible une machine qui n'est pas celui que je suis en cours d'exécution à partir, je n'ai pas de problème que ce soit, avec rien d'autre changement à la façon dont je me connecte. En outre, ce est un domaine de test où l'administrateur de domaine de l'accès n'a pas été restreint ou modifié de quelque manière, de sorte qu'il devrait avoir totalement accès à tout.

Les commandes spécifiques, je suis saisie sont:

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'http://<HOSTNAME>/Powershell' -Credential $cred

Est de se connecter à localhost comme ce quelque chose que je devrais être capable de le faire? Ou est-il tout simplement pas pris en charge?

Je suis à une perte complète à ce point. Toute aide, même pour me pointer dans la bonne direction, serait grandement apprécié.

EDIT: je tiens à ajouter, j'ai tenté la connexion à ce localhost à partir d'une autre machine, en utilisant les mêmes commandes que celles ci-dessus, et cela a fonctionné sans problème. Donc, je n'ai pas pense c'est un problème de configuration.

Vous avez vérifié que votre administrateur de domaine peut accéder au serveur? la raison pour laquelle je demande, c'est que je crois qu'ils ont besoin d'une autorisation spéciale à distance à l'échange, et je pense que vous ne pouvez le faire que dans l'échange.
Oui. Je suis connecté au serveur avec mon domaine d'identification d'administrateur. En outre, à partir d'un autre ordinateur, je suis en mesure d'accéder à distance à cet ordinateur à l'aide de celles de domaine creds. Aka, Un ordinateur exchange est installé. Je suis connecté à Un ordinateur (localhost dans l'exemple ci-dessus) avec le domaine creds, ne peut powershell à distance à l'échange de A. Cependant, à partir de l'Ordinateur B (sur le même domaine), je suis en mesure à distance dans Exchange sur Un ordinateur avec ces mêmes creds. En outre, si je tente de distance de l'ordinateur A à C de l'ordinateur (qui a aussi change installé) avec mon admin creds il fonctionne
ok donc il ne fonctionne pas à partir d'Un...est le pare-feu? bien que la façon dont vous l'avez expliqué ce qui pourrait ne pas être le problème...
Exécuter Set-Item -force WSMan:\localhost\Client\TrustedHosts –Value * sur Un ordinateur
simple à deviner, ne vous définir le mot de passe sur ur d'un compte de connexion?

OriginalL'auteur Jgraum | 2015-05-27

1

Donc, je suis tombé sur la solution en fin de semaine dernière. Il semble avoir quelque chose à voir avec l'authentification utilisée. J'avais quitté le "- " Authentification paramètre vide, avec l'intention de laisser le Nouveau-PSSession commande trier la méthode qui serait la meilleure.

Apparemment, par défaut, c'est le "Négocier" méthode d'authentification, qui permet de sélectionner Kerberos contre une machine distante, mais sélectionnez l'authentification NTLM dans le cas contraire (ou au moins, c'était mon observée/supposé comportement). Voir cette description Microsoft des méthodes d'authentification.

La spécification d'une méthode d'Authentification (à la Fois "Kerberos" et "de Base" travaille, "Négocier" n'a pas, je n'ai pas bricoler trop passé ce) efface la question et m'a permis de connecter les locaux de l'instance.

Donc, plutôt que de ceci:
```
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'http://<HOSTNAME>/Powershell' -Credential $cred
```
Ce faire:
```
$session = New-PSSession -Authentication Kerberos -ConfigurationName Microsoft.Exchange -ConnectionUri 'http://<HOSTNAME>/Powershell'  -Credential $cred
```
Pourquoi ce travail? Je n'ai aucune idée. Je vais laisser ça à des gens qui en savent plus que moi de l'expliquer.

OriginalL'auteur Jgraum
0

Si vous essayez juste de créer une session sur le même ordinateur que votre session actuelle omettre l'URI.
```
$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -Credential $cred
```
Cela va créer une nouvelle session sur l'hôte local que vous pouvez vous connecter et utiliser au besoin.

Essayé ce, m'en rapprocher. La session a été créée, mais pour quelque raison il n'avait pas les commandes, j'ai besoin de courir. Je ne suis pas entièrement sûr de savoir pourquoi, comme je l'ai pensée le nom de la configuration était ce qui rendait ces commandes disponibles. Je pense que je peut juste besoin de détecter que je suis cibler mon localhost en quelque sorte, et il suffit de charger le composant logiciel enfichable (microsoft.blah.blah.blah.Powershell.E2010), et d'accéder aux commandes de cette façon.
Je pense que vous pouvez peut-être sur cette pensée, et il manque le point de cet article que vous avez lié. Que toute la chose est de l'accès des cmdlets Exchange si vous n'avez pas l'Exchange PowerShell Outils installés sur votre ordinateur local, ce que vous faites. Pour une utilisation en local, vous devriez avoir un raccourci vers la Console de Gestion Exchange ou quelque chose de similaire qui permettra de créer une session powershell avec les cmdlets Exchange est déjà chargé et disponible.
Je ne peut pas avoir expliqué mon usage prévu correctement. Je suis en train d'écrire un script pour exécuter automatiquement une collection de commandes sur un serveur exchange. Il va être exécuté à partir d'une application externe, et je ne veux pas d'une console à apparaître. Alors... autant que je peux dire que j'ai besoin de créer un pssession contre la machine locale. Cependant, j'ai trouvé une solution en fin de semaine dernière, je vais poster ici comme une réponse sous peu.

OriginalL'auteur TheMadTechnician

Vous devez vous connecter pour publier un commentaire.