Your question as it stands does not make sense
PowerShell is not just a bunch of cmdlets
!
PowerShell is a powerful and extensible management tool - anything you can do from a Management Console, you can do from PowerShell - it's simply a matter of familiarity with the underlying APIs
Even configuration options that doesn't necessarily conform to well-known APIs can be manipulated through PowerShell, through builtin storage providers for the filesystem, the registry, the certificate store etc.
WMI
Interacting with WMI through PowerShell is almost to easy, at least looking back at my early attempts at VBScript (oh, the horrors).
The core modules in PowerShell comes with a variety of cmdlets, including Get-WMIObject
(Windows 2012 introduces the more generic CIM cmdlets
like Get-CimInstance
):
$OSbitness = (Get-WmiObject -Class Win32_OperatingSystem).OSArchitecture
Holy balls?! We just used WMI to tell us the OS architecture without invoking wmic
or writing 700 lines of wsh error handling!
COM
PowerShell can invoke and interact with COM applications. Many Microsoft applications can be accessed this way, using the New-Object
cmdlet.
See for instance this example of creating and saving a spreadsheet using Excel - pretty neat!
.NET? No problem!
Since .NET is already and integral part of PowerShell (same object model, derived type system, same runtime environment etc.), .NET extensibility is right at your fingertips using a mash of reflection and a few builtin cmdlets like New-Object
and Add-Type
. Extend away!
The Powershell runtime collection types are not for you? You want a HashSet of strings? No problem:
$myHashSet = New-Object System.Collections.Generic.Hashset[String]
Need to import existing vendor libraries to your Powershell session? No problem:
Add-Type -Path C:\Stupid\Old\App\Lib.Helper.dll
Need a managed library from the GAC? No problem:
[Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
or
Add-Type -AssemblyName System.Windows.Forms
How about some managed code on the fly? A few static functions that were easily implemented using C#
? No problem:
$typeDef = "public class HelperFuncs {public static string HelloWorld(){return "Hello World";}}"
Add-Type -TypeDefinition $typeDef
[HelperFuncs]::HelloWorld()
Native APIs?
To access the native APIs in Windows we'll have to go through a bit of .NET wrapping, or marshalling, but DllImport and PInvoke.NET makes this task trivial as well:
$MethodDefinition = @'
[DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
public static extern bool CopyFile(string lpExistingFileName, string lpNewFileName, bool bFailIfExists);
'@
$Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name 'Kernel32' -Namespace 'Win32' -PassThru
$Kernel32::CopyFile("C:\somefile.txt","C:\newLocation\somefile.txt")
Add to the above, that PowerShell is its own scripting language, building on the best of many worlds including syntax borrowed from proven languages like Perl, ksh, Tcl and of course C# and its ancestors.
It has flow control options like loops, switches, if-else and a wide variety of generic comparison operators, support for multi-value assignment and an incredibly powerful object-oriented pipeline, and a myriad of other features.
To be honest, the only real limitation to PowerShell with regards to Windows Server management is sitting 20" from the screen