Conceptually, pushing configurations is the easiest to talk about, so we'll start there. It also requires the least setup in most environments. There's really only one prerequisite, which is that your target nodes must have PowerShell remoting enabled. If they don't, you should read through _Secrets of PowerShell Remoting _, another free ebook at http://PowerShell.org/wp/newsletter. In a domain environment, running Enable-PSRemoting on the target nodes is a quick and easy way to get remoting enabled. It's pre-enabled on Windows Server 2012 and later server operating systems.
|As of this writing, Remoting isn't enabled on any client computers by default. So if you plan to push a configuration to a client - even if you've authored the configuration right on that client - you first need to enable remoting.|
So, let's say you've written your configuration script, and run it to produce MOF files. All you need to do now is run:
Start-DSCConfiguration -Path c:\windows\system32\MonitoringSoftware
Remember, when we created the sample configuration, we named it MonitoringSoftware. Running it will create a folder named MonitoringSoftware , with one MOF file per targeted node. So Start-DSCConfiguration only needs that path - it'll figure out the rest on its own. Add the -Verbose switch to get blow-by-blow progress reports as the command runs. This command will copy the MOF file to the targets, and tell their Local Configuration Manager (LCM) software to start processing the configuration.
|By default, you need to be an administrator to use Remoting - and so you must be an administrator to run Start-DscConfiguration. On a client with User Account Control (UAC) enabled, make sure you see the word "Administrator" in the Windows PowerShell window title bar. If you don't, you're not really Administrator.|
DSC push happens by default as a PowerShell remoting job, and has a -ThrottleLimit parameter that controls how many machines it communicates with in parallel. That defaults to 32; each simultaneous connection puts a bit of extra memory and CPU overhead on the machine where you run the command, so on a well-equipped machine you can safely bump that up. All the more reason to get a quad-core Xeon box with 64GB of RAM as your next admin workstation, right?
What this command will not do is take care of deploying any resources that your configuration requires. That's on you, and it's pretty much a manual process if you're using push mode. Here's why: the target machine will attempt to evaluate the entire MOF file. If there are any resources in that MOF file that aren't present, then the evaluation will fail - meaning the entire configuration will fail. This is one reason that pull mode can be so attractive, since with pull mode the target node can copy over any resources it needs from the pull server.