-2

I'm preparing a quick presentation on the possibilities of Powershell management in Windows 2012R2, versus GUI-based administration. Now, I'm trying to pin down what administrative tasks typically performed using MMCs or similar are still not possible using Powershell cmdlets/functions.

Some examples of functionality that is at least almost completely managable using Powershell as of 2012R2 is IIS, DHCP, Active Directory. I'm well aware that there are many additional possibilities using pre-powershell tooling, WMI, COM or the .NET assemblies, but in my experience very few sysadmins feel comfortable going there, so I'm limiting the scope to the cmdlets.

9
  • This is not a good question for serverfault. This is a Q&A site, not a discussion forum. We expect questions to be mostly aimed at asking about a specific problem.
    – Zoredache
    Feb 5, 2014 at 18:05
  • I would say that asking what functionality is not included is a quite clear question? Can I phrase it in a clearer way?
    – carlpett
    Feb 5, 2014 at 18:10
  • I think a proper answer as the question currently is phrased would comprise a bookshelf or three. As PS can access the .NET API you might just as well ask 'what can't be accomplished programmatically in .NET?'
    – ErikE
    Feb 5, 2014 at 18:15
  • 3
    I still can't open vi on my FreeBSD box with PowerShell. Feb 5, 2014 at 18:17
  • 2
    I'm pretty certain that POSH is Turing-complete, so I guess the only answer is "solve the halting problem."
    – mfinni
    Feb 5, 2014 at 19:10

1 Answer 1

8

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

5
  • 2
    I think you gave him a perfect answer. Now he knows that almost everything is possible with Powershell.
    – Alex Rouge
    Feb 5, 2014 at 18:59
  • As a Linux/Bash guy, this is making me a little jealous.
    – Ladadadada
    Feb 5, 2014 at 21:31
  • @Ladadadada Mission accomplished :D Feb 5, 2014 at 21:50
  • 1
    @Ladadadada Well, you can take solace in telling yourself that PowerShell still has to manipulate Windows on the backend, and Windows is inferior to *nix, after all. Of course, saying that won't make it true, or change the fact that Windows guys finally have the superior CLI... but it might make you feel a little better. :) Feb 6, 2014 at 7:26
  • 2
    You know what I like about POSH? No "xargs" and no (or at least less) munging text in a pipeline - you're just passing objects.
    – mfinni
    Feb 7, 2014 at 2:23

Not the answer you're looking for? Browse other questions tagged .