Accepted domains in exchange, exchange acceepted domains, exchange authoritative domain, internal relay domain, exchange external relay, exchange external relay domain

Симптомы

При попытке запуска microsoft Exchange Management Shell (EMS) или microsoft консоль управления Exchange (EMC) на сервере, который работает Microsoft Exchange Server, вы получаете одно из следующих сообщений об ошибке:

Сообщение об ошибке 1

Подключение к удаленному серверу не удалось с помощью следующего сообщения об ошибке: клиент WinRM не может обработать запрос. Он не может определить тип контента http-ответа с конечного компьютера. Тип контента отсутствует или недействителен. Дополнительные сведения см. в разделе about_Remote_Troubleshooting Справка.
Сообщение об ошибке 2

Подключение к удаленному серверу не удалось со следующим сообщением об ошибке: клиент WinRM отправил запрос на сервер HTTP и получил ответ о том, что запрашиваемая URL-адрес http недоступна. Обычно это возвращается http-сервером, который не поддерживает протокол WS-Management. Дополнительные сведения см. в разделе about_Remote_Troubleshooting Справка.
Сообщение об ошибке 3

Подключение к удаленному серверу не удалось со следующим сообщением об ошибке: клиент WinRM получил состояние ошибки HTTP-сервера (500), но удаленная служба не включала никаких других сведений о причине сбоя. Дополнительные сведения см. в разделе about_Remote_Troubleshooting Справка. В нем была запущена команда «Discover-ExchangeServer -UseWIA $true-SuppressError $true».
Сообщение об ошибке 4

Подключение к удаленному серверу не удалось с помощью следующего сообщения об ошибке: было отказано в подключении к указанному удаленному хосту. Убедитесь, WS-Management служба работает на удаленном хосте и настроена для прослушивания запросов в правильном порту и URL-адресе HTTP. Дополнительные сведения см. в разделе about_Remote_Troubleshooting Справка.
Сообщение об ошибке 5

Подключение к удаленному серверу сбой со следующим сообщением об ошибке: клиент WinRM получил код состояния HTTP 403 из удаленной WS-Management службы.
Сообщение об ошибке 6

Подключение к удаленному серверу не удалось со следующим сообщением об ошибке: клиент WinRM отправил запрос на http-сервер и получил ответ о том, что запрашиваемая URL-адрес HTTP недоступна. Обычно это возвращается http-сервером, который не поддерживает протокол WS-Management.
Сообщение об ошибке 7

Подключение к удаленному серверу не удалось со следующим сообщением об ошибке: клиент не может подключиться к пункту назначения, указанному в запросе. Убедитесь, что служба в пункте назначения запущена и принимает запросы. Обратитесь к журналам и документации для WS-Management службы, которая работает в пункте назначения, чаще всего iiS или WinRM. Если предназначена служба WinRM, запустите следующую команду в пункте назначения для анализа и настройки службы WinRM:
Сообщение об ошибке 8

Подключение к удаленному серверу не удалось со следующим сообщением об ошибке: служба WS-Management не поддерживает запрос.
Сообщение об ошибке 9

Подключение к удаленному серверу не удалось с помощью следующего сообщения об ошибке: клиент WinRM не может обработать запрос. Клиент WinRM попытался использовать механизм проверки подлинности Kerberos, но на компьютере назначения.

Implicit Send connectors

Although no Send connectors are created during the installation of Exchange servers, a special implicit Send connector named the intra-organization Send connector is present. This implicit Send connector is automatically available, invisible, and requires no management. The intra-organization Send connector exists in the transport services to send mail, either internally between services on the local Exchange server, or to services on remote Exchange servers in the organization. For example:

Front End Transport service to the Transport service.
Transport service to the Transport service on other servers.
Transport service to subscribed Edge Transport servers.
Mailbox Transport Submission service to the Transport service.

Creating the RelayAnonymous connector…

The first step towards our proposed solution is to create the RelayAnonymous connector. Since my environment will have several sites in a near future, I decided to plan ahead and label the new receive connector with a prefix to identify its location. So, the name used here will be POA-RelayAnonymous (where POA is the Porto Alegre city where my servers are located).

These are the steps to create and configure the POA-RelayAnonymous connector, as follows:

Open Exchange Management Console
Expand Server Configuration
Click on Hub Transport
Select the desired Hub Transport
Click on New Receive Connector item located on the Toolbox Actions
On the Introduction page, name our connector and select Custom, then click Next. (Figure 07)

