При добавлении сервера в группу доступности возникает ошибка:
Не удается преобразовать символ юникода \uDD20 по индексу 434 в формат заданной кодовой страницы.
При добавлении сервера в группу доступности возникает ошибка:
Не удается преобразовать символ юникода \uDD20 по индексу 434 в формат заданной кодовой страницы.
Обновил ОС на сервере Exchange 2010 (Windows 2008 R2 -> Windows 2012), после этого не запускается консоль управления Exchange с ошибкой:
Не удалось подключиться к http://server.local/PowerShell с помощью проверки подлинности «Kerberos»: Сбой подключения к удаленному серверу server.local. Сообщение об ошибке: WinRM-клиент получил состояние «Ошибка сервера» (ошибка HTTP 500), но удаленная служба не предоставила других сведений о причине сбоя.
Как запустить powershell скрипт для Exchange Management Shell?
Предположим у нас есть скрипт с таким содержимым
Get-Mailbox | Set-Mailbox -MaxSendSize 10MB -MaxReceiveSize 10MB
Сохраняем его например в D:\Exchange\Scripts\script.ps1
Далее создаем bat или cmd файл, назовем его например D:\Exchange\Scripts\script.bat. Для Exchange 2010 пишем в нем следующее:
Exchange 2010. В консоли Exchange Management Shell при попытке выполнения команды Set-AdSiteLink для изменения параметра MaxMessageSize выдается сообщение об ошибке:
[PS] C:\Windows\system32>Set-AdSiteLink DEFAULTIPSITELINK -MaxMessageSize 30MB
Операция Active Directory над <DC.domain.local> не выполнена. Данная ошибка не допускает повторения попытки. Дополнительные сведения: Для выполнения операции права недостаточны.
Отклик Active Directory: 00002098: SecErr: DSID-03150A48, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
+ CategoryInfo : NotSpecified: (0:Int32) [Set-AdSiteLink], ADOperationException
+ FullyQualifiedErrorId : A663D9E2,Microsoft.Exchange.Management.SystemConfigurationTasks.SetAdSiteLink
Ошибка возникает т.к. параметр delivContentLenght не позволяет Exchange Trusted Subsystem производить изменения (Чтение и Запись). Поэтому решение такое:
Exchange 2010, Windows Server 2008 R2, вдруг перестали уходить письма на некоторые домены. В очереди повисло много писем, все с ошибкой
451 4.4.0 Error DNS Query Failed
Как видно — проблема с ДНС. Однако с сервера через nslookup все отлично работает.
Помогло прописывание внешнего ДНС-сервера в настройках Exchange:
Если нужно отредактировать локальную политику безопасности удаленного компьютера (например добавить пользователей в политику «доступ к компьютеру из сети»), то это можно сделать с помощью утилиты ntrights из Windows Resource Kit для Windows Server 2003.
Для этого надо на удаленном сервере зайти под пользователем у которого уже есть права на доступ к нужному компьютеру.
Нужный нам параметр для изменения политики «доступ к компьютеру из сети»: SeNetworkLogonRight
В Windows Server 2008 R2, как и в других версиях Windows есть встроенная программа архивации данных. Однако через графический интерфейс можно создать только одну задачу по бэкапу. Например если нужно архивировать какую-то папку 2 раза в неделю в разные места, это настроить не получится.
Однако можно обойти это ограничение, добавив задачу в планировщик вручную.
После перехода на Exchange 2010 с Exchange 2003 в логах нового сервера стала периодически фиксироваться ошибка 14029:
Не удалось найти сервер общих папок, работающий под управлением Exchange 2010 или более поздней версии, с репликой папки сведений о занятости: EX:/O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP.
Мой опыт перехода от Exchange 2003 к Exchange 2010.
Исходная среда:
Единственный в организации сервер Microsoft Exchange 2003 установлен на контроллере домена Windows Server 2003 R2. Пользователи подключаются к серверу с помощью Аутлука из локальной сети, а также удаленно через RPC over HTTP.
Также в сети есть контроллер на Windows Server 2008 R2 (поэтому обновлять схему Active Directory не пришлось).
Цель:
Осуществить наиболее гладкий переход на сервер Microsoft Exchange 2010, причем нужно сделать два сервера для обеспечения непрерывного доступа к почте.
Для этого решено было использовать виртуальные сервера на Hyper-V.
Вот тут все хорошо расписано для тех, кто знает английский.
А ниже написано по-русски, исходя из моего опыта.
Все началось с того, что неожиданно на gmail перестали доставляться письма с нашего сервера. Приходил отчет со следующим текстом:
mx.google.com выдал это сообщение об ошибке:
[<IPv6-адрес> 16] Our system has detected that this message does not meet IPv6 sending guidelines regarding PTR records and authentication. Please review https://support.google.com/mail/?p=ipv6_authentication_error for more information. yz1si800491bkb.222 — gsmtp
Сообщение не было доставлено из-за проблемы с разрешениями или безопасностью. Сообщение мог отклонить модератор, адресат может принимать сообщения электронной почты лишь от некоторых получателей, либо же доставке препятствует другое ограничение.
В заголовках отправленного сообщения было видно, что gmail зачем-то определяет внутренний IPv6 адрес почтового сервера (внешнего адреса у него нет, и даже галочка в настройках интерфейса не стоит), и ищет PTR запись для него. Естественно ее нет (провайдер про IPv6 даже не слышал), поэтому письмо возвращается.
Как вариант решения надо запретить IPv6 на сервере полностью.
Для Windows Server 2008 это делается таким образом.