Windows PowerShell Blog

Microsoft Script Explorer: Next Steps

2013-04-05T19:56:00Z

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

2013-03-17T22:45:00Z

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

2013-01-25T23:22:00Z

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?

2013-01-17T19:20:00Z

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

2012-12-20T02:11:22Z

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

2012-10-28T21:10:13Z

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

2012-10-04T00:12:00Z

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

2012-09-17T19:38:00Z

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

2012-09-10T17:52:52Z

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

Introduction to CIM Cmdlets

2012-08-24T22:42:26Z

PowerShell 3.0 shipping with Windows server 2012 and Windows 8 brings a new set of Cmdlets to manage any server or device that complies with CIM and WS-Man standards defined by DMTF. In this blog post we will explore these new Cmdlets and how can they help IT Pros in managing a datacenter.

The list of new Cmdlets is given in the table below:

Cmdlet	Purpose
Get-CimInstance	Gets instances of a class.
New-CimInstance	Creates a new instance of a class.
Remove-CimInstance	Removes one of more instances of a class.
Set-CimInstance	Modifies one or more instances of a class.
Get-CimAssociatedInstance	Gets all the associated instances for a particular instance.
Invoke-CimMethod	Invokes instance or static method of a class.
Get-CimClass	Gets class schema of a CIM class.
Register-CimIndicationEvent	Helps subscribe to events.
New-CimSession	Creates a CIM Session with local or a remote machine
Get-CimSession	Gets a list of CIM Sessions that have been made.
Remove-CimSession	Removes CimSessions that are there on a machine.
New-CimSessionOption	Creates a set of options that can be used while creating a CIM session.

Basic terminology

If you are already familiar with terms like WMI, CIM, WinRM and WS-Man, you can skip this section.

CIM: Common Information Model (CIM) is the DMTF standard [DSP0004] for describing the structure and behavior of managed resources such as storage, network, or software components.

WMI: Windows Management Instrumentation (WMI) is a CIM server that implements the CIM standard on Windows.

WS-Man: WS-Management (WS-Man) protocol is a SOAP-based, firewall-friendly protocol for management clients to communicate with CIM servers.

WinRM: Windows Remote Management (WinRM) is the Microsoft implementation of the WS-Man protocol on Windows.

Why new Cmdlets

With Windows Server 2012, Windows has shifted its focus to become a Cloud OS. In a datacenter running a private or public cloud – there are always set of devices and servers from different vendors. We strongly believe that the only way to reduce the cost of running datacenters is through automation built on top of standards. There is less learning and less chances of error when IT Pros are able to automate heterogeneous environment using same set of tools that they have learned for Windows.

This was not the case with previous versions of PowerShell. We had two set of Cmdlets to manage Windows and Non-Windows. WMI Cmdlets were primarily used to manage Windows and WsMan Cmdlets were targeted at non-Windows that implemented WsMan standard.

WMI Cmdlets:

- Pros: Provided better task abstraction compared to WsMan Cmdlets, output is a .NET object.

- Cons: Use of non-standard DCOM protocol. Does not work for non-Windows.

WinRM Cmdlets

- Pros: Works with Windows and non-Windows using standard protocol.

- Cons: Poor task abstraction. Output is XML , scaring most IT Pros away

We heard from you that the major obstacle in PS scripting for WMI is lack of discoverability. We also heard that WMI Cmdlets don’t provide first class PS experience. There are issues with serializing a WMI object, there is no concept of session reuse and WMI object has weird looking property names (like __Server). Last but not least, there is poor formatting for most of the commonly used WMI classes. Someone said “When I run Get-WmiObject Win32_process, I feel like standing on bridge above freeway and lot of traffic zipping in front of my eyes”.

Key goals for new CIM Cmdlets

- Rich PowerShell experience. Make CIM a first class citizen of PS, addressing usability concerns and user feedback for WMI and WsMan Cmdlets.

- Standard compliance. With so much focus on standards, our goal is to make PowerShell the best platform for managing Windows and Non-Windows. New CIM Cmdlets should be able to manage any CIM + WsMan compliant endpoint, including Windows.

- Support for down-level machines. We understand that there are more down-level servers in a datacenter than there would be Windows Server 2012 for some time to come. We want to make sure same set of Cmdlets can be used to manage down-level Windows as well.

In the subsequent sections we will talk about each of these goals in detail.

Goal 1 - Rich PowerShell experience

1. Discovery of classes and namespaces.

There is a famous joke about WMI, often attributed to Jeffrey Snover. “IT Pros love and hate WMI. They love it because there is so much they accomplish with WMI and PowerShell. They hate it because it is very difficult to discover what’s in there”

To address this, we have done key improvements in new CIM Cmdlets

Tab completion for classname and namespace parameters.
Get-CimClass Cmdlet

# Using tab completion for CIM cmdlet parameters ( Tab+Space in ISE shows a drop down)

Get-CimInstance –Namespace <Tab> #Finding top-level namespaces

# Tab completion for class names

# If namespace is not specified, shows classes from default root/cimv2 namespace

Get-CimInstance -ClassName *Bios<Tab>

Get-CimInstance –Namespace root/Microsoft/Windows/smb –ClassName <tab>

# Note: Tab completion only works for local machine.

#Using Get-CimClass for advanced class search

#All classes in root/cimv2

PS:>Get-CimClass

#Classes named like disk

PS:>Get-CimClass -ClassName *disk*

# The Cmdlet makes querying much easier (what would require scripting before)

# Get all classes starting with "Win32" that have method starting with "Term"

PS:>Get-CimClass Win32* -MethodName Term*

# Get classes starting with "Win32" that have a property named "Handle"

PS:>Get-CimClass Win32* -PropertyName Handle

# Get classes starting with "Win32" that have the "Association" qualifier

PS:>Get-CimClass Win32* -QualifierName Association

#Find classes used for events

PS:> Get-CimClass -Namespace root/Microsoft/Windows/smb -class *Smb* -QualifierName Indication

Get-CimClass and tab completion described above only works for local machine. If you specify ComputerName or CimSession parameter, tab completion would not work. In order to make tab completion more efficient, PowerShell caches the list of namespaces and classnames.

2. Getting Instances

Getting/Enumerating instance of a class is the most commonly performed operation. We wanted the new Get-CimInstance Cmdlet to have better performance and even better user experience as compared to the old Get-WmiObject cmdlet. To achieve these goals we made the following design decisions:

a. The Get-CimInstance cmdlet returns one or more instances of CimInstance. CimInstance is different from the object returned by Get-WmiObject.

b. __Properties are no longer mixed with properties of an instance.

c. Reduce memory and on-the-wire footprint by allowing retrieval of a subset of properties.

d. Allow retrieval of key properties.

e. Allow creation of in-memory instance to reduce round trips.

f. Allow retrieval of specific instances using in-memory instances or actual instances.

g. DateTime values are returned as objects of System.DateTime type. Old cmdlets treat them as strings.

# Get-CimInstance was designed to be similar to the Get-WmiObject

# WMI Cmdlet : Get-WmiObject -class Win32_Process

# WsMan Cmdlet : get-wsmaninstance wmicimv2/win32_process -Enumerate

# The default value of -Namespace is root/cimv2, and the default value of -ComputerName is local computer

PS:> Get-CimInstance -Class Win32_Process

# Filtering using WQL

PS:> Get-CimInstance -Query "SELECT * FROM Win32_Process WHERE Name Like 'power%'"

# use the -Filter parameter with -classname

PS:> Get-CimInstance -Class Win32_Process -Filter "Name Like 'power%'"

#Retrieving a subset of properties : To reduce memory and on-the-wire footprint

PS:> Get-CimInstance -Class Win32_Process -Property Name, Handle

#Only get the key properties

PS:> Get-CimInstance -Class Win32_Process -KeyOnly

########################## Looking into CimInstance #########################

PS:> $x, $y = Get-CimInstance Win32_Process

PS:> $x | gm

# The object contains the full CIM class derivation hierarchy

PS:> $x.pstypenames

# The object also has a reference to its class declaration

PS:> $x.CimClass | gm

# DateTime values are returned as strings

PS:> Get-WmiObject Win32_OperatingSystem | Select *Time*

# DateTime values are returned as System.DateTime

PS:> Get-CimInstance Win32_OperatingSystem | Select *Time*#

3. Working with associations

Working with associations was not straight forward in the old WMI cmdlets. Customers wanted a way to find out associated instances of a particular instance. To resolve this issue we came up with a cmdlet called Get-CimAssociatedInstance. The following example shows some of the important features of this cmdlet.

# Get instance of Win32_LogicalDisk class with DriveType =3 (hard drives)

PS:> $disk1, $diskn = Get-CimInstance -class Win32_LogicalDisk -Filter 'DriveType = 3'

PS:> $disk1

# Get the all instances associated with this disk

PS:> Get-CimAssociatedInstance -CimInstance $disk1

# Get instances of a specific type

PS:> Get-CimAssociatedInstance -CimInstance $disk1 -ResultClassName Win32_DiskPartition

# Finding associated instances through a specific CIM relationship

PS:> Get-CimAssociatedInstance -CimInstance $diskn -Association Win32_LogicalDiskRootDirectory

4. Working with methods

A large number of tasks in WMI are achieved by invoking methods. The new Invoke-CimMethod makes two things really easy:

a. Discovery of method and method parameters

b. Execution of methods with parameters. Using feedback from our customers: Connect bug

The following examples show how easy it is to discover and execute methods using Invoke-CimMethod:

PS:> $class = Get-CimClass Win32_Process

PS:> $class.CimClassMethods

# Get the parameters of the Create method

PS:> $class.CimClassMethods["Create"].Parameters

# Invoke the static Create method on the Win32_Process class to create an instance of the Notepad

# application. Notice that the method parameters are given in a hash table since CIM method arguments

# are unordered by definition.

PS:> Invoke-CimMethod -Class win32_process -MethodName Create -Argument @{CommandLine='notepad.exe';

CurrentDirectory = "c:\windows\system32"}

# Get the owners of the running Notepad instances

PS:> $result = Invoke-CimMethod -Query 'SELECT * FROM Win32_Process WHERE name like "notepad%"'

-MethodName GetOwner

# The result has the returned value and out parameters of the method

PS:> $result

5. CliXML serialization.

CimInstance supports full fidelity serialization and deserialization. This is an important feature for those who wish to save state of an instance or result of a cmdlet and then want to use it later. The WMI cmdlets do not support full-fidelity serialization/deserialization.

# CimInstances are serialized and deserialized with full fidelity

PS:> $x = Get-CimInstance Win32_Service

PS:> $x

PS:> $x[0].pstypenames

PS:> $x | Export-CliXml t1.xml

PS:> $y = Import-CliXml .\t1.xml

PS:> $y

PS:> $y[0].pstypenames

# The deserialized objects are identical to the ones obtained from the server

PS:> diff ($y) (Get-CimInstance win32_service )

6. Remote management

Managing remote machines with the new cmdlets is also pretty simple and straight forward. The two parameters that can be used to manage remote machines are:

a. ComputerName

b. CimSession

The following example will explain how these two parameters can be used to manage a remote machine.

PS:> $props = @{v_Key = [UInt64] 8;}

# If ComputerName parameter is used, the cmdlets create an implicit session during the execution.

PS:> $inst = New-CimInstance -ClassName TestClass -Namespace root\test -Key v_Key -Property $props

-ComputerName SecondWin8Server

# Create a session

PS:> $session = New-CimSession –ComputerName SecondWin8Server

# Use the session

PS:> $inst = New-CimInstance -ClassName TestClass -Namespace root\test -Key v_Key -Property $props

–CimSession $session

Tip: If a large number of remote operations are to be performed then session reuse is highly recommended. This can provide a significant performance gain.

7. Easy migration from WMI cmdlets

Last, but not the least, a very important aspect is to reduce learning. If you know how to use WMI cmdlets from PowerShell 2.0, you will find learning new CIM cmdlets easy. These cmdlets follow similar patterns as WMI cmdlets -including parameter names and alias. Let’s see how easy or difficult it is to move to new cmdlets

# OLD: One liner to get ComputerSystem information

PS:> Get-WmiObject Win32_ComputerSystem

# NEW:

PS:> Get-CimInstance Win32_ComputerSystem

# ClassName is position and mandatory.

# Namespace default is root/cimv2 namespace

#WMI Cmdlet – with classnames and Namespace

PS:> Get-WmiObject –ClassName Win32_Process –Namespace root/cimv2

#CIM cmdlet follows the same pattern

PS:> Get-CimInstance –ClassName Win32_Process –Namespace root/cimv2

The table below shows the list of WMI cmdlets and their CIM equivalent:

Old cmdlet	New Cmdlet
Get-WmiObject	Get-CimInstance
Get-WmiObject -list	Get-CimClass
Set-WmiInstance	Set-CimInstance
Set-WmiInstance –PutType CreateOnly	New-CimInstance
Remove-WmiObject	Remove-CimInstance
Invoke-WmiMethod	Invoke-CimMethod

Note: In old cmdlets Set-WmiInstance was used to perform update and create operations. The new cmdlets clearly define the distinction between the two operations i.e. New-CimInstance is used to create an instance and Set-CimInstance is used to update an existing instance.

You will also notice that in some places we have broken this rule – and script using WMI cmdlet can’t be simply changed to CIM cmdlet by changing the cmdlet name. e.g.

# OLD:

PS:> Invoke-WMIMethod -class Win32_Process -Name create -ArgumentList 'calc.exe'

# NEW:

PS:>Invoke-CimMethod Win32_Process -MethodName create -Arguments @{CommandLine='calc.exe'}

New Cmdlet takes a hash table or ordered dictionary as input not an Object.

The rule here is, if the WMI cmdlet experience is not ideal, we don’t want to carry it forward. It’s better to break a bad experience (like in the example given above)

Goal 2 - Standard Compliance

· CIM cmdlets are modeled on generic CIM operations

· Work over WsMan for remote management, making it possible to manage any server or device that implements WsMan and CIM standard.

· Removes the need to build custom agents and/or protocol to manage complex heterogeneous environments

· CIM cmdlets will work seamlessly with the new Open Management Infrastructure. http://blogs.technet.com/b/windowsserver/archive/2012/06/28/open-management-infrastructure.aspx

The following example shows that CimCmdlets can be used to manage a non-windows device (i.e. an Intel AMT box):

# Save credentials in an object

PS:> $cred = Get-Credential -UserName admin

# Create a session with Intel AMT machine.

PS:> $s = New-CimSession -ComputerName $serverAMT -Port 16992 -Authentication Digest -Credential $cred

# Use classname to get instances from an Intel AMT machine.

PS:> Get-CimInstance -class CIM_ComputerSystem -Namespace interop -CimSession $s

# Use resourceURI to get instances from an Intel AMT machine.

PS:> $resourceURI = “http://intel.com/wbem/wscim/1/amt-schema/1/AMT_GeneralSettings”

PS:> Get-CimInstance -ResourceUri $resourceURI -Namespace interop -CimSession $s

Goal 3 - Support for down-level OS or non-windows machines

CimCmdlets can be used to manage Windows 8, down-level windows machines and any machine that has a CIM standards compliant CIMOM. So, IT pros can now manage non-windows machines with PowerShell in the exact same fashion as they could manage a windows box.

To manage these machines, a CimSession to the machine is required. Once a CimSession is created, the machine can be managed irrespective of the operating system.

WinRM support on down-level windows machines is limited. The latest WMF-V1 release will enable the latest version of WinRM on the down-level machines; this will help our customers in making best use of these new cmdlets.

If customers do not want to install WMF-V1 or do not wish to use WinRM then they can always use DCOM protocol to achieve the same results.

# If ComputerName is specified, WinRM protocol is used

PS:> $serverwin8 = New-CimSession –ComputerName "ServerWin8"

PS:> $serverwin2k8r2 = New-CimSession –ComputerName “Serverwin2k8r2 "

# For a remote machine, if you wish to go over DCOM, you need to explicitly specify

PS:> $sOpt = New-CimSessionOption –Protocol DCOM

PS:> $sessionWin2k8r2Dcom = New-CimSession –ComputerName “Serverwin2k8r2 " –SessionOption $sOpt

# User Experience remains same irrespective of the target machine.

PS:> $instanceServerWin8 = Get-CimInstance –CimSession $ serverwin8

PS:> $instanceServerWin2k8r2 = Get-CimInstance –CimSession $ serverwin2k8r2

PS:> $instanceServerWin2k8r2DCOM = Get-CimInstance –CimSession $ sessionWin2k8r2Dcom

#Note: The results in $instanceServerWin2k8r2 and $instanceServerWin2k8r2DCOM are identical in all aspects.

# Only the protocol used to get them is different.

Our objective is to provide the best user experience to all the IT professionals. We would love to know what you think about these new cmdlets. Please give us your comments below.

Vaibhav Chugh

SDET, WMI

Osama Sajid

Program Manager, WMI