В данной заметке мы рассмотрим вариант развёртывания альтернативного KMS сервера, позволяющего активировать современные версии ОС Microsoft Windows/Windows Server и пакета Microsoft Office. Этот вариант будет реализован на базе ОС Debian GNU/Linux 11 (Bullseye) и исходных кодов открытого проекта vlmcsd. Для своей работы KMS сервер vlmcsd не требует наличия купленных KMS-ключей или какой-либо онлайн-активации в Microsoft. Вопрос "лицензионной чистоты" данного варианта в текущих реалиях оставим на обсуждение любителям философии и "кинутым" заказчикам известного вендора. При этом, следует понимать, что изложенный далее материал публикуется исключительно в образовательных целях и не позиционируется, как руководство к действию. Этот материал опирается на публично открытые программные продукты и не преследует цели нарушения норм действующего законодательства и правил лицензирования ПО. И вообще, мы за всё хорошее и против всего плохого. Поехали…
-
KMS сервер активации Microsoft Windows и Office на базе Debian GNU/Linux 11 (Bullseye)
-
Как получить читаемый лог WindowsUpdate.log на сервере с ОС Windows Server 2016 с ограниченным доступом в Интернет
При отладке работы клиента Windows Update в Windows Server 2016 одним из ключевых источников получения информации является лог, который ведёт системная служба "Windows Update". В отличие от предыдущих версий Windows Server, где этот лог имел простой текстовый формат и мог быть прочитан любым текстовым редактором, в Windows Server 2016, как и в Windows 10, прежний текстовый формат лога сменился на бинарный формат Event Trace Log (ETL) механизма Event Tracing for Windows (ETW). Соответственно, для извлечения информации из такого лога требуются дополнительные инструменты типа специализированного командлета PowerShell. А в случае, если диагностируемая серверная система имеет ограниченный доступ в Интернет, то с получением читаемого формата данных ETL у нас могут возникнуть проблемы. Рассмотрим такую проблемную ситуацию и способ её решения.
-
Windows Server 2016 и длительное ожидание проверки обновлений Windows Update
В Windows Server 2016 можно столкнуться с ситуацией, когда встроенный клиент Windows Update очень долго выполняет проверку обновлений. Характерно то, что проблема может проявляться плавающим образом и воспроизводиться не всегда. Замечено, что чаще всего проблема проявляется в случае, если система была недавно включена или перезагружена. В этой заметке мы поговорим о том, какие могут быть причины у такого поведения и как это можно попробовать исправить.
-
Январские накопительные обновления Windows Server могут вызывать циклические перезагрузки контроллеров домена ADDS, сломать ВМ с UEFI в Hyper-V и вызвать отказ в работе ReFS
По появившейся на днях информации, развёртывание Январских кумулятивных обновлений для ОС Windows Server 2012 R2 (KB5009624) может привести к проблемам в работе служб Active Directory Services (ADDS), так как серверы с ролью контроллера домена могут начать циклические перезагрузки. Microsoft уже подтвердили наличие проблемы, о чём можно прочитать по соответствующим ссылкам на Microsoft Docs:
- Windows Server 2022 Known issues and notifications
- Windows 10 20H2 and Windows Server 20H2 Known issues and notifications
- Windows 8.1 and Windows Server 2012 R2 Known issues and notifications
Можно встретить сообщения о том, что после установки KB5009624 на Windows Server 2012 R2 могут возникнуть проблемы с запуском виртуальных машин с использованием UEFI в Hyper-V. Опять же, это подтверждается со стороны Microsoft: Virtual machines (VMs) in Hyper-V might fail to start.
Также есть информация о замеченных проблемах с дисковыми томами с файловой системой ReFS, которые после установки Январских обновлений могут перестать монтироваться и начать отображаться как RAW. На данный момент времени Microsoft со своей стороны при проявлении данной проблемы предлагает удалять Январское обновление: KB5010691: ReFS-formatted removable media may fail to mount or mounts as RAW after installing the January 11, 2022 Windows updates.
Кроме того, есть информация о том, что и обновления, выпущенные в Январе для серверных ОС Windows Server 20H2 и клиентских ОС Windows 10 (KB5009543), а также Windows 11 (KB5009566) могут вызвать проблему использования L2TP VPN, сложности с RDP и всё те же внезапные перезагрузки серверов с ролью контроллера домена. Для получения подробностей и обходном решении, читайте раздел "Известные проблемы, связанные с этим обновлением" в соответствующих KB.
Есть информация о том, что проблемные обновления уже отозваны из каталога Windows Update, однако они всё ещё могут оставаться в метаданных локальных служб WSUS. Поэтому стоит воздержаться от их развёртывания в продуктивных средах до тех пор, пока со стороны Microsoft не будут выпущены корректирующие обновления.
-
Изменение схемы распространения Servicing Stack Updates для Windows 10 2004-21H1 на WSUS и решение ошибки 0x800f0823 - CBS_E_NEW_SERVICING_STACK_REQUIRED
В операционной системе Windows 10 для успешного получения обновлений ОС механизм "Центр обновления Windows" должен и сам регулярно обновляться.
Это происходит с помощью специальных обновлений SSU (Servicing Stack Updates). Актуальный список обновлений SSU для всех версий Windows можно найти на странице "ADV990001 - Security Update Guide - Microsoft - Latest Servicing Stack Updates". -
Августовские обновления Windows требуют тщательного предварительно тестирования перед развёртыванием
Появившиеся в службе Windows Update и WSUS в начале этой недели Августовские кумулятивные обновления Windows нацелены на повышение уровня безопасности ОС и, в частности, исправляют проблему безопасности при работе с протоколом RDP, которую уже успели окрестить "BlueKeep-2". Однако, следует внимательно подходить к вопросу предварительного тестирования данных обновлений, чтобы не создать себе дополнительных проблем. Читать далее...
-
Установка Remote Server Administration Tools (RSAT) в Windows 10 v1903 в Offline-режиме
Ранее мы уже писали об особенностях установки пакета Remote Server Administration Tools (RSAT) в Windows 10. Но время идёт и новые релизы Windows 10 вносят новые правила работы с этим пакетом. В этой заметке мы поговорим об особенностях автономной установки RSAT в актуальной версии Windows 10 1903.
-
Использование клиента NFS в Windows 10 редакции Professional
Администрируя серверы на базе ОС Linux в среде, где в качестве основной клиентской ОС используется Windows, время от времени приходится сталкиваться с необходимостью что-либо скопировать с клиентской Windows на Linux-систему или наоборот, с Linux-системы на Windows. Чаще всего для этого используются возможности протоколов SSH/SCP с помощью таких инструментов, как например, утилита pscp.exe. Но когда приходится сталкиваться с файловыми Linux-серверами, позволяющими использовать возможности протокола NFS, мы можем задаться вопросами типа "может ли клиентская ОС Windows выступать в качестве NFS-клиента?", "есть ли в клиентской ОС Windows какая-то встроенная реализация клиента NFS?". Именно такие вопросы у меня возникли в период времени, который совпал с периодом, когда мы перебирались с Windows 8.1 на первый релиз Windows 10. Информация, которую в тот момент удалось найти по этому вопросу, заключалась в том, что функциональность NFS-клиента имеют только "старшие" редакции клиентских ОС Windows, такие как Windows 7 Ultimate/Enterprise, Windows 8/8.1 Enterprise и Windows 10 Enterprise. Однако в нашем случае использовалась ОС Windows 10 редакции Professional, поэтому пришлось отбросить эти мысли. Читать далее...
-
Ошибка проверки подлинности при подключении к удалённому рабочему столу Windows RDS …"Причиной ошибки может быть исправление шифрования CredSSP"
Информация об уязвимости в провайдере безопасности CredSSP ОС Windows была опубликована 13.03.2018 в документе CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability. В этом документе можно найти ссылки на обновления безопасности, которые были выпущены для закрытия этой уязвимости. Выпущенные обновления относятся к механизмам CredSSP, как в клиентских, так и в серверных ОС Windows. При этом неправильная последовательность развёртывания обновлений, касающихся CredSSP, может привести к неожиданным последствиям.
-
Обход некоторых видов ограничений запуска приложения через механизмы Software Restriction Policies (в режиме Unrestricted) в групповых политиках Active Directory
Некоторые администраторы применяют в своей инфраструктуре Active Directory (AD) функционал Software Restriction Policies (SRP), имеющийся в составе Group Policy, для того, чтобы явным образом ограничивать запуск и исполнение каких-либо приложений. То есть используется сценарий ограничительных мер по типу "разрешено всё, кроме того, что явно запрещено". Например, в рамках мероприятий по противодействию новомодным комплексным шифровальщикам, у некоторых администраторов может возникнуть желание явно запретить запуск некоторых исполняемых файлов, используемых вредительским ПО, не запрещая при этом запуск всех прочих приложений и не используя механизмы проверки цифровых подписей.
В данной заметке мы поговорим о том, почему мероприятия подобного рода могут оказаться малоэффективны, наглядно продемонстрировав пример того, как любой непривилегированный пользователь может без особых сложностей обойти некоторые механизмы защиты. В качестве наглядного примера мы рассмотрим ситуацию с запретом исполнения небезызвестной утилиты PsExec из пакета PsTools Sute.