Exchange Server 2013 – чистим мусор. Дополнение.


Exchange Server 2013 – чистим мусор. Дополнение.

Недавно в статье Exchange Server 2013 – чистим мусор я опубликовал скрипт для удаления журналов IIS, которые копятся на серверах Exchange по пожирают место на диске. Этот скрипт универсальный: он сам находит расположения журналов IIS, даже если вы их переместили.

Сейчас обнаружил, что есть еще один журнал HTTPERR, который создает не сам IIS, а сервис HTTP.SYS. Этот журнал расположен по умолчанию по пути %systemroot%\System32\LogFiles. Его также можно переместить в другое место с помощью ключей реестра, как описано в документации Configuring HTTP.sys Error Logging. Поэтому делаем дополнение в скрипт.

Соответственно скрипт теперь выглядит так:

Скрипт перенесён И ещё раз про чистку мусора в папках Exchange Server 2013

Реклама

Exchange Server 2013 – чистим мусор


_______________

Update:

Exchange Server 2013 – чистим мусор. Дополнение.

___________________

В Exchange Server 2013 есть одна особенность, которой не было в предыдущих версиях: журналы Exchange Server включены всегда. Почему так сделано? Чтобы быстрее находить и устранять неисправности. Если журнал выключен и произошёл сбой, то у вас нет или очень мало информации о причинах сбоя – нужно включить журналы и воспроизвести проблему, а это потеря времени, да и как воспроизвести проблему, если о ней ничего толком неизвестно? – замкнутый круг. Поэтому журналы всегда включены, и это порождает новое требование: необходимо дополнительно около 30Gb на диске для размещения журналов Exchange Server 2013. Это описано в документации. Более подробно ситуация описана в статье Exchange 2013 Logging and Space Requirements.

Но как всегда находятся подводные камни.

Читать далее

Особенности настройки SSO для Tomcat на IIS 8.5


Когда Microsoft подвергают критике за сложность и нелогичность настройки ее продуктов, то можно иной раз с этим согласиться, но когда приходится работать с продуктами других производителей, то, как говориться, все познается в сравнении: уровень обычно настолько ниже, что ясно понимаешь, почему продукты Microsoft так популярны даже несмотря на наличие массы «бесплатных» альтернатив.

Вот на днях пришлось настраивать SSO (Single-Sign-On) для Aparche Tomcat, чтобы заработала прозрачная аутентификация для Windows пользователей. Для этого был поднят сервер Windows Server 2012 R2 и IIS 8.5, потом установлен Tomcat 8 и ключевой элемент — Jakarta Isapi Redirector, который собственно и реализует SSO.

Все это нужно было для работы с HP Service Manager 9. Когда я выполнил тестовое подключение, то все достаточно быстро открылось и работало замечательно. Когда тоже самое сделал коллега, то получил сообщение об ошибке: «The page was not displayed because the request entity is too large».

Сообщение четко описывает, в чем проблема. Первым делом я нашел настройки ограничений на IIS:

clip_image001

Как видите по умолчанию IIS разрешает передачу контента аж в 30 Мб! Значит проблема где-то в Tomcat, но где? Количество мест и неочевидных параметров, как показывал предыдущий опыт, в Tomcat просто не имеет границ.

Тем не менее поиск в Интернет вывел на страничку с решением: проблема в том, что Jakarta Isapi Redirector имеет буфер по умолчанию 8 Кб! Сколько у Tomcat ограничение по умолчанию, я не знаю, поэтому выставляем одно и то же значение для обоих компонентов.

Увеличиваем буфер коннектора в 2 раза с 8 Кб до 16 Кб:

1. В файле server.xml

a. Найти

<Connector port=»8009″ protocol=»AJP/1.3″ redirectPort=»8443″ tomcatAuthentication=»false» URIEncoding=»UTF-8″/>

b. Добавить параметр packetSize=»16384″ (по умолчанию 8 Кб)

<Connector port=»8009″ protocol=»AJP/1.3″ redirectPort=»8443″ tomcatAuthentication=»false» URIEncoding=»UTF-8″ packetSize=»16384″/>

2. В файле worker.properties (используется isapi_redirect.dll ) вставить строку:

worker.local.max_packet_size=16384

(Вместо Local у вас может быть что-то другое)

PS: Нашел описание параметра packetSize http://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html

Не меняйте настройки IIS на сервере с установленным Exchange


Изначально Exchange Server ставится на чистую систему и не имеет полного набора прописывания конфигурации. Поэтому когда администратор на сервере что-то «накрутил», убил Exchange, снес его и снова восстановил, то полностью конфигурация не восстанавливается, и Exchange может не заработать. Особенно Exchange чувствителен к изменению настроек IIS.

Поэтому самое простое решение – переустановить сервер полностью, а потом восстановить на него Exchange.

Если же хочется более сложного пути, то можно попытаться восстановить настройки IIS вручную, например, сравнив их с работающей системой аналогичной конфигурации.

Вот пример восстановления работы Exchange Management Shell (версия 2013) (На форумах Technet иной раз попадается кое-что полезное…! ):

1.Выберите сервер=> sites=> Default Web site=> Authentication и отключите все аутентикации, тоесть поставьте их на disabled

2.Выберите сервер=> sites=> Default Web site=>Modules и проверьте задан ли у Вас WSMan модуль. Если нет, то задайте модуль с помощью КВ 2028305

3.Выберите сервер=> sites=> Default Web site=> правой кнопкой выберите Basic Settings и убедитесь, что путь задан C:\Program Files\Microsoft\Exchange Server\v15\ClientAccess\Powershell

4.Выберите сервер=> sites=> Default Web site=> SSL settings и убедитесь, что галочка не стоит на Require SSL Check

5.Сделайте IIS reset и проверьте работу конзоли

А лучше всего никогда не трогайте настройки IIS на сервере с установленным Exchange: не надо пытаться его оптимизировать или нагрузить дополнительным приложением – в эру виртуализации всегда можно поднять отдельную виртуальную машину.