Search results for 'app:weblogs' matching tag 'Release/Download'

Windows PowerShell 3.0 SDK Sample Pack

Anonymous — Sun, 17 Mar 2013 05:00: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

When Windows PowerShell Met Workflow

Anonymous — Fri, 16 Mar 2012 05:00:00 GMT

Meet the new kid on the block! Windows PowerShell Workflow (PSWF) is the latest addition to the Windows PowerShell family.

First, let’s establish the context for the decision to integrate workflows into Windows PowerShell. It starts with cloud computing and Windows-based datacenters. Cloud computing provides a set of highly available, scalable computing services that leverage high volume components (servers, disks, RAM, etc.) High volume components are less reliable than their tier 1 counterparts and even those occasionally fail. The key to cloud computing is to use software to deliver a reliable service in spite of failures. Cloud computing management needs to be reliable in spite of failures. This is where workflows come in. Workflows are typically long-running scripts that are designed to survive component or network errors and reboots.

Automation is the heart of creating and running private and public clouds at scale. By automating administration tasks and operations, you decrease cost and improve repeatability, quality, auditing and logging. This allows you to increase your server-to-admin ratio, take on more business and increase the value of your employees by freeing them up to deliver higher value functions. As an example, Erin Chapple explains:

“Server Manager accomplishes this by leveraging the multi-machine management capabilities of WMI, Windows PowerShell and Windows PowerShell’s new workflow capabilities. Virtually every operation done using Server Manager can also be done via Windows PowerShell”.

While building Windows PowerShell Workflow, we took advantage of the scalability and maturity of Windows Workflow Foundation 4.0 (WF) to bring the benefits of workflows -- long running capability and reliability -- to scripters and the Windows PowerShell ecosystem.

In one sentence, Windows PowerShell Workflow is all about:

Reliably executing long-running tasks across multiple computers, devices or IT processes

Until Windows PowerShell 3.0, the approach to solving this problem has been to combine Windows PowerShell and Windows Workflow Foundation with proprietary implementations. As part of our planning process, we talked to many customers and found many cloud providers and hosters who took WF and Windows PowerShell and put them together. Hundreds of design decisions need to be made during that process so the workflows for any implementation did not work with other solutions. We wanted to deliver the definitive integration of these two technologies in a way that could be used out-of-the box or as a reusable library in a third-party solution. For example, we have designed our implementation with extension points that allow applications to host our engine in a fault tolerant, scale out configuration with detailed auditing. The goal is for the community to write workflows that work with our in-box solution and then light up without modification in third-party solutions.

In Windows 8, we introduce Windows PowerShell Workflow with two key goals:

- Minimizing the complexity of automating across a large number of cloud or datacenter computers and devices.

- Creating an ecosystem where ISVs and partners can build solutions on top of Windows PowerShell Workflow and the artifacts can be shared with the community and used in any solution.

To achieve these goals, we decided to invest in the following areas for our first PSWF release:

- Simplified workflow authoring

- Leverage your existing knowledge

- Reliable workflow execution

- Performance and Scalability

Simplified Workflow Authoring

Windows PowerShell Workflow enables IT professionals and developers to author sequences of activities that are long-running, repeatable, frequent, parallelizable, interruptible, suspendable, and/or restartable as workflows.

A workflow is a set of activities. An activity is an individual step within a workflow that performs a defined task, such as getting the list of virtual machines in a host computer.

Leverage Your Existing Knowledge

We designed PSWF with our sacred vow in mind:

We respect your investment in learning Windows PowerShell by reusing concepts over and over to make sure learning Windows PowerShell was the best thing you ever did.

This is very important to us: making the most of your time and leveraging the investment you have already made in Windows PowerShell instead of asking you to learn a whole new language for authoring workflows. We care deeply about your ROI, so instead of creating new workflow abstractions, we used and built Windows PowerShell abstractions with workflow semantics.

At the same time, we want to work within the existing Windows Workflow Foundation ecosystem. This is why you have two options for writing a Windows PowerShell workflow:

- PowerShell script-based workflow: If you know how to write PowerShell scripts, you can reuse your assets and skills and learn a few new constructs to create workflows. For instance:

workflow

inlinescript { }

foreach –parallel

parallel { }

sequence { }

- XAML: If you have used WF or have existing XAML workflows from the community, your XAML workflows will still work in the PSWF world.

