Архив

Archive for the ‘Exchange 2013’ Category

Публикация ресурсного календаря Exchange 2013

ICal_IconМаленькая заметка как опубликовать календарь ресурсного ящика в формате iCalendar или HTML. Чтобы публиковать в таком виде календари пользователей необходимо предварительно настроить данную возможность, например здесь отлично описан этот процесс: http://www.stevieg.org/2010/06/calendar-sharing-improvements-coming-in-exchange-2010-sp1/

Но что если нам нужно опубликовать календарь ресурсного ящика в интернет? для этого нам необходимо сделать следующее:

1. Set-Mailbox -Identity ResourceMailbox -SharingPolicy SharingPolicyForInternet (назначим созданную ранее политику либо предварительно создадим новую например так New-SharingPolicy -Name SharingPolicyForInternet -Domains ‘Anonymous: CalendarSharingFreeBusySimple’ -Enabled $true)

2. Set-MailboxCalendarFolder -Identity ResourceMailbox:\Calendar -PublishEnabled $true

3. Get-MailboxCalendarFolder -Identity ResourceMailbox:\Calendar

из последней команды найдем ссылку для подключения календаря (ical или html) — теперь можно выслать данные ссылки для подключения ical либо просмотра через браузер.

P.S. Если у вас папка календаря на русском то замените в командах Calendar на Календарь (получится так ResourceMailbox:\календарь ).

Рубрики:Exchange 2010, Exchange 2013

Синхронизация адресной книги CommuniGate Pro и Exchange 2013

 

ex2013

Решение задачки по синхронизации адресной книги CGP и Exchange(в одну сторону CGP to Exchange). Скрипт публикую как есть, описывать подробно лень, а кому очень нужно разберется :).

Описание ситуации: Сосуществование CGP и Exchange 2013, при этом необходимо в адресной книге Exchange иметь контакты пользователей, находящихся на CGP.

Решение задачи: Скрипт + Scheduler

 

#Выгрузка объектов(пользователей) с помощью ldap запроса из CGP

Param($user = “CGPuser”,
      $password = “CGPuserpassword”,
      $filter = “(objectclass=*)”,
      $server = “server.cgp.local:489”,
      $path = “cn=cgp.local,o=mxs”,
      [switch]$all,
      [switch]$verbose)
   

if($verbose){$verbosepreference = “Continue”}

$DN = “LDAP://$server/$path”
Write-Verbose “DN = $DN”
$auth = [System.DirectoryServices.AuthenticationTypes]::FastBind
Write-Verbose “Auth = FastBind”
$de = New-Object System.DirectoryServices.DirectoryEntry($DN,$user,$Password,$auth)
Write-Verbose $de
Write-Verbose “Filter: $filter”
$ds = New-Object system.DirectoryServices.DirectorySearcher($de,$filter)
$ds.SearchScope = “Subtree”
Write-Verbose $ds
$users = $ds.FindAll()
$Encode =  new-object system.text.UTF8encoding
Set-Content -Path C:\UAB\UsersContacts.csv -Value “displayname, alias, WindowsEmailAddress” -Encoding unicode
$i = 0
foreach ($user in $users)
{
    $i++; Write-Host $i
    $Row = “{0}, {1}, {2}” -f $Encode.GetString($user.properties[“cn”][0]), $Encode.GetString($user.properties[“uid”][0]), $Encode.GetString($user.properties[“mail”][0])
    Add-Content -Path C:\UAB\usersContacts.csv -Value $Row -Encoding unicode
}
#Создание контактов из объектов присутствующих в LDAP запросе (производится добавление только отсутствующих контактов, реализованное через сравнение Compare-Object). При этом используется отдельная OU.

