Применять правило (вместе с целой политикой) на OU, в котором есть рабочие станции, а терминальный сервер посадить в другой OU. Вообще, OU - хорошее средство разделения пользователей и компьютеров по ролям, правда, древовидное, а не областное, но для областного есть группы.
Да, хочу ходить по сертификатам user@domain1.ru в домен domain2. Для этого добавил в domain2 суффикс domain1.ru, присвоил его учеткам, от которых получил сертификаты на смарт-карту, привесил на них сертификаты УЦ, и вроде как этого достаточно. Вот и интересует, где косяк, если отдельно по сертификату авторизация выполняется, если подсунуть user hint.
Кирилл: нет прав - надо добыть. Иначе получается вмешательство в нормально работающую инфраструктуру. Имхо это уже административная задача, тем более если администратор домена не вы.
Скорее всего это проблемы (?) почтового клиента, который не желает по умолчанию показывать картинки со сторонних сайтов. Или у вас картинка аттачем в письме?
Скорее всего в местной локалке отсутствует DHCP. А так вообще - дельное решение пункт 2, к тому же подменять будет довольно просто. Раз у вас несколько точек, разумнее всего будет на каждой точке держать по устройству, раздающему меню по телевизорам. Вариант failover - на каждой точке держать те саые флэшки, в норме воткнутыми в устройство, в случае проблем с устройством сотрудники перетыкают флэшки в телевизоры и меняют отображение. Дешево и сердито.
Основная проблема обновлять это меню когда надо. Кроме того, если меню будет немного динамическим, будет куда веселее, как в каком-нибудь большом фастфуде сейчас.
zeliboba: Да, не каждый, и да, гостевая сеть - это обычно отдельный SSID, он вроде там указывается рядом с настройкой. И кстати, можно тогда настроить безопасный DNS на роутере сразу, а на известных устройствах выставлять статическим "обычный" DNS от яндекса. (Остальные, правда, могут сделать то же самое, но это уже под их ответственность.)
kinok: При этом не нужно извращаться со сменой ns-записей, достаточно заменить A-запись в их домене. NS ваши никуда не переезжают сами по себе, они как жили с адресами 1.1.1.1 и 3.3.3.3, так и живут. NS-записи меняются только тогда, когда ВЫ перевозите свои сервера DNS. И вот их как раз очень нежелательно дублировать в А-записях.
То есть конфиг DNS должен быть настолько статичен, насколько возможно. Есть у вас два сервера имен, у каждого по одному IP, их прописываете в своей зоне с адресами 1.1.1.1 и 3.3.3.3, и не трогаете с тех пор (пока не придет пора менять хостинг вместе с белыми адресами). На них создаете зоны для клиентов, настраиваете их авторитетами для этих зон, и поддерживаете А, MX и прочие записи, которые хотят ваши клиенты. Если они переезжают - это их забота сообщить вам новый адрес для такой-то А-записи. Если их перевозите вы сами, то вы меняете А-записи так, чтобы у них ничего не отвалилось. В этом случае можете пользоваться сервисом от гугла "вычистить старые данные из DNS" https://developers.google.com/speed/public-dns/cache чтобы ускорить очистку старых данных из кэшей DNS.
А что мешает прописать адрес в зоне AD? Прав нет, что ли? DNS-зона в AD ничем не отличается от обычной зоны, в ней так же можно создавать статические A-записи.
Может, урлы содержат ORDER_ID вместе с /cart или /delivery? Тогда срабатывает сразу последний пункт, и метрика будет заведомо сломана. Или, как вариант, что никто так не делает.
Я бы здесь поменял порты со стандартных на какие-либо в диапазоне 0x8000-0xbfff, чтобы заведомо исключить провайдера. Также, а из офиса2 какой-либо другой RDP на стандартном порту доступен?
