Windows PowerShell Blog

Saving remote session to your local disk

PowerShellTeam — Tue, 29 Dec 2009 23:09:59 GMT

Read the previous post on implict remoting to learn how the Import-PSSession cmdlet makes it easier to work with remote commands by presenting them as if they were local commands. This user experience saves you the trouble of typing long Invoke-Command incantations to pass arguments to remote commands or to download remote help content.

The next great thing would be to jump straight into the implicit remoting experience without having to explicitly set up a remote session each time and having to remember how to invoke Import-PSSession... This is where Export-PSSession cmdlet comes handy - it can be used to save the remote session and the remote commands to a local disk.

Temporary implicit remoting modules

Let's recall how one can import remote commands into a local session:

PS> $s = New-PSSession -ComputerName lukasza5 -Credential REDMOND\lukasza
PS> Import-PSSession -Session $s -CommandName *-Process -Prefix Remote

ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Script     tmp_a50e3c88-46f1-4c25... {Stop-Process, Get-Process, Debug-Process, Wait-Process...}

Import-PSSession cmdlet creates a temporary module containing local functions that act as proxies for remote commands. The module is then implicitly imported into the local session by the Import-PSSession cmdlet. The module and all the temporary files are deleted whenever the user explicitly removes the module or when the remote session is closed:

PS> Remove-PSSession $s

Saving an implicit remoting module

Instead of working with temporary modules created by Import-PSSession, one can save a module in the file system. This is done one with the Export-PSSession cmdlet. Example below asks Export-PSSession cmdlet to look in the remote session $s, take all the remote commands matching "*-Process" wildcard, and save them to "MyRemoteCommands" module. The example explicitly says that it would be okay to clobber local commands that have the same name as the imported, remote commands.

PS> $s = New-PSSession -ComputerName lukasza5 -Credential REDMOND\lukasza
PS> Export-PSSession -Session $s -CommandName *-Process -OutputModule MyRemoteCommands -AllowClobber


    Directory: C:\Users\lukasza\Documents\WindowsPowerShell\Modules\MyRemoteCommands


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        2009-12-29  11:50 AM      20535 MyRemoteCommands.psm1
-a---        2009-12-29  11:50 AM         99 MyRemoteCommands.format.ps1xml
-a---        2009-12-29  11:50 AM        598 MyRemoteCommands.psd1


PS C:\> Remove-PSSession $s

You can see that Export-PSSession cmdlet saved a new module under the default user path from ${env:PSModulePath}. No remote commands have been imported into the local session yet - there is no Get-RemoteProcess command and Get-Process works against the local machine.

Importing a saved implicit remoting module

After implicit remoting module is saved, one can invoke the remote commands without having to ever again use New-PSSession, Invoke-Command, Import-PSSession or Export-PSSession. Let's see how that works:

PS> Import-Module MyRemoteCommands -Prefix Remote

In the example above, I imported the remote commands from the saved module into the local session (I used the -Prefix parameter to avoid clobbering my local commands). No connection has been made to the remote computer yet, but I can see all the remote commands in Get-Command and use tab completion when typing them at the command prompt.

Let's try to invoke one of the commands:

PS> Get-RemoteProcess -Name w*host
Creating a new session for implicit remoting of "Get-Process" command...

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    237       9    24372      35556   146     0.95   4344 wsmprovhost

The remote invocation worked. I didn't even have to create a remote session - implicit remoting took care of that when I first attempted to use a remote command from the saved module. I've been prompted for the password, but all the other connection parameters (i.e. computer name, http proxy settings) were stored in the saved module.

Thanks,

Lukasz Anforowicz [MSFT]
Windows PowerShell Developer
Microsoft Corporation

Bringing remote commands to your local session

PowerShellTeam — Tue, 29 Dec 2009 22:50:37 GMT

How can you manage multiple technologies installed on separate machines that expose their management surface through cmdlets? One approach would be to open remote desktop connection to each of those machines, another approach would be to send commands using Invoke-Command and PowerShell Remoting. But remote desktop is not a feasible solution for automation and invoking remote commands using Invoke-Command cmdlet can sometimes get burdensome - tab completion is missing, verbose incantations are needed for passing arguments to remote commands and Get-Help -Online doesn't quite work in a remote session.

That’s where IMPLICIT REMOTING comes to play – ability to import remote commands into your local session. One can even store the information about imported commands on disk for later use, details in a later post. Implicit remoting is a feature that smoothes out the user experience of invoking remote commands.

Importing remote commands into local session

Let's see how one can import a remote command into a local session. First – let’s ask Import-PSSession cmdlet to look in the remote session $s, take all the remote commands matching "*-Process" wildcard, add a "Remote" prefix to their noun, and then present them to me as if they were local commands:

