3

Desired State Configuration and the remoting myth

Windows PowerShell Desired State Configuration feature depends on PowerShell remoting. This is what we have been hearing and reading in the WMF 4.0 release notes too! Right?

It is a myth. Thanks to Aleksandar for shedding light on this. This is a myth like the other one that says we need PowerShell remoting for CIM cmdlets to work. CIM cmdlets and DSC just need the WinRM listeners and not PS remoting. The WinRM listeners are a requirement for DSC and PowerShell remoting creates them. This makes people think that PowerShell remoting is a requirement for DSC to work. Let us understand this in detail by looking at an example.

We will first go through the process of creating WinRM listeners and then make sure that we disable remoting. We, then, see how DSC configuration push just works without enabling PowerShell remoting on a target system. For this demo purpose, I chose Windows 8.1 x64 OS as the target OS. This system is joined to a domain and has Windows Remote Management disabled, by default.

Verifying that Windows Remote Management is indeed disabled

This is straightforward. I just have to see if WinRM service on a target is system is running or not. For this, we can use the Get-Service cmdlet.

winrm1

Create WinRM HTTP listener

There are many ways to do this. You can use any of the following methods

#1. Using Set-WSManQuickConfig
Set-WSManQuickConfig

#2. Using winrm (do this at the console)
winrm quickconfig

#3. Enable PS Remoting
Enable-PSRemoting -Force

There are other methods such as using winrm command to create just the listener or using WSMAN provider to create the listener. On my target system, I just ran the Set-WSManQuickConfig instead of the Enable-PSRemoting as the release notes suggests.

winrm2

Verify that WinRM listener is enabled

We can do this using the Test-WSMan cmdlet. This tells us that the HTTP listener is created and functional.

winrm3

Although, we did not intend to enable PS remoting, creating a WinRM listener enables it automatically. The subject of this post is to show you that pushing DSC configuration or DSC in general does not require PowerShell remoting. So, I will disable remoting using the Disable-PSRemoting cmdlet.

Verify that remoting is not enabled on the target system

We can try and remote into the target system and make sure we really have remoting disabled.

winrm6

The moment of truth! DSC without remoting

I have a sample DSC configuration that I want to push to the target system where remoting is not enabled. But, remember, I have the listeners still functioning on that.

Configuration WinRMDemo {
    Node WC81-1 {
       WindowsProcess ProcessDemo {
           Path="Notepad.exe"
           Arguments=""
           Ensure="Present"
       }
    }
}

WinRMDemo
Start-DscConfiguration -Path .\WinRMDemo -Wait -Verbose

winrm7

This is it. We pushed the DSC configuration without enabling remoting on the target system. Using the Enable-PSRemoting cmdlet is probably the easiest way to create WinRM listeners and therefore people might be suggesting it as a method to create WinRM listeners. PowerShell remoting is more than just the WinRM listeners. It includes enabling session configurations and changing permissions to enable remote execution. PowerShell remoting is enabled by default on domain-joined Windows Server 2012 and Windows Server 2102 R2 systems, but it’s not a requirement for DSC.

Filed in: Articles, Online Only Tags: ,

3 Responses to "Desired State Configuration and the remoting myth"

Leave a Reply

Submit Comment

© 2016 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: