Windows PowerShell Blog

Understanding PowerShell's Type Conversion Magic

PowerShell Team — Tue, 11 Jun 2013 19:38:40 GMT

Type Conversion in PowerShell is, without question, one of the most useful ingredients in its "Magic Sauce" of administrator effectiveness. When you run a command with a specific parameter type (I.e.: a DateTime or a TimeSpan), things seem to "just work".

For example, consider this recent question / info dump on Twitter:

#PowerShell parameters that take a timespan object interpret 10 as 10 ticks, 10:00 as 10 hours, and "10" as 10 days.
— June Blender (@juneb_get_help) June 6, 2013

But how?

Here are the steps that PowerShell takes on your behalf to convert input to a given type - such as TimeSpan. As with many things, there is no magic - just a lot of hard work.

Direct assignment. If your input is directly assignable, simply cast your input to that type.
Language-based conversion. These language-based conversions are done when the target type is void, Boolean, String, Array, Hashtable, PSReference (i.e.: [ref]), XmlDocument (i.e.: [xml]). Delegate (to support ScriptBlock to Delegate conversions), and Enum.
Parse conversion. If the target type defines a Parse() method that takes that input, use that.
Static Create conversion. If the target type defines a static ::Create() method that takes that input, use that.
Constructor conversion. If the target type defines a constructor that takes your input, use that.
Cast conversion. If the target type defines a implicit or explicit cast operator from the source type, use that. If the source type defines an implicit or explicit cast operator to the target type, use that.
IConvertible conversion. If the source type defines an IConvertible implementation that knows how to convert to the target type, use that.
IDictionary conversion. If the source type is an IDictionary (i.e.: Hashtable), try to create an instance of the destination type using its default constructor, and then use the names and values in the IDictionary to set properties on the source object.
PSObject property conversion. If the source type is a PSObject, try to create an instance of the destination type using its default constructor, and then use the property names and values in the PSObject to set properties on the source object. . If a name maps to a method instead of a property, invoke that method with the value as its argument.
TypeConverter conversion. If there is a registered TypeConverter or PSTypeConverter that can handle the conversion, do that. You can register a TypeConverter through a types.ps1xml file (see: $pshome\Types.ps1xml), or through Update-TypeData.

Now, see if you can figure out what these do, and why:

[TimeSpan] 10
[TimeSpan] "10"
[TimeSpan] "0:10"

Hope this helps!

Lee Holmes [MSFT]
Windows PowerShell Development

Microsoft Script Explorer: Next Steps

PowerShell Team — Fri, 05 Apr 2013 19:56:00 GMT

For those who are familiar with Microsoft Script Explorer for Windows PowerShell, you know that we haven't released additional updates to it since we published the release candidate (RC) in August 2012. Over the past few months, we have been talking with customers and partners and taking a hard look at the adoption rate of the RC in terms of the number of downloads and the feedback we're received to date.

One of the results of this analysis was that the adoption and usage of the pre-release versions of Script Explorer were not at the level we had hoped. Part of this stems from the fact that customers already have a number of options in the market for discovering and sharing PowerShell scripts, and most appear content to continue using these existing mechanisms. As a result, we've decided not to bring the Script Explorer project to RTM.

In the meantime, we will start winding down the Script Explorer project. This will be a gradual process to allow time for existing users to move to other tools. We'll start by removing the RC package from the Download Center this week.

For those who have already downloaded pre-release versions and are actively using Script Explorer in their environments, we will continue to operate the back-end script aggregation service used by Script Explorer for a few more months. We plan to turn off the service on June 14, 2013.

To help with migrating from Script Explorer to other solutions, we would like to highlight a few of the existing options that you might find useful for discovering and sharing PowerShell scripts:

TechNet Script Center

PowerShell Code Repository

PowerShell.com

PowerShell.org

Bing

PowerShell Plus and PowerShell Scripts by Idera

PowerGUI by Quest

PowerShell Studio by SAPIEN

Microsoft Developer Network

CodePlex

And there are lots of others. Feel free to add your favorites in the comments below.

Thanks,

The PowerShell Team

Windows PowerShell 3.0 SDK Sample Pack

PowerShell Team — Sun, 17 Mar 2013 22:45:00 GMT

