Tw-city.info

IT Новости
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Обновление групповой политики в домене

Обновление групповой политики в домене

трабл такой, на компах в домене слетели настройки прокси сервера. компов очень много, пробежаться по всем нет возможности, в групповой политике домена еще вчера прописали настроки прокси, поставили галочку что политика главная самая, но ничего не обновилось почему то!

можно как то вручную, принудительно, обновить политику на всех компах?

Добавление от 10.11.2004 12:04:

это строки на серваке PDC в командной строке.

локалки или жди ( время можно выставить ) или перегружай

secedit /refreshpolicy machine_policy
secedit /refreshpolicy user_policy

или gpupdate для WinXP.

это я знаю, но это на локальном компе! мне же надо во всем домене сделать!

перегружать контроллер домены не прокатит их много и на них возложены и некоторые другие функции

Добавление от 10.11.2004 13:04:

Вот только все равно перегрузиться всем придется — а при перезагрузке GP и так обновится

Добавление от 10.11.2004 13:11:

Кстати перегрузить всех можно, если восп. утилями типа «Remoute Control» & «Remote Shutdown» из Ресурскита

У нас RAdmin есть у большинства, опять же есть утилита DameWare она вообще сама инсталится может принудительно! Но тяжело обойти как минимум 600 компов (всего в домене их более 1400) и обновлять политики.

то же относится к бат файлу. как это сообщить всем юзерам. почта есть далеко не у всех!

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

пролистал всякие там чаты майкрософта по политикам, вопросы тупые задают, про это ничего нет толком

Вот только все равно перегрузиться всем придется — а при перезагрузке GP и так обновится

а вот и нет, после обновления все данные появились без перезагрузки

цитата: а вот и нет, после обновления все данные появились без перезагрузки По умолчанию, пользовательские групповые политики обновляются в фоновом режиме каждые 90 минут, со случайным смещением времени обновления на интервал от 0 до 30 минут.

Как-то не совместимо с фразой: «. СРОЧНО. »

цитата: Но тяжело обойти как минимум 600 компов (всего в домене их более 1400) Сочувствую и. завидую одновременно
У меня всего лишь 35

Добавление от 10.11.2004 14:33:

цитата: как это сообщить всем юзерам net send, например, всем членам домена

А точнее возможны варианты:

net send * — вообще всем машинам в сети, т.е. по списку netbios службы browsing
net send domain or net send /DOMAIN:name

Правда для всех этих действ требуется NetBios, а в ТАКОЙ сети я бы постарался его как можно реже исп. — очень много пакетов с х.х.х.255 будет

Да мы не ставили эксперименты. просто вчера пошли звонки что типа в Инет не могу зайти. у всех не был прописан прокси. мы прописали политику, но стормозили и прописали её для компов, хотя политика для юзеров утром пошла лавина звонков. тут мы поняли свою ошибку. щас вроде все окей стало!

Я еще 2 недели назад админил офис с 35 компами. теперь понял разницу. если раньше один клик ничего толком не значил, то сейчас это может отключить несколько отделов

Обновление групповой политики в Windows

Компьютеры будут обновлять групповую политику в фоновом режиме каждые 90 минут, кроме того, групповая политика обновляется при запуске компьютера. Иногда вы вносите изменения или создаете новые объекты групповой политики, и вам нужно, чтобы изменения вступили в силу немедленно.

    Существует 3 способа обновить групповую политику:

Способ 1 Обновление групповой политики с помощью команды gpupdate /force

Шаг 1: Запустите окно командной строки

Windows 7

Нажмите кнопку «Пуск» , введите «cmd» (без кавычек) в строку поиска в самом низу меню «Пуск», а затем щелкните значок cmd.exe, который должен появиться вверху списка результатов.

Windows 10

Щелкните правой кнопкой мыши кнопку «Пуск» Нажмите на командную строку(Admin), чтобы открыть окно CMD.

Шаг 2: Запустите команду gpupdate /force

Использование команды PsExec для обновления групповой политики удаленных компьютеров PsExec

