1. Сам отправитель является хозяином папки
2. Права «анонимного пользователя» = Author
3. Права «по умолчанию» = Author
4. Папка не требует обязательной аутентификации отправителей
5. Сообщение от любого внешнего источника в папку доставляется корректно. При этом несущественно, через какой smtp коннектор получена почта (внешний анонимный или внутренний с аутентификацией отправителя).
6. Проблема наблюдается только для какого-то ряда внутренних отправителей, на первый взгляд совершенно несвязанных друг с другом (разные департаменты, различные полномочия, большой разброс времени создания учетной записи)

И даже более того: после создания новой mailenabled общей папки и внимательного назначения для нее прав, была проведена серия тестов:

1. Письмо с smtp адресом отправителя изнутри организации, возвращается с NDR.
2. Письмо с smtp адресом отправителя извне, ложится в папку.
3. Если добавить пользователю произвольный внешний smtp адрес, а затем отослать письмо с этим адресом отправителя. То на основной адрес пользователя сваливается NDR.
4. Действо из предыдущего пункта совершенно безболезненно проходит с отправкой на адреса почтовых ящиков пользователей организации.

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

Но потусторонние силы оказались не виноваты
В AD для целей поддержки какого-то решения удаленного доступа, проверяющего права пользователя на вход путем LDAP запросов, был создан контейнер в который помещены несколько групп. Для целей безопасности, доступ к данному контейнеру был обеспечен только для контроллеров домена, администраторов и специально созданного пользователя с минимальным набором прав (гость домена).
Поскольку серверы Exchange прав на доступ к данным группам не имели, у всех пользователей, включенных в одну из данных групп безопасности, и возникала проблема невозможности доставки сообщений.
Ну а «свежесозданные пользователи» заводились путем копирования учетных записей нескольких администраторов и одной из тестовых учетных записей...тоже входящей в какую-то «секретную» группу.

Данные требования были удовлетворены путем установки глобального значения Recipient Limits равного 30 и явного указания заведомо большого (15000) разрешенного количества адресатов в свойствах тех пользователей, с которых ограничение необходимо снять. Собственно говоря, данная конфигурация является полностью логичной...при использовании почтового сервера Exchange 2003.

В архитектуре же Exchange 2010 (на самом деле, насколько я помню, уже начиная с Exch2007) логика работы иная.

Глобальное ограничение является полноценно глобальным для организации, а не «значением по умолчанию». И в свойствах конкретного пользователя бессмысленна установка значений выше данного ограничения.
Соответственно, уже в начале процесса миграции почтовой системы на новую версию, возникает следующая проблема: необходимо вместо глобального ограничения количества получателей одного сообщения, установить для каждого пользователя индивидуальное. Что при количестве пользователей равному примерно 3000 несколько затруднительно...если, конечно, не знать простой способ

Чтобы получить список ящиков, находящихся на сервере предыдущей версии, необходимо в EMS консоли (да-да, на 2010 сервере) выполнить простейшую команду:
get-mailbox -server MyExch2003 -ResultSize Unlimited | where {$_.RecipientLimits -like «unlimited»}

И дабы автоматически решить возникшую «проблему», всего лишь незначительно дополнить данную команду:
get-mailbox -server MyExch2003 -ResultSize Unlimited | where {$_.RecipientLimits -like «unlimited»} | set-mailbox -RecipientLimits 30

Начальная разборка устройства не представляет сложностей, затем снимаем крышку отсека радиомодуля и видим:

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

Ладно, оставим эти размышления потомкам, а сами возьмем два радиатора, ножницы, термопасту, пузырек суперклея и решим проблему охлаждения так, чтобы она более не мешала спать по ночам.

Хотя это и широко анонсировалось, до сих пор мало кто хорошо знает об одной интересной особенности новых операционных систем от компании Microsoft. Я о поддержке режима работы в качестве точки доступа, который появился в Windows 7 и Server 2008 R2.
Уж скажем честно, решение, традиционно, получилось чуть-чуть не совсем доработанным до того функционала, о котором можно было мечтать. Но для целей оперативно предоставить доступ в интернет приехавшему на переговоры партнеру — вполне подойдет, когда не хочется этого партнера заставлять мучительно ожидать организации доступа силами сотрудников ИТ отдела.
Достаточно лишь запустить командную строку с повышенными правами и скопировать-вставить в появившееся черное окно две строки:

1. netsh wlan set hostednetwork mode=allow ssid=LibertineGuest key=superKey^1234
2. netsh wlan start hostednetwork

После чего вызвать свойства своего текущего сетевого подключения и на вкладке «доступ» установить галочку «другие пользователи могут подключаться».
Вот и все, скучающий бизнес-партнер теперь может подключиться к беспроводной сети LibertineGuest используя пароль superKey^1234
Кстати, вот после этого имеет смысл задуматься о степени сетевой безопасности и том, за что же Вы все же платите сотрудникам своего ИТ отдела, утверждающим, что трудятся в поте лица, защищая корпоративные данные? Кто, кроме Вас, может проделать вышеозначенные операции и дать доступ группе злоумышленников сидящих в автомобиле внизу? А ведь, по-хорошему, у вас, как обычного пользователя, не должно было быть даже прав в системе на подобные операции.

Ну да ладно, предположим, мы все же используем технологии во благо
Итак, как я уже упомянул, в Server 2008 R2 появилась возможность создания беспроводной точки доступа. А, значит, если у нас есть все необходимые лицензии на использование соответствующего ПО, мы вполне можем установить на него Threat Management Gateway со всем его приятным функционалом в виде защиты от внешних угроз, кэширования и антивирусной проверке трафика, возможности создания VPN подключений и, главное, автоматического переключения на резервный канал при недоступности основного (например, то же коммерческий публичный WiFi).
Правда, кое о чем необходимо упомянуть:

1. По умолчанию, поддержка беспроводных подключений в серверной OC отключена. Поэтому, необходимо перевести в автоматический старт службу «Wireless LAN AutoConfig»
2. После перезагрузки системы необходимо заново вручную выполнить команду «netsh wlan start hostednetwork». Но это решается крайне просто, учитывая, что для запуска при помощи ключа реестра или локальной групповой политики не активен UAC (на самом деле, оно неактивно для всех действий учетной записи системы, но это детали).
3. Поскольку все данное решение разработано производителем именно для целей «быстрого подключения партнера», при старте сети будут включены и запущены службы ICS (общий доступ к подключениям) и DHCP/DNS сервер. Что, разумеется, вызовет конфликт со службами TMG. Что ж, просто необходимо сначала все ненужные службы остановить и запретить к запуску (т.к., в частности, ICS будет пытаться сделать перезапуск при любой остановке), а затем все нужные нам службы — перезапустить. Все это ровно также просто автоматизируется, главное, помнить о том, что необходимо вставлять задержки выполнения, т.к. некоторые службы, имеющие под собой зависимые, требуют некоторого времени на старт

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

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

И снова нам на помощь приходит простое и функциональное средство LogParser (ранее примеренное для анализа логов Exhange2007), на этот раз используемое для анализа логов принт-сервера.

Итак, предположим, нам необходимо получить простой csv файл, где будет присутствовать информация за сегодняшний день о том, когда, кто, на каком принтере и сколько страниц распечатал. Да и название отправленного на печать документа лишним не будет.
Для этого к командной строке нам необходимо написать:
1. LogParser.exe — без комментариев
2. file:parsprn.sql  — файл, в котором записан необходимый SQL запрос
3. -i:EVT — указатель, что ввод необходимо взять из системного лога принт-сервера
4. -o:CSV — указатель на необходимый формат вывода

Но прежде, чем выполнять команду, неплохо будет создать сам файл запроса parsprn.sql:
select
TimeGenerated AS LogonDate,
EXTRACT_TOKEN (Strings, -6, '|') AS docname, — из за того, что в имени файла могут встречаться символы |, рекомендую использовать именно «обратную» форму записи.
EXTRACT_TOKEN (Strings, -5, '|') AS username,
EXTRACT_TOKEN (Strings, -4, '|') AS prndevice,
EXTRACT_TOKEN (Strings, -2, '|') AS bytesize,
EXTRACT_TOKEN (Strings, -1, '|') AS pgsize
into v:\parsprn.csv
from SYSTEM — указатель, из какого именно системного лога нам необходимо извлечь данные
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM-dd'),'yyyy-MM-dd') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM-dd'),'yyyy-MM-dd') — на каком-то этапе была выявлена неприятная особенность определения понятия «сегодня», поэтому надежнее сравнивать простые строки
and EventID IN (10)

Отчет для целей архивного хранения мы таким образом получили. А теперь предлагаю начать создавать отчеты, приемлемые для восприятия человеком.
Первым делом, предлагаю не уходить далеко от простейшего отчета в виде csv файла, но вывести в него только события, имевшие место после завершения рабочего дня. Очень, кстати, забавно наблюдать реакцию, утверждающего что месячный отчет для вас он героически готовил вчера аж до 11 вечера, когда этому «герою» задаешь вопрос, как же так получается, если единственную копию он распечатал в 18:23?
Особенных изменения предыдущий вариант файла SQL запроса не потребует, всего лишь нужно добавить условие отбора:
and TO_TIMESTAMP (TO_STRING (TimeGenerated, 'h'),'h') > TO_TIMESTAMP (TO_STRING ('17'),'h')

Теперь предлагаю наглядно вывести, так сколько же отпечатков суммарно выводится на каждом из принтеров. Данная информация, кстати, может послужить хорошим аргументом в планировании модернизации оборудования. Вовсе не факт, что тому или иному департаменту действительно актуален апгрейд многофункционального устройства, а не установка дополнительного дешевого копира.
Примерная строка запуска будет выглядеть следующим образом:
LogParser file:parsprnpcountd.sql -i:EVT -o:CHART -chartType:barstacked -chartTitle:"printers by pages" -groupSize:1024×1600
parsprnpcountd.sql

Файл же непосредственно SQL запроса, примерно так:
select
EXTRACT_TOKEN (Strings, -4, '|') AS prndevice,
sum (TO_INT (EXTRACT_TOKEN (Strings, -1, '|'))) AS pgcount
into v:\pages_per_device.gif
from SYSTEM
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM-dd'),'yyyy-MM-dd') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM-dd'),'yyyy-MM-dd')
and EventID IN (10)
group by prndevice
order by pgcount desc

На выходе мы получим вполне наглядное представление того, что хотели выяснить:

Наконец, предлагаю вывести 25 «рекордсменов» по расходу бумаги. Примерная строка запуска запроса будет выглядеть следующим образом:
LogParser file:parsprnpcountopu.sql -i:EVT -o:CHART -chartType:barstacked -chartTitle:"top 25 users by pages" -groupSize:1024×800

Сам же файл запроса parsprnpcountopu.sql будет выглядеть следующим образом:
select
top 25 EXTRACT_TOKEN (Strings, -5, '|') AS username, — соответственно, если из запроса убрать «top 25», мы получим отчет, включающий всех пользователей
sum (TO_INT (EXTRACT_TOKEN (Strings, -1, '|'))) AS pgcount
into v:\top_users_by_pages.gif
from SYSTEM
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM-dd'),'yyyy-MM-dd') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM-dd'),'yyyy-MM-dd')
and EventID IN (10)
group by username
order by pgcount desc

Примерный вид получившегося отчета будет таков:

