domino-exchange

 (KSMG-2.0) Ограничение списка LDAP-серверов через подмену DNS-записей Общая информация При настройке подключения к LDAP-серверу вы указываете кейтаб-файл, который содержит в себе имя пользователя (Principal name) и секретный ключ для аутентификации. Перед тем, как выполнить подключение, вычисляется имя домена Active Directory на основе доменной части имени пользователя в кейтабе. Например, для пользователя username@EXAMPLE.COM именем домена является example.com. Далее, выполняется запрос к DNS-серверу для получения SRV-записей для Kerberos и LDAP, соответствующих данному домену. На основе ответа DNS- сервера формируется список серверов (контроллеров домена) для подключения. Используемые SRV-записи приведены в таблице ниже (домен example.com приведен для примера): SRV-запись Описание _kerberos._udp.example.com _kerberos._tcp.example.com Список серверов, отвечающих за выписку ключей по протоколу Kerberos для данного домена _ldap._tcp.example.com Список серверов LDAP, обслуживающих данны

  Get-MailboxDatabase -Status | Select-Object Name, DatabaseSize, AvalaibleNewMaiboxSpace | Format-Table -AutoSize

  Всем привет Обнаружил что папка C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem занимает 20 Гб захотелось почистить ее ) плюсьі/минусьі/подводньіе камни ? Никаких, я оставляю последние две версии, остальные удаляю

  Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery 'Subject:"тема для удаления"' -EstimateResultOnly -DeleteContent У меня другая проблема, русский язык на серверах отсутствует и формат даты американский. Если скопировать русские символы туда, они вопросиками становятся. Вот думаю, если я добавлю русский язык и формат даты поменяю, не сломается ли чего? Пока как то обходился без поиска русских слов. Вы можете добавить русскую раскладку и заменить локаль для non-Unicode. И вопросики исчезнут

 смотреть на ошибки в /var/log/kaspersky/ksmg/extra/webapi.log

 https://support.kaspersky.ru/ksmg/2.0.1/troubleshooting/15904

  https://exchangepedia.com/2008/01/exchange-server-2007-renewing-the-self-signed-certificate.html/comment-page-1 In Exchange 2007 and later, Exchange Setup creates a self-signed certificate to protect communication with Exchange services such as  SMTP ,  IMAP ,  POP ,  OWA ,  EAS ,  EWS  and  UM . Exchange’s self-signed certificates meet an important need – securing communication paths for all Exchange services by default. The self-signed certificate meets an important need – securing communication paths for all Exchange services by default. This is a great development – it ensures that out of the box, Exchange does not transfer any data in the clear and all communication is encrypted. Nevertheless, one should treat these certificates as temporary. Although self-signed certificates work perfectly well for internal  SMTP  communication between Hub Transport servers, and between Hub Transport and Edge Transport servers, it’s not recommended to use them for any client communication on an

 https://practical365.com/exchange-2013-the-internal-transport-certificate-cannot-be-removed/ When you attempt to remove an  SSL certificate from an Exchange 2013 server  you may encounter the following error. A special Rpc error occurs on server E15MB2: The internal transport certificate cannot be removed because that would cause the Microsoft Exchange Transport service to stop. To replace the internal transport certificate, create a new certificate. The new certificate will automatically become the internal transport certificate. You can then remove the existing certificate. To be able to remove the SSL certificate you need to  create a new certificate  to replace the existing one as the internal transport certificate. You can perform this task quickly in the Exchange Management Shell. The following command when run on the server in question will generate a self-signed certificate that contains the server’s FQDN and NetBIOS names on it. [PS] C:\>New-ExchangeCertificate -IncludeSer

https://practical365.com/configuring-the-tls-certificate-name-for-exchange-server-receive-connectors/   Consider a scenario in which you’re trying to do the right thing by ensuring that authenticated SMTP client connections to your Exchange server are protected by TLS encryption. Most commonly this will be when you have IMAP or POP clients configured with the Exchange server (or a DNS alias that points to the Exchange server) as the SMTP server for sending email. If the client tries to authenticate over an unencrypted connection, a message is received with words to the effect of: The outgoing server (SMTP) mail.exchangeserverpro.net does not support the selected authentication method. After Googling around you learn that your SMTP client should use STARTTLS in order to authenticate securely. Here’s an example of how that is configured in Mozilla Thunderbird’s outgoing server settings. Notice also the use of port 587. Exchange servers are pre-configured by setup with a receive connector