$ContactOU = “OU=Update Address Book,OU=All Users,DC=cgp,DC=local“
$ContactsCGP = import-Csv ‘C:\UAB\UsersContacts.csv’ -Encoding Unicode
$ContactsExch = get-mailcontact -OrganizationalUnit $ContactOU -resultsize unlimited | select-object displayname,alias,windowsemailaddress
Compare-Object $ContactsCGP $ContactsExch -Property displayname, alias, windowsemailaddress | Where-Object {$_.SideIndicator -eq “<=“} | Export-Csv -Encoding Unicode C:\UAB\AddContacts.csv
$Users = import-Csv ‘C:\UAB\AddContacts.csv’ -Encoding Unicode
$users | ForEach-Object {Remove-MailContact -identity $_.Alias -Confirm:$y}
$users | ForEach {New-MailContact -Name $_.alias -displayname $_.displayname -alias $_.alias -ExternalEmailAddress $_.WindowsEmailAddress -OrganizationalUnit $ContactOU}

 

#Удаление контактов объектов отсутствующих в LDAP запросе(т.е пользователи уже отсутствуют в CGP)

$ContactsExch = Get-MailContact -OrganizationalUnit $ContactOU -ResultSize Unlimited |select -exp alias
$ContactsCGP = import-Csv ‘C:\UAB\UsersContacts.csv’ -Encoding Unicode|select -exp alias
$Diff  = $ContactsExch | ? {$ContactsCGP -notcontains $_}
$Diff | ForEach-Object {remove-mailcontact -identity $_ -Confirm:$Y}

#P.S. Можно и не пользоваться выгрузкой в файлы, сделано для наглядности процесса синхронизации. Также можно через set-contact добавить дополнительные сведения в контакты.

Рубрики:Exchange 2013

Публикация CRL (certificate revocation list)

PKIProcessДанная статья описывает пример публикации CRL (certificate revocation list), в целях доступности их внешним клиентам, например мобильным клиентам lync, в случае когда для публикации вебслужб Lync используются сертификаты внутреннего CA. Данная статья предназначена для тех кому надо решить данную задачу, но не хочет лезть в дебри PKI 🙂

 

Что мы имеем:

  • Внутренний CA развернут и работает корректно
  • Запись во внешнем DNS(для публикации crl по этому имени), например ca.company.ru
  • Возможность обеспечить доступ к серверу CA (или другой публикующий web server) из Интернета по порту 80/TCP (HTTP). Например можно использовать IIS ARR который мы развернули в прошлых статьях для публикации вебслужб Lync. Просто добавим новую ферму (Server Farm) участником которой будет сервер CA и добавим новое правило(URL Rewrite) для запросов типа ca.* (для нашего примера).

Итак, приступим:

  1. На веб сервере (у нас CA) создадим папку, например c:\CRLDistribution . Дать на нее серверу CA NTFS права на модификацию. Расшарить директорию и дать серверу CA или группе Everyone права на модификацию. crl1crl2
  2. Откройте Internet Information Services (IIS) Manager (на сервере CA). Далее правой кнопкой по Default Web Site и выберете Add Virtual Directory. Заполните поле ALIAS например – CRLD, и выберете директорию из пункта 1. crl3
  3. Выберете созданную виртуальную директорию. Справа выберете и зайдите в Directory Browsing, и включите его (Enable справа в поле action)
  4. Выберете созданную виртуальную директорию. Справа выберете и зайдите в Configuration Editor, выберете в поле section значение system.webServer/security/requestFiltering. Ниже в поле allowDoubleEscaping выберете для него true. crl4         Это необходимо для доступа к файлам, содержащим в имени знак ‘+’. Такой знак генерируется в имени файла, содержащего Delta CRL. Без этого при попытке доступа к файлу Delta CRL сервер будет в любом случае возвращать Error 404 (даже при наличии файла). В нашем случае необходимо также выставить данный флаг и на IIS ARR: Default Web Site\Request Filtering\Edit Feature Settings\Allow double escaping
  5. Перейти на СА и открыть оснастку управления СА (Administrative Tools > Certificate Authority). Войти в свойства CA и перейти на вкладку Extensions. Нажать кнопку Add. В поле Location ввести следующее:
  6. file://\\CA01\CRLDistribution\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
    Необходимо для автоматической публикации crl в нужной папке. Где \\CA01\CRLDistribution — UNC-путь к директории, а CA01 — имя, по которому веб-сервер доступен внутри сети(в нашем случае это корпоративный CA).
    Нажать ОК, выделить в списке эту строку и установить:
    Publish CRLs to this location
    Publish Delta CRLs to this location
  7. Добавить еще одну строку(по этому пути внешние клиенты будут искать наши crl). При этом CA.company.ru – fqdn имя по которому сервер доступен из сети интернет. CRLD – это ALIAS виртуальной директории.
    http://CA.company.ru/CRLD/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
    Нажать ОК, выделить в списке эту строку и установить:
    Include in CRLs. Clients use this to find Delta CRL locations.
    Include in the CDP extension of issued certificates
  8. crl5
  9. Сохранить изменения. Согласиться с перезапуском службы СА
  10. В оснастке управления СА щелкнуть правой кнопкой на Revoked Certificates и выбрать All tasks -> Publish. В директории на веб-сервере появились два файла — CLR и Delta CLR. Если по этому действию возникают ошибки то они зачастую связаны с отсутствием прав на директорию размещения файлов crl. Еще раз перепроверьте правильно ли вы дали доступ к папке. Возможно помогут статьи с technet http://social.technet.microsoft.com/wiki/contents/articles/3081.ad-cs-error-the-directory-name-is-invalid-0x8007010b-win32http-267.aspx и http://technet.microsoft.com/en-us/library/cc726342(v=WS.10).aspx
  11. Теперь нужно перевыпустить сертификаты для наших публикуемых сервисов. Например для Lync: необходимо перевыпустить сертификаты для ReverseProxy и Edge. Открыть свойства новых сертификатов и на вкладке Details проверить содержимое поля CLR Distribution Points. Там должен фигурировать соответствующий URL, ссылающийся на публичный FQDN веб-сервера.
  12. Проверить доступность CRL из интернет. Например пройдя в нашем случае по ссылке http://ca.company.ru/crld/ вы должны увидеть все файлы в этой директории, попробуйте скачать их. Если скачивается значит все работает как надо. crl6
  13. Примечание: Для использования сертификатов, выданных внутренним CA, с сервисами, доступными из интернет (различные веб службы, например веб службы Lync), необходимо, чтобы публичные сертификаты корневого центра сертификации и всех подчиненных CA были помещены в хранилище Доверенные корневые центры сертификации / Trusted root certification authorities и клиентам были доступны CRL(списки отзыва сертификатов), публикуемые этими центрами сертификации. На мобильных клиентах Lync также необходимо устанавливать корневой сертификат.
  14. Пример из практики для чего нужна данная публикация CRL.

Исходные данные: В организации развернут Lync, используются сертификаты внутреннего CA. Администратор решил организовать доступ мобильных клиентов Lync из сети интернет. Опубликовал веб службы в интернет с помощью IIS ARR, использовал для публикации сертификаты выпущенные внутренним CA. Установил Lync client 2013 на свой смартфон с ОС WP8, установил корневой сертификат своего CA и успешно подключился, после этого свернул приложение. На следующее утро администратор вызвал из фона приложение Lync но приложение не могло подключиться, помогал только выход из клиента путем разлогирования, при этом появлялось сообщение что связь с сервером разорвана. Данная проблема повторялась каждый раз после длительного периода нахождения в фоне(около 4-6 часов).

Причины: поиск мобильным клиентом списков отзыва сертификатов (CRL)

Решение проблемы: публикация CRL, заново опубликовать веб службы Lync с новыми сертификатами (где есть новая точка распространения CRL)

Profit!

Пересоздание виртуальных каталогов OWA и ECP Exchange 2013

ex2013Данная статья рассказывает, как пересоздать виртуальные каталоги в Exchange 2013 на примере OWA и ECP. Также будет немножко теории для того чтобы напомнить о чем идет речь.

 