Ровно аналогичные отчеты можно, разумеется, получить и за другие промежутки времени. Все зависит исключительно от буйности фантазии. Например, запрос распределения количества отпечатков по дням будет выглядеть следующим образом:
select
TO_STRING (TimeGenerated, 'dd') as day,
sum (TO_INT (EXTRACT_TOKEN (Strings, -1, '|'))) AS pgcount
into v:\pages_per_day_month.gif
from SYSTEM
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM'),'yyyy-MM') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM'),'yyyy-MM')
and EventID IN (10)
group by day
order by day

Связка Exchange и Outlook вполне разумно, что уже давно используется исключительно в двух вариациях: со включенной функцией кэширования и с выключенной. Оба варианта использования имеют свои недостатки: при выключенном кэшировании возникает излишняя нагрузка на сервер, а при включенном кэшировании объемного ящика — могут быть серьезные проблемы с производительностью на стороне клиента (в особенности, если на стороне клиента активизирован плагин для антивирусной проверки корреспонденции). Это, кстати, тот самый вариант, когда Best Practices поставщика оказываются малопригодны в конкретной рабочей среде.

Но иногда проявляются решения, казалось бы, давно устаревшие и не использующиеся. Например, по странному желанию и привычке, у конечного пользователя почтовый ящик Exchange подключен таким образом, что корреспонденция хранится в единственном экземпляре в локальных личных папках. Такой режим доступа правильно называется Remote Mail (средство удаленного доступа) и специально предназначен для того, чтобы при использовании низко скоростного удаленного соединения синхронизировать только папку Входящие с файлом личных папок. Соответственно, у конечного пользователя, который по неким личным причинам предпочитает хранить всю корреспонденцию в файле личных папок, возникает следующая сложность: входящая корреспонденция успешно помечается серверным антиспам фильтром и помещается в папку нежелательной корреспонденции почтового ящика.

Таким образом, со стороны конечного пользователя возникает недопонимание происходящего: растет устойчивое ощущение того, что часть входящей почты теряется, так как что видимая ему папка «нежелательная почта» (Junk mail) столь же пуста, сколь и папка входящих.

А решается, данная проблема недопонимания, собственно, единственным способом: необходимо выключить фильтрацию нежелательной корреспонденции для данного почтового ящика. Для этого достаточно выполнить следующую команду Exchange Management Shell:
set-Mailbox -Identity infobox@libertine.su -SCLJunkEnabled:$false

При этом Outlook конечного пользователя в момент получения с сервера новой корреспонденции успешно разместит всю нежелательную почту в соответствующей папке локального хранилища сообщений.

Например, нам необходимо получить данные о том, каковы текущие размеры всех почтовых ящиков. Нет ничего проще!
От имени учетной записи с достаточными административными привилениями, на любой рабочей станции домена c установленной на оной консолью PowerShell выполняем команду:
Get-WmiObject -ComputerName MyExch2003 -Namespace root\MicrosoftExchangeV2 -Class Exchange_Mailbox | Select MailboxDisplayName, Size -First 10000

Не более сложно получить и предварительно отсортированный по размеру список почтовых ящиков:
Get-WmiObject -ComputerName MyExch2003 -Namespace root\MicrosoftExchangeV2 -Class Exchange_Mailbox | sort size -desc | Select MailboxDisplayName, Size -First 10000

И, наконец, получим список почтовых ящиков, отсортированный по дате последнего отключения от оного, а затем по размеру. Это позволит наглядно увидеть почтовые ящики, которыми уже давно никто не пользуется:
Get-WmiObject -ComputerName MyExch2003 -Namespace root\MicrosoftExchangeV2 -Class Exchange_Mailbox | sort LastLogoffTime, size | Select MailboxDisplayName, Size, LastLogoffTime -First 10000

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

А что, если нам необходимо получить не список ящиков, а параметры ящиков из некоторого списка? Например, Имя / Размер / Хранилище в котором находится почтовый ящик / Последнее время выхода из ящика.
Это тоже несложно: нам понадобиться всего лишь сам список в текстовом формате, та же самая рабочая станция с консолью Powershell и две строки команд:
$BoxesList = Get-Content C:\lists\boxlist.txt
foreach ($boxuser in $BoxesList) {Get-WmiObject -ComputerName MyExch2003 -Namespace root\MicrosoftExchangeV2 -Class Exchange_Mailbox | Where {$_.MailboxDisplayName -like $boxuser} | Select MailboxDisplayName, Size, StoreName, LastLogoffTime}

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

