More PowerShell v4 and DSC Details

Here's what I know, much based on a TechEd talk this week:
We can expect PowerShell v4 to ship in the Windows Management Framework, as with previous versions. It will be preinstalled on Windows Server 2012 R2 and what they're calling Windows 8.1; the default execution policy will be RemoteSigned, and on the server OS Remoting will be enabled by default. Microsoft's past policy has been "current version and two back," and if they follow that then we'll get WMF 4.0 on Windows 7, Windows Server 2008 R2, and later. That would leave out Server 2008, if in fact they follow that same policy.
DSC itself starts with a PowerShell script that's mainly declarative code: Make sure x is installed, make sure y isn't installed, etc. PowerShell compiles that into a MOF, which can be transmitted to managed endpoints (computers). The built-in mechanisms for deployment aren't as complex or flexible as GPO or SCCM targeting, but you could use either GPO or SCCM to deploy those MOFs. That's the "push" model - you push MOFs out to managed nodes. A "pull" model requires you to configure managed nodes to have a URI and UDDI, and they check that URI for their MOFs.
DSC runs every 15 minutes or every 30 minutes by default, depending on whether you're using push or pull, and you can configure that time. Right now there's no feedback or reporting - it's a bit like GPO, where you push out the setting and it enforces it, but that's it.
When DSC runs, it takes your "desired state" MOFs and starts running "DSC resources." These resources are special modules that implement a predefined set of functions - a Get, a Test, and a Set function, to be specific. I expect MS product groups to provide these - the Exchange team will likely someday provide resources that can check/set Exchange settings, for example. You can also write your own modules. DSC calls the "test" to see if your setting is or isn't configured at that time; it calls the "set" to add/remove/whatever the setting. So the real work is done by these special modules - and those modules can do whatever they want. Write to the registry, run commands, call .NET classes, anything.
So there's two scripts: The "desired state" script that gets compiled to a MOF (so you shouldn't ever have to mess directly with MOFs yourself), and the "implementing module" that has the three special functions which actually do all the work.
In the "pull" model, those special modules can be dynamically downloaded by a managed node. "Hey, I grabbed this desired state MOF, and it seems to require 12 modules, so I'll go to the same URI and look for those 12 modules." You provide those modules as ZIPs, and PowerShell can grab the ZIP, expand it into the proper location, and then run the modules as needed.
Personal analysis (meaning this is my opinion, not something MS has said): I can see this DSC feature integrating super-well with some future version of SCCM. DSC writes out some local file with configuration details, and the SCCM client grabs it and feeds it up to the database. Those MOFs could potentially be pulled from a Distribution Point by the client, handed off to PowerShell, and run on a scheduled basis. I can also see DSC starting to supplant GPO in a lot of ways. After all, most GPO stuff is just reg hacks in a special section of the registry; there's no reason DSC couldn't do that - and it does it on a more frequent basis, making it more reliable. Right now, the targeting of a MOF isn't as flexible as GPO targeting... but that could obviously evolve. Until more of the architectural details emerge, we won't know for sure... and this is of course a v1 feature that will doubtless be expanded on and invested in as the team moves forward. We do know that the first release of DSC will not have a lot of those underlying "resource modules," which means you won't actually be able to configure much. This is a feature the team needs to put in place so that folks can start building those things... so this is going to take a cycle or two to start being really useful.
There's obviously still a lot under wraps here, and this is all subject to change and tweaking as the team moves toward release. We're told there will be some kind of public preview - but they haven't announced a date on that. Personally, with the Build conference coming up, we can imagine that Microsoft will try and have a preview release ready for that show. There's also no announcement of ship date. It's still too early to tell, and I want to emphasize that the company hasn't announced any dates. We can but try to make educated guesses at this stage.