Проблемы с windows server 2008

Обновлено: 06.07.2024

Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах. Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления

Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления.

Ошибки, связанные с Adprep

Adprep — утилита для подготовки существующей среды Active Directory (AD) для первого DC, функционирующего с новой операционной системой, например Server 2008 R2. Если все контроллеры домена в среде AD работают с Server 2008 или Windows 2003 и требуется добавить первый DC с операционной системой Server 2008 R2, необходимо выполнить определенные команды Adprep.

Выполните adprep/forestprep на хозяине схемы.
Выполните adprep/domainprep на каждом хозяине инфраструктуры домена.
Если предполагается установить доступный только для чтения DC (RODC — новшество Server 2008), следует также выполнить adprep/rodcprep для каждого домена с RODC.

Этот достаточно простой процесс подробно описан в Интернете, но тем не менее у администраторов часто возникают вопросы:

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

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

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

Ошибка делегирования DNS

Экран 1. Ошибка делегирования DNS

До появления Server 2008 многие проблемы с AD были вызваны внутренними неполадками в инфраструктуре DNS, в частности отсутствующими или неправильными записями делегирования DNS. Одной из целей специалистов Microsoft при совершенствовании установки служб AD DS в Server 2008 было помочь потребителям в начальной настройке правильной инфраструктуры DNS, а затем облегчить обслуживание данной конфигурации.

утилита Dcpromo настроена для установки роли DNS-сервера;
слишком мало отношений делегирования существует между DNS-серверами и непосредственной родительской зоной DNS и поддоменом, в котором устанавливается новый DC;
устанавливаемый DC не может создать делегирование поддомену DNS на DNS-сервере для родительской зоны.

Dcpromo пытается создать делегирование, чтобы компьютеры в других доменах могли распознавать запросы DNS для узлов, в том числе контроллеров домена и компьютеров — членов домена, в поддомене DNS. Dcpromo может автоматически создавать такие отношения делегирования только на DNS-серверах Microsoft; попытка завершится неудачей, если родительская зона домена DNS находится на сторонних DNS-серверах, таких как BIND.

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

На родительском DNS-сервере должна функционировать служба Microsoft DNS Server.
DNS-сервер Microsoft в родительском домене должен быть подключен к сети и доступен с устанавливаемого контроллера домена.
Пользователь, запускающий утилиту Dcpromo на устанавливаемом контроллере домена, должен иметь учетные данные Domain Admins, Enterprise Admins или DNS Admin в родительской зоне DNS.

Виртуальные DC и возврат USN

Только поддерживаемые решения резервного копирования, такие как Windows Server Backup, могут быть использованы для восстановления контроллера домена. Недавно компания Microsoft пересмотрела рекомендации по запуску контроллеров домена на виртуальных машинах, в частности объяснено функционирование USN и способы предотвращения возврата USN. Благодаря этим изменениям информация представлена в более краткой и ясной форме, и администраторам будет проще избежать проблем.

Ошибка The Specified User Already Exists

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

Если выполняется замена ранее пониженного DC новым контроллером домена с тем же именем, обязательно удалите метаданные старого DC. В Server 2008 и более новых версиях самый простой способ удаления метаданных — через оснастки AD. При необходимости можно воспользоваться и старым методом — Ntdsutil.
Если по-прежнему происходят сбои Dcpromo с этой ошибкой, выясните в файле dcpromoui.log имя исходного DC (он же вспомогательный DC), используемого новым DC для репликации. Найдите в файле раздел, который начинается с метки A в листинге 2. Имя исходного DC показано во фрагменте с меткой B.
Убедитесь, что исходный DC выполнил входящую репликацию удаления метаданных DC (то есть конфликтующих учетной записи компьютера DC и объектов параметров NTDS). Если учетная запись контроллера домена все еще существует, определите причину:

простая задержка репликации; например, DC находится на расстоянии нескольких переходов от DC, запустившего операцию очистки метаданных;
сбой входящей репликации на вспомогательном DC или на исходном DC, с которого вспомогательный DC получает изменения;
вспомогательный DC в «сайте задержки» преднамеренно настроен на входящую репликацию изменений в AD с задержкой.

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

