Устанавливаем и настраиваем WSUS. Типичные проблемы с синхронизацией ПО-обновлений через WSUS – как их определить

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

Установка обновлений и патчей является очень важной составной частью обеспечения безопасности. Для всех специалистов по информационной безопасности основной необходимостью является мониторинг, анализ и устранение уязвимостей программного обеспечения. Компания Microsoft предоставляет бесплатную возможность использования сервиса обновлений своих программных продуктов в течение всего времени поддержки программного продукта. Необходимые обновления доступны через сеть интернет всем пользователям программных продуктов.

Применение обновлений к корпоративной среде требует дополнительных механизмов управления. Microsoft предлагает использовать в корпоративной среде мощный бесплатный продукт Windows Server Update Services (WSUS), который позволяет экономить трафик в сети Интернет, централизованно управлять обновлениями для серверов и рабочих станций.

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

Установка WSUS

В рамках ОС Windows Server 2008 существует роль сервера Windows Server Update Services(рис. 1).

Для Windows Server 2003 следующие системные требования к установке WSUS 3.0 SP1:

• Операционная система: Windows Server 2003 SP1 и выше.
• Дополнительные роли сервера: IIS 6.0 и выше
• Дополнительные обновления ОС: Microsoft .NET Framework 2.0, Microsoft Management Console 3.0.
• Дополнительные программы: Microsoft Report Viewer, SQL Server 2005 SP1 (Служба WSUS способна установить внутреннюю службу Windows Internal Database).

Несмотря на то, что служба практически не требовательна к процессору и оперативной памяти, ей необходима изрядная доля дискового пространства. Желательно 40 Гб и более. В конечном итоге, размер занимаемого дискового пространства будет зависит от количества продуктов, которые необходимо обновлять, и количества требуемых обновлений в инфраструктуре.
Если при установке сервер не удовлетворяет системным требования, то появится окно предупреждения, в котором будет описано что необходимо установить (рис. 2).

Настройка сервера WSUS

Для нормальной работы сервера необходимо указать ряд параметров, которые делаются с помощью «Мастер настройки Windows Server Update Services»

В окне «Выбор вышестоящего сервера» необходимо указать пункт «Синхронизировать с Центром обновлений Майкрософт» (рис. 3).

При применении к корпоративной среде прокси-сервера в окне «Настройка прокси-сервера» необходимо указать IP адрес, номер порта и параметры аутентификации на прокси-сервере(рис. 4).

В окне «Выбор языков» необходимо выбрать пункт «Загружать обновления только на следующих языках» обязательно выбрать «Английский». Выбор остальных языков необходимо делать исходя из систем, установленных в компании, обычно ещё добавляют «Русский» (рис. 5). Нет необходимости выбирать «Загружать обновления на всех языках, включая новые», так как это увеличит количество обновлений, хранящихся на дисковом пространстве.

В окне «Выбор продуктов» необходимо указать продукты, установленные в рамках корпоративной среды. ВНИМАНИЕ! Никогда не устанавливаете все продукты, так как это может привести к увеличению размера хранимых обновлений, при этом обновления не будут использоваться. Необходимо методично и последовательно выбрать только те продукты которые используются в рамках корпоративной среды (рис. 6).

В окне «Выбор классов» необходимо указать только те классы которые требуют обновлений. Так как указание лишних классов в значительной степени увеличивает размер хранимых обновлений (рис. 7).

В окне «Настройка расписания синхронизации» необходимо выбрать время синхронизации (рис. 8). В рамках WSUS синхронизации не предполагает загрузку обновлений. В данном случае синхронизация будет производить только обновление информации с сервера Центра обновлений Майкрософт».

После первой синхронизации необходимо открыть консоль WSUS и выбрать «Параметры». В «Параметры» открыть пункт «Файлы и языки обновлений» (рис. 9)

Во вкладке «Файлы обновлений» окна «Файлы и языки обновлений» необходимо указать каким образом будет осуществляться хранение файлов обновлений. Так как мы хотим уменьшить размер Интернет трафика, то необходимо выбрать «Хранить файлы обновлений локально на этом сервере» и ОБЯЗАТЕЛЬНО! выбираем пункты «загружать файлы обновлений на сервер только после одобрения обновления» и «Загружать файлы экспресс - установки» (рис. 10). Пункт «Загружать файлы обновлений на сервер только после одобрения обновления» необходим, так как по умолчанию сервер загрузить ВСЕ обновления, которые он посчитает необходимым для выбранных продуктов. Однако так как с течением времени очень многие обновления аккумулируются в Service Pack, то вероятнее всего они не будут нужны и займут дисковое пространство.

После всех настроек необходимо добавить компьютеры в службу WSUS.

Добавление компьютеров в службу WSUS

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

Это делается следующим образом «Пуск – Администрирование – Управление групповой политикой ». Выбираем ту политику, которая действует в домене (по умолчанию Default Group Policy). Кликаем правой кнопкой и выбираем «Изменить».

В окне «Редактор управления групповыми политиками» заходим «Конфигурация компьютера – Политики – Административные шаблоны – Компоненты Windows – Центр обновления Windows ». Выбираем пункт «Указать размещение службы обновлений в Интрасети » (рис. 11)

В окне «Свойства: Указать размещение службы обновлений в Интрасети» указываем параметр «Включен» и в строке «Укажите службу обновление в интрасети для поиска обновлений» прописываете строку вида: http:// [ip адрес или DNS имя сервера обновления в сети ]. Копируете адрес в окно «Укажите сервер статистики в интрасети» (рис. 12). В рамках редактора групповой политики есть подсказки в окне объяснений (рис. 12).

Также необходимо определить политику обновлений. Это делается через пункт «Настройка автоматических обновлений» (рис. 13).

В окне «Свойства: Настройка автоматических обновлений» указываем параметр «Включен» и параметры «Настройка автоматического обновления», «Установка по расписанию – день», «Установка по расписанию – время». В окне «Объяснение» есть описание всех параметров для серверов и желательно устанавливать параметр «2 –уведомления о загрузке и установке», что позволит администраторам выбирать время установки обновлений на сервера(рис. 14).

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

В командной строке набираем gpedit.msc и проделываем те же операции, которые были описаны выше для групповой политики в домене.

Через некоторое время компьютер появится в окне «Компьютеры – Все компьютеры – Не назначенные компьютеры » при «Состояние: Любой» (рис. 15).

Управление обновлениями

Для того чтобы увидеть и одобрить необходимые обновления нужно в «Обновления – Все обновления» выбрать следующие пункты фильтра: «Одобрение: Неодобренные» и Состояние: Требуется» и нажать «Обновить»(рис. 16). ВНИМАНИЕ! для проверки необходимых обновлений всегда обращайте внимание, чтобы настройки фильтра стояли в положениях «Одобрение: Неодобренные» и Состояние: Требуется», иначе вы рискуете загрузить ненужные вам обновления, или не загрузить их вообще. В случае, если фильтр в настройках «Одобрение: Неодобренные» и Состояние: Требуется» показал пустое поле, то все необходимые обновления для компьютеров уже одобрены и находятся на сервере.

После одобрения на компьютере через какое-то время появятся обновления согласно правилам, настроенным в политике безопасности.

Достаточно часто существует необходимость принудительной проверки обновлений на сервере обновлений со стороны компьютера. Для этого существует программа wuauclt. exe , которая запускается через командную строку. Для проверки обновлений её необходимо запускать с ключом / detectnow (wuauclt. exe / detectnow ). Для посылки отчета о состоянии (очень часто необходимо при первом подключении к серверу обновлений) необходимо запускать с ключом / reportnow (wuauclt. exe / reportnow ).

Господа, удачных вам обновлений

Все началось с того, что на клиентских машинах я перестал получать обновления и выпадала ошибка. Зайдя на вой сервер WSUS в логах Просмотра событий я увидел две ошибки. Первая это последняя попытка синхронизации каталогов оказалась не удачной, Код 10022.

Вторая ошибка это Многие клиентские компьютеры не сообщали информацию на сервер за последние 30 дней.

Погуглив ошибку я нашел решение, оно заключалось в том, что нужно было установить обновления KB2734608 , мне они к сожалению не подошли так как они рассчитаны на WSUS 3, а в Windows Server 2012 R2 идет уже WSUS 6. Но поискать в инете обновления я не поленился. В итоге получил аж 82, устанавливаем их.

После перезагрузки я обнаружил еще ошибку Консоли администрирования WSUS не удается подключиться к базе данных сервера WSUS, причин этому несколько идет режим обновления скриптов. При установке WSUS я использовал встроенную базу данных, WID (Windows Internal database) - встроенная база Windows. База WID по умолчанию называется SUSDB.mdf, расположена в каталоге windir%\wid\data\. Поддерживается только Windows аутентификация (не SQL). Именем инстанса базы данных WSUS: server_name\Microsoft##WID. Логи WSUS смотрим в каталоге windir%\wid\

После того как закончится обновление перезапускаем службу Внутренняя база данных Windows

После чего консоль уже отображает данные и WSUS работает.

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

• \WSUS\WSUSContent
• %windir%\wid\data
• \SoftwareDistribution\Download

Каждый администратор осознает важность своевременных обновлений, особенно если это касается критических обновлений безопасности. Однако с ростом сети и увеличением числа программных продуктов это становится весьма непростой задачей. Значит самое время развернуть WSUS (Windows Server Update Services ) - локальный сервер обновлений в вашей сети.

Этим вы убьете сразу несколько зайцев: значительно уменьшите загрузку канала и потребляемый интернет трафик, а также получите в руки мощный инструмент для контроля и управления процессом обновлений. Отныне все локальные ПК будут обновляться с вашего сервера и устанавливать только выбранные вами обновления.

Приступим. Перед установкой WSUS следует подготовить сервер, мы будем использовать Windows Server 2008 R2, однако с небольшими поправками все сказанное будет справедливо для других версий Windows Server. Что нам понадобится:

• IIS 6 или выше,
• .NET Framework 2.0 или выше,
• Report Viewer Redistributable 2008 ,
• SQL Server 2005 SP2 Express или выше.

WSUS может хранить обновления в собственной БД или использовать SQL-сервер, последнее более предпочтительно с точки зрения производительности. Если в вашей сети уже развернут SQL-сервер можно использовать его, иначе вполне подойдет бесплатный SQL Express.

Получить все необходимые компоненты можно на сайте Microsoft:

При скачивании обращаем внимание на разрядность, для 64-битной ОС скачиваем 64-битные версии продуктов.

Пока идет скачивание добавим роли сервера. Нам понадобятся Веб-сервер (IIS) и Сервер приложений (в предыдущих версиях Windows Server установите.NET Framework). Сервер приложений устанавливается со значениями по умолчанию, а в Веб-сервере необходимо добавить следующие опции:

• ASP.NET
• Windows - проверка подлинности
• Сжатие динамического содержимого
• Совместимость управления IIS6

Добавив необходимые роли, установим Report Viewer и SQL Server c параметрами по умолчанию. Все готово, можно устанавливать WSUS.

Запустив инсталлятор, выбираем установку сервера и консоли администрирования, папку установки. В параметрах базы данных указываем наш SQL-сервер. Остальные настройки можно оставить по умолчанию.

Сразу после установки запустится мастер начальной настройки. Все опции довольно просты и понятны. В параметрах синхронизации указываем откуда наш сервер будет получать обновления: с сервера Microsoft или с другого WSUS сервера. Последний вариант следует использовать если вам требуется развернуть дополнительный сервер обновлений, например, для филиала. В этом случае подчиненный сервер будет получать только одобренные вами обновления.

На следующей закладке, при необходимости, указываем параметры прокси-сервера, и выполняем первичное подключение. Будет загружена информация от вышестоящего сервера: списки продуктов, типов обновлений и т.д.

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

На следующей странице укажите какие классы обновлений вы хотели бы получать, здесь все зависит от политики обновлений на вашем предприятии. Следует помнить, что обновления драйверов и пакеты новых функций крайне не рекомендуется разворачивать автоматически, без предварительного тестирования. Если у вас нет возможности этим заниматься, то указывать эти классы вам ни к чему.

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

Открыв консоль (доступна в меню Администрирование), первым делом запустите ручную синхронизацию, чтобы скачать все имеющиеся на сегодняшний день обновления для выбранных продуктов. В зависимости от того, чего и сколько вы выбрали при настройке, а также скорости вашего подключения это может занять продолжительное время.

Пока идет синхронизация займемся настройкой клиентских ПК. Если у вас развернута Active Directory это можно сделать с помощью групповых политик. Откройте Управление групповой политикой , выберите необходимый объект и щелкнув правой кнопкой мышки нажмите Изменить . В открывшемся окне выберите Конфигурация компьютера - Политики - Административные шаблоны - Центр обновления Windows . Нас интересует параметр Указать размещение службы обновлений Microsoft в интрасети . Переводим его в положение Включено и указываем путь к нашему WSUS серверу в виде http:\\ИМЯ_СЕРВЕРА .

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

Если ваша сеть имеет одноранговую структуру, то вам придется настраивать каждый ПК в отдельности. Делается это через Редактор локальной групповой политики (Пуск - Выполнить - gpedit.msc), сам процесс настройки полностью аналогичен вышеописанному.

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