Напомню, что виртуальные каталоги необходимы для осуществления доступа через них к веб-приложениям, например к Outlook Web App (OWA), Exchange Active Sync, Autodiscover. Управлять ими можно в трех местах: EAC, EMS, IIS Manager. Согласно новой архитектуре Exchange 2013 все клиентские подключения проксируются на виртуальные каталоги сервера с ролью Mailbox. При этом виртуальные каталоги располагаются в различных сайтах в зависимости от роли:

На сервере с ролью CAS: в сайте DefaultWebSite (80, 443 порты)

На сервере с ролью Mailbox: в сайте ExchangeBackEnd(81, 444 порты)

Если роли совмещены, то выглядит через IIS Manager это так:

1virtcat

Если роли не совмещены то так:

6278_CAS_IIS_png-550x00028_MB_IIS_png-550x0

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

В связи с новой архитектурой Exchange 2013(проксирование на Mailbox) в случае необходимости пересоздания виртуальных каталогов нам необходимо пересоздать каталоги на сервере с ролью Mailbox в сайте Exchange Back End (в примере мы пересоздадим каталоги и на CAS и на Mailbox)

Приступим непосредственно к пересозданию каталогов OWA и ECP через EMS :

  •  OWA

Удалим каталоги:

Remove-OwaVirtualDirectory “ServerName\owa (Default Web Site)”

Remove-OwaVirtualDirectory “ServerName\owa (Exchange back end)”

Создадим каталоги:

New-OwaVirtualDirectory  -InternalUrl “https://ServerName/owa” -ExternalUrl “https://mail.domain.com/owa”

New-OwaVirtualDirectory  -InternalUrl “https://ServerName/owa” -ExternalUrl “https://mail.domain.com/owa” -WebSiteName “Exchange Back End”

 

  •  ECP

Удалим каталоги:

Remove-EcpVirtualDirectory -Identity “ServerName\ecp (Default Web Site)”

Remove-EcpVirtualDirectory -Identity “ServerName\ecp (Exchange Back End)”

 

Создадим каталоги:

New-EcpVirtualDirectory -Server ServerName -ExternalURL “https://mail.domain.com/ecp” -InternalURL “https://mail.domain.com/ecp”

New-EcpVirtualDirectory -Server ServerName -ExternalURL “https://mail.domain.com/ecp” -InternalURL “https://mail.domain.com/ecp” -WebSiteName “Exchange Back End”

 

Надеюсь кому то помогло 🙂

Рубрики:Exchange 2013

Удаление папок из ящика пользователя используя API EWS Exchange 2013

ex2013Бывают ситуации когда в результате каких то действий(скрипты, миграции, и т.п) у пользователя в почтовом ящике Exchange 2010\2013 возникают ненужные ему папки. И все бы ничего если он один такой — можно вручную взять и удалить их, а если проблема не единичная а массовая? Сразу возникает вопрос как ее решить глобально и у всех сразу. Я предлагаю решить эту задачу используя API EWS Exchange.

Рассмотрим решение задачи на реальном примере:

Исходные данные:

— Exchange Server 2013 развернут и настроен. Веб службы работают корректно.

— Во время миграции почтовых ящиков с Lotus Domino на Exchange 2013 с помощью утилиты Notes Migrator for Exchange в ящике возникают ненужные в дальнейшей работе пользователя папки: ~TRASH, FolderHiddenPublic, MAPIUseContacts, Stationery.

Задача:

Удалить у всех пользователей эти папки незаметно и не отвлекая их от работы.

Решение:

1. Для удаления папок используя API EWS Exchange необходимо дать полные права на ящики пользователей учетной записи из под которой будет выполнятся удаление, сделать это можно например так:

Get-Mailbox | Add-MailboxPermission -user "AccountForDeleteFolders" -AccessRights FullAccess -InheritanceType All –AutoMapping $false

 

2. Удаление ненужных папок во всех ящиках почтового домена(в тесте uclab.ru). Для выполнения скрипта необходима библиотека Microsoft.Exchange.WebServices.dll находящаяся в папке c установленным Exchange, в данном примере мы скопировали ее в удобное место(и указали потом соответственно к ней путь). Также в теле скрипта замените почтовый домен на свой(в примере это тестовый почтовый домен uclab.ru). При этом имена ящиков в организации имеют вид SamAccountName@domain.ru

$mailboxes=get-mailbox
ForEach ($Mailbox in $mailboxes)
{
$dllpath = "c:\exchange\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_sp1)
$MailboxName = $mailbox.SamAccountName + "@uclab.ru"
$Service.AutodiscoverUrl($MailboxName,{$true})
$RootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)
$RootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service,$RootFolderID)
$FolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
$FolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
$Response = $RootFolder.FindFolders($FolderView)
ForEach ($Folder in $Response.Folders)
{
if($folder.DisplayName -eq "(Custom Expiration\Manage Folders)") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
if($folder.DisplayName -eq "~TRASH") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
if($folder.DisplayName -eq "FolderHiddenPublic") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
if($folder.DisplayName -eq "MAPIUseContacts") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
if($folder.DisplayName -eq "threadsEmbed") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
if($folder.DisplayName -eq "Stationery") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
}
}

 

3. Вернем права в исходное состояние у всех ящиков(т.е. удалим полный доступ у сервисной учетной записи)

$mailboxes=get-mailbox
ForEach ($Mailbox in $mailboxes)
{
$Name = $mailbox.Name
Remove-MailboxPermission -AccessRights FullAccess -Identity "$name" -User AccountForDeleteFolders@uclab.ru
}

 

4. Если вам понадобится удалить папки в конкретном ящике — это можно сделать так:

Удаление папок testdelete1 и testdelete2 из ящика rmamyshev@uclab.ru используя API EWS Exchange 2013

$dllpath = "c:\exchange\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_sp1)
$MailboxName = ‘rmamyshev@uclab.ru’
$Service.AutodiscoverUrl($MailboxName,{$true})
$RootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)
$RootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service,$RootFolderID)
$FolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
$FolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
$Response = $RootFolder.FindFolders($FolderView)
ForEach ($Folder in $Response.Folders)
{
if($folder.DisplayName -eq "testdelete1") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
if($folder.DisplayName -eq "testdelete2") {$folder.delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete)}
}

 

5. P.S Конечно это возможно не самый элегантный вариант но он работает, правда не удалось достичь полной стабильности при выполнении скрипта, периодически удаление происходит частично(остаются некоторые папки), это лечится повторным запуском  🙂 Если есть у кого способ полегче — буду рад увидеть его в комментариях.

 

Рубрики:Exchange 2013

IIS ARR в качестве Reverse Proxy для Exchange Server 2013

ex2013Данная статья описывает возможность публикации сервисов Exchange 2013: Outlook Web App (OWA), ActiveSync (EAS), Outlook Anywhere с помощью Reverse Proxy на базе IIS. Так как в стандартном наборе IIS данной возможности нет – то для реализации необходимо будет установить дополнительный компонент Application Request Routing (ARR).

Итак, что мы имеем:

1schema

  • Exchange Server 2013 развернут и работает корректно
  • В сети периметра (DMZ) развернут сервер с установленной ОС Windows Server 2012R2. Используется два сетевых интерфейса (DMZexternal(ext ip) и DMZinternal(int ip)). Сервер должен будет принимать запросы из интернета и маршрутизировать их в локальную сеть. Для разрешения имен используется DNS в DMZ, в случае его отсутствия можно использовать файл HOSTS.

Приступим к развертыванию Reverse Proxy-сервера на базе IIS (ОС WindowsServer 2012R2):

1. Установим IIS. Выберете для установки две роли: Applications Server и Web Server (IIS)

2

2. Установите ваши сертификаты: SAN сертификат(или wildcard) и CA root certificate. В данном случае используется свой внутренний CA и wildcard сертификат (если используете SAN сертификат будьте внимательны относительно имен, отсутствие необходимого имени может привести к унылой страничке «что то пошло не так», например при попытке доступа к ящику через owa)

3. Добавьте HTTPS привязку для Default Web Site (используйте ваш сертификат).

3bind

4. Установите ARR

В идеальном случае ARR нужно установить через механизм WebPlatformInstaller (WebPI) http://www.microsoft.com/web/downloads/platform.aspx

В моем частном случае (windows server 2012R2) я решил сделать вручную. Скачал и установил следующие пакеты:

-WebDeployversion 2.0 (без него не устанавливался WebFarmFrameworkversion 2.2)

-WebPlatformInstaller 3.0 (без него не устанавливался WebFarmFrameworkversion 2.2)

-WebFarmFrameworkversion 2.2 (версия 1.1 на R2 не захотела работать)

-External cache version 1.0

-URL Rewrite version 2.0

-ARR version 3.0

5. Следующие параметры не обязательны, но рекомендуются:

IIS Manager\Application Pools\DefaultAppPool\Advanced Settings\

Значение параметра Idle Time-out (minutes) — установите «0»

3-1idle

IIS Manager\Application Pools\DefaultAppPool\Recycling…\

Отключите параметр Regular time intervals (in minutes)

3-2recycling

6. После установки ARR в окне просмотра функций нашего IIS сервера (в оснастке Internet Information Services Manager) появится «URL Rewrite», а в дереве сайтов — пункт «ServerFarms»:

Создайте server farm (можно использовать любое имя). Сервера входящие в ферму будут получателями трафика, пересылаемого Reverse Proxy сервером.

4

5

7. Добавьте в ферму сервера Exchange(с ролью cas). Порты оставьте по умолчанию (443)

6addserver

Последним шагом будет предложено создать правило, которое будет перенаправлять весь входящий трафик на новую ферму(согласитесь а потом переделайте правило, либо не соглашайтесь и потом сами создайте правило)

8. В настройках фермы настроим следующие компоненты:

7module

Настроим Caching, Health Test, Proxy, Load Balance, Routing Rules

  • В Caching — отключим кэш (disk cache).
  • Health Test

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

  • Load Balance. Параметр Load Balance algorithm: Least current request
  • В Proxy, изменим time-out на 180 секунд(рекомендуемое), Response buffer threshold (KB) — 0.
  • В Routing Rules, выключим SSL off loading (незабудьте всегда нажимать Apply)

8routrules

9. В корне IIS настроим модуль Request Filtering

В панели IIS Manager\server\Request Filtering\Edit Feature Settings..

Параметр Maximum allowed content length – установим значение 2147483648 (2GB):

13request

10. Настроим правила URL Rewrite. Находится модуль в IISManager\сервер\URL Rewrite

9rules

Когда вы откроете URL Rewrite то найдете там два правила по умолчанию. Первое – SSL правило, второе – HTTP правило. HTTP правило нам не понадобиться, поэтому мы можем его удалить или отключить.

10rules

11. Двойной клик на правиле ARR_OWA_loadbalance_SSL и мы увидим настройки правила:

Раздел Match URL – это фильтр, который фильтрует запросы согласно шаблону

Раздел Conditions – дополнительные условия для запросов, которые прошли фильтр Match URL

Раздел Action – действия, которые выполняются с запросами, которые прошли через фильтр Match URL и удовлетворяют условиям, указанным в Conditions

Запросы, проходящие через наш Reverse Proxy-сервер, содержат URL сервера, к которому обращается клиент.

Разберем что за что отвечает:

http(s)://<host>:<port>/<path>?<querystring>

Match URL — работает с <path> .

Conditions — <host>, <port> и <querystring> (черезпеременные «HTTP_HOST», «SERVER_PORT» и «QUERY_STRING»). Для обработки HTTP запросов также используются переменные «SERVER_PORT_SECURE» и «HTTPS»

12. Создадим отдельные правила для OWA и autodiscover

Создадим правило для OWA:

14rule

15rule

13. Создадим аналогичное правило для autodiscover

В итоге у нас получится:

16rules

Profit!

14. Тестируем и ищем возникшие неисправности

Troubleshooting:

Для начала решения возникшей проблемы рекомендуется сначала обратится к логам(не только iis arr но и логи iis exchange). Они находятся по умолчанию в: %SystemDrive%\inetpub\Logs\LogFiles\

Чтобы понять в тонкостях, что ARR делает, нужно настроить Failed Request Tracing, используйте для этого статью Using Failed Request Tracing Rules to Troubleshoot Application Request Routing (ARR). Этот процесс создает XML trace файл в папке по умолчанию: %SystemDrive%\inetpub\Logs\FailedReqLogFiles\W3SVC1.

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

11

22

 

Рубрики:Exchange 2013

Перемещаем и чистим логи Exchange 2013

ex2013

Перемещаем и чистим логи Exchange 2013

При внедрении Exchange возникает неприятная ситуация – мы вроде бы все требования по месту для Exchange выполнили, но оно неумолимо уменьшается… начинаем разбираться и понимаем что всевозможные логи растут быстрее чем мы предполагали, так как же с ними бороться? Далее описаны способы по усечению\перемещению различных логов, в общем все то, что поможет нам решить проблему. Отдельно замечу, что вся информация есть в технической библиотеке technet 🙂 и здесь она всего лишь подобрана для определенной задачи: напомнить способы решения проблем с нехваткой места по причине разрастания логов.

 

Transaction logs

Журнал транзакций наиважнейший элемент Exchange. Приведем пример: при отправке сообщения транзакция сначала записывается в журнал. Пока транзакция не передалась в базу данных Exchange, эти данные существуют только в системной памяти и журналах транзакций. В случае аварии вы теряете содержимое памяти, и все, что у вас остается, это записи в журнале транзакций. Эти журналы важны для восстановления поврежденной базы. То же самое касается и других транзакций: полученных сообщений, удаленных элементов и сообщений, перемещенных в другие папки. Соответственно данные логи растут очень быстро, как же их уменьшить?

1. Резервное копирование

Одной из функций, выполняемых при успешном завершении полной или добавочной архивации, является усечение файлов журнала транзакций, которые больше не требуются для восстановления базы данных. Exchange 2013 поддерживает только резервные копии Exchange на основе службы теневого копирования томов (VSS).

Отличная статья по настройке резервного копирования с использованием Windows Server Backup здесь

2. Включение Circular Logging

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

С помощью EAC  Circular Logging включается так:

ExchLogs1

При включенном циклическом ведении журнала расширенного обработчика хранилищ дополнительные файлы журнала не создаются, вместо этого при необходимости перезаписывается текущий файл журнала. Однако в среде с непрерывной репликацией(DAG) файлы журнала необходимы для доставки и преобразования журналов. В результате при включении циклического ведения журнала непрерывной репликации текущий файл журнала не перезаписывается, а для процесса доставки и преобразования журналов создаются закрытые файлы журнала, т.е обеспечивается непрерывность журналов, а журналы не удаляются, пока они необходимы для репликации. Служба репликации Microsoft Exchange и служба банка данных Microsoft Exchange взаимодействуют с помощью удаленного вызова процедур (RPC), касающихся того, какие файлы журнала могут быть удалены.

3. Перемещение Transaction logs

Ну и в конце концов мы можем переместить логи вместе с базой в другое место\другой диск.

Для этого есть прекрасный командлет Move-DatabasePath. Приведем пример переноса базы данных MDB01 и журналов транзакций на диск M в соответствующие директории:

Move-Databasepath “MDB01” –EdbFilepath “M:\DB\MDB01\database\mdb01.edb” –LogFolderpath “M:\DB\MDB01\logs\”

ExchLogs2

 

Queue Database

Это конечно не логи, но если вам необходимо освободить место то перемещение данной базы может вам помочь. Queue Database — это временное хранилище сообщений, ожидающих следующую стадию обработки. Каждая очередь представляет собой логический набор сообщений, которые обрабатываются сервером транспорта в определенном порядке. Все очереди хранятся в одной базе данных ESE. Очереди размещаются только на серверах почтовых ящиков или на пограничных транспортных серверах. Местоположение базы данных очереди и ее журналов транзакций контролируется ключами в XML-файле конфигурации приложения %ExchangeInstallPath%Bin\EdgeTransport.exe.config.

