Прочитал статью, потом комментарии и… вспомнил, что жена давно хотела себе наручные часы, а скоро годовщина свадьбы и вечная проблема с тем, что дарить. Нашел, заказал. Автор, спасибо!
Разобрался. Политика сохранения (Retention Policy) нигде не задана (ни в глобальных настройках, ни в классах обслуживания). При этом у всех ящиков параметр «Время жизни почтового сообщения» выставлен 675. Как оказалось, это значение выставляется по дефолту при создании ящика и было задано бывшими админами в дополнительных настройках в классе обслуживания «default».
Вопрос немного не по теме статьи, но все же. Заметили, что бесплатная Зимбра, которая у нас доживает свои дни в режиме архива, автоматически удаляет из всех ящиков старые письма (ориентировочно — старше двух лет), но так и не нашли, где это настраивается и как можно отключить. Наверно, от скуки начала сама себя пожирать. :) Может, кто сталкивался?
Отслеживание таких гиперактивных пользователей — это уже другая задача. Решение, кстати, тоже есть, но оно выходит за рамки статьи. Возможно, опишу отдельно.
Но если у вас много таких людей, которые параллельно за несколькими машинами работают, возможно, имеет смысл подойти с другой стороны и пересмотреть процессы для них?
Почему Вы так считаете? Задача — оперативно узнать, за какой машиной сейчас работает пользователь, чтобы удаленно подключиться/выполнить диагностику. Сбор истории — это уже другая задача.
И если уж так рассуждать, то почему обязательно на АД садиться?
Описанное в статье решение для тех, кто уже «сидит» на AD, и оно позволяет добавить нужный функционал в уже работающую систему с минимальными трудозатратам. Если же инфраструктура поднимается с нуля, то, конечно, возможны варианты.
ИМХО, называть ПК по имени пользователя — путь в никуда, если у вас много пользователей/ПК и большая текучка кадров. Замучаетесь переименовать и всё равно не уследите в итоге.
складывается впечатление, что в вашей организации много контроллеров без географического разделения (т.е. без необходимости).
Совсем нет. К примеру, 5 площадок с парой DC в каждой.
Что вас пугает в параллельном запуске скриптов на контроллерах?
Я не про параллельный запуск, а вообще про парсинг. Не пугает ничего,, если это не в моей AD творится. :) Парсинг таких логов — ресурсоёмкая операция, и я бы не стал на DC ее запускать. Как Вы планируете это реализовать на практике? Вручную по мере надобности? По расписанию автоматом? За какой период будете смотреть, как и куда выгружать результаты?
Ведь, если не ошибаюсь, то новый логин будет перезаписывать атрибут со старым, но ещё актуальным логином.
Да, всё верно.
пользователь имеет личную машину, но для вывода информации должен приходить со своей флешкой на машину с открытыми USB-портами
Согласен, есть нюансы.
Как вариант. Кладём учётку такой «открытой» машины в отдельный OU, к которому не применяется GPO. В случае проблем на этой машине пользователь сообщает, что, мол, я сейчас не за своим ПК, а за «открытым». Техподдержка со своей стороны видит имя этой машины в ADUC. Либо на самой машине есть наклейка с номером/сетевым именем (если машин несколько).
Идея интересная, но за актуальностью таких наклеек надо следить, что в наших реалиях не всегда возможно. Да и человеческий фактор никто не отменял: компьютеры сотрудникам поменяли, а наклейки забыли.
Командлет Set-ADComputer входит в состав модуля Active Directory для PowerShell и требует наличие установленного модуля на компьютере.
У Вас на всех рабочих станциях ADUC установлен?
VBS-скрипты из моего решения этого не требуют, будут запускаться даже на старых ОС, а скорость выполнения будет значительно выше, чем у их PS-аналогов из Вашей статьи.
И, как я писал выше с статье, вот эта модификация мне не очень нравится:
В первую очередь необходимо делегировать права группе Domain Users (или другой группе безопасности пользователей) на OU с компьютерами на изменение значений в полях объктов типа Computer: ManagedBy и description (Write Description + Write Managed By).
В моём же варианте всё работает «из коробки», со стандартными настройками безопасности.
Интересно взглянуть на Ваши логон/логофф-скрипты для машины. Каким образом машина узнает, кто на ней залогинен с учетом того, что сначала отрабатывает логон-скрипт для машины, а уже потом для пользователя?
Одно это чего стОит.
Осилил только треть статьи и решил посмотреть оригинал.
Вопрос немного не по теме статьи, но все же. Заметили, что бесплатная Зимбра, которая у нас доживает свои дни в режиме архива, автоматически удаляет из всех ящиков старые письма (ориентировочно — старше двух лет), но так и не нашли, где это настраивается и как можно отключить. Наверно, от скуки начала сама себя пожирать. :) Может, кто сталкивался?
«Чую, что дело бесовское, но обосновать не могу». Нет, не пробовал, колитесь, в чем гешефт!
Отслеживание таких гиперактивных пользователей — это уже другая задача. Решение, кстати, тоже есть, но оно выходит за рамки статьи. Возможно, опишу отдельно.
Но если у вас много таких людей, которые параллельно за несколькими машинами работают, возможно, имеет смысл подойти с другой стороны и пересмотреть процессы для них?
Мне показалось удобнее так. Но ничто не мешает сделать с параметрами. Как говорится, на вкус и цвет… все фломастеры разные
Почему Вы так считаете? Задача — оперативно узнать, за какой машиной сейчас работает пользователь, чтобы удаленно подключиться/выполнить диагностику. Сбор истории — это уже другая задача.
Описанное в статье решение для тех, кто уже «сидит» на AD, и оно позволяет добавить нужный функционал в уже работающую систему с минимальными трудозатратам. Если же инфраструктура поднимается с нуля, то, конечно, возможны варианты.
Тяжёлые — это какие, например?
Совсем нет. К примеру, 5 площадок с парой DC в каждой.
Я не про параллельный запуск, а вообще про парсинг. Не пугает ничего,, если это не в моей AD творится. :) Парсинг таких логов — ресурсоёмкая операция, и я бы не стал на DC ее запускать. Как Вы планируете это реализовать на практике? Вручную по мере надобности? По расписанию автоматом? За какой период будете смотреть, как и куда выгружать результаты?
Да, всё верно.
Согласен, есть нюансы.
Как вариант. Кладём учётку такой «открытой» машины в отдельный OU, к которому не применяется GPO. В случае проблем на этой машине пользователь сообщает, что, мол, я сейчас не за своим ПК, а за «открытым». Техподдержка со своей стороны видит имя этой машины в ADUC. Либо на самой машине есть наклейка с номером/сетевым именем (если машин несколько).
Что тут странного? Это стандартное поведение AD.
Еще раз спрошу: Вы пробовали это в продакшне делать в крупной или хотя бы средних размеров организации перед тем, как подобные советы давать?
У Вас на всех рабочих станциях ADUC установлен?
VBS-скрипты из моего решения этого не требуют, будут запускаться даже на старых ОС, а скорость выполнения будет значительно выше, чем у их PS-аналогов из Вашей статьи.
И, как я писал выше с статье, вот эта модификация мне не очень нравится:
В моём же варианте всё работает «из коробки», со стандартными настройками безопасности.
Вы пробовали парсить Security-логи, скажем, для организации, где тысяча пользователей и с десяток контроллеров домена?
И что из этого следует?