I think I’ve gotten my DSC classroom and demo setup ready. Understand that this isn’t meant to be production-friendly - it doesn’t automate some stuff because I want to cover that stuff in class by walking through it. But, I thought I’d share. I’ve basically made an ISO that I can carry into class, attach to a Win2012R2 VM and a Win81 VM, and run students through. The server VM is a DC in “company.pri” domain, and the client VM belongs to that domain. In the root of the ISO are these scripts: ISO_Root (unzip that). Students basically just open PowerShell, set the execution policy to RemoteSigned or Unrestricted, and then run SetupLab -DVD D:, replacing “D:” with the drive letter of the VM’s optical drive. The script isn’t super-intelligent since I demo it at the same time; it needs the colon after the drive letter. In a folder called DSC_Modules, I add the following DSC modules (unzipped): xActiveDirectory, xComputerManagement, xDscDiagnostics, xDscResourceDesigner, xNetworking, xPSDesiredStateConfiguration_1.1, xSmbShare, xSqlPs, xWebAdministration. In a folder called DSC_Pull_Examples, I include these scripts: DSC_Pull_Examples (unzip that). In a folder called eBooks, I include these files: eBooks (unzip that). Those get used in a lot of the demos I do, so I have the lab setup scripts copy over some script modules. In a folder called Help, I have a file called Help.zip. This contains everything downloaded by the Save-Help command in PowerShell. The Setup script unzips this into the VM and then runs Update-Help against it, so the VM doesn’t need to be Internet-connected. In a folder called Hotfix, I have the Windows8.1-KB2883200-x64.msu hot fix installer. I include the 32-bit version also, just in case, but my script doesn’t use it. In a folder called Installers, I have installers for PrimalScript, PowerShell Studio, and SQL Server Express with Advanced Services. Again, those get used a lot in my classes, but the setup script doesn’t rely on them. Finally, in a folder called sxs, I have the contents of the Windows 8.1 installation media’s \Sources\sxs folder. Some of the things my setup script does - like adding .NET Framework 3.5 so SQL Server 2012 will work - rely on features that aren’t in a Win8.1 VM, normally. Because I don’t want to rely on the Internet, I include this source so I can install new features from it. This is all pretty specific to the way I run classes, but if there’s any use you can make of it, feel free.
Now that we’ve suitably rested, let’s get back to working with Desired State Configuration. Now, there are some basic features to work with that ship by default and the PowerShell team has been blogging some additional resources, but in order to do some really interesting thing with DSC, we’ll need to create our own resources.
DSC resources are (at their most basic) a PowerShell module. These modules are augmented by a schema.mof file (we’ll get into that more in a minute or two). These modules expose three main functions, Get-TargetResource, Set-TargetResource, and Test-TargetResource. All three functions should share the same set of parameters.
Some lovely conversation on DSC over on Reddit… with some I wanted to perhaps offer an opinion on. From what I’ve seen, these are very common sentiments, and they definitely deserve… not argument or disagreement, but perhaps an alternate viewpoint. I’m not suggesting the commenters are wrong - but that maybe they’re not considering the entire picture.
Certainly if you work with a superset of MS OSs (i.e. you do Linux also), then Puppet or something like it seems like a no brainer. In fact, that is what we’re doing now. Puppet has powershell modules you can install for instance. Personally, I still feel like Powershell is overrated except for small snippets of that’s how something is exposed. Puppet can run powershell commands. AutoIT can run powershell commands… I just don’t see value in Powershell today.
Desired State Configuration offers a number of immediate opportunities for independent software vendors (ISVs) who are smart enough to jump on board _now. _DSC currently suffers from a marked lack of tooling. That’s partially deliberate; MS obviously needs to deliver the functionality, and they may well rely on third parties or the System Center team to build tools on top of that functionality. But let’s explore some of the immediate opportunities. Change Control and Versioning. This should be pretty easy. We basically need a way to “check in” a new DSC configuration, possibly have it go through an approvals workflow, and then deploy it. In more detail, I’d want to be able to submit a configuration script to this tool. It would run the config, generate a MOF, and deploy it to a “lab” pull server location. I could then verify its functionality, and “approve” it to deploy the MOF to a production pull server. Deployment would include creating the necessary checksum file. Obviously, rollback capability to a previous version would be nice.** ** **Configuration Consolidation. **Natively, DSC requires me to specify the nodes I want to push a configuration too. I’d like to see a tool that lets me create server lists somewhat graphically, organizing things so that a single server might appear in a “domain controllers” list, a “New York servers” list, and a “Win2012R2” list. I could target configurations at each list, and the tool would combine those configurations to create the appropriate one for each node based on its “folder memberships.” That might be done through composite resources. This makes DSC work a bit like GPO, with this tool doing the work of combining configurations into a single one per node. **DSC Studio. **Using the underlying DSC Resource Kit and Resource Designer for functionality, give me an IDE that lets me graphically design a resource (specify properties) and then spit out the schema MOF and skeleton PSM1 file. This could probably be a very simple PowerShell ISE add-on, in fact. **Node management. **In a pull server environment, give me a tool that lets me group servers. The tool should modify the LCM on each group, so that each member of the group has the same DSC configuration ID. That way, they’re all pulling the correct MOF from the pull server. Otherwise, managing GUIDs gets out of hand pretty quickly - I can see a lot of Excel spreadsheets. Resources. There are obviously a ton of resources to be written. This might be a bit of a bad call for an ISV, as you never know what MS is going to release resources for. Now that MS has built so many PowerShell cmdlets, building resources on top of them gets pretty straightforward. They’ve pumped out two waves of resources pretty fast already. In short, I think there’s a big opportunity for a smart company. It’s a matter of seeing the “holes” in the technology, which currently focus mainly on management, and filling them in.
On a recent PowerScripting Podcast episode, I went off on a bit of a career-oriented rant, and amongst other things mentioned something to the effect of, “if you’re not learning DSC now, you’re screwed.” It hopefully goes without saying that my comment applies to folks working in environments that use Microsoft server products; obviously, in an all-Linux shop you’re pretty safe not knowing Microsoft’s technologies :). Some discussion on Twitter ensued, a place I hate for discussions because 140 characters leaves you enough room to be misunderstood and paraphrased, but not enough room to articulate your perspective. I wanted to follow-up on the rant a bit, and by doing so here hopefully engender a more detailed discussion. One comment - and this is a nice, succinct one to start with: “Is it a useful tool? Yes; is it the tool that makes or breaks a sysadmin? No.” Couldn’t disagree more. Maybe it won’t make or break you _today, _but in a few years - absolutely. Unless you’re stuck in a company that’s going to just run Win2008 forever. So if it’s going to be an inevitable part of your future, then you are, in fact, more and more screwed the longer you ignore it. It’s like the poor NetWare guys who ignored TCP/IP. They were screwed, in the end, and had to hustle to catch up. I hate playing catch-up; in my mind “screwed” is what you are whenever you’re playing “catch up.” So maybe knowing my definition of “screwed” will help the discussion a bit! Another comment - and a good one - was, “[PowerShell] is a must… but I live in a multi-platform world where it is just a part, not a definer, of the whole.” Excellent point, but if you must manage Microsoft technologies, then DSC is going to be a part of your life. Perhaps it’ll be DSC “as managed by ___” cross-platform solution, but DSC is going to be the underlying API. If you’re comfortable being insulated from underlying APIs by tools, fine - but you’ll never be as effective as you would be if you knew those tools. Point being, in a multi-platform environment, DSC is not all you need to know, but you must know it (or begin to) if that environment includes Microsoft server products. Could you manage your Microsoft elements without using DSC? Sure. You can also drive a car using mind control, I’m told, but it’s not the most effective way of doing so. Folks are quite welcome to disagree, but I do firmly believe that any environment would benefit from DSC. Time will tell if I’m right or wrong there, but personally - and this is very much a “this is how I proceed with my life” thing - I would rather be on the forefront of something than turn around in 5 years and realize I should have been there. Keep in mind that, 6 years ago, folks felt free to ignore PowerShell. Many now wish they hadn’t. It was a lot easier to get into PowerShell in v1, and then “keep up” with new versions, than to dive in now. Why do I think DSC will be the same? Because _DSC is the ultimate outcome of PowerShell. _DSC is what PowerShell has been building toward. I think this is perhaps a perspective that other folks don’t share. To them, DSC is “just a tool.” It isn’t doing anything they couldn’t have done all along. But understand something about DSC: This is something Snover planned _almost a decade ago. _It was the ultimate destination of his “Monad Manifesto.” DSC is exactly what PowerShell has been building up to. DSC is the _main reason, _in many ways, for PowerShell. If you really think about it, DSC removes much of the need for you to learn PowerShell.** ** That’s a bold statement. Let me explain. There’s no question that PowerShell can be difficult to learn. It’s programming, and not everyone has an aptitude for that. There are literally thousands of commands, and that’s just from Microsoft product teams. It’s a huge product, like any language has idiosyncrasies, and you can come at it from a half-dozen different directions. Writing scripts that configure or re-configure computers, or even that report on current configurations, can be complex. Yes, they’re faster than doing it manually - but it’s not a zero effort. DSC abstracts all of that. To create a DSC configuration, _you don’t need to know how to program, _yet you can potentially leverage all the PowerShell investment Microsoft has been making. You can use PowerShell, and all it can do, without having to really touch much of PowerShell. Sure, there’s a middle layer of folks writing DSC resources (which use PowerShell commands as their API), but that’s going to be a small subset of folks. A highly-paid subset, I suspect. If Microsoft had had infinite time, money, and people, they’d have just given us DSC and not mentioned PowerShell at all. PowerShell v1, v2, and v3 were building blocks toward what DSC gives us. DSC was the _point, _all along. We’re just seeing the tippy top of that, now. There’s a glacier underneath. Now, you may be thinking, “bullshit. I can’t use DSC to do everything that my job involves, even if I just think about my Microsoft assets.” True. _Today. _But folks, you need to have a little vision. We’re dealing with DSC 1.0. _Kindergarten DSC. _Literally, what you’re seeing now is the simplest possible expression of something that _the world’s largest software company took seven years to deliver. _Seven years. Most of Microsoft’s PowerShell investment, going forward, is going to be in DSC - I guarantee it. They’ve done the lower-level building blocks already. “Can I use DSC to generate configuration reports?” Maybe not today. But have you noticed that a DSC pull server can have a “compliance server” component? Have you looked at its service definition? It’s basically a way for servers to report in on the state of their configuration compliance. That’s reporting. And that’s my point: DSC _has a super long way to go. _It is going to be everything for an administrator - and that’s going to happen fast. Looking at DSC today, that may be tough to imagine. So was PowerShell, in 2006. And we haven’t even seen the tooling that will be layered on top of DSC yet, because it’s all so new. The tool where you click a Wizard to add a user… and the tool goes and rewrites four dozen server configuration files, causing the user to exist in AD, in your accounting system, as a home directory on a file server, and so on. Yeah, that’ll all happen. Eventually, you won’t touch servers anymore - you’l touch their configuration files, and they’ll reconfigure themselves appropriately. That’s why this is such a big deal. It’s not a tool. It’s the administrative _interface. _ So when I say, “if you’re not learning DSC _right now, _you’re screwed,” it’s because I personally believe that to be true. My experience in the industry and my familiarity with how Microsoft pursues these things informs that opinion. You are going to fall behind the curve so fast you won’t even realize it’s a curve anymore. Today, people look at Infant DSC and see a basic configuration tool. I see Teenager DSC, and Young Adult DSC, coming around the corner, and _they are going to absolutely change the way you are required to manage Microsoft products. _Yeah, I personally want to be on board with that right now. “What about a small shop? Isn’t DSC meant for large scale?” No, large enterprises just have the _most obvious _advantage from DSC. It’s less obvious to small shops. You know how Exchange 2007 really impressed everyone, because the GUI was just running PowerShell under the hood? That meant a small shop could still get the GUI, but you could always drop down to PowerShell when you needed to. It also meant that not _everything _went into the GUI, and sometimes you had to drop into PowerShell anyway. I predict DSC will do the same thing. GUIs won’t run PowerShell commands anymore - they’ll modify DSC configurations. Those configurations will then be implemented on the affected servers. Your cross-platform management tools? If they’re smart, they’ll be doing the same thing. Think about that. DSC isn’t going to be “just a tool.” It’s going to be the entire interface by which you interact with Microsoft server products. It’s as important as the mouse or the keyboard. I truly think people aren’t seeing the end-game when it comes to this technology. You know those admins who only know what the GUI shows them? They don’t know much about what’s happening underneath, and as a result, they’re not very good at planning, architecture, troubleshooting, or anything else that requires a deeper knowledge. That’s where you stand with DSC. You either ride that bus, or get run over by it. Eventually. Do you want to risk not knowing this thing? You might. Perhaps in your job position you know it’s not going to affect you. For me, I won’t risk it. So that’s where my perspective comes from. In my world, this thing is a must-have. And yes, that’s an enterprise-class world, with large, cross-platform environments. But it’s also a perspective from my experience in SMB - I’d have killed for DSC, given the minuscule budgets and staff I worked with in those environments, and given my colleagues’ distaste for scripting. Anyway, that’s how I feel about it - in more detail than 140 characters allowed ;). If you have a different perspective, please feel free to share it. I can’t promise that you’ll change my mind (and I’m not really out to change yours), but it’s good for the world in general to see different perspectives, so that folks can make informed decisions about their own career directions.
This Thursday, Feb 27, 2014 join us with guest, Nick Howell, (@that1guynick) from NetApp as the discussion will be software defined datacenter. See you at 9:30PM EST
Ed Wilson, Microsoft’s Scripting Guy, has created a free ebook, _Windows PowerShell Networking Guide. _It’s designed to provide a super-quick PowerShell crash course, and then show you how to manage various networking scenarios by using the shell. And it’s free! Just click the link to get your copy - and please, tell a friend! PoshNetworking.pdf
In This Episode
Tonight on the PowerScripting Podcast, we talk to Steve Roberts from Amazon on Amazon Web Services and PowerShell.
News
-
[The Scripting Games](https://powershell.org/category/announcements/scripting-games/) are going on now!
-
[PowerShell Saturday #007](http://powershellsaturday.com/007/) is on February 8th
-
[PowerShell Saturday #008](http://powershellsaturday.com/008/) is on February 15th
Interview
Guest - Steve Roberts
Links
-
[Amazon Web Services](http://aws.amazon.com/)
-
[AWS Tools for PowerShell](http://aws.amazon.com/powershell/)
-
AWS .Net / PowerShell team
[Windows & .Net Developer Center](http://aws.amazon.com/net/)
-
[Blog](http://aws.amazon.com/net/)
-
Twitter: [@awsfornet](https://twitter.com/awsfornet)
-
[Handling credentials with PowerShell tools](http://blogs.aws.amazon.com/net/post/Tx36NATIEAMER5V/Handling-Credentials-with-AWS-Tools-for-Windows-PowerShell)
Chatroom Highlights:
[21:55:58] [http://amzn.com/1430264519](http://amzn.com/1430264519)
[21:56:13] Pro PowerShell for Amazon Web Services
[21:56:33] Steve (speaking) was a big help with the book
[21:56:43] his team was great
[https://powershell.org/community-events/summit/](https://powershell.org/community-events/summit/)
[http://www.panasonic.com/business/toughpad/us/7-inch-tablet-fz-m1.asp](http://www.panasonic.com/business/toughpad/us/7-inch-tablet-fz-m1.asp)
[http://aws.amazon.com/powershell/](http://aws.amazon.com/powershell/)
[http://docs.aws.amazon.com/powershell/latest/reference/Index.html](http://docs.aws.amazon.com/powershell/latest/reference/Index.html)
[http://aws.amazon.com/](http://aws.amazon.com/)
[http://amzn.com/1430264519](http://amzn.com/1430264519)
[http://docs.aws.amazon.com/powershell/latest/reference/Index.html](http://docs.aws.amazon.com/powershell/latest/reference/Index.html)
[http://aws.amazon.com/net/](http://aws.amazon.com/net/)
[http://blogs.aws.amazon.com/net](http://blogs.aws.amazon.com/net)
[http://www.musicradar.com/us/news/guitars/trent-reznor-talks-johnny-cash-168199](http://www.musicradar.com/us/news/guitars/trent-reznor-talks-johnny-cash-168199)
[https://scontent-a-iad.xx.fbcdn.net/hphotos-ash3/1607005_10202465193703988_1046463679_n.jpg](https://scontent-a-iad.xx.fbcdn.net/hphotos-ash3/1607005_10202465193703988_1046463679_n.jpg)
## what does AWS stand for again?
DexterPOSh, please add ## before your questions so they are easier for us to pick out
@JonWalz ...got it ##
## can you give a quick/small example of the differences between AWS and Azure?
## Can I extend my local Lab to include machines from AWS ?
## does he have a blog
Join us this Thursday, Jan 16, 2014 at 9:30 PM EST as we talk with Steve Roberts from Amazon about the AWS Tools. Read more about it here: http://aws.amazon.com/powershell/
DSC Setup and Demo Scripts I recently set up a virtual machine to use for Desired State Configuration (DSC) demos. I wanted to make the demo-ing fairly brainless, as DSC requires a number of setup steps to get a pull server running. So I took some demo scripts Microsoft offered from TechEd 2013, updated them to work with Windows Server 2012 R2 RTM, and thought I’d offer them to you. SetupDSC.ps1 is the main script. Now, because I didn’t want to use good ol’ Start-Demo, there’s a who crapload of kinda ugly Write-Debug statements. That way I can get an “about to do ____” message and then have the script pause before doing it. Lets me explain to the class what’s about to happen. You can remove all that crud if you like. InstallPullServerConfig.ps1 and PSWSIISEndpoint.psm1 are the updated Microsoft scripts. SetupDSC.ps1 calls these. They’re intended to run locally; you’ll need to be _on _the machine you want to make into a pull server, and it needs to be Windows Server 2012 R2 (the DSC pull server role is part of the OS, not part of Windows Management Framework v4). Setup takes a few minutes, and will install IIS. This sets up an HTTP pull server. SampleConfig.ps1 is a sample DSC configuration, targeted to a computer named MEMBER2. It just specifies that the Windows Server Backup feature be installed. SetupDSC.ps1 actually runs this, which produces a MOF. SetupDSC.ps1 also copies the MOF to the DSC pull server configuration directory. SampleSetPullMode.ps1 also gets run by SetupDSC.ps1. This contains a DSC Local Configuration Manager configuration, targeted to MEMBER2, that turns on pull mode and directs MEMBER2 to pull the previously-created configuration. I think I have it refreshing every 5 minutes, which is totally unrealistic for production. Again, this was made for class demos, but you can adjust the time or leave it off to default to 30min. Running this script creates the MOF and pushes it to MEMBER2. That, in turn, causes MEMBER2 to start pulling the sample config, which causes Windows Server Backup to be installed. SetupDSC.ps1 has some additional code to show that Windows Server Backup isn’t installed, and then is installed (after you give the pull time to occur). Anyway, might need some tweaking to use in production, but hopefully it’ll give you a snapshot of the whole DSC process. Much thanks to James Dawson’s article on DSC, which gave me a couple of the tweaks I needed to get all this working on RTM code. Enjoy.
