none
disable mailbox. Членство в группах RRS feed

  • Общие обсуждения

  • Добрый день.

    Есть группа распространения, включающая в себя пользователей с почтовыми ящиками.

    После того, как делаешь ящику disable, у него удаляются все почтовые атрибуты, ящик помечается на удаление, а вот пользователь с ним связанный по-прежнему остается в группе рассылки, хотя уже и не имеет e-mail адреса.

    Если при отправке через MAPI пользователь в  Outlook делает раскрытие этой группы и производит отправку, то в ответ получает NDR связаный с отключенным пользователем.

    Я уже не говорю про кучу user'ов в составе групп распространения.

    Нехорошо как-то получается.

    Как вы выходите из этой ситуации или это у меня только одного лыжи не едут?


    MCP,MCTS

    23 июля 2012 г. 12:39

Все ответы

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

    23 июля 2012 г. 14:09
  • 1. обычно disable делают когда сотрудников увольняют

    2. я например банально удаляю сотрудника из всех групп

    1. Ну да. Это что-то меняет в нашем случае? :)

    2. Согласитесь как-то это не Enterprise. А если администраторов почтовой системы с правами recipient management около десятка и далеко не все настолько добросовестны и квалифицированы? А если руководство через пару дней после увольнения или перевода сотрудника решило предоставить ему возможность поработать еще недельку всех ранее выданных прав на ресурсы, а членство в группах уже подчищено?

    Проверял уже на трех независимых почтовых системах Exchange: такой косяк (или фича) во всех них имеет место быть.

    Можно даже проще сделать: добавить в группу рассылки (группу безопасности по совместительству) обычного пользователя (recipient type - user). В Outlook в поле "To" раскрыть группу. И тут, к гадалке не ходи, получишь mailtips с соответствующим предупреждением.

    Все очень печально. Не ожидал, что придется подчищать за Exch такие косяки. Скрипт удаления из групп, опять же, как я уже писал, не панацея.


    MCP,MCTS

    23 июля 2012 г. 20:02
  • Зачем делать в Outlook раскрытие?

    Сазонов Илья http://isazonov.wordpress.com/

    24 июля 2012 г. 5:54
    Модератор
  • Ряд сотрудников используют этот механизм. Я не могу им это запретить.

    MCP,MCTS

    24 июля 2012 г. 6:08
  • Запретить не можете, но объяснить, что так не надо делать можете.

    Сазонов Илья http://isazonov.wordpress.com/

    24 июля 2012 г. 6:52
    Модератор
  • Запретить не можете, но объяснить, что так не надо делать можете

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

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


    MCP,MCTS

    24 июля 2012 г. 9:22
  • Считаю вообще неприемлемым тот факт, что пользователи в Outlook могут по-прежнему видеть в составе групп рассылок давно уволенных сотрудников с отключенными ящиками или. после этого начинаются звонки с претензиями и т.д. и т.п.


    MCP,MCTS

    Я тоже считаю неприемлимым такой факт =) Это косяк отдела кадров, но никак не системного администратора.

    В качестве костыля - http://eightwone.com/2011/05/24/disabling-distribution-group-expansion-in-outlook/. Можно отключить функцию раскрытия групп в Outlook.
    24 июля 2012 г. 9:25
  • средствами exchange выкидывать уволенных из групп само собой нельзя, и никто это реализовывать не станет, потому как откуда exchange узнает уволен сотрудник или нет? ведь в группу можно включить не только mailbox user, но и contact, и mailuser у которых тоже нет ящиков. поэтому следить за этим должны account managers или админы. если надо автоматизировать то можно написать скрипт который будет с уволенным сотрудником делать все что надо: из групп чистить, доступы закрывать, ящики удалять, из lync, ocs и прочих систем убирать и т.д.

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

    24 июля 2012 г. 10:21
  • Я тоже считаю неприемлимым такой факт =) Это косяк отдела кадров, но никак не системного администратора.

    А причем здесь OK?

    Отключение раскрытия - не выход.


    MCP,MCTS

    24 июля 2012 г. 10:22
  • А причем здесь OK?

    Отключение раскрытия - не выход.


    MCP,MCTS


    Отдел кадров отвечает заа процедуру увольнения сотрудника. Если процедура до конца не прописана (как в вашем случае) - это косяк отдела кадров.
    24 июля 2012 г. 10:48
  • Отдел кадров отвечает заа процедуру увольнения сотрудника. Если процедура до конца не прописана (как в вашем случае) - это косяк отдела кадров.

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

    Мы вообще не в ту степь с вами пошли. Вопрос чисто технический: почему почтовые клиенты воспринимают и отображают в группах распространения пользователей без "почтовых" атрибутов?

    Это может ввести (и вводит) в заблуждение сотрудников организации.


    MCP,MCTS

    24 июля 2012 г. 11:23
  • Осталось в процедуру добавить удаление из всех групп рассылок - это решит проблему.

    24 июля 2012 г. 11:41
  • Осталось в процедуру добавить удаление из всех групп рассылок - это решит проблему.


    Я уже писал, почему для меня это не подходит. (мой 2-ой пост)

    MCP,MCTS

    24 июля 2012 г. 12:00
  • Вы пытаетесь решить административную проблему техническими средствами. Обычно такие проблемы техническими средствами плохо решаются.

    24 июля 2012 г. 12:07
  • Вы пытаетесь решить административную проблему техническими средствами. Обычно такие проблемы техническими средствами плохо решаются.

    Я не считаю этот вопрос чисто административным. Дальнейшее обсуждение в таком ключе не принесет ровным счетом ничего.

    Надо признать - такая особенность(фича) в Exchange существует как данность и для рада организаций она может оказаться достаточно неприятной.


    MCP,MCTS

    24 июля 2012 г. 12:28
  • это особенность не только exchange, а любых продуктов где используются группы - если учетку из группы не удалять то она там будет присутствовать и никуда не денешься.

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

    выше все верно написали, это чисто административный/организационный вопрос: должны быть процедуры приема, увольнения, перевода и т.д. и эти процедуры должны выполняться и контроллироваться, вручную или автоматически.

    24 июля 2012 г. 19:21
  • 1. это особенность не только exchange, а любых продуктов где используются группы - если учетку из группы не удалять то она там будет присутствовать и никуда не денешься.

    2. а удалять из всех групп (а не только рассылки) учетку при увольнении хорошая практика ...

    3. выше все верно написали, это чисто административный/организационный вопрос: должны быть процедуры приема, увольнения, перевода и т.д. и эти процедуры должны выполняться и контроллироваться, вручную или автоматически.

    1. Безусловно будет присутствовать, но должен ли он, не имея почтовых атрибутов, отображаться в группах рассылки, именно в почтовом клиенте. Не в ADUC не в EMC а еще раз подчеркиваю в почтовом клиенте. Пользователь же не может выбрать в качестве получателя обычную учетку AD. Здесь срабатывает своего рода механизм обеспечения валидности получателя. В случае с раскрытием DG такого не происходит. Причем появившийся mailtips гласит о том, что адрес получателя "потерял свою актуальность" . Ерунда! Да его и не было никогда. Я просто добавил объект USER в соответствующую группы безопасности.

    Некрасиво получается.

    2. Возможно, но, например, нам на данном этапе она не подходит.

    3. Не все так просто. Абстрагируйтесь вы наконец от административной составляющей. Мы - технические специалисты и должны смотреть на вопрос в первую очередь с технической точки зрения, отталкиваясь от требований бизнеса, а не пытаться научить "правильно" работать другие службы организации.


    MCP,MCTS

    24 июля 2012 г. 19:51
  • Вариан решения.

    1. Экспортируем список груп в которые входит пользователь в текстовый файл.

    $_users = Get-ADUser -Filter * -Properties *
    foreach($_user in $_users){
      $_user.samaccountname
      $_user.givenname " " $_user.surname
      foreach($_group in $_user.memberof){
        (get-adgroup $_group.tostring())
        }
        " "
        " "
      }

    Или вот этот.

    DSGET user -name * -limit 0 | dsget user -memberof > c:\user_date.txt

    2. Проверяем файл. Удаляем пользователя со всех групп в которые входит, дизейблим учетку.

    3. Текстовый файл именуем пользователем датой и в архив.

    Скрипт тестируйте в тестовой среде.


    MCITP. Знание - не уменьшает нашей глупости.

    24 июля 2012 г. 20:23
    Модератор