Многие клиентские компьютеры не сообщали информацию на сервер за последние 30 дней
Каждый администратор осознает важность своевременных обновлений, особенно если это касается критических обновлений безопасности. Однако с ростом сети и увеличением числа программных продуктов это становится весьма непростой задачей. Значит самое время развернуть WSUS (Windows Server Update Services ) - локальный сервер обновлений в вашей сети.
Этим вы убьете сразу несколько зайцев: значительно уменьшите загрузку канала и потребляемый интернет трафик, а также получите в руки мощный инструмент для контроля и управления процессом обновлений. Отныне все локальные ПК будут обновляться с вашего сервера и устанавливать только выбранные вами обновления.
Приступим. Перед установкой WSUS следует подготовить сервер, мы будем использовать Windows Server 2008 R2, однако с небольшими поправками все сказанное будет справедливо для других версий Windows Server. Что нам понадобится:
WSUS может хранить обновления в собственной БД или использовать SQL-сервер, последнее более предпочтительно с точки зрения производительности. Если в вашей сети уже развернут SQL-сервер можно использовать его, иначе вполне подойдет бесплатный SQL Express.
Получить все необходимые компоненты можно на сайте Microsoft:
При скачивании обращаем внимание на разрядность, для 64-битной ОС скачиваем 64-битные версии продуктов.
Добавив необходимые роли, установим Report Viewer и SQL Server c параметрами по умолчанию. Все готово, можно устанавливать WSUS.
Запустив инсталлятор, выбираем установку сервера и консоли администрирования, папку установки. В параметрах базы данных указываем наш SQL-сервер. Остальные настройки можно оставить по умолчанию.
Сразу после установки запустится мастер начальной настройки. Все опции довольно просты и понятны. В параметрах синхронизации указываем откуда наш сервер будет получать обновления: с сервера Microsoft или с другого WSUS сервера. Последний вариант следует использовать если вам требуется развернуть дополнительный сервер обновлений, например, для филиала. В этом случае подчиненный сервер будет получать только одобренные вами обновления.
На следующей закладке, при необходимости, указываем параметры прокси-сервера, и выполняем первичное подключение. Будет загружена информация от вышестоящего сервера: списки продуктов, типов обновлений и т.д.
При выборе продуктов не жадничайте, указывайте только то, что вам реально нужно, впоследствии вы всегда сможете изменить данный список.
На следующей странице укажите какие классы обновлений вы хотели бы получать, здесь все зависит от политики обновлений на вашем предприятии. Следует помнить, что обновления драйверов и пакеты новых функций крайне не рекомендуется разворачивать автоматически, без предварительного тестирования. Если у вас нет возможности этим заниматься, то указывать эти классы вам ни к чему.
Не забудьте также задать расписание для синхронизации с вышестоящим сервером. На этом первоначальная настройка закончена.
Открыв консоль (доступна в меню Администрирование), первым делом запустите ручную синхронизацию, чтобы скачать все имеющиеся на сегодняшний день обновления для выбранных продуктов. В зависимости от того, чего и сколько вы выбрали при настройке, а также скорости вашего подключения это может занять продолжительное время.
Также советуем настроить опцию Настройка автоматического обновления , которая полностью повторяет аналогичную настройку на клиентских ПК. Через некоторое время, необходимое для обновления групповых политик, компьютеры вашей сети начнут подключаться к серверу и получать обновления.
Если ваша сеть имеет одноранговую структуру, то вам придется настраивать каждый ПК в отдельности. Делается это через Редактор локальной групповой политики (Пуск - Выполнить - gpedit.msc), сам процесс настройки полностью аналогичен вышеописанному.
Контролировать количество ПК и их статус вы можете в разделе Компьютеры консоли администрирования.
Информации вполне достаточно, чтобы быстро оценить общую ситуацию и обратить внимание на проблемные места. Красные крестики указывают на то, что на данных ПК произошли ошибки в обновлении, с каждым таким случаем надо разбираться в отдельности. По каждому обновлению формируется детальный отчет, содержащий все необходимые для анализа проблемы данные.
Также рекомендуем разбить ПК на группы, для каждой группы можно назначить свою политику обновлений. Так в отдельную группу можно выделить сервера, для которых автоматически устанавливать только критические обновления безопасности.
Вот мы и подошли к еще одной важной настройке сервера - автоматическом одобрении. Клиентские ПК могут получать только одобренные обновления, но каждый раз делать все вручную нереально, поэтому часть обновлений можно одобрять автоматически. Откроем Параметры - Автоматические одобрения и активируем уже имеющуюся там политику, которая позволяет автоматически устанавливать критические обновления и обновления безопасности.
Здесь вы можете создавать свои правила и назначать их любой группе ПК. Например мы создали правило: автоматически одобрять все обновления MS Office группы Рабочие станции.
Просмотреть все доступные обновления можно в разделе Обновления, здесь же можно одобрять их вручную. Мы рекомендуем завести один или несколько тестовых ПК (можно виртуальных) и тестировать на них обновления и пакеты новых функций и только после этого одобрять обновления для установки. Одобрить обновления можно как для всех ПК, так и для группы, в качестве примера мы одобрили установку пакета Silverlight для группы Рабочие станции.
В качестве обслуживания сервера стоит время от времени (где-то раз в месяц) проводить очистку сервера. Это позволит избежать черезмерного увеличения размеров базы за счет удаления невостребованных, уже не нужных и неодобренных вами обновлений.
Клиенты WSUS не хотят обновляться после смены сервера?
Тогда мы идем к вам. (С)
У всех бывали ситуации, когда что-нибудь переставало работать. В данной статье речь пойдет о WSUS (более подробную информации о WSUS можно получить и ). А точнее о том, как заставить клиентов WSUS (т.е. наши с вами компьютеры) заново получать обновления после переноса или восстановления существующего сервера обновлений.
Итак, ситуация следующая
Сдох сервер WSUS. Точнее RAID-контроллер аж 2000 года выпуска. Но радости этот факт не прибавил. После непродолжительной возни (с попытками восстановить RAID, загубленный помирающим контроллером), было принято решение послать все развернуть новый WSUS-сервер.
В итоге мы получили работающий WSUS, на который почему-то не коннектились клиенты.
Моменты: WSUS привязан с FQDN через внутренний DNS-сервер, WSUS-сервер прописан в групповых политиках и распространяется на клиентов через AD, настройки для сервера по-умолчанию, перед началом всех действий обновите сам WSUS и выполните синхронизацию обновлений.
После анализа ситуации, было выявлено несколько ключевым моментов
- Клинч клиента (речь о wuauclt) при попытке соединиться с SID старого сервера WSUS.
- Проблема с неустановленными обновлениями, скачанными со старого WSUS-сервера.
- Парковка служб влияющих на работу wuauclt (речь о wuauserv, bits и cryptsvc). Парковка произошла по разным причинам, которые детально не анализировались.
Опишу, что делается (для особо любопытных)
Паркуем службу сервера обновлений, чистим дескриптор безопасности службы связи с WSUS, удаляем имеющиеся обновления от предыдущего WSUS, чистим реестр от упоминаний о предыдущем WSUS, стартуем службы автоматического обновления (wuauserv), фоновую интеллектуальную службу передачи (bits) и службу криптографии (cryptsvc), в самом конце принудительно стукаемся в WSUS с обнулением авторизации, обнаружением нового WSUS и генерацией отчета на сервер.
И как всегда: все действия описанные выше и ниже вы выполняете на свой страх и риск. Пожалуйста, удостоверьтесь в том что все необходимые данные сохранены до выполнения скрипта.
Net stop wuauserv sc sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU) del /f /s /q %windir%\SoftwareDistribution\download\*.* REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f net start wuauserv && net start bits && net start cryptsvc wuauclt /resetauthorization /detectnow /reportnow
Такую серверную роль как Windows Server Update Services (WSUS) целесообразно использовать как в мелких компаниях, насчитывающих от 10 компьютеров, так и в крупных корпорациях. В отличие от таких серверных ролей, как доменные службы или серверов электронной почты, для серверов обновлений WSUS вам не обязательно разворачивать отказоустойчивые сервера, так как автоматизация обновления клиентских компьютеров не является самой критичной задачей в бизнес процессах.
Сценарии развёртывания серверов обновлений:
Простое развертывание WSUS-серверов: Многие маленькие и средние организации в своей производственной среде для распространения обновлений, используют именно данную модель. Простые решения развертывания WSUS-серверов обычно представляют собой модель с развернутым сервером обновлений, который расположен внутри интрасети, защищенной межсетевым экраном и обслуживающим клиентские компьютеры интрасети. Для загрузки обновлений WSUS-сервер синхронизируется с серверами Центра обновления Microsoft.
Иерархическое развертывание WSUS-серверов: Как понятно с названия модели, предыдущая модель развертывания WSUS-серверов является базовой, но при необходимости вы можете создавать сложные иерархии серверов WSUS. Прежде всего, стоит учесть, что для синхронизации с Центром обновлений Microsoft вам достаточно иметь только один WSUS-сервер, а все остальные WSUS-серверы должны подключаться к текущему. При связывании нескольких WSUS-серверов у вас образуется так называемая иерархия, состоящая из вышестоящего и подчиненного WSUS-серверов. Существует два способа установки связи между WSUS серверами.
- Автономные серверы WSUS. В этом случае, в процессе синхронизации вышестоящий WSUS-сервер предоставляет все свои загруженные обновления одному или нескольким подчиненным серверам, но при всем этом процессе состояния утверждений или информация о группе компьютеров на клиентские рабочие места не передается. Администрирование всех подчиненных серверов WSUS выполняется отдельно от развертывания обновлений на клиентские компьютеры;
- Режим репликации. В случае развертывания данной модели, вышестоящий сервер WSUS передает все свои обновления, состояния утверждений и информацию о группах своим подчиненным серверам. При этом, подчиненные реплицируемые сервера наследуют все утверждения, причем они не могут выполнять административные задачи на своих вышестоящих WSUS-серверах.
Данная конфигурация развертывания серверов обновлений удобная для большинства производственных случаев, включая организации с филиалами. Модель иерархического развертывания WSUS-серверов рационально использовать для загрузки обновлений из Центра обновлений Microsoft и последующей установки этих обновлений посредством подчиненных серверов, тем самым разгружая широкополосное соединение с Интернетом. Целесообразно использовать такую конфигурацию в окружении, где один WSUS-сервер не в состоянии самостоятельно обеспечить развертывание обновлений в существующем парке компьютеров. По всем рекомендациям желательно использовать не более чем трехуровневую иерархию WSUS-серверов, так как при последующем распространении обновлений время задержки все время увеличивается. В любой модели и при любой конфигурации, подчиненный сервер обязан регулярно выполнять синхронизацию с вышестоящим сервером обновлений, образуя между собой неподдерживаемый замкнутый цикл. При изменении протокола соединений между серверами, для обеспечения максимальной защиты всей цепочки серверов обновлений, во время настройки иерархии WSUS-серверов, для настройки автоматических обновлений вам нужно указать наиболее удаленный подчиненный сервер. В том случае, если в вашей организации насчитывается несколько подчиненных серверов обновлений, вам не стоит настраивать на них синхронизацию с вышестоящими серверами обновлений в одно и то же время, что может привести к перезагрузке вышестоящего сервера. Для этой конфигурации лишь один WSUS-сервер загружает и управляет обновлениями непосредственно с серверов Microsoft, а все остальные серверы конфигурируются как реплики.
Группы компьютеров
Для всех моделей развертывания серверов WSUS, причем, модель простого развертывания не исключение, важнейшей частью при развертывании являются группы компьютеров. В большинстве организаций, одновременно все обновления не развертываются на все компьютеры. А для управления компьютерами, которые будут получать обновления, серверы WSUS позволяют настраивать группы компьютеров, а сами обновления уже развертывать для одной или нескольких групп одновременно. По умолчанию, в консоли WSUS вы можете найти две группы компьютеров: «Все компьютеры» и «Не назначенные компьютеры». По умолчанию, когда клиентский компьютер синхронизируется с WSUS-сервером, он автоматом добавляется в обе группы, созданные по умолчанию. Затем, из группы «Не назначенные компьютеры», вы можете переместить компьютеры в специально отведенную для них группу, так как данная группа содержит только те компьютеры, для которых не было назначено членство в созданных вами группах. В свою очередь, группа «Все компьютеры» позволяет распространять целевые обновления на все компьютеры вашей организации, независимо от того, членами каких групп являются компьютеры. Возьмём для примера случай простого развертывания WSUS с тремя настраиваемыми группами, которые называются «Тестирование», «Пилотная группа» и «Производство». Группа тестирования содержит несколько компьютеров, которые находятся в лабораторной среде и предназначены для проверки корректности работы механизма распространения обновлений. Если тестирование проходит удачно, то обновления будут развертываться в следующей группе. После тестирования обновления разворачиваются в пилотной группе, которая состоит из компьютеров ИТ-отдела, где квалифицированные специалисты могут устранить появившиеся после развертывания обновлений неисправности. Затем, если пилотное развертывание прошло без инцидентов, то вы можете развертывать обновления на производственных компьютерах, которые расположены в среде «Производство».
Зачастую ошибки в ходе синхронизации могут возникать из-за того, что было неправильным образом сконфигурировано одно из следующих предпосылок:
- при условии, что активная точка ПО-обновления была установлена в рамках системного сервера на удаленном веб-сайте, необходимо установить административную WSUS-консоль на сервер web-сайта;
в случае, когда связь между центром обновления MS либо сервером ПО-обновления и активной точкой обновления ПО установлена с проверкой учетных инфо-данных при использовании proxy-сервера, потребуется сконфигурировать учетную запись прокси-сервера;
важно, чтобы настройки по портам для веб-сайта Windows Server Update Servises в IIS (Internet Information Services) и активной точки ПО-обновления были аналогичными;
«Администратор» и учетная запись ПК должна в рамках WSUS веб-сайта в IIS с сайтового сервера обеспечивать возможность полноценного доступа к виртуальным каталогам;
для синхронизации Microsoft с центром обновлений в рамках центрального web-сайта необходимо всегда настраивать активную точку ПО-обновлений. В процессе создания самой первой точки ПО- обновления на web-сайте данный параметр будет сконфигурирован в автоматическом режиме. Тем не менее, в случае если он будет изменен через административную WSUS-консоль, он не будет сбрасываться Configuration Manager-ом таким же образом, как это происходит с прочими настройками Windows Server Update Servises.
WCM.log
Как найти устаревшие учетные записи компьютеров
В решении нашей задачи мы будем использовать разные средства, как графические, так и консольные, в виде скриптов на Powershell, но обо всем по порядку.
Wsyncmgr.log
Через Powershell
За, что я люблю Poweshell, так это за его огромные возможности, у него для Active Directory отдельный модуль с командлетами, позволяющими производить большое количество манипуляций. Сразу приведу готовый код, который ищет компьютеры, от которых не было вестей 120 дней и выводит все это дело в тестовый файл с датой последнего обращения.
$date_with_offset= (Get-Date).AddDays(-120)
Get-ADComputer -Properties LastLogonDate -Filter | Sort LastLogonDate | FT Name, LastLogonDate -AutoSize | Out-File c:\Script\services.txt
Замечательно список мы с вами научились получать, и вы можете посмотреть время последнего обращения компьютера к контроллеру домена. Идем дальше, теперь я хочу, чтобы данные компьютеры были выключены в Active Directory и были перемещены в отведенную под это дело OU. Вот пример кода.
$date_with_offset= (Get-Date).AddDays(-120)
$comps = Get-ADComputer -Properties LastLogonDate -Filter | Sort LastLogonDate
foreach ($comp in $comps)
Get-ADComputer -Properties LastLogonDate -Filter | Sort LastLogonDate | FT Name, LastLogonDate -AutoSize | Out-File c:\Script\services.txt
Тут все отключенные компьютеры будут перемещаться в организационное подразделение Мск Л. рабочие станции на удаление. И далее я сделал, вывод в txt файл, чтобы видеть, какие именно учетные записи были отключены.
Далее вы этот скрипт можете повесить на контроллеры домена, через групповую политику и выполнять хотя бы раз в месяц. Я лично такие компьютеры через неделю удаляю.
Дополнительные сведения
Временное решение
Чтобы обойти эту проблему, измените цикл обнаружения на значение в разрешенном диапазоне. С помощью групповой политики можно управлять время между каждого цикла обнаружения от 1 часа до 22 часов. Например при изменении частоты цикл обнаружения по умолчанию 22 часа на 11 часов, 7 500 клиентов уменьшается количество клиентов, которые могут поддерживать сервер WSUS.
Если клиентские компьютеры не отчет обратно на сервер WSUS после изменения частоты цикл обнаружения, необходимо удалить все текущие события из таблицы tbEventInstance. Чтобы сделать это, выполните следующую команду в анализаторе запросов SQL:
Инструкция TRUNCATE TABLE dbo.tbEventInstanceКроме того можно остановить процесс автоматического удаления, а затем увеличить частоту процесс удаления. После увеличения частоты процесс удаления, WSUS удаляет строки в более мелкие части, но сохраняет размер таблицы tbEventInstance.
Чтобы остановить процесс автоматического удаления и задать частоту процесс удаления до 1 часа, выполните следующую команду в анализаторе запросов SQL:
Обновление dbo.tbConfigurationB НАБОР AutoPurgeDetectionPeriod = 1Эта команда запускает процесс удаления каждый час. После запуска этой команды WSUS удаляет 24 000 событий в день со скоростью 1000 событий в час. Это максимальная частота, можно задать для процесса удаления.
Чтобы вычислить правильный автоматического удаления частоты и частоты правильное определение цикла, необходимо знать количество клиентов WSUS.
Используйте следующие формулы для расчета минимальную частоту процесс удаления и частоту обнаружения цикла:
Минимальное удаление процесса частоты: (24/DF) x CL
Частота обнаружения цикла: (CL/PF) x 24Примечание. DF равна частоте цикл обнаружения, CL — количество клиентов WSUS и PF-это частота очистки минимальное.
Например при наличии 4 000 клиентов WSUS и частоту обнаружения цикла равным 8 циклов в день, около 32 000 событий могут регистрироваться в таблицу tbEventInstance. Максимальное число событий, которые могут быть удалены в процессе удаления в день — 24 000 событий, если задать частоту удаления до 1 часа. Таким образом можно снизить частоту обнаружения цикла, таким образом, количество событий, созданных клиентами меньше 24 000.
Проверяем наличие ошибок
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе "Относится к".
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте данное исправление только в тех системах, которые имеют данную проблему.
Если исправление доступно для скачивания, имеется раздел "Пакет исправлений доступен для скачивания" в верхней части этой статьи базы знаний. Если этого раздела нет, отправьте запрос в службу технической поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме "Пакет исправлений доступен для скачивания" отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки предварительные компоненты не требуются.
Необходимость перезагрузки
Не требуется перезагружать компьютер после установки данного исправления.
Сведения о замене исправлений
Это исправление не заменяет других исправлений.
Сведения о файлах
Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, откройте вкладку Часовой пояс элемента "Дата и время" панели управления.
Полезные ключи командлета Get-ADComputer
Что вам еще может пригодиться у команды Get-ADComputer, это больше для себя подсказка. Напоминаю, чтобы им воспользоваться, нужно загрузить модуль Active Directory, через команду
Теперь можно получить справку по команду Get-ADComputer, через команду:
Как видите, у команды очень много ключей и богатые возможности.
Я очень часто ее использую, когда мне нужно получить о компьютерной учетной записи максимальное количество данных, вот пример.
В данном выводе команды вы увидите основные значения:
- DistinguishedName
- SID >кто не вкурсе что такое SID, то смотрите по ссылке.
- DNSHostName
Если вам вдруг не хватает данных, то вы можете вывести все доступные поля.
Если хотите вывести конкретные поля, то выполните вот такую конструкцию, через | перечисляются нужные поля
Выше я писал уже, о том как сделать вывод всех компьютеров по параметрам, но тут то же продублирую в более простом виде. В качестве значений, так же можете указывать, все что вам нужно.
Выберем все компьютеры с операционной системой Windows 10
Get-ADComputer -Filter < OperatingSystem -Like '*Windows 10*' >-Properties OperatingSystem | Select Name, OperatingSystem | Format-Table -AutoSize | Out-File C:\Script\server_system.txt
На выходе получаем файл со списком компьютеров.
Надеюсь вы поняли принцип поиска неактивных компьютеров в вашей локальной сети, и уверен, что вы сможете сами подобрать дополнительные сценарии использования powershell для себя.
Клиентские компьютеры предоставляют отчет обратно на сервер Microsoft Windows Software Update Services (WSUS). Кроме того могут возникнуть следующие неполадки:
Случаи аварийной остановки процесса синхронизации по неустановленным причинам
В случае если после проверки wsyncmgr.log вам не удалось определить причину, по которой произошел сбой, вполне возможно, что он был порожден не одним сторонним фактором.
Приведем возможные проблемы синхронизации и пути их решения:
Точка ПО-обновления не была установлена. В данном случае потребуется установить точку ПО-обновления в рамках каждого Configuration Manager – сайта.
Была допущена ошибка в proxy-параметрах ПО-обновления. В случае необходимости нужно правильным образом сконфигурировать порт, имя сервера и учетные данные.
На компьютере с SQL-Server может не хватать памяти или же он имеет не оптимальную конфигурацию. В данном случае следует попросить у администратора SQL-сервера осуществить проверку эффективности и, если возникнет такая необходимость, произвести настройку.
Все началось с того, что на клиентских машинах я перестал получать обновления и выпадала ошибка. Зайдя на вой сервер WSUS в логах Просмотра событий я увидел две ошибки. Первая это последняя попытка синхронизации каталогов оказалась не удачной, Код 10022.
Вторая ошибка это Многие клиентские компьютеры не сообщали информацию на сервер за последние 30 дней.
Погуглив ошибку я нашел решение, оно заключалось в том, что нужно было установить обновления KB2734608 , мне они к сожалению не подошли так как они рассчитаны на WSUS 3, а в Windows Server 2012 R2 идет уже WSUS 6. Но поискать в инете обновления я не поленился. В итоге получил аж 82, устанавливаем их.
После того как закончится обновление перезапускаем службу Внутренняя база данных Windows
После чего консоль уже отображает данные и WSUS работает.
В завершении стоит отметить, что для повышения быстродействия рекомендуется исключить следующие папки из области проверки антивируса:
Всем привет сегодня хочу поделиться своим опытом решения ошибки последняя попытка синхронизации каталогов оказалась не удачной в WSUS Windows Server 2012R2. Для начала давайте вспомним что это такое, Windows Server Update Services (WSUS) — сервер обновлений операционных систем и продуктов Microsoft. Программа бесплатно может быть скачана с сайта Microsoft и установлена на серверную ОС семейства Windows Server.
Все началось с того, что на клиентских машинах я перестал получать обновления и выпадала ошибка. Зайдя на вой сервер WSUS в логах Просмотра событий я увидел две ошибки. Первая это последняя попытка синхронизации каталогов оказалась не удачной, Код 10022.
Ошибка последняя попытка синхронизации каталогов оказалась не удачной в WSUS Windows Server 2012R2-01
Вторая ошибка это Многие клиентские компьютеры не сообщали информацию на сервер за последние 30 дней.
Ошибка последняя попытка синхронизации каталогов оказалась не удачной в WSUS Windows Server 2012R2-01-1
Погуглив ошибку я нашел решение, оно заключалось в том, что нужно было установить обновления KB2734608 , мне они к сожалению не подошли так как они рассчитаны на WSUS 3, а в Windows Server 2012 R2 идет уже WSUS 6. Но поискать в инете обновления я не поленился. В итоге получил аж 82, устанавливаем их.
Ошибка последняя попытка синхронизации каталогов оказалась не удачной в WSUS Windows Server 2012R2-02
Ошибка последняя попытка синхронизации каталогов оказалась не удачной в WSUS Windows Server 2012R2-03
После того как закончится обновление перезапускаем службу Внутренняя база данных Windows
Ошибка последняя попытка синхронизации каталогов оказалась не удачной в WSUS Windows Server 2012R2-04
После чего консоль уже отображает данные и WSUS работает.
Ошибка последняя попытка синхронизации каталогов оказалась не удачной в WSUS Windows Server 2012R2-05
В завершении стоит отметить, что для повышения быстродействия рекомендуется исключить следующие папки из области проверки антивируса:
Решение
Через оснастку active directory пользователи и компьютеры
Через ADUC можно получить список компьютер, по такому значению как последнее время изменения, которое по дате совпадает с параметром последнего логирования компьютера в Active Directory. Открываем active directory пользователи и компьютеры. Выбираем пункт сохраненные запросы и нажимаем создать запрос.
У вас откроется поле с созданием нового запроса к Active Directory. Задаем ему название, далее через кнопку обзор выбираем организационное подразделение, на которое следует натравить запрос, можете оставить и корень. Далее нажимаете кнопку запрос.
На вкладке пользователи выбираем пункт "Число дней со времени последнего входа в систему", я ставлю 60 дней, так как считаю, что таких командировок нет и компьютер уже точно не присутствует в локальной сети, и нет смысла хранения его учетной записи в базе контроллера домена.
Все, все параметры заданы и можно строить запрос к базе данных AD.
На выходе я получил список неактивных компьютеров в своей локальной сети, я называю их призраками. Они появляются, либо с поломкой техники, либо из-за халатности администратора. Простой пример системный администратор взял компьютер pyatilistnik01, для переустановки системы, в итоге при попытке ввода его в домен, он получает ошибку, о том, что такой компьютер уже есть и забивает на это, вводя другое имя, либо оставляет имя с генерируемое при установке системы, вида DESKTOP-4BA9AP5. В таких случаях помогает корпоративный стандарт именования компьютеров и автоматическое переименование на основании этих политик.
Зайдя в свойства любого компьютера, перейдите на вкладку объект, и посмотрите поле, изменен, оно будет совпадать по дате с полем LastLogonDate. В итоге я вижу, что данный компьютер не появлялся в сети с 14 ноября 2016 года, что дает мне мысли, о его удалении из базы NTDS.dit.
Как видите, хоть этот метод и графический, но не совсем удобный в плане автоматизации, так как подразумевает кучу ручной работы. К сожалению, выделив все компьютеры вы не сможете их отключить за один клик, вывод делаем все то же самое на powershell.
Как определить, является ли таблица tbEventInstance превысило 1 миллион строк
Запустите SQL Query Analyzer и подключитесь к локальному серверу.
В списке баз данных выберите SUSDB.
В окне запроса вставьте следующий запрос SQL:
При запуске Microsoft SQL Server Desktop Engine (WMSDE) (Windows), также можно использовать команду osql для проверки, является ли таблица tbEventInstance превысило 1 миллион строк. Чтобы сделать это, введите в командной строке следующую команду и нажмите клавишу ВВОД:
Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:
Описание 824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт
Сегодня сам себе поставил интересную задачу — удаленно установить на все компьютеры в домене через Kaspersky Security Center. Этот инструмент был выбран как самый удобный из доступных. Выбор был между:
Наверняка существует много других способов удаленной установки приложений, если Вы из тех читателей, которые знают об этих способах — прошу рассказать о них в комментариях.
Итак, основная цель — установка десктопного приложения Bitrix24 на все компьютеры в зоне моей ответственности. Ранее пробовал удаленную установку через active directory — безрезультатно. Удаленно устанавливать через psexec как-то не очень в плане скорости выполнения в будущем. Rinstall тоже достаточно замороченное приложение и с первого взгляда доверия не вызывает. Kaspersky Security Center Версия: 10.4.343 был выбран в качестве основного претендента для выполнения этой задачи как наиболее привлекательный на первый взгляд инструмент.
Для установки требуется sql сервер, в процессе установки инсталлятор предлагает поставить свою систему управления базами данных, но, так как у меня уже развернут sql сервер, то устанавливать лишнее ПО не было смысла. Сама установка заняла примерно 20-30 минут. В итоге получаем такое меню:
Как видно из рисунка в меню есть пункт «Удаленная установка», в нем есть подраздел «Инсталляционные пакеты». На открывшейся странице мы видим:
Как видите, на этой вкладке мы можем воспользоваться стандартными пакетами «Агент администрирования…» и «Kaspersky Endpoint Security…». Как я понимаю, первый пакет нужен как система мониторинга и оперативного удаленного доступа, в том числе для простой установки. Вообще, это достаточно мощная система администрирования. Второй из указанных пакетов — непосредственно антивирус + много много всего для удаленного контроля компьютера (контроль USB портов, контроль доступа в социальные сети, антивирусная защита, информирование пользователей о предстоящем техническом обслуживании и т.д.). Также есть возможность добавить собственный пакет, любое msi, exe приложение для установки, при создании пакета есть возможность указать параметры установки, например, в тихом режиме с параметром «/S».
Удаленно можно устанавливать программы и без агента, но с ним будет гораздо проще в будущем. Поэтому первоначально проще установить именно Агент администрирования, а уже потом остальные программы. Для установки необходимо обладать правами администратора на всех удаленных компьютерах, соответственно это могут быть:
- компьютеры в домене, при этом у вас есть права администратора домена.
- компьютеры в одноранговой сети (рабочая группа), в таком случае на каждом компьютере должен быть задан локальный администратор с идентичными аутентификационными данными (пара логин-пароль).
После установки агента список ваших возможностей существенно повысится, но мы достигли нашей главной цели — удаленная установка приложений на большую группу компьютеров в локальной сети (в том числе по ВПН). На этом я все на сегодня, особо в подробности не вдавался, так как разобраться что к чему можно самостоятельно, но если у Вас возникли вопросы, можете задать их в форме комментариев ниже, постараюсь помочь.
Клиент: Как подключиться к к клиентскому компьютеру в Kaspersky Security Center?
Консультант: Возможны 2 варианта подключения - RDP и Windows Desktop Sharing. Windows Desktop Sharing требует купить лицензию Kaspersky System Management (Управление Системами)
Клиент: Опишите подробнее метод удаленного подключения в Касперски?
Консультант: Kaspersky Security Center позволяет удаленно подключаться к управляемому компьютеру. Для этого в контекстном меню комьютера нужно выбрать опцию Подключиться к компьютеру. В зависимости от настроек интерфейса и типа лицензии можно использовать разные способы подключения:
— Создать новую сессию RDP — подключение осуществляется через Remote Desktop Protocol. Такой способ подключения доступен всегда, независимо от типа лицензии и настроек интерфейса
— Подключиться к существующей сессии RDP — подключение осуществляется с помощью технологии Windows Desktop Sharing. Сессия устанавливается поверх протокола RDP, поэтому на клиентском компьютере должно быть разрешено удаленное подключение через RDP. Преимущество такого подхода заключается в том, что доступ к удаленному компьютеру предоставляется нескольким участникам в рамках одной сессии, они называются sharer и viewer. То есть viewer видит все действия sharer на удаленном компьютере. Для использования технологии Windows Desktop Sharing необходимо иметь лицензию на функционал Systems Management . Для отображения команды Подключиться к существующей сессии RDP необходимо в настройках интерфейса Kaspersky Security Center включить опцию Включить Системное администрирование.
Клиент: Как провести аудит операций с файлами, контроль чтения и изменения указанных типов файлов? Где настроить параметры контроля, мониторинга и аудита секретных файлов?
Консультант: Администратор может вести мониторинг активности при удаленном подключении с помощью Windows Desktop Sharing, т.е. к каким файлам происходило обращение и были ли какие-то изменения в файлах. Аудит действий настраивается в политике Агента администрирования в секции Общий доступ к рабочему столу, по умолчанию аудит не выполняется. Администратор может дополнительно указать маски файлов, для которых отдельно будет отслеживаться доступ на чтение и на изменение.
Для использования всех возможностей администирования в Kaspersky Security Center необходимо приобрести дополнительную лицензию на продукт Управление Системами Kaspersky Systems Management
Предлагаем Вашей организации - бесплатный электронный ключ Kaspersky Systems Management для тестирования. - Купить Kaspersky Systems Management со значительной скидкой у Официального Партнера Лаборатории Касперского.
Клиент: Откуда и как Касперский собирает сведения о программах на компьютерах сети?
Консультант: Информация об установленных приложениях поступает через Агент администрирования. В качестве источника данных о программах выступает реестр Windows. При появлении в сети наблюдаемого приложения на Сервер администрирования передается соответствующее событие
Клиент: Можно подробнее о работе и настройках блока Реестр Программ в Касперский секьюрити Центр?
Консультант: Основная цель Реестра программ — предоставить администратору информацию об установленных в сети приложениях. Используя эту информацию, администратор видит, на каких компьютерах установлено то или иное приложение. Например, если в сети обнаружился интернет-браузер старой версии, администратор может принудительно обновить версию браузера на всех компьютерах.
Также Реестр программ может использоваться для отслеживания появления на компьютерах пользователей запрещенного в компании программного обеспечения. Например, в компании может быть запрещено использование IM-мессенджеров. Обнаружив в списке запрещенную программу, администратор может принять меры по ее удалению.
Клиент: Значит Агентами администрирования сканируется постоянно реестр?
Консультант: Информация об установленных на клиентских компьютерах программах отображается в контейнере Реестр программ узла Программы и уязвимости. За сбор данных отвечает Агент администрирования. Информация берется из веток реестра, формирующих список Programs and Features (в старых версиях операционных систем — Add/Remove Programs).
В зависимости от разрядности операционной системы, отслеживаются изменения в следующих ветках:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
Сканирование веток реестра происходит при старте Агента администрирования или при изменениях в ветке реестра. За передачу информации на Сервер администрирования отвечает опция Информация об установленных программах в свойствах политики Агента администрирования. По умолчанию опция включена, то есть Сервер получает информацию об установленных приложениях, при желании ее можно отключить. В контейнере Реестр программ есть возможность задать конкретные приложения, для которых будут публиковаться события об установке программы на клиентском компьютере.
Например, если в компании существует политика, регламентирующая список запрещенных или нежелательных для использования приложений, администратор может задать список приложений и получать уведомления об их установке по электронной почте.
Список наблюдаемых приложений задается в свойствах контейнера Реестр программ в секции Наблюдаемые программы. Чтобы получать уведомления об установке/удалении наблюдаемых программ, нужно указать тип уведомления (по почте, по SNMP и т.д.) для события Установлена наблюдаемая программа / Удалена наблюдаемая программа в политике Агента администрирования.
Клиент: Какие фильтры и пользовательские настройки доступны в списке программ для поиска приложения?
Консультант: Список приложений содержит информацию обо всех приложениях когда-либо установленных в сети. Для удобства работы со списком можно использовать опции фильтрации:
— Группировать программы по названию — группирует различные версии одного и того же приложения по имени приложения
— Первая установка в сети — отображает приложения, установленные относительно определенной даты, например, до какой-то даты или после, или именно в конкретный день. Дата в качестве критерия фильтрации указывается вручную.
Для улучшения поиска приложений по списку или поиска компьютеров с установленными приложениями можно назначать теги. Например, создать единый тег для запрещенных приложений. Также можно создать отдельные теги для группы приложений, предназначенных для решения сходных задач, например, интернет-браузеры или офисные приложения.
Теги задаются в свойствах конкретного приложения. Список тегов единый, поэтому любой созданный тег будет доступен в списке для назначения другим приложениям. Кроме того, теги можно назначать и для компьютеров. Для таких тегов ведется отдельный единый список, отображаемый в свойствах каждого компьютера. Например, можно объединить все компьютеры, назначенные на роль Инфорсера с помощью тега.
Теги могут использоваться в утилите Поиск в случае глобального поиска компьютеров на Сервере администрирования. Для этого на закладке Поиск ->Реестр программ в качестве критерия поиска достаточно указать нужный тег.
Кроме того, теги могут использоваться при создании Группы лицензионных программ.
Для использования представленных возможностей необходимо приобрести дополнительную лицензию на продукт Управление Системами Kaspersky Systems Management Предлагаем Вашей организации - бесплатный электронный ключ Kaspersky Systems Management для тестирования. - Купить Kaspersky Systems Management со значительной скидкой у Официального Партнера Лаборатории Касперского.
Как уже , Kaspersky Security Center представляет собой мощное средство для администрирования антивирусного (и не только) ПО в локальной сети. Впрочем, и нюансов работы с данной системой хватает.
При установке Агента администрирования Kaspersky Security Center на рабочие станции можно получить ошибку следующего вида: Адрес «» уже ассоциирован с компьютером «[имя компьютера]». Отсутствует соединение с Агентом администрирования. Данная ошибка сигнализирует о невозможности установить соединение между рабочей станцией и сервером Kaspersky Security Center. О причинах и вариантах решения проблемы ниже.
Насколько я смог для себя установить, в основе ошибки могут лежать две причины:
Итак, для начала удалите запись о проблемном компьютере из группы, в которой он состоит. Затем перейдите в раздел Дополнительно, нажмите правой кнопкой мыши на Опрос сети и нажмите Поиск.
В открывшемся окне вбейте информацию о проблемном компьютере. Проще всего искать по имени. После того, как нажмете Найти, внизу должен появиться искомый компьютер. Иногда Kaspersky Security Center может содержать и несколько записей об одном компьютере. Записи-дубли будут содержать после имени компьютера тильду (~ ) и набор цифр.
Пример отображения имени компьютера с тильдой.
Также щелкаем по компьютеру(-ам) правой кнопкой мыши и удаляем.
Теперь можно вернуть компьютер на сервер обратно. Так как мы отовсюду удалили запись об этой рабочей станции, то нужно, что Kaspersky Security Center заново опросил сеть. Но, если сеть большая и содержит множество IP-диапазонов, то для экономии времени лучше сканировать только тот диапазон адресов, где находится искомый компьютер. Для этого перед запуском сканирования убедитесь, что у Вас добавлен нужный IP-диапазон.
Убедитесь, что среди IP-диапазонов присутствует нужный.
Если диапазонов даже больше нужного, то уберите лишнее, дабы не затягивать опрос. После этого запустите опрос сети по IP-диапазонам.
Причина
Эта проблема возникает, если количество отчетов событий в таблице tbEventInstance превышает 1 миллион строк.
Процесс автоматического удаления происходит очень медленно и блокирует клиентских компьютеров из отчетов обратно на сервер WSUS. По умолчанию WSUS настроена для удаления события, которые старше, чем за 15 дней на рабочих станциях, которые старше, чем 90 дней на серверах. WSUS удаляет старые события со скоростью 1000 событий каждые 12 часов.
Для получения сведений о том, как определить, является ли таблица tbEventInstance превысило 1 миллион строк обратитесь к разделу «Дополнительная информация».
Читайте также: