There are thousands of PowerShell commands built-in, and there even more available to you as you add roles to your server. The challenge is how to find the correct commands and install the necessary modules to do your work. In this video you will see how to find, install and work with modules. We'll also talk about execution policies in this context.
- [Voiceover] Now one of the great things about PowerShell is just the number of commands and commandlets that we can run on a server. But in previous videos, I really talked about that's not all that's there, there's a lot more that's available to you. Now commands come down in a thing called a module, and all a module is is a collection of commandlets for a particular function. VMware has modules for its tools, Citrix has its tools, Azure, Office 365, they all have their own modules, and you even have additional modules on your systems that may not be available to you, because they haven't been installed yet.
So the question becomes how do I find those modules, how do I install them, and how can I start taking advantage of them? So I'm going to go ahead and just run a quick command, to just remind us what get command looks like. Remember all the different commands that we have available on a system. Now how do I know that's all of them? Well, I don't, but what I can also run is what do I have available to me? What else is out there that hasn't been currently installed? So what I'm going to do is just run get module, and I'm going to say list available, and what this is going to do is show me all the modules that are on my system that are available for me to actually use in leverage.
Now these modules haven't been loaded. Now the nice thing about this, unlike previous versions of PowerShell where you had to remember, and you had to import all the modules into your system, you no longer have to do that. Inside of PowerShell 3.0 and greater, we actually have what is called module autoloading, so if you happen to call a command out of a module that hasn't been loaded yet, it will actually do it automatically for you. But let me show you the process of how you can actually manually load your modules, and this is common inside of scripts, you'll see a lot of these statements at the beginning of a lot of scripts inside of the PowerShell world.
Import module, and I'm just going to say name, and I'm going to say I want to import applocker, which is just one of the modules built into most Windows systems, and it's going to bring up, it runs that command, everything's working fine. Now if I want to see what commands are there, I simply say get command, followed by the module parameter, and then I tell it applocker, and what it's going to do is show me all the specific commandlets that are there, so as you can work with PowerShell, there's lots and lots, and we're talking thousands of commandlets. Generally speaking, you're going to have very focused ability on what you want to do, and actually install on the systems for you.
Now one of the things that you might leverage as you're working with PowerShell, is once again the community has done a lot of great work, so you may not always have to remember which modules or which commandlets, and you want to reverse engineer some things. Well, the modules and commandlets that we have based on the system help us generate and create scripts. Well, one of the nice things that's out on the World Wide Web in the tech environment is the PowerShell gallery, the repository, where we actually have scripts that are out there. And you'll notice that I have actually have a script resources, and they have scripts for pretty much every language imaginable across many, many, many functions that are there inside of it, and you can filter on PowerShell or VB Script, or C Sharp.
It really depends on what you write your scripting language in. The thing I'll point out though is that there's over 6,000 scripts, that's 2,000 clear of its closest competitor, which is VB Scripts, so people write PowerShell, and actually support this community. So when you start working with your modules, and you start creating those scripts that are inside the world, you're not going to have to reinvent the wheel, you can do a lot of reverse engineering, there's been a lot of great work done by the PowerShell community. So as you start working with the modules, start trying to identify work loads, my advice to you is go take a look at the PowerShell gallery first and say hey, what's out there, what's in that repository that I can actually use, what's in that gallery that I can already use that I can take and leverage for my existing environment? Now, as you start to work with the scripts and the galleries that are out there, you're probably going to run in to some security issues with PowerShell, specifically around a policy called execution policy.
Let me hop back into my PowerShell command prompt and show you what I mean. So I'm going to hop back inside of here, and I'm going to get what is called my execution policy, and let me talk about what this is going to come up with. What this does is when you work with scripts and download scripts, PowerShell doesn't trust them, matter of fact, doesn't trust them by default. It only trusts scripts and things that are created on the local machine. Even if I took a script I created here, and tried to run it remotely on another server, I'd most likely get an executionary and access denied message.
So when you work with PowerShell, by default, our policy is set to remote sign, and what that simply means is local scripts will run fine, but for any other remote script it has to be digitally signed to be able to verify that it'll work properly. Now there's actually four levels of security that you can set this execution policy for. You can set it to restricted, and restricted means nothing runs on the system, it'll prevent all scripts that you've downloaded, and even ones that you've created from running. We have one that is all signed. It basically means all the scripts, whether they're locally created or remotely downloaded, we have to have them digitally signed and encrypted.
We have remote sign, which is the policy you're seeing here, and then you have one called unrestricted. Now folks, if you ever run unrestricted as your execution policy in a production environment, I'm going to come and take your PowerShell card away. This is not something you want to do in a production environment, but unrestricted is great for testing, especially if you're creating scripts that you're going to be distributing out to the world, you might want to just remove unrestricted as you test and develop your script, but if you turn on unrestricted in a production environment just for a test, that's OK, you better turn it back on, otherwise you could open yourself up to some just really bad things inside of your environment.
So once again, working with your execution policy, if you run into those errors that you're going to see, and say hey, this script won't run, or something won't run properly, the error message will actually tell you that it's execution policy, and to set it, it's just simply set execution policy, and you simply give it one of the parameter names, whether it's restricted, all signed, remote sign, or unrestricted.
Matt then dives into PowerShell's functions and What If statements, working with output, and coding in the Integrated Scripting Environment (ISE). The course wraps up with some tips on using PowerShell for both on-premises and cloud deployments involving Office 365 and Azure.
- Reading the language
- Discovering cmdlets and aliases
- Using PowerShell functions
- Working with output
- Finding and installing modules
- Using PowerShell with Office 365 and Azure