I setup Windows Event Forwarding on several servers to log to a Sever Core Event Collector server. I got the GPO setup and all. Since the collector is Core and has no option to open Event Viewer, I opened mmc.exe locally, and attached Event Viewer to remotely manage the Core server subscriptions. Once I was done, I tested it all and… nothing. The event source machines were throwing:
The forwarder is having a problem communicating with subscription manager at address http://collectingserver:5985/wsman/SubscriptionManager/WEC. Error code is 2150859027 and Error Message is 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.
Turns out, the Subscriptions section of Event Viewer never manages the remote computer even if you selected a remote computer when attaching the snap-in.
What finally clued me in, is I checked the collector build with PowerShell against the remote core server, and nothing popped up. The whole time I thought I was managing the core server, I had instead been setting up the collector on my own machine. So yeah, either use a local instance of the Event Viewer snap-in or wecutil.
We ran into an issue with Microsoft Remote Assistance (MSRA) after disabling RC4 encryption support. I was having a hell of a time troubleshooting the issue and eventually resorted to WireShark for troubleshooting.
WireShark for the MSRA traffic showed that the Encryption type used for MSRA is AES as it should be. No problem there. Then I looked at the kerberos traffic specifically and seen alternating KRB5KCD_ERR_S_PRINCIPAL_UNKNOWN and KDC_ERR-ETYPE-NOSUPP. So the issue was not MSRA but kerberos.
Diving further I found that the TGS-REQ packet in WireShark showed the principal target was not the machine as I expected, but instead, the end-user. So, fun fact there, when you MSRA to a machine, your kerberos ticket is generated for the end-user, not for the machine account. We checked the “This account supports AES” check boxes in AD for the target user, and still the issue occurred.
I checked the logs on the domain controller and came across one in the Kerberos-Key-Distribution-Center category. It was a KDCEVENT_NO_KEY_INTERSECTION_TGS which stated “While processing a TGS request for the target server, the account did not have a suitable key for generating a kerberos ticket (the missing key has an ID of #). The requested etypes were # 23 #. The accounts available etypes were 23. Changing or resetting the password of will generate a proper key.” This pretty much explicitly stated the fix.
While we had matching supported encryption methods, the target user had to change their password for the AES support to kick in! So, if you disable RC4 support, ensure your user accounts have the AES check boxes set, and then make sure they change their passwords shortly after, or at least before you need to use MSRA to assist them.