PowerShell For Fun

PowerShell Script: Amazon WII Watch

2007-11-30T14:22:00.000-05:00

I just wanted a WII for Christmas gift and didn't want to spend $500 on ebay.

A Small powershell script will do!

# Begin of script
# =============================================================
# This code is for test purposes only. Use it at your own risk.
# =============================================================
param([string] $query= "B0009VXBAQ", [string] $button = "btn-atc._V46858960_.gif")

#Submit query sequence
"================================================================="
"ASIN: " + $query
"Button: " + $button
""
"Submit query ..."
$uri="http://www.amazon.com/gp/product/" + $query
$AmazonClient = new-object System.Net.WebClient

#checking for results
While ($true)
{
$pagecontent = $AmazonClient.DownloadString($uri);
"================================================================="
# Get Availability
if ($pagecontent -match $button)
{
write-host "In Stock`a`a`a" -foregroundcolor Red
}
else
{
write-host "out of Stock" -foregroundcolor yellow
}
[datetime]::Now.tostring()
"Wait..."
Start-sleep 60
}

#End of script

=================================================================
out of Stock
2007-11-30 13:07:52
Wait...
=================================================================
In Stock

2007-11-30 13:08:58
Wait...
=================================================================
out of Stock
2007-11-30 13:10:01
Wait...
=================================================================
In Stock

2007-11-30 13:11:05
Wait...

Tags: msh monad PowerShell

New Project Home at CodePlex.com

2007-02-28T14:07:00.000-05:00

Private workspaces @ gotdotnet.com will be phased out on 3/20/2007. I moved new project home to CodePlex.com @ http://www.codeplex.com/powershellremoting. You can get news, report bugs and request feature there.

We are working on a beta release on X64 and VISTA. We will come up a road map for future PowerShell Remoting development soon. If you have any suggestions, please reply here or discussion section @ new Powershell Remoting project home.

Tags: msh monad PowerShell

PowerShell Remoting Go OpenSource!

2007-01-25T14:47:00.000-05:00

You can now download full source code of PowerShell Remoting from my workspace.

Let's welcome our new developers: Romangeeko and JaviRuso. We are still looking for developers. If you are intersted, please Email me (shenzhonghao AT gmail DOT com).

Enjoy.

Tags: msh monad PowerShell

Looking For Developers

2006-12-12T14:31:00.000-05:00

I am very busy with my daytime job and my new born daughter. So I don't have enough time for PowerShell Remoting Project. But I would like to continue the development of this project in a community (probably open source).

I have been contact some friends also intersted in PowerShell Remoting.There are also a couple of user requesting for source code of PowerShell Remoting. If you are interested in this project and would like to contribute your time to it, please Email me (shenzhonghao AT gmail DOT com). It would be great if you could include some details about your previous development experience. Any other suggestion about this project is also welcome.

Tags: msh monad PowerShell

PowerShell Remoting version 0.2.9.0 For V1.0

2006-11-15T14:35:00.000-05:00

PowerShell Remoting version 0.2.9.0
1. Rebuild For PowerShell V1.0 RTW.
2. Fix "All User" profile not load at server problem.

Download here (381k)

Some user reported that PowerShellRemoting.ClientPSHost.dll is not registered properly in x64 platform. So I also uploaded a x64 build of PowerShell Remoting. Warning: This package have not been tested on x64 platform, use it at your own risk.

Please uninstall old version of Powershell Remoting before uninstall PowerShell RC2. After install PowerShell v1.0, you can install new version of Powershell Remoting.

Tags: msh monad PowerShell

PowerShell Remoting version 0.2.8.0 For RC2 Drop

2006-09-27T12:42:00.000-04:00

Windows PowerShell Team finally released PowerShell RC2. If you are running windows server 2003, you can enjoy new active directory provider. If you are a windows XP (non-English) user like me, I suggest you download Windows PowerShell 1.0 RC2 Language-Neutral Package for Windows XP (KB925228)

Some important changes not in release note.

Big window, different color

> $host.ui.rawui

ForegroundColor       : DarkYellow
BackgroundColor       : DarkMagenta
CursorPosition        : 0,4
WindowPosition        : 0,0
CursorSize            : 25
BufferSize            : 120,3000
WindowSize            : 120,44
MaxWindowSize         : 120,44
MaxPhysicalWindowSize : 128,44
KeyAvailable          : False
WindowTitle           : Windows PowerShell

If you like color setting of old version

>$host.ui.rawui. ForegroundColor = "gray"
>$host.ui.rawui. BackgroundColor = "black"
>clear

Path change
1. Home
C:\WINDOWS\system32\windowspowershell

2. User Profile folder
<My Documents>\WindowsPowerShell

3. Assembly change
System.Management.Automation now goes to GAC

PowerShell Remoting version 0.2.8.0
1. Rebuild for PowerShell RC2 version

Download from here. (381k)

Please uninstall old version of Powershell Remoting before uninstall PowerShell RC1. After install PowerShell RC2, you can install new version of Powershell Remoting.

Tags: msh monad PowerShell

Do You Know There is a $Host Variable

2006-08-06T23:19:00.000-04:00

PowerShell has a build-in $host variable which expose a System. Management. Automation. Internal. Host. InternalHost object. It is an internal object so you can't access it from assembly but monad team made it directly accessible from PowerShell script. $host is interesting and powerful. Just an example how powerful it is: my PowerShell Remoting "steal" the $host.UI for user interface remoting.

$Host is an implementation of System. Management. Automation. Host. PSHost abstract class. PSHost defined some important properties and methods which will be used for all cmdlet. For more detailed information about PSHost, you can consult Monad SDK online.

Let's see what we can do with $host
1. Some read-only properties provide information about current host.
These could be useful when you have to distinguish among multiple hosts (For example, my PowerShell Remoting has a remote host. Remote host have different Name, InstanceId, Version, etc).

CurrentCulture
CurrentUICulture
InstanceId
Name
PrivateData
Version

2. Two methods to support legacy application (like ping.exe).
Usually you do not need to call them directly. Monad engine will call them automatically if you invoke legacy application.

NotifyBeginApplication()
NotifyEndApplication()

3. Two methods about nested prompt.
I already discussed how to use those methods previously.

EnterNestedPrompt()
ExitNestedPrompt()

4. One method to force PowerShell exit.
This could be useful if some sever error occurs and you want to quit PowerShell.exe from your script. You can also pass error code to environment. For example:

>$host.SetShouldExit(10000)

5. $host.UI
This is an implementation of PSHostUserInterface object which expose some import user interface API.

5.1 public override Dictionary<string, PSObject> Prompt(string caption, string message, Collection<FieldDescription> descriptions)
This API is called when cmdlet required field(s) is null or empty. It is capable of get user input ([string]) and cnvert them to almost any .Net type in current appdomain. But the task of constructing Collection<FieldDescription> from script can be daunting.

5.2 public override int PromptForChoice(string caption, string message, Collection<ChoiceDescription> choices, int defaultChoice)
This is standard PowerShell text-base menu system. Don't re-invent wheels! If you want to provide a menu for user input, look nowhere and this method got you all covered. Mow has a nice example of how to use this methods.

5.3 Some more input API to get user input

ReadLine: Read a line from standard input, similar to read-host cmdlet
PromptForCredential: Get PSCredential object from User input, similar to get-credential cmdlet.
ReadLineAsSecureString: read from standard input and convert to SecureString, similar to Read-host -AsSecureString

5.4 Some output API to direct output to different channel and with color support.

Write: Write to standard output without /n/r
WriteLine: Write a line to standard output
WriteProgress: Wrtie to Progress panel, similar to Write-progress cmdlet
WriteDebugLine: Write to Debug channel, similar to Write-debug cmdlet
WriteErrorLine: Write to Standard Error, similar to Write-error cmdlet
WriteVerboseLine: Write to Verbose channel, similar to Write-verbose cmdlet
WriteWarningLine: Wrtie to Warning channel, similar to Write-warning cmdlet

5.5 $Host.UI.RawUI
This is an implementation of PSHostRawUserInterface abstract class. This is a new concept in PowerShell. In the prompt post, we use this object to do a lot of tricks.

5.5.1 Some properties to control Console window size, window title, cursor, buffer size, background/foreground color

BackgroundColor
BufferSize
CursorPosition
CursorSize
ForegroundColor
KeyAvailable
MaxPhysicalWindowSize
MaxWindowSize
WindowPosition
WindowSize
WindowTitle

5.5.2 Some console buffer API. Lee has a great burn-console script to demonstrate these methods.

FlushInputBuffer
GetBufferContents
LengthInBufferCells
NewBufferCellArray
ScrollBufferContents
SetBufferContents

5.5.3 public override KeyInfo ReadKey(ReadKeyOptions options)
It is a powerful API to read keyboard input. Check out the retuned KeyInfo object, with this method, one can theoretically write a script act like a simple screen editor.
Here is the ReadKeyOption enum:

[Flags]
public enum ReadKeyOptions
{
      AllowCtrlC = 1,
      IncludeKeyDown = 4,
      IncludeKeyUp = 8,
      NoEcho = 2
}

For example

> $host.ui.RawUI.ReadKey(12)
a
     VirtualKeyCode           Character     ControlKeyState             KeyDown
     --------------           ---------     ---------------             -------
                 65                   a              262176                True

Just to remind you, my PowerShell Remoting remote host implemented all Host, UI and RawUI. So feel free to explore those interesting API on you remote host.

Have Fun

Tags: msh monad PowerShell

Runspace Remoting

2006-07-18T23:11:00.000-04:00

Scott Hanselman is one of the early users and supporters of my PowerShell Remoting. He did an interesting post about Runspace Remoting. Briefly, he used export-clixml to serialize objects at server and used import-clixml to reconstruct PSObject at client. I have tried similar mechanism and failed. Actually Karl Prosser and I have been talking about using export-clixml/import-clixml a while ago . Great job, Scott!

Despite of my failure on serialization/de-serialization of PSObject, there is other reasons made me choose user interface remoting:

Monad was designed to capable of user interface remoting. Monad engine will manage to display and format (out-default) remote objects. Monad engine can even truncate objects collection for you if there are too many objects in the pipline.
Not all tasks require local objects exactly matching remote objects. For most remote scripting tasks, user interface remoting is good enough. User interface remoting deliver similar user experience as local shell. SSHD already proved itself successful story by similar mechanism.
User can manipulate "Real" remote objects via user interface remoting (No "Heisenberg Uncertainly Principle of PowerShell").
Serialization/de-serialization method has its own limitations.
- It can use a lot of resources and band-width. Consider the situation when multiple runspace ouput huge collection of objects at the same time, even with proper threading management server could still be overloaded.
- What if you just need one simple property of an object with hundreds or thounds of properties, you would have to serialize all public properties of that object and transfer it to client.
- It can loose some property associate with original objects.
"Clustering" multiple servers is possible with user interface remoting. I am trying to "fork" single client input to multiple servers by simply add current client component to server component. (There are still some problems with this model)

PS: To Monad Team, a public helper API to serialize PSObject to string will be really helpful.

Have Fun

Tags: msh monad PowerShell

How to: Using PowerShell through SSH

2006-07-13T23:51:00.000-04:00

It is possible to use PowerShell through SSH. Read the story from The Hive Archive.

But there are certain limitations:
1. You have to install cygwin, sshd and ssh client like putty (Well I can certainly live with that. Actually they are always on my hard drive).
2. No prompt
3. some Raw UI might not work

I am really looking forward to the new version of PowerShell with buildin Remoting function. According to Jeffrey Snover : Our plans for remoting are to leverage WS-MGMT the remoting protocol recently standardized through the DMTF.

Have Fun

Tags: msh monad PowerShell

Why There Is an Out-Default Cmdlet

2006-07-12T23:37:00.000-04:00

PowerShell have a couple of output control cmdlets:

> gcm out-*

CommandType     Name                            Definition
-----------     ----                            ----------
Cmdlet          Out-Default                     Out-Default [-InputObject <P...
Cmdlet          Out-File                        Out-File [-FilePath] <String...
Cmdlet          Out-Host                        Out-Host [-Paging] [-InputOb...
Cmdlet          Out-Null                        Out-Null [-InputObject <PSOb...
Cmdlet          Out-Printer                     Out-Printer [[-Name] <String...
Cmdlet          Out-String                      Out-String [-Stream] [-Width...

Out-Default cmdlet is one of the most mysterious one.

> help out-default

NAME
    Out-Default

SYNOPSIS
    The default controller of output.

DETAILED DESCRIPTION
    The standard treatment at the end of a pipeline is to send all objects to o
    ut-default. Out-default then sends them all to format-default. It takes th
    e objects that return and sends them to the default destination. For this
    reason, it is functionally equivalent to out-host but is not called from th
e console.

The help message does not help at all. Luckily enough, Jeffrey Snover has a blog entry talking about this cmdlet. In summary, It will "figure out how to format and output the object stream" and send them to host via Out-host cmdlet.

Here is my two cents:
1. Out-Default cmdlet is NOT for interactive console User.
Every interactive command from console will have Out-Default appended automatically by Monad engine. Add Out-Default in the middle of pipline could even cause unexpected output.

> gps | format-table
> gps | out-default | format-table # format-table will not work.

2. Out-Default cmdlet is for Monad hosting application.
To have a full-blown Monad hosting application, you have to create your own "Host" (System.Management.Automation.Host.PSHost) which implement interface to process output (If you don't have your PSHost output interface implemented, your will get an exception when Out-default finally called out-host.). Every interactive command from user input should have Out-Default appended. Then the output of user command were assessed by out-default, formatted by format-* cmdlet, and eventually sent to user interface by out-host cmdlet.

using System.Management.Automation;
using System.Management.Automation.Host;
using System.Management.Automation.Runspaces;

namespace HostingExample
{
   class TestHost
   {
       static void Main(string[] args)
       {
           string command = "gps";
           PSHost myhost = new MyHost();
           Runspace myRunspace = RunspaceFactory.CreateRunspace(myhost);
           myRunspace.Open();
           Pipeline pipeline1 = myRunspace.CreatePipeline(command, true);
           pipeline1.Commands[0].MergeMyResults(PipelineResultTypes.Error, PipelineResultTypes.Output);
           pipeline1.Commands.Add("out-default");
           Pipeline1.Invoke();
       }
   }

   Class MyHost : PSHost
   {
            // MyHost class should be derived from PSHost abstract class.
   }
}

Although you don't have to (and probably should not) type "Out-Default" at the end of your command, it is always there working for you. Given this reason, Out-Default cmdlet is registered and loaded as default cmdlets.

You see it is there, you do not use it, but it is definitely important.

Tags: msh monad PowerShell

Naive and Generic Object Collections in Powershell

2006-07-02T23:17:00.000-04:00

I believed that you must have dealt with collections in Powershell Scriting. PowerShell has a nice way to support naive object array (object[]):

>$a = 1,2,3 #comma were interpreted as object[]
>$a.gettype().AssemblyQualifiedName
System.Object[], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

>$a= 1..10 # .. were interpreted as continuous filled object[]
>$a.gettype().AssemblyQualifiedName
System.Object[], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

For naive object ArrayList/stack/Queue, you have to use new-object cmdlet

> $a = new-object System.Collections.Stack
> $a.GetType().AssemblyQualifiedName
System.Collections.Stack, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKey
Token=b77a5c561934e089
> $a.Push($([System.Net.IPAddress] "192.168.0.1"))

Most of time, you are fine with naive object model because PowerShell will do the type conversion for you.

>$a= 1..10
>$a |gm
   TypeName: System.Int32

Name        MemberType Definition
----        ---------- ----------
CompareTo   Method     System.Int32 CompareTo(Int32 value), System.Int32 Com...
Equals      Method     System.Boolean Equals(Object obj), System.Boolean Equ...
GetHashCode Method     System.Int32 GetHashCode()
GetType     Method     System.Type GetType()
GetTypeCode Method     System.TypeCode GetTypeCode()
ToString    Method     System.String ToString(), System.String ToString(IFor...

But sometimes it is not good enough. You probably want to use generic object model.

For generic array (like System.Net.IPAddress[]), it requires a conversion:

>$a = ($([System.Net.IPAddress] "192.168.0.1"),$([System.Net.IPAddress] "127.0.0.1") )
>$a.gettype().AssemblyQualifiedName
System.Object[], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
>$b= [System.Net.IPAddress[]] $a
> $b.GetType().AssemblyQualifiedName
System.Net.IPAddress[], System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

For generic collection (like System.Collections.ObjectModel.Collection<System.Net.IPAddress>), it becomes a little nasty (it requires Assembly Qualified Name) :

>$a = New-Object System.Collections.ObjectModel.Collection"`1[[System.Net.IPAddress, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]"
> $a.GetType().AssemblyQualifiedName
System.Collections.ObjectModel.Collection`1[[System.Net.IPAddress, System, Vers
ion=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Vers
ion=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
> $a.Add($([System.Net.IPAddress] "192.168.0.1"))

What about generic Stack?

> $a = New-Object System.Collections.Generic.Stack"`1[[System.Net.IPAddres
s, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]"
> $a.GetType().AssemblyQualifiedName
System.Collections.Generic.Stack`1[[System.Net.IPAddress, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
> $a.Push($([System.Net.IPAddress] "192.168.0.1"))
> $a.pop()
IPAddressToString : 192.168.0.1
Address           : 16820416
AddressFamily     : InterNetwork
ScopeId           :
IsIPv6Multicast   : False
IsIPv6LinkLocal   : False
IsIPv6SiteLocal   : False

Have Fun

Tags: msh monad PowerShell

PowerShell Remoting version 0.2.7.1

2006-06-29T23:18:00.000-04:00

Download here

Uninstall old version of PowerShell Remoting before install newer version.

New GUI client manager: Save/delete server information & connection option, generate connection script automatically, launch powershell remoting client directly.

Add option to reject connection if user found invalid remote X509 certificate.

Bug fix: Null login credential (press Cancel in CredUI window) cause server crash and client throw Null reference exception.

Bug fix: other minor bugs

Check out the help.chm in release package for details.

Have Fun

Tags: msh monad PowerShell

Enter Nested Prompt function

2006-06-22T23:27:00.000-04:00

In windows PowerShell, $Host object provides direct access to some important APIs. One of the interesting functions is $Host.EnterNestedPrompt(). Frankly speaking, it did not appeal to me at all when I first tried it. But I discovered this beauty after I implemented my own PSHost in PowerShell Remoting,

What did it do?

Suspend & Save current execution context state.
Create a new nested execution context.(Nested pipline, new prompt execution helper and new script excution helper)
Push the new nested execution context to stack. (PowerShell use a static stack. In my PowerShell Remoting, it is more complicate. Every client has its own host; every host has its own stack for nested prompt.)
Increase $NESTEDPROMPTLEVEL

That is to say:

Your current pipeline is suspended. All variables and errors state were saved.
In the meantime, you still have access to monad engine. You can have new prompt, run new script or other interactive command.
When you are done with the new scope, you can call invoke $Host.ExitNestedPrompt() or "exit" (which will call $Host.ExitNestedPrompt()) to return to previous pipeline.

What can I do with it?

First, Let's see how "Suspend" works when using -confirm option or "Set-PSDebug -Step"

> kill 2804 -Confirm

Confirm
Are you sure you want to perform this action?
Performing operation "Stop-Process" on Target "Notepad (2804)".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

> Set-PSDebug -Step
> D:\ps1\special.ps1

Continue with this operation?
1+ D:\ps1\special.ps1
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

Secondly, $Host.EnterNestedPrompt() can be used as break point when debugging your script.

> 1..10 | %{if($_ -eq 5) {$host.EnterNestedPrompt()};$_}
1
2
3
4
>>> $_
5
>>> exit
5
6
7
8
9
10

Be careful

Nested prompt and original prompt share same variables provider. So when you change a variable in nested prompt, the change will remain effective in original prompt.
Comannd will be written in history when it is completed. So a suspended command will not be found in history.
The maximum depth of nested prompt level ($NESTEDPROMPTLEVEL) is 128. So always check $NESTEDPROMPTLEVEL for current nested prompt level. You can write it into your prompt function.
Do not try to make a nested function using $Host.EnterNestedPrompt(). But you can always do this.

function factorial
{
    param ([int]$n = 1)
    if ($n -le 0)
    {
        "Invalid parameter."
         return
    }
    if ($n -eq 1)
    {
        return 1
    }
    return $n * (factorial ($n-1))
}

Reference: Start-NewScope

Tags: msh monad PowerShell

What Access Rights Do You Have?

2006-06-12T11:30:00.000-04:00

A PowerShell script to check User/Group access rights on FileSystem and Registry.

Yesterday, I was reading post on Mark's Sysinternals Blog: The Power in Power Users. It says "a user that belongs to the Power Users group can easily elevate themselves to fully-privileged administrators". He used a tool called AccessChk to find out what access rights does "Power User" group have.

If you read my serise posts on access control list in monad. you will find out that we can get/set access rule in PowerShell directly without using extra tools. So I wrote a PowerShell script (Check-AccessRights.ps1) to get similar function as AccessChk. It is pretty dirty, but dose the job. You may want to try

D:\ps1\Check-AccessRights.ps1 .\
# Check your access rights on current path (could be filesystem or registry)

D:\ps1\Check-AccessRights.ps1 HKLM:\sytem\CurrentControlSet\Services $true "Power Users"
# HKLM:\sytem\CurrentControlSet\Services is Path to check
# $true is to get child object ACL recursively
# "Power Users" is user/group

Be prepared if you use -Recurse option ($true), you may want to redirect results to a file.

#################################################################
#
# File: Check-AccessRights.ps1
# Author: Tony (http://MSHForFun.blogspot.com/)
# Parameters:
#    $Path: PowerShell Path (for example, c:\ or HKLM:\)
#    $Recurse: Check child object recursively
#    $Account: User name / Group (for example, "domain\alice",
#               "Power Users")
#
################################################################
param([string] $Path = {throw "Please specify a path"}, [bool] $Recurse = $false, [string] $Account)
if (-not (test-path $Path))
{
    $Path + " not exists!"
    return
}
if ([string]::ISNullOrEmpty($Account))
{
    $SID = ([System.Security.Principal.WindowsIdentity]::GetCurrent()).Owner
}
else
{
    $SID = (new-object System.Security.Principal.NTAccount($Account)).Translate([System.Security.Principal.SecurityIdentifier])
    if ($SID -eq $null) {return}
}
"Account: " + $SID.ToString()
"Path: " + $Path
$AccessRules = (get-acl $Path).Access
if ($AccessRules -eq $null)
{
    "Can't get access rules!"
    return
}
$AccessRules|foreach-object {
    $CurrentSID = $_.IdentityReference.Translate([System.Security.Principal.SecurityIdentifier])
    if ($CurrentSID.ToString() -eq $SID.ToString())
    {
        $_
    }
}
if ($Recurse)
{
    Get-ChildItem $Path -Recurse| foreach {
        "========================================"
        "Child Path: " + $_.ToString()
        $AccessRules = (get-acl $Path).Access
        if ($AccessRules -eq $null)
        {
            "Can't get access rules!"
            return
        }
        $AccessRules|foreach-object {
            $CurrentSID = $_.IdentityReference.Translate([System.Security.Principal.SecurityIdentifier])
            if ($CurrentSID.ToString() -eq $SID.ToString())
            {
              $_
            }
        }
    }
}

Have Fun

Tags: msh monad PowerShell

PowerShellIDE: the Good, the Bad and the Ugly

2006-06-07T23:45:00.000-04:00

PowerShellIDE? Yes, an IDE for PowerShell! Oh, boy! That's a whole lot fun. If you like PowerShell, you should try this out.

The good:
It is advertised (it is free at this moment) as "The World's First PowerShell Editor" (what is "PowerShell Analyzer" then?) and wrapped in a dazzling GUI (you should really checkout its Mac style chooser).

You got intellisense functionality, a debugger, variable explorer and properties window.

You can set up a breakpoint in your script and checkout pipline in a GUI environment.

It is the first GUI Monad hosting application I have seen which can handle legacy console application (like ping.exe or netshe.exe)

The bad:
1. Not yet implemented.
You'd better forgot about following API:
Read-host -AsSecureString (ReadLineAsSecureString)
PromptForCredential
SetBufferContents
Getbuffercontents

2. It is not the same!
Don't expect same user experience with
Write-progress
$host.UI.ReadLine() (Oops, Popup window)
$host.UI.RawUI.ReadKey()

The ugly:
PowerShellIDE has to be run under Administrator account. This is killing me. Come on, men! Why it has to read prefetch?

PowerShellIDE.E:3300 OPEN C:\WINDOWS\Prefetch\POWERSHELLIDE.EXE-3628D30E.pf ACCESS DENIED

Some other thoughts:
I came across someone's post (I forgot where) talking about PowerShell: "This thing is for Programmer." Now, we have an IDE for PowerShell. It again prove "This thing is for Programmer." Remember the famous joke about Microsoft Visual Studio:" The IDE is so good and you were having so much fun with it. Eventually you forgot what you were doing." This is exactly what happened here:

Despite of intellisense, the entire "breakpoint, pipline reader and properties" thing can be done in PowerShell.exe command line directly. Just add "$host.EnterNestedPrompt()" in my script, I can get current pipline status, explore properties as I wish. But in the windows world, everyone indulged themselves to the IDE thing. People always try to find an IDE desperately even there is no need for that. I bet those guys from "slash dot" will laugh at us again.

Tags: msh monad PowerShell

PowerShell Remoting version 0.2.6.0

2006-06-06T00:25:00.000-04:00

Download here

Uninstall old version of PowerShell Remoting before install newer version.

Write Server Information & Error to EventLog (Source: PowerShellRemoting). Log file will no longer be used by newer version.

SSL support using SSLStream.

Warning: SSL is for advanced user.

Get X509 certificate for server. For testing purpose, you can use makecert.exe (included in .NET framework SDK)
Install X509 certificate at StoreLocation: LocalMachine, StoreName: My (personal).
Grand "NetworkService" account read access to X509 certificate associated private key file.
Set [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters\ X509] to thumbprint of X509 Certificate.

There is pretty good walkthrough at John Howard's blog.

X509 Option

DebugHost Option (Default 0: false)

Bug fix: Write-Progress throw null object Exception.

Check out the help.chm in release package for details.

Have Fun

Tags: msh monad PowerShell

Download Gene Sequences Using NCBI eFetch Tools

2006-05-30T23:56:00.000-04:00

Recently, I was working on a bioinformatics research project which needed to download hundreds of gene mRNA sequences. I have all the gene IDs in one text file. So a simple PowerShell Script could solve my problem.

I have a old post talking about NCBI Entrez eUtils tools. Today, I will use the eFetch tool (also included in eUtils). The script is simple and self-explaining.

# ===========================================================================
#
# Author:      Tony (http://MSHForFun.blogspot.com)
# File:        Efetch.ps1
# Description: Download gene sequences using NCBI eUtils.eFetch tool
# Reference: http://eutils.ncbi.nlm.nih.gov/entrez/query/static/eutils_example.pl
# Reference: http://eutils.ncbi.nlm.nih.gov/entrez/query/static/efetch_help.html
# Reference: http://eutils.ncbi.nlm.nih.gov/entrez/query/static/efetchseq_help.html
#
# ===========================================================================
param
(
[string] $Path=$(throw "Please Specify a file")
)
$BaseURL = "http://www.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=nucleotide&id="
$Option= "&rettype=fasta&retmode=text"
$WebClient = new-object System.Net.WebClient
$SavePath = $Path + ".result"
if (test-path $savePath)
{
del $SavePath
}
foreach ( $id in (get-content $path))
{
# Construct eFetch URL
$URL=$BaseURL + $id + $Option
Write-Progress -Activity "Download Sequences" -Status "Submit gene $Id"
# Submit and download data
$Data = $WebClient.DownloadString($URL)
# Parse Data
if ($Data.Length -gt 1)
{
    Write-Progress -Activity "Download Sequences" -Status "$id OK"
    # Write to Console
    $data
    # Wrtie To file
    $data >> $SavePath
}
else
{
    Write-Progress -Activity "Download Sequences" -Status "$Id is not found!"
    "$Id is not found!`n`r"
    "$Id is not found!`n`r" >> $SavePath
}
# Try not to overload NCBI Server
start-sleep 1
}
# Clear Progress pane
Write-Progress -Activity "Download Sequences" -Status "Done" -completed

You need a text file (genes.txt) to test this script:

0
NM_008176
NM_009140
NM_009141
NM_011333
NM_013654
NM_016960
NM_009142
NM_008491
NM_031168
NM_009883
NM_007679
NM_010030
NM_009971
NM_010809
NM_008607
NM_030612
NM_011198
NM_007987

If you are a biologist, you can see what kind of genes I am intersted in. The first "0" is just to cause an "Not Found" Error. You can run this script like following:

.\efetch.ps1 genes.txt

Your results is printed to screen as well as "genes.txt.result" file.

Have Fun

Tags: msh monad PowerShell

PowerShell Remoting, Lock Down

2006-05-18T21:24:00.000-04:00

Any remote shell application is dangerous because you open a door to outside world. So does PowerShell Remoting. Previous version of PowerShell Remoting totally depended on NegotiateStream. You have no control of login process or you can not limit user access. So anyone with a valid local or domain account can login remotely into your computer. As more and more people began to download and install PowerShell Remoting on their computer, I decided to add client access control policy to PowerShell Remoting.

Firstly, you should limit maximum number of clients which can connect to server simultaneously. This is done by modify registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]
"MaxClient"=dword:0000000a

Default value is 10. Given 256MB memory is standard configuration for desktop PC, this number is more than enough if you decided to login to your desktop from home network. You can definitely increase this number if you have more clients but remember each runspace will allocate quite a few of memory. So do some experiment and calculation then you can find a reasonable number.

Secondly, you should limit maxium number of clients which can connect to server simultaneously from Same IP address. This is done by modify registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]
"MaxClientPerIP"=dword:00000002

Default value is 2. You can also change that but you don't want all your available slots of connection were occupied by clients from same computer.

Thirdly, you may want to limit which user can login from which IP address. This is done by modify
%Program Files%\PowerShell Remoting\user.xml
Default installation only allow user in Administrators group login from localhost. So you have to have your own user.xml before you can login from another IP. If user.xml file parse error occorred when start service, default policy will be loaded. If you can't login, check log file or EventLog for details of parse error.
User.xml file contain information about your user access control list. It has SEVEN tags:

<NetworkACL>: container of one or more access control entry (<NetworkACE>)
<NetworkACE>: access control entry container of <Account>, <Access> and <IPRange>
<Account>: Valid Group or User
<Access>: Allow / Deny
<IPRange>: container of <IP> and <Subnet>
<IP>: IPAddress. 0.0.0.0 for any IP, 127.0.0.1 for localhost, 192.168.0.2 etc. IPv6 string should be fine, but I have not been able to test it.
<Subnet>: IPv4 subnet. 192.168.0.0/255.255.255.0 or CIDR like format 192.168.0.0/24.

Within <NetworkACE> and </NetworkACE> tags, order matters.

<Account>
<Access>
<IPRange>

Within <IPRange> and </IPRange> tags, <IP> and <Subnet> can be used in any order.
As you can probably already figured it out : After user provide credential and got a token (WindowsIdentity), PowerShell Remoting will try to match User/Group and IP range in records of access control list. If no record was found, access is denied. If a records match User/Group and IP range were found, PowerShell Remoting will assess access in following order:

User Deny > User Allow > Group Deny > Group Allow

For example: if client were a privileged user (Administrators group) from 192.168.0.2, but there were only one record which wanted to deny access of Users group from subnet 192.168.0.0/255.255.255.0. Then access from this client will be denied because any user belongs to Administrators group also belongs to Users group and 192.168.0.2 belongs to subnet 192.168.0.0/255.255.255.0.

After you logged in and get a PowerShell prompt, you can check $UserACL for serialized access control list.

Right now, subnet parsing and match could be buggy. So tell me if you found it did not act as expected.

These changes could make it more difficult to start using PowerShell Remoting. But I believed that you will like them later on. Remember, if you make any changes to previous setting, you will have to restart service to make them take effect.

Stop-Service PowerShellRemoting
Start-Service PowerShellRemoting

There is also some exciting new feature:

PowerShell Remoting Client becomes a PSSnapin now. So installation become usier. Just run install.ps1 in client folder and invoke Start-RemoteHost, you are on you way to your remote shell.
Ctrl+C Ctrl+Break support.

dir c:\windows\system32

$RemotingClient.CanHandleCancelKey = $false

You will find out that information written in log file has been dramatically reduced because I am going to swith to EventLog in later verion.

I can actually run PowerShell Remoting Client with in PowerShell Analyzer. But its ReadLine popup window really bothers me.

Tags: msh monad PowerShell

PowerShell Remoting version 0.2.5.1

2006-05-18T17:05:00.000-04:00

Version 0.2.5.1

Uninstall old version of PowerShell Remoting before install newer version.

Support Ctrl+C and Ctrl+Break to cancel current pipeline (UDP datagram, So not 100% reliable)

Support Maximum Client per IP option (default 2)

Customized client filter policy (%Program Files%\PowerShell Remoting\user.xml, see sample files for format information)

Important

only allow user in Administrators group login from localhost

$UserACL variable for current client filter policy

Client is installed as PSSnapin

New install/uninstall script for both server and client, new start-remotehost.ps1 script

CanThrowException and CanHandleCancelKey property of client (For developer)

Change Log file path to %Documents and Settings%\NetworkService\Local Settings\Application Data\PowerShellRemoting.log

Change Service Name to "PowerShellRemoting"

Service related Exception is also Logged to Eventlog (EventLog: Application, source: PowershellRemoting)

Other Bugs fixed

Have Fun

Tags: msh monad PowerShell

Potential Security Problem of PSSnapin Installation and Execution

2006-05-13T22:47:00.000-04:00

Windows PowerShell is powerful (hehe, sounds like a bad salesman). To make it even better, user can extent it by PSSnapin. PSSnapin can contain PSProviders, Cmdlets and other class library. But there is a catch. PSSnapin is arbitrary code which could be bad designed, bugs loaded and somewhat out of your control. If you are not careful when install and execute, PSSnapin can cause serious security problems. Let's look following example:

Supposed you have a PSSnapin:

using System;
using System.ComponentModel;
using System.Management.Automation;
namespace TestSnapin
{
    [RunInstaller(true)]
    public class MySnapin : PSSnapIn
    {
         public override string Name
         {
            get { return "Test"; }
         }
        public override string Vendor
        {
             get { return "http://MSHForFun.blogspot.com/"; }
        }
        public override string Description
        {
            get { return "Test"; }
        }
    }

   public class Class2
   {
        public string Who
        {
              get { return "Good Guy!"; }
        }
   }
}

You built it by yourself or simply downloaded it from internet. You (An Administrator) copied it to a folder and ran installutil.exe to install it. Then you tried to use it in PowerShell:

>get-pssnapin -reg

Name : Test
PSVersion : 1.0
Description : Test

> add-pssnapin test
> $a = new-object TestSnapin.Class2
> $a.Who
Good Guy!

Looks perfect, right? But

The folder where you save your PSSnapin is writeable by any user, so anyone can change your PSSnapin.
Your PSSnapin assembly is not signed, so PowerShell will load it without checking its integrity. See the registry key about your PSSnapin

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Test]
"PowerShellVersion"="1.0"
"Vendor"="http://MSHForFun.blogspot.com/"
"Description"="Test"
"Version"="1.0.0.0"
"ApplicationBase"="D:\\ps1"
"AssemblyName"="Snapin1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
"ModuleName"="D:\\ps1\\snapin1.dll"

Suppose there were a malicious user wrote a PSSnapin like yours PSSnapin except Class2:

public class Class2
{
    public string Who
    {
        get { return "Bad Guy!"; }
    }
}

He just overwrote your PSSnapin with his DLL. What happened next?

> add-pssnapin test
> $a = new-object TestSnapin.Class2
> $a.Who
Bad Guy!

That is to say user can run any code he wanted. In a worst condition, when you (An Administrator) tried to use this PSSnapin, you were actually tricked into running malicious code as Administrator!

So Lessons:

Keep an eye on your PSSnapin. Never put them in a directory which is writeable by unprivileged user

Edit: 2006-05-16 08:36

Always use a Signed PSSnapin. If a signed PSSnapin were altered, PowerShell will not load it.

> add-pssnapin test
Add-PSSnapin : Cannot load PSSnapIn test. Encountered following error: PSSnapin
module D:\ps1\snapin1.dll doesn't have required PSSnapin strong name Snapin1,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=3daf9f8a713aaa33.
At line:1 char:13
+ add-pssnapin <<<< test

Tags: msh monad PowerShell

New Shell, New Script Language, Same Old Problem

2006-05-11T16:19:00.000-04:00

I was reading post on "The Old New Thing" titled "A new scripting language doesn't solve everything" yesterday. I was just going to write something about this. Lee was one step ahead of me and did a response post titled "Nothing solves everything - PowerShell and other technologies".

Monad (well, I mean PowerShell) is cool. We have new shell and new script language. But it is still going to be a very long time before we can do everything using cmdlet because not only we need time to write new cmdlets, but also we are limited by what .NET Framwork can do. Most important, monad is NOT supposed to "solve everything". Instead monad is supposed to work cooperatively with "OLD" techniques. So we have to deal with backwards compatibility issue. For example, other scripting language, unmanaged code and legacy program (console application). I will talk about support for console application in monad hosting application today.

For a local interactive user, powershell.exe provides nice support for "old" console application inherited from cmd.exe. Common user don't even feel much difference between cmd.exe and powershell.exe if they just invoke

ping localhost

For a programmer, there is a difference lying underneath the surface. Monad using PSHostUserinterface and PSHostRawUserinterface to get user input and display results if user invokes cmdlets. To support legacy console application, powershell.exe actually create a new process (outside of pipeline) and redirects stdin/stdout/stderr of legacy console application to its own console.

PowerShell.exe works fine for two reasons:
1. PowerShell.exe itself is a console application.
2. PowerShell.exe does NOT care whether the legacy console application runs in a different process or not. (cmdlet runs in-process)

It becomes a nightmare if you are going to write a hosting application. Considering what will happen when user invokes console application inside your hosting application like "netsh.exe" which requires user input/output and you did not redirect input and output.
1. Legacy console application start a new process which is out of your control
2. If your hosting application is not a console application (like PowerShell Analyzer), legacy console application start a new Console window which is out of your control. "You can loose output or hang waiting for input that never comes." -- William Stacey [MVP]
3. For a remoting host application (like my PowerShell Remoting), it is even worse because the new console window is on another computer, there is no way for remote user move their cursor to the console window and provide input.

It is NOT a trivial work to solve this problem. My "PowerShell Remoting" does not solve this issue (A NotSupportException will be thrown if user invoked legacy console application). Karl Prosser's PowerShell Analyzer does not solve this problem. If you follow the disscussion in newsgroup: Redirect msh.exe in/out you will find more people are struggling with this issue.

So here comes the question: Should this issue been taken care of by internal host or external hosting application?

I think the answer is both YES and NO.
1. NO: The Design of Monad internal host is to focus on process scripting language, work with objects and piplines. External host is supposed to take care of application logic and user interface.
2. YES: legacy console application is a PROBLEM for ALL monad hosting application. So monad should provide more support for it.

For me, a perfect solution would be that all legacy console application use PSHostUserinterface and PSHostRawUserinterface for ALL output/input (There are protential big problem behind this). Maybe improvement for PSHostUserinterface and PSHostRawUserinterface's definition is needed. NotifyBeginApplication() and NotifyEndApplication() is not good enough.

Have Fun

Tags: msh monad PowerShell

PowerShell Remoting version 0.1.1.7

2006-05-09T17:29:00.000-04:00

What's New

Version 0.1.1.7
1. Recompiled for new Windows PowerShell RC1 (Refresh version)
2. Using "Thread Pooling" method to schedule multiple Host threads. So Sever can potentially
accept more connections. (Old version uses one thread per connection method).
3. Using a separate thread actively reclaim resources from broken connection and dead host.
4. Clean exit when stop service: Disconnect all clients and dispose all running hosts.
5. Gracefully disconnect client when server reach maximum client capacity.
6. Fix: Nested Prompt stack error when multiple clients connected.
7. Fix: Server unable to exit when connection closed unexpectedly by client.
8. Fix: "SetShouldExit" method re-throw "SocketException" Error

Tags: msh monad PowerShell

PowerShell Remoting version 0.1.0.317

2006-05-05T17:06:00.000-04:00

Version 0.1.0.317
1. NestedPrompt (suspend host)
2. Multiple line input mode
3. Use local UI to get login credential
4. Save RawUI state on start, and Reset RawUI state on exit.
5. $CurrentUser Variable (WindowsIdentity Object represent current
login user)
6. Load user profile in following order
1) "\Documents and settings\All users\PsConfiguration\profile.ps1"
2) "\Documents and settings\All users\PsConfiguration\PowerShellRemoting_profile.ps1"
3) "My Documents\PsConfiguration\profile.ps1"
4) "My Documents\PsConfiguration\PowerShellRemoting_profile.ps1"

Tags: msh monad PowerShell

Perfect Prompt for Windows PowerShell

2006-05-01T01:00:00.000-04:00

What Can Tweaking Your Prompt Do For You?

Windows PowerShell have a default prompt in one color (usually gray) that tells you your current working directory. This is OK, but you can do much more with the prompt.
1. All sorts of information can be displayed (machine name, host name, user name, time & date ...)
2. The prompt can use colors
3. You can also manipulate the windows title to dispaly more information.
4. Other RawUI operation is allowed (move cursor)

Why Bother?

Beyond looking cool, it's often useful to keep track of system information.
1. Get your current working directory (how many files in current directory)
2. Current system time, how many process is running
2. If you use my su.msh, you would like to know you current windows identity
3. If you use my powershell remoting, different color helps distingish between local host and remote host.
4. Colorizing your prompt is the ability to quickly spot the prompt when you use scroll console.

First step: Profile and prompt function

Windows PowerShell use Profile to customize user environment. For more detail, about profile
The Story Behind the Naming and Location of PowerShell Profiles:
http://www.leeholmes.com/blog/TheStoryBehindTheNamingAndLocationOfPowerShellProfiles.aspx

1. You can have different prompt for different shell (Maybe you use makeshell.exe generated you own shell)
2. If you have different prompt function defined in multiple profile, the last one excuted take effect
Remember the excution order is

"All users" profile is loaded from "<Installation Directory>\profile.ps1"
"All users," host-specific profile is loaded from "<Installation Directory>\Microsoft.PowerShell_profile.ps1"
Current user profile is loaded from "<My Documents>\WindowsPowerShell\profile.ps1"
Current User, host-specific profile is loaded from "<My Documents>\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"

Edit 09-29-2006

Windows PowerShell RC2 changed profile location to

<My documents>\WindowsPowerShell
Now you can customize you prompt in you profile (say <my document>\psconfigurtion\profile.ps1)
this is typical prompt function looks like:

function prompt
{
"PS " + $(get-location) + "> "
}

You can do whatever you want in prompt function. But remember
1) Always return a [string], otherwise Windows PowerShell will use default "PS> " prompt.
2) Try to limit your prompt in one (short) line
3) Host will evaluate prompt frequently, so don't do crazy stuff to slow down your work.

Colorized prompt

function prompt
{
Write-Host ("PS " + $(get-location) +">") -nonewline -foregroundcolor Magenta
return " "
}

Random color

function prompt
{
    $random = new-object random
    $color=[System.ConsoleColor]$random.next(1,16)
    Write-Host ("PS " + $(get-location) +">") -nonewline -foregroundcolor $color
    return " "
}

Cursor Movement
Display current time at the end of prompt line (this will mess up you console buffer)

function prompt
{
    $oldposition = $host.ui.rawui.CursorPosition
    $Endline = $oldposition
    $Endline.X+=60
    $host.ui.rawui.CursorPosition = $Endline
    Write-Host $(get-date).Tostring("yyyy-MM-dd HH:mm:ss")
    $host.ui.rawui.CursorPosition = $oldposition
    Write-Host ("PS " + $(get-location) +">") -nonewline -foregroundcolor Magenta
    return " "
}

Use Window Title
Show current user, host, current line number

$global:CurrentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()
function prompt
{
    $host.ui.rawui.WindowTitle = $CurrentUser.Name + " " + $Host.Name + " " + $Host.Version + " Line: " + $host.UI.RawUI.CursorPosition.Y
    Write-Host ("PS " + $(get-location) +">") -nonewline -foregroundcolor Magenta
    return " "
}

Make some noise
if your command take very long time to run, beep when it is done.

function prompt
{
Write-Host ("PS " + $(get-location) +">") -nonewline -foregroundcolor Magenta
return "`a "
}

More information
Count number of files(or items) in current path and number of process running

function prompt
{
    $host.ui.rawui.WindowTitle = "Files: " + (get-childitem).count + " Process: " + (get-process).count
    Write-Host ("PS " + $(get-location) +">") -nonewline -foregroundcolor Magenta
    return " "
}

Something for readers:
1. laptop battery is low ! (Edit 2006-07-21: Already done by Musings of a PC)
2. You got new mail !
3. LAN cable disconnected !

Have Fun

Reference:
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/

Tags: msh monad powershell

PowerShell, Change ... is Good ... but Painful

2006-04-26T11:36:00.000-04:00

"Monad" has evolved into "Windows PowerShell”. Don’t tell me your feeling about this name. That’s one of the problems working on a pre-release product. Just to make you fell better, it means we are really close to final release.

There is a bunch of improvement for console user:

1. Tab completion gets better now.

Did anyone know where is the API mentioned in release note: We added support for parameters and variables tab completion. This was done by having the host call a PowerShell function TabExpansion that takes two parameters – the line being entered and the last token on that line.

2. Some cmdlet Parameters alias changed

For example: *-Process Changed -ProcessName to -Name alias -ProcessName, add alias ProcessId to –Id

This makes me feel much better when working with *-process cmdlet.

Here comes the pain:

1. Change your old script file extention: *.msh - > *.ps1

2. Check into individual script (especially you profile.msh) see if you use any old cmdlet names: for example, combine-path -> join-path

3. Change you %my documents%\msh\profile.msh to %my documents%\PSconfiguration\profile.ps1

If you previously wrote some cmdlets or hosting application, you are going to deal with some mess here:

1. Be careful about name changes:

CmdletAttribute
VerbNounCommand

MshHostRawUserInterface
PSHostRawUserInterface

MshCredential
PSCredential

MshCredentialTypes
PSCredentialTypes

MshCredentialUIOptions
PSCredentialUIOptions

MshInvalidCastException
PSInvalidCastException

Some hidden changes:

FieldDescription.AssemblyFullName
FieldDescription.ParameterAssemblyFullName

FieldDescription.TypeFullName
FieldDescription.ParameterTypeFullName

FieldDescription.TypeName
FieldDescription.ParameterTypeName

BufferCell.Type
BufferCell.BufferCellType

If you are using my “Monad Remoting”

Uninstall “Monad Remoting” before upgrade to “PowerShell”
You’ve been warned!

To use “PowerShell Remoting”, you have to change you client script.
To build your own client, be careful about name change.

Tags: msh monad