1. Отказ от необходимости создания кластера на уровне ОС. И я бы даже сказал, что производитель очень навязчиво декларирует данный факт. Кстати, да. Учитывая требования к оборудованию (а точнее, к системе хранения данных) для создания кластерных конфигураций на базе server 2008, лично для меня подобная необходимость была бы достаточно неприятна.
2. Возможность размещения любых дополнительных ролей Exchange на любой из нод отказоустойчивого почтового хранилища.

Но дело в том, что на самом деле отказоустойчивый кластер создается. Просто не на уровне операционной системы. А размещение на хранилище дополнительных ролей вовсе на так однозначно. Что все это значит? Рассмотрим дальше.

1. На два сервера объединенные в кластер была установлена роль mailbox store. При этом один из серверов мог быть заведомо слабее, т.к. выполнял исключительно функцию аварийного резерва.
2. Роли транспортного сервера и сервера клиентского доступа были установлены на единственный сервер, защищенный от аппаратных сбоев путем помещения внутри отказоустойчивой виртуальной машины.
3. Для защиты от вирусов и спама, был установлен отдельный релей на базе свободного ПО. Данное решение значительно снижает нагрузку на транспортный сервер Exchange, не требуя при этом дополнительных лицензий для сервера с ролью Edge Transport.
4. Для защиты от DDoS атаки на сервер клиентского доступа, данный сервер был опубликован через ISA сервер. Что, кстати, дополнительно значительно снижает нагрузку за счет кэширования и возможности отключения шифрования между внутренним интерфейсом ISA и интерфейсом CAS сервера (разумеется, нешифрованный трафик между серверами категорически рекомендуется передавать исключительно через выделенный VLAN).

1. Абсолютно все подключения теперь будут проходить через CAS сервер. Что автоматически означает необходимость его существенной производительности.
2. Размещение дополнительных ролей на одном из серверов хранилища почтовых ящиков — это замечательно (особенно, когда есть запас производительности). Но необходимо хорошо себе представлять тот факт, что в этом случае необходимо размещение тех же самых ролей на любом другом сервере и создания NLB кластеров для получения отказоустойчивости. Надеюсь, как работает NLB unicast и в чем особенность NLB multicast при доступе к нему через роутер, все хорошо понимают и недоразумений при настройке ни у кого возникать не будет
3. Поскольку, как я уже отметил, отказоустойчивый кластер на самом деле создается, честь и хвала тому, что сможет на тех же самых нодах поднять NLB. Да, признаю, в предыдущем пункте я именно издевался, разглагольствуя о режимах работы NLB
4. Да, есть одна особенность: при двух серверах с ролью транспорта, почта между двумя ящиками одной почтовой базы всегда будет доставляться через второй сервер транспорта — это особенность новой архитектуры и ее необходимо иметь в виду. Транспорт совершит локальную доставку только в случае недоступности стороннего партнера, и что-то мне подсказывает, что доступность проверяется отнюдь не запросом к smtp порту, а обычным icmp. Надеюсь, система контроля статуса критических сервисов всех серверов настроена у всех?
5. Резервное копирование и удобство восстановления лучше даже не упоминать, если совершенно случайно нигде не завалялось лицензии на DPM (Data Protection Manager). Впрочем, возможность создания «отсроченной» (lagged database) копии средствами самого Exchange, несомненно, существенно снимает ряд проблем.

Для начала, получим список всех существующих почтовых ящиков для перемещенных пользователей. Для этого запустим Exchange Management Shell (PowerShell) и выполним простенькую команду:
get-mailbox -organizationalUnit «libertine.su/Disabled Users»

