Introduction to Windows PowerShell - Windows Server Tutorial

Alright, so Windows PowerShell. It's a really, really, really big deal. And a lot of people don't quite get into it, don't quite understand what it is and why it's such a big deal. So in this introduction, I think you'll see that it's an exceptionally powerful tool, or set of tools, or a bunch of stuff that you can do. And you can use it manage Windows. Not just Windows Server but Windows Client, all kinds of different platforms, operating systems based on Windows. It's worth learning, it's worth understanding about. And this is just the first taste. As you learn about different components in Windows Server 2012, different client components, different configuration options, you'll actually see PowerShell come up over and over and over again. In fact, in almost all cases you'll actually see that PowerShell is an option for managing clients and servers right alongside the Gooey tools like Server Manager or Active Directory Users and Computers, things like that. So I'll actually give you a taste of it here, and then you'll see it again and again and again. So first of all, what is PowerShell itself and then what is it made out of? These things called "cmdlets" are really what PowerShell is made out of. What's that all about? What does that do for me and why is it a big deal? Then how does PowerShell fit into some kind of management component or management infrastructure or approach? We'll cover that as well. So first of all, what is it? What is Windows Powershell? And to listen to some folks talk you would think it's better than sliced bread. You would think it's the end-all be-all of server management. It's the coolest thing in the world. And it has its place, but before you get into how good it is or how bad it is, or how annoying it is or how complicated it is or how hard it is to remember, all of that stuff, it's important to remember what it is first. And what it is, is basically a command-line interface into the guts of Windows, allowing you to get information out of Windows, allowing you to change information in Windows, allowing you to find out what's going on inside the operating system and potentially do some things with it. Like for example, finding out if a server is using DHCP. And if it is, finding out what the DHCP address is. And if it's not, configuring static IP addressing. That kind of stuff. So really, really, really interesting and powerful. And that's a very, very basic example. There's virtually no end to the different kinds of things you can do with PowerShell to Windows. The different configuration options, the different data you can suck out of it and process. It's actually really, really great in that respect. It's really powerful. The last bullet here is kind of the one that's near and dear to my heart. You hear people argue back and forth, is PowerShell code, is PowerShell not code? Is PowerShell scripting? Is PowerShell not scripting? Is PowerShell just a command-line interface? If so, what's the difference between that and typing CMD and pressing Enter and getting a command prompt? So, yes and no. It's actually all of those and none of those. What we can agree on at this level is that this thing is text-based. Yeah? Kind of looks like text-base. It looks like letters, probably in Courier or Lucidia, white letters on a blue background. What does that mean? It means that it's a very, very basic interface. A very, very straightforward, direct way to interface with the system. That's both great and not great, depending on how you like to use it. But I'll talk about how to use it in just a few minutes. What can it do? Really just about anything. There's very, very, very little that PowerShell cannot do. And to be honest, some of it gets done better in PowerShell. Some tasks, some automations, some types of configuration get done better in PowerShell than in graphical tools, than in other kinds of ways. Some are worse in PowerShell, some take longer and are more complicated, more difficult to configure and change. So PowerShell definitely is an extremely strong player. There's very little that PowerShell can't do in Windows. But sometimes it's harder to do in PowerShell than it is in the Gooey or through Server Manager or through another type of tool or through a remote desktop connection perhaps. So there's definitely a time and a place for Powershell, but it's not all the time and every place, no matter what some other instructors, particularly the ones with bald heads named "Jason," tell you. That's just not the case. The PowerShell infrastructure itself is actually based on these little things called "cmdlets" that are both built-in and extend PowerShell. And so you might say to yourself, "What is a cmdlet?" Well funny, I actually have some information on that. Cmdlets, they're these little, tiny task-based functions. Essentially they're little, tiny commands that run one thing or a small set of things. They're generally designed by MicroSoft code developers, by feature owners, by role owners, by component owners of Windows itself. And those people sit down, actually just as a bit of an insight into Windows planning, they sit down at the beginning of a Windows development cycle and while they're figuring out what features they're going to add, what they're going to change, what they're going to make new, what they're going to remove, all of that, they actually think to themselves "What kind of stff "would an administrator want to change and should "I automate it, should I provide a cmdlet that changes "this particular component or this feature "or this little tiny bit? "Should I also provide a cmdlet that changes "the entire thing in a big way? "Should I automate some of that? "Should I abstract the administrator from having to "make some of these decisions and provide some of "this data or should I let them actually make all of "those tiny, little idiosyncratic changes as variables, "or as parts of that command?" That's actually how these PowerShell functions, these cmdlets show up, is through that kind of process. The other nice bit about cmdlets is that they can be used one at a time, so if you just want to use one at a time, if you just want to run Add-Computer, great. You can run just a single PowerShell cmdlet to add a computer to a domain. No problem. Or if you want to run that as part of a larger process. If you wanted to Add-Computer, Restart-Computer, change a bunch of stuff around the computer account, change stuff on the computer itself, you can actually add that to part of a larger process, part of a larger script that will go through ordinal. And there's conditions and there's variables. There's input and output, all that kind of stuff. So it can be as simple or as complex as you really want to make it be, to be. At this point, usually I'll have students ask me, "But this sounds just like a command prompt, right?" The old cmd, the old character-based command prompt. And it kind of is, and it kind of isn't. PowerShell is a little bit more portable in that it will run across an infrastructure. Command-prompt type scripting or command-prompt scripting was really designed and kind of limited by the fact that it would have to run on one place, on one computer at a time, one system at a time, rather than PowerShell that can run across all servers in an enterprise or across all client computers. Or based-on conditions, like for all computers that show through WMI that they have a battery configure power saving options to look like this. That's the kind of stuff that PowerShell can do. And it's really wicked cool. So I mentioned that it can be code-ish or not code-ish. It actually has a lot of attributes, PowerShell does of code, of kind of what we'd think of as higher level language coding. It's got an authoring environment, it's reusable, it's portable, it's got an awful lot of great help built in, which is really, really cool. Thank you June Blender for pumping a bunch of that stuff in. So it's got an awful lot of stuff, an awful lot of attributes where if you stood back for a moment and said "What is PowerShell?" it could be code, it could not be code. It really depends. But it doesn't matter. To be honest, it really doesn't matter. We don't want to think in terms of just bottle-necking into "is it code or not code," other than "I don't like to write code." When your response to code is "I don't like to write code" then you probably don't like PowerShell, because PowerShell feels codish enough where you're probably not going to enjoy it very much. And I'll go on record saying you don't have to like PowerShell very much. You don't have to know PowerShell today. And I'm waiting for someone to barge through the door and assault me because there's a lot of folks, there's a lot of zealots out there that say that PowerShell is critical, PowerShell is necessary. PowerShell is just another tool in your portfolio. If you like it, if you enjoy interfacing with the system, if it gives you the benefits you're looking for, use it. If it doesn't do those things for you, don't use it. There's other ways to do virtually everything you want to do with Server. And that's really leading into how we look at PowerShell as part of a server management methodology. First of all, the important component about PowerShell that it really brings is that if you, excuse me, throat's getting a little dry. If you recall, one of the major features behind Windows Server 2012 is the fact that it's very cloud-enabled, right? It runs in data centers, It powers cloud-based infrastructures, stuff like that. I won't go through all the marketing terms. But at its core the cloud means that resources are everywhere. So I have a data center in Phoenix. And I have a data center in New Haven, Connecticut. And I have a data center in San Diego, California. And I have a data center in Beijing. I have these data centers everywhere. Can I rely on local management? Can I rely on walking up to this computer and touching it and logging in? No, not anymore, not in 2012. At the same time there's very few services and features that users find valuable that run on exactly one system. You'd probably agree that most email systems have several servers, even in smaller companies or mid-sized companies. Sometimes several hundred deployed throughout the world. If you think about Googe itself as a company, its search engine is distributed across the globe. Thousands and thousands of servers and routers and switches, oh my. You can't manage all of those by walking up to them one at a time and touching the keyboard and touching the mouse, it's not going to work. So there's got to be a way to manage these things without being a local system administrator. Those are critical components of today's paradigm for server management. And the nice thing about remote management really is that it does a lot of different stuff, mainly in terms of minimizing resource use. So if you don't have a Gooey, it you don't have to have a keyboard or mouse plugged in, if you don't actually have to log in locally, Windows doesn't have to load all those features. Windows doesn't have to run all of that software. That saves memory, that saves CPU, that saves hard drive, that's all great stuff. We like that very much, especially when we're talking about hundreds, thousands, tens of thousands of systems. These tools, PowerShell in particular, is also great about managing several machines at a time, or hundreds of computers at a time rather than just one. Sitting down, you'd probably agree, sitting down at a server with a keyboard and a mouse and a monitor, you're monitoring, most likely, one server at a time. That's not so good if you've got servers throughout the world, if you've got multiple data centers. So some management technique, or technology, that distributes across the world, that goes across groups, you know, arbitrary groups of self-defining groups or does queries, runs all that stuff across, that's useful. That's actually one of the biggest assets I think of PowerShell is its flexibility and its scalability across the world or across at least your IT infrastructure. The last one, I want to make sure I'm really clear on this, on this last bullet, Enable Better IT Documentation, what that means is because PowerShell is text-based, you can copy and paste all that stuff out to Notepad or to Word or to Infopath or whatever you want to copy and paste it to. Save it out in Sharepoint. So you can actually document what you're doing on your systems and the results. Compare that to a Gooey tool like Server Manager or Active Directory Users and Computers, any of that stuff. You clicky clicky, draggy draggy, you know, movy movy, all that kind of stuff. Right click, shift alt double left click kind of stuff. That, you can Camtasia that or record it in some way, but largely it's more difficult to record and to save and to document what you're doing there versus something like PowerShell where you can simply copy and past it, it's just text. It also becomes searchable, it becomes reusable. It's great for audit compliance, showing what you've done to systems by actually printing out or supplying text files of this is the change log for this server. Not just "On this date I went in and changed "the computer name," no. Actually "Here's the input and here's the output. "Here's exactly what happened." It's better than Event Log, it's better than a Gooey video recorder. It's actually extremely comprehensive. That's what I mean by better documentation. It's quite lovely like that. As I mentioned several times now already, so I'll just cover this very briefly, PowerShell is one management option. It's not the only management option. It's not the best management option. It's not the worst management option. It's not my favorite, it's not my least favorite. It's an option that should be in your portfolio. It should be in your choice of tools. But ultimately my advice is figure out what the best tool is for the job. What are you comfortable with? Do you like writing code? Great, this is awesome. Do you like interfacing with the command prompt? Great, this is great, this is fantastic. You'll love it to death. Oh, you don't like that actually? Cool, if you don't like that, if you prefer Gooey tools, if you prefer right click, if you prefer seeing things visually, this is probably not the right tool for you. But you should at least know what it is, understand its capabilities, put it in its place. And so to review, PowerShell is pretty amazing. It's pretty strong in that its got an extensive architecture based on cmdlets. So as you plug stuff into Windows Server 2012, as you get more client and server operating systems, more features like SQEL or SMS or anything like that, PowerShell gets extended exchange, all that stuff. PowerShell gets extended so you can use the same kind of management approach for those. So it's really flexible, really robust. But it's not the only technique that you need to be aware of. You need to understand that if you're comfortable with this, if you like using it, if you want to learn more about it, fantastic. You'll see it over and over and over again. Whenever you're learning about Windows Server 2012, Windows 7 or 8, you're probably learning about PowerShell to some degree. So keep aware of it, keep an open mind. But don't think that you're being slammed into this one solution for server management because that's not the case at all. There's still plenty of options to manage servers.