PS> $s = New-PSSession -ComputerName lukasza5 -Credential REDMOND\lukasza
PS> Import-PSSession -Session $s -CommandName *-Process -Prefix Remote

ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Script     tmp_a50e3c88-46f1-4c25... {Stop-Process, Get-Process, Debug-Process, Wait-Process...}

Implicit remoting experience

The basic promise behind implicit remoting is that you can work with remote commands using local syntax. In particular - after Import-PSSession did its magic I can invoke remote commands as if they were local commands. Let's see if Get-RemoteProcess really works on a different machine than Get-Process:

PS> Get-RemoteProcess -Name w*host

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    313      10    39000      51044   162     2.18   2348 wsmprovhost


PS> Get-Process -Name w*host

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    216      11     2056       6132    61     0.09   1208 WUDFHost

Below is a list of other things that you can try:

Get-RemotePr<tab>: tab completion on remote command and parameter names
Get-Help Get-RemoteProcess: downloading help content from remote session and displaying it on a local box
Get-RemoteProcess -Name $localVariable: binding local variables as arguments to parameters of remote commands
Get-RemoteProcess -AsJob: invoking remote commands as background jobs using an extra switch parameter added to remote commands
Get-RemoteProcess -OutVariable global:localVariable | Out-Null: storing results of remote invocation in a local variable (scope prefix is unfortunately necessary because of implementation details)
Get-RemoteProcess | Select-Object -Last 5: mixing remote and local commands in a single pipeline

Thanks,

Lukasz Anforowicz [MSFT]
Windows PowerShell Developer
Microsoft Corporation

How to pass arguments for remote commands

PowerShellTeam — Tue, 29 Dec 2009 20:57:56 GMT

When invoking remote commands, one often wants to use local values as arguments to the remote command. This post explains how to do that.

Hardcoded values

Let's start with a simple example. Below you can see how Get-Process is invoked in a remote session when the Id parameter is set to 0:

PS> $s = New-PSSession -Computer localhost
PS> Invoke-Command -Session $s -Script { Get-Process -Id 0 }
 
Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName     PSComputerName
-------  ------    -----      ----- -----   ------     -- -----------     --------------
      0       0        0         24     0               0 Idle            localhost

Passing local values

What if we want to calculate the value of the Id parameter programmatically, instead of hard-coding it to a particular integer? Well, script blocks can declare parameters and the param block can be used to pass a value to the command that is being invoked. In the following example, we declare the $processId parameter in the script block and then use the Args parameter of Invoke-Command to set the value of $processId to $pid, which is the process ID of the current Windows PowerShell process.

PS> $s = New-PSSession -ComputerName localhost
PS> Invoke-Command -Session $s -Script { param($processId) Get-Process -Id $processId } -Args $pid
 
Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName     PSComputerName
-------  ------    -----      ----- -----   ------     -- -----------     --------------
    533      13    46160      37456   198     6.07   9488 powershell      localhost

The example above demonstrates that Get-Process was invoked with a process id of the local Windows PowerShell console. Invoke-Command takes whatever you pass in the Args parameter and binds it to script block's parameters in the remote session. Note that above I simply passed in a value of a local $pid variable, but any local expression (not just a simple variable dereference) can be used instead.

Referring to remote variables

A different behavior takes place when you don't declare script block parameters using the "param" keyword:

PS> $s = New-PSSession -ComputerName localhost
PS> Invoke-Command -Session $s -Script { Get-Process -Id $pid }
 
Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName     PSComputerName
-------  ------    -----      ----- -----   ------     -- -----------     --------------
    329      10    21216      33524   154     7.63   6596 wsmprovhost     localhost

In this case $pid is an unbound variable and Windows PowerShell assumes that it refers to the $pid variable in the remote session. Therefore, as you can see Get-Process returns the process that hosts the remote session.

Magic $args variable

What happens when you use the Args parameter of Invoke-Command cmdlet, but don't declare any parameters in the script block? Local values are still passed to the remote session and in this case are bound to the $args variable. This can save some typing:

PS> $s = New-PSSession -ComputerName localhost
PS> Invoke-Command -Session $s -Script { Get-Process -Id $args[0] } -Args $pid

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName                    PSComputerName
-------  ------    -----      ----- -----   ------     -- -----------                    --------------
    808      46    76840      81876   596     5.05   7824 powershell                     localhost

Thanks,

Lukasz Anforowicz [MSFT]
Windows PowerShell Developer
Microsoft Corporation

PowerShell Help Reader – WOW!

PowerShellTeam — Sat, 26 Dec 2009 19:03:10 GMT

Alexey Martseniuk posted a blog entry in the PowerShell NewsGroup announcing a new version (V1.2) of the PowerShell Help Reader. My first reaction is WOW!

Start your wow experience by going to http://PowershellTools.Com and checking out the Silverlight-based intro screen. (You’ll need Silverlight of course but you should have it anyway – it is awesome.) This is the harbinger of things to come. The installed app takes advantage of WPF to deliver an excellent help experience.

The basic edition of the product is free and contains all the features but works only for the built-in PowerShell snap-ins/modules. The professional Edition has no limitations.

This is a great looking tool and addresses a lot of the shortcomings of our help.

Great job Alexey!

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

A Christmas Tree in WPK

PowerShellTeam — Sat, 26 Dec 2009 01:16:45 GMT

Merry Christmas. To celebrate the holiday, here’s a quick Christmas tree written in WPK (the WPF PowerShell Kit). You can get WPK as part of the PowerShellPack (http://code.msdn.microsoft.com/PowerShellPack).

Here’s a screenshot:

and Here’s the script:

Import-Module WPK            
            
New-Polygon -Points {            
    # Start from the top            
    "87.5,0"            
    # Left Side of Tree            
    "0,150"             
    "75,140"            
    # Bottom of Tree            
    "75,175"            
    "95,175"            
    # Right Side of Tree            
    "95,140"            
    "175,150"            
    # Back to the top            
    "87.5,0"            
} -On_SizeChanged {            
    if ($_.PreviousSize.Width -eq 0 -and            
        $_.PreviousSize.Height -eq 0) {            
        $this.Resources.OriginalSize = $_.NewSize            
    } else {            
            
        $originalSize = $this.Resources.OriginalSize            
        $ScaleX = $_.NewSize.Width  /$originalSize.Width             
        $ScaleY = $_.NewSize.Height / $originalSize.Height             
        $this.RenderTransform = New-ScaleTransform -ScaleX $ScaleX -ScaleY $ScaleY            
    }                    
} -BitmapEffect {             
    New-BevelBitmapEffect -BevelWidth 1            
} -Fill DarkGreen -AsJob

It’s only about 30 lines, but this script has tons of Christmas goodies. It shows an example of how to create any random polygon with a simple list of points, how to resize that polygon to whatever size the control need to be, and how to apply a quick bitmap effect to an image.

Hope this Helps,

James

PowerShellPack Reaches 10,000 Downloads in 3 Months

PowerShellTeam — Thu, 24 Dec 2009 00:39:07 GMT

Just before the release of Windows 7, the Windows 7 Resource Kit PowerShell Pack was released. Today, it hit 10,000 downloads.

It contains 10 useful modules that help you do more with Windows PowerShell. It has modules that can help every IT admin ( like the TaskScheduler module), and modules that can help any .NET developer (like PSCodeGen). There’s also a nifty module, IsePack, which provides a set of tools for working with the Windows PowerShell Integrated Scripting Environment. It also contains WPK, a module that allows you to script rich WPF UIs with PowerShell.

If you haven’t taken the time to check it out yet, you should. It can help any scripter get up to speed with the possibilities of PowerShell V2. You can check out the PowerShellPack on MSDN Code Gallery: http://code.msdn.microsoft.com/PowerShellPack

If you’re interested in scripting UI in PowerShell, these three Channel9 videos should help get you started:

If you want to try using the Task Scheduler module, you can check out this blog post:

Sending Automated emails with Send-MailMessage, ConvertTo-HTML, and the Task Scheduler Module

Go ahead and check out the PowerShellPack. It’s a great way to see all that PowerShell V2 is capable of.

Hope this helps,

James Brundage [MSFT]

Windows PowerShell 2.0 SDK

PowerShellTeam — Wed, 23 Dec 2009 11:27:00 GMT

Windows PowerShell 2.0 Software Development Kit (SDK) is now available for download. This SDK contains sample code and reference assemblies that allow you to build applications based on Windows PowerShell.

The samples demonstrate how to use the Windows PowerShell 2.0 APIs. You will also find sample code that shows how to use the new PowerShell class, how to write cmdlets that supports eventing, transactions and jobs. In addition, there are examples of host applications that connect to remote computers using individual runspaces and runspace pools. This SDK release also include modified Windows PowerShell 1.0 samples using the improved Windows PowerShell 2.0 APIs.

Hemant Mahawar [MSFT]
Program Manager

New-Object PSObject –Property [HashTable]

PowerShellTeam — Sat, 05 Dec 2009 04:30:25 GMT

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!

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

PowerShellTeam — Mon, 23 Nov 2009 00:52:02 GMT

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

PowerShellTeam — Fri, 20 Nov 2009 00:43:16 GMT

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

PowerShellTeam — Thu, 19 Nov 2009 02:08:00 GMT

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

PowerShellTeam — Sun, 15 Nov 2009 17:42:37 GMT

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

PowerShellTeam — Thu, 12 Nov 2009 13:57:00 GMT

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!

PowerShellTeam — Mon, 09 Nov 2009 16:05:15 GMT

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

PowerShellTeam — Thu, 05 Nov 2009 16:46:00 GMT

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