Таблица 1. Возможные строки расширения ошибок

Еще одна распространенная причина сбоя установки AD заключается в том, что группе Administrators не назначено право Enable computer and user accounts to be trusted for delegation («Разрешение доверия к учетным записям компьютеров и пользователей при делегировании»). Это право — параметр групповой политики, включенный для группы Administrators по умолчанию в политике контроллеров домена. Если DC выбран в качестве партнера репликации в ходе повышения уровня реплицируемого DC, выбранному DC требуется доступ к ресурсам повышаемого компьютера. Если право Enable computer and user accounts to be trusted for delegation не назначено группе безопасности Administrators, то каждый запрос доступа к ресурсу завершается неудачей с пояснением «отказано в доступе», как показано на экране 2.

Экран 2. Ошибка «отказано в доступе»

Чтобы устранить ошибку, используйте консоль управления групповой политики (GPMC) и инструмент Group Policy Results (Gpresult) для проверки, назначено ли группе Administrators право Enable computer and user accounts to be trusted for delegation в политике Default Domain Controllers Policy. Путь в редакторе групповой политики — \Computer Configuration\Policies\Windows Settings\SecuritySettings\Local Policies\UserRights Assignment\Enable computer and user accounts to be trusted for delegation.

После того как DC начинает работать с 2008 R2, можно запустить анализатор AD DS Best Practices Analyzer (BPA) для обнаружения любых ошибок в настройках политики. Соответствующее правило BPA не входит в изначальный набор правил, но имеется в дополнительном наборе правил, поставляемом через службу Windows Update. Это правило применяется к DC, работающему с Server 2008 R2.

При запуске AD DS BPA другое правило из того же дополнительного набора поможет предотвратить две типичные ошибки в настройках групповой политики, которые являются коренными причинами отказа репликации DC: непредоставление права Access this computer from the network («Доступ к компьютеру из сети») группам безопасности Administrators, Enterprise Domain Controllers или Authenticated Users либо назначение группам безопасности Enterprise Domain Controllers, Everyone, Administrators или Authenticated Users права Deny access to this computer from network («Запрет доступа к компьютеру из сети»). Отказ может случиться на любом DC, пытающемся выполнить репликацию из DC с одной из упомянутых выше настроек. Пользователи и компьютеры также могут столкнуться с отказами при применении объектов групповой политики (GPO).

Чтобы устранить эту ошибку, убедитесь в анализаторе BPA, что контроллеры домена назначили это право соответствующему участнику безопасности. Используйте настройки GPMC и Gpresult из таблицы 2, чтобы проверить правильность параметров групповой политики.

Таблица 2. Параметры GPMC и Gpresult

Особенности Adprep

Когда в Windows Server 2003 впервые появилось требование выполнения команды adprep/forestprep, компания Microsoft и некоторые партнеры рекомендовали в целях предосторожности изолировать хозяина схемы (например, временно поместить его в отдельную сеть) для лучшего управления процессом обновления схемы. С тех пор специалисты службы поддержки пользователей Microsoft пришли к выводу, что в большинстве компаний такой подход скорее вызывает проблемы, чем устраняет. Поэтому специалисты Microsoft больше не рекомендуют отключать от сети хозяина схемы перед запуском adprep/forestprep.

См. список известных проблем, которые были устранены для Windows 2008 SP2 за последние шесть месяцев. Ищете определенную проблему? Нажмите комбинацию кнопок CTRL + F (или Command + F на Mac) и введите искомое слово или слова для поиска на странице.

Устраненные проблемы

Сведения о проблеме

Ноябрь 2021 г.

Проверка подлинности может привести к сбою в DCs с определенными сценариями делегирования Kerberos

