Windows PowerShell Blog

New-Object PSObject –Property [HashTable]

2009-12-05T04:30:25Z

Let me start of by suggesting you take a few minutes and read Laerte Junior’s excellent blog 
entry Exceptional PowerShell DBA Pt1 Orphaned Users.  Laerte does a great job describing the 
scenario, the approach he took to solving it and then he included the scripts!  Really good
stuff Laerte!

When I looked at Laerte’s code, I recognized one of my least favorite PowerShell V1isms:

		$Object = New-Object PSObject                                       
               $Object | add-member Noteproperty LineNumber       $LineNumber                 
               $Object | add-member Noteproperty Date             $TodayDate              
               $Object | add-member Noteproperty ServerName       $svr            
               $Object | add-member Noteproperty DatabaseName     $Database            
               $Object | add-member Noteproperty UserName         $user.name            
               $Object | add-member Noteproperty CreateDate       $CreateDate            
               $Object | add-member Noteproperty DateLastModified $DateLastModified            
               $Object | add-member Noteproperty AsymMetricKey    $user.AsymMetricKey            
               $Object | add-member Noteproperty DefaultSchema    $user.DefaultSchema            
               $Object | add-member Noteproperty HasDBAccess      $user.HasDBAccess            
               $Object | add-member Noteproperty ID               $user.ID            
               $Object | add-member Noteproperty LoginType        $user.LoginType            
               $Object | add-member Noteproperty Login            $user.Login            
               $Object | add-member Noteproperty Orphan           ($user.Login -eq "")

Gosh that is a horrible looking thing. This is one of the things we fixed with PowerShell V2 so you take a few minutes to
learn this so you never have to do that mess again. Let’s get some help:

PS> Get-Help New-Object -Parameter Property

-Property <hashtable>
    Sets property values and invokes methods of the new object.
    Enter a hash table in which the keys are the names of properties or methods and the values are property value
    s or method arguments. New-Object creates the object and sets each property value and invokes each method in
    the order that they appear in the hash table.
    If the new object is derived from the PSObject class, and you specify a property that does not exist on the o
    bject, New-Object adds the specified property to the object as a NoteProperty. If the object is not a PSObjec
    t, the command generates a non-terminating error.
    Required?                    false
    Position?                    named
    Default value
    Accept pipeline input?       false
    Accept wildcard characters? false

Thats right – you can now specify a hashtable and we’ll set these as NoteProperties on an object. What that means is that you can now write code like this:

    $Object = New-Object PSObject -Property @{            
        LineNumber       = $LineNumber                 
        Date             = $TodayDate              
        ServerName       = $svr            
        DatabaseName     = $Database            
        UserName         = $user.name            
        CreateDate       = $CreateDate            
        DateLastModified = $DateLastModified            
        AsymMetricKey    = $user.AsymMetricKey            
        DefaultSchema    = $user.DefaultSchema            
        HasDBAccess      = $user.HasDBAccess            
        ID               = $user.ID            
        LoginType        = $user.LoginType            
        Login            = $user.Login            
        Orphan           = ($user.Login -eq "")            
    }

or if you prefer:

   $hash = @{            
        LineNumber       = $LineNumber                 
        Date             = $TodayDate              
        ServerName       = $svr            
        DatabaseName     = $Database            
        UserName         = $user.name            
        CreateDate       = $CreateDate            
        DateLastModified = $DateLastModified            
        AsymMetricKey    = $user.AsymMetricKey            
        DefaultSchema    = $user.DefaultSchema            
        HasDBAccess      = $user.HasDBAccess            
        ID               = $user.ID            
        LoginType        = $user.LoginType            
        Login            = $user.Login            
        Orphan           = ($user.Login -eq "")            
    }                           
                                    
    $Object = New-Object PSObject -Property $hash

This is SO much better than V1 – be sure to use it and to tell all your friends about it as well!

Experiment! Enjoy! Engage!

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

You Don’t Have to Be An Administrator to Run Remote PowerShell Commands

2009-11-23T00:52:02Z

I was just read blog entry which complained about having to have administrative access to execute PowerShell commands against a remote server. This is not the case.

We are “secure by default” which means that if you want to do something that exposes a security risk to your machines, you have to make a conscious decision to do so. We are secure by default so that you can feel confident in putting PowerShell on all your machines. Your risks are a function of the decisions you make after you install PowerShell and we’ll educate you about the risks and benefits of those decisions. (Run “Get-Help about_Execution_Policies” to see a great example of that.)

That is why remoting is turned off by default and you have to run Enable-PSRemoting to turn it on.

When you do this, we create the default PSSessionConfiguration called Microsoft.PowerShell with a SDDL which only allows people with administrative rights to execute remote commands on that machine. You can see that by the following command:

PS> Get-PSSessionConfiguration |fl *

Name                   : microsoft.powershell
Filename               : %windir%\system32\pwrshplugin.dll
SDKVersion             : 1
XmlRenderingType       : text
lang                   : en-US
PSVersion              : 2.0
ResourceUri            : http://schemas.microsoft.com/powershell/microsoft.powershell
SupportsOptions        : true
Capability             : {Shell}
xmlns                  : http://schemas.microsoft.com/wbem/wsman/1/config/PluginConfiguration
Uri                    : http://schemas.microsoft.com/powershell/Microsoft.PowerShell
ExactMatch             : false
SecurityDescriptorSddl : O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
Permission             : BUILTIN\Administrators AccessAllowed

If you decide you want to allow others, what you do is run the command:

PS> Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

Confirm
Are you sure you want to perform this action?
Performing operation "Set-PSSessionConfiguration" on Target "Name: Microsoft.PowerShell".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Notice that this action could have a serious impact on your system so we ask you to confirm that you really want to do this.(In general we assume you know what you are doing and only bring up these nag-messages when we think it is super important that you not sleep walk through this one. You can always add a –FORCE switch to bypass this message.) This brings up the following dialog box which allows you to give others the ability to run commands on that machine:

Experiment! Enjoy! Engage!

Windows PowerShell and the Windows Management Framework

2009-11-20T00:43:16Z

There’s been a lot of great excitement that’s accompanied the release of PowerShell V2 and Windows Remote Management (WinRM) – also known as the Windows Management Framework. We’ve also heard the occasional question on whether it’s possible to install them independently.

When we’ve heard this concern, it is usually focused on security. To be clear, Windows Remote Management (WinRM) has been part of Windows since Vista and Server 2008. It does not listen to network connections by default, and must be explicitly activated. Both have advanced greatly during the release of Windows 7 – most notably by working together to support a rich PowerShell-based remoting experience.

The Windows Management Framework download (PowerShell + WinRM) simply updates the binaries on non-Win7 machines to bring them up to the same version already included in Windows 7 and Windows Server 2008 R2.

Investigating this concern further, it usually comes down to concern about increased network attack surface: automatically opening a network port to accept incoming connections. Installing the Windows Management Framework does not do this automatically. “Secure by Default” is the mantra of both our team, and Microsoft as a whole. Enabling PowerShell Remoting is an explicit step that must be run from an elevated prompt. The command fully informs you of the security implications when you do so:

[C:\Windows\system32]
PS:101 > Enable-PsRemoting

WinRM Quick Configuration

Running command "Set-WSManQuickConfig" to enable this machine for remote management through WinRM service.

This includes:
    1. Starting or restarting (if already started) the WinRM service
    2. Setting the WinRM service type to auto start
    3. Creating a listener to accept requests on any IP address
    4. Enabling firewall exception for WS-Management traffic (for http only).

Do you want to continue?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):

While we (and Windows Security, and external security consultants that we hired for analysis and penetration testing) also believe in the security of our remoting protocol and the attack surface that it exposes, we focused from the start on letting you make that decision independently.

Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation

PDC09 SVR12 and SVR13 Session Demos

2009-11-19T02:08:00Z

Attached are the demos from the PDC sessions SVR12 and SVR 13 today. Here are the steps you need to do before you can run them

1. Unzip the files and run setup\setup.ps1. This will configure user accounts and initialize some files required

2. Change computers.dat in service\roles\. Set it to the computers that you want to connect to

3. Edit Impersonation\Get-DelegationCredential.ps1 under each folder - Inventory, Service and Employee (Please Note: This script is intended only for demo purposes and is not recommended to be copied for production

4. Set the paths in app.xaml.cs in each of the visual studio projects - EasyGUI and RemoteUI

Once the above are done then you are all set. Play around with them and have fun !!!

Cheers

Nana

---

Narayanan Lakshmanan [MSFT]
Developer
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

I Can Do That With 1 Line of PowerShell: Installed Software

2009-11-15T17:42:37Z

Ying Li has a cool PowerShell Script to list installed Software on a local computer HERE.

When I looked at it and thought to myself, I can do that with 1 line (if I cheat a little). Here it is:

PS> gp HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |Select DisplayName, DisplayVersion, Publisher, InstallDate, HelpLink, UninstallString |ogv

Here is what you get for that 1 line of code:

I cheated by using OGV (Out-GridView). Ying used Excel and the output is nicer. But when you only want to spend a single line… :-)

Experiment! Enjoy! Engage!

SRV312 TechEd Slides

2009-11-12T13:57:00Z

I just gave the talk, "”Server Management Improvements and Solutions for Windows Server 2008 R2”. It went over rather well. Attached are the slides. I will try to get you the demos but that will be difficult and will take some time.

Enjoy!

Windows Server 2008 R2 Rocks!

2009-11-09T16:05:15Z

One of the things I like to say is that, “Microsoft is incapable of sustained error”. By that I mean that Microsoft is an intensely self-conscious culture, fearless about confronting shortcomings and constantly looking for ways to do things better. We beat ourselves up pretty brutally about the shortcomings of Vista and committed ourselves to doing better going forward. This is one of the reasons why Windows Server 2008 was such a good release. We didn’t stop there, we raised the bar for Windows 7 and Windows Server 2008 R2.

Part of that was the product itself. Anyone that uses either of these products can see that immediately. These are solid, high quality products. We also raised the bar and teaching people about the release.

This morning, MSDN’s Channel9 opened up a new site for learning about WS08/R2 HERE. This site has lessons and short training videos for the following WS08/R2 topics:

Designed for Performance
Designed for Efficiency
Server Core .NET Application Server
The Extensible Web Platform
Extreme Web Services
The Extensible File Classification Infrastructure
Windows PowerShell is Powerful Automation!

VHD and Hyper-V APIs Enable Creative New Solutions

Much of this content if focused on developers but admin/It Pro scripters will find PowerShell section useful and appropriate.

Experiment! Enjoy! Engage!

PowerPack Challenge

2009-11-05T16:46:00Z

Quest Software’s PowerPack Challenge’09 is on... calling all script warriors to show their skills.

See the details here - http://powergui.org/powerpackchallenge.jspa

Happy Scritping

Osama Sajid, Program Manager

Why is Get-ChildItem so Slow?

2009-11-04T20:52:55Z

We get this question fairly frequently when it comes to slow network connections.

The performance of directory listings (especially on a laggy network) are limited by the .NET APIs we call to retrieve the directory information. There are two limitations to the current set of APIs:

Forced Retrieval of Attributes

When we do a directory listing, we show the standard attributes of the file or directory: Mode, LastWriteTime, Length, and Name. The core Windows API is highly optimized for this basic scenario, and returns these attributes by default along with the rest of the file information. However, the .NET Framework doesn’t take advantage of this data, and instead goes back to the network location to ask for all of the file attributes. This chatty behaviour adds a handful of network round trips for each file or directory, making the directory listing many times slower: hundreds or thousands of times slower in many cases. The Framework team addressed this as part of .NET 4.0, and you’ll see the benefits of this new feature as soon as we are able to adopt it.

In version two, even without the benefit of the new .NET API, though, you’ll see a huge improvement in wildcarded directory listings (both local and remote.)

As a background, PowerShell wildcards are different than straight cmd.exe wildcards. For example, PowerShell wildcards do not match the 8.3 short file name, while the native filesystem filtering (exposed by cmd.exe wildcards) do. PowerShell’s wildcards support character ranges, while the native file system filtering support does not. Because of this, PowerShell wildcard processing happens AFTER we’ve retrieved all of the files.

This comes at a cost, however. Native file system filtering (as exposed by the –Filter parameter) is MUCH faster, as its processing is wired into the Windows file system.

In version two, we did a bunch of work to resolve this strain. When you provide a PowerShell wildcard, we convert as much of it as possible to a native filesystem filter, and then apply our wildcarding logic to the much smaller set of results. You’ve probably noticed this most in tab completion, but it makes huge improvements in regular wildcarded directory listings. Especially remote ones. Since the native filtering is processed by the remote file system, we don’t need to suffer the performance penalty of accessing attributes of files that you ultimately don’t care about anyways. In version one, you can work around the issue by specifying the –Filter parameter directly. If this still doesn’t provide the speed you need, you can call “cmd.exe /c dir”.

Lack of Enumeration API

This issue raises itself for directory listings that contain many files. The DirectoryInfo.GetFiles() method returns an array. When creating that result list, the .NET Framework does many re-allocations (and copies) of that array, causing an exponential performance degradation:

This, too, has been resolved in the .NET 4.0 updates, by offering an API that lets you enumerate through a directory result, rather than retrieve them all at once. If you are running into these limitations, you can again apply a wildcarding approach. If this still doesn’t provide the speed you need, you can call “cmd.exe /c <command>”.

Why Don’t We Fix It?

Since cmd.exe isn’t impacted by these issues, why don’t we just do the same thing and call into the core Windows APIs directly? The reason is twofold:

A core tenet of PowerShell is providing access to the REAL underlying .NET objects. If we implemented the semantics ourselves, we’d have to return new types of objects – something like PSFileInfo and PSDirectoryInfo. V1 scripts (or downstream cmdlets) that expect the REAL underlying .NET objects would fail to work. While we could add a new switch (-Raw?), users would still have to change their scripts to support it. In that case, they might as well use the existing cmd /c workaround.
This issue is ultimately transient. While it’s annoying to drag out over a few years, it will ultimately come and go without users having to change their behaviour. One day, you’ll install a build and the issues will just magically be gone.

Again, thanks for your continuing feedback. That’s what ultimately helped us discover the issue and make sure the right people knew about it.

Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation

Workaround for Add-Member on plain .Net objects

2009-11-03T23:57:22Z

Introduction

While I was fixing bugs, I came across an interesting bug (https://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=382818) that seemed to have a very simple fix upon first glance. However, after doing some more research, I found out that it was actually very tricky to fix the root cause. If you do the following:

$table = @{ key1="val1"; key2="val2" }
Add-Member -in $table -MemberType NoteProperty -Name test -Value testValue

Now if you pipe $table to Get-Member you will notice that the test property is missing. No matter how many times you repeat the same Add-Member operation, $table seems to be totally unaffected. However, if you access the test property or even a nonexistent property before you use Add-Member, the command will behave correctly.

Why is this happening?

In PowerShell, we create .Net objects as System.Object as opposed to System.Management.Automation.PSObject for performance reasons. This is because every time an object is converted from System.Object to PSObject, PowerShell has to build the metadata information by reflecting on the .Net object. Doing so can introduce unnecessary overhead since not all operations require PSObjects. When you do something with it (i.e. property access), it becomes a PSObject. However, when you pass a variable ($table) bound to an Object to a cmdlet such as Add-Member, the cmdlet internally converts the bound object into a PSObject. This effectively creates a copy of the original object and anything done to the PSObject is not reflected on the input object.

How can we work around it?

We are hoping to fix the root cause in the next release. However, the workaround is actually quite simple. Since Add-Member is able to emit the modified object if the –PassThru flag is specified, all you have to do is assigned the object back to your initial variable.

$table = Add-Member -in $table NoteProperty Test "Test property" –PassThru

Tianjie (James) Wei [MSFT]
Software Design Engineer
Windows PowerShell Team

Quick, Dirty, Super-Useful Scripting

2009-10-31T19:28:00Z

Last weekend I installed the super-awesome W7 Ultimate on all the machines at home. This weekend I decided to install the XP Virtual mode download. I started to do this and noticed that it was 500MB. That is large and is going to take a long time FOR EACH PC I have. One of the reasons I got the Ultimate SKU is that it has BranchCache. This is EXACTLY what Branchcache was designed to do. One PC downloads something and puts it into a distributed cache and then when the other PCs go to download it, they get it from their peers instead of from the internet (given the way my son reacts when my downloads affects the network and his ability to kill Nazi Zombies, I’m motivated to minimize the usage of the network :-) ).

That sounds great but the Branchcache is not enabled by default so you have to set it up. I was doing this and it was a pain in the butt so I decided to experiment with a quick and dirty script and I LOVE the results so I thought I would share.

The issue is that they way you configure Branchcache is with NETSH. The problem with that is that NETSH isn’t remotable. I was going back and forth between machines trying things out. I gave myself a dopeslap and I realized what I was doing and established a remote PowerShell session to the machines. For a while I was doing Enter-PSSession which gives you an interactive session to the remote machine. That was great but I have more than one machine so I either had to switch machines or have a couple of windows open. Then I decided I would use Invoke-Command. I created a remote connection to all the machines and then collected them in a variable $s and used ICM.

PS> $s = GSN
PS> icm $s {netsh branchcache show localcache}

That worked great but it was a little clumsy to work with so I decided to write a quick-n-dirty function to make my life better.

function b { icm $s -ScriptBlock $([scriptblock]::create("netsh branchcache $args "))}

Notice that I’m not using VERB-NOUN. Why should I? I’m after FAST (minimal typing) and this is a throw away function. “B” is perfect.

Notice that I didn’t declare parameters. Why should I? I’m going quick. I need it to work but I don’t need it to be formal.

Notice that I use positional parameters and aliases? Why not?

Now what I’m able to do is:

PS> b show localcache
PS> b set service mode=DISTRIBUTED

<UPDATE>
I realized from the comments that I didn't deliver the punchline. The WHOLE point was that the command is going to run on ALL the machines! THAT's the crazy wonderful part of it.
</UPDATE>

I haven’t got Branchcache working yet but I’m am zooming and having a blast. We spend a lot of time talking about best practices and formal scripting. That is all super great and super important but there is NOTHING wrong with quick-n-dirty scripting for adhoc functions. The fact that we designed it so that you can do both with PowerShell is a source of great pride.

GOD I LOVE POWERSHELL!

Experiment! Enjoy! Engage!

Sending Automated emails with Send-MailMessage, ConvertTo-HTML, and the PowerShellPack’s TaskScheduler module

2009-10-30T19:32:59Z

On October 15th I released a large collection of scripts called the PowerShellPack. The PowerShellPack has tons of PowerShell V2 scripts that can be used to do all sorts of fun and practical things. Today, we’ll show how to use a module in the PowerShell Pack to schedule sending a daily automated email with information about the installed programs on a given system.

Turning the output of a PowerShell script into an automated email is a snap in PowerShell V2, thanks to a nifty new cmdlet called Send-MailMessage. Send-MailMessage sends out emails with the credentials of the current user (or an arbitrary user) and an SMTP server. Send-MailMessage can send HTML emails by using the –BodyAsHtml switch, and ConvertTo-HTML can take the output of a cmdlet and turn it into an HTML chunk. If the email needs some introduction and a signature, you can always use ConvertTo-HTML’s new –PreContent and –PostContent parameters.

Here’s a quick chunk of script that will send the email message once. Notice that instead of having a very long line with a lot of parameters, I keep the parameters to Send-MailMessage in a Hashtable and use Splatting to provide them to Send-MailMessage

            $messageParameters = @{                        
                Subject = "Installed Program report for $env:ComputerName.$env:USERDNSDOMAIN - $((Get-Date).ToShortDateString())"                        
                Body = Get-WmiObject Win32_Product |                         
                    Select-Object Name, Version, Vendor |             
                    Sort-Object Name |             
                    ConvertTo-Html |                         
                    Out-String                        
                From = "Me@MyCompany.com"                        
                To = "Me@MyCompany.com"                        
                SmtpServer = "SmtpHost"                        
            }                        
            Send-MailMessage @messageParameters -BodyAsHtml

Now that we've got that chunk of code down, let's go ahead and make sure that any problems we encounter get put into a file somewhere. I can do this by setting one of PowerShell’s magic variables $ErrorActionPreference = “Stop”, and adding a try/catch around all of my code:

        $ErrorActionPreference = "Stop"                        
        try {                        
            $messageParameters = @{                        
                Subject = "Installed Program report for $env:ComputerName.$env:USERDNSDOMAIN - $((Get-Date).ToShortDateString())"                        
                Body = Get-WmiObject Win32_Product |                         
                    Select-Object Name, Version, Vendor |             
                    Sort-Object Name |             
                    ConvertTo-Html |                         
                    Out-String                        
                From = "Me@MyCompany.com"                        
                To = "Me@MyCompany.com"                        
                SmtpServer = "SmtpHost"                        
            }                        
            Send-MailMessage @messageParameters -BodyAsHtml                        
        } catch {                        
            $_ |                         
                Out-File $env:TEMP\ProblemsSendingHotfixReport.log.txt -Append -Width 1000                        
        }

Finally, I’ll just go ahead and use the TaskScheduler module from PowerShellPack to make sure the email arrives every day. To do this, I’ll need to download the PowerShellPack to the machine I’ll be scheduling the task on. Scheduling a task with the PowerShell Pack involves a short pipeline: Ours will look something like:

New-Task |            
    Add-TaskAction -Script {            
        # Our Emailer Here            
    } |            
    Add-TaskTrigger -Daily -At "9:00 AM" |             
    Add-TaskTrigger -OnRegistration |             
    Register-ScheduledTask "DailyHotfixReport"

Piece of cake, right? In our case, we’re sending an email at 9 AM every day (and when the task is registered) with the output of a simple cmdlet, but I could also use this to run a more complex task, and I can play around with the different trigger types to send the emails whenever I’d like.

Here’s the full script:

New-Task |                        
    Add-TaskAction -Hidden -Script {                        
        $ErrorActionPreference = "Stop"                        
        try {                        
            $messageParameters = @{                        
                Subject = "Installed Program report for $env:ComputerName.$env:USERDNSDOMAIN - $((Get-Date).ToShortDateString())"                        
                Body = Get-WmiObject Win32_Product |                         
                    Select-Object Name, Version, Vendor |             
                    Sort-Object Name |             
                    ConvertTo-Html |                         
                    Out-String                        
                From = "Me@MyCompany.com"                        
                To = "Me@MyCompany.com"                        
                SmtpServer = "SmtpHost"                        
            }                        
            Send-MailMessage @messageParameters -BodyAsHtml                        
        } catch {                        
            $_ |                         
                Out-File $env:TEMP\ProblemsSendingHotfixReport.log.txt -Append -Width 1000                        
        }                        
    } |            
    Add-TaskTrigger -Daily -At "9:00 AM" |                        
    Add-TaskTrigger -OnRegistration |                         
    Register-ScheduledTask "DailyHotfixReport"

That wasn't bad, was it? It took only 24 lines of PowerShell script to create a schedule task that emails me a fairly detailed report of all of the installed programs on the machine. As you can see, PowerShell V2 makes sending automated emails a snap, and the PowerShellPack makes scheduling this or any other script on a regular basis a piece of cake.

Hope this Helps,

James Brundage [MSFT]

Windows Management Framework is here!

2009-10-27T18:25:13Z

Windows Management Framework, which includes Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0, was officially released to the world this morning. By providing a consistent management interface across the various flavors of Windows, we are making our platform that much more attractive to deploy. IT Professionals can now easily manage their Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 machines through PowerShell remoting – that’s a huge win!

You can download the packages here: http://go.microsoft.com/fwlink/?LinkID=151321

Lee Holmes [MSFT]

Tonight is the Virtual Launch Party @ PowerScripting Podcast

2009-10-22T12:14:47Z

Tonight is the night!

I was super happy when we shipped V1 of PowerShell. It started the journey. That said, V2 is the release that we really wanted to release.

Today Windows 7 is publicly available and every version has PowerShell V2 in it.

Tonight – we party!

I’ll be cracking a beer with Hal Rottenberg and Jonathan Walz (hosts of the PowerScripting Podcast) in a PowerShell V2 Virtual Launch Party tonight at 9:30 PM EDT (GMT-4).

For more details and info on how to join us go HERE. I’m looking forward to seeing you. Note, you can always watch the podcast after the fact but if you join, you can make comments and ask questions in the chat room – lots of fun.

PowerShell V2 Virtual Launch Party

2009-10-17T21:30:48Z

I’ll be joining Hal Rottenberg and Jonathan Walz (hosts of the PowerScripting Podcast) in a PowerShell V2 Virtual Launch Party this Thursday, Oct 22nd, 9:30 PM EDT (GMT-4).

For more details and info on how to join us go HERE.

Hmmm, I wonder if it is BYOB… :-)

Experiment! Enjoy! Engage!