Теперь, если у вас есть куча компьютеров, которые нуждаются в обновлении, было бы сложно войти в каждый из них и запустить эту команду. Для её запуска на удаленном компьютере вы можете использовать команду PsExec из набора инструментов Sysinternals. Вот пример использования PsExec для удаленного обновления групповой политики

Просто замените Computername на фактическое имя хоста компьютера

Чтобы выполнить GPUpdate.exe на группе компьютеров, указанных в текстовом файле, используйте команду PSExec.exe:

PSExec.exe @Computers.TXT GPUpdate.exe /force

Шаг 3: Перезагрузите компьютер

В окне командной строки введите gpupdate /force и нажмите клавишу Enter на клавиатуре. Строка «Обновление политики …» должна появиться в окне командной строки ниже, где вы только что набрали.

После завершения обновления вам будет предложено либо выйти из системы, либо перезагрузить компьютер. Нажмите N,чтобы отклонить эти запросы, а затем перезагрузите компьютер вручную. Иногда вам не будет предложено перезагрузить компьютер или выйти из системы после обновления. Тем не менее, вам все равно следует перезагрузить компьютер, если ИТ-специалист не примет иного решения.

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

Способ 2. Использование консоли управления групповой политикой

В Windows Server 2012 и более поздних версиях теперь можно принудительно обновить групповую политику на удаленных компьютерах из консоли управления групповой политикой. Этот метод очень прост и позволяет запускать обновление для одного подразделения или всех подразделений.

Читать еще:  Понижение контроллера домена 2020

Шаг 1. Откройте консоль управления групповыми политиками.

Шаг 2: Щелкните правой кнопкой мыши, чтобы обновить

Вы можете обновить отдельное подразделение или родительское подразделение, и оно обновит все подчиненные подразделения.

Я собираюсь обновить свой родительский OU «ADPRO Computers», в этом OU есть несколько подразделений, разбитых на отделы. Это запустит обновление групповой политики на всех компьютерах.

Способ 3: использование Powershell Invoke-GPUpdate

В Windows 2012 можно принудительно выполнить немедленное обновление с помощью команды powershell invoke-GPUupdate . Эта команда может использоваться для обновления клиентов Windows 10 и Windows 7.

Вам потребуется установленный Powershell, а также консоль управления групповыми политиками (GPMC).

RandomDelayMinutes 0 гарантирует, что политика обновляется сразу, а не ..

Единственным недостатком использования этой команды является то, что клиенты получат всплывающее окно CMD, как показано ниже. Отображается только около 3 секунд, затем закрывается.

Если вы хотите использовать команду PowerShell для принудительного обновления на всех компьютерах, вы можете использовать эти команды:

Вышеприведенные команды будут извлекать каждый компьютер из домена, помещать их в переменную и запускать команды для каждого объекта в переменной

Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи

Хороши обновления под windows, но настраивать их на каждой машине так, как вам это хочется — задача трудная да и не нужная, если вы используете домен и групповые политики. Ниже опишу какие параметры и где нужно настроить, что обновления ставились сами собой, обычным юзерам как можно меньше надоедали. Другими словами максимально автоматически.

И так. Создаём новую групповую политику «update«. Какие параметры нам нужно будет настроить. Описание настроек привожу на русском (у кого на английском, сложностей перевести не возникнет). Жирным выделено, какие значения нужно придать парамтерам.

Открываем «Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows/Windows Update» и настраиваем следующие параметры:

Задержка перезагрузки при запланированных установках Disabled

Настройка автоматического обновления Enabled
— Настройка автоматического обновления 4 — авт. загрузка и устан. по расписанию
— Установка по расписанию — день: 0 — ежедневно
— Установка по расписанию — время: 10:00

Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователи Enabled
Не отображать параметр «Установить обновления и завершить работу» в диалоговом окне завершения работы Windows Disabled
Повторный запрос для перезагрузки при запланированных установках Disabled
Разрешать пользователям, не являющимся администраторами, получать уведомления об обновлениях Disabled
Разрешить Windows Update автоматически пробуждать систему для установки запланированных обновлений Enabled
Разрешить немедленную установку автоматических обновлений Enabled
Разрешить получение рекомендуемых обновлений через службу автоматического обновления Enabled

Указать размещение службы обновлений Microsoft в интрасети Enabled
— Укажите службу обновлений в интрасети для поиска обновлений:http://saturn:8530
— Укажите сервер статистики в интрасети: http://saturn:8530

Частота поиска автоматических обновлений Enabled

Открываем «Конфигурация пользователя -> Административные шаблоны -> Компоненты Windows/Windows Update» и настраиваем следующие параметры:

Не отображать параметр «Установить обновления и завершить работу» в диалоговом окне завершения работы Windows Disabled
Удалить доступ к возможностям Windows Update Disabled

После этого принудительно обновляем политики:

Теперь что бы принудительно обновиться, выполняем такую команду:

и смотрим, что обновления скачиваются быстрее.

Настройка клиентов WSUS с помощью групповых политик

В одной из предыдущих статей мы подробно описали процедуру установки сервера WSUS на базе Windows Server 2012 R2 / 2016. После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.

Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).

Предполагается, что в нашей сети будут использоваться две различные политики обновления — отдельная политика установки обновлений для серверов (Servers) и для рабочих станций (Workstations). Эти две группы нужно создать в консоли WSUS в секции All Computers.

В первую очередь необходимо указать правило группировки компьютеров в консоли WSUS (targeting). По умолчанию в консоли WSUS компьютеры распределяются администратором по группам вручную (server side targeting). Нас это не устраивает, поэтому укажем, что компьютеры распределяются в группы на основе client side targeting (по определенному ключу в реестре клиента). Для этого в консоли WSUS перейдите в раздел Options и откройте параметр Computers. Поменяйте значение на Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).

Теперь можно создать GPO для настройки клиентов WSUS. Откройте доменную консоль управления групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.

Групповая политика WSUS для серверов Windows

Начнем с описания серверной политики ServerWSUSPolicy.

Настройки групповых политик, отвечающих за работу службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies-> Administrative templates-> Windows Component-> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).

В нашей организации мы предполагаем использовать данную политику для установки обновлений WSUS на сервера Windows. Предполагается, что все попадающие под эту политику компьютеры будут отнесены к группе Servers в консоли WSUS. Кроме того, мы хотим запретить автоматическую установку обновлений на серверах при их получении. Клиент WSUS должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью модуля PSWindowsUpdate) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:

  • ConfigureAutomaticUpdates (Настройка автоматического обновления): Enable. 3 – Autodownloadandnotifyforinstall(Автоматически загружать обновления и уведомлять об их готовности к установке) – клиент автоматически скачивает новые обновлений и оповещает об их появлении;
  • SpecifyIntranetMicrosoftupdateservicelocation (Указать размещение службы обновлений Майкрософт в интрасети): Enable. Set the intranet update service for detecting updates (Укажите службу обновлений в интрасети для поиска обновлений): http://srv-wsus.winitpro.ru:8530, Set the intranet statistics server (Укажите сервер статистики в интрасети): http://srv-wsus.winitpro.ru:8530 – здесь нужно указать адрес вашего сервера WSUS и сервера статистики (обычно они совпадают);
  • No auto-restart with logged on users for scheduled automatic updates installations (Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователя): Enable – запретить автоматическую перезагрузку при наличии сессии пользователя;
  • Enableclient-sidetargeting(Разрешить клиенту присоединение к целевой группе): Enable. Target group name for this computer (Имя целевой группу для данного компьютера): Servers – в консоли WSUS отнести клиенты к группе Servers.
Читать еще:  Восстановление контроллера домена из резервной копии

Политика установки обновлений WSUS для рабочих станций

Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически (предупреждая пользователя за 5 минут).

В данной GPO (WorkstationWSUSPolicy) мы указываем:

  • AllowAutomaticUpdatesimmediateinstallation (Разрешить немедленную установку автоматических обновлений): Disabled — запрет на немедленную установку обновлений при их получении;
  • Allownon-administratorstoreceiveupdatenotifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях): Enabled — отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку;
  • Configure Automatic Updates:Enabled. Configure automatic updating: 4 — Auto download and schedule the install. Scheduled install day: 0 —Everyday. Scheduled install time: 05:00 – при получении новых обновлений клиент скачивает в локлаьный кэш и планирует их автоматическую установку на 5:00 утра;
  • Target group name for this computer:Workstations – в консоли WSUS отнести клиента к группе Workstations;
  • No auto-restart with logged on users for scheduled automatic updates installations:Disabled — система автоматически перезагрузится через 5 минут после окончания установки обновлений;
  • Specify Intranet Microsoft update service location: Enable. Set the intranet update service for detecting updates: http://srv-wsus.winitpro.ru:8530, Set the intranet statistics server: http://srv-wsus.winitpro.ru:8530 –адрес корпоративного WSUS сервера.

В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan. Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update (ссылка).

Назначаем политики WSUS на OU Active Directory

Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).

Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.

Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.

Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:

Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate.

Данный reg файл можно использовать для переноса настроек WSUS на другие компьютеры, на которых не удается настроить параметры обновлений с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
«WUServer»=»http://srv-wsus.winitpro.ru:8530»
«WUStatusServer»=»http://srv-wsus.winitpro.ru:8530»
«UpdateServiceUrlAlternate»=»»
«TargetGroupEnabled»=dword:00000001
«TargetGroup»=»Servers»
«ElevateNonAdmins»=dword:00000000
[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]
«NoAutoUpdate»=dword:00000000 –
«AUOptions»=dword:00000003
«ScheduledInstallDay»=dword:00000000
«ScheduledInstallTime»=dword:00000003
«ScheduledInstallEveryWeek»=dword:00000001
«UseWUServer»=dword:00000001
«NoAutoRebootWithLoggedOnUsers»=dword:00000001

Также удобно контролировать применённые настройки WSUS на клиентах с помощью rsop.msc.

И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.

Также иногда приходится принудительно перерегистрировать клиента на сервере WSUS:

wuauclt /detectnow /resetAuthorization

В особо сложных случаях можно попробовать починить службу wuauserv так. При возникновении ошибки 0x80244010 при получении обновлений на клиентах, попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.

В следующей статье мы опишем особенности одобрения обновлений на сервере WSUS. Также рекомендуем ознакомиться со статьей о переносе одобренных обновлений между группами на WSUS сервере.

Читать еще:  Как посмотреть групповые политики домена

Групповые политики Active Drirectory

Групповые политики Windows являются неотъемлемой частью администрирования Windows-систем. Рассмотрим примеры работы с этим инструментом на VDS под управлением ОС семейства Windows Server.

Для чего необходимы групповые политики

Говоря простым языком, Групповая политика — это инструмент архитектуры Active Directory, который позволяет управлять настройками серверов и рабочих терминалов, подключенных к домену, централизованно. Также, с помощью групповых политик достаточно просто распространить программное обеспечение. Администратор может указать политики для группы в одном месте, а затем применить их к целевой группе пользователей.

Во многих компаниях, как правило, применяется деление на отделы: отдел кадров, бухгалтерия, юристы, отдел системного администрирования. Предположим, что каждому отделу необходим собственный минимальный набор программного обеспечения, а рабочие станции должны быть настроены для конкретных нужд и под конкретные задачи. Благодаря групповым политикам появляется возможность создать настройки для конкретных групп пользователей в домене. При помощи Active Directory GPO администратор может устанавливать и управлять стандартизированными наборами настроек, конкретно для бухгалтерии или отдела кадров.

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

Компоненты GPO

Выделяют два компонента групповых политик — клиентский и серверный, т.е. формируется структура “клиент-сервер”.

Серверный компонент представляет оснастка MMC (Microsoft Management Console), предназначенная для настройки групповой политики. MMC можно использовать для создания политик, а также для контроля и управления административными шаблонами, настройками безопасности (установка ПО, скрипты и т.п.). Обобщенное название “возможностей” называется расширением. Каждое расширение может иметь дочернее расширение, которое разрешает добавление новых или удаление старых компонентов, а также их обновление.

Клиентский компонент получает и применяет настройки групповой политики. Клиентские расширения являются компонентами запускаемыми на клиентской ОС, которые отвечают за интерпретацию и обработку объектов групповой политики.

Для администрирования GPO используют оснастки MMC — Group Policy Management Console (GPMC) и Group Policy Management Editor.

Сценарии использования Active Directory GPO:

  • Централизованная настройка пакета программ Microsoft Office.
  • Централизованная настройка управлением питанием компьютеров.
  • Настройка веб-браузеров и принтеров.
  • Установка и обновление ПО.
  • Применение определенных правил в зависимости от местоположения пользователя.
  • Централизованные настройки безопасности.
  • Перенаправление каталогов в пределах домена.
  • Настройка прав доступа к приложениям и системным программам.

Оснастка управления групповыми политиками

Сперва следует установить роль сервера Active Directory Domain Service (AD DS) на контроллер домена. После этого будет доступна оснастка Group Policy Management, для ее запуска вызываем окно “Выполнить” (Windows + R). В открывшемся окне вводим команду:

И нажимаем “OK”.

Возможно оснастка не сможет открыться т.к. не была установлена ранее. Исправим это.

1. Открываем диспетчер серверов и выбираем установку ролей и компонентов.

2. На этапе выбора типа установки, отметим параметр “Установка ролей и компонентов”. Кликаем по кнопке “Далее”.

3. Так как установка выполняется для текущего сервера — нажимаем “Далее”.

4. Установку серверных ролей пропускаем нажатием на кнопку “Далее”.

5. На этапе выбора компонентов отметим галкой “Управление групповой политикой”. Кликаем по кнопке “Далее”.

Завершаем установку компонентов как обычно.

Окно оснастки управления групповой политикой выглядит так:

Создание объектов групповой политики

Добавим новый объект групповой политики. В левой части, проследуем по пути: Лес → Домены → → Объекты групповой политики.

В правой части окна, кликаем правой кнопкой мыши в свободном месте. В открывшемся контекстном меню, выбираем “Создать”.

В открывшемся окне, вводим имя новой политики. Нажимаем “OK”.

Добавленный объект появится в общем списке:

Настроим созданный объект

Для настройки нового объекта кликаем по нему правой кнопкой мыши. В контектстном меню выбираем “Изменить”.

Откроется окно редактора управления групповыми политиками. Займемся “полезным” делом — удалим папку со стандартными играми из меню Пуск. Для этого, в меню слева проследуем по пути Конфигурация пользователя Конфигурация пользователя → Политики → Административные шаблоны: получены определения политик (ADMX-файлы) с локального компьютера → Меню “Пуск” и панель задач.

В правой части окна найдем параметр “Удалить ссылку “Игры” из меню “Пуск””. Для удобства поиска можно воспользоваться сортировкой по имени, вверху окна.

Кликаем по этому параметру правой кнопкой мыши, выбираем “Изменить”.

В открывшемся окне изменим состояние на “Включено”. В поле комментария рекомендуем не игнорировать. Для завершения настройки нажимаем “OK”.

Создание объектов можно считать оконченным.

Поиск объектов

В корпоративных средах, как правило, создается большое количество объектов GPO. Хорошо было бы уметь находить нужный объект. У консоли есть данный функционал. Для этого, в левой части окна кликаем правой кнопкой мыши по лесу. В открывшемся меню выбираем “Найти…”

В открывшемся окне выбираем в каком домене выполнять поиск. Можно выполнить поиск и по всем доменам, но это может занять продолжительное время.

Попробуем найти созданный ранее объект.

В поле “Элемент поиска” из выпадающего списка выбираем “Имя объекта групповой политики”. В условии оставляем вариант “Содержит”. В “Значение“ указываем имя созданной ранее политики. Именно по этой причине следует создавать понятные имена политик. Нажимаем кнопку “Добавить”.

Критерии поиска заданы. нажимаем кнопку “Найти” и просматриваем результаты поиска.

Удаление объекта групповой политики

Если в объекте GPO пропадает необходимость, будет лучше его удалить. Кликаем по созданному объекту правой кнопкой мыши, в контекстном меню выбираем “Удалить”. Если уверены в своем решении, на вопрос подтверждения отвечаем “Да”.

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector
×
×