Compliance Setting to Enable WinRM

The Situation:  ConfigMgr 2012 clients can be managed remotely (and troubleshooting remotely) quite handily... if only Powershell were installed and Remote Management via Powershell (WinRM) were enabled.

This article presumes you are deploying Powershell via other means, and this routine is just 1 of several ways to get WinRM enabled, if Powershell is installed.  Note you don't have to use this at all; by far the most popular method is to simply have a GPO, or if you must, interactively login to a computer and run   winrm quickconfig -q  from a command prompt (if you have the rights).

This situation may or may not be an edge case for you... but in our environment there are a few workstations, which are ConfigMgr Clients, but which for whatever reason are not candidates for the GPO, and to have a human interactively connect to each of those machines and run the winrm config (with our settings) is cumbersome. 

I grabbed Roger Zander's Baseline from here: http://myitforum.com/cs2/blogs/rzander/archive/2013/06/21/configure-winrm-by-using-cm12-settings-management.aspx, and found that there were a few things inside that just weren't working in my environment--some old clients, or older versions of Powershell just were not being detected or remediated well.  So I tweaked it to work in my environment.  The tweaking I did may or may not work for your environment--only you can determine that.

The baseline attached is just a SAMPLE of a Configuration Item; using the settings as created if you were to run winrm quickconfig; however you or your security team may have determined not to use those defaults--you may need to modify the port used, or change the ipv4 or ipv6 listening ports.  So take the attached as-is ONLY if you know you are using the defaults, and they are acceptable in your environment.  If you've modified how WinRM is configured in your company, you will definitely need to either modify the ConfigItem detection and remediation, or not use this at all.

How to use:

1. Import the --> Attached <--  baseline into your Compliance Settings, Baselines 
2. PARANOIA: Deploy the Baseline to a collection withOUT checking the box about remediation.  
   1. Monitor, and for the machines which say "non-compliant", check that you really cannot remotely connect to them with Powershell Remote Management.  
   2. To a collection of those non-compliants, Deploy the baseline again, but DO check the remediation box.  
   3. Confirm that the remediation Baseline runs, and that you now can remotely connect to them with Powershell remote management. 
3. Repeat the Paranoia steps as many times as you need to until you are comfortable that it's doing what you think it should be doing. 
4. Once you've passed your own internal Paranoia Steps (above), you can remove the test deployments, and deploy it again to your 'main' collection, with the remediation checkbox checked.

Again, to repeat... this is just a sample.  and this sample will only be logical to use in your environment if you simply can't use a GPO to enable WinRM on all of your CM clients.  If you CAN use a GPO against your entire environment; then perhaps all you'd maybe, and I mean MAYBE want this for is to Monitor only (no remediation) and just check if the GPO is in fact getting to all your clients.  I wouldn't bother, personally; if I had a GPO that could get to every client.

Puzzling Behavior: When I was testing, more often than I was comfortable with (when using remediation enabled), client computers would report "Failed"--but at re-run they would report Compliant, and forever after report compliant.  What I suspect is happening (but couldn't verify, because a rerun was compliant) was that during Remediation, AS it was remediating one of the 1st non-compliant results... other tests would fail.  But by the time of a human (me) following up on it, WinRM was all enabled and configured and a re-run of the Baseline would indicate absolutely nothing wrong.  So... if you get a lot of failures in Remediation... just wait for your next cycle or re-run the baseline manually.  I suspect it's fine; just a timing issue.