3

I have a Server 2008 R2 server acting as a collector for two other servers. One is 2008 R2 as well, the other is 2012 R2. Collector Initiated forwarding works just fine, and that's really the only type I've ever implemented. I decided to have a go at Source Initiated, and it's not working out.

I have configured it per "Configure Computers to Forward and Collect Events" on TechNet (and the related articles linked there). I can see a healthy status of the forwarder itself, but the "Source Computers" column remains blank and wcutil gs reports the same: healthy forwarder, no sources.

The group policy is definitely applying to the source servers (gpresult displays it), and sends them to http://, which I'm certain is wrong, because there's already a separate website on this collector that answers on port 80. I tried the WinRM default port (e.g., I set the value in the GPO to Server=http://server.foo.com:5985, but this didn't work either).

I have ensured the computer account of the collector is in the Administrators group of each source server, and I've restarted each source server for good measure.

I think it's worth restating it works with collector-initiated forwarding, so winrm qc did its job and whatnot. Something else is clearly missing, but what?

EDIT: I should have mentioned I've also added the Network Service account on each source computer to the respective computer's Event Log Readers group, as another post on this matter advises.

Tohuw
  • 488
  • 2
  • 8
  • 23
  • Could you temporarily suspend IIS on your Collector server and see if the issue goes away? –  Jun 13 '14 at 13:39
  • 1
    Two questions: What WinRM stack are you running on the 2008 R2 servers? from cmd type: 'winrm id' Secondly, and I'm just being thorough here, since you did not mention any, how are your firewall configurations exceptions for transfer over http set? I.E., inbound exception on port 443 – Get-HomeByFiveOClock Jun 13 '14 at 13:42
  • @Yehaw, 443 and 80 are open on the collector. Also: `IdentifyResponse ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd ProductVendor = Microsoft Corporation ProductVersion = OS: 6.1.7601 SP: 1.0 Stack: 2.0` – Tohuw Jun 20 '14 at 14:56
  • @SujaySarma, I'm awaiting an approval to try this; another application is housed on this server. It's a good idea though. – Tohuw Jun 20 '14 at 15:00
  • 2
    'Stack 2.0' That was what I was looking for. I've recently had a similar issue with 2012r2 <--> 2008R2 communication over WinRM since the 2012R2 Server Manager runs on the 3.0 stack and is for some reason incompatible with the 2.0 stack. There is a Microsoft Update available to bring your 2008R2 server to the newest version. Here's the live link [link]http://www.microsoft.com/en-us/download/details.aspx?id=34595 check to see if it's appropriate to you. I don't believe there was a restart required but once again, read the documentation as there could be compat issues. – Get-HomeByFiveOClock Jun 20 '14 at 19:34

2 Answers2

2

I'm not sure if this is likely to make a difference, but the SubscriptionManager value in my GPO is set to Server=http://server.foo.com:5985/wsman/SubscriptionManager/WEC. Apparently I felt it necessary to provide the full URL even though it explicitly states that this is not necessary in the GPO help. I don't remember, but it's possible I too had issues with this and this was my resolution. It might be worth a shot.

pk.
  • 6,413
  • 1
  • 41
  • 63
  • Trying this now. Sorry for the delay; it's been a chaotic couple weeks. – Tohuw Jun 20 '14 at 14:59
  • This fixed it for me. Just having the http://fqdn didn't work until I added :5985/wsman/SubscriptionManager/WEC. – murisonc Aug 06 '14 at 17:23
  • Checking back in to say this didn't work, however it eventually (days!) started working, with no indication as to why! Annoying, right? – Tohuw Aug 07 '14 at 00:23
0

Per my comment above, it began working after several days, with no clear indication as to why or how. I wish I could be more helpful, but there's nothing in the logs save indications of the services cycling at appropriate times.

Tohuw
  • 488
  • 2
  • 8
  • 23