После установки ноябрьских обновлений безопасности, выпущенных 9 ноября 2021 г. на контроллерах доменов (DC) с версией Windows Server, перечисленных ниже на затронутых платформах, могут возникнуть сбои в проверке подлинности на серверах, связанных с билетами Kerberos, приобретенными через S4u2self. Сбои проверки подлинности являются результатом приобретения билетов Kerberos через S4u2self и использования в качестве доказательств для перехода протокола к делегированию службы backend, которые не удается проверить подпись. Проверка подлинности Kerberos не будет работать в сценариях делегирования Kerberos, которые используют интерфейсную службу для получения билета Kerberos от имени пользователя для доступа к службе backend. Важные сценарии делегирования Kerberos, в которых клиент Kerberos предоставляет передовую службу с билетом на доказательства, не влияют. Чистый Azure Active Directory среды не влияют на эту проблему.

Конечные пользователи в вашей среде могут не войти в службы или приложения с помощью единого знака On (SSO) с помощью локальной среды Active Directory или в гибридной Azure Active Directory среде. Обновления, установленные на Windows устройствах, не вызывают и не влияют на эту проблему.

Azure Active Directory (AAD) Встроенная Windows проверки подлинности (IWA) с помощью ограниченной делегирования Kerberos (KCD)
Встроенный единый знак проверки подлинности Windows веб-приложения (WAP) (SSO)
Active Directory Federated Services (ADFS)
Microsoft SQL Server
службы IIS (IIS) с помощью интегрированной Windows проверки подлинности (IWA)
Промежуточные устройства, включая балансиры нагрузки, выполняемые делегированную проверку подлинности

При столкновении с этой проблемой вы можете получить одну или несколько следующих ошибок.

Решение. Эта проблема была решена в обновлении KB5008606, выпущенном 14 ноября 2021 г. Чтобы получить автономный пакет для KB5008606, ищите его в каталоге обновлений Майкрософт. Это обновление можно импортировать в Windows Server Update Services (WSUS) вручную. Инструкции см. в каталоге Центра обновления Майкрософт . Примечание KB5008606 не доступно из Windows обновления и не будет устанавливаться автоматически.

Сервер: Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows 2008 R2 SP1; Windows Server 2008 SP2

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

После установки KB5006736 или более позднего обновления некоторые приложения могут иметь неожиданные результаты при отрисовывии некоторых элементов пользовательского интерфейса или при рисовании в приложении. Вы можете столкнуться с этой проблемой с приложениями, GDI+ и установить объект пера ширины 0 (0) на дисплеях с высокими точками на дюйм (DPI) или разрешением, или если приложение использует масштабирование.

Разрешение. Эта проблема была решена в KB5007263 .

Клиент: Windows 11, версия 21H2; Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 2004; Windows 10 версии 1909; Windows 10, версия 1809; Windows 10 Корпоративная LTSC 2019; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием; Windows 8.1; Windows 7 SP1
Сервер: Windows Server 2022, Windows Server версии 20H2; Windows Server версии 2004; Windows Server версии 1909; Windows Server версии 1809; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2

Октябрь 2021 г.

Свойства настраиваемой печати могут неправильно предоставляться клиентам серверов печати

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

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

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

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

Клиент: Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 2004; Windows 10 версии 1909; Windows 10 версии 1809; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием; Windows 8.1; Windows 7 SP1; Windows 11 версии 21H2
Сервер: Windows Server 2022; Windows Server версии 20H2; Windows Server версии 2004; Windows Server версии 1909; Windows Server версии 1809; Windows Server 2016; Windows Server 2012; Windows Server 2008 SP2

Установка принтеров может завершаться сбоем при попытке использования некоторых сетевых подключений

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

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

Разрешение. Эта проблема была решена в KB5006736 .

Клиент: Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 2004; Windows 10 версии 1909; Windows 10 версии 1809; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием; Windows 8.1; Windows 7 SP1; Windows 11 версии 21H2
Сервер: Windows Server 2022; Windows Server версии 20H2; Windows Server версии 2004; Windows Server версии 1909; Windows Server версии 1809; Windows Server 2016; Windows Server 2012; Windows Server 2008 SP2

Получение запроса на предоставление административных учетных данных при каждой попытке печати

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

Клиент: Windows 11 версии 21H2; Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 2004; Windows 10 версии 1909; Windows 10 версии 1809; Windows 10 Корпоративная LTSC 2019; Windows 10 Корпоративная LTSC 2016; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием; Windows 8.1; Windows 7 SP1
Сервер: Windows Server 2022, Windows Server версии 20H2; Windows Server версии 2004; Windows Server версии 1909; Windows Server версии 1809; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2

Разрешение. Эта проблема была решена в KB5006736 . Если после установки KB5006736 вы все равно получаете подсказку при каждом печати, см. в разделе Q1 в разделе "Часто задайте вопросы" KB5005652.Управление новым поведением установки драйвера по умолчанию point и print (CVE-2021-34481) .

Сентябрь 2021 г.

Учетные данные администратора требуются при каждой попытке приложений выполнить печать

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

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

Клиент: Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 2004; Windows 10 версии 1909; Windows 10 версии 1809; Windows 10 Корпоративная LTSC 2019; Windows 10 Корпоративная LTSC 2016; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием; Windows 8.1; Windows 7 SP1
Сервер: Windows Server 2022, Windows Server версии 20H2; Windows Server версии 2004; Windows Server версии 1909; Windows Server версии 1809; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2

Решение. Эта проблема решается извне путем настройки драйверов печати в среде. Если обновление драйверов в среде не устраняет проблему, обратитесь в службу поддержки производителя принтеров (OEM). Дополнительные сведения см. в разделе Q1/A1 в разделе "Часто задаваемые вопросы" статьи KB5005652.

Июль 2021 г.

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

После установки на контроллерах доменов (DC) в вашей среде обновлений, выпущенных 13 июля 2021 г., принтеры, сканеры и многофункциональные устройства, не соответствующие разделу 3.2.1 спецификации RFC 4556, могут вызывать сбой при печати, если используется проверка подлинности с помощью смарт-карт (PIV).

Клиент: Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 2004; Windows 10 версии 1909; Windows 10 версии 1809; Windows 10 Корпоративная LTSC 2019; Windows 10 Корпоративная LTSC 2016; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием; Windows 8.1; Windows 7 SP1
Сервер: Windows Server версии 20H2; Windows Server версии 2004; Windows Server версии 1909; Windows Server версии 1809; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2

Далее: теперь доступно временное устранение рисков. Дополнительные сведения см. в статье KB5005408 — проверка подлинности с помощью смарт-карт может вызывать сбой печати и сканирования.

Июнь 2021 г.

У приложений могут возникать проблемы с доступом к журналам событий на удаленных устройствах

После установки обновлений KB5003661 или более поздних версий приложения, доступ к журналам событий на удаленных устройствах может быть неспособен подключиться. Эта проблема может возникнуть, если на локальном или удаленном устройстве еще не установлены обновления, выпущенные 8 июня 2021 г. или позже. Затронутые приложения используют некоторые устаревшие API ведения журнала событий. При попытке подключения может возникать ошибка, например:

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

Клиент: Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 2004; Windows 10 версии 1909; Windows 10 версии 1809; Windows 10 Корпоративная LTSC 2019; Windows 10 Корпоративная LTSC 2016; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием; Windows 8.1; Windows 7 SP1
Сервер: Windows Server версии 20H2; Windows Server версии 2004; Windows Server версии 1909; Windows Server версии 1809; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2

Решение. Это ожидаемое поведение из-за изменений по усилению безопасности, связанных с трассировкой событий Windows (ETW) для CVE-2021-31958. Эта проблема устранена, если на локальных и удаленных устройствах установлен KB5003661.

Обмен пакетами с 192.168.2.23 по с 32 байтами данных:
Ответ от 127.0.0.1: Заданная сеть недоступна.
Ответ от 127.0.0.1: Заданная сеть недоступна.
Ответ от 127.0.0.1: Заданная сеть недоступна.
Ответ от 127.0.0.1: Заданная сеть недоступна.

Статистика Ping для 192.168.2.23:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)

Обмен пакетами с 192.168.2.108 по с 32 байтами данных:
Общий сбой.
Общий сбой.
Общий сбой.

Статистика Ping для 192.168.2.108:
Пакетов: отправлено = 3, получено = 0, потеряно = 3
(100% потерь)
Control-C
^C
C:\Windows\System32>ping localhost

Обмен пакетами с VIDEOSERVER [::1] с 32 байтами данных:
Ответ от ::1: время<1мс
Ответ от ::1: время<1мс
Ответ от ::1: время<1мс

Статистика Ping для ::1:
Пакетов: отправлено = 3, получено = 3, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Control-C
^C
C:\Windows\System32>ping 127.0.0.1

Обмен пакетами с 127.0.0.1 по с 32 байтами данных:
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128

Статистика Ping для 127.0.0.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

C:\Users\Manager 23>ping 192.168.2.108

Обмен пакетами с 192.168.2.108 по с 32 байтами данных:
Ответ от 192.168.2.108: число байт=32 время=1мс TTL=128
Ответ от 192.168.2.108: число байт=32 время<1мс TTL=128
Ответ от 192.168.2.108: число байт=32 время<1мс TTL=128
Ответ от 192.168.2.108: число байт=32 время<1мс TTL=128

Статистика Ping для 192.168.2.108:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 1 мсек, Среднее = 0 мсек

При таких обстоятельствах в сетевых окружениях не видно ни его, ни он никого не наблюдает. Но если обратиться к нему по сетевому имени-отчеству (точнее, только по имени, так как домена нет), то подключиться можно. Ну и RDP работает.

Если же поставить динамику, то все работает более менее сносно. Только IP меняется, потому что в качестве IP-раздающего девайса стоит D-Link 2540 или кто-то подобный, с кривой прошивкой, не способной сохранить статический айпишник, обновление которой тоже по некоторым причинам невозможно.

Ну и как всегда — просьба не бить, не обливать и отнестись с пониманием.

UPD: Что ж, воткнул сегодня имевшуюся под рукой сетевушку, и все чудесным (или чудным) образом заработало. Но вопроса это все-таки не решило.

В 2020 году Microsoft завершила поддержку двух популярных продуктов – Windows 7 и Windows Server 2008 R2. Однако в тысячах компаний все еще работают персональные компьютеры и серверы под управлением этих операционных систем. К чему может привести дальнейшая эксплуатация устаревшего ПО и что делать руководителю, дабы избежать рисков?

Почему завершение поддержки — это важно

Microsoft больше не присылает пользователям Windows 7 и Server 2008 R2 автоматических обновлений системы, в том числе исправлений свежеобнаруженных уязвимостей. Для каждого, кто несет ответственность за состояние корпоративной ИТ-инфраструктуры, что означает три серьезные проблемы.

Проблема 1. Компьютеры и серверы будут уязвимы для атак вирусов-шифровальщиков

WannaCry и NotPetya — лишь самые известные из шифровальщиков, эпидемия которых за последние несколько лет охватила миллионы компьютеров, в том числе и в нашей стране. Как результат – в российских компаниях такой вирус чаще всего шифрует базу «1С» и файловые хранилища (обычно вместе с локальными резервными копиями). Без обновлений от такаих угроз не защищен ни один бизнес – будь в нем хоть пять ПК, хоть тысяча. Данные атаки носят массовый характер, а зараженные файлы могут «улететь» по цепочке клиентам и партнерам.

Просто заплатить вымогателям за расшифровку не вариант — гарантий анонимные злоумышленники никаких не дают. И обычные антивирусы от таких угроз не спасают, ведь зловреды постоянно изменяются. Правда, помочь могут специализированные средства информационной безопасности. Уязвимости обнаруживаются регулярно: официальная поддержка Windows 7 завершилась 14 января, а 17 января уже обнаружилась новая уязвимость.

Итак, «просто ничего не делать» при отсутствии поддержки операционных систем нельзя.

Проблема 2. Совместимость с ПО

Заменить операционные системы на всех компьютерах — непростой процесс даже для небольшой компании. Дело в том, что версии Windows совместимы с определенными версиями прикладного ПО, например Adobe, Corel, «1C» и т. д. Но после прекращения поддержки Windows 7 далеко не все новые версии стороннего ПО могут быть установлены на устаревшую ОС.