We're pleased to announce the availability of the Windows PowerShell 3.0 SDK Sample Pack. For Windows PowerShell 3.0, the SDK samples work a little differently than in previous releases of Windows PowerShell. For Windows PowerShell 2.0, we released a separate standalone SDK to the Download Center at http://go.microsoft.com/fwlink/?LinkID=180421. This download contained both the reference assemblies and code samples in a single SDK package.

For Windows PowerShell 3.0, we are more closely following the format used by the Windows SDK. The reference assemblies for Windows PowerShell 3.0 are included in the Windows 8 SDK which is available at http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx.

Similar to the Windows SDK, the code samples are available from the Dev Center on MSDN at http://code.msdn.microsoft.com/. You can download individual samples from the Dev Center at http://code.msdn.microsoft.com/site/search?f%5B0%5D.Type=User&f%5B0%5D.Value=PowerShell%20Team.
Alternatively, you can download the Windows PowerShell 3.0 SDK Sample Pack which includes all the samples at http://code.msdn.microsoft.com/Windows-PowerShell-30-SDK-9a34641d.

Here are the links to the Windows PowerShell 3.0 SDK Sample Pack.

Windows PowerShell 3.0 Sample Pack: http://code.msdn.microsoft.com/Windows-PowerShell-30-SDK-9a34641d

Individual Samples

AccessDB Provider Sample 01

AccessDB Provider Sample 02

AccessDB Provider Sample 03

AccessDB Provider Sample 04

AccessDB Provider Sample 05

AccessDB Provider Sample 06

Activity Controller Extensibility Sample

Activity Generator Sample

Event Notification Sample

Event Registration Sample

Get-Process Sample 01

Get-Process Sample 02

Get-Process Sample 03

Get-Process Sample 04

Get-Process Sample 05

Job Source Adapter Sample

PowerShell Sample 01

PowerShell Sample 02

Remote Runspace Pool Sample 01

Remote Runspace Sample 01

Remoting Disconnect Reconnect Sample 01

Script Line Profiler Sample

Select-Object Sample 01

Select-String Sample

Serialization Sample 01

Serialization Sample 02

Serialization Sample 03

Simple Workflow Extensibility Sample

SQL Store Extensibility Sample

Stop-Process Sample 01

Stop-Process Sample 02

Stop-Process Sample 03

Stop-Process Sample 04

Supports Paging 01 Sample

Template Provider Sample 01

Transacted Comment Sample

Enjoy!

Dan Harman

Senior Program Manager

Windows PowerShell

First German PowerShell Community Conference

PowerShell Team — Fri, 25 Jan 2013 23:22:00 GMT

We are delighted to broadcast that the community will hold the first German PowerShell Community Conference on April 10 and 11, 2013 in Oberhausen, Germany. As shown by the “sold out” PowerShell Summit for North America, there is a real need for PowerShell focused conferences that offer the attendees the opportunity to dig deep into PowerShell internals and experiences.

Agenda:
http://www.powershell.de/powershell/konferenz/Zeitplan.aspx

Press release:
“In the setting of the Museum for Industrial and Social History in Oberhausen, Germany, the first German PowerShell Community Conference will take place April 10 and 11, 2013. ‘PowerShell quickly becomes a core competence for IT people in administration and development’, Conference Co-Initiator Dr. Tobias Weltner said. ‘In a fantastic atmosphere, you get quality information and a chance to network’. Leading experts like Dr. Holger Schwichtenberg (MVP .NET Framework), Peter Monadjemi and Dr. Tobias Weltner (MVP PowerShell) present topics from the field and development and are available for questions and discussions. A separate pre-conference prep course is available for those who did not yet have the time to dive into PowerShell that much. Information and booking is available at www.powershell.de/konferenz. Please note that this is a German-speaking event.”

The Windows PowerShell Team

Updatable Help speaks only English! What’s up with that?

PowerShell Team — Thu, 17 Jan 2013 19:20:00 GMT

Our customers have certainly not been shy about their interest in multiple languages of Windows PowerShell Updatable Help, and we're grateful to hear how much they would value localized Help. Our challenge is this: Updatable Help is a new feature for this release of Windows PowerShell, and we have so very many new cmdlets and modules for Windows PowerShell 3.0 (over 2,300 new cmdlets in 95 modules). It takes time to translate the content once it's available in English, and we can't translate all of it. There's just too much new content. One of the Windows PowerShell Core modules just by itself contains over 87,000 words, meaning it's roughly the same size as Jane Austen's Persuasion, or J.K. Rowling's Harry Potter and the Chamber of Secrets. That's one module. We must make judicious choices about which modules get localized, and which are the most sought-after languages.

To determine which modules most urgently require translated Help, we're looking primarily at the number of page views of the cmdlet Help topics in the TechNet Library. Although we don't yet have the full picture at just five months after General Availability, this is giving us a good idea of which of the new modules are most read by our customers. Here's a look at the current page view count for the top three non-Core modules, for example:

Module Name	Page View Count
Hyper-V	114701
Storage	48653
PrintManagement	23915

We're also viewing suggestions filed on the Microsoft Connect feedback website for Windows PowerShell. Some of our customers are filing suggestion bugs for getting the Updatable Help translated into languages that they'd like. We welcome and are reviewing these suggestions, too; but again, we will not be able to localize all modules of Updatable Help at this time. Additionally, it's unlikely that there will be support for languages beyond those in which Windows Server 2012 was shipped. The languages in which the first-localized modules would most likely be available, within three to six months from now, are the following four:

Chinese (Traditional)
French
German
Japanese

While other languages might be supported, these are the most likely languages, based on known consumption of Windows Server (and other server and management software from Microsoft, such as the System Center suite, or SQL Server) in non-English languages. We are still open to considering additional language support for Windows PowerShell. Furthermore, we continuously update the localized content, potentially adding new languages, and new topics in previously-available languages.

Please do continue to give us your feedback about languages that you'd like to see, and the updatable Help that's most valuable to you. And vote with your browsing, by viewing the cmdlet reference topics in your preferred language.

Thanks for your patience, while we work to get our international customers the module Help that they need the most.

The Windows PowerShell Team

Windows Management Framework 3.0 Compatibility Update

PowerShell Team — Thu, 20 Dec 2012 02:11:22 GMT

Windows Management Framework (WMF) 3.0, (currently distributed as KB2506146 for Windows Server 2008 SP2 and KB2506143, for Windows 7 SP1 and Windows Server 2008 R2 SP1) has been temporarily removed from Windows Update to protect from accidental installations on unsupported systems. Those who want to install WMF 3.0 to take advantage of all the great features this update provides can do so by installing the update from the Microsoft Download Center, after reading the known compatibility issues detailed below.

Background:

Windows Management Framework (WMF 3.0) was released to the Download Center on September 17, 2012. On December 11, 2012,this package was released through Windows Update. Although it was released as an optional update, many customers chose to deploy the package automatically. Because there are compatibility issues between some released server applications and WMF 3.0, we have temporarily removed WMF 3.0 from Windows Update. This should prevent customers from inadvertently installing the package on unsupported systems.

Known Compatibility Issues:

Windows Management Framework 3.0 (WMF 3.0) is not currently compatible with the following applications.

- System Center 2012 Configuration Manager

http://support.microsoft.com/kb/2796086 (Configuration Manager Management Points collocated with clients fail after installing Windows Management Framework 3.0 and running Client Health Evaluation)

- System Center Virtual Machine Manager

http://support.microsoft.com/kb/2795043 (Managing Hyper-V hosts using Virtual Machine Manager fails with Error: 0x8033803b after installing WMF 3.0)

- Microsoft Exchange Server 2007 and Microsoft Exchange Server 2010

http://blogs.technet.com/b/exchange/archive/2012/12/14/windows-management-framework-3-0-on-exchange-2007-and-exchange-2010.aspx (Windows Management Framework 3.0 on Exchange 2007 and Exchange 2010)

- Microsoft SharePoint 2010

http://connect.microsoft.com/PowerShell/feedback/details/746908/powershell-3-0-and-sharepoint-2010 (Windows PowerShell 3.0 and SharePoint 2010)

- Windows Small Business Server 2008 and Windows Small Business Server 2011

http://blogs.technet.com/b/sbs/archive/2012/12/15/windows-management-framework-3-0-applicability-on-windows-small-business-server-2008-2011-standard.aspx (Windows Management Framework 3.0 applicability on Windows Small Business Server 2008/2011 Standard)

Systems that are running the above server applications should not run Windows Management Framework 3.0 at this time. WMF 3.0 is otherwise supported on Windows 7 SP1, Windows Server 2008 R2 SP1, and Windows Server 2008 SP2.

WMI cheat sheet for PS users

PowerShell Team — Sun, 28 Oct 2012 21:10:13 GMT

Hi,

We got multiple requests to publish the cheat sheet for CIM Cmdlets that was distributed in Tech Ed NA this year. Responding to popular demand, this document is attached as PDF . This is a great resource put together by WMI team for people who want to get started with CIM cmdlets.

Standard disclaimer :-). Cheat sheet is just for a quick start to get people started - real documentation is here http://technet.microsoft.com/en-us/library/jj553783.aspx.

Thanks

Osama Sajid

Program Manager

Joining Multiple Tables, Grouping and Evaluating Totals

PowerShell Team — Thu, 04 Oct 2012 00:12:00 GMT

Joining Multiple Tables, Grouping And Evaluating Totals

This is a continuation to the Join-Object blog post considering multiple joins and SQL style grouping and total evaluation.

Problem:

In the Join-Object blog we’ve seen that relational data naturally organizes in multiple tables. Once we have those tables, we frequently want to see the information back together, so we need something like Join-Object. Sometimes we also need to group the information and evaluate totals inside the groups. For instance, what are the total sales for each customer?

How can we use Join-Object in multiple tables and group information from the tables to report totals?

Joining multiple tables:

Consider the following tables describing sales at a fruit stand:

Customers
Id	Name	Phone
1	John Smith	(206)555-8899
2	Mark Stone	(425)999-8811
3	Ruth Moore	(425)888-3355

Products
Id	Name	Price
1	Apple	10
2	Orange	12
3	Kiwi	15

Orders
Id	Date	CustomerId
1	6/6/2012 9:12:44 AM	1
2	6/7/2012 6:12:10 PM	1
3	6/5/2012 12:05:03 PM	2

OrderItems
Id	Quantity	ProductId	OrderId
1	2	3	1
2	1	2	1
3	4	5	1
4	5	1	2
5	4	2	2
6	1	1	3

As we saw in the Join-Object blog, we need this many tables to deal with the simple conceptual problem of selling fruit!

One might question the need for the OrderItems table. An order item is a line in the receipt for an order that lists a product and its quantity. Since there can be many items per order, it needs its own table as mentioned in the Join-Object blog.

As we can see from the data, we have 3 customers, 3 products, 3 orders, and 6 order items. The three first order items are for the Order with Id 1.

Good data design forces us to split the tables, but after this is done, we frequently need to see the data together.

For example, suppose I want a report with all basic receipt information, including customer name, order date, all products bought, their quantity, and price. Here is the SQL statement that produces the report:

SELECT Customer.Name, [Order].Date, OrderItem.Quantity,

Product.Name AS [Product Name], Product.Price

FROM OrderItem INNER JOIN Product ON OrderItem.ProductId = Product.id INNER JOIN

Customer INNER JOIN [Order] ON Customer.id = [Order].CustomerId ON OrderItem.OrderId = [Order].id

Here is the result:

Joining All Tables
Name	Date	Quantity	Product Name	Price
John Smith	6/6/2012 9:12:44 AM	2	Apple	10
John Smith	6/6/2012 9:12:44 AM	1	Orange	12
John Smith	6/6/2012 9:12:44 AM	4	Kiwi	5
John Smith	6/7/2012 6:12:10 PM	5	Apple	10
John Smith	6/7/2012 6:12:10 PM	4	Orange	12
Mark Stone	6/5/2012 12:00:00 AM	1	Apple	10

A little explanation of the SQL statement

The “AS [Product Name]” segment sets the column name in the output. Both product name and customer name are called “Name” in their own tables, so we need to differentiate them in the output.

The brackets around “[Order]” differentiate it from the SQL "Order" keyword.

The Inner Join shows only the items present in both tables.

All 4 tables are “inner joined” in the statement.

Putting the data in Windows PowerShell

From here on, we will use Windows PowerShell to manipulate this data, so let’s start by putting this data in PowerShell.

The following script creates four CSV files and then imports them into four variables that contain our data.

Id,Name,Phone

1,John Smith,(206)555-8899

2,Mark Stone,(425)999-8811

3,Ruth Moore,(425)888-3355

"@ > c:\temp\customers.csv

$customers=import-csv c:\temp\customers.csv

Id,Name,Price

1,Apple,10

2,Orange,12

3,Kiwi,15

"@ > c:\temp\products.csv

$products=import-csv c:\temp\products.csv

Id,Date,CustomerId

1,6/6/2012 9:12:44 AM,1

2,6/7/2012 6:12:10 PM,1

3,6/5/2012 12:05:03 PM,2

"@ > c:\temp\orders.csv

$orders=import-csv c:\temp\orders.csv

Id,Quantity,ProductId,OrderId

1,2,1,1

2,1,2,1

3,4,3,1

4,5,1,2

5,4,2,2

6,1,1,3

"@ > c:\temp\orderItems.csv

$orderItems=import-csv c:\temp\orderItems.csv

"Customers ";$customers | format-table -AutoSize

"`r`nProducts ";$products | format-table -AutoSize

"`r`nOrders ";$orders | format-table -AutoSize

"`r`nOrder Items ";$orderItems | format-table -AutoSize

Here is the output:

Customers

Id Name Phone

-- ---- -----

1 John Smith (206)555-8899

2 Mark Stone (425)999-8811

3 Ruth Moore (425)888-3355

Products

Id Name Price

-- ---- -----

1 Apple 10

2 Orange 12

3 Kiwi 15

Orders

Id Date CustomerId

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

1 6/6/2012 9:12:44 AM 1

2 6/7/2012 6:12:10 PM 1

3 6/5/2012 12:05:03 PM 2

Order Items

Id Quantity ProductId OrderId

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

1 2 1 1

2 1 2 1

3 4 3 1

4 5 1 2

5 4 2 2

6 1 1 3

The equivalent joins in PowerShell with the help of Join-Object are as follows:

# Joins the customer to his orders and places Name(from Customer),

# Date(from Order) and Id (from Order)

$customerOrders=Join-Object -Left $customers -Right $orders -LeftProperties Name -RightProperties Date,Id -Where {$args[0].Id -eq $args[1].CustomerId}

# Adds the OrderItems to the data already gathered. The output objects will

# have Name(from Customer), Date(from Order), Quantity(from OrderItem)

# and ProductId (from OrderItem).

$customerOrderItems=Join-Object -Left $customerOrders -Right $orderItems -LeftProperties Name,Date -RightProperties Quantity,ProductId -Where {$args[0].Id -eq $args[1].OrderId}

# Adds the Products to the data already gathered. The output objects will

# have Name (from Customer), Date(from Order), Quantity (from OrderItem)

# Product Name (from Product) and Price from Product

# We use a Hashtable instead of simply "Name" for Product Name because

# "Name" is already present in the output object for the customer name,

# so we need to differentiate the Product name from that.

# If you did not know the syntax for the Hashtable Expression, you will

# be interested in the fact it also works for Select-Object properties

$customerProducts=Join-Object -Left $customerOrderItems -Right $products -LeftProperties Name,Date,Quantity -RightProperties @{Name="Product Name";Expression={$_.Name}},Price -Where {$args[0].ProductId -eq $args[1].Id}

$customerProducts | format-table

Here is the output:

Name Date Quantity Product Name Price

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

John Smith 6/6/2012 9:12:44 AM 2 Apple 10

John Smith 6/6/2012 9:12:44 AM 1 Orange 12

John Smith 6/6/2012 9:12:44 AM 4 Kiwi 15

John Smith 6/7/2012 6:12:10 PM 5 Apple 10

John Smith 6/7/2012 6:12:10 PM 4 Orange 12

Mark Stone 6/5/2012 12:05:03 PM 1 Apple 10

So, the following three lines of code …

$customerOrders=Join-Object -Left $customers -Right $orders -LeftProperties Name -RightProperties Date,Id -Where {$args[0].Id -eq $args[1].CustomerId}

$customerOrderItems=Join-Object -Left $customerOrders -Right $orderItems -LeftProperties Name,Date -RightProperties Quantity,ProductId -Where {$args[0].Id -eq $args[1].OrderId}

… do the same job as the SQL statement:

SELECT Customer.Name, [Order].Date, OrderItem.Quantity,

Product.Name AS [Product Name], Product.Price

FROM OrderItem INNER JOIN Product ON OrderItem.ProductId = Product.id INNER JOIN

Customer INNER JOIN [Order] ON Customer.id = [Order].CustomerId ON OrderItem.OrderId = [Order].id

There are some advantages to the SQL statement:

· It is a single statement that is somewhat shorter than the three statements in PowerShell.

· It has a better syntax for aliasing a property in the output (“as ProductName” as opposed to “@{Name="Product Name";Expression={$_.Name}}”).

In my opinion, those are small advantages. Each one of the PowerShell join statements is easy to understand in isolation. The hashtable syntax used in the third command (to change a property name) is a bit long, but very common to PowerShell users, because it is useful for other cmdlets including Select-Object.

I considered changing Join-Object to take all the lists and Where clauses in a single cmdlet call, but the need to pair each of two lists with a Where clause (and a Join type) makes the command a bit too cryptic for my taste. I prefer three statements that are easy to understand to one that is not. Performance-wise, there is no difference, because each Join has to be considered in isolation.

Now that the data is joined, what about getting the total money spent by each customer, the total money spent in each product and the total money spent?

Total Money Spent by Each Customer

Let’s start with the whole command:

$customerProducts | Group-Object name | `

Select-Object Name,@{Name='Total';

Expression={$_.Group | ForEach-Object `

-Begin {$total=0;} `

-Process {$total+=[int]$_.Price*$_.Quantity} `

-End {$total}}} | format-table

It produces this output:

Name Sum

---- ---

John Smith 190

Mark Stone 10

The first line:

$customerProducts | Group-Object name

Produces two groups:

Count Name Group

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

5 John Smith {@{Name=John Smith; Date=6/6/2012 9:12:44 AM;...

1 Mark Stone {@{Name=Mark Stone; Date=6/5/2012 12:05:03 PM;...

In order to better see what is in each group, we run:

($customerProducts | Group-Object name)[0].Group

Which produces:

Name : John Smith

Date : 6/6/2012 9:12:44 AM

Quantity : 2

ProductName : Apple

Price : 10

Name : John Smith

Date : 6/6/2012 9:12:44 AM

Quantity : 1

ProductName : Orange

Price : 12

Name : John Smith

Date : 6/6/2012 9:12:44 AM

Quantity : 4

ProductName : Kiwi

Price : 15

Name : John Smith

Date : 6/7/2012 6:12:10 PM

Quantity : 5

ProductName : Apple

Price : 10

Name : John Smith

Date : 6/7/2012 6:12:10 PM

Quantity : 4

ProductName : Orange

Price : 12

And:

($customerProducts | Group-Object name)[1].Group

Which produces:

Name : Mark Stone

Date : 6/5/2012 12:05:03 PM

Quantity : 1

ProductName : Apple

Price : 10

So, inside the “Group” property of each object in the output of group-object is the Price and Quantity we want to multiply in order to get a total. If we wanted just the total quantity of fruit we could do:

$customerProducts | Group-Object name | `

Select-Object Name, `

@{Name='Total';Expression={($_.Group | Measure-Object Quantity -Sum).Sum}} `

| format-table

With output:

Name Total

---- -----

John Smith 16

Mark Stone 1

Name is the first column in the output. The second column is given by:

@{Name='Total'; Expression={($_.Group | Measure-Object Quantity -Sum).Sum}}

This hashtable is a syntax for select object which means a column with a Name = Total and a value which is the Expression. The Expression gets the value of the Group property and pipes to Measure-Object to sum the ‘Quantity’ property of each member of the Group. Finally the Sum property of the Measure-Object result is retrieved. That property contains the actual sum.

Since we want to get Price * Quantity and measure-object only supports plain properties we end up with the full command repeated here:

$customerProducts | Group-Object name | `

Select-Object Name,@{Name='Total';

Expression={$_.Group | ForEach-Object `

-Begin {$total=0;} `

-Process {$total+=[int]$_.Price*$_.Quantity} `

-End {$total}}} | format-table

Instead of | measure-object we have a | ForEach-Object where we use –Begin, -Process and –End to evaluate the total. This could be easily modified to calculate anything else, including averages, standard deviations, etc.

Note: The [int] cast in front of $_.Price is required because the price is a string out of our CSV file. This could be avoided by using Export-CliXml and Import-CliXml for our data, whioch would preserve the data type.

Here is the corresponding SQL statement:

SELECT Customer.Name, SUM(OrderItem.Quantity * Product.Price) AS SUM

FROM OrderItem INNER JOIN

Product ON OrderItem.ProductId = Product.id INNER JOIN

Customer INNER JOIN

[Order] ON Customer.id = [Order].CustomerId ON OrderItem.OrderId = [Order].id

GROUP BY Customer.Name

The SQL statement combines the joining, grouping and total evaluation(Price * Quantity) operations.

The Powershell statement is only doing the grouping and total evaluation, since the $customerProducts variable has the result of the joins performed in the previous section of this blog post.

The bold segments of the SQL statement are performing the grouping and the PowerShell statement.

SQL is designed specifically for this kind of data, so it provides a shorter syntax overall, but I believe the PowerShell equivalent is simple enough to understand.

Total Money Spent in Each Product

The only thing that changes from the previous section is that the property we’re passing to Group-Object is “ProductName”:

$customerProducts | Group-Object ProductName | `

Select-Object Name,@{Name='Total';

Expression={$_.Group | ForEach-Object `

-Begin {$total=0;} `

-Process {$total+=[int]$_.Price*$_.Quantity} `

-End {$total}}} | format-table

Name Sum

---- ---

Apple 80

Orange 60

Kiwi 60

The corresponding SQL is:

SELECT Product.Name, SUM(OrderItem.Quantity * Product.Price) AS Sum

FROM OrderItem INNER JOIN

Product ON OrderItem.ProductId = Product.id

GROUP BY Product.Name

Total Money Spent

Here is the command that produces this total:

$customerProducts | ForEach-Object `

-Begin {$total=0;} `

-Process {$total+=[int]$_.Price*$_.Quantity} `

-End {$total}

Here is the corresponding SQL:

SELECT SUM(OrderItem.Quantity * Product.Price) AS Sum

FROM OrderItem INNER JOIN

Product ON OrderItem.ProductId = Product.id

Lucio Silveira[MSFT]

Windows Management Framework 3.0 Available for Download

PowerShell Team — Mon, 17 Sep 2012 19:38:00 GMT

We hope that you’ve been enjoying all of the great new Windows PowerShell 3.0 features in Windows Server 2012. We wanted to make sure that everyone knows the final release of Windows Management Framework 3.0 is also available for download from the Microsoft Download Center.

Windows Management Framework 3.0 makes much of the same great management functionality from Windows Server 2012 available to earlier versions of Windows. Windows Management Framework 3.0 allows you to install Windows PowerShell 3.0 (including a new version of WMI and WinRM) on the following Operating Systems:

Windows 7 Service Pack 1 (32-bit & 64-bit)
Windows Server 2008 R2 Service Pack 1 (64-bit only, includes Server Core)
Windows Server 2008 Service Pack 2 (32-bit & 64-bit)

Note: You must uninstall any of the pre-release packages of Windows Management Framework prior to installing the final release.

Travis Jones [MSFT]
Program Manager – Windows PowerShell
Microsoft Corporation

Managing Hardware devices from PowerShell

PowerShell Team — Mon, 10 Sep 2012 17:52:52 GMT

Steve did a very cool blog post last month about managing hardware that implements standard DMTF profiles (examples: Intel AMT , Broadcom TruManage )

http://blogs.msdn.com/b/wmi/archive/2012/08/08/standards-based-hardware-management-using-powershell.aspx

He has also published a PowerShell module on TechNet script center to help IT Pros. This module has been built on top of new CIM Cmdlets.

http://gallery.technet.microsoft.com/scriptcenter/PowerShell-Out-of-Band-84009c12

Take a look, and send your feedback.

Osama Sajid

Program Manager, WMI