Managing Advanced DSC Configurations and Configuration Data
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Helmick, Jason
Learn how to write and manage complex DSC configurations. Make them reusable and bullet proof with advanced techniques in hierarchical configuration data. Transform the data structure into an easy to edit database.
 I'll turn the mic on and that kind of thing. So how do you want your morning to go? Do you want it to go easy? Good, because it's not. Here we go. Guys, this is kind of a strange, and let me just tell you, I'm just going to be right up front with you. There's some of us that work with DSC and working with DSC configurations that are running into some problems, and we've come up with some solutions. The problem is some of these solutions get complicated conceptually in a lot of people's brains. In other words, they can't solve the problem, not because the code is hard. Let me just tell you this. This is not chewy code. The concepts are hard. And so the code, you can copy and paste it all you want. You're never going to make it work for you, because you don't know what the hell you're trying to do. So I see this all the time, and I struggle at time, trying to learn the next step. As a matter of fact, if you don't know Gail, you will before you leave. I struggle to understand some of the things that he knows. And as Gail and a friend of ours said, you don't really have a chance at understanding it until you have the real problem. In other words, I have this problem. I don't know how to solve. That's the solution for it. Well, what I wanted to do is I've talked to a lot of people, and I wanted to see if maybe I could get you up to that level that if you run into that problem, you could solve it. In other words, you'd be ready for that concept. But to do that, I want to show you how a lot of us are looking at managing and cleaning up how we work with DSC configs and the configuration data for it. And I'm going to start you at zero on how I do things and take you up to the point of blissful happiness. Now, here's the thing. I'm showing you this so that when you have a problem in the future, you can see where you can go to get the answer. In other words, I remember that bald pudgy guy was talking about this. I need to go look at that because that was what I need now. So you kind of see how this is weird. It may not solve your problem today, but it may be the solution for you tomorrow kind of thing. OK, you don't sound impressed. You're giving us a solution to a problem we don't have. I was trying not to say it that way, but yes. You don't care to be here until after you leave. Then all of a sudden, you might care. The other thing is how many of you guys work with DSC? Now, let me quantify or let me explain what I mean when I say that, though. DSC is a platform. So a lot of you may work through it by using products like Puppet and Chef for configuration management. Are you with me? Some of us also kind of make our own products out of the platform of DSC. So we work just with DSC. I do both, but I really like working with DSC, because here's the thing. I don't understand how to solve the problems, but as I'm working on them, I can, working with PowerShell and DSC, that's not my problem. And I don't want a language and all that kind of stuff to be a problem when I'm trying to do this. So I know this works, and I love working with it, and it lets me learn in a comfortable environment that I know really well. So this is kind of what happened. First of all, I want to give you a couple of shout outs. There's a couple of people here. First of all, how many of you know who Steven Moroski is? He now works for Microsoft, but I have to say that Steven Moroski was talking about this concept what, five years ago? 2014. And literally, he was sitting there going, I have no idea what you're talking about. And I went up and asked him. I said, I have no idea. He's like, it's OK. When you actually have the problem, it'll make sense. Well, when am I going to have the problem? You have so many now. Now, the other thing is that Gail also ran into this. And Gail and Steve came up with some really cool solutions. The thing is, is getting to that point of understanding what those are. It just so happens that also along the way to get some good information that you can take home now of cleaning up this kind of stuff, your configuration data, Missy wrote an article. As a matter of fact, take out your phones and take a picture of that so you get the links and all that kind of stuff. Missy wrote an article. As a matter of fact, I highly recommend that article, along with my code, if you want to redo this. The other thing I highly recommend is if you start playing with this kind of stuff, you will run into the problem. When you run into the problem, he knows it better than anybody else. So Gail and his article, you're really going to want these at some point if you are working with DSC. If you're not working with it, you're not going to run into this. Kind of sort of maybe? We OK? OK. All right. So here we go. By the way, who was here in my GIA session yesterday? OK. There is no execution of code in here. So it's good for you to know that it's going to be OK. Let's take a simple configuration. So I got a lot of concepts that could be useful to you. Here's a quick little DSC config that I just for demo purposes that I wrote. So see if it makes sense to you. It's pretty simple. I just have a configuration. I put in the import DSC resource PSdesiredState configuration just so it stopped giving me that little yellow message if you do run this. Everything I show you can be run in a Lamaqumaw file. So it works. I don't need to show you know run it for the maw files in here. But I want you to see I've got some resources in here. It doesn't just having some fun. I got a file resource. What am I going to do? I'm going to stop a service. I'm going to install a Windows feature, a couple of Windows features. I have a question for you. Look at the config. What service am I stopping? What service do I expect to get? Oh, OK, good. Thanks. I didn't look at my code. What service would I like to be running? Do I want it running or stopped? How do you know this? Because it's right there. OK, so I have a question for you. This config runs. It works. It's beautiful. I send it out to 1,000 servers. But now I need the BFE service stopped, not the bit service. So what am I going to have to do? Don't overthink this, guys. These are easy questions. What do I have to do to now do something to the BFE service? I got a what? I got to do what? Say that out loud. Say that out proud. I got to change my code. That's a nice way of saying, what is it that I actually have to do? I have to open the code and now touch it. What is likely to happen along the way? If I touch it, I'm going to break it. I find it hilarious when he says that, the reason the PowerShell is so good is because I'm a deeply flawed individual. You don't know what deeply flawed is, bro. So I need you to understand something. Can we agree if this config works? Do I want to touch it? Ever? No, not ever. So guess what I don't want listed in here. I don't want anything hard coded that would cause me to go in here and touch this. I need to separate the data from my configuration. Now, here's the benefit that you get. I can change the configuration all day long. What won't go wrong? I could give it bad data and the configuration could fail. But what do I know did not go wrong? Nobody screwed with the code and the code is good. It'll pass its test, all this kind. I may have screwed up data, but if I change the data right and I put some validation, if I don't let users or myself change the configuration data directly, in fact, if I have them do it through an interface where the database that's being stored generates the configuration data, well, hell, I'm getting a lot of benefits. I got good running code that is stable, that's easy to maintain. I got it separated from it. My data separate from it. So it becomes a much more easier thing to maintain. So one of the first things that we recommend to people as they're working with this is you'll hear the term separate out your configuration data. This is easy to do. And I recommend that you take a look at the docs that Microsoft has on it. They have a great DSC docs that'll show you how to do this. However, all my code has that same thing in it too. And I'm going to give you all this code. So let me show you an example. If you look at these two files at the top, number two, simple config data, the PS1 is the configuration. The configuration is not going to change, except I'm now going to remove this stuff and put the data into a separate data file. Now I'm not going to go through all of the structure of the data file, because you can get that from docs and take a look online. But I did put at the top of all of these the big note from the documentation of what the different components are to remind you of it later. Here's the thing. Inside of here, all nodes is where we're going to have all the data that we want for our configuration. Now I have a question for you. I don't need you to really work hard here. I want you to do me a favor. See where it says, node name equals star? What computers do you think that data would apply to? How do you know it's all of them? Yeah, I told you the questions aren't that hard, because it's a store. See where it says, node name down here, S1? Anything in here will be available for? So right now, just the concept. Now guys, for details on this, I'm giving you all the articles for it, but just the concept is if it's in the star part, all your machines can get access to that data. They'll get it. And you can do unique data on a machine by machine basis, like S1, S2, S3, maybe S1. You get an extra SQL server. S2, you get an exchange. No, we went to 0365. We don't need that. So you can become something else. So you have control now on your machines. I'm going to make a big configuration file for a bunch of computers. I want that data in here, and I want to be able to separate that data for those different machines. Now, I didn't want to do this to you, but this works. But now I need to make this a little bit smarter. By the way, if you run this, you're going to get a moth file, and you're going to get S1, and it's going to be unique from all the stuff that you have. So this is going to work just fine. Now, the thing is this. This data is in a separate file. I've got to go to my configuration and tell it how to find that data when it needs it. So take a look here. I'm going to open up the config. The config is not different. I just put notes at the top to remind you what's going on. Look at the config. Does it have hard-coded data? What service am I stopping? Do you know? Go like this? No, you don't know. Because I've replaced it with a variable that can be filled with the data I want to go in there from the config data. Now, before you start freaking them out about this dollar sign node thing, because that's scary, I want you to see how you attach this. The two files are separate. When I run this config called test config, I can tell it where I want the moth file to go. But this is how I'm tying it to the configuration data. Oh, by the way, guys, my syntax coloring tool doesn't do PowerShell. So you'll notice this. I apologize. But when you bring it up into the ISC or VS Code, it'll look like you'd expect it to. So here, this connects that data file. Now what we need to do, since that data file gets loaded into memory, I need to reach into that data file and grab the data I want. Dollar sign node is where that data is. Now, there's actually a few variables that I've put up into the notes that will become important to you. And you're going to see me use them. But the first one we're going to start with is dollar sign node. Dollar sign node dot. And then whatever name you put over here in the data file. Take a look at the data file. See where it says destination path, service state, bit service, dsc feature, dnss feature? Equals. The name over here is the name you want to use over here. So dollar sign node.destinationPath. Now, that path could change 30 machines here, 40 machines here, 40 machines here. This code never gets altered. Only the data gets changed. So I know this is going to work. I have high probability of success. Are you kind of with me? Now, I know that for a lot of, some of you have done this. If you haven't, I know that looking at the code, you're like, well, I'm going to have to structurally get this. But besides the syntax of this, what do you think? Not too bad? Well, I've separated this. I don't know if I need to solve my problem. I don't know if I need to do this yet. On the day that you have the problem, you now this will be part one of your solution. This will be your first step to move to. Now, there's a couple of good things about this. First of all, this increases your maintainability. It reduces the risk of you touching stuff and breaking stuff. This is a good practice period.underline and how to do it. Now, the thing is, your configs start getting scary. This is really simple. And alls I did, I threw a bunch of stuff under node name, and I can grab it. $node.dns feature. $node.dns, whatever one I want. However, as you start to use this, something weird might happen to you, as it often does to me. You might notice that your configuration data for $start is getting ugly. Look at all the data I have in here for node name equals star. Look at all the things under there. In other words, this is an example of a configuration where it's going to build multiple machines and bring up infrastructure services that I need. I need domain controller, DNS, I need every all these things I need. So look at where all the data is. Now, at the time I wrote this, I thought, great. I'll just put in a little comment to kind of make it easier to separate and see and maintain. As this gets bigger and bigger, it's not easier to maintain. It's harder to maintain. Because it's like taking, you have 5,000 files, individual files, and you threw them all into the same folder. And somebody said, oh, I needed that file. Can you go find it for me? You're going to be there a long, freaking time looking for that file. Because you put everything in just the pfft. The other thing is, if I were building five VMs, I'm building a domain controller, a DNS box, and a few servers, how many boxes need to be a DNS server in this five server network? This data is an all nodes equals star. Everybody has this data. Everybody doesn't need this data. What if something runs and they grab data they shouldn't have? So this is not good. It's hard to work with. Well, this is where things become interesting. To handle this and other things, you will see in the docs something called a role-based configuration. How many of you have written either a role-based config, a composite config, or a partial? Excellent. Now look, for the type of work I do, I don't spend a lot of time with composites and partial. I know that at this conference, of all conferences, people have different modes and beliefs of whether you do this or don't do that and all that. And I agree that everybody should have those conversations. But I'm just saying I'm doing something called role-based for most of my stuff. And I'm not messing with composites and partials, because they add weight that I don't need. So that means I'm going to have one massive config and one massive generated configuration data file that could be thousands of lines of code. I need to make this maintainable and easier to do and easier to troubleshoot. This is not going to be that. So I got my solution working. But man, this was really hard to maintain over time. And every time then, I started messing with the data. I'd screw something up, all that. So I went to role-based. Here's what role-based looks like. And I'm going to take you back to the config. You will see this in the docs online. But take a look. All nodes, star, you know what's in there. That's data for all machines. Then I've got separate machines. Node name S1, node name S2. By the way, it does not have to be the word role. It could be whatever you want to call it. But when you're done screwing around with whatever word you want to call it, call it role. Equals make up a role name. Now, all this is going to be is a search tag for you. This will be the, you know, this guy, I want him to have DNS. This guy, I want him to be a DC. That's the role I'm defining. Are you with me so far? Is that pretty easy so far? Yes. So let me show you the config down here. Again, make sure you grab the configuration data file. Up here, dollar sign node. See, got it all in there. Now there's a tricky line. I know it looks chewy. Don't panic. Whoops, almost went off the stage there. Node, dollar sign all nodes. Again, explained in the comment. This is how you grab. I want everything in that config file. All nodes, dot, where? You guys have used where before, where, object, all that? So look at all nodes where that thing you called role is equal to DNS. So what do you think's going to happen when it runs this line? It's going to go to the config file. It's going to see which one has the role that says DNS. Got it. If any of those machines listed have the role DNS, grab the data you need, go and execute that resource. Are you with me? So now you're starting to separate the data into manageable pieces based upon the way you want the services and all that deployed. Yes, sir? So if I read this right, I've never used the s before, by the way. The top part of that applies to everything. And then you get specific roles. You got it. So I was just about to say, if you go all the way up to the top there where you see all nodes where true, that's going to be for everybody. And then these, I went specific machine. So I'm kind of almost building a hierarchy here. Here's what everybody needs, some data. And then I'm saying, well, but then I get to unique little snowflakes. Here's a snowflake, here's a snowflake, here's a snowflake, here's a snowflake, here's a snowflake. And now I'm going to start putting only the data that the snowflake needs in for the snowflake. But suddenly, that's going to get worse. This is a temporary solution that you're going to love right up until you don't. So let me give you this one. Here's when you're going to start not loving it. Notice I've got stuff, one, two, and three, these to go to everybody. I've got my stuff isolated. And as I start providing data for the configurations of those machines, you start to realize, in the real world, when you make a DHCP server, have you guys ever used the resource and configured a DHCP server? That's a lot of stuff you got to do. Well, I need this box to be DC, DHCP, DNS. Have this app, have this, have this, have this. These now are becoming huge. And they're getting harder to read, harder to maintain. Yes, you should be auto-generating this, like out of a database. But still, when it breaks, it's, oh my god, I can't figure out what's going on. And you're repeating the data in a lot of places. If you want to change one thing, now you have to find the five places you had to put it. So it's getting worse. And as an example, show you on a mind, it started getting worse. Whoops. So there's my all node, which is way out of control. And then I'm starting to get into my individual nodes. I realize these syntax highlighting does not work. But this is just real simple stuff. My data is starting to get out of control. And things are being repeated. And things are, oh, it's getting messier and messier. What I'd like to do is clean things up. Now, Missy wrote an article on non-node data. A lot of people don't understand this concept, and neither did I. So they didn't understand why I would need it. Well, now I've got a messy, messy configuration data that I am finding impossible to make reusable, because it's hard to maintain. So I want to start working with this data maybe in a different way. In other words, the things for all nodes, node name star, that's what everybody gets. That list is whatever size it's going to be. But what I'm not going to do is put unique data for machines in there for their roles. I'm just going to keep it as small as possible, down under node name role. That's I need that, so you could find the role. But I'm going to put as least amount of additional data there. I'm going to start creating something called non-node data. Now, we have ways for you to access anything you put into this thing called non-node data. Does anybody want to guess whether non-node data is a required, reserved word or not? In other words, do you have to type that word? You can call non-node data whatever you want. But no. Don't call it non-node data, because non-node data doesn't make any damn sense. Because I looked at it, and I'm like, well, the reason I don't understand it is because I don't mean it. Here's the thing. You don't have to call it non-node data. In fact, I don't want to call it non-node data. Yes, I could put stuff here. And yes, in the config, I can go over here to the config. Whoops. Over the config. And now take a look. I can call that by using, and the notes are up at the top, dollar sign configuration data dot non-node data is now exposed to me dot than whatever thing you want to grab. Well, that's kind of nice. I like that. I like that. That's cool. I don't. I'll just be, I don't like. See how I'm using dollar sign node dot? That's nice, clean, clear. Which line is easier to read? The line insure equals or the line name equals? Which one's easier to read? Or so how about, can we maybe, I want to solve this a little bit better. Oops, that's not where I wanted to solve it. Here, I'm going to show you a solution to that in just a minute. We're going to shorten that puppy up so that it looks just like dollar sign dot. Just a second. So watch. Transformation time. I don't call it non-node data. I call it for what data it holds. DC data. Everything I need to know about a domain controller goes here. Everything I need for DNS config goes here. Now, when somebody opens this file and it's all collapsed, they can open up just the part they need to see what's going on with. And that's the data that they should be looking at. Nothing else. So it drops the confusion, adds to the maintainability. But now, watch. When you want to call that data, look at the change here. Dollar sign configuration data dot. Now you just pick the name that you chose for the data, DC data. Does that make sense? You still don't like the length of it. But yeah? So let's make that a little bit better. Here's what I prefer to do. And by the way, if you look at Missy's article that I gave you the link to, she takes you step by step and explains each one of these components and takes you through this. Here's what I prefer to do. It's a line 30 up here, but let me do this one since my finger gets close. Dollar sign DNS data equals configuration data dot DNS data. Now all that data underneath there is a here. Does that look more maintainable and readable? Does it describe the data that should be there? Here's the thing. This is configuring DNS using the DNS data. Notice it doesn't say DC data. If this line said DC data, would that be wrong? It's not DC data. If this line said DC data, would that be wrong? Got it. I see it. Oh, somebody must have copied that. And they didn't. Oh, morons. Anyways, so you can see this better. What do you think so far? OK, now hang on. I know the code, if it's new to you, looks a little scary. But does it really look like hard code? No. It's the concept of how to solve these data problems as you're moving forward with your configs. So conceptually, you can break this up. But I've got to say something. Here's the concept. In the config file for this example, or the config data file, this is just a nice little example I want you to notice. I've got the all node name star stuff. I've got my nice clean machines here. By the way, when you run this, it's going to make a moth for S1 and for S2 with the right data for the role in it. Those moths are ready to be deployed. Are you with me? So here's the DC data. It stays clean. And as this grows, it gets clean. But I want you to see if you can look at the screen at the data down at the bottom. Here's where I want to start to introduce you to my next problem, the data in this section. We can have DNS servers. They can be Active Directory integrated, right? Which is kind of like the old fashioned primary DNS servers, right? It's writable. So I've got Active Directory integrated as a type. You can still do the old primaries. And I've got secondary DNS servers. We use them as cache servers a lot, right? So each one of those configs for DNS need to be a little bit different with its own unique data, but still share a common pool of data. In here, maybe all DNS servers that get built need this stuff. That's why I call it stuff. But a primary needs this unique piece, and a secondary needs this unique piece. Well, here's where Steve and Gail came in. Obviously, here's what I want you to get. The size and the amount of data that needs to go into this data file is getting larger because I have a stable configuration that can be run that always works, that can be used for one to a million machines with all unique characteristics. So as you're writing this role-based, styled configuration and getting it to solve machine problems, machine problems, basically, I do this for destroy and deploy. In other words, I'm sorry, the LA office just fell into the ocean. Not a problem. Azure, boom! The entire infrastructure, all services, all things, everything comes back. All machines, everything comes back. Well, I got this unique data. This is problem here is going to get worse. This is where Gail comes in. Because Gail and Steve worked out a way where I want you to kind of know. It's hard to see. And in this editor, I don't have a whole lot of control, but I've opened it up here at the top. And then I've got something nested inside, all nodes. And then I've got the non-node data called DC data and DNS data. You can now get, whoops, there's a keyboard up. Now the F keys. Oh boy, almost blue saying that word. But see, as this problem gets worse, what Gail and Steve were working on is underneath this, we can now create an additional hierarchy. It's almost like the inheritance of GPOs. No, I know you're going, dude, that's not funny. I know. But you're getting capabilities to maintain this data. Now, underneath here, you can start to break it down so that they share this, and only the primary gets this data, only the secondaries get this data, and it's still all in one place. And I want you to notice, what I'm doing along the way is I'm trying to remove things that get repeated so that they only are in one place, defined one place, defined one place, convenient and easy to find. I need to make a modification to the data for the DNS service. And so far, when I auto-created, it's not working. I need to go look at this. I know exactly where I need to be. I know exactly what I need to work with. I don't need to touch and screw up anything else. I never need to go to the actual configuration that already is a known working thing. So the only thing I'm messing with now is the data. Everything else is. But as the data gets more complex, I'm almost creating like database structure, hierarchy structures in here. And one of those reasons is, do you think I'm going to hand right these giant configs? Why won't I hand right them? Because, yeah, I am way more than deeply flawed. I will screw that up. Yeah, I'm going to have this generated from the data in the database. And maybe that data in the database already shows me how bad this problem is going to be. And so this allows me now to start structurally handling that data in a maintainable, go-forward way. If you are working with DSC in much larger scales, these are the kind of problems you start to run across that you have to solve. And you have to understand how you can get things to relate and make it kind of sort of. Kind of sort of? Little bit? It's OK. Because when Steve finished this, what, five years ago, we just all went, we'll never use this. Right, we'll never use this. And then, and Gail, here's, I'm going to tell you what happens. I run DSC camp. It's a thing for, it's basically level 500 and above. It's only about 20 guys and gals that come out. And these people are at the top of configuration management, not just with DSC, but with everything they do. And Gail, last year at DSC camp, oh, yeah, I'm going to talk about that thing that Steve does. He started talking about it. And literally, my jaw just started, because what I was fighting was this problem actually in full scale. And my brain is going, this is the most magical thing in the world. And as soon as he was done, I just ran up to him, you know, I love you, you solved everything. He's like, yeah, this has been solved for a while. It's just nobody understood it. And then this is what Steve was talking about. Really? Because I thought he was stupid. This makes sense. It doesn't make sense until you have the problem. But when it makes sense, then it's one of the best solutions out. So I encourage you to take my code. Play with my code. My code works. It's good little demos combined with the actual official docs. Work through this. If you're playing with this and you start to run anything, I guarantee you're going to be here. So play with this. What I've shown you so far is actually pretty straightforward and simple and will make your life happy if you start there. Missy's article, her end state, that's what you want to start with now. Just start doing it so that you're already doing it the right way. It's going to work. You can move forward. Then if you should hit the same kind of problems that some of us are hitting, he's going to help you solve that next step. Does that kind of make sense on where to go? One other thing on these and all this stuff. I'm working on a new project. I did a project a while back called AutoLab. It was kind of a thing that kind of on your machine would make a whole bunch of machines, whatever you wanted for you. I'm doing a new one that does it both locally and all in Azure. Don't ask me when it's going to come out because I don't know. But I'm working on it. I'm getting there. You run into this problem a lot now. And so it's getting, this solution makes everything work better. You want to start your configuration data out as clean and maintainable as possible. And at least let her show you and do it that way and then grow up to that. Questions? So this reminds me a lot of any normal system that goes into a specific thing. Hmm, how about that? Yes, absolutely. Yes, that's very good. I'm speaking a little bit more of a little bit more. And I have to say this, that if you are, if the term, this is a lot like the normalization of a database and its data and all that, if that term makes sense to you, good. That wasn't a term that made sense to me when I was working with this. I was sitting there going, okay, basically my brain was, I have multiple elements in this, in this bar and I just want to grab an element. And now it's out of freaking control and I don't know what to do. It never, I never, you know, as I hit the problem, it wasn't a data structure problem. It was, I'm not sure how I'm solving it. And then as I understood it, it then went, got it. Well, here's what I'm going to do. When I finish, I guess what the point was with the autolab thing was, is that when I finish the autolab, that'll all be free code. Plus how we, how we do our configs and all of that, which we generated out of a database. We're going to try to use the cleanest, best coding practices and data practices all the way through. Because I want it to be an example, right? The one thing though, out of that, that, that with the autolab stuff is we're running into these problems and we're going to write, I'm going to write articles around it when it releases so that you, in other words, it's going to be a teaching tool as well for DSC and that kind of thing. So we'll make that available too. I know this is kind of weird, but you're going to run across it. Thank you. Have a nice day. Have you guys done, don't forget to do that big eval thing. Remember take a few minutes to do it and leave comments about the show. What'd you like? What didn't you like? What sessions should we have? All that wonderful stuff. It's been wonderful having all of you here. When you all leaving. Now? No, I'm just kidding. We're going to be here all day. So again, all day, we'll be at the hotel tonight, all that kind of stuff. Everybody just have a great day and thank you for coming to the summit. Have a great day. Oh, stop, don't move a muscle. This code along with all code, I don't have the slide up here, is the repository is, right there's the name of it, PowerShell Summit 2018. It's off my repository, which is the Jason Helmick. So it's GitHub, the Jason Helmick and that's it. That repository will be lit by lunch. I also will be, it has my Gia stuff, this stuff and probably next week a lot of people have asked me for additional examples on things as we've been talking about stuff. I'll probably put more demos and examples in there next week as well and I'll leave this up for probably six, seven months. So you have plenty of time. Yeah? Now you can go. Thank you. Thank you.
 I'll turn the mic on and that kind of thing.  So how do you want your morning to go?  Do you want it to go easy?  Good, because it's not.  Here we go.  Guys, this is kind of a strange, and let me just tell you,  I'm just going to be right up front with you.  There's some of us that work with DSC  and working with DSC configurations  that are running into some problems,  and we've come up with some solutions.  The problem is some of these solutions  get complicated conceptually in a lot of people's brains.  In other words, they can't solve the problem,  not because the code is hard.  Let me just tell you this.  This is not chewy code.  The concepts are hard.  And so the code, you can copy and paste it all you want.  You're never going to make it work for you,  because you don't know what the hell you're trying to do.  So I see this all the time, and I struggle at time,  trying to learn the next step.  As a matter of fact, if you don't know Gail,  you will before you leave.  I struggle to understand some of the things that he knows.  And as Gail and a friend of ours said,  you don't really have a chance at understanding it  until you have the real problem.  In other words, I have this problem.  I don't know how to solve.  That's the solution for it.  Well, what I wanted to do is I've talked to a lot of people,  and I wanted to see if maybe I could get you up to that level  that if you run into that problem, you could solve it.  In other words, you'd be ready for that concept.  But to do that, I want to show you  how a lot of us are looking at managing and cleaning up  how we work with DSC configs and the configuration data for it.  And I'm going to start you at zero on how I do things  and take you up to the point of blissful happiness.  Now, here's the thing.  I'm showing you this so that when you have a problem  in the future, you can see where you can go to get the answer.  In other words, I remember that bald pudgy guy  was talking about this.  I need to go look at that because that was what I need now.  So you kind of see how this is weird.  It may not solve your problem today,  but it may be the solution for you tomorrow kind of thing.  OK, you don't sound impressed.  You're giving us a solution to a problem we don't have.  I was trying not to say it that way, but yes.  You don't care to be here until after you leave.  Then all of a sudden, you might care.  The other thing is how many of you guys work with DSC?  Now, let me quantify or let me explain what I mean  when I say that, though.  DSC is a platform.  So a lot of you may work through it  by using products like Puppet and Chef for configuration  management.  Are you with me?  Some of us also kind of make our own products  out of the platform of DSC.  So we work just with DSC.  I do both, but I really like working with DSC,  because here's the thing.  I don't understand how to solve the problems,  but as I'm working on them, I can, working with PowerShell  and DSC, that's not my problem.  And I don't want a language and all that kind of stuff  to be a problem when I'm trying to do this.  So I know this works, and I love working with it,  and it lets me learn in a comfortable environment  that I know really well.  So this is kind of what happened.  First of all, I want to give you a couple of shout outs.  There's a couple of people here.  First of all, how many of you know who Steven Moroski is?  He now works for Microsoft, but I  have to say that Steven Moroski was talking about this concept  what, five years ago?  2014.  And literally, he was sitting there going,  I have no idea what you're talking about.  And I went up and asked him.  I said, I have no idea.  He's like, it's OK.  When you actually have the problem, it'll make sense.  Well, when am I going to have the problem?  You have so many now.  Now, the other thing is that Gail also ran into this.  And Gail and Steve came up with some really cool solutions.  The thing is, is getting to that point of understanding  what those are.  It just so happens that also along the way  to get some good information that you can take home now  of cleaning up this kind of stuff, your configuration data,  Missy wrote an article.  As a matter of fact, take out your phones  and take a picture of that so you get the links  and all that kind of stuff.  Missy wrote an article.  As a matter of fact, I highly recommend that article,  along with my code, if you want to redo this.  The other thing I highly recommend  is if you start playing with this kind of stuff,  you will run into the problem.  When you run into the problem, he knows it better than anybody  else.  So Gail and his article, you're really  going to want these at some point  if you are working with DSC.  If you're not working with it, you're not going to run into this.  Kind of sort of maybe?  We OK?  OK.  All right.  So here we go.  By the way, who was here in my GIA session yesterday?  OK.  There is no execution of code in here.  So it's good for you to know that it's going to be OK.  Let's take a simple configuration.  So I got a lot of concepts that could be useful to you.  Here's a quick little DSC config that I just  for demo purposes that I wrote.  So see if it makes sense to you.  It's pretty simple.  I just have a configuration.  I put in the import DSC resource PSdesiredState configuration  just so it stopped giving me that little yellow message  if you do run this.  Everything I show you can be run in a Lamaqumaw file.  So it works.  I don't need to show you know run it for the maw files in here.  But I want you to see I've got some resources in here.  It doesn't just having some fun.  I got a file resource.  What am I going to do?  I'm going to stop a service.  I'm going to install a Windows feature,  a couple of Windows features.  I have a question for you.  Look at the config.  What service am I stopping?  What service do I expect to get?  Oh, OK, good.  Thanks.  I didn't look at my code.  What service would I like to be running?  Do I want it running or stopped?  How do you know this?  Because it's right there.  OK, so I have a question for you.  This config runs.  It works.  It's beautiful.  I send it out to 1,000 servers.  But now I need the BFE service stopped, not the bit service.  So what am I going to have to do?  Don't overthink this, guys.  These are easy questions.  What do I have to do to now do something to the BFE service?  I got a what?  I got to do what?  Say that out loud.  Say that out proud.  I got to change my code.  That's a nice way of saying, what is it that I actually have to do?  I have to open the code and now touch it.  What is likely to happen along the way?  If I touch it, I'm going to break it.  I find it hilarious when he says that,  the reason the PowerShell is so good  is because I'm a deeply flawed individual.  You don't know what deeply flawed is, bro.  So I need you to understand something.  Can we agree if this config works?  Do I want to touch it?  Ever?  No, not ever.  So guess what I don't want listed in here.  I don't want anything hard coded that would cause me to go in here  and touch this.  I need to separate the data from my configuration.  Now, here's the benefit that you get.  I can change the configuration all day long.  What won't go wrong?  I could give it bad data and the configuration could fail.  But what do I know did not go wrong?  Nobody screwed with the code and the code is good.  It'll pass its test, all this kind.  I may have screwed up data, but if I change the data right  and I put some validation, if I don't let users or myself change  the configuration data directly, in fact,  if I have them do it through an interface where the database that's  being stored generates the configuration data, well, hell,  I'm getting a lot of benefits.  I got good running code that is stable, that's easy to maintain.  I got it separated from it.  My data separate from it.  So it becomes a much more easier thing to maintain.  So one of the first things that we recommend to people  as they're working with this is you'll hear the term separate  out your configuration data.  This is easy to do.  And I recommend that you take a look at the docs  that Microsoft has on it.  They have a great DSC docs that'll show you how to do this.  However, all my code has that same thing in it too.  And I'm going to give you all this code.  So let me show you an example.  If you look at these two files at the top, number two,  simple config data, the PS1 is the configuration.  The configuration is not going to change,  except I'm now going to remove this stuff  and put the data into a separate data file.  Now I'm not going to go through all  of the structure of the data file,  because you can get that from docs and take a look online.  But I did put at the top of all of these  the big note from the documentation  of what the different components are to remind you of it later.  Here's the thing.  Inside of here, all nodes is where  we're going to have all the data that we  want for our configuration.  Now I have a question for you.  I don't need you to really work hard here.  I want you to do me a favor.  See where it says, node name equals star?  What computers do you think that data would apply to?  How do you know it's all of them?  Yeah, I told you the questions aren't that hard,  because it's a store.  See where it says, node name down here, S1?  Anything in here will be available for?  So right now, just the concept.  Now guys, for details on this, I'm  giving you all the articles for it, but just the concept  is if it's in the star part, all your machines  can get access to that data.  They'll get it.  And you can do unique data on a machine by machine basis,  like S1, S2, S3, maybe S1.  You get an extra SQL server.  S2, you get an exchange.  No, we went to 0365.  We don't need that.  So you can become something else.  So you have control now on your machines.  I'm going to make a big configuration  file for a bunch of computers.  I want that data in here, and I want  to be able to separate that data for those different machines.  Now, I didn't want to do this to you,  but this works.  But now I need to make this a little bit smarter.  By the way, if you run this, you're  going to get a moth file, and you're going to get S1,  and it's going to be unique from all the stuff that you have.  So this is going to work just fine.  Now, the thing is this.  This data is in a separate file.  I've got to go to my configuration  and tell it how to find that data when it needs it.  So take a look here.  I'm going to open up the config.  The config is not different.  I just put notes at the top to remind you what's going on.  Look at the config.  Does it have hard-coded data?  What service am I stopping?  Do you know?  Go like this?  No, you don't know.  Because I've replaced it with a variable that  can be filled with the data I want to go in there from the config  data.  Now, before you start freaking them out about this dollar  sign node thing, because that's scary,  I want you to see how you attach this.  The two files are separate.  When I run this config called test config,  I can tell it where I want the moth file to go.  But this is how I'm tying it to the configuration data.  Oh, by the way, guys, my syntax coloring tool  doesn't do PowerShell.  So you'll notice this.  I apologize.  But when you bring it up into the ISC or VS Code,  it'll look like you'd expect it to.  So here, this connects that data file.  Now what we need to do, since that data file gets loaded  into memory, I need to reach into that data file  and grab the data I want.  Dollar sign node is where that data is.  Now, there's actually a few variables  that I've put up into the notes that will become important to you.  And you're going to see me use them.  But the first one we're going to start with is dollar sign node.  Dollar sign node dot.  And then whatever name you put over here in the data file.  Take a look at the data file.  See where it says destination path, service  state, bit service, dsc feature, dnss feature?  Equals.  The name over here is the name you want to use over here.  So dollar sign node.destinationPath.  Now, that path could change 30 machines here, 40 machines here,  40 machines here.  This code never gets altered.  Only the data gets changed.  So I know this is going to work.  I have high probability of success.  Are you kind of with me?  Now, I know that for a lot of, some of you have done this.  If you haven't, I know that looking at the code,  you're like, well, I'm going to have to structurally get this.  But besides the syntax of this, what do you think?  Not too bad?  Well, I've separated this.  I don't know if I need to solve my problem.  I don't know if I need to do this yet.  On the day that you have the problem,  you now this will be part one of your solution.  This will be your first step to move to.  Now, there's a couple of good things about this.  First of all, this increases your maintainability.  It reduces the risk of you touching stuff and breaking stuff.  This is a good practice period.underline and how to do it.  Now, the thing is, your configs start getting scary.  This is really simple.  And alls I did, I threw a bunch of stuff under node name,  and I can grab it.  $node.dns feature.  $node.dns, whatever one I want.  However, as you start to use this,  something weird might happen to you, as it often does to me.  You might notice that your configuration data for $start  is getting ugly.  Look at all the data I have in here for node name equals star.  Look at all the things under there.  In other words, this is an example of a configuration  where it's going to build multiple machines  and bring up infrastructure services that I need.  I need domain controller, DNS, I need every all these things  I need.  So look at where all the data is.  Now, at the time I wrote this, I thought, great.  I'll just put in a little comment to kind of make it easier  to separate and see and maintain.  As this gets bigger and bigger, it's not easier to maintain.  It's harder to maintain.  Because it's like taking, you have 5,000 files,  individual files, and you threw them all into the same folder.  And somebody said, oh, I needed that file.  Can you go find it for me?  You're going to be there a long, freaking time  looking for that file.  Because you put everything in just the pfft.  The other thing is, if I were building five VMs,  I'm building a domain controller, a DNS box,  and a few servers, how many boxes need  to be a DNS server in this five server network?  This data is an all nodes equals star.  Everybody has this data.  Everybody doesn't need this data.  What if something runs and they grab data they shouldn't have?  So this is not good.  It's hard to work with.  Well, this is where things become interesting.  To handle this and other things, you  will see in the docs something called a role-based configuration.  How many of you have written either a role-based config,  a composite config, or a partial?  Excellent.  Now look, for the type of work I do,  I don't spend a lot of time with composites and partial.  I know that at this conference, of all conferences,  people have different modes and beliefs of whether you do this  or don't do that and all that.  And I agree that everybody should have those conversations.  But I'm just saying I'm doing something called  role-based for most of my stuff.  And I'm not messing with composites and partials,  because they add weight that I don't need.  So that means I'm going to have one massive config  and one massive generated configuration data file that  could be thousands of lines of code.  I need to make this maintainable and easier to do  and easier to troubleshoot.  This is not going to be that.  So I got my solution working.  But man, this was really hard to maintain over time.  And every time then, I started messing with the data.  I'd screw something up, all that.  So I went to role-based.  Here's what role-based looks like.  And I'm going to take you back to the config.  You will see this in the docs online.  But take a look.  All nodes, star, you know what's in there.  That's data for all machines.  Then I've got separate machines.  Node name S1, node name S2.  By the way, it does not have to be the word role.  It could be whatever you want to call it.  But when you're done screwing around  with whatever word you want to call it, call it role.  Equals make up a role name.  Now, all this is going to be is a search tag for you.  This will be the, you know, this guy, I want him to have DNS.  This guy, I want him to be a DC.  That's the role I'm defining.  Are you with me so far?  Is that pretty easy so far?  Yes.  So let me show you the config down here.  Again, make sure you grab the configuration data file.  Up here, dollar sign node.  See, got it all in there.  Now there's a tricky line.  I know it looks chewy.  Don't panic.  Whoops, almost went off the stage there.  Node, dollar sign all nodes.  Again, explained in the comment.  This is how you grab.  I want everything in that config file.  All nodes, dot, where?  You guys have used where before, where, object, all that?  So look at all nodes where that thing you called role  is equal to DNS.  So what do you think's going to happen when it runs this line?  It's going to go to the config file.  It's going to see which one has the role that says DNS.  Got it.  If any of those machines listed have the role DNS,  grab the data you need, go and execute that resource.  Are you with me?  So now you're starting to separate the data  into manageable pieces based upon the way  you want the services and all that deployed.  Yes, sir?  So if I read this right, I've never used the s before,  by the way.  The top part of that applies to everything.  And then you get specific roles.  You got it.  So I was just about to say, if you go all the way up  to the top there where you see all nodes where true,  that's going to be for everybody.  And then these, I went specific machine.  So I'm kind of almost building a hierarchy here.  Here's what everybody needs, some data.  And then I'm saying, well, but then I  get to unique little snowflakes.  Here's a snowflake, here's a snowflake,  here's a snowflake, here's a snowflake, here's a snowflake.  And now I'm going to start putting only the data  that the snowflake needs in for the snowflake.  But suddenly, that's going to get worse.  This is a temporary solution that you're  going to love right up until you don't.  So let me give you this one.  Here's when you're going to start not loving it.  Notice I've got stuff, one, two, and three,  these to go to everybody.  I've got my stuff isolated.  And as I start providing data for the configurations  of those machines, you start to realize,  in the real world, when you make a DHCP server,  have you guys ever used the resource  and configured a DHCP server?  That's a lot of stuff you got to do.  Well, I need this box to be DC, DHCP, DNS.  Have this app, have this, have this, have this.  These now are becoming huge.  And they're getting harder to read, harder to maintain.  Yes, you should be auto-generating this,  like out of a database.  But still, when it breaks, it's, oh my god,  I can't figure out what's going on.  And you're repeating the data in a lot of places.  If you want to change one thing, now  you have to find the five places you had to put it.  So it's getting worse.  And as an example, show you on a mind,  it started getting worse.  Whoops.  So there's my all node, which is way out of control.  And then I'm starting to get into my individual nodes.  I realize these syntax highlighting does not work.  But this is just real simple stuff.  My data is starting to get out of control.  And things are being repeated.  And things are, oh, it's getting messier and messier.  What I'd like to do is clean things up.  Now, Missy wrote an article on non-node data.  A lot of people don't understand this concept,  and neither did I.  So they didn't understand why I would need it.  Well, now I've got a messy, messy configuration data  that I am finding impossible to make reusable,  because it's hard to maintain.  So I want to start working with this data maybe  in a different way.  In other words, the things for all nodes, node name star,  that's what everybody gets.  That list is whatever size it's going to be.  But what I'm not going to do is put unique data for machines  in there for their roles.  I'm just going to keep it as small as possible,  down under node name role.  That's I need that, so you could find the role.  But I'm going to put as least amount of additional data  there.  I'm going to start creating something called non-node data.  Now, we have ways for you to access anything you put  into this thing called non-node data.  Does anybody want to guess whether non-node data is  a required, reserved word or not?  In other words, do you have to type that word?  You can call non-node data whatever you want.  But no.  Don't call it non-node data, because non-node data  doesn't make any damn sense.  Because I looked at it, and I'm like, well,  the reason I don't understand it is because I don't mean it.  Here's the thing.  You don't have to call it non-node data.  In fact, I don't want to call it non-node data.  Yes, I could put stuff here.  And yes, in the config, I can go over here to the config.  Whoops.  Over the config.  And now take a look.  I can call that by using, and the notes are up at the top,  dollar sign configuration data dot non-node data is now exposed  to me dot than whatever thing you want to grab.  Well, that's kind of nice.  I like that.  I like that.  That's cool.  I don't.  I'll just be, I don't like.  See how I'm using dollar sign node dot?  That's nice, clean, clear.  Which line is easier to read?  The line insure equals or the line name equals?  Which one's easier to read?  Or so how about, can we maybe, I want to solve this a little bit  better.  Oops, that's not where I wanted to solve it.  Here, I'm going to show you a solution to that in just a  minute.  We're going to shorten that puppy up so that it looks just  like dollar sign dot.  Just a second.  So watch.  Transformation time.  I don't call it non-node data.  I call it for what data it holds.  DC data.  Everything I need to know about a domain controller goes here.  Everything I need for DNS config goes here.  Now, when somebody opens this file and it's all collapsed,  they can open up just the part they need to see what's going  on with.  And that's the data that they should be looking at.  Nothing else.  So it drops the confusion, adds to the maintainability.  But now, watch.  When you want to call that data, look at the change here.  Dollar sign configuration data dot.  Now you just pick the name that you chose for the data, DC  data.  Does that make sense?  You still don't like the length of it.  But yeah?  So let's make that a little bit better.  Here's what I prefer to do.  And by the way, if you look at Missy's article that I gave  you the link to, she takes you step by step and explains each  one of these components and takes you through this.  Here's what I prefer to do.  It's a line 30 up here, but let me do this one since my  finger gets close.  Dollar sign DNS data equals configuration data dot DNS  data.  Now all that data underneath there is a  here.  Does that look more maintainable and readable?  Does it describe the data that should be there?  Here's the thing.  This is configuring DNS using the DNS data.  Notice it doesn't say DC data.  If this line said DC data, would that be wrong?  It's not DC data.  If this line said DC data, would that be wrong?  Got it.  I see it.  Oh, somebody must have copied that.  And they didn't.  Oh, morons.  Anyways, so you can see this better.  What do you think so far?  OK, now hang on.  I know the code, if it's new to you, looks a little scary.  But does it really look like hard code?  No.  It's the concept of how to solve these data problems as  you're moving forward with your configs.  So conceptually, you can break this up.  But I've got to say something.  Here's the concept.  In the config file for this example, or the config data  file, this is just a nice little example I want you to  notice.  I've got the all node name star stuff.  I've got my nice clean machines here.  By the way, when you run this, it's going to make a  moth for S1 and for S2 with the right data for the role in  it.  Those moths are ready to be deployed.  Are you with me?  So here's the DC data.  It stays clean.  And as this grows, it gets clean.  But I want you to see if you can look at the screen at the  data down at the bottom.  Here's where I want to start to introduce you to my next  problem, the data in this section.  We can have DNS servers.  They can be Active Directory integrated, right?  Which is kind of like the old fashioned primary DNS  servers, right?  It's writable.  So I've got Active Directory integrated as a type.  You can still do the old primaries.  And I've got secondary DNS servers.  We use them as cache servers a lot, right?  So each one of those configs for DNS need to be a little bit  different with its own unique data, but still share a  common pool of data.  In here, maybe all DNS servers that get built need this  stuff.  That's why I call it stuff.  But a primary needs this unique piece, and a secondary  needs this unique piece.  Well, here's where Steve and Gail came in.  Obviously, here's what I want you to get.  The size and the amount of data that needs to go into this  data file is getting larger because I have a stable  configuration that can be run that always works, that can  be used for one to a million machines with all unique  characteristics.  So as you're writing this role-based, styled  configuration and getting it to solve machine problems,  machine problems, basically, I do this for  destroy and deploy.  In other words, I'm sorry, the LA office just fell  into the ocean.  Not a problem.  Azure, boom!  The entire infrastructure, all services, all things,  everything comes back.  All machines, everything comes back.  Well, I got this unique data.  This is problem here is going to get worse.  This is where Gail comes in.  Because Gail and Steve worked out a way where I want you to  kind of know.  It's hard to see.  And in this editor, I don't have a whole lot of control, but  I've opened it up here at the top.  And then I've got something nested inside, all nodes.  And then I've got the non-node data called DC data and  DNS data.  You can now get, whoops, there's a keyboard up.  Now the F keys.  Oh boy, almost blue saying that word.  But see, as this problem gets worse, what Gail and Steve  were working on is underneath this, we can now create an  additional hierarchy.  It's almost like the inheritance of GPOs.  No, I know you're going, dude, that's not funny.  I know.  But you're getting capabilities to maintain this data.  Now, underneath here, you can start to break it down so  that they share this, and only the primary gets this data,  only the secondaries get this data, and it's still all in  one place.  And I want you to notice, what I'm doing along the way is I'm  trying to remove things that get repeated so that they only  are in one place, defined one place,  defined one place, convenient and easy to find.  I need to make a modification to the data for the DNS  service.  And so far, when I auto-created, it's not working.  I need to go look at this.  I know exactly where I need to be.  I know exactly what I need to work with.  I don't need to touch and screw up anything else.  I never need to go to the actual configuration that  already is a known working thing.  So the only thing I'm messing with now is the data.  Everything else is.  But as the data gets more complex, I'm almost creating  like database structure, hierarchy structures in here.  And one of those reasons is, do you think I'm going to hand  right these giant configs?  Why won't I hand right them?  Because, yeah, I am way more than deeply flawed.  I will screw that up.  Yeah, I'm going to have this generated from the data in the  database.  And maybe that data in the database already shows me how  bad this problem is going to be.  And so this allows me now to start structurally handling  that data in a maintainable, go-forward way.  If you are working with DSC in much larger scales, these are  the kind of problems you start to run across that you have  to solve.  And you have to understand how you can get things to relate  and make it kind of sort of.  Kind of sort of?  Little bit?  It's OK.  Because when Steve finished this, what, five years ago, we  just all went, we'll never use this.  Right, we'll never use this.  And then, and Gail, here's, I'm going to tell you what happens.  I run DSC camp.  It's a thing for, it's basically level 500 and above.  It's only about 20 guys and gals that come out.  And these people are at the top of configuration management,  not just with DSC, but with everything they do.  And Gail, last year at DSC camp, oh, yeah, I'm going to talk  about that thing that Steve does.  He started talking about it.  And literally, my jaw just started, because what I was  fighting was this problem actually in full scale.  And my brain is going, this is the most magical thing in the  world.  And as soon as he was done, I just ran up to him, you know,  I love you, you solved everything.  He's like, yeah, this has been solved for a while.  It's just nobody understood it.  And then this is what Steve was talking about.  Really?  Because I thought he was stupid.  This makes sense.  It doesn't make sense until you have the problem.  But when it makes sense, then it's one of the best solutions  out.  So I encourage you to take my code.  Play with my code.  My code works.  It's good little demos combined with the actual official  docs.  Work through this.  If you're playing with this and you start to run anything,  I guarantee you're going to be here.  So play with this.  What I've shown you so far is actually pretty straightforward  and simple and will make your life happy if you start there.  Missy's article, her end state, that's what you want to start  with now.  Just start doing it so that you're already doing it the  right way.  It's going to work.  You can move forward.  Then if you should hit the same kind of problems that some of  us are hitting, he's going to help you solve that next step.  Does that kind of make sense on where to go?  One other thing on these and all this stuff.  I'm working on a new project.  I did a project a while back called AutoLab.  It was kind of a thing that kind of on your machine would  make a whole bunch of machines, whatever you wanted for you.  I'm doing a new one that does it both locally and all in Azure.  Don't ask me when it's going to come out because I don't know.  But I'm working on it.  I'm getting there.  You run into this problem a lot now.  And so it's getting, this solution makes everything work better.  You want to start your configuration data out as clean and  maintainable as possible.  And at least let her show you and do it that way and then grow up to that.  Questions?  So this reminds me a lot of any normal system that goes  into a specific thing.  Hmm, how about that?  Yes, absolutely.  Yes, that's very good.  I'm speaking a little bit more of a little bit more.  And I have to say this, that if you are, if the term, this is a lot like  the normalization of a database and its data and all that, if that term makes  sense to you, good.  That wasn't a term that made sense to me when I was working with this.  I was sitting there going, okay, basically my brain was, I have multiple  elements in this, in this bar and I just want to grab an element.  And now it's out of freaking control and I don't know what to do.  It never, I never, you know, as I hit the problem, it wasn't a data structure  problem.  It was, I'm not sure how I'm solving it.  And then as I understood it, it then went, got it.  Well, here's what I'm going to do.  When I finish, I guess what the point was with the autolab thing was, is that  when I finish the autolab, that'll all be free code.  Plus how we, how we do our configs and all of that, which we generated out of  a database.  We're going to try to use the cleanest, best coding practices and data  practices all the way through.  Because I want it to be an example, right?  The one thing though, out of that, that, that with the autolab stuff is we're  running into these problems and we're going to write, I'm going to write  articles around it when it releases so that you, in other words, it's going to  be a teaching tool as well for DSC and that kind of thing.  So we'll make that available too.  I know this is kind of weird, but you're going to run across it.  Thank you.  Have a nice day.  Have you guys done, don't forget to do that big eval thing.  Remember take a few minutes to do it and leave comments about the show.  What'd you like?  What didn't you like?  What sessions should we have?  All that wonderful stuff.  It's been wonderful having all of you here.  When you all leaving.  Now?  No, I'm just kidding.  We're going to be here all day.  So again, all day, we'll be at the hotel tonight, all that kind of stuff.  Everybody just have a great day and thank you for coming to the summit.  Have a great day.  Oh, stop, don't move a muscle.  This code along with all code, I don't have the slide up here, is the repository is, right  there's the name of it, PowerShell Summit 2018.  It's off my repository, which is the Jason Helmick.  So it's GitHub, the Jason Helmick and that's it.  That repository will be lit by lunch.  I also will be, it has my Gia stuff, this stuff and probably next week a lot of people  have asked me for additional examples on things as we've been talking about stuff.  I'll probably put more demos and examples in there next week as well and I'll leave  this up for probably six, seven months.  So you have plenty of time.  Yeah?  Now you can go.  Thank you.  Thank you.
Managing_Advanced_DSC_0_47.png Managing_Advanced_DSC_48_95.png Managing_Advanced_DSC_96_143.png Managing_Advanced_DSC_144_227.png Managing_Advanced_DSC_228_5747.png Managing_Advanced_DSC_5748_8543.png Managing_Advanced_DSC_8544_8963.png Managing_Advanced_DSC_8964_15335.png Managing_Advanced_DSC_15336_18827.png Managing_Advanced_DSC_18828_21179.png Managing_Advanced_DSC_21180_21563.png Managing_Advanced_DSC_21564_23171.png Managing_Advanced_DSC_23172_23639.png Managing_Advanced_DSC_23640_23687.png Managing_Advanced_DSC_23688_27983.png Managing_Advanced_DSC_27984_29315.png Managing_Advanced_DSC_29316_31295.png Managing_Advanced_DSC_31296_31391.png Managing_Advanced_DSC_31392_32711.png Managing_Advanced_DSC_32712_34283.png Managing_Advanced_DSC_34284_34331.png Managing_Advanced_DSC_34332_34379.png Managing_Advanced_DSC_34380_34427.png Managing_Advanced_DSC_34428_34847.png Managing_Advanced_DSC_34848_34895.png Managing_Advanced_DSC_34896_34943.png Managing_Advanced_DSC_34944_37631.png Managing_Advanced_DSC_37632_37703.png Managing_Advanced_DSC_37704_37751.png Managing_Advanced_DSC_37752_39191.png Managing_Advanced_DSC_39192_39623.png Managing_Advanced_DSC_39624_39671.png Managing_Advanced_DSC_39672_40691.png Managing_Advanced_DSC_40692_41219.png Managing_Advanced_DSC_41220_41291.png Managing_Advanced_DSC_41292_41339.png Managing_Advanced_DSC_41340_43643.png Managing_Advanced_DSC_43644_47771.png Managing_Advanced_DSC_47772_47819.png Managing_Advanced_DSC_47820_47867.png Managing_Advanced_DSC_47868_48203.png Managing_Advanced_DSC_48204_53843.png Managing_Advanced_DSC_53844_60887.png Managing_Advanced_DSC_60888_60935.png Managing_Advanced_DSC_60936_60983.png Managing_Advanced_DSC_60984_61031.png Managing_Advanced_DSC_61032_61074.png