none
Добавление ветки реестра для отключения TNEF RRS feed

  • Вопрос

  • Здравствуйте! Потребовалось отключить протокол в Outlook'е - TNEF. И было принято решение, сделать это через правку реестра, как описано здесь: http://support.microsoft.com/kb/958012/ru

    Но проблема в том, что не хочется применять это ко всему домену, а только к OU содержащим пользовательские ПК. Т.е. получается, что учётки находятся в одном месте, а ПК в другом. А изменить нужно HKEY_CURRENT_USER, т.е. проводить какие-либо действия нужно в "User Configuration", а ведь учётные записи находятся за пределами действия этой политики (в другом OU). В GPP есть нацеливание на OU - тоже не подходит, т.к. на старых ОС будет ошибка типо предупреждения, о том, что политика отфильтрована по какому то критерию - уже проходили :) Какие-либо манипуляции в разделе "Computer Configuration" ничего не дают, т.е. нужные значения в реестре не появляются.

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


    MCTS

    29 августа 2012 г. 9:16

Ответы

  • а зачем группа безопасности? примените политику на OU с компьютерами и включите loopback processing

    Ориентируясь на статью Групповая политика: замыкание на себя почему то подумал, что нужно две полиитки: в одной включить политику замыкания, в другой - сами пользовательские настройки, ну и + где то когда то вычитал, что выставлять настройки в двух разделах сразу не очень хорошо. Поэтому как то и не проверил этот вариант сразу. Проверил - всё заработало:


    MCTS


    • Изменено Раймонд 29 августа 2012 г. 13:21
    • Помечено в качестве ответа AndricoRusEditor 29 августа 2012 г. 13:21
    29 августа 2012 г. 13:19
  • а зачем группа безопасности? примените политику на OU с компьютерами и включите loopback processing

    • Помечено в качестве ответа Раймонд 29 августа 2012 г. 13:20
    29 августа 2012 г. 13:05
    Модератор

Все ответы

  • немного не понял, а что мешает вам использовать политику для учётных записей пользователей (для чего собственно она изначально и задумывалась)? или я не полностью усвоил условия задачи?
    29 августа 2012 г. 9:25
    Отвечающий
  • немного не понял, а что мешает вам использовать политику для учётных записей пользователей (для чего собственно она изначально и задумывалась)? или я не полностью усвоил условия задачи?

    Кто то кого то точно не понял :) Политика учётных записей работает при условии же, когда эта политики попадает под влияние именно этой учётки,  т.е. политики применяется к OU в которой эта учётка присутствует. У меня же иная ситуация: применить нужно к OU с рабочими станциями отредактировав раздел "User Configuration", в то время, когда учётка находится в стандартном контейнере "Users", т.е. за пределами действия политики.

    MCTS

    29 августа 2012 г. 10:38
  • Политика учётных записей работает при условии же, когда эта политики попадает под влияние именно этой учётки,  т.е. политики применяется к OU в которой эта учётка присутствует. У меня же иная ситуация: применить нужно к OU с рабочими станциями отредактировав раздел "User Configuration", в то время, когда учётка находится в стандартном контейнере "Users", т.е. за пределами действия политики
    Хорошо, давайте тогда с другой стороны: если вам нужно отсечь, допустим, терминальные сервера, на которые ходят пользователи - вы можете настроить loopback processing и сделать группу, в которую поместите только сервера и запретите этой группе применение политики с настройками. Или как вы указали наоборот - можете все нужные раб. станции поместить в группу, которой разрешить. При этом политику вы можете привязать спокойно и на верхний уровень, если у вас будут фильтры по группам безопасности - на скорость отработки это никак не повлияет. Если у вас нет терминалов - спокойно назначайте на OU с пользователями и тогда применяться будет везде, куда входят пользователи - в их профилях. Вариантов масса.
    29 августа 2012 г. 10:51
    Отвечающий
  • Хорошо, давайте тогда с другой стороны: если вам нужно отсечь, допустим, терминальные сервера, на которые ходят пользователи - вы можете настроить loopback processing и сделать группу, в которую поместите только сервера и запретите этой группе применение политики с настройками. Или как вы указали наоборот - можете все нужные раб. станции поместить в группу, которой разрешить. При этом политику вы можете привязать спокойно и на верхний уровень, если у вас будут фильтры по группам безопасности - на скорость отработки это никак не повлияет. Если у вас нет терминалов - спокойно назначайте на OU с пользователями и тогда применяться будет везде, куда входят пользователи - в их профилях. Вариантов масса.


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

    MCTS

    29 августа 2012 г. 11:53
  • а зачем группа безопасности? примените политику на OU с компьютерами и включите loopback processing

    • Помечено в качестве ответа Раймонд 29 августа 2012 г. 13:20
    29 августа 2012 г. 13:05
    Модератор
  • а зачем группа безопасности? примените политику на OU с компьютерами и включите loopback processing

    Ориентируясь на статью Групповая политика: замыкание на себя почему то подумал, что нужно две полиитки: в одной включить политику замыкания, в другой - сами пользовательские настройки, ну и + где то когда то вычитал, что выставлять настройки в двух разделах сразу не очень хорошо. Поэтому как то и не проверил этот вариант сразу. Проверил - всё заработало:


    MCTS


    • Изменено Раймонд 29 августа 2012 г. 13:21
    • Помечено в качестве ответа AndricoRusEditor 29 августа 2012 г. 13:21
    29 августа 2012 г. 13:19