PowerShell is a flexible scripting tool that lets you automate and customize your admin tasks. It combines command-line speed with the power of a GUI-based tool. This ebook offers a hands-on look at how you can put PowerShell to work.
From the ebook:
Anyone who has been managing Windows systems for the last decade has no doubt heard of PowerShell (PS) and knows what the modernized shell has to offer. PS is now rounding out its fifth stable version with many more management and scripting capabilities under the hood.
From basic systems management to Active Directory (AD DS), PowerShell does it all. And it achieves this through the use of specialized cmdlets, called modules. They act as self-contained, reusable units of PS code that execute from the PowerShell environment in their own context. This means you could effectively manage Active Directory, for example, by loading the module and making any changes necessary, then simply unloading the module so that one management console session does not affect another inadvertently.
Where are modules stored?
Modules are primarily stored in a system-wide directory that is accessible for all users:
Additional directories may store modules, such as the %USERPROFILE% and %PROGRAMFILES%, since applications installed, such as MS SQL, will typically include their own set of modules for SQL database management.
Entering the following command will display the location of each directory where modules are stored:
Custom directories may also be used to stored modules by entering the command below. This will enable PS to use that location for loading modules during the session only.
$env.PSModulePath = $env.PSModulePath + “;PATH_TO_DIRECTORY”
What modules are loaded in PowerShell?
By default, the modules that are loaded with PS allow for basic management using system-related cmdlets. Specialized cmdlets for managing AD DS require individual modules to be loaded, which I’ll address in the next section.
To list what modules are currently loaded in PowerShell, enter this command: