Zoredache имел верное представление. Проблема с тем, как NAT работает. Не делая ничего специального, и с помощью шлюза NAT, который не умен, это - то, что происходит с пакетами.
У Вас есть две опции здесь. Первое как Zoredache, на который указывают, и создайте расщепленный горизонт DNS (внутренние пользователи видят один набор записей DNS, внешние пользователи видят другого). Тем путем то же имя может указать на два различных IP-адреса на основе того, где Вы.
Второй способ зафиксировать это состоит в том, чтобы использовать шлюз NAT, который достаточно умен для распознавания этой конкретной маршрутизации. Вместо того, чтобы вслепую передать 192.168.1.30's неизменный пакет, это перепишет его так, источник является самим шлюзом. Это называют исходным NAT (и может быть назван многими другими вещами в зависимости от того, кто продает поле). Это инвертирует NAT, таким образом, это - источник, который переписывается, не место назначения.
Первый путь является самым дешевым для установки, так как можно выполнить собственные серверы DNS внутренне, и остальное - просто изменения конфигурации различных типов. Второе будет стоить денег, но должно Просто Работать, если Вы получите их на месте.
Однажды у меня была такая же проблема. Я думаю, решение было следующее:
$s=new-pssession -computername xxxxx
import-pssession -session $s
затем добавьте свою оснастку и запустите свои команды
Я бы предложил использовать удаленную конечную точку, которая является частью обычной установки Exchange. Вы можете найти более подробную информацию здесь
Я успешно использовал его как с EX 2010, так и с EX 2013. Это поддерживаемый способ и он следует правилам RBAC, поэтому я бы предложил использовать его вместо добавления привязки Exchange к «нормальной» конечной точке удаленного взаимодействия.
Проблема в том, что обе машины должны находиться в одном домене.
Также убедитесь, что вы используете учетную запись домена, а не локальную.
Вы пытаетесь подключиться к конечной точке удаленного взаимодействия по умолчанию на сервере Exchange и добавить оттуда оснастки ps. Это не верно. Замените свои первые 3 строки на следующие:
$mailcred = Get-Credential
$mailSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://MAILSRV/PowerShell/ -Credential $mailcred
Import-PsSession $mailSession
Вам не нужно входить в сеанс, вместо этого импортируйте его в локальный сеанс. С этого момента вы можете использовать специфичные для Exchange CmdLets локально. Кроме того, некоторые типы Exchange .Net устанавливаются вместе с консолью управления Exchange, поэтому ее необходимо установить на локальном компьютере, если вы хотите работать с размерами почтовых ящиков (Exchange использует свои собственные типы для объектов размера)
Вы можете сделать это так, используя import-pssesion и указав идентификатор подключения и имя конфигурации.
PS U:\> $cred = Get-Credential
PS U:\> $session = New-PSSession -ConnectionUri http://Exchange01/powershell -ConfigurationName Microsoft.Exchange -Credential $cred
PS U:\> Import-PSSession $session
PS U:\> Get-Mailbox marius.davidsen
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Marius Davidsen Marius.Davidsen Exchange01 unlimited
Для этого необходимо разрешить порт 80 TCP в вашем брандмауэре.
Используя этот сеанс, вы также можете ввести его, как вы хотели:
PS U:\> Enter-PSSession $session
[Exchange01]: PS> get-mailbox
[Exchange01]: PS> get-mailbox marius.davidsen
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Marius Davidsen Marius.Davidsen Exchange01 unlimited