Presentation on theme: "Get to Know DSC A PowerShell.org TechSession. Remember Find the latest TechSessions at"— Presentation transcript:
Get to Know DSC A PowerShell.org TechSession
Remember Find the latest TechSessions at http://powershell.org/wp/techsession-webinars/. http://powershell.org/wp/techsession-webinars/ Advanced registration is required to attend the live events, where you can participate in Q&A Recordings posted to YouTube, usually in 48 hours.
Today We’ll introduce the DSC technology, explain what it is (and isn’t), and provide some guidance for using it. We’ll also look at where it currently falls short, and try to predict where it’ll go next. This will be about 50/50 lecture and demo… …and you’re encouraged to ask questions as we go, using the Q&A panel in GoToWebinar.
Basic Information Level: 100-200 Technology introduction and feature overview Planning and architecture Pre-requisites: Solid experience with Windows PowerShell and Windows administration
What is DSC? A means of declaratively specifying the configuration a computer should adopt. Mainly focused on servers at this time. Rather than writing a script that checks the config and then corrects it, you simply specify the config. Microsoft (and others) provide the code that does the checking and fixing.
Applicability Part of WMF 4 and later Win2008R2, Win7, and later Included in Win2012R2 and Win8.1 Note that because Win8.1 was a free update, WMF 4 does not technically apply to Win8; the expectation is that you’ll upgrade to 8.1. Much more limited resource availability on Win2008R2 and Win7, meaning DSC is there, but it can do less.
“Target Node” Because not every node is a computer these days Although presently, an LCM exists only for Windows and Linux *LCM=Local Configuration Manager, the client-side bit of DSC that does all the dirty work
Configuration Scripts These can contain zero logic, to incredibly complex logic. They run once on your authoring computer, and produce a static MOF. The MOF is what you deploy. Keep in mind that the MOF is static – it doesn’t contain code or logic. A configuration can be written to target one computer, or contain logic that allows it to produce MOFs for multiple computers. Let’s take a look…
Resources A Configuration Script (and thus, the MOF it produces) references one or more Resources. Resources are what actually check the config, and when necessary fix it. Non-core resources must be explicitly imported. Use Get-DscResource to discover installed resources. A Config can reference any resource that will be available on the target node (e.g., you can code a Config for Linux on Windows) Resources should be available on the authoring system (for IntelliSense and whatnot)
One Machine, One MOF You can only deploy a single MOF to a given computer. To “modularize,” you can… Add logic to a monolithic configuration script so that it produces “customized” MOFs per computer Save a configuration as a resource, and then “include” it in another, top-level composite configuration
Composite Configurations Composite Configuration for Domain Controllers Composite Configuration for aux. DNS servers Configuration for AD DS Configuration for DNS servers Configuration for all company servers
DSC Resources Several come bundled with WMF 4 MANY MANY MORE are in the DSC Resource Kit (at Wave 4 as of June 2014) Resource Kit also includes Diagnostics and Resource Designer modules A Resource is a special PowerShell script module, and multiple Resources can be bundled into a single Resource Module. The RM is what gets distributed; the R is what gets referenced in a configuration script Let’s see one…
Deploying Resources Containing module should go in \Program Files\WindowsPowerShell\Modules This is in PSModulePath as of WMF4. Simple file copy is sufficient… However, resources usually have their own dependencies, usually other PowerShell modules.
Deploying MOFs PUSH Mode Uses WinRM to deploy the MOF and kick off the Local Configuration Manager (LCM) You must deploy all Resource Modules referenced in the MOF PULL Mode Configure machines’ LCM to grab their config from a central Web or file server They can also grab needed Resource Modules from the pull server Available on 2008R2+ (harder to install on older OS)
“Compliance” Server Additional optional feature of a Web-based pull server Gives machines a place to check back in with their current state of conformity This is only a status code, not a detailed “difference” report. By default, stored in a Win Internal DB; can be pointed to SQL Server.
“Diffs” LCMs can be configured to Apply (e.g., look at the config) and Monitor (report back)… …and Apply and AutoCorrect (e.g., look at the config and do something about it) DSC is designed to ensure there are no differences; while the technology does support the concept of “report back and tell me what’s non-conforming” there are presently no tools which do so.
Mental Switch We’re used to asking “what changed?” for troubleshooting. With DSC, if you’re doing it right, the answer is always nothing. Which is why it doesn’t natively report back with a difference. There is no difference. You can extract this information from diagnostic logs, but difference reporting isn’t the main goal of the technology.
What’s Missing Full resource coverage (improving almost monthly) Tooling (aside from ISE, there basically is nothing) Documentation (“The DSC Book” is about the best starting point; see also articles on PowerShellMagazine.com and the PowerShell team blog; it’s all a bit scattered at present).
What DSC Isn’t A catchall replacement for everything E.g., you’d use DSC to configure WSUS, not to deploy updates
Sketchy Areas Software installation is a little primitive – the current Package resource is a bit finicky Broad availability of OneGet (WMF 5) will probably help move this further toward the goal
Security The LCM runs as SYSTEM, so it has almost no authority off-computer Anything you need to do non-local (e.g., retrieve a package from a file server) will need to be given a credential You can specify, in a config, the thumbprint of a certificate (which you must pre-deploy to nodes) that can be used to decrypt credentials in the config
HTTPS! Pull Servers should be set up using SSL – this is what they want by default Without SSL, you get NO AUTHENTICATION OF THE PULL SERVER IDENTITY THIS IS A MASSIVE SECURITY FAIL AND YOU WILL PROBABLY GO TO HELL AND YOU’VE GOT NOBODY TO BLAME BUT YOURSELF PLEASE DON’T USE A NON-HTTPS PULL SERVER THANK YOU VERY MUCH.
This Isn’t GPO (Yet) There is no connection to Active Directory. Targeting is basically manual, or whatever logic you build. There’s no apply-time dynamic targeting or filtering (MOFs are static). You get only one MOF per computer (which complicates authoring, but massively simplifies everything else).
Let’s Take Some Questions I know you’ve got ‘em… ask away.
Follow-Up Resources The DSC Book (soon to be retitled The Free DSC Book) at PowerShell.org (on the “Resources” menu) The DSC Hub at PowerShell.org (including our GitHub repo) Watch for a DSC Microsoft Virtual Academy from Don Jones and Jeffrey Snover in 2014Q4 DSC Q&A Forum at PowerShell.org
Thank You! Find the latest TechSessions at http://powershell.org/wp/techsession-webinars/. Advanced registration is required to attend the live events, where you can participate in Q&A Recordings posted to YouTube, usually in 48 hours. http://powershell.org/wp/techsession-webinars/ Ask follow-up questions in the Forums on PowerShell.org.