Разрешение на полный доступ к ящику
 

Случайно заметил, что у некоторых ящиков по умолчанию в числе учетных записей, имеющих к нему полный доступ, помимо NT AUTHORITY\SELF стоит MYDOMAIN\Exchange Servers, MYDOMAIN\Exchange Trusted Subsystem, NT AUTHORITY\система. У других же стоит только NT AUTHORITY\SELF. Скриншот прикрепил. Почему так могло получиться и чем может грозить?

Еще хотелось бы узнать, что случается с ящиком, когда я удаляю пользователя из Active Directory с помощью оснастки "Active Directory - Пользователи и компьютеры"? Ящик автоматом тоже удаляется или как?

это вроде когда пользователь ещё ни разу не воспользовался почтовым ящиком, т.е. не произвёл вход в него.
создайте тестовую учётную запись - узнаете опытным путём :)

exo, насчет первого вопроса - да, так оно и есть.
Создал, грохнул - ящик исчез из списка ящиков в графической консоли Exchange (еще до того, как сюда написал). Мне теперь интересно, ящик после таких манипуляций корректно удалился или где-то подвис и просто не виден. В отключенных тоже нет.

Нет. Это Well Known SID для идентификации самого объекта. На всех ящиках разрешения даны именно ему. SID берется из контекста связанного с ящиком объекта типа User Account. Другими словами Full Access по умолчанию разрешен только владельцу ящика.Во-первых, если ящик не был инициализирован (в него не выполнялся вход или не поступала почта) - в базе его просто нет. Он создается именно при инициализации.
Во-вторых, ящик появляется в отключенных только после прохождения по базе специального сервиса (некий аналог Garbage Collector), который находит бесхозные элементы и помечает их, как удаленные. Чтобы форсировать этот процесс, достаточно запустить Clean-MailboxDatabase

Oleg Krylov, в ящик я заходил и там было несколько тестовых писем. Прогнал Clean-MailboxDatabase testdb, в отключенных ничего не появилось. Надо думать, сам ящик удалился при удалении учетки?
Немного оффтопа.
Т.е. в этой ситуации пользователь не сможет присоединиться к нему почтовым клиентом, используя POP3/IMAP?

Надо посмотреть в настройки Retention в свойствах базы. по умолчанию удаленный ящик хранится 30 дней, если настройки менялись - возможно это причина.
Ну и далее повышать уровень диагностики на ESE и службы Database Management и смотреть в Application Log на сервере с базой.
Может. Этот первый логон любым разрешенным клиентом и будет триггером для инициализации.

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

Зависит... Надо смотреть код ошибки на устройстве, возможно проблема с правами учетной записи на собственные аттрибуты. Если HTTP 500, например получает.

Нет, настройки для базы я не менял.
В принципе, мне интересно, не может ли так получиться, что удалим уволившегося сотрудника способом, который я описал, а его ящик размером в несколько гигабайт будет болтаться в базе? Или механизм очистки Exchange все равно его удалит через некоторое время?

Oleg Krylov, ещё вспомнил. Если пользователь ни разу не входил в почтовый ящик, то его не увидит программа для резервного копирования ArcServe.
Собственно по той же причине - видеть то нечего, т.к. ящик не создался )

Ну а зачем ей его видеть? Бэкапить все равно нечего :)
Будет. Те самые 30 дефолтных дней. Потом удалится.

так я для настройки. хотел показать руководству программу в действии в тестовом домене. т.к. она умеет бекапить отдельные письма или папки. Хотел показать дерево "каталогов" пользовательского ящика.
так же при настройках Exchange по умолчанию, данная программа делала одновременный бекап только для 5 почтовых ящиков, пока случайно не узнал что нужно настраивать New-ThrottlingPolicy для пользователя, под которым подключается ArcServe.