По сути, нам это не дало ничего нового. Кроме того, что всего лишь перенаправив вывод данной команды на вход следующей, мы можем моментально решить вопрос с адресной книгой.
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | set-Mailbox HiddenFromAddressListsEnabled:$true
Все, мы только что отключили отображение в адресной книге имен всех пользователей, перемещенных в OU Disabled Users.

Теперь осталось понять, можем ли мы как-то сократить количество ящиков, занимающих место в почтовом хранилище.
Но для начала, выведем список всех учетных записей, имеющих доступ к ящикам в заданном контейнере:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Get-MailboxPermission | Format-List
Предупреждаю, на выходе будет очень длинная простыня Поэтому, вывод целесообразно было бы перенаправить в тестовый файл и далее работать уже с ним.

Поскольку нам нет резона тратить массу времени на тщательную вычитку доступов для каждого ящика, целесообразно выбрать любой и на его основе написать фильтр, существенно облегчающий дальнейшие задачи. Нам необходимо для каждого ящика получить список доступа, исключая доступ администраторов, серверов и самого титульного пользователя. Конечный сценарий может выглядеть примерно следующим образом:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Get-MailboxPermission | Where {($_.user -notlike «LIBERTINE\admin») -and ($_.user -notlike «LIBERTINE\Exchange View-Only Administrators») -and ($_.user -notlike «LIBERTINE\Exchange Organization Administrators») -and ($_.user -notlike «LIBERTINE\Exchange Servers») -and ($_.user -notlike «LIBERTINE\Exchange Domain Servers») -and ($_.user -notlike «LIBERTINE\Exchange Services») -and ($_.user -notlike «LIBERTINE\Exchange Public Folder Administrators») -and ($_.user -notlike «NT AUTHORITY\NETWORK SERVICE») -and ($_.user -notlike «LIBERTINE\Exchange Organization Administrators») -and ($_.user -notlike «LIBERTINE\Domain Admins») -and ($_.user -notlike «LIBERTINE\Enterprise Admins») -and ($_.user -notlike «LIBERTINE\SECLMAIL$») -and ($_.user -notlike «LIBERTINE\FRSTCLMAIL$») -and ($_.user -notlike «NT AUTHORITY\SELF») -and ($_.user -notlike «LIBERTINE\superoot»)} | Format-List Identity, user

Замечательно, факт наличия доступа мы определили. Но пользуются ли им? Для этого введем дополнительное условие отбора: определим ящики, в которые не смотрели последние 70 дней (но смотрели когда-либо вообще).
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Get-MailboxStatistics | Where {($_.LastLogonTime -lt (get-date).adddays (-70)) -and ($_.LastLogonTime -gt (get-date).adddays (-900))}| Get-MailboxPermission | ...

Впринципе, для завершения расследования происходящего, осталось лишь определить ящики, с которых стоит пересылка корреспонденции. Разумеется, с выводом ящика и адрес для пересылки.
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Where {$_.ForwardingAddress -ne $null} | Format-List DisplayName,ForwardingAddress

Комбинируя вышеперечисленные команды, можно, например, легко вывести прямых кандидатов на превращение старого почтового ящика в дополнительный smtp адрес для ящика ныне работающего сотрудника. Кстати, в этом примере рекомендую обратить внимание на двойное использование команды get-mailbox:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Where {$_.ForwardingAddress -ne $null} | Get-MailboxStatistics | Where {($_.LastLogonTime -lt (get-date).adddays (-70)) -and ($_.LastLogonTime -gt (get-date).adddays (-900))} | get-mailbox | Format-List DisplayName,ForwardingAddress

Да, и еще: старые ящики, даже если ими периодически пользуются, рекомендуется перенести в отдельную почтовую базу, т.к. это даст определенный выигрыш в скорости доступа для активных пользователей. После создания самой новой базы почтовых ящиков, остальное сделать несложно:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Move-Mailbox -TargetDatabase «OldMailboxesDB»

