Exchange и PowerShell работаем с почтовыми ящиками (заметки)

Сегодня решил закинуть в блог несколько полезных команд для работы с почтовыми ящиками используя командную строку PowerShell. Все команды рабочие, используются периодически для разных административных нужд. В начале несколько команд, без понимания которых дальше будет сложно разобраться.
1) Полная статистика почтового ящика пользователя

[PS] > Get-Mailbox user | select *

Эта команда выводит все параметры, которые могут потребоваться для работы с почтовым ящиком.
2) Для того, чтобы посмотреть кто имеет полные права к конкретному почтовому ящику выполняем следующую команду:

[PS] > Get-MailboxPermission | where {$_.AccessRights -eq «FullAccess» -and $_.IsInherited -eq $false}

Указываем алиас почтового ящика и смотрим кто имеет права доступа FullAccess
3) Добавляем права доступа FullAccess к почтовому ящику пользователя:

[PS] > Add-MailboxPermission -Identity -User -AccessRights FullAccess -InheritanceType All -Automapping $false

Обращаем внимание на параметр: -Automapping $false — он говорит чтобы пользователю автоматически не подключался почтовый ящик пользователя .

Дальше более интересные комбинации команд.
4) Добавляем разрешения FullAccess ко всем почтовым ящикам в организации. Для начала соберем массив почтовых ящиков с уникальными параметрами, которых будет достаточно для наших задач Name, Alias, ServerName, ProhibitSendQuota:

[PS] > $MailboxList = Get-Mailbox $Identity

Затем выполняем команду:

[PS] > $MailboxList | ForEach {Add-MailboxPermission -Identity $_.Alias -User -AccessRights FullAccess -InheritanceType All -Automapping $false}

В результате выполнения этих команд пользователь будет иметь полный доступ ко всем почтовым ящикам и у него будет отключено автоматическое подключение почтовых ящиков, к которым он имеет доступ.
5) Удаляем разрешения FullAccess ко всем почтовым ящикам в организации. Опять создаем массив из примера 4 и выполняем команду:

[PS] > $MailboxList | ForEach {Remove-MailboxPermission -Identity $_.Identity -User -AccessRights FullAccess -InheritanceType All -confirm:$False}

Пользователь больше не имеет прав доступа к почтовым ящикам кроме своего (SELF). Здесь еще хочу обратить внимание на параметр: -confirm:$False Он освобождает нас от подтверждения удаления прав доступа к каждому почтовому ящику.

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

P.S. Ахтунг: не забываем про кавычки

Реклама

Exchange 2010 — создаем много почтовых ящиков

Предыстория: две организации сливаются в одну и около ста новых сотрудников должны появиться в локальной сети.
Задача: Создать 100 учетных записей в домене и у каждого должен быть почтовый ящик.
Решение: Есть много вариантов. Самый простой и муторный, на мой взгляд — это каждого заводить «руками». Долго и большая вероятность ошибки, что что-то сделаешь не так. Более быстрый вариант — это всех списком импортировать в систему. Если боитесь использовать PowerShell, то тогда ваш выбор — это первый вариант.
Я хочу показать как решить поставленную задачу с помощью второго варианта. У нас есть таблица с ФИО новых сотрудников. В начале приводим ее в удобный вид для импорта. Чтобы понять какие поля нам нужно заводить смотрим то, что есть уже у существующего пользователя:

>Get-Mailbox s.sidorov | select *

На выходе должен получиться CSV файл с разделителем «запятая» в формате UTF-8 (new.csv):

DisplayName,Mail,Alias,SAM,UPN
Иванов И.,i.ivanov@maildomain.ru,i.ivanov,usr-i.ivanov,usr-i.ivanov@domain.net
Петров П.,p.petrov@maildomain.ru,p.petrov,usr-p.petrov,usr-p.petrov@domain.net

На почтовом сервере предварительно готовим политику почтовых адресов, где указываем, что люди в этом OU «domain.net/_users/NewUsers» будут иметь почтовый адрес: @maildomain.ru
Теперь в PowerShell-е вводим две комманды (можно все оформить одним скриптом, но мне удобнее вот так):

>import-csv C:\Temp\new.csv | Foreach-object {
>New-Mailbox -Name $_.DisplayName -UserPrincipalName $_.UPN -DisplayName $_.DisplayName -SamAccountName $_.SAM -PrimarySmtpAddress $_.Mail -Alias $_.Alias -OrganizationalUnit «domain.net/_users/NewUsers» -Database DB01 -Password (ConvertTo-SecureString 111qqq@@@ -AsPlainText -Force) -ResetPasswordOnNextLogon $true }

Ахтунг: не забываем про кавычки
На мой взгляд только один параметр заслуживает здесь внимания: -Password. Здесь мы новой доменной учетной записи назначаем пароль для первого входа в систему, который в системе храниться в зашифрованном виде. При первом входе в систему пользователь будет обязан его сменить. За это отвечает параметр -ResetPasswordOnNextLogon.

