Что такое обновление сервера

Исправление установки Server Core

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Исправление сервера, на котором выполняется установка Server Core, можно выполнить следующими способами.

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

Вручную. даже в организациях, которые не используют Windows update или WSUS, можно применить обновления вручную.

Просмотр обновлений, установленных на сервере основных серверных компонентов

Перед добавлением нового обновления в Server Core рекомендуется увидеть, какие обновления уже установлены.

чтобы просмотреть обновления с помощью Windows PowerShell, выполните команду Get-Hotfix.

Чтобы просмотреть обновления, выполнив команду, запустите systeminfo.exe. При проверке системы может возникнуть небольшая задержка.

Также можно выполнить команду WMIC QFE List из командной строки.

обновление ядра сервера автоматически с Центр обновления Windows

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

проверьте текущий параметр Центр обновления Windows:

Чтобы включить автоматическое обновление, выполните следующие действия.

Чтобы отключить автоматическое обновление, выполните:

Чтобы указать клиентскому компоненту Центра обновления Windows немедленно обнаруживать и устанавливать все доступные обновления, выполните следующую команду:

Обновление сервера с помощью WSUS

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

Обновление сервера вручную

Скачайте обновление и сделайте его доступным для установки Server Core. В командной строке выполните следующую команду:

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

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

Источник

Общие сведения об обновлениях Windows Server

Процесс обновления до новой версии Windows Server может отличаться в зависимости от используемой операционной системы и выбранного пути. Чтобы определить действия, выполняемые в новом развертывании Windows Server, мы будем использовать следующие термины.

Обновление. Также именуется «обновление на месте». Вы переходите с более старой версии операционной системы на более новую, сохраняя неизменным физическое оборудование. Именно этот метод мы рассмотрим в этой статье.

Обновления на месте можно дополнить поддержкой общедоступного или частного облачного поставщика, но соответствующие возможности и процедуры нужно уточнять отдельно у каждого из них. Кроме того, вы не сможете выполнить обновление на месте для Windows Server, если настроена загрузка с VHD. Обновление на месте от выпусков Windows Storage Server до Windows Server 2019 не поддерживается. Вместо этого можно выполнить миграцию или установку.

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

Миграция. Вы переходите с более старой версии операционной системы на более новую путем ее переноса на другой набор оборудования или другую виртуальную машину.

Последовательное обновление операционной системы кластера. Вы обновляете ОС узлов кластера, не останавливая рабочие нагрузки Hyper-V и (или) масштабируемого файлового сервера. Эта функция позволяет избежать простоя, который может нарушать соглашения об уровне обслуживания. Дополнительные сведения см. в статье Последовательное обновление ОС кластера.

Преобразование лицензии. Вы преобразуете определенный выпуск версии в другой выпуск той же версии за один шаг, выполнив простую команду и предоставив соответствующий лицензионный ключ. Это называется преобразованием лицензии. Например, если ваш сервер работает под управлением Windows Server 2016 Standard, вы можете преобразовать его в Windows Server 2016 Datacenter.

До какой версии Windows Server лучше всего обновляться?

Мы рекомендуем всегда обновлять ОС до последней версии Windows Server: сейчас это Windows Server 2019. Использование последней версии Windows Server предоставит вам все современные функции, в том числе повышающие безопасность и производительность.

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

При обновлении Windows Server обычно можно пропустить одну, а иногда даже две версии. Например, Windows Server 2012 R2 и Windows Server 2016 можно обновить на месте до Windows Server 2019.

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

Источник

Службы Windows Server Update Services (WSUS)

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

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

Описание роли сервера WSUS

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

Практическое применение

Управление обновлениями — это процесс управления развертыванием и обслуживанием промежуточных выпусков программного обеспечения в рабочей среде. Это помогает поддерживать производительность, преодолевать уязвимости и обеспечивать стабильность рабочей среды. Если организация не может устанавливать и поддерживать известный уровень доверия в своих операционных системах и прикладном программном обеспечении, то у нее может появиться ряд уязвимостей, что в случае взлома способно привести к потере дохода и интеллектуальной собственности. Чтобы минимизировать данную угрозу, необходимо правильно настроить системы, использовать последние версии программного обеспечения и установить рекомендуемые обновления ПО.

Основными сценариями, в которых WSUS повышает эффективность вашего бизнеса, являются:

Централизованное управление обновлениями

Автоматизация управления обновлениями

Новые и измененные функции

Обновление с любой версии Windows Server, поддерживающей WSUS 3.2, до Windows Server 2012 R2 требует предварительного удаления WSUS 3.2.

В Windows Server 2012 обновление с любой версии Windows Server с установленными службами WSUS 3.2 блокируется в процессе установки, если будет обнаружена служба WSUS 3.2. В этом случае вам будет предложено сначала удалить службы обновления Windows Server, а затем повторно обновить сервер.

Но после изменений, внесенных в текущем выпуске Windows Server и Windows Server 2012 R2, установка не блокируется при обновлении с любой версии Windows Server и WSUS 3.2. Если перед выполнением обновления Windows Server или Windows Server 2012 R2 не будут удалены службы WSUS 3.2, то задачи WSUS после установки будут завершаться ошибкой. Известен только один метод решения такой проблемы — отформатировать жесткий диск и повторно установить Windows Server.

Службы Windows Server Update Services представляют собой встроенную роль сервера со следующими дополнительными возможностями.

Может быть добавлена и удалена с помощью диспетчера серверов

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

Добавляет возможность использования хэширования SHA256 для дополнительной безопасности

Обеспечивает разделение клиента и сервера, благодаря чему версии агента Центра обновления Windows (WUA) могут поставляться независимо от WSUS

Использование Windows PowerShell для управления WSUS

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

Какой эффект дает это изменение?

Пропуская основные операции WSUS через Windows PowerShell, системные администраторы могут увеличить продуктивность, уменьшить время на изучение новых инструментов, а также снизить количество ошибок из-за неоправданных ожиданий, ставших результатом отсутствия согласованности простых операций.

Что работает иначе?

В более ранних версиях операционной системы Windows Server отсутствовали командлеты Windows PowerShell, а автоматизация управления обновлениями была затруднительным делом. Командлеты Windows PowerShell для операций WSUS дают дополнительную гибкость и быстроту системному администратору.

Содержание коллекции

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

Источник

Установка и настройка сервера обновлений WSUS

Windows Server Update Services или WSUS предназначен для распространения обновлений внутри сети. Он позволит скачивать все пакеты для их установки на один сервер и распространять данные пакеты по локальной сети. Это ускорит процесс получения самих обновлений, а также даст администратору контроль над процессом их установки.

В данной инструкции мы рассмотрим пример установки и настройки WSUS на Windows Server 2012 R2.

Перед установкой

Рекомендуется выполнить следующие действия, прежде чем начать установку WSUS:

Также нужно убедиться, что на сервере достаточно дискового пространства. Под WSUS нужно много места — в среднем, за 2 года использования, может быть израсходовано около 1 Тб. Хотя, это все условно и, во многом, зависит от количества программных продуктов, которые нужно обновлять и как часто выполнять чистку сервера от устаревших данных.

Установка роли

Установка WSUS устанавливается как роль Windows Server. Для начала запускаем Диспетчер серверов:

На странице приветствия просто нажимаем Далее (также можно установить галочку Пропускать эту страницу по умолчанию):

На следующей странице оставляем переключатель в положении Установка ролей или компонентов:

Далее выбираем сервер из списка, на который будем ставить WSUS:

Среди компонентов оставляем все по умолчанию и нажимаем Далее:

Мастер запустит предварительную настройку служб обновления — нажимаем Далее:

Среди ролей службы можно оставить галочки, выставленные по умолчанию:

Прописываем путь, где WSUS будет хранить файлы обновлений:

* в нашем примере был прописан путь C:\WSUS Updates. Обновления нужно хранить на разделе с достаточным объемом памяти.

Запустится настройка роли IIS — просто нажимаем Далее:

Среди служб ролей оставляем все галочки по умолчанию и нажимаем Далее:

В последнем окне проверяем сводную информацию о всех компонентах, которые будут установлены на сервер и нажимаем Установить:

Процесс установки занимаем несколько минут. После завершения можно закрыть окно:

Установка роли WSUS завершена.

Первый запуск и настройка WSUS

После установки наш сервер еще не готов к работе и требуется его первичная настройка. Она выполняется с помощью мастера.

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

. и ждем завершения настройки:

Откроется стартовое окно мастера настройки WSUS — идем далее:

На следующей странице нажимаем Далее (при желании, можно принять участие в улучшении качества продуктов Microsoft):

Далее настраиваем источник обновлений для нашего сервера. Это может быть центр обновлений Microsoft или другой наш WSUS, установленный ранее:

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

Если в нашей сети используется прокси-сервер, задаем настройки:

* в нашем примере прокси-сервер не используется.

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

. и дожидаемся окончания процесса:

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

Внимательно проходим по списку программных продуктов Microsoft и выбираем те, которые есть в нашей сети, и для который мы хотим устанавливать обновления:

* не стоит выбирать все программные продукты, так как на сервере может не хватить дискового пространства.

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

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

Настраиваем синхронизацию обновлений. Желательно, чтобы она выполнялась в автоматическом режиме:

Мы завершили первичную настройку WSUS. При желании, можно установить галочку Запустить первоначальную синхронизацию:

После откроется консоль управления WSUS.

Завершение настройки сервера обновлений

Наш сервис установлен, настроен и запущен. Осталось несколько штрихов.

Установка Microsoft Report Viewer

Для просмотра отчетов, необходим компонент, который не ставится с WSUS. Для его установки нужно сначала зайти в установку ролей и компонентов:

Продолжаем установку и завершаем ее.

Для загрузки Microsoft Report Viewer переходим на страницу https://www.microsoft.com/en-us/download/details.aspx?id=3841 и скачиваем установочный пакет:

После выполняем установку приложения и перезапускаем консоль WSUS — отчеты будут доступны для просмотра.

Донастройка WSUS

Мастер установки предлагает выполнить большую часть настроек, но для полноценной работы необходимо несколько штрихов.

1. Группы компьютеров

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

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

2. Автоматические утверждения

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

Кликаем по Создать правило:

У нас есть возможность комбинировать условия, при которых будут работать наши правила. Например, для созданных ранее групп компьютеров можно создать такие правила:

3. Добавление компьютеров в группы

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

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

Настройка клиентов

И так, наш сервер готов к работе. Клиентские компьютеры могут быть настроены в автоматическом режиме с помощью групповой политики Active Directory или вручную в реестре. Рассмотрим оба варианта. Также стоит отметить, что, как правило, проблем совместимости нет — WSUS сервер на Windows Server 2012 без проблем принимает запросы как от Windows 7, так и Windows 10. Приведенные ниже примеры настроек являются универсальными.

Групповая политика (GPO)

Открываем инструмент настройки групповой политики, создаем новые политики для разных групп компьютеров — в нашем примере:

* 8530 — сетевой порт, на котором по умолчанию слушает сервер WSUS. Уточнить его можно на стартовой странице консоли управления WSUS.

Ждем применения политик. Для ускорения процесса некоторые компьютеры можно перезагрузить вручную.

Настройка клиентов через реестр Windows

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

Для этого запускаем редактор реестра и переходим по пути: HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\WindowsUpdate. Нам необходимо создать следующие ключи:

Теперь переходим в раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\WindowsUpdate\AU. Если он отсутствует, создаем вручную. После нужно создать ключи:

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

Автоматическая чистка WSUS

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

Также можно воспользоваться командлетом в Powershell Invoke-WsusServerCleanup — целиком команда будет такой:

Источник

Что происходит, когда вы обновляете свой DNS

Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?

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

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

Как работает DNS: рекурсивные и авторитетные DNS-серверы

Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные

Авторитетные DNS-серверы (также известные как серверы имен) хранят базу данных IP-адресов для каждого домена, за который они отвечают. Например, прямо сейчас авторитетный DNS-сервер для github.com — это ns-421.awsdns-52.com. Вы можете спросить у него IP-адрес github.com вот таким запросом:

Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.

Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!

Как рекурсивный DNS-сервер запрашивает IP-адрес github.com

Давайте рассмотрим пример того, что делает рекурсивный DNS-сервер (например, 8.8.8.8), когда вы запрашиваете у него IP-адрес (запись А) для github.com. Во-первых, если у него уже есть кэшированный результат, он выдаст его. Но что, если все кэши просрочены? Вот что происходит.

Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).

Шаг 2: Спросить корневые серверы имен о github.com.

Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.

У нас есть новый IP-адрес для отправки запроса! Это один из серверов имен для github.com.

Шаг 4: Спросить у серверов имен github.com об адресе github.com.

Мы почти закончили!

Итак, у нас есть запись А для github.com. Теперь у рекурсивного сервера есть IP-адрес github.com, и он может вернуть его вам. И он смог провернуть всю процедуру, начиная всего с нескольких жестко закодированных IP-адресов: адресов корневых серверов имен.

Как увидеть все шаги рекурсивного DNS-сервера: dig +trace

Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:

Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.

Обновим записи DNS

Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.

При обновлении записей DNS существует два основных варианта

Поговорим о TTL

Но мы забыли кое-что важное. Это пакеты TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).

В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:

Это довольно короткий TTL. Теоретически, если бы все DNS-реализации следовали стандарту DNS, это означало бы, что если GitHub решил изменить IP-адрес для github.com, каждый получил бы новый IP-адрес в течение 60 секунд. Давайте посмотрим, как это происходит на практике.

Вариант 1: обновление записи DNS на тех же серверах имен

Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:

Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca, которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд)

Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:

Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.

После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!

Не всегда можно полагаться на TTL

Как и в большинстве интернет-протоколов, не всё подчиняется спецификации DNS. Некоторые DNS-серверы интернет-провайдеров будут кэшировать записи дольше, чем указано в TTL. Например, в течение двух дней вместо пяти минут. И люди всегда могут жестко закодировать старый IP-адрес в своем файле /etc/hosts.

На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.

Вариант 2: обновление ваших серверов имен

Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!

Я не хотела обновлять серверы имен для своего блога, поэтому вместо этого взяла другой свой домен и использовала его в примерах для журнала по HTTP: это examplecat.com.

Раньше мои серверы были установлены на dns1.p01.nsone.net. Я решила изменить их на серверы Google с адресами ns-cloud-b1.googledomains.com и так далее.

Когда я внесла изменения, мой доменный регистратор несколько зловеще высветил сообщение: «Изменения в examplecat.com сохранены. Они вступят в силу в течение ближайших 48 часов». Затем я установила новую запись A для домена, чтобы она указывала на 1.2.3.4.

Ладно, давайте посмотрим, изменилось ли что-нибудь:

Источник