Попрощались со старым Exchange Server 2013


На днях разбирал старый Exchange Server 2013 после переезда на версию 2019. Всё прошло гладно, но с парой приколов. Выяснилось, что часть клиентов упрямо подключается к старым CAS серверам. После недолгих изысканий оказалось, что недостаточно обнулить URL-ы в SCP с помощью командлетов. Пришлось запустить ADSIEDIT.msc и удалить старые SCP вручную:

CN=<server>,CN=Autodiscover,CN=Protocols,CN=<server>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru

Это значительно улучшило ситуацию, но некоторые клиенты продолжали подключаться к старым CAS серверам. Оказалось, что есть записи в Host файлах на клиентах: когда-то что-то отлаживали и забыли убрать :-)

Еще один прикол вылез со старыми клиентами — несколько Unix систем и масса МФУ, которые анонимно отправляли сообщения в локальные почтовые ящики. Оказалось, что не работает TLS — на новых Windows Server 2019 все старые протоколы отключены, кроме TLS 1.2. МФУ пришлось перепрошивать (у некоторых и это не помогло — сделали под них анонимный коннектор без TLS). На Unix-ах исправляли конфиги.

Exchange Server 2013 безотказно проработал около 7 лет за что ему большое спасибо! Хочется верить, что Exchange Server 2019 проработает не меньше, несмотря на политические замещения :-)

Отчёт по событиям из календарей Outlook


Для управления рабочим временем (Time management) существует множество подходов и программных продуктов их поддерживающих.

Самое простое средство для планирования и управления рабочим временем это календари Outlook. Outlook обладает хорошими возможностями для управления рабочим временем (Time management) на базе календарей даже без всяких надстроек. Существует много статей и книг по этому вопросу.

Проблема в том, что календари ведутся автономно. А что если нужен ответ на простой вопрос: «Насколько много сотрудники неоправдано отвлекаются на совещания?». Неужели для этого придется закупать bи внедрять систему Time management и настраивать систему отчётов?

Посмотрим как можно собрать информацию из календарей пользователей, используя Exchange Server API.

Во-первых, нам нужна учётная запись, которая будет формировать отчёт. Этой учётной записи нужны права доступа ко всем календарям. Как их предоставить? Можно назначить права доступа командлетом или захватить права на почтовую базу (в стиле Exchange Server 2003). Самый правильный подход — использовать RBAC. Нам нужна имперсонализация:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <имя нашей учётки>

Разновидностей отчётов может быть бесконечное множество. Поэтому мы запустим PowerShell от имени учётой записи, для которой мы настроили имперсонализацию, и выгрузим все события из всех календарей со всеми свойствами в файл в CSV формате. Затем эту информацию можно загрузить в базу данных или Excel для анализа.

$StartDate = Get-Date 1/1/2020
$EndDate = Get-Date 1/31/2020

# Исправьте этот путь для вашей версии Exchange Server
# Это вообще не нужно для EWS
Add-Type -Path "C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.WebServices.Auth.dll"
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013_SP1)

$result = Get-MailBox -ResultSize Unlimited | ForEach-Object {

  $SmtpAddress = $_.PrimarySmtpAddress.Address

  Write-Host "MailBox: $SmtpAddress"

  $Service.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $SmtpAddress);

  [void]$Service.AutodiscoverUrl($SmtpAddress)

  # Bind to the calendar folder of the mailbox
  $FolderId = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar,$SmtpAddress)
  $Calendar = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service,$FolderId)

  # Define the calendar view
  $CalendarView = New-Object Microsoft.Exchange.WebServices.Data.CalendarView($StartDate,$EndDate)
  $Calendarview.MaxItemsReturned = 1000 	# 1000 is the maximum number of items that can be returned in a CalendarView

  $AppointmentItems = @()
  $AppointmentItems = $Service.FindAppointments($Calendar.Id,$CalendarView)

  if ($AppointmentItems.TotalCount -eq 0)
  {
      #Write-Host "MailBox: $SmtpAddress : AppointmentItems is empty."
      #return;
  } 

  $properties = New-Object Microsoft.Exchange.WebServices.Data.PropertySet(
      [Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties,
      [Microsoft.Exchange.WebServices.Data.AppointmentSchema]::RequiredAttendees,
      [Microsoft.Exchange.WebServices.Data.AppointmentSchema]::OptionalAttendees);

  $res = $service.LoadPropertiesForItems($AppointmentItems, $properties)
  $service.LoadPropertiesForItems($AppointmentItems, $properties)

} | Select-Object -ExpandProperty Item -Property @{name="User"; expression={ $SmtpAddress }},@{name="Count"; expression={ CountMembers $_ }} |
    Select-Object -Property * -ExcludeProperty Body |
    Export-CSV -Path all_items.csv -NoTypeInformation

function CountMembers ($item) {
    $count = 0

    $item.Item.RequiredAttendees |
        ForEach-Object {
           $count += if ($_.MailboxType -eq "PublicGroup") { (Get-ADGroup -Identity $_.Name -Properties members).Members.Count } else { 1 }
        }

    $item.Item.OptionalAttendees |
        ForEach-Object {
           $count += if ($_.MailboxType -eq "PublicGroup") { (Get-ADGroup -Identity $_.Name -Properties members).Members.Count } else { 1 }
        }

    return $count
}

Как бонус скрипт подсчитывает число участников собраний.

Я не буду описывать, как создать какой-то конкретный отчёт в Excel на основе этой информации — это не благодарное дело. Используя фильтры Excel, вы можете найти организаторов собраний, выделить собрания по уникальному идентификтору, вычислить длительность собраний, построить сравнительные графики рабочего времени и много чего ещё.

Для полноты картины вы можете добавить информацию о пользователях из Active Directory (или другой системы). Тогда вы сможете делать анализ, например, по подразделениям.

Полезные ссылки:

  1. New-ManagementRoleAssignment
  2. Configure impersonation
  3. Auditing Exchange Rooms for Double Bookings
  4. Create appointments and meetings by using EWS in Exchange 2013

AppLocker и CRL


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

Со временем политика использования сертификатов на Windows системах ужесточается. Мы все ощутили это в то время, когда RDP клиент на Windows 7 начал делать жесткие проверки сертификатов. Многие инфраструктуры пришлось тогда подчистить и подправить, чтобы пользователи не испытывали проблем с подключениями к удаленным рабочим столам.

Проверки CRL также могут вызывать проблемы — в виде задержек. Это уже было в нашем опыте с Sharepoint и Exchange серверами. Собственно это все тот же CAPI.

На днях выяснилось, что этой проблеме подвержен AppLocker. Оказывается, даже если он выключен, он всё равно работает где-то в недрах системы, пытается что-то проверять и даже провоцирует проверки сертификатов и CRL. А уж если он включен, и настроены правила Publisher, то и подавно.

Это имеет один неожиданный побочный эффект. Собственно так это и было обнаружено. Суть в том, что PowerShell имеет встроенную поддержку AppLocker, т.е. делает специальные вызовы API, чтобы проверить можно ли запускать тот или иной скрипт. Побочный эффект в том, что из-за проверок CRL в AppLocker PowerShell может работать медленнее: задержка запуска, задержки при загрузке модулей, задержки при выполнении скриптов.

Надо отметить, что эта проблема чаще всего возникает в изолированных сетях. Но иной раз и в сетях, которые просто неправильно сконфигурированы (фаервол и, особенно, DNS).

Неправильно сконфигурированные сети надо лечить.

Рекомендация для изолированных сетей простая: групповыми политиками уменьшить тайм-аут проверки CRL.

Ссылки:

Рекомендация отсюда

Обсуждение PowerShell