Из исходных данных имеем — автономный Центр сертификации (ЦС) на базе Windows Server 2012 R2 и клиентский компьютер на базе Windows XP SP3, с которого выполняется попытка получения корневого сертификата ЦС с помощью утилиты CertUtil.exe (из состава Windows Server 2003 Administration Tools Pack). В результате получаем ошибку: 0x80094011 (-2146877423) Имеющиеся разрешения для центра сертификации не позволяют текущему пользователю получать сертификаты Описание причины такого поведения можно найти в документе TechNet Library — Windows Server 2012 R2 and Windows Server 2012 — What’s New in Certificate Services in Windows Server Для решения проблемы в указанном документе предлагается два варианта :1. Заменить на клиентских компьютерах с Windows XP ОС на более новую.2. Понизить уровень безопасности ЦС для поддержки клиентов на базе Windows XP. Первый вариант приемлем далеко не во всех случаях (по разного рода причинам). Для реализации второго варианта на сервере ЦС нужно выполнить команду: certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST После этого следует перезапустить службу сертификации Active Directory Certificate Services service net stop certsvc & net start certsvc В результате запрос с клиента под управлением Windows XP должен отработать успешно… В дальнейшем, когда станет возможной реализация варианта #1, вернуть обратно настройки ЦС можно следующим образом: certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST net stop certsvc & net start certsvc Дополнительная информация: TechNet Forums — Windows Server 2012 CA will not allow Windows XP to autoenroll
↧
CertUtil.exe на Windows XP &ЦС на Windows Server 2012 R2 — 0x80094011 —Имеющиеся разрешения для центра сертификации не позволяют текущему пользователю получать сертификаты
↧
Первичный анализ файла дампа памяти MEMORY.DMP при STOP-ошибках Windows (BSOD)
Это маленькая заметка о том, какие шаги необходимо выполнить для получения первичной информации об исполняемом файле, ставшем возможной причиной остановки работы операционной системы Windows — Blue Screen of Death (BSOD). По умолчанию ОС Windows настроена таким образом, что при возникновении ошибки приводящей к полной остановке работы системы, автоматически создаётся аварийный дамп памяти в виде файла MEMORY.DMP. Чтобы получить доступ к информации из этого файла, нам потребуется набор отладочных утилит Debugging tools for Windows из состава Windows Software Development Kit. Переходим по ссылке WDK and WinDbg downloads и скачиваем онлайн-инсталлятор/загрузчик Standalone Debugging Tools for Windows (WinDbg) – файл sdksetup.exe. Запускаем инсталлятор и выбираем вариант установки… На следующем шаге выбора компонент к установке (Select the features you want to install) отмечаем только то, что нам нужно — Debugging tools for Windows и нажимаем Install В указанную на первом экране папку из Интернета будет загружен и установлен набор утилит. После окончания установки находим в меню “Пуск” или на стартовом экране в группе ярлыков Windows Kits утилиту WinDbg и запускаем её с правами администратора Если по какой-то причине ярлык найти не удалось, то можно запустить исполняемый файл из каталога установки — С:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\windbg.exe В главном меню программы WinDbg выбираем пункты File > Symbol File Path. В открывшееся окно вставляем строку определяющую пусть к локальному каталогу символьного кэша и его онлайн-источнику: SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols Сохраняем настройки, выбрав в главном меню пункты File > Save Workspace Открываем файл дампа памяти, выбрав в меню File > Open Crash Dump… Выбираем файл MEMORY.DMP (по умолчанию расположен в каталоге C:\Windows) и нажимаем Open Появится информация о том, какой именно исполняемый модуль стал причиной остановки работы системы. Щёлкнув по гиперссылке !analyze-v можно получить более развернутую информацию о состоянии системы на момент возникновения стоп-ошибки. Туже самую информацию можно получить и с помощью командной строки используя примерно следующую последовательность команд: cd /d
↧
↧
Windows Server 2012 R2 Remote Access —Настраиваем VPN сервер с двухфакторной аутентификацией на базе L2TP/IPsec и авторизацией через RADIUS
В этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя Среда исполнения В рассматриваемом примере будет создан Windows NLB кластер из двух виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 R2 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2012 R2 Standard EN. Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее. Серверам присвоены имена – KOM-AD01-VPN01 и KOM-AD01-VPN02. Создаваемый в процессе описания NLB-кластер будет использовать имя KOM-AD01-VPNCL. В качестве поставщика аутентификации будут использоваться два отдельных сервера внутри локальной сети с заранее установленной и настроенной ролью Network Policy and Access Services (RADIUS) с именами KOM-AD01-NPS01 и KOM-AD01-NPS02. Аутентификация для протокола L2TP/IPsec с использованием сертификатов потребует наличия Доменного или Автономного Центра сертификации (ЦС) для создания цифровых сертификатов для VPN-клиентов. В рассматриваемой конфигурации а качестве Автономного ЦС будет использоваться отдельный сервер внутри локальной сети с именем KOM-AD01-CA01 Упрощённая схема взаимодействия компонент конфигурации будет выглядеть следующим образом: Данная конфигурация построена по принципу избыточности основных функциональных компонент. Если потребности в наличии такой избыточности нет, то описанную ниже конфигурацию вполне можно реализовать в рамках одного виртуального сервера, совместив соответствующие серверные роли на нём. Так как планируемая конфигурация получается многокомпонентной, то во избежание лишних сложностей, мы не будем пытаться настроить весь функционал сразу. Вместо этого мы сначала настроим базовый функционал
↧
Раздаём свежую прошивку iLO2 v2.27 на серверы HP ProLiant DL360/380 G5 c Windows Server 2012 R2 через VCRM
В прошлый раз мы рассматривали обновление прошивки Integrated Lights-Out 2 (iLO2) до актуальной на тот момент версии 2.25 для решения проблемы совместимости веб-интерфейса iLO2 c браузером Internet Explorer 11. В январе этого года появилась новая версия прошивки 2.27 с исправлением нескольких проблем безопасности и некоторыми улучшениями… FIXES: - Addressed possible security vulnerabilities mentioned in the HP Software Security Response Team reports SSRT101745 and SSRT101886. - Disabled SSL version 3. iLO 2 2.27 and later supports only TLS 1.0. - Addressed CVE-2014-0224 false positive. - The current user cannot be deleted by using the RIBCL command DELETE_CURRENT_USER. ENHANCEMENTS: - Added a CLI command to enable or disable the SSLv3 cryptographic protocol. The command is "set /map1/config1 oemhp_ssl_v3_enable=yes" to enable SSLv3 or "set /map1/config1 oemhp_ssl_v3_enable=no" to disable SSLv3. iLO will reset if the command state transitions from yes to no or from no to yes. - Hard drive status reporting on the System Health Summary web page now displays smart errors. - Added additional permission attributes to the JAR Manifest file for the Java Remote Console and Virtual Media applets. - Added a watchdog timer for firmware lockups. iLO 2 will reboot if the firmware does not respond for 60 minutes. - Added support for retrieving a certificate from a trusted HP SIM 7.0 and later server. Как и раньше, новую версию прошивки можно загрузить с сайта HP по ссылке: http://www.hp.com/support/ilo2 Я скачал файл cp025665.exe — Online ROM Flash Component for Windows — HP Integrated Lights-Out 2 версии 2.27 (30 Jan 2015) и попытался установить его на сервер HP ProLiant DL 380 G5 c операционной системой Windows Server 2012 R2. Установка прошла без каких-либо проблем и после обновления прошивки все проверенные мной функции iLO2 работали вполне себе штатно. Однако в этой ситуации меня мутило то, что в веб-интерфейсе HP Version Control Agent
↧
Обновляем Firmware BIOS & iLO2 на серверах HP ProLiant DL360/380 G5
В прошлый раз мы рассматривали обновление прошивки Integrated Lights-Out 2 (iLO2) до версии 2.27 на серверах HP ProLiant DL360/380 G5 c Windows Server 2012 R2 с помощью пакета установки, распространяемого через VCRM. В конце сентября и начале октября этого года появились новые версии прошивок iLO2 а также BIOS, относящихся в частности к этому же поколению серверов. Наверно можно было бы пропустить эти обновления «мимо ушей», если бы не степень критичности уязвимостей, которые исправляются этими обновлениями. Обновление iLO2 до версии 2.29 Относительно iLO информацию о проблемных версиях прошивок можно найти в бюллетене безопасности HP — ID c04486432 — HPSBHF03151 rev.4 — HP Integrated Lights-Out 2 and 4 (iLO 2, iLO 4), Chassis Management (iLO CM) on Proliant, Remote Denial of Service, Execution of Code, Elevation of Privilege. Как видно из этого документа, проблема безопасности распространяется в том числе и на рассмотренную нами в прошлый раз версию прошивки 2.27 для iLO2. Поэтому нам обязательно нужно выполнить обновление прошивки. Причём обновляться нужно не на следующую версию 2.28, которая имеет уже известные проблемы с JRE, описанные в документе ID c04818378 — Advisory: HP Integrated Lights-Out 2 (iLO 2) — Unable to Launch Java Remote Console with Java Runtime Environment (JRE) Versions 7 and 8 when TLSv1.1 and TLSv1.2 Are Enabled. Поэтому обновляться будем сразу на текущую версию 2.29, с момента выхода которой прошло уже достаточно времени. FIXES: - The Java IRC will not start when JRE versions 7 or 8 are installed and TLS 1.1/1.2 is enabled. - Addressed the vulnerability mentioned in CVE-2015-4000 and SSRT102268 (client-side SSL/TLS connections). Как и раньше, новую версию прошивки можно загрузить с сайта HP по ссылке: http://www.hp.com/support/ilo2. По указанной ссылке откроется страница загрузки HP Integrated Lights-Out 2 (iLO 2) Firmware for ProLiant G6 Servers, где выберем любую наиболее подходящую нам ОС, например Microsoft Windows Server 2008 R2 и
↧
↧
Обновления для Windows Server Remote Desktop Services
В блоге Remote Desktop Services Blog опубликована заметка Staying current with Windows Server updates for Remote Desktop Services (RDS), в которой старший эскалационный инженер David Rankin (тех.поддержка Microsoft по направлению Remote Desktop) даёт полезную рекомендацию по использованию нескольких статей базы знаний Microsoft описывающих перечень исправлений/обновлений компонент служб RDS, применение которых может рассматриваться в качестве первоначальной меры по разрешению разнообразных проблем связанных с RDS. KB2601888 — Available Updates for Remote Desktop Services in Windows Server 2008 R2 SP1 KB2821526 — Available updates for Remote Desktop Services in Windows Server 2012 KB2933664 — Available Updates for Remote Desktop Services in Windows Server 2012 R2 В соответствующих статьях перечисляются не только обновления доступные для загрузки и установки через службы Windows Update/WSUS (в основном из категории рекомендуемых обновлений), но и отдельные хот-фиксы, которых нет на Windows Update/WSUS (такие хот-фиксы должны применяться исключительно в ситуациях, описываемых в симптоматике соответствующих им статей KB). Заносим указанные статьи в Избранные ссылки, как отправные точки при решении проблем со службами RDS.
↧
Windows Server 2012 R2 Remote Access —Настраиваем VPN сервер на использование протокола SSTP
Прошло уже более года, после того как мы начали работу с VPN соединениями на базе протокола L2TP/IPsec и авторизацией через RADIUS. Накопился некоторый опыт использования описанной конфигурации, были выявлены её плюсы и минусы, сделаны определённые выводы. Опираясь на эти выводы, в данной заметке мы продолжим развитие темы настройки безопасных VPN соединений и рассмотрим шаги, необходимые для организации возможности работы по протоколу SSTP (Secure Socket Tunneling Protocol). Опыт использования L2TP/IPsec VPN показал, что при наличии внятной пошаговой инструкции по подключению, большинство пользователей способны без особых проблем настроить такое VPN-подключение самостоятельно. Но всё-таки всегда остаются индивидуумы, которые умудряются наделать ошибок даже в таких условиях, и поэтому мысль о необходимости упрощения процесса создания VPN-подключения всегда мелькала где-то на заднем фоне. К тому же в ряде ситуаций мы столкнулись с проблемой блокировки некоторых портов, необходимых для L2TP/IPsec VPN, обнаруженной на уровне интернет-провайдеров. Причём иногда дело доходило до абсурда, когда у одного и того-же интернет-провайдера трафик L2TP/IPsec в одном конце города транслировался беспрепятственно, а в другом конце города блокировался. Мы уже даже мысленно поделили для себя зоны разных интернет-провайдеров на сегменты, где L2TP/IPsec VPN будет работать без нареканий, и на зоны, где точно будут проблемы и нам потребуется подумать об альтернативных вариантах доступа к ресурсам локальной корпоративной сети. Помимо этого, были и случаи, когда командированные пользователи и «отпускники», удалённо пытающиеся подключиться через «гостиничный интернет», испытывали проблемы в силу всё тех же проблем с блокировкой нужных портов. Разумеется перед внедрением L2TP/IPsec VPN мы понимали все эти риски и в подавляющем большинстве проблемных ситуаций находилось какое-то обходное решение, но «осадочек» от каждой такой ситуации оставался неприятный. Я начал вспоминать, почему же ранее мой выбор пал именно на L2TP/IPsec. Определяющих факторов было два – приемлемый уровень безопасности и поддержка более широкого круга клиентских ОС. Помню, что в то время меня заинтересовал протокол SSTP, но было пару факторов, которые
↧
Октябрьские обновления безопасности Windows вызывают сбой работы приложений, использующих интерфейс Поставщика OLE DB для Jet (Microsoft.Jet.OLEDB.4.0)
В Октябре был выпущен ряд обновлений, относящихся к категории обновлений безопасности Windows, установка которых может вызвать ошибки в приложениях, использующих программный интерфейс устаревшего Поставщика OLE DB для Jet (Microsoft.Jet.OLEDB.4.0), например, при попытке программного доступа в Microsoft Office Excel или Access версии 2007 и более старых версий Office или сторонних приложений, таких как 1С, самописных АРМ-ов и т.п., использующих данный интерфейс. Перечень обновлений (то, что удалось найти), установка которых порождает проблему : Windows 7, Windows Server 2008 R2 KB4041681 , KB4041678 , KB4041686 Windows Server 2012 KB4041690 Windows 8.1, Windows Server 2012 R2 KB4041693 , KB4041687 Windows 10 1507 (RTM) KB4042895 Windows 10 1607, Windows Server 2016 KB4041691 Windows 10 1703 KB4041676 Ошибка, которая может возникать при попытке вызова Поставщика OLE DB для Jet после установки данных обновлений: Unexpected error from external database driver (1). (Microsoft JET Database Engine) ...или... "Непредвиденная ошибка с внешнего драйвера базы данных (1). (Microsoft JET Database Engine)". Другие примеры ошибок, которые могут возникать в данной ситуации: [Microsoft][Driver ODBC Excel] Reserved error (-5016). [Microsoft][ODBC Excel Driver] General Warning Unable to open registry key 'Temporary (volatile) Jet DSN for process Собственно, данная проблема описана в соответствующих статьях KB к выше обозначенным обновлениям в перечне известных проблем: В качестве решения проблемы предлагается использование более современного Поставщика, например Microsoft Access Database Engine 2010 (Microsoft.ACE.OLEDB.12.0) или новее. Если же оперативное изменение Ваших приложений, использующих Microsoft.Jet.OLEDB.4.0, невозможно, то лучше воздержаться от установки выше обозначенных обновлений, по крайней мере, до тех пор, пока не будут выпущены "обновления на обновления", исправляющие данную проблему. По некоторой информации совсем недавно были выпущены обновления, направленные на решение проблемы для Windows 7 и Windows 8.1, но, по уже традиционному для Microsoft сценарию, эти обновления оказались кривыми и в данный момент они недоступны для загрузки: Windows 7, Windows Server 2008 R2 KB4052234 Windows Server 2012 KB4052235 Windows 8.1, Windows
Сообщение Октябрьские обновления безопасности Windows вызывают сбой работы приложений, использующих интерфейс Поставщика OLE DB для Jet (Microsoft.Jet.OLEDB.4.0) появились сначала на Блог IT-KB.
↧
Способы смены пароля учётной записи пользователя в RDP-сессии
При использовании удалённого подключения к операционным системам Microsoft Windows/Windows Server по протоколу RDP в некоторых случаях может возникать потребность в смене пароля учётной записи пользователя. При этом инициатором смены пароля в разных ситуациях может выступать как сам пользователь, так и администратор Windows-системы. В некоторых сценариях может получиться так, что, казалось бы, несложная задача смены пароля может стать не такой уж и простой. Поэтому в данной записи я попробую собрать информацию о самых разнообразных способах смены пароля учётной записи пользователя в RDP-сессии. Способ №1 - "Горячие" клавиши В случае, если пользователю Windows необходимо самостоятельно изменить пароль своей учётной записи, то в стандартной Windows-сессии пользователем может использоваться всем известное сочетание "горячих" клавиш Ctrl-Alt-Del. Это сочетание клавиш вызывает специальный экран Безопасности Windows (Windows Security), с которого доступна функция изменения пароля: Если же речь заходит об использовании горячих клавиш в RDP-сессиях, то стоит заметить то, что во избежание перехвата некоторых сочетаний клавиш локальной клиентской системой (системой, с которой запускается RDP-клиент), перенаправление сочетаний клавиш Windows должно быть явно разрешено в свойствах RDP-клиента. Например в клиенте mstsc.exe, встроенном в Windows, данную опцию можно включить на закладке управления локальными ресурсам. В стандартной первичной RDP-сессии для вызова специального экрана Безопасности Windows с функцией изменения пароля используется сочетание клавиш: Ctrl-Alt-End В случае использования вложенных RDP-сессий (второго и последующего уровней), то есть когда из одной RDP-сессии открывается другая RDP-сессия, стандартное сочетание клавиш работать не будет. В разных источниках в интернете можно найти информацию об использовании более сложных сочетаний клавиш, таких как Ctrl-Alt-Shift-End или Shift-Ctrl-Alt-End. Однако мои эксперименты с Windows 10/Windows Server 2012 R2 показали, что данные сочетания клавиш попросту не работают (возможно они работали в ранних версиях ОС Windows). В этом случае на выручку нам может прийти следующий способ. Способ №2 - Экранная клавиатура В составе Windows имеется приложение "Экранная клавиатура" (On-Screen Keyboard), расположенное по умолчанию в %SystemRoot%\System32\osk.exe. Используя это
Сообщение Способы смены пароля учётной записи пользователя в RDP-сессии появились сначала на Блог IT-KB.
↧
↧
Ошибка проверки подлинности при подключении к удалённому рабочему столу Windows RDS …"Причиной ошибки может быть исправление шифрования CredSSP"
Информация об уязвимости в провайдере безопасности CredSSP ОС Windows была опубликована 13.03.2018 в документе CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability. В этом документе можно найти ссылки на обновления безопасности, которые были выпущены для закрытия этой уязвимости. Выпущенные обновления относятся к механизмам CredSSP, как в клиентских, так и в серверных ОС Windows. При этом неправильная последовательность развёртывания обновлений, касающихся CredSSP, может привести к неожиданным последствиям. Например, если перечисленные в документе мартовские обновления не были установлены на стороне сервера служб удалённых рабочих столов (Remote Desktop Services\RDS), но при этом на клиентских Windows-системах разворачивается выпущенное 08.05.2018 кумулятивное обновление (Monthly Rollup), получится так, что клиенты больше не смогут подключиться к RDS-серверу, получив ошибку проверки подлинности с отсылкой на исправление безопасности CredSSP: Это связано с тем, что майские обновления приводят к форсированному применению более высокого уровня безопасности CredSSP для исключения возможности эксплуатации ранее обнаруженной уязвимости. Из информации о ревизиях CVE-2018-0886: Microsoft is releasing new Windows security updates to address this CVE on May 8, 2018. The updates released in March did not enforce the new version of the Credential Security Support Provider protocol. These security updates do make the new version mandatory. For more information see "CredSSP updates for CVE-2018-0886" located at https://support.microsoft.com/en-us/help/4093492. Более подробную информацию о вносимых в систему изменениях и вариантах использования режимов работы CredSSP можно получить из статьи KB4093492 - CredSSP updates for CVE-2018-0886. Помимо служб RDS, замечено, что отсутствие обновления для CredSSP на стороне серверов виртуализации Hyper-V также может привести к невозможности подключения к консолям виртуальных машин при попытке доступа с обновлённых клиентских систем через консоли управления Hyper-V Manager или SCVMM. Учитывая то обстоятельство, что патченный клиент не сможет подключаться к непатченному серверу, важно соблюсти корректную последовательность развёртывания обновлений из службы Windows Update/WSUS, описанных в CVE-2018-0886. То есть, сначала планируем и разворачиваем обновления безопасности на стороне серверов RDS, а затем
Сообщение Ошибка проверки подлинности при подключении к удалённому рабочему столу Windows RDS …"Причиной ошибки может быть исправление шифрования CredSSP" появились сначала на Блог IT-KB.
↧
Июльские обновления Windows Server могут нарушить работу Exchange Server, SQL Server, IIS
В блоге Microsoft Exchange Team Blog на днях была опубликована информация о том, что Июльские обновления Windows Update для Windows Server, выпущенные 10.07.2018 г., могут нарушить работу Exchange Server. Позднее, 17.07.2018, появилась информация о том, что выпущен набор корректирующих обновлений, которые будут устанавливаться поверх проблемных обновлений. Таблица исходных обновлений, создающих проблемы, и корректирующих эти проблемы обновлений выглядит следующим образом: Операционная система Проблемное обновление Корректирующее обновление Windows Server 2016 KB4338814 KB4345418 Windows Server 2012 R2 KB4338824 KB4345424 KB4338815 KB4338831 Windows Server 2012 KB4338820 KB4345425 KB4338830 KB4338816 Windows Server 2008 R2 SP1 KB4338823 KB4345459 KB4338818 KB4338821 Windows Server 2008 KB4295656 KB4345397 Судя по статьям KB для корректирующих обновлений, исходные обновления могут вызвать проблемы не только с Exchange Server, но и с службами веб-сервера IIS и SQL Server. И это только то, что официально подтверждено на данный момент. И исходные и корректирующие обновления уже доступны в службах Windows Update, поэтому следуют обратить особое внимание на то, что при планировании развёртывания исходных обновлений очень желательно включать развёртывание соответствующих корректирующих обновлений.
Сообщение Июльские обновления Windows Server могут нарушить работу Exchange Server, SQL Server, IIS появились сначала на Блог IT-KB.
↧
Ошибка "SoapException: Fault occurred"при синхронизации WSUS на Windows Server 2012 R2 с онлайн каталогом Windows Update
При использовании WSUS на базе Windows Server 2012 R2 было замечено, что в последнее время наблюдались временные отказы при синхронизации метаданных с онлайн службой Windows Update. Синхронизация не работала несколько дней в Июле, затем в конце Июля опять заработала. И вот теперь ситуация снова повторяется, однако, судя по всему, рассчитывать на самовосстановление сервиса уже не приходится. Теперь при каждой попытке выполнить синхронизацию из консоли WSUS стала воспроизводится одна и та же "непредвиденная ошибка". Ход выполнения синхронизации и ошибку, возникающую при синхронизации можно увидеть на сервере WSUS в лог-файле, расположенном в конфигурации по умолчанию в пути: C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log ... SoapException: Fault occurred at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetUpdateData(Cookie cookie, UpdateIdentity[] updateIds) at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetUpdateData(UpdateIdentity[] updateIds, List`1 allMetadata, List`1 allFileUrls, List`1& updatesWithSecureFileData, Boolean isForConfig) at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.GetUpdateDataInChunksAndImport(List`1 neededUpdates, List`1 allMetadata, List`1 allFileUrls, Boolean isConfigData) at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect) ... Выяснилось то, что, согласно статьи 4482416 - WSUS synchronization fails with SoapException, с начала Июля этого года точка подключения для серверов WSUS изменилась с адреса, который использовался прежде, (https://fe2.update.microsoft.com/v6) на новый адрес: https://sws.update.microsoft.com. Как это ни странно, Microsoft не выполнила автоматической корректировки точки подключения посредствам какого-нибудь очередного обновления WSUS, а отделалась выше указанной статьёй. Информация в статье применима к роли WSUS, развёрнутой на системах: Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 В нашем случае на сервере WSUS достаточно оказалось выполнить фрагмент PS-кода, предложенного для решения проблемы в статье: [void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") $server = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer() $config = $server.GetConfiguration() # Check current settings before you change them $config.MUUrl $config.RedirectorChangeNumber # Update the settings if MUUrl is https://fe2.update.microsoft.com/v6 $config.MUUrl = "https://sws.update.microsoft.com" $config.RedirectorChangeNumber = 4002 $config.Save(); iisreset Restart-Service *Wsus* -v Данный фрагмент должен успешно отработать и на Windows Server 2012 и на Windows Server 2012 R2. В случае, если сервер WSUS всё ещё работает на базе ранних версий,
Сообщение Ошибка "SoapException: Fault occurred" при синхронизации WSUS на Windows Server 2012 R2 с онлайн каталогом Windows Update появились сначала на Блог IT-KB.
↧
Ноябрьские накопительные обновления Windows Server могут вызывать проблемы с Kerberos
По появившейся на днях информации, развёртывание Ноябрьских кумулятивных обновлений для ОС Windows Server может привести к проблемам в работе механизмов делегирования в сценариях Single Sign-On (SSO) при использовании протокола Kerberos. В частности, установка кумулятивного обновления на контроллеры домена Active Directory может привести к нештатной работе таких приложений, как SQL Server, IIS, WAP, ADFS и прочих. В перечень обновлений, для которых были замечены проблемы входят: KB5007206 - Windows Server 2019 KB5007192 - Windows Server 2016 KB5007247 - Windows Server 2012 R2 KB5007260 - Windows Server 2012 KB5007236 - Windows Server 2008 R2 SP1 KB5007263 - Windows Server 2008 SP2 Учитывая то, что перечисленные накопительные обновления доступны для развёртывания через службу WSUS, следует более внимательно отнестись к их предварительному тестированию перед развёртыванием в продуктивной среде. Появилась дополнительная информация о том, что для тех, кто уже развернул в продуктивной среде перечисленные выше кумулятивы и столкнулся с проблемами работы Kerberos, есть набор срочных обновлений, исправляющих эти проблемы: KB5008602 для Windows 10 1909 / Server 2019 KB5008601 для Windows 10 1607 / Server 2016 KB5008603 для Windows Server 2012 R2 KB5008604 для Windows Server 2012 KB5008605 для Windows Server 2008 R2 На текущий момент времени данные обновления не доступны для автоматического развёртывания в службе WSUS, но при необходимости их можно скачать с сайта Microsoft Update Catalog и вручную импортировать на внутренний сервер WSUS. В средах, где нет жёстких требований к наличию всех самых актуальных обновлений Windows, возможно, имеет смысл воздержаться от развёртывания Ноябрьских кумулятивов и дождаться выпуска Декабрьских кумулятивов, которые (предположительно) могут включать в себя исправление обнаруженных проблем с работой протокола Kerberos.
Сообщение Ноябрьские накопительные обновления Windows Server могут вызывать проблемы с Kerberos появились сначала на Блог IT-KB.
↧
↧