Главное, при переносе помнить о том, что в Exchange 2007 процесс совершается от имени администратора путем последовательного копирования всех сообщений. То есть, время последнего доступа к ящику будет установлено в текущее.

• Выбирается доменный пользователь, максимально схожий по должности с принимаемым на работу
• Путем копирования создается новый доменный пользователь
• Для нового пользователя заводится почтовый ящик и т.д.

Какие типовые сценарии обычно выполняются при увольнения сотрудника:

1. Для учетной записи пользователя меняется пароль.
2. • к почтовому ящику увольняющегося пользователя дается доступ сотруднику, принимающему дела
   • вся деловая переписка архивируется и архив затем подключается к почтовому клиенту сотрудника, принимающего дела увольняющегося коллеги
3. • с почтового ящика увольняющегося пользователя ставится пересылка всей входящей корреспонденции на адрес коллеги, принимающего дела
   • почтовый smtp адрес переназначается с ящика увольняющегося сотрудника на ящик сотрудника, принимающего дела

Причем, надо отметить, если при приеме на работу, в целом, сценарии всегда одинаковы. То при увольнении могут отличаться совершенно разительно. Это может быть обусловлено необходимость дать доступ к архиву почты нескольким пользователям, что порождает действия, противоречащие обычному регламенту. А может быть обусловлено и простым отсутствием самих четких регламентов.

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

При этом, вполне разумно, что хотелось бы ограничить видимость данных учетных записей. Как в адресной книге почтового клиента, так и в общем списке доступа в домене. Ну в самом деле, непорядок, что при каждом назначении прав на объект среди пользователей и групп домена видны записи, которым заведомо уже давно ничего не нужно.

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

Например, для того, чтобы понять, кто из пользователей, находящихся в OU marketing не входил в сеть в течении 6 недель, необходимо выполнить следующий запрос:
'dsquery user «ou=marketing,dc=libertine,dc=su» -inactive 6 -limit 0'

Можно, конечно, точно также сделать запрос о просроченных паролях на вход.
'dsquery computer «ou=marketing,dc=libertine,dc=su» -stalepwd 61 -limit 0'
Но это даст очень много ложных срабатываний, если в домене нет ограничения на срок действия пароля пользователя. Или же персонально для какой-либо учетной записи задано свойство «password newer expires». Поэтому предыдущий способ все же надежнее.

Ок, предположим, мы получили список записей о пользователях домена, которые давным давно не выполняли вход. Но что нам это дает?

• Если к ящику пользователя для кого-либо назначен доступ, удалять данную учетную запись нельзя
• Если к ящику пользователя кому-либо дан доступ, но это уже давно не актуально, запись пользователя можно удалить
• Если в организации используется какая-либо система, хранящая некие данные, основанные на доменных записях пользователей (например, CRM), удалять учетную запись пользователя крайне нежелательно.

Ладно, предлагаю решать проблемы по порядку.
Для начала предлагаю перенести все записи неактивных пользователей в отдельный OU. Для этого создадим новый OU old users в корне домена и этого напишем командный сценарий:
@echo off
for /F «delims=» %%a in ('dsquery user «ou=marketing,dc=libertine,dc=su» -inactive 6 -limit 0') dsmove %%a -newparent «ou=old users,dc=libertine,dc=su»
pause

Теперь если для данного OU мы не разрешим получать список (листинг содержимого) данного OU никому, кроме контроллеров домена, почтовых серверов и учетных записей администраторов предприятия, то получим ровно ожидаемый эффект.
Таким образом, обычный пользователь домена при запросе к LDAP серверу (например, в диалоге назначения прав на некий объект) не получит в общем списке пользователей домена указанные записи уволенных пользователей.
Одновременно, нет никаких проблем для пересылки входящей корреспонденции или работы с ранее подключенными почтовыми ящиками уволенных пользователей (т.к. права на чтение содержимого вышеуказанного OU есть у всех).

А продолжение я напишу в следующем посте