We will analyze these new constructs in the upcoming workflow posts to help you get started quickly.

Reliable Workflow Execution

Windows PowerShell Workflow helps you orchestrate the reliable execution of management workflows across multiple computers that target Windows and standard supporting devices in an IT environment.

To help increase the reliability and robustness of your workflows, we provide the following workflow features:

- Checkpoint-Workflow activity

- PSPersist parameter

- $PSPersistPreference variable

- Suspend-Workflow activity

Performance and Scalability

In addition to the areas above, we also invested heavily in improving the performance and scalability of the PSWF engine. Using PSWF, you can scale out workflow execution to thousands of managed nodes. The core investments that helped make this a reality are:

- Parallel Task Execution (parallel, foreach -parallel)

- Workflow Throttling

- Connection Throttling

- Connection Pooling

- Integration with the Disconnected Sessions feature

- PSWF Extensibility API

A set of future blog posts will analyze each of the investments above in detail.

Setup and Down-Level Support

Some of the questions we received after introducing this feature set and the investments above to our awesome Windows PowerShell MVPs were: “How do I install PSWF?” and “Can I use this feature set in down-level machines?” The good news is that Windows PowerShell Workflow ships as part of Windows PowerShell 3.0, which means that it is available wherever Windows PowerShell is installed. This includes the Server Core installation option, in which Windows PowerShell is available out of the box starting in Windows 8. PSWF is even available for down-level installations of Windows Server 2008 R2, Windows Server 2008 and Windows 7 via the Windows Management Framework 3.0 (Beta Release).

To Workflow or To Script… That is the Question

This post covered some of the common questions but the top five would not be complete without the following:

When should I write a PowerShell workflow vs. a script?

This question requires deeper analysis so we will answer it fully in a separate article. However, here are the basic reasons for writing a workflow so we help you start thinking about this.

For “Reliably executing long running tasks across multiple computers, devices or IT processes” you will typically need:

- Robustness (persistence, suspension and resumption capabilities, tracked execution)

- Enhanced PowerShell assets and skills (built-in library of management tasks, built-in parameters for multi-machine management, authoring workflows as scripts, workflow management through job cmdlets or APIs)

- Scalability and Reliability (parallel execution, connection and action retry, etc.)

If you need the above, you may want to consider writing a workflow instead of a regular script. More of this in an upcoming episode of Workflow awesomeness…

Show me the Money!

I know, I know, you can’t wait to get started! J Here is one of the most basic workflows you can write:

Now… How do you find it? How do you run it? How do you get help for it? So many questions, so little time! We wanted the answers to be as simple and as consistent with your existing knowledge as possible: Workflows behave just like every other Windows PowerShell command!

- How do you find it?

Get-Command Test-Workflow

Get-Command Test-Workflow -Syntax

- What is the proper way to name a workflow?

Verb-noun, just like you name any PowerShell cmdlet! Please remember to use approved verbs.

- How do you run it?

Test-Workflow

- How do you get help for it?

Get-Help Test-Workflow

- How do I run it against other computers?

Test-Workflow –PSComputerName ManagedNode1, ManagedNode2

- Will the awesome ISE Intellisense feature work for PSWF at some point?

That’d be a smart thing to do, wouldn’t it? As Cato said, patience is the greatest of all virtues.

But wait, there is more! Stay tuned for upcoming blog posts about using the new workflow common parameters such as PSComputerName and PSCredentials (the keys of the kingdom for running workflows in multi-machine environments), and the Windows PowerShell jobs and modules infrastructure for workflow execution. This is just the beginning!

Here is a sneak peak at what is coming next. These examples use some of the concepts that we will dive into during the next few weeks.

We Want You!

Now that you know the basics, we want to hear from you!

You can send feedback directly to the Windows PowerShell Workflow team by using the Windows PowerShell Connect site at http://connect.microsoft.com/powershell. We triage Connect bugs several times a week and make a point to add comments to each of the bugs.

While you wait for our next post, here are some additional resources about Windows PowerShell 3.0 and Windows PowerShell Workflow:

Getting started with Windows PowerShell Workflow (Download WMF3 CTP2 Windows PowerShell Workflow.pdf)

PowerShell v3: Workflow is the Flagship Feature (by Don Jones – PowerShell MVP)

PowerShell Workflow, Defined (by Hal Rottenberg – PowerShell MVP)

Rocking the Windows Server 8 Administrative Experience

TechNet docs on the Workflow module

Writing a Windows PowerShell Workflow in the Visual Studio Designer

SDK/MSDN documentation

We hope you enjoy the new Windows PowerShell Workflow functionality of Windows 8. We are having lots of fun building it!

Mir Rosenberg [MSFT]

Senior Program Manager

Windows PowerShell

Windows Management Framework 3.0 Beta Available for Download

Anonymous — Thu, 01 Mar 2012 06:00:00 GMT

Yesterday we published a Beta version of the Windows Management Framework 3.0.

Windows Management Framework 3.0 Beta makes some updated management functionality available to earlier versions of Windows. Windows Management Framework 3.0 Beta can be installed on the following Operating Systems:

Windows 7 Service Pack 1 (32-bit & 64-bit)
Windows Server 2008 R2 Service Pack 1 (64-bit only)
Windows Server 2008 Service Pack 2 (32-bit & 64-bit) – NEW! Beginning with this Beta release.

Windows Management Framework 3.0 contains Windows PowerShell 3.0, WMI and WinRM. The Beta version also includes a Server Manager CIM provider. This CIM provider allows users of Server Manager in Windows Server “8” to collect and view management data from servers with Windows Management Framework 3.0 installed.

Feedback & Bugs
We welcome any feedback or bug submissions to the Windows PowerShell Connect site: http://connect.microsoft.com/PowerShell. The release notes include a list of user submitted Connect bugs that have been fixed since Windows Management Framework 3.0 Community Technology Preview #2.

Additional Information:
Release notes are available on the download page. They contain important information about changes since Windows PowerShell 2.0 and a list of known issues.

You must uninstall any other copies of Windows Management Framework 3.0 before installing Windows Management Framework 3.0 Beta.

This software is a pre-release version. Features and behavior are likely to change before the final release.

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

Windows PowerShell 2.0 on Windows Update

Anonymous — Tue, 22 Jun 2010 05:00:00 GMT

Today, we released Windows PowerShell 2.0 and WinRM 2.0 for pre-Windows 7 operating systems on Windows Update. This non-security, optional update is designed for Windows Server 2008 SP2, Windows Vista SP2, Windows Server 2003 SP2, and Windows XP SP3.

Windows PowerShell 2.0 and WinRM 2.0 are also available as part of the Windows Management Framework (WMF) Core Package on the Microsoft Download Center and Windows Server Update Services (WSUS).

The WMF Core Package available on the Microsoft Download Center and the Windows Update release contain the same binaries of the products, so you can now download them from either source. Because Windows PowerShell 2.0 is in-place upgrade to Windows PowerShell 1.0, we will no longer be offering Windows PowerShell 1.0 on Windows Update.

Windows PowerShell 2.0 appears as an option in a Windows Update scan only if the computer meets the following conditions.

The computer has at least Microsoft .NET Framework 2.0 SP1
The computer does not have a non-RTM (CTP, Beta, RCs etc.) release of Windows PowerShell. (Windows PowerShell 1.0 RTM can be installed.)

Hemant Mahawar [MSFT]
Program Manager

Detection logic for PoweShell installation

Anonymous — Thu, 25 Jun 2009 05:00:00 GMT

"How do we programmatically detect that PowerShell is installed ?" - This question has started coming up frequently as more folks (both internally and externally) have started to build applications with PowerShell support. As we approach Win7/W2K8-R2 release, which will include PowerShell 2.0 in-box, it is pertinent to have the right guidance out for PowerShell detection logic. If you're writing an installer which relies on PowerShell presence, not only do you need to detect whether PowerShell is installed, but also what version of PowerShell is installed.

To check if any version of PowerShell is installed, check for the following value in the registry:

Key Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1
Value Name: Install
Value Type: REG_DWORD
Value Data: 0x00000001 (1

To check whether version 1.0 or 2.0 of PowerShell is installed, check for the following value in the registry:

Key Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine
Value Name: PowerShellVersion
Value Type: REG_SZ
Value Data: <1.0 | 2.0>

Remember:

Depending on any other registry key(s), or version of PowerShell.exe or the location of PowerShell.exe is not guaranteed to work in the long term.
PowerShell 2.0 doesn't support side by side installations with 1.0, but 2.0 is back-wards compatible with 1.0.

Hemant Mahawar [MSFT]
Program Manager
Windows PowerShell