Ответ:
В системе у нас есть:
пользователь: i.ivanov
логин: usr-i.ivanov
в домене: domain.net
почтовый алиас: i.ivanov
почтовый ящик: i.ivanov@maildomain.ru
в адресной книге он будет отображаться как: Иванов И.

Контроллер, электричество и другие неприятности

Не так давно пришлось попыхтеть с восстановлением данных. В один прекрасный день, сервер «упал». После перезагрузки в логах было много ошибок записи NTFS системы. Вынув сбойный диск и заменив его на другой система через минут 20 снова рухнула. После различных экспериментов, стало ясно — контроллер жестких дисков не работает с диском, который подключен к 3-му каналу.
Небольшое отступление, система была спроектирована в «бюджетном» варианте. 4 диска, два зеркала, одно под систему и логи, второе зеркало под базы данных. В том бюджете — это было самое оптимальное решение.
После замены контроллера LSI MegaRAID SAS MR9240-4i, аккуратного запуска системы с дисками, работа системы была восстановлена. Дальше началось «лечение» баз данных. В результате — одна база из трех имела потерянные данные и восстановлению не подлежала. Она была восстановлена из архива и были потеряны данные только за двое суток. Понятно, что данный инцидент не очень приятен, но на тот момент лучшего варианта не было.
Но на этом история не закончилась. Через 5 дней в серверной комнате выключают электричество. Авария на подстанции мосэнерго. ИБП протянул минут 10 и сервера в стойке сказали «прости — прощай».
После включения электричества начали заводить сервера. Сервер контроллер домена — пережил падение на удивление легко. При восстановлении своей базы все отработало на автомате и АД поднялась без проблем. Далее начал запускать почтовый сервер. А это как раз тот сервер на котором меняли контроллер жестких дисков. Все три базы находились в состоянии Dirty Shutdown. Собственно не страшно, с точки зрения данных, но по времени восстановление баз в рабочее состояние заняло около 9 часов.

Немного команд, так сказать на будущее:
eseutil /MH BASE00.edb — смотрим в каком состоянии почтовая база
eseutil /ML E00.log — смотрим уелы логи или нет. Чаще всего они целы, что не может не радовать

eseutil /P BASE00.edb — Repairs a corrupted or damaged database. Хоть разработчики и рекомендуют, строго рекомендуют восстановить базу с последнего момента чистого отключения базы, но если время после последнего архива прошло достаточно много или еще какие причины? Поэтому деваться некуда — смело запускаем и ждем завершения процесса. Процесс может затянуться, все зависит от размеров Вашей почтовой базы.
После того как база примет состояние «Чистого отключения», то не торопитесь монтировать базу. Для завершения процедуры выполним команду:
eseutil /R E00.log

Все! Монтируйте базы, но не думайте, что все будет идеально. Скорее всего ошибки с некоторыми почтовыми ящиками будут. Увеличивайте уровень журналирования и смотрите логи на сервере.

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

Exim как почтовый релей для двух доменов

Сегодня хочу рассказать о том, как настроить почтовый сервер Exim в роли почтового релей сервера, который обслуживает две почтовые системы и два почтовых домена соответственно. Exim сервер в качестве почтового релея использую достаточно давно из-за его простоты, быстроты, удобства управления и, самое главное, его стоимости — он бесплатный.

Читать далее

Миграция почтовых ящиков с Lotus Domino на Exchange server 2007

В предыдущей статье я описал, как настроить синхронизацию каталогов между Lotus Domino и Exchange server 2007 с помощью утилиты «Microsoft Transporter Suite». Это первый этап в процессе миграции почтовых ящиков с одной почтовой системы на другую. Сегодня я опишу сам процесс миграции и постараюсь уделить внимание ошибкам, которые могут возникнуть при выполнении этой задачи.

Читать далее

Синхронизация каталогов между Lotus Domino и Exchange server 2007

Сегодня я опишу процесс настройки синхронизации каталогов между Lotus Domino и Exchange server 2007 с помощью утилиты «Microsoft Transporter Suite». На первый взгляд в процессе настройки синхронизации ничего сложного нет, но, как показывает практика, любая кажущаяся простой задача может перейти в разряд непростых, если не соблюдены определенные условия.

Читать далее

Переименование домена

Хочу поделиться своим опытом, как можно переименовать существующий домен Windows 2003 с установленным Exchange Server 2007. Не торопитесь с критикой и ссылками на Microsoft. Я там был, читал, даже поверил. Цитата из официальной информации (здесь):

После переименования существующего домена Windows Server 2003 с помощью средства Rendom.exe на компьютерах с Exchange 2007 не запускаются указанные ниже службы… и т.д.

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

Читать далее