Уже достаточно давно столкнулся со следующей проблемой.

Был установлен Microsoft Office Communicator 2007, который складывал в Outlook в папку Conversation History логи разговоров. После обновления до версии 2007 R2 логи резко увеличились в размере (до обновления были 5-7Кб на сообщение, после 50-70Кб на сообщение). Проблема замечена здесь и здесь.

Заметил, что старые логи хранятся в формате ReachText, новые в HTML. Написал с помощью Васи Гусева небольшой скрипт, который позволяет изменять тип сообщений:

$Outlook = New-Object -ComObject outlook.application
$ns = $Outlook.GetNamespace("MAPI")
$MyFolder = $ns.Folders.Item("Mailbox - DisplayName")
$Conv = $MyFolder.Folders.Item("Conversation History")
$Conv.Items | ForEach-Object { If ($_.BodyFormat -eq 2) {$_.BodyFormat = 3; $_.Save()}}

Здесь аттрибут BodyFormat = 2 для сообщений с форматом HTML, BodyFormat = 3 для ReachText. К сожалению, скрипт проблему с размером не мешает. Думаем дальше.

Вопрос, вынесенный в заголовок, имеет однозначный ответ ещё со времён NT 4.0, а может и раньше. По умолчанию, любой пользователь домена может в него добавить до 10 компьютеров включительно. После превышения этого значения пользователь получит предупреждение «Your computer could not be joined to the domain. You have exceeded the maximum number of computer accounts you are allowed to create in this domain. Contact your system administrator to have this limit reset or increased» после попытки добавить компьютер в домен. Компьютер, конечно же, в домен не добавится.

А теперь немного теории. Любой компьютер в AD имеет аттрибут mS-DS-CreatorSid, в который записывается SID пользователя, который добавил этот компьютер в домен. При попытке добавить новый компьютер для пользователя считается количество объектов-компьютеров, которые он добавлял в домен ранее. Если это число 10, то пользователь не сможет добавить компьютер в домен.

В компаниях, в которых существует отдел тестирования, его сотрудники достаточно часто добавляют в домен компьютеры для тестирования. Обычно, они забывают их при этом из домена удалить. В итоге, в AD хранится некоторое количество «мёртвых» объектов-компьютеров, которые уже не используются, при этом добавляют значения к счётчику компьютеров, введённых пользователем в домен. Достаточно их удалить и пользователь снова сможет добавлять компьютеры в домен. Для решения этой задачи написал небольшой скрипт на PoSh.

$UserName = Read-Host -Prompt "Enter users name"
$UserSID = (Get-QADUser -Identity $UserName -IncludeAllProperties).objectsid

Get-QADComputer -SizeLimit 0 | Where-Object {$_.'mS-DS-CreatorSid' -eq $UserSID} | ft Name

Скрипт запрашивает имя пользователя (можно ввести также и логин) и выводит список компьютеров, которые он вводил в домен. Этот список можно показать пользователю, чтобы он подсказал какие из этих компьютеров можно удалить.

Exchange 2003 позволяет выставлять ограничения на размер почтовых ящиков как на уровне почтовых баз так и на уровне пользователей. Причём, пользовательские настройки переопределяют настройки базы, в которой находится почтовый ящик пользователей. Если таких пользователей много, то бывает проблематично понять у кого какие настройки. К счастью, PoSh может нам помочь в этом. У объекта пользователя в AD имеются следующие аттрибуты, отвечающие за настройки ограничения размера почтового ящика:

• mDBUseDefaults – имеет значение True, если используются настройки базы, иначе равно False
• mDBStorageQuota – указывает ограничение в KB, при достижении которого пользователь получит предупреждение о переполнении ящика
• mDBOverQuotaLimit – указывает ограничение в KB, при достижении которого пользователь не сможет отпрвлять письма
• mDBOverHardQuotaLimit – указывает ограничение в KB, при достиженгии которого пользователь не сможет отправлять и принимать письма.

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

Get-QADUser -IncludeAllProperties -SizeLimit 0 -SerializeValues |
Where-Object {$_.mDBUseDefaults -eq 'False'} |
ft DisplayName, mDBStorageQuota, mDBOverQuotaLimit, mDBOverHardQuotaLimit

Если приходится поддерживать несколько DNS-зон, то можно это делать вручную, так как много времени их поддержка занимать не будет. А что делать если таких зон несколько сотен? Сидеть и вручную их перебирать может занять очень много времени, а следовательно нужно как-то автоматизировать процесс. Задачу упростим следующим образом. Предположим, нам надо получить с нашего DNS-сервера все MX-записи, находящиеся в DNS-зонах которые поддерживаются этим сервером.

К сожалению стандартного командлета для доступа к DNS-серверу я не нашёл. После некоторых поисков нашёл сторонний командлет Get-Dns, который устанавливается как отдельная оснастка в PoSh. Сам командлет можно взять здесь. Установка происходит следующим образом:

PS D:\distr\PoshNet>Extract-Archive PoshNet.zip      
PS D:\distr\PoshNet>.\Install.ps1 PoshNet.dll
PS D:\distr\PoshNet> Add-PSSnapin PoshNet
PS D:\distr\PoshNet> Get-Command -PSSnapin PoshNet
CommandType  Name     Definition
-----------  ----     ----------
Cmdlet       Get-Dns  Get-Dns [-Name] [[-Type] ]...

Теперь осталось попробовать получить список только своих (не факт, что в поддерживаемых зонах используются свои почтовые серверы) mx-серверов. У меня это получилось примерно следующим образом:

(dir \\dns-server\c$\windows\system32\dns\*.dns -Name) |
ForEach-Object { $_ -replace ".dns", "" } | Get-Dns -Type MX -DnsServers dns-server |
select -expand Answers | Where-Object {$_.record.exchange -like "*main-domain.com."} |
ft Name, Type, Record -auto

Как известно DNS-сервер от Microsoft хранит зоны в виде файлов в папке %systemdrive%\windows\system32\dns с именем совпадающим с именем домена и с расширением dns. В первой части мы получаем от нашего DNS-сервера (dns-server) имена всех этих файлов, затем убираем у них расширение .dns и получаем имена зон, которые поддерживает сервер. Далее начинает работать наш новый командлет, который подключается к нашему DNS-серверу и для полученных на первых шагах зонах получает MX-записи и оставляет только те, которые находятся в нашем основном домене. И в конце выводит их в виде таблички. Что здесь важно. Первую часть надо обязательно поставить в скобки, так как процес считывания имён файлов обязательно должен дойти до конца, прежде чем скрипт продолжит работать дальше, и нужно иметь ввиду, что имена серверов пишутся обязательно с точкой на конце.

Создание процедуры резервного копирования является важным шагом при внедрении любого ПО в производство. Enterprise Vault не является исключением из этого правила. В связи с тем, что EV является продуктом, который использует SQL сервер, то процедура резервного копирования проходит в несколько шагов. Во-первых надо сделать резервную копию всех баз данных, которые использует EV, во-вторых надо сделать резервную копию архивного хранилища самого сервера EV. Если с первым пуктом всё достаточно ясно (процедуру резервного копирования базы SQL можно посмотреть в одном из моих предыдущих постов), то с резервным копированием хранилища есть небольшая тонкость. Для проведения полноценного резервного копирования необходимо само хранилище и индексы перевести в так называемый Backup Mode. Что при этом происходит? При включении этого режима все операции записи в архив и изменения индексов останавливаются (фактически хранилище и индексы становятся статическими), пользователи при этом сохраняют возможность получать сообщения из архива и искать по ним сообщения. Большим подспорьем стало присутсвие в последней версии EV набора командлетов для работы с EV из PowerShell. Далее я покажу некоторые скрипты для организации резервного копирования. Continue Reading »

Как известно, утилита ntbackup в Windows 2008 заменена утилитой ServerBackup. При этом механизм работы штатного средства резервного копирования изменился. Кроме этого утверждается о существовании некоторого набора командлетов PoSh для резервного копирования. К сожалению, информации на эту тему совсем немного. Это и послужило поводом для этой записи.
Continue Reading »

Возникла задачка – получить список всех общих папок на Exchange 2003, у которых подключен e-mail адрес. Первое что пришло в голову – попробовать через PoSh.
Вот какой небольшой срипт получился:

Get-WmiObject -ComputerName MBXSRV -Namespace root\MicrosoftExchangeV2 -Class exchange_publicfolder | where {$_.IsMailEnabled -like "True"} | Select-Object Name,Path | Export-Csv filename

Доступ к общим папкам получаем через класс exchange_publicfolder. И делаем выборку только по тем папкам, у которых в свойствах IsMailEnabled равняется True.
Было бы неплохо на выходе иметь таблицу вида Name,path,e-mail. Но как получить доступ к почтовому алиасу общей папки пока не знаю.

Поддержание в актуальном состоянии информации о размере почтовых баз крайне полезно. Это позволяет давать оценку роста почтовых баз и контролировать их размер. Не менее интересно иметь в наличии информацию о размере почтовых ящиков пользователей в базах. Известно, что при онлайновой дефрагментации, которая происходит при выполнении стандартных профилактических работ, размер самого файла базы не изменяется. В Event Log при этом по завершении процесса пишется информация об объёме, который фактически резервируется Exchange-сервером и который заполняется при поступлении новой информации в почтовую базу. Имеется инструмент и для сжатия самого файла почтовой базы на этот объём (eseutil /d).

Ниже привожу скрипт для получения в удобном для обработки виде информации по пользователям/базы размещения их почтового ящика/размере ящика/количестве писем:

#Создаем переменные массивов под размеры писем и их количество
$Sizes = @{}
$Messages = @{}
#Здесь собственно эти массивы заполняются информацией с Exchange-сервера
Get-WmiObject -ComputerName $Server -Namespace root\MicrosoftExchangeV2 -Class Exchange_Mailbox |
ForEach {$Sizes[$_.MailboxDisplayName]=$_.Size; $Messages[$_.MailboxDisplayName]=$_.TotalItems}
#Здесь формируется список следующего вида -
#Имя пользователя, почтовая база, отдел, компания, размер ящика, количество писем
Get-QADUser -IncludeAllProperties -SerializeValues -SizeLimit 0 | Where-Object {$_.homeMDB} |
Select-Object Name, homeMDB, department, Company,
@{name="MailboxSize";expression={$Sizes[$_.DisplayName]}},
@{name="MailboxItems";expression={$Messages[$_.DisplayName]}} | Export-Csv file.csv

Оргомное спасибо Василию Гусеву за этот скрипт.

Предполагается что параметры DisplayName и MailboxDisplayName совпадают для любой учётной записи пользователя. В принципе можно пробовать использовать LegacyDN и LegacyExchangeDN, но это имеет смысл только в случе несовпадения DisplayName и MailboxDisplayName.

Последние несколько недель занимался реструктуризацией почтовых баз. В итоге количество баз увеличилось примерно в 2 раза, средний размер составляет 20-25Гб. Несколько гигантских баз было расформировано и удалено (например 2 базы по 70Гб). К этому решению шёл долго. Началось всё с, казалось бы, незначительной проблемы с рассылкой почты по спискам распространения. Случайно выяснилось, что при рассылке почта доходит не всем адресатам. Доходя до некоторых адресатов почта застревает в очереди и либо через несколько попыток доходит, либо (что происходило чаще) через 3 дня с начала отправки формируется NDR и сообщение из очереди удаляется. Вот здесь пытался разобраться с этой проблемой. Как оказалось дело в том, что нарушена целостность почтовых баз. Решений оказалось всего три:
1. Нахождение проблемных пользователей, выгрузка их почты в PST, пересоздание почтового ящика и загрузка PST обратно.
2. Проверка почтовых баз и исправление ошибок с помощью isinteg.
3. Создание новых хранилищ и перенос пользовательских данных в них.
Первый пункт в моем случае оказался малопродуктивным (слишком много проблемных пользователей), со вторым возникла некоторая проблема. Как известно isinteg /fix работает примерно со скоростью 10Гб/с на базе без ошибок, а при исправлении ошибок скорость снижается на 3 порядка. В итоге 2 проблемные базы на 70Гб так до конца проверить и не получилось, так как оставлять часть офиса без почты более чем на 10 часов даже в выходные мне было запрещено. Остался только третий пункт. При переносе заметил следующую особенность – скорость переноса сильно зависит не от объёма ящика, как можно было бы подумать, а от количества сообщений в нём. Помимо этого скорость зависит ещё от количества одновременно переносимых ящиков. В итоге экспериментальным путём установил, что ящик, в котором около 30000 сообщений, переносится в районе часа.
Параллельно с процессом переноса решалась задача о соответствии структуры хранилищ организационной структуре компании. В итоге сваял простенький запрос на PoSh для вытаскивания на свет информации о пользователе, отделе в котором он работает, компании (у нас несколько юридических лиц и эта информация отображается в учётной записи пользователя) и базе, в которой находится его ящик:

Get-QADUser -IncludeAllProperties -SerializeValues -SizeLimit 0 | Where-Object {$_.homeMDB -notlike ''} |
Select-Object Name, homeMDB, department, Company | Export-Csv f:\tmp.csv

Очень удобно для составления таблицы с указанием какие пользователи в каких базах хранятся. Для полного счастья не хватает ещё информации о размере ящиков и количестве сообщений в них. Видимо этот запрос надо скомбинировать с запросом, который находится здесь. В общем пока эта задачка ещё ждёт решения.

Функционал общих папок в Exchange 2007 сильно урезан по сравнению с Exchange 2003/2000. Майкрософт заявляет, что после 2016 года прекратит поддержку общих папок в продуктовой линейке Exchange. В качестве альтернативы предлагается использовать MOSS. В интернете достаточно много статей посвященных процессу переноса общих папок из Exchange в SharePoint. Это такое лирическое отступление.
Конкретика начинает потихонечку появляться на форумах в вопросах об управлении общими папками в Exchange 2007. Не смотря на то, что с выходом sp1 Exchange приобрел консоль управления общими папками (Public Folder Management Console) он не умеет через неё назначать права доступа к папкам.
На Technet Library лежит довольно подробная инструкция о том как это делается. Графический интерфейс заменён на командлеты и сценарии PoSh:

1. Можно использовать командлет Add-PublicFolderClientPermission или сценарий управления пользователями AddUserToPFRecursive.ps1 для указания разрешений пользователя.

2. Можно использовать командлет Remove-PublicFolderClientPermission или сценарий RemoveUserFromPFRecursive.ps1 для удаления полномочий пользователя-клиента.
Сценарии ReplaceUserWithUserOnPFRecursive.ps1 и ReplaceUserPermissionOnPFRecursive.ps1 можно использовать для замены клиентских полномочий по отношению к общей папке.

3. Командлет Get-PublicFolderClientPermission можно использовать для просмотра клиентских прав доступа, связанных с общей папкой.

4. Разрешение «Отправить от имени» можно использовать для настройки общей папки, поддерживающей почту.

5. Можно использовать командлет Add-PublicFolderAdministratorPermission, командлет Add-ExchangeAdministrator или мастер добавления администратора Exchange, чтобы предоставить пользователю административные права на доступ к общей папке или иерархии общих папок.

6. Можно использовать командлет Add-PublicFolderAdministratorPermission, командлет Add-ExchangeAdministrator или мастер добавления администратора Exchange, для отзыва у пользователя административных права на доступ к общей папке или иерархии общих папок.

7. Можно использовать командлет Get-PublicFolderAdministratorPermission, командлет Get-ExchangeAdministrator или узел Конфигурация организации для просмотра административных прав, связанных с общей папкой или иерархией общих папок.

В принципе всё достаточно просто и прозрачно. На мой взгляд командлеты – более удачное решение по управлению правами доступа к общим папкам, чем графический интерфейс Exchange System Manager.
P.S. Всё выше написанное не связано с управлением общими папками из MS Outlook 2007.