Информации вполне достаточно, чтобы быстро оценить общую ситуацию и обратить внимание на проблемные места. Красные крестики указывают на то, что на данных ПК произошли ошибки в обновлении, с каждым таким случаем надо разбираться в отдельности. По каждому обновлению формируется детальный отчет, содержащий все необходимые для анализа проблемы данные.

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

Вот мы и подошли к еще одной важной настройке сервера - автоматическом одобрении. Клиентские ПК могут получать только одобренные обновления, но каждый раз делать все вручную нереально, поэтому часть обновлений можно одобрять автоматически. Откроем Параметры - Автоматические одобрения и активируем уже имеющуюся там политику, которая позволяет автоматически устанавливать критические обновления и обновления безопасности.

Здесь вы можете создавать свои правила и назначать их любой группе ПК. Например мы создали правило: автоматически одобрять все обновления MS Office группы Рабочие станции.

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

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

На этой ноте мы и закончим наше повествование, материал данной статьи позволит вам быстро развернуть и сделать базовые настройки сервера обновлений. С задачей тонкой настройки вы должны без труда справиться самостоятельно.

• Теги:

Please enable JavaScript to view the

Клиенты WSUS не хотят обновляться после смены сервера?
Тогда мы идем к вам. (С)

У всех бывали ситуации, когда что-нибудь переставало работать. В данной статье речь пойдет о WSUS (более подробную информации о WSUS можно получить и ). А точнее о том, как заставить клиентов WSUS (т.е. наши с вами компьютеры) заново получать обновления после переноса или восстановления существующего сервера обновлений.

Итак, ситуация следующая

Сдох сервер WSUS. Точнее RAID-контроллер аж 2000 года выпуска. Но радости этот факт не прибавил. После непродолжительной возни (с попытками восстановить RAID, загубленный помирающим контроллером), было принято решение послать все развернуть новый WSUS-сервер.

В итоге мы получили работающий WSUS, на который почему-то не коннектились клиенты.
Моменты: WSUS привязан с FQDN через внутренний DNS-сервер, WSUS-сервер прописан в групповых политиках и распространяется на клиентов через AD, настройки для сервера по-умолчанию, перед началом всех действий обновите сам WSUS и выполните синхронизацию обновлений.

После анализа ситуации, было выявлено несколько ключевым моментов

1. Клинч клиента (речь о wuauclt) при попытке соединиться с SID старого сервера WSUS.
2. Проблема с неустановленными обновлениями, скачанными со старого WSUS-сервера.
3. Парковка служб влияющих на работу wuauclt (речь о wuauserv, bits и cryptsvc). Парковка произошла по разным причинам, которые детально не анализировались.

В итоге все решение вылилось в маленький скрипт, который распространяется групповыми политиками через AD или собственными руками (и ногами). Скрипт использует наиболее безопасный вариант починки и не приносил ни одного негативного результата уже на протяжении полугода использования.

Опишу, что делается (для особо любопытных)

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

И как всегда: все действия описанные выше и ниже вы выполняете на свой страх и риск. Пожалуйста, удостоверьтесь в том что все необходимые данные сохранены до выполнения скрипта.

Скрипт

Net stop wuauserv sc sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU) del /f /s /q %windir%\SoftwareDistribution\download\*.* REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f net start wuauserv && net start bits && net start cryptsvc wuauclt /resetauthorization /detectnow /reportnow

Такую серверную роль как Windows Server Update Services (WSUS) целесообразно использовать как в мелких компаниях, насчитывающих от 10 компьютеров, так и в крупных корпорациях. В отличие от таких серверных ролей, как доменные службы или серверов электронной почты, для серверов обновлений WSUS вам не обязательно разворачивать отказоустойчивые сервера, так как автоматизация обновления клиентских компьютеров не является самой критичной задачей в бизнес процессах.

Сценарии развёртывания серверов обновлений:

Простое развертывание WSUS-серверов: Многие маленькие и средние организации в своей производственной среде для распространения обновлений, используют именно данную модель. Простые решения развертывания WSUS-серверов обычно представляют собой модель с развернутым сервером обновлений, который расположен внутри интрасети, защищенной межсетевым экраном и обслуживающим клиентские компьютеры интрасети. Для загрузки обновлений WSUS-сервер синхронизируется с серверами Центра обновления Microsoft.

Иерархическое развертывание WSUS-серверов: Как понятно с названия модели, предыдущая модель развертывания WSUS-серверов является базовой, но при необходимости вы можете создавать сложные иерархии серверов WSUS. Прежде всего, стоит учесть, что для синхронизации с Центром обновлений Microsoft вам достаточно иметь только один WSUS-сервер, а все остальные WSUS-серверы должны подключаться к текущему. При связывании нескольких WSUS-серверов у вас образуется так называемая иерархия, состоящая из вышестоящего и подчиненного WSUS-серверов. Существует два способа установки связи между WSUS серверами.

• Автономные серверы WSUS. В этом случае, в процессе синхронизации вышестоящий WSUS-сервер предоставляет все свои загруженные обновления одному или нескольким подчиненным серверам, но при всем этом процессе состояния утверждений или информация о группе компьютеров на клиентские рабочие места не передается. Администрирование всех подчиненных серверов WSUS выполняется отдельно от развертывания обновлений на клиентские компьютеры;
• Режим репликации. В случае развертывания данной модели, вышестоящий сервер WSUS передает все свои обновления, состояния утверждений и информацию о группах своим подчиненным серверам. При этом, подчиненные реплицируемые сервера наследуют все утверждения, причем они не могут выполнять административные задачи на своих вышестоящих WSUS-серверах.

Данная конфигурация развертывания серверов обновлений удобная для большинства производственных случаев, включая организации с филиалами. Модель иерархического развертывания WSUS-серверов рационально использовать для загрузки обновлений из Центра обновлений Microsoft и последующей установки этих обновлений посредством подчиненных серверов, тем самым разгружая широкополосное соединение с Интернетом. Целесообразно использовать такую конфигурацию в окружении, где один WSUS-сервер не в состоянии самостоятельно обеспечить развертывание обновлений в существующем парке компьютеров. По всем рекомендациям желательно использовать не более чем трехуровневую иерархию WSUS-серверов, так как при последующем распространении обновлений время задержки все время увеличивается. В любой модели и при любой конфигурации, подчиненный сервер обязан регулярно выполнять синхронизацию с вышестоящим сервером обновлений, образуя между собой неподдерживаемый замкнутый цикл. При изменении протокола соединений между серверами, для обеспечения максимальной защиты всей цепочки серверов обновлений, во время настройки иерархии WSUS-серверов, для настройки автоматических обновлений вам нужно указать наиболее удаленный подчиненный сервер. В том случае, если в вашей организации насчитывается несколько подчиненных серверов обновлений, вам не стоит настраивать на них синхронизацию с вышестоящими серверами обновлений в одно и то же время, что может привести к перезагрузке вышестоящего сервера. Для этой конфигурации лишь один WSUS-сервер загружает и управляет обновлениями непосредственно с серверов Microsoft, а все остальные серверы конфигурируются как реплики.

Группы компьютеров
Для всех моделей развертывания серверов WSUS, причем, модель простого развертывания не исключение, важнейшей частью при развертывании являются группы компьютеров. В большинстве организаций, одновременно все обновления не развертываются на все компьютеры. А для управления компьютерами, которые будут получать обновления, серверы WSUS позволяют настраивать группы компьютеров, а сами обновления уже развертывать для одной или нескольких групп одновременно. По умолчанию, в консоли WSUS вы можете найти две группы компьютеров: «Все компьютеры» и «Не назначенные компьютеры». По умолчанию, когда клиентский компьютер синхронизируется с WSUS-сервером, он автоматом добавляется в обе группы, созданные по умолчанию. Затем, из группы «Не назначенные компьютеры», вы можете переместить компьютеры в специально отведенную для них группу, так как данная группа содержит только те компьютеры, для которых не было назначено членство в созданных вами группах. В свою очередь, группа «Все компьютеры» позволяет распространять целевые обновления на все компьютеры вашей организации, независимо от того, членами каких групп являются компьютеры. Возьмём для примера случай простого развертывания WSUS с тремя настраиваемыми группами, которые называются «Тестирование», «Пилотная группа» и «Производство». Группа тестирования содержит несколько компьютеров, которые находятся в лабораторной среде и предназначены для проверки корректности работы механизма распространения обновлений. Если тестирование проходит удачно, то обновления будут развертываться в следующей группе. После тестирования обновления разворачиваются в пилотной группе, которая состоит из компьютеров ИТ-отдела, где квалифицированные специалисты могут устранить появившиеся после развертывания обновлений неисправности. Затем, если пилотное развертывание прошло без инцидентов, то вы можете развертывать обновления на производственных компьютерах, которые расположены в среде «Производство».