Figure 07

On the Local Network Settings page is where the magic happens. We are going to listen on a single IP address (the one that we associated to the second adapter — our case is 10.60.99.165) and finally to save us time during any future troubleshooting let’s use the string POA-RelayAnonymous.mva.local in the FQDN of the connector. Click Next (Figure 08).

Figure 08

On the Remote Network Settings page, leave the default settings and click Next (Figure 09).

Figure 09

On the New Connector page, a summary of all options chosen so far will be displayed, just click New to start the creation process.
On the Completion page, cmdlet and result of the operation will be displayed, and if everything was okay and the Completed status displayed via a green icon, then click Finish.

Now, that we have a new Receive Connector, double click it and in the Permissions groups tab, select Anonymous users, as shown in Figure 10.

Figure 10

Finally, click on Authentication taband uncheck all options, as shown in Figure 11.

Figure 11

We now have the first Receive Connector created. We can test it by using telnet POARelay 25 (you can be more specific and type in telnet POARelay.mva.local 25) but since the A record was created in the AD FQDN both should be fine.

In the first line of the connection, we will see the FQDN that we specified in the connector that in our case is POA-RelayAnonymous.mva.local, which helps us to identify which Receive Connector the client is connecting to. This will be useful when we have our second Receive Connector in place.

Since we are connected to our new Receive Connector, we are going to run a couple of tests. In order to make it easier for the reader who is not aware of the SMTP verbs in a regular message communication among servers we used the table below to show where we are in each command.

Phase of the communication	Commands issued
Server communication	Ehlo test.ca
From portion of the message
To portion of the message
Message body	Data <enter> Subject: Teste <enter> <enter> Message body info <enter> . <enter>
Server communication	quit

Table 1

Figure 12

Send connector permissions

Permissions are assigned to Send connectors by well-known security principals. Security principals include user accounts, computer accounts, and security groups (objects that are identifiable by a security identifier or SID that can have permissions assigned to them). By default, the same security principals with the same permissions are assigned on all Send connectors, regardless of the usage type that you selected when you created the connector. To modify the default permissions for a Send connector, you need to use the Add-ADPermission and Remove-ADPermission cmdlets in the Exchange Management Shell.

The available Send connector permissions are described in the following table.

Permission	Assigned to	Description
		Controls the preservation of Exchange forest headers in messages. Forest header names start with X-MS-Exchange-Forest-. If this permission isn’t granted, all forest headers are removed from messages.
		Controls the preservation of Exchange organization headers in messages. Organization header names start with X-MS-Exchange-Organization-. If this permission isn’t granted, all organization headers are removed from messages.
		Controls the preservation of RECEIVED headers in messages. If this permission isn’t granted, all received headers are removed from messages.
		Allows the source Exchange server to submit XEXCH50 commands on the Send connector. The X-EXCH50 binary large object (BLOB) was used by older versions of Exchange (Exchange 2003 and earlier) to store Exchange data in messages (for example, the spam confidence level or SCL). If this permission isn’t granted, and messages contain the X-EXCH50 BLOB, the Exchange server sends the message without the X-EXCH50 BLOB.
		This permission is reserved for internal Microsoft use, and is presented here for reference purposes only.

Note: Permissions names that contain are part of the header firewall feature. For more information, see Header firewall.

Send connector permission procedures

To see the permissions that are assigned to security principals on a Send connector, use the following syntax in the Exchange Management Shell:

For example, to see the permissions that are assigned to all security principals on the Send connector named To Fabrikam.com, run the following command:

To see the permissions that are assigned only to the security principal on the Send connector named To Fabrikam, run the following command:

To add permissions to a security principal on a Send connector, use the following syntax:

To remove permissions from a security principal on a Send connector, use the following syntax:

Пользователь коробочной версии Битрикс24

Просмотров: 1171 (Статистика ведётся с 06.02.2017)

Корпоративный портал — это прежде всего программное обеспечение, с которым надо уметь работать. Пошаговое добросовестное прохождение курса гарантирует овладение функционалом программы и успешное его использование. При необходимости можно отступить от пошаговости и обратиться только к нужному разделу.

Курс разработан для обучения сотрудников компаний, использующих Битрикс24. В нем описаны принципы работы с порталом и механизмы работы с конкретными функциями системы. Если вы хотите ознакомится с тем как внедрить наш сервис в работу вашей компании, то для вас создан курс Внедрение корпоративного портала.

Внимание! Все приведенные в учебном курсе скриншоты сняты с демоверсии Битрикс24. Внешний вид корпоративного портала в конкретной организации может отличаться от приведенного, так как программой допускается существенное изменение внешнего вида с целью придания индивидуальности

Однако штатный функционал не будет изменен, могут быть перенесены некоторые командные кнопки, изменены места расположения информационных зон.

Возможно при этом появление дополнительных возможностей, не предусмотренных по умолчанию в программе, но доработанных для конкретного корпоративного портала конкретной организации. В этом случае необходимо обратиться к администратору сайта за разъяснениями о работе такого функционала.

После изучения курса вам будет предложено пройти тесты на сертификацию. (Сертификация необязательна.) При успешной сдаче линейки тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.

На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий — не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщений нам об ошибках, неточностях. Для отправки воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой:

Для преподавания оффлайн

Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 3 дня (21 академический час).

Примечание: в рамках курса слова сайт и корпоративный портал являются синонимами.

Дисковые квоты на почтовые ящики

Ограничения на занимаемый объем почтового ящика могут быть заданы на уровне базы данных, в которой находится ящик, а также для на уровне самого ящика. Последний имеет приоритет.

Get-Mailbox -Identity «Кузнецов Кузнец Кузнецович» | fl IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota, UseDatabaseQuotaDefaults

* в данном примере мы увидим настройку квоты для пользователя Кузнецов Кузнец Кузнецович. IssueWarningQuota — квота, при достижении которой Exchange отправит уведомление; ProhibitSendQuota — при достижении будет запрещена отправка; ProhibitSendReceiveQuota — при достижении будет запрещена отправка и получение; UseDatabaseQuotaDefaults — используется ли квота базы данных или для пользователя используются индивидуальные настройки.

Для того, чтобы узнать установленные квоты на уровне базы вводим команду:

Get-MailboxDatabase | fl Name, *Quota

В ответ мы получим список баз данных и установленные для них квоты, например:

Name : MailDatabase1
ProhibitSendReceiveQuota : 5 GB (5,368,709,120 bytes)
ProhibitSendQuota : 4.883 GB (5,242,880,000 bytes)
RecoverableItemsQuota : 30 GB (32,212,254,720 bytes)
RecoverableItemsWarningQuota : 20 GB (21,474,836,480 bytes)
IssueWarningQuota : 4.785 GB (5,138,022,400 bytes)

* где:

Name — имя базы данных.
ProhibitSendReceiveQuota — квота, при достижении которой будет запрещена отправка и получение.
ProhibitSendQuota — квота, при достижении которой будет запрещена отправка.
RecoverableItemsQuota — квота для папки RecoverableItems (с удаленными данными, которые можно восстановить в течение определенного периода).
RecoverableItemsWarningQuota — квота для папки RecoverableItems, при достижении которой Exchange отправит уведомление.
IssueWarningQuota — квота, при достижении которой Exchange отправит уведомление.

Задать квоту можно следующими командами.

а) Для базы данных:

Set-MailboxDatabase Database12 -ProhibitSendReceiveQuota ’11 GB’ -ProhibitSendQuota ’10 GB’ -IssueWarningQuota ‘9 GB’

* в данном примере мы задаем параметры квоты для базы Database12.

б) Для пользователя:

Set-Mailbox -UseDatabaseQuotaDefaults $false -IssueWarningQuota ‘4 GB’ -ProhibitSendQuota ‘5 GB’ -ProhibitSendReceiveQuota ‘6 GB’ -Identity «Кузнецов Кузнец Кузнецович»

* в данном примере мы изменим квоту для пользователя Кузнецов Кузнец Кузнецович

Обратите внимание, чтобы учитывалась индивидуальная квота, необходимо задать значение для параметра UseDatabaseQuotaDefaults равное $false

Настройка параметров журнала протокола на сервере Exchange с помощью командной консоли Exchange

Выполните указанные ниже действия, чтобы настроить параметры журнала протокола для всех соединителей отправки или получения в службе транспорта на сервере почтовых ящиков, а также в службе транспорта на пограничном транспортном сервере.

Чтобы настроить параметры журнала протокола в командной консоли Exchange, используйте следующий синтаксис:

В этом примере показано, как задать следующие параметры журнала протокола в службе транспорта на сервере Mailbox01:

расположение журнала протокола для всех соединителей получения D:\Hub SMTP Receive Log, а для всех соединителей отправки D:\Hub SMTP Send Log. Если такой папки не существует она создается автоматически;
максимальный размер файла журнала протокола для соединителей получения и отправки 20 МБ;
максимальный размер папки журнала протокола для соединителей получения и отправки 400 МБ;
максимальный возраст файла журнала протокола для соединителей получения и отправки 45 дней.

Примечания.

Настройка параметров SendProtocolLogPath или ReceiveProtocolLogPath к значению фактически отключает ведение журнала протоколов для всех соединители отправки или получения на сервере. Однако, задайте значение для создания ошибок журнала событий, когда журнал протоколов включен для любого соединителю отправки или соединителю получения на сервере, включая соединитель отправки внутри организации или соединитель получения почтовых ящиков.
Установка параметров ReceiveProtocolLogMaxAge или SendProtocolLogMaxAge к значению предотвращает автоматическое удаление файлов журналов протоколов из-за их возраста.

Как убедиться, что все получилось?

Чтобы убедиться, что вы успешно настроили параметры ведения журнала протокола на сервере Exchange с помощью командной консоли Exchange, сделайте следующее:

Выполните следующую команду в командной консоли Exchange и проверьте параметры журнала протокола на сервере Exchange:
Откройте расположение журнала протокола в проводнике, чтобы убедиться, что файлы журнала существуют, в них записываются данные и они удаляются в соответствии с заданными максимальными размерами файлов и папок.

How Does Exchange 2013 Know Which Receive Connector to Use?

You may be wondering how the server knows which receive connector should handle the incoming SMTP connection, considering that both the “Default Frontend E15MB1” and “Relay E15MB1” connectors are listening on all IP addresses and on the same port (TCP 25).

Simply put, receive connector selection is on a “most specific match wins” basis. The connector with remote network settings that most closely match the IP of the connecting server/device will be the one that handles the connection.

The “Default Frontend” receive connector has remote network settings equivalent to “anything”.

The “Relay” connector we just created has remote network settings that list specific IP addresses.

So, if two SMTP connections are inbound, one from 192.168.0.180 and the other from 192.168.0.181, the server knows to handle 192.168.0.181 with the “Relay” connector as it is the more specific match, and handle the other connection with the “Default Frontend” connector.

With the relay connector in place the ongoing management is simple.

If an application or device needs internal SMTP relay, simply configure it to use the DNS record you configured (eg smtp.exchange2013demo.com) and port 25.
If an application or device needs external SMTP relay, simply add the IP address of the application server or device to the remote network settings of the relay connector, and then configure the application or device to use the DNS record you configured.

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

Убедитесь, что модуль Kerbauth не включен на веб-сайте по умолчанию, а включен только для виртуального каталога PowerShell. Remote PowerShell использует проверку подлинности Kerberos для подключения к пользователю. службы IIS (IIS) реализует этот метод проверки подлинности Kerberos с помощью модуля Native.

В диспетчере IIS Kerbauth должен быть указан в качестве модуля Native в виртуальном каталоге PowerShell. Расположение DLL для этого модуля должно указать на .

Примечание

Тип локальной записи для модуля Kerbauth указывает, что модуль включен непосредственно на этом уровне и не был унаследован от родительского уровня.
Убедитесь, что пользователь, который пытается подключиться, имеет состояние включенной удаленной powerShell. Чтобы определить, включен ли пользователь для remote PowerShell, необходимо запустить Exchange с помощью включенной учетной записи, а затем выполнить следующую команду:

Этот запрос возвращает ответ True или False. Если вывод отображается как False, пользователь не включен для remote PowerShell. Чтобы включить пользователя, запустите следующую команду:
Убедитесь, что модуль WSMan зарегистрирован, но не включен на уровне Сервера. Кроме того, убедитесь, что модуль WSMan включен для виртуального каталога PowerShell. Затем убедитесь, что следующая запись модуля WSMan включена в раздел файла следующим образом:

Примечание

Вы должны следовать этим шагам, даже если функция расширения WinRM IIS удалена. Это происходит из-за того, что процедура открепить автоматически не ApplicationHost.config файл.

Как убедиться, что это сработало?

Чтобы убедиться, что вы настроили поток почты и внешний клиентский доступ, выполните следующие действия:

Создайте новый профиль в приложении Outlook и/или на устройстве ActiveSync. Убедитесь, что новый профиль успешно создается в Outlook или на мобильном устройстве.
В Outlook или на мобильном устройстве отправьте новое сообщение внешнему получателю. Убедитесь, что внешний получатель получил сообщение.
В почтовом ящике внешнего получателя ответьте на сообщение, отправленное из почтового ящика Exchange. Убедитесь, что сообщение успешно доставлено в почтовый ящик Exchange.
Перейдите по адресу https://owa.contoso.com/owa, чтобы убедиться в отсутствии предупреждений о сертификате.

Типы использования соединителей получения

Тип использования определяет параметры безопасности по умолчанию для этого соединителя получения. Тип использования указывает, кому разрешено использовать соединитель, какие разрешения получают эти пользователи и какие способы проверки подлинности поддерживаются.

При создании соединителей получения в Центре администрирования Exchange мастер предлагает выбрать значение Тип для соединителя. При использовании команды New-ReceiveConnector в оболочке управления Exchange используется параметр Use с одним из доступных значений (например, ) или назначенный переключатель для типа использования (например).

Тип использования можно указать только при создании соединителей получения. Создав соединитель, вы можете изменить доступные механизмы проверки подлинности и группы разрешений в Центре администрирования Exchange или с помощью командлета Set-ReceiveConnector в командной консоли Exchange.

Доступные типы использования представлены в приведенной ниже таблице.

Тип использования	Назначенные группы разрешений	Доступные механизмы проверки подлинности	Комментарии
Клиент	Exchange пользователей ( )	Безопасность транспортного слоя ( ) Базовая проверка подлинности ( ) Предлагаем базовую проверку подлинности только после запуска TLS ( ) Интегрированная Windows проверки подлинности ( )	Используется клиентами POP3 и IMAP4, которым требуется отправлять электронные сообщения по протоколу SMTP с проверкой подлинности. При создании соединителя получения с этим типом использования в Центре администрирования Exchange или командной консоли Exchange невозможно выбрать привязки локальных IP-адресов и TCP-порт. По умолчанию этот тип использования привязан ко всем локальным IPv4- и IPv6-адресам для TCP-порта 587. Вы можете изменить эти привязки после создания соединителя. Этот тип использования недоступен на пограничных транспортных серверах.
Пользовательский	Ни один выбранный ( )	Безопасность транспортного слоя ( )	Используется в сценариях с несколькими лесами для получения почты от сторонних серверов обмена сообщениями, а также для внешней ретрансляции. Создав соединитель получения с этим типом использования, необходимо добавить группы разрешений в Центре администрирования Exchange или командной консоли Exchange.
Внутренний	Устаревшие Exchange серверы ( ) Exchange серверов ( )	Безопасность транспортного слоя ( ) Exchange Server проверки подлинности ( )	Используется в сценариях с несколькими лесами для получения почты от предыдущих версий Exchange или от сторонних серверов обмена сообщениями либо на пограничных транспортных серверах для получения исходящей почты из внутренней организации Exchange. При создании соединителя получения с этим типом использования в Центре администрирования Exchange или командной консоли Exchange невозможно выбрать привязки локальных IP-адресов и TCP-порт. По умолчанию соединитель привязан ко всем локальным IPv4- и IPv6-адресам для TCP-порта 25. Вы можете изменить эти привязки после создания соединителя. Группа разрешений недоступна на edge transport servers.
Интернет	Анонимные пользователи ( )	Безопасность транспортного слоя ( )	Используется для получения почты из Интернета. При создании соединителя получения с этим типом использования в Центре администрирования Exchange или командной консоли Exchange невозможно выбрать удаленные IP-адреса. По умолчанию соединитель принимает удаленные подключения со всех IPv4-адресов (0.0.0.0-255.255.255.255). Вы можете изменить эти привязки после создания соединителя.
Партнер	Партнеры ( )	Безопасность транспортного слоя ( )	Используется для настройки защищенного соединения с внешним партнером (взаимная проверка подлинности TLS, также называемая защитой на уровне домена).

Send connector usage types

For Send connectors, the usage type is basically a descriptive label that identifies what the Send connector is used for. All usage type values receive the same permissions.

You can specify the connector usage type only when you create Send connectors. When you use the EAC, you must select a Type value. But when you use the New-SendConnector cmdlet in the Exchange Management Shell, the usage type isn’t required (either by using or ).

Specifying a usage type does configure a default maximum message size, which you can change after you create the connector.

The available usage type values are described in the following table.

Usage type	Maximum message size	Comments
Custom	35 MB	None
Internal	unlimited	When you create a Send connector of this usage type in the EAC, you can’t select MX record associated with recipient domain. After you create the connector, you can go to the Delivery tab in the properties of the Send connector and select MX record associated with recipient domain. This same restriction doesn’t exist in the Exchange Management Shell. You can use the Internal switch and set the DNSRoutingEnabled to on the New-SendConnector cmdlet.
Internet	35 MB	None
Partner	35 MB	When you create a Send connector of this usage type in the EAC, you can’t select Route mail through smart hosts or a smart host authentication mechanism. After you create the connector, you can go to the Delivery tab in the properties of the Send connector and select Route mail through smart hosts and the smart host authentication mechanism. This same restriction doesn’t exist in the Exchange Management Shell. You can use the Partner switch and set the DNSRoutingEnabled to and use the SmartHosts and SmartHostAuthMechanism parameters on the New-SendConnector cmdlet.

Включение и отключение ведения журнала протокола для соединителя с помощью командной консоли Exchange

Выполните указанные ниже действия, чтобы включить или отключить ведение журнала протокола для:

соединителя отправки или получения в службе транспорта на серверах почтовых ящиков;
соединителя получения во внешней службе транспорта на серверах почтовых ящиков;
соединителя отправки или получения в службе транспорта на пограничных транспортных серверах.

Чтобы включить или отключить ведение журнала протокола для соединителя отправки или получения, используйте следующий синтаксис в командной консоли Exchange:

В этом примере показано, как включить ведение журнала протокола для соединителя получения Connection from Contoso.com на сервере Mailbox01.

В этом примере показано, как отключить ведение журнала протокола для соединителя отправки Connection to Internet.

Выполните указанные ниже действия, чтобы включить или отключить ведение журнала протокола для неявного и невидимого соединителя отправки внутри организации, который имеется в службе транспорта, внешней службе транспорта и службе отправки транспорта почтовых ящиков на серверах почтовых ящиков. Дополнительные сведения об этих соединителях см. в разделе .

Ведение журнала протокола для соединителя отправки внутри организации происходит в журналах протокола соединителя отправки для указанной службы транспорта

Обратите внимание, что параметр службы транспорта управляет ведением журнала протокола для соединителя отправки внутри организации в службе транспорта, а также в службе отправки транспорта почтовых ящиков

Чтобы включить или отключить ведение журнала протокола для соединителя отправки внутри организации, используйте следующий синтаксис в командной консоли Exchange:

В этом примере показано, как включить ведение журнала протокола для соединителя отправки внутри организации в службе транспорта и службе отправки транспорта почтовых ящиков на сервере Mailbox01.

В этом примере показано, как отключить ведение журнала протокола для соединителя отправки внутри организации во внешней службе транспорта на том же сервере.

Выполните указанные ниже действия, чтобы включить или отключить ведение журнала протокола для неявного и невидимого соединителя получения доставки в почтовые ящики, находящегося в службе доставки транспорта почтовых ящиков. Ведение журнала протокола для этого соединителя происходит в журналах протокола для соединителей получения в службе доставки транспорта почтовых ящиков. Дополнительные сведения об этом соединителе см. в разделе .

Чтобы включить или отключить ведение журнала протокола для соединителя отправки доставки в почтовые ящики, используйте следующий синтаксис в командной консоли Exchange:

В этом примере показано, как включить ведение журнала протокола для соединителя получения доставки в почтовые ящики на сервере Mailbox01.

В этом примере показано, как отключить ведение журнала протокола для соединителя получения доставки в почтовые ящики на том же сервере.

Как убедиться, что все получилось?

Чтобы убедиться, что вы успешно включили или отключили ведение журнала протокола для соединителя с помощью командной консоли Exchange, сделайте следующее:

Выполните следующую команду в командной консоли Exchange, чтобы проверить, удалось ли вам включить или отключить ведение журнала протокола для всех соединителей на сервере Exchange:
Перейдите к расположению журнала протокола. Если вы включили ведение журнала протокола, убедитесь, что файл журнала существует и обновляется для соединителя. Если же вы отключали ведение журнала протокола, убедитесь, что последний файл журнала больше не обновляется для соединителя.

Устранение неполадок

Что делать, если результаты не отображаются?

Убедитесь, что имена командлета и его параметров введены верно.
Указанные параметры фактически доступны для комлета в одной роли. Перед запуском второй команды попробуйте указать только имя командлета в первой команде. Затем добавьте параметры по одному в первую команду перед запуском второй команды.

В противном случае результаты, скорее всего, не будут вызваны одним из следующих условий:

В роли, которая по умолчанию не назначена группам ролей, определяются cmdlet или параметры.
В вашей среде не доступны cmdlet или параметры. Например, вы указали Exchange Online или Exchange Online параметры в локальной Exchange среде.

Чтобы найти роли в среде (если таковые имеются), содержащие командлет или параметры, замените и необязательно, со значениями, которые необходимо использовать и выполнить следующую команду:

Примечание. Можно использовать символы под диктовки (*) в именах и параметрах (например, ).

Если команда возвращает ошибку с сообщением о том, что объект найти не удалось, значит в вашей среде недоступны командлет или параметры.

Если команда возвращает результаты, командлет или параметры доступны в вашей среде, но необходимая роль не назначена группам ролей. Чтобы найти роли, которые не назначены группам ролей, запустите следующую команду:

Установка ограничений на доставку сообщений в Центре администрирования Exchange

В центре администрирования Exchange перейдите к Получатели > Почтовые ящики.
В списке почтовых ящиков пользователей щелкните почтовый ящик, для чего необходимо настроить ограничения на доставку сообщений, а затем нажмите кнопку Изменить .
На странице свойств почтового ящика нажмите кнопку Функции почтового ящика.
В разделе Ограничения доставки сообщений щелкните Подробности, чтобы просмотреть и изменить следующие ограничения доставки:
- Прием сообщений из: Используйте этот раздел, чтобы указать, кто может отправлять сообщения этому пользователю.
- Все отправители. Этот параметр указывает, что пользователь может принимать сообщения от всех отправителей. Сюда относятся отправители из вашей организации Exchange и внешние отправители. Это значение используется по умолчанию. Этот параметр включает внешних пользователей, только если снят флажок Требовать проверку подлинности всех отправителей. Если этот флажок установлен, сообщения от внешних пользователей будут отклоняться.
- Только отправители в следующем списке. Этот параметр указывает, что пользователь может принимать сообщения только из указанного набора отправителей в Exchange организации. Нажмите кнопку Добавить отображение списка всех получателей в Exchange организации. Выберите нужных получателей, добавьте их в список и нажмите ОК. Вы также можете найти определенного получателя, введя имя получателя в поле поиска, а затем нажав значок Поиска .
- Требуйте, чтобы все отправители были аутентификацией. Этот параметр не позволяет анонимным пользователям отправлять сообщения пользователю. Это включает внешних пользователей, которые находятся за пределами вашей организации Exchange.
- Отклонение сообщений из : Используйте этот раздел, чтобы заблокировать отправку сообщений этому пользователю.
- Нет отправителей. Этот параметр указывает, что почтовый ящик не будет отклонить сообщения от всех отправителей в Exchange организации. Этот параметр установлен по умолчанию.
- Отправители в следующем списке. Этот параметр указывает, что почтовый ящик будет отклонить сообщения из указанного набора отправителей в Exchange организации. Нажмите кнопку Добавить отображение списка всех получателей в Exchange организации. Выберите нужных получателей, добавьте их в список и нажмите ОК. Вы также можете найти определенного получателя, введя имя получателя в поле поиска, а затем нажав значок Поиска .
Щелкните ОК, чтобы закрыть страницу Ограничения доставки сообщений, а затем нажмите Сохранить для сохранения изменений.

Что нужно знать перед началом работы

Предполагаемое время выполнения задачи: 50 минут.
Для процедур в этом разделе требуются особые разрешения. См. информацию о разрешениях по каждой процедуре.
Вы можете получать предупреждения сертификата при подключении к веб-сайту центра администрирования Exchange центра администрирования (EAC) до настройки сертификата безопасного уровня розеток (SSL) на сервере клиентского доступа. Как это сделать, будет показано далее в этом разделе.
Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.

Важно!

Для каждой организации требуется как минимум один сервер клиентского доступа и один сервер почтовых ящиков в лесу Active Directory. Кроме того, каждый из узлов Active Directory, который содержит сервер почтовых ящиков, должен также содержать как минимум один сервер клиентского доступа. При разделении серверных ролей рекомендуем сначала установить роль сервера почтовых ящиков.