Я успешно установил 2 подписки для инициированного сборщика, и они являются перспективными событиями. Теперь я пытаюсь добавить третью подписку, чтобы получить журналы для всех моих рабочих столов, поэтому из-за их количества я использую источник, инициированный для использования групп. Я предполагаю, что могу инициировать как сборщик, так и источник? Просматривая множество статей и форумов по устранению неполадок, я убедился, что службы (WinRM, пересылка событий) проталкиваются через объект групповой политики на моем тестовом рабочем столе. Службы (сборщик журнала событий Win) находится на сервере сборщика. Похоже, что правила брандмауэра Windows действуют на всех компьютерах, даже если брандмауэры отключены. GPO для диспетчера подписки выглядит хорошо. Все мои подписки активны с зелеными галочками.
Мой основной тест - запустить: EventCreate / T ERROR / ID 101 / L APPLICATION / SO TEST / D «Это только синтетический тест транзакции. Не обращайте внимания на это событие».
Я запускал его с серверов и вижу (запускается сборщиком), я запускал его как на рабочем столе Win7, так и на Win10. Ни один из компьютеров не может пересылать события. Я видел на другом форуме, что кто-то говорил о стеке 2.0 и 3.0 в зависимости от того, был ли сборщик сервером 2008 или сервером 2012. Я использую сервер 2012. Я запускал идентификатор Winrm на обоих рабочих столах, и win7 - это стек 2.0, а win10 - это стек 3.0. Поскольку ни один рабочий стол не может пересылать событие, я предполагаю, что проблема не в этом.
Я запустил winrm id -remote: computername -auth: none с сервера-сборщика и получил ответ. Есть ли какие-то шаги по устранению неполадок, которые мне не хватает? Могу ли я выполнить какие-либо команды для проверки связи с любого компьютера? Есть ли тест для запуска с рабочего стола на сборщик?
Попытка запустить winrm qc на сервере-сборщике 2012 дает результат: C: \ Users \ richard> winrm qc Служба WinRM уже запущена на этом компьютере. Сообщение WSManFault = Клиент не может подключиться к месту назначения, указанному в запросе. Убедитесь, что служба на месте назначения работает и принимает запросы. Просмотрите журналы и документацию для службы WS-Management, работающей в месте назначения, чаще всего IIS или WinRM. Если местом назначения является служба WinRM, выполните следующую команду в месте назначения, чтобы проанализировать и настроить службу WinRM: «winrm quickconfig». Номер ошибки: -2144108526 0x80338012 Клиент не может подключиться к месту назначения, указанному в запросе. Убедитесь, что служба в пункте назначения работает и принимает запросы. Просмотрите журналы и документацию для службы WS-Management, работающей в месте назначения, чаще всего IIS или WinRM. Если местом назначения является служба WinRM, выполните следующую команду в месте назначения, чтобы проанализировать и настроить службу WinRM: «winrm quickconfig».
В конце концов, сканирование порта 5985 обнаружило, что сервер прослушивает этот порт на IP-адресе обратной связи '127.0.0.1', но не на всех интерфейсах, как должно. И запустив команду netsh http show iplisten, покажите IP-адрес обратной петли в адресе прослушивания HTTP: IP-адреса, присутствующие в списке прослушивания IP: ------------------- ------------------------ 127.0.0.1 Итак, сервер прослушивал HTTP-запросы только через интерфейс обратной связи. Поэтому я запустил команду netsh http delete iplisten 127.0.0.1, чтобы удалить его. После этого все заработало.