Проблема 3. Совместимость с «железом»

Поставить «семерку» на самое современное «железо» не получится – новые версии процессоров Intel и AMD не поддерживают Windows 7.

То же самое справедливо и для серверного оборудования. Можно приобрести новый сервер за полмиллиона рублей, но воспользоваться ранее купленной лицензией Windows Server 2008 R2 тоже не получится – ПО и «железо» просто не распознают друг друга. Конечно же, виртуализация была, есть и будет, но она не позволяет решить проблемы с безопасностью (см. проблему 1).

Что же делать, если у меня Windows 7 или Server 2008

Есть несколько вариантов развития событий – какой из них выбрать, зависит от особенностей бизнеса. В первую очередь, необходимо провести аудит инфраструктуры. Он состоит из трех этапов:

Чтобы автоматизировать данный этап, Microsoft предлагает бесплатный программный пакет Assessment and Planning Toolkit (MAP). Он покажет, какие версии Windows и Windows Server и в каком количестве используются в инфраструктуре.

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

Независимо от того, решите вы в дальнейшем перейти на Windows 10 или остаться на «семерке» (такой вариант я опишу ниже), следует установить все обновления. Дело в том, что киберпреступники прекрасно осведомлены о завершении поддержки, а значит, в этом году рабочие станции и серверы под управлением устаревших версий Windows и Windows Server будут в зоне их пристального внимания. Если обновления не устанавливались, то площадь уязвимости вашей инфраструктуры огромна и решать эту проблему нужно быстро.

В небольшой компании достаточно просто физически дойти до каждого ПК и вручную обновить ОС. Если же рабочих станций больше 20-30, то можно использовать еще одну бесплатную службу – WSUS (Windows Server Update Services). Правда, чтобы настроить ее, понадобятся лицензии на Windows Server и определенные навыки: можно прокачать их самостоятельно либо привлечь технологического партнера (недорого).

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

Путь 1. Перейти на Windows 10

Наиболее очевидная опция — заменить устаревшие «семерки» на «десятки», проинсталлировав новую версию, как и раньше, в своей инфраструктуре. Причем у Microsoft имеется предложение по переходу (оно называется Windows 10 Upgrade), в рамках которого можно сэкономить около 2 тыс. рублей на каждой лицензии – то есть порядка 16% от стоимости.

Во время сбора данных необходимо убедиться, что все рабочие станции и серверы достаточно производительны, чтобы на них можно было установить новую версию ОС. Если все окей, приобретаем лицензии и начинаем процесс перехода. В маленькой компании можно обойтись дедовским методом: загрузить образ Windows на флешку и ногами обойти все рабочие станции. Для среднего же и крупного бизнеса переход нужно проводить в нерабочее время. Порядок следующий: сначала создается образ Windows с основными программными пакетами (Office, Adobe Acrobat и т. д.), а затем его централизованно отправляют на необходимое количество ПК, находящихся в сети. Если должной квалификации нет, здесь также может помочь технологический партнер.

Путь 2. Платить за обновления безопасности

Однако в случае обнаружения крупных уязвимостей патчи все-таки выпускаются: например, во время эпидемии WannaCry корпорация разослала обновление для устаревших версий бесплатно. Но в 2018 году Microsoft сделала заявление, что все апдейты для Windows 7 и Windows Server 2008 R2 будут платными. (Понять ее можно: разработка обновлений — дорогостоящий процесс.)

Экономически данный вариант не слишком выгоден и подходит только в качестве временной меры. Например, в текущем году за каждое устройство с Windows 7 придется выложить не менее четырех с лишним тысяч рублей. В 2021-м цена вырастет как минимум вдвое. Из-за нерегулярности обновлений устройствам под управлением устаревших ОС лучше всего ограничить выход в Интернет. Однако такой вариант позволит сделать переход на новые версии более плавным – ведь новое «железо» будет приобретаться с новой версией ОС.

Путь 3. Перейти в виртуальную среду Microsoft Azure

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

Читайте также: