More Related Content
What's hot
What's hot (20)
Similar to Deeper into DSC (DSC vs. GPO vs. DCM - What and When)
Similar to Deeper into DSC (DSC vs. GPO vs. DCM - What and When) (20)
Deeper into DSC (DSC vs. GPO vs. DCM - What and When)
- 1. BIGGER than ever! 195 event locations #GlobalAzure Deeper into DSC Matt Hitchcock, PowerShell MVP 3rd year in Singapore
- 4. Windows Operating System APIAPIAPIAPIAPIAPI Windows Management Framework WinRMWMI PowerShellBITS LCM PowerShell Web Access Agent • Local Configuration Manager (LCM) Delivers DSC • Supports Industry Standard MOF Documents from DMTF • Uses PowerShell and API’s to Deliver Configuration • Understands how to configure settings using Resources • Other Vendors are plugging into the LCM now and building resources
- 6. Term Explanation Local Configuration Manager (LCM) The agent within the Windows Management Framework that can enact Configurations on a system Configuration / Document / Configuration Document A file formatted in Industry Standard syntax (MOF) that describes the configuration of the system Resource Used by the Local Configuration Manager to: • Understand the components in the Configuration • Understand how to Test if they are compliant • Understand how to Set them to a compliant State • Understand how to Get Compliance Status information
- 8. Intent Environment Configuration (Dev -> Test -> Production) $SystemDrive = "C:" $DemoFolder = "$SystemDriveDemo" $global:WebServerCount = 3 … Structural Configuration WindowsFeature IIS { Name = "Web-Server" Ensure = "Present" } … Make It So Idempotent Automation foreach -parallel ($featureName in $Name) { $feature = Get-WindowsFeature -Name $featureName if(($Ensure -eq "Present") -and (!$feature.Installed)) { Install-WindowsFeature -Name $featureName } …. } …
- 12. Technology Benefit Limitaton Group Policy • Controlled and Delivered from Active Directory • Locks settings from change • Keeps everything defined in the Policy set • Prevents changes being made in a valid Troubleshooting scenario • High overhead in most organisations and slows server change tasks • Cannot Sequence the settings • Hard to report on a large number of servers, servers treated individually Desired State Configuration • Uses Industry Standard Document Standards )MOF from DMTF) • Extensible for in-house applications • Produces Configuration Files compatible with Linux OMI • Leveraged by Industry Leading configuration management tools (Chef/Puppet) • Allows full server configuration through automation (if modules/resources are present) • Configuration is pulled from SMB or HTTP/HTTPS • Server can Autocorrect or just log Configuration drift • Configurations can be sequenced • Change process becomes comparing MOF Files • Server configuration happens without an extra agent and without someone requiring Administrator rights • Easy to query compliance state • Spin up test labs that look like Production without the overhead of SCCM or AD Configuration - build out AD before GPO can even be used! • Bare-OS Provisioning • Servers treated like Cattle - Service oriented • No GUI Configuration Tools • Leaves settings in place when no longer in Configuration • Limited Reporting features SCCM DCM • Supports multiple Scripting Languages • Configurable with a GUI • Rich reporting features • Supports Mac OS X & Mobile Devices • Requires SCCM • Difficult to move to another technology • Persons managing configuration need SCCM Permissions to do so - moving the bottleneck/process from GPO to SCCM • Machine oriented
- 14. 1. Group Policy applies the Security and Audit settings 2. Once built, the Server has the ConfigMgr agent installed and lands in a collection 3. Based on the Collection, a Pull Server Certificate is installed and a DCM Baseline is applied 4. DCM see’s that LCM is not configured and configures it for the appropriate Pull Server 5. LCM reaches out to the Pull Server to configure its role and applications from here on in Group Policy DCM DSC
- 18. Get the SDKs and command-line tools you need http://azure.microsoft.com/en-us/downloads/ Learn more http://azure.microsoft.com/ Like us our Facebook page Join us @ meetup group
Editor's Notes
- Note: Scale * Complexity => exceeds our skill level… Demo: ConfigurationEnv Assert-Website with ConfigurationEnv1.psd1 (show easy configuration and flow of $Node, etc) Demo: Continuous Deployment cd ..\WebsiteWithVM simply show number of machines change… Assert-Website with ConfigurationEnv.psd1 Show consistency of Structural Configuration Demo: SCVMM and DSC (?) or at Ecosystem time Obviously DSC is not itself a Fabric Controller, but SC happens to have one… where DSC can easily integrate
- Unfortunately at this time Microsoft has a lot of overlapping technologies and no clear story. This is because we are in the midst of extreme change in IT. Traditionally, we have used Group Policy as this is a way to set what we want and enforce it. However, this comes with some inherent issues: 1. Process - Because Active Directory is involved in delivering Group Policy, the Active Directory team are often involved in the process of configuration changes for Servers. They have to vet the Policy, be the ones to implement and apply it, be the ones to roll it back. Sometimes teams are delegated their own GPO admin rights but not often 2. Rigidity - Once a GPO is applied the settings are enforced and cannot be changed. In a troubleshooting scenario this can create an issue, you may need to legitimately stop a service, remove some settings. You have to fight against GPO 3. You cannot control Processing Order 4. It’s hard to tell if systems that are part of a service are in compliance of everything they are meant to have applied At the same time you have DCM that does do a lot of this itself but if you use DCM you then shift the problem to the SCCM Console rather than AD. Application Teams need to have SCCM Knowledge and permissions, or, they depend on the SCCM Team to deliver what they need. Configuration Management is about enabling DevOps scenarios to deliver
- Active Directory Team – They care about Identity & Access management. They want to ensure the appropriate level of Security is implemented but are not interested in what else is happening on the server Systems Management Team – They care that the Server is being manager i.e. Part of a lifecycle, managed by SCCM, Security standards are in effect i.e. the Server is using the right Certificates and connected to the right Pull Server with no Rogue settings, they too do not care about the application Application Team – Can be given the freedom to change the server and application as needed to run the service. Cannot change the LCM to Go-Rogue, do not need Administrator rights to the Server because they are not making Manual changes, can prove the changes they are making through MOF File differences, speed up their Change process.