Superstar Dmitry Sotnikov has done the world a great service today by documenting how to get PowerShell running on WS08 Server Core HERE.  Just to be clear, this is  not a MSFT supported configuration.  That does NOT mean that we think it won't work.  What it means is that if it doesn't, you have to leverage the community to help you figure it out instead of Microsoft support. [Insert your favorite snarky remark here]  :-)

As admins, it is just a simple fact of life that we have to color outside the lines to get our jobs done.   Yes - it would be best if we could leverage standard configurations and officially supported components but most days the criteria is "if it works, it works". 

Just to be clear - there will be certain .NET classes that do not have the necessary WIN32 APIs to support them.   I think you will be hard pressed to find any or more importantly, NEED any.  I went out of my way to find one to see what the experience was and you just get a nice error message saying that it could not find the DLL.  PowerShell continues to run without a glitch.

You should give it a try and then share your experiences so that we all get this configuration better in focus. 

• How did the install go for you?
• What things are you using it for?
• Any problems?

What a great way to start the day!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

The TIOBE Programming Community Index provides a monthy rating of the popularity of programming languages.  This month's headline was:

PowerShell on its way to the top 20

I'm not sure how they rate popularity or how they came up with that title (given that right now we are at 36) but I liked the headline!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Doug Finke has just posted a blog entry HERE with an awesome 7 minute video demo HERE.  I HIGHLY recommend this as a great use of 7 minutes of your life (or as Doug points out, you can type Ctrl-Shift-G to speed it up and it will be a great use of 4-5 minutes of your life :-) )

In the demo, he starts out writing and running some C# code. He then takes advantage of the new PowerShell V2 feature Add-Type to run this code from a PowerShell script.  Then, step by step, he transform the original C# code into PowerShell and ends up with a single line of PowerShell.  Each step produces a running PowerShell script and it nicely illustrates what I love about PowerShell - how the language carves away all the syntatics crap and allows you to focus your thoughts and energies on WHAT you want to do.

 Very nicely done Doug.  What a great way to start the day.

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

I just got through reading Scott Hanselman's blog entry:  TypeConverters: There's not enough TypeDescripter.GetConverter in which he referenced  Jesse Liberty's blog entry: Did You Know That... Type Converters allow you to use property attributes in Complex Types and decided to pile on.

Developers - you should stop what you are doing and get TypeConverters in focus.  Here is the big picture way to think about it:  As developers, our mission in life is to make the lives of others easier by providing them the functions they need in they way they need them.  TypeConverters play a huge role in the mission.

TypeConverters are one of the many the unsung heroes behind the magic of PowerShell.  Think about the code you write, think about the code your customers write.  An amazing amount of time and effort goes into coding around impendence mismatches:

• That API gave me an A but this API needs a B.
• I can easily get a string but I need an object of type A.

This impendence mismatches cause conceptual and code friction.  Think of TypeConverters as the grease in the object model that make things work together easily.  As a developer, you should take a look at the code you/your customers have to write and consider where a typeconverter could make things easier. 

Traditional languages have the disadvantage of requiring the developer to know about and use the TypeConverter.  The magic of PowerShell is that we do all of that for the user.  We know the TYPE of the data that the user has and we know what TYPE is needed.  We'll go through lots of hoops to make things "just work" including calling constructors, Parse() methods and TypeConverters.  Abhishek Agrawal wrote a good blog Extending PowerShell with Customer TypeConverters where he describes how to write a TypeConverter and then how to register it with PowerShell so we can use it in our type coercion engine.

Users:  I'd love to hear from you about any examples where you think we should have type convertors and don't.

Cheers!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

PowerShell V2 introduces a new capability which allows you to remotely manage machines in your organization. I will give a basic overview of PowerShell remoting here and follow it up with some adavanced topics later. Are you ready for the fun..

A remote interaction involves 2 endpoints ? Client and a Server. The same computer or system can act both as a client and as a server.

Configuration

To enable an endpoint for PowerShell remoting you need to do the following:

Step 1: Install PowerShell CTP2 of PowerShell V2

Step2: Install CTP of WinRM

Step 3: Configure WinRM for PowerShell remoting. This can be done from a PowerShell Console using the following steps

(a)    Open PowerShell console in elevated prompt

(b)   Run $pshome\configure-wsman.ps1 script.

The above script will prepare your machine for remoting. This script will enable an endpoint both to act as a client and as well as a server.

PowerShell depends on WinRM for transport of data between endpoints. WinRM implements WS-Management a SOAP-based protocol for the management of servers etc. The good thing about this protocol is it is based on HTTP. So all the packets are going on Port 80 (by default) and you don?t need to open any other port for PowerShell remoting.

Using the Power

The beauty of PowerShell remoting is that all the cmdlets/scripts you have from V1 work as is everywhere (as long as PowerShell is installed on the server). So you develop your cmdlet/scripts once and you can remotely execute them with PowerShell as is without making any changes. The only dependency being the cmdlet/script you want to execute should be accessible on the remote box.

Let me show you some examples:

PS C:\> #my current machine

PS C:\> $env:computername

KRISCV-JHOOM

PS C:\> icm kriscv-lh { $env:computername }

KRISCV-LH

PS C:\>

The above example gives a glimpse of powershell remoting. Here I ran ?$env:computername? locally and then on a remote machine from my local machine. I showed a new command ?icm? here. ?icm? is an alias for invoke-command cmdlet. This cmdlet takes the following pattern:

Invoke-command <ExecutionContext>  { <script block to run in the context>}

In my above ?kriscv-lh? is the execution context. In this case it is a destination computer name.  So, essentially I have asked invoke-command to run the script ?{$env:computername}? on the remote machine. This is the cmdlet you should use for remoting in CTP2 of Powershell V2. This cmdlet internally creates a connection with the machine ?kriscv-lh?, runs the command on the machine, gets the output from the remote machine to the local machine, displays the output and then closes the connection.

You can pretty much do anything on the remote machine as you would on the local machine. Administrator of the remote machine however has the complete control of restricting you.

The following example shows you a way of finding free disk space on the remote machine:

PS C:\> $env:computername

KRISCV-JHOOM

PS C:\> icm kriscv-lh {gwmi win32_logicaldisk | select deviceid,freespace}

deviceid                 freespace                ComputerName             RunspaceId

--------                          ---------                ------------                           ----------

A:                                                               kriscv-lh                         8ce689c2-87a2-4e38-83...

C:                       44054937600                 kriscv-lh                          8ce689c2-87a2-4e38-83...

D:                                                              kriscv-lh                          8ce689c2-87a2-4e38-83...

Estentially whatever you have learned with V1 of PowerShell can be used with PowerShell remoting.  Lets convert the above example to show the freespace in GB instead of bytes:

PS C:\> icm kriscv-lh {gwmi win32_logicaldisk | select deviceid,freespace} | select deviceid,@{Name=

"freespace(GB)";Expression={$_.freespace/1gb}},computername

deviceid                                             freespace(GB)           ComputerName

--------                                                     -------------                 ------------

A:                                                                               0               kriscv-lh

C:                                                   41.0060882568359              kriscv-lh

D:                                                                               0               kriscv-lh

Notice what I have done here. The command in bold above is run on the remote machine kriscv-lh and the rest of the pipeline is run on the local box ie.,?select-object? cmdlet is run on the local machine. PowerShell remoting ensures objects are written onto the pipeline and hence you can leverage the complete power of PowerShell by working directly with an object.

You can apply the same concept to multiple machines. The following examples gets the free disk space from multiple machines:

PS C:\> icm kriscv-lh,kriscv-jhoom {gwmi win32_logicaldisk | select deviceid,freespace} | select dev

iceid,@{Name="freespace(GB)";Expression={$_.freespace/1gb}},computername

deviceid                                             freespace(GB)       ComputerName

--------                                                      -------------                  ------------

C:                                                182.064617156982       kriscv-jhoom

D:                                                136.152328491211      kriscv-jhoom

E:                                                7.60776519775391       kriscv-jhoom

F:                                                1.76084136962891       kriscv-jhoom

G:                                                                           0        kriscv-jhoom

A:                                                                           0        kriscv-lh

C:                                               41.0063934326172       kriscv-lh

D:                                                                           0        kriscv-lh

Notice I am running the command on 2 machines and running select-object cmdlet on the local box to filter the data.

There are so many things I want to talk about this CTP which I will do in the coming weeks. For the time being install the CTP, try out our new features and most importantly, if possible, give us your feedback.

Have a great weekend!!

Thanks

Krishna Vutukuri[MSFT]

Windows PowerShell Development

This posting is provided ?AS IS? with no warranties.