Все что мы можем сделать с нею, это переместить ее в другое место. Достаточно исчерпывающая информация о перемещении находится в библиотеке technet в статье Change the Location of the Queue Database

 

Transport Logs

Журналы транспорта предоставляют сведения о происходящем в транспортном конвейере. Достаточно исчерпывающая информация о отключении\включении логирования и их перемещении находится в библиотеке technet в статье Transport Logs.

В Microsoft Exchange Server 2013 доступны следующие журналы транспорта:

  • Agent logs
  • Connectivity logs
  • Message tracking and delivery reports
  • Pipeline tracing
  • Protocol logs
  • Routing table logs

Например изменить путь хранения Protocollogs через EAC: servers\servers\выбрать сервер\transport logs\protocol log

ExchLogs3

Например изменить путь хранения Message Tracking через EAC: servers\servers\выбрать сервер\transport logs\message tracking log.

ExchLogs4

Отдельно замечу что переместить можно только в локальную папку. Проблему с размещением на сетевом ресурсе можно обойти использовав команду mklink и создав ссылку на сетевой ресурс. Например  создайте ссылку mklink /d «D:\HubReceiveSMTPLog» \\Server\HubReceiveSMTPLog  , теперь вы можете используя командлет Set-TransportService и параметр –ReceiveProtocolLogPath  «D:\HubReceiveSMTPLog» хранить ReceiveSMTP логи на сетевом ресурсе. Данный способ подходит и для других логов.

 

IIS log files

В логе IIS у вас будет информация например о подключении вашего ipad с помощью протокола activesync. Размер IIS логов, если за ним не уследить может быть очень большим. Как же их автоматом удалить или переместить на другой диск?

1.Автоматическое удаление логов

Запускайте ежедневно через scheduler следующий скрипт ps1 (измените путь хранения логов если нужно) и все ваши логи IIS старше 30 дней будут удаляться не требуя вашего внимания.

set-location c:\inetpub\logs\LogFiles\W3SVC1\

foreach ($File in get-childitem) {

   if ($File.LastWriteTime -lt (Get-Date).AddDays(-30)) {

      del $File

   }

}

Запускать скрипт ps1 через scheduler вы можете следующим образом:

  • Создайте задачу в scheduler
  • Создайте action: start a program
  • В поле program/script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • В поле add arguments(optional): -command “pathTOscript\name.ps1”

ExchLogs5

2.Перемещение логов в другое место

  • Откройте IIS Manager from Administrative Tools и выберете Default Web Site.

ExchLogs6

  • Откройте Logging (щелкните два раза на иконке Logging)
  • Измените место хранения логов

ExchLogs7

  • Сохраните изменения. Следующий файл лога запишется в новое место хранения
  • Тоже самое можно сделать при мощи powershell:

Import-Module WebAdministration

Set-ItemProperty ‘IIS:\Sites\Default Web Site’ -name logfile.directory «D:\IISLogs»

 

Папка Logging

И наконец папка Logging которая по умолчанию находится в ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging. Здесь хранится множество логов различных служб, и может занимать достаточно большое количество места. Особенно выделяются по объему diagnostic and performance log files которые находятся в папке ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics

На просторах интернета было найдено простое решение этого вопроса, запускайте ежедневно через scheduler и все логи из этих папок старше 14 дней перестанут вас беспокоить 🙂

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-14) | Remove-Item

P.S. Я лично предпочитаю резать только diagnostics:

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-2) | Remove-Item

Рубрики:Exchange 2013
Заметки ИТ инженера

Мои заметки, связанные с профессиональной деятельностью в сфере Информационных Технологий

IT in realworld

о технологиях Microsoft, или кратко обо всем. Active Directory and other stuff.