Windows Vista óta lehet olyat, hogy az Eseménynapló bizonyos eseményeit automatikusan továbbítsuk egy központi gép felé. A funkció neve Event Forwarding, az Eseménynapló Subscriptions részében lehet beállítani. Két féle üzemmódban működhet:
- Collector initiated (pull): az események begyűjtését a központi gép (event collector) kezdeményezi. Leírás: Configure Computers to Forward and Collect Events
- Source computer initiated (push): az eseményeket a forrás gépek küldik el a központi gép felé. Leírás: Setting up a Source Initiated Subscription
A második módszert csoportházirendből lehet beállítani, az elsőt kézzel is meg lehet csinálni. A fenti leírások elég pongyolák (ráadásul pl. a Techneten nincs is semmi a source initiated módszerről:), ezt a blog bejegyzést érdemes inkább megnézni: Quick and Dirty Large Scale Eventing for Windows.
Kézzel kipróbálva a collector initiated módszert ment is rendesen. [Egy megjegyzés csak: a fenti leírással ellentétben a központi gép fiókját elég berakni csak az Event log readers csoportba, nem kell a Local administratorsba.]
Gondoltam akkor beállítom, hogy a tartományban lévő minden szerver egy központi gépre továbbítsa a Critical és Error típusú bejegyzéseket. Ha már van tartományunk, akkor viszont minden beállítást próbáltam csoportházirendben megadni. A következőket kell elvégezni:
- WinRM engedélyezése és beállítása (Windows Components/Windows Remote Management (WinRM)/WinRM Service): Az “Allow automatic configuration of listeners” beállítást kell engedélyezni. Én korlátoztam, hogy csak a belső hálóhoz tartozó IP címeken figyeljen.
- WinRM kiengedése a tűzfalon (Windows Settings/Security Settings/Windows Firewall with Advanced Security/Inbound Rules): “Windows Remote Management (HTTP-In)” beépített szabály engedélyezése. Arra figyeljünk, hogy a Public profilban azért ne engedélyezzük.
- Event Forwarding beállítása (Windows Components/Event Forwarding): “Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager” beállítás megadása, Server=collect_FQDN_neve értékkel.
- WinRM szolgáltatás automatikusan induljon.
Ezzel fut a WinRM minden gépen, és a gépek megpróbálnak a Subscription Manager beállításnál megadott géphez csatlakozni, hogy lekérjék, hogy milyen eseményeket kell nekik továbbítani.
Most már csak be kell állítani a központi gépen, hogy fogadja az eseményeket: Eseménynapló / Subscriptions megnyitása. Itt igent mondani arra, hogy az Event Collector szolgáltatást indítsa el automatikusan. Ezek után létrehoztam egy új, push típusú előfizetést:
Viszont az OK után a következő hibával fogadott:
És az előfizetés tényleg nem is működött:
A Runtime status leírást megnézve a hibaüzenethez már tartozott egy hibakód is: “Code (0x8033808F): The client could not start a valid listener to receive subscription events based on the specified input settings.” Viszont a google nulla találatot adott erre a hibakódra, úgyhogy el kellett kezdeni gondolkozni, hogy mit is jelent ez:-)
1. WinRM ellenőrzése: egy távoli gépről kiadva a következő kérést gond nélkül kaptam választ:
winrm id -r:kozponti_gep
2. WinRM listener megnézése a központi gépen:
c:>winrm enum winrm/config/listener Listener [Source="GPO"] Address = * Transport = HTTP Port = 5985 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 10.40.1.100
Látszik, hogy van rendesen listener, a beállítások csoportházirendből származnak (Group Policy Object), HTTP-t használ, és a gép belső IP címén figyel (ez az az interfésze, amin a többi szerver a SubscriptionManagernél megadott FQDN-en eléri). A hostname nem volt kitöltve, de ezt sehol máshol nem láttam kitöltve. Azért megpróbáltam megadni (WinRM set winrm/config/listener?Transport=HTTP+Address=* @{Hostname = gep_FQDN}), de ez nem segített. Látszólag valami WinRM gond van, ezért megpróbáltam lefuttatni a winrm quickconfig parancsot, hogy hátha még valami egyéb beállítás is kell. Legnagyobb meglepetésemre a WinRM azt mondta, hogy a tűzfal szabályok nincsenek meg (holott csoportházirendben az is be volt állítva), viszont nem is tudta létrehozni azokat.
WinRM quickconfig megjavítása
Ezt mondta a quickconfig:
Error: One or more update steps could not be completed. Unable to enable the firewall for WinRM.
Holott a tűzfal beállításait megnézve a WinRM portja (5985) ki volt engedve. Leszedtem a csoportházirend beállítást, és megpróbáltam, hogy a winrm engedélyezhesse a tűzfal szabályt, de ugyanez volt az eredmény. Jobb ötletem nem volt, úgyhogy kitöröltettem az összes WinRM beállítást:
winrm invoke restore winrm/config @{}
Utána pedig megnéztem, hogy ténylegesen mit is csinál a quickconfig. A winrm.cmd a c:\windows\system32\winrm.vbs scriptet hívja meg. Ez egy 4000 soros VBScript, ami annyit csinál, hogy feldolgozza a paramétereket, elvégzi a hibakezelést, és meghívja a WSMAN.Automation osztályt. A Private Function QuickConfigRemoting függvényt kell megkeresni, és itt érdemes a benne lévő wscipt.echo hívásokat kikommentezni. Így aztán ha lefuttatjuk, akkor látszik, hogy miket küld el és kap vissza:
C:\Windows\system32>winrm qc analysisOutputXml: <cfg:AnalyzeService_OUTPUT xmlns:cfg="http://schemas.microsoft.com/wbem/wsman/1/ config/service"><cfg:RemotingEnabled>true</cfg:RemotingEnabled></cfg:AnalyzeServ ice_OUTPUT> WinRM already is set up to receive requests on this machine. analysisOutputXml: <cfg:Analyze_OUTPUT xmlns:cfg="http://schemas.microsoft.com/wbem/wsman/1/config/ service" xml:lang="en-US"><cfg:RemotingEnabled>false</cfg:RemotingEnabled><cfg:R esults>Enable the WinRM firewall exception. </cfg:Results><cfg:EnableRemoting_INPUT><cfg:EnableFirewallException>true</cfg:E nableFirewallException></cfg:EnableRemoting_INPUT></cfg:Analyze_OUTPUT> updateInputXml: <cfg:EnableRemoting_INPUT xmlns:cfg="http://schemas.microsoft.com/wbem/wsman/1/c onfig/service"><cfg:EnableFirewallException>true</cfg:EnableFirewallException></ cfg:EnableRemoting_INPUT> WinRM is not set up to allow remote access to this machine for management. The following changes must be made: Enable the WinRM firewall exception. Make these changes [y/n]? y updateOutputXml: <cfg:EnableRemoting_OUTPUT xmlns:cfg="http://schemas.microsoft.com/wbem/wsman/1/ config/service" xml:lang="en-US"><cfg:Status>failed</cfg:Status><cfg:Results>Una ble to enable the firewall for WinRM. </cfg:Results><cfg:EnableFirewallException>failed</cfg:EnableFirewallException>< /cfg:EnableRemoting_OUTPUT> Error: One or more update steps could not be completed. Unable to enable the firewall for WinRM.
A hiba most is ugyanaz. Az Analyze_OUTPUT kérés eredménye, hogy milyen változtatásokat kell megcsinálni. Utána az updateInputXml-ben küldi el a módosításokat, majd erre válaszként megkapja az updateOutputXml fájlt. Itt sincs részletesebb hibakód, csak annyi, hogy nem tudta hozzáadni a kivételt.
A megoldás annyi volt, hogy fogtam, és a tűzfal is kapott egy “Restore defaults” lökést. Ezután a quickconfig gond nélkül lefutott, és engedélyezte ugyanazt a szabályt, ami eddig is be volt kapcsolva:-)
Subscription hiba megoldása
Az eseményforrások viszont továbbra se tudtak kapcsolódni, az ő naplójukban ez az üzenet volt:
The forwarder is having a problem communicating with subscription manager at address collector.ftslab.local. Error code is 2150859027 and Error Message is <f:WSManFault xmlns:f=”http://schemas.microsoft.com/wbem/wsman/1/wsmanfault” Code=”2150859027″ Machine=”source.ftslab.local”><f:Message>The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. </f:Message></f:WSManFault>.
Ennek ellenére a forrás tudott a sima parancssori winrm klienssel csatlakozni. A Wireshark segített most is, mint sok más esetben, a háttérben ezt a kérést küldte a forrás:
POST /wsman/SubscriptionManager/WEC HTTP/1.1 Connection: Keep-Alive Content-Type: application/soap+xml;charset=UTF-16 Authorization: Kerberos User-Agent: Microsoft WinRM Client Content-Length: 0 Host: collector.ftslab.local:5985
Ez a válasz jött rá:
HTTP/1.1 404 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 11 Mar 2010 12:29:16 GMT Connection: close Content-Length: 0
Tehát tud kapcsolódni itt is, csak a /wsman/SubsciptionManager/WEC nincs meg. Úgyhogy irány vissza a központi gép, és lássuk, hogy van-e valami részletesebb hiba. Az eseménynaplójában egymás után közvetlenül a következő két üzenet szerepelt:
10149 The WinRM service is not listening for WS-Management requests. 10148 The WinRM service is listening for WS-Management requests.
?? Döntse már el, hogy most figyel, vagy nem figyel:-) A 10149 hiba leírása nem segített, ugyanis előtte már többször is ellenőriztem, hogy távolról el tudják érni a központi gépet, létezik is a listener, csak az Event forwarding nem találja. Végső elkeseredésemben teljes resetet nyomtam: központi gép újraindít, csoportházirend szabályok levéve, winrm gyári konfiguráció visszaállít:) Utána megcsináltam kézzel mindent, és most ment is rendesen. Most már csak a két, látszólag ugyanolyan beállítás közötti különbséget kellett megtalálni. Nézegettem egy darabig, amikor belém csapott, hogy a WinRM listener nem csak a szerver külső IP-jén nem figyel, hanem a loopback interfészen (127.0.0.1-es cím) sem! Nosza, a csoportházirendben a WinRM beállításoknál hozzáadtam ezt is az IPv4 szűrőhöz, és így már egyből ment minden. Arra kell még figyelni, hogy 15 percenként küldi csak tovább az eseményeket, a tesztelésnél ezt vegyük figyelembe.
Megoldás: tehát a megoldás csak annyi volt, hogy a csoportházirendben hagyni kell, hogy a loopback interfész IP címén is hallgatózzon a WinRM. 0x8033808F hiba megoldva.
KIEGÉSZÍTÉS: Tűzfalprobléma
Az események továbbítása ment egy ideig, aztán pár hét múlva megnéztem a tulajdonságait mégegyszer, és akkor már a következő hibát dobta (“The WinRM client could not create a push subscription…”):
Az előfizetés állapotát lekérdezve ezt kaptam:
A 0x802280AA hibakódra nem találtam semmit. A listenert nem piszkáltam azóta, és a többi gépről is be tudtam lépni WinRM-mel erre a gépre, úgyhogy először nem értettem a hibát.
A megoldás annyi volt csak, hogy ennek a szervernek több hálózati interfésze van, és a külső lábán a tűzfal beállításainál letiltottam a WinRM portját. Az Event Forwarding pedig nem veszi észre, hogy azon a lábon nincs is WinRM listener, így felesleges a tűzfalszabály meglétét ellenőriznie. A wecutil.exe segédprogramjában nem találtam ezzel kapcsolatban semmi beállítást. Úgyhogy egyelőre engedélyeztem újra a WinRM-et a külső lábon is (úgysincs ott listener).