Lord of the Servers

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).