Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Ещё как упустил :) 11.02.11 03:03 Число просмотров: 7867
Автор: AlexD <Alexander> Статус: Member
|
У показанных тобой настроек - самый низкий приоритет из возможных.
Если я правильно помню документацию ещё со времен Win2k (советую почитать:) ), то порядок применения интересующих тебя параметров такой:
1) настройки на твоём скрине;
2) настройки из профиля пользователя;
3) GP в стандартном порядке (LSDOU).
Принцип тот же, что и с GP: тот, кто применяется позже - перекрывает предыдущих. Естественно, что перекрываются только настройки с "непустыми" значениями.
Поэтому для твоей задачи (исходим из принципа минимальных затрат труда:) ):
1) задаем настройки локально на сервере (в tsconfig.msc - то, что у тебя на скрине) для "всех остальных групп", т.е. это будут настройки для всех, кому явно не определено другое.
2) создаём новый GPO, в котором определяем настройки для группы "Х". В разрешениях на него даем право "Apply policy" только группе "Х" (смотри, не снеси право на его чтение у админов и компов домена; вообще, права на чтение лучше оставь, какие есть).
|
|
<sysadmin>
|
Win2K8 R2 Terminal Server - настройка продолжительности сеансов и мультисессий 03.02.11 11:42
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
Отредактировано 03.02.11 17:49 Количество правок: 2
|
Отредактировал, яснее:
надо:
1)
//////////////////////////////////////////////////////////////////////////////////////////////
отключение сеанса (актвный/простаивание)
для х группы - - никогда
остальным группам 1 день
завершение сеанса (актвный/простаивание)
для х группы - - никогда
остальным группам 1 день
Мультисессии к "своему" сеансу
разрешить для х группы;
остальным группам 1сессия к 1сеансу;
////////////////////////////////////////////////////////////////////////////////////////////////
Сейчас на сервере настройка как в скриншоте по ссылке.
Я так понимаю что пока настройка как на скриншоте, - Групповая Политика подавляется .
Мой вывод - снять все отметки переопределения на сервере, и настроить Групповую Политику как указано выше 1).
Или что-то я упустил?
http://img13.imageshack.us/i/termssh.jpg/
|
|
Ещё как упустил :) 11.02.11 03:03
Автор: AlexD <Alexander> Статус: Member
|
У показанных тобой настроек - самый низкий приоритет из возможных.
Если я правильно помню документацию ещё со времен Win2k (советую почитать:) ), то порядок применения интересующих тебя параметров такой:
1) настройки на твоём скрине;
2) настройки из профиля пользователя;
3) GP в стандартном порядке (LSDOU).
Принцип тот же, что и с GP: тот, кто применяется позже - перекрывает предыдущих. Естественно, что перекрываются только настройки с "непустыми" значениями.
Поэтому для твоей задачи (исходим из принципа минимальных затрат труда:) ):
1) задаем настройки локально на сервере (в tsconfig.msc - то, что у тебя на скрине) для "всех остальных групп", т.е. это будут настройки для всех, кому явно не определено другое.
2) создаём новый GPO, в котором определяем настройки для группы "Х". В разрешениях на него даем право "Apply policy" только группе "Х" (смотри, не снеси право на его чтение у админов и компов домена; вообще, права на чтение лучше оставь, какие есть).
|
| |
Админ безумный, говорит что то, что я хочу вообще невозможно... 11.02.11 18:21
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
Отредактировано 11.02.11 18:22 Количество правок: 1
|
> У показанных тобой настроек - самый низкий приоритет из
> возможных.
> Если я правильно помню документацию ещё со времен Win2k
> (советую почитать:) ), то порядок применения интересующих
> тебя параметров такой:
> 1) настройки на твоём скрине;
> 2) настройки из профиля пользователя;
> 3) GP в стандартном порядке (LSDOU).
>
> Принцип тот же, что и с GP: тот, кто применяется позже -
> перекрывает предыдущих. Естественно, что перекрываются
> только настройки с "непустыми" значениями.
>
> Поэтому для твоей задачи (исходим из принципа минимальных
> затрат труда:) ):
> 1) задаем настройки локально на сервере (в tsconfig.msc -
> то, что у тебя на скрине) для "всех остальных групп", т.е.
> это будут настройки для всех, кому явно не определено
> другое.
> 2) создаём новый GPO, в котором определяем настройки для
> группы "Х". В разрешениях на него даем право "Apply policy"
> только группе "Х" (смотри, не снеси право на его чтение у
> админов и компов домена; вообще, права на чтение лучше
> оставь, какие есть).
Админ безумный, говорит что то, что я хочу вообще невозможно =)
Судя по твоему ответу я думаю может лучше мне у себя в HKCU на этом сервере подправить политику и делов? Мне надо только себе политику отличную от скрина настроить. Права локальные админа есть у меня. Политика эта не переопределяется сейчас вообще. Так что по идее перезаписаться не должно.
|
| | |
Да всё ещё интереснее, на самом деле 12.02.11 22:45
Автор: AlexD <Alexander> Статус: Member
|
> Админ безумный, говорит что то, что я хочу вообще
> невозможно =)
> Судя по твоему ответу я думаю может лучше мне у себя в
> HKCU на этом сервере подправить политику и делов? Мне надо
> только себе политику отличную от скрина настроить. Права
> локальные админа есть у меня. Политика эта не
> переопределяется сейчас вообще. Так что по идее
> перезаписаться не должно.
1) В одном маленьком моменте он прав - параметр "по одной сессии на юзера". Он задаётся только на уровне компьютера. Т.е. с ним штатными средствами сделать так, как ты хочешь, не выйдет. Тут будет либо для всех 1 сессия (а чем тебя-то это не устраивает?), либо для всех сколько угодно.
Если админ будет упорствовать и про остальное - то можно ставить вопрос о его профпригодности:).
Но тут есть другая сторона вопроса - на месте админа я бы тоже был против создания GPO лишь ради одного пользователя (т.е. тебя), если ты, конечно, не CEO компании или типа того:). Ну или только в случае, если есть обоснованная производственная необходимость (в чём я сомневаюсь:) ).
2)По поводу правки HKCU: а вот проверь - я как-то совсем недавно наткнулся в семерке на такой эффект, что при входе параметры, не определённые в политике, вычищались из реестра.
Блин, что-то порывшись на сайте MS, обнаружил, что я слегка сам напутал:).
Настройки из свойств пользователя и из tscc.msc надо поменять местами в списке. Т.е. настройки через tscc.msc более приоритетные, чем настройки конкретного пользователя.
Поэтому если система тебе не даст просто так играться с параметрами в HKCU, то я вижу лишь один нормальный вариант: задать локальную политику "только для администраторов" тебе на твоём компе, и в ней определить эти параметры. Речь идёт о множественных локальных политиках - это появилось начиная с висты.
|
| | | |
Очень странно - зачем тогда это позволено в редакторе ГП... 13.02.11 18:51
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
Отредактировано 13.02.11 19:03 Количество правок: 3
|
> 1) В одном маленьком моменте он прав - параметр "по одной
> сессии на юзера". Он задаётся только на уровне компьютера.
> Т.е. с ним штатными средствами сделать так, как ты хочешь,
> не выйдет. Тут будет либо для всех 1 сессия (а чем тебя-то
> это не устраивает?), либо для всех сколько угодно.
> Если админ будет упорствовать и про остальное - то можно
> ставить вопрос о его профпригодности:).
Очень странно - зачем тогда это позволено в редакторе ГП настраивать?
( Политика :
КомпонентыВиндоус/Службы терминалов/Сеансы/РазрешатьПереподключениеТолькоОтОдногоКлиента
Указывает, могут ли пользователи переподключаться к отключенному сеансу служб терминалов, используя другой компьютер (не тот, с которого был начат сеанс).
Используя этот параметр, можно предотвратить переподключение пользователей служб терминалов к отключенным сеансам с другого компьютера (не с того, с которого был начат сеанс). По умолчанию службы терминалов позволяют пользователям переподключаться к отключенным сеансам с любого компьютера.
)
Только тут не совсем понятно что подразумевается под "отключенным сеансом" если к нему идет "переподключение".
>
> Но тут есть другая сторона вопроса - на месте админа я бы
> тоже был против создания GPO лишь ради одного пользователя
> (т.е. тебя), если ты, конечно, не CEO компании или типа
> того:). Ну или только в случае, если есть обоснованная
> производственная необходимость (в чём я сомневаюсь:) ).
Я кодер, и системный архитектор. Мне надо чтобы сессия не дропалась(не надо было дропать мне при уходе) на работе если я подключаюсь из дома. Тоесть вдруг я забыл на работе завершить сеанс, и все, из дому ничего не сделаешь, а к новому сеансу получиться рассинхронизация кода, не дай бог, либо убивать открытое без сохранение что равносильно. Короче к 1му и тому же виндоустэйшену надо. Там свны всякие не прикручиваются.
Я на новой группе, как ты видишь, и не настаиваю, избыточность ни к чему, минимализм.
>
> 2)По поводу правки HKCU: а вот проверь - я как-то совсем
> недавно наткнулся в семерке на такой эффект, что при входе
> параметры, не определённые в политике, вычищались из
> реестра.
>
> Блин, что-то порывшись на сайте MS, обнаружил, что я слегка
> сам напутал:).
> Настройки из свойств пользователя и из tscc.msc надо
> поменять местами в списке. Т.е. настройки через tscc.msc
> более приоритетные, чем настройки конкретного пользователя.
>
> Поэтому если система тебе не даст просто так играться с
> параметрами в HKCU, то я вижу лишь один нормальный вариант:
> задать локальную политику "только для администраторов" тебе
> на твоём компе, и в ней определить эти параметры. Речь идёт
> о множественных локальных политиках - это появилось начиная
> с висты.
По поводу HKCU - у всех по дефолту стоит политика с валпейпером холдинга, я у себя в HKCU ее как убрал (привык к черному экрану), до сих пор нету, сеансы уже сто раз перезапускал. Сервак правда не перезагружали вроде. Да, с декабря.
|
| | | | |
Вот в этом-то "непонятно" и дело:). Это совсем другой... 19.02.11 00:22
Автор: AlexD <Alexander> Статус: Member
|
> > 1) В одном маленьком моменте он прав - параметр "по
> одной
> > сессии на юзера". Он задаётся только на уровне
> компьютера.
> > Т.е. с ним штатными средствами сделать так, как ты
> хочешь,
> > не выйдет. Тут будет либо для всех 1 сессия (а чем
> тебя-то
> > это не устраивает?), либо для всех сколько угодно.
>
> Очень странно - зачем тогда это позволено в редакторе ГП
> настраивать?
> ( Политика :
> КомпонентыВиндоус/Службы
> терминалов/Сеансы/РазрешатьПереподключениеТолькоОтОдногоКли
> ента
> Указывает, могут ли пользователи переподключаться к
> отключенному сеансу служб терминалов, используя другой
> компьютер (не тот, с которого был начат сеанс).
> .....
> Только тут не совсем понятно что подразумевается под
> "отключенным сеансом" если к нему идет "переподключение".
>
Вот в этом-то "непонятно" и дело:). Это совсем другой параметр. Тут идёт речь о следующем: ты делаешь disconnect (отключаешься от сервера), идешь к другому компу, и пытаешься с него подключиться к тому же серверу. Вот этот параметр разрешает подобный сценарий или запрещает. Но (как обычно, есть одно но:) ) в документации я видел упоминание, что этот параметр работает только для Citrix-клиентов (т.е. при установленном XenApp'е, как он нынче у них называется). Никогда не проверял, так ли это. Отсутствовала необходимость:).
> >
> > Но тут есть другая сторона вопроса - на месте админа
> я бы
> > тоже был против создания GPO лишь ради одного
> пользователя
> > (т.е. тебя), если ты, конечно, не CEO компании или
> типа
> > того:). Ну или только в случае, если есть обоснованная
> > производственная необходимость (в чём я сомневаюсь:)
> ).
> Я кодер, и системный архитектор. Мне надо чтобы сессия не
> дропалась(не надо было дропать мне при уходе) на работе
> если я подключаюсь из дома. То есть вдруг я забыл на работе
> завершить сеанс, и все, из дому ничего не сделаешь, а к
> новому сеансу получиться рассинхронизация кода, не дай бог,
> либо убивать открытое без сохранение что равносильно.
> Короче к 1му и тому же виндоустэйшену надо. Там свны всякие
> не прикручиваются.
> Я на новой группе, как ты видишь, и не настаиваю,
> избыточность ни к чему, минимализм.
Ну здрасте, как это ничего не сделаешь? Подключаешься, если попал в другую сессию - самое простое: запускаешь task manager, выбираешь на вкладке Users свою старую сессию и Connect. Потом из старой сессии можно смело прибить ту, куда ты изначально "пришёл" из дома.
Начиная с висты консольная сессия ничем не отличается от остальных (поэтому они теперь нумеруются с 1; в 0-ю пользователи зайти не могут).
Короче, включай всем ограничение в 1 сеанс и живи спокойно. Будешь к своей сессии подключаться откуда угодно. А уходя с работы, просто делай "Switch user" или Lock, если работаешь за консолью.
> >
> > 2)По поводу правки HKCU: а вот проверь - я как-то
> совсем
> > недавно наткнулся в семерке на такой эффект, что при
> входе
> > параметры, не определённые в политике, вычищались из
> > реестра.
> >
> > Блин, что-то порывшись на сайте MS, обнаружил, что я
> слегка
> > сам напутал:).
> > Настройки из свойств пользователя и из tscc.msc надо
> > поменять местами в списке. Т.е. настройки через
> tscc.msc
> > более приоритетные, чем настройки конкретного
> пользователя.
> >
> > Поэтому если система тебе не даст просто так играться
> с
> > параметрами в HKCU, то я вижу лишь один нормальный
> вариант:
> > задать локальную политику "только для администраторов"
> тебе
> > на твоём компе, и в ней определить эти параметры. Речь
> идёт
> > о множественных локальных политиках - это появилось
> начиная
> > с висты.
> По поводу HKCU - у всех по дефолту стоит политика с
> валпейпером холдинга, я у себя в HKCU ее как убрал (привык
> к черному экрану), до сих пор нету, сеансы уже сто раз
> перезапускал. Сервак правда не перезагружали вроде. Да, с
> декабря.
Картинка-картинкой, а с другими параметрами может и не прокатить:). GP состоит из довольно большого количества компонентов, каждый из которых работает по-своему.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
