PowerShell Remoting Project Home

Friday, March 31, 2006

PowerShell Remoting - Beta and future

Release of "PowerShell Remoting", 0.2.7.1 Beta version.
Version 0.2.7.1

  1. New GUI client manager: Save/delete server information & connection option, generate connection script automatically, launch powershell remoting client directly.
  2. Add option to reject connection if user found invalid remote X509 certificate.
  3. Bug fix: Null login credential (press Cancel in CredUI window) cause server crash
  4. Bug fix: other minor bugs

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

  2. SSL support using SSLStream.

  3. Warning: SSL is for advanced user.
    If you want to provide SSL support to server, you should

    • 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.

  4. X509 Option

  5. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]
    "X509"="0"

  6. DebugHost Option (Default 0: false)

  7. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]
    "DebugHost"=dword:00000000

  8. Bug fix: Write-Progress throw null object Exception.
Check out the help.chm in release package for details.

Version 0.2.5.1
1. Support Ctrl+C and Ctrl+Break to cancel current pipeline (UDP datagram, So not 100% reliable)
2. Support Maximum Client per IP option (default 2)
3. Customized client filter policy (%Program Files%\PowerShell Remoting\user.xml, see sample files for format information)
Important: 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. Check log file or EventLog for details of parse error.
4. $UserACL variable for current client filter policy
5. Client is installed as PSSnapin
6. New install/uninstall script for both server and client, new start-remotehost.ps1 script
7. CanThrowException and CanHandleCancelKey property of client (For developer)
8. Change Log file path to %Documents and Settings%\NetworkService\Local Settings\Application Data\PowerShellRemoting.log
9. Change Service Name to "PowerShellRemoting"
10. Service related Exception is also Logged to Eventlog (EventLog: Application, source: PowershellRemoting)
11. Other Bugs fixed

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

Version 0.1.0.318
1. Fix "All User" profile Path
1) "\Documents and settings\All users\Documents\PsConfiguration\profile.ps1"
2) "\Documents and settings\All users\Documents\PsConfiguration\PowerShellRemoting_profile.ps1"

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"

Version 0.1.0.311
1. Solve Server cause CPU overload problem
2. Solve Port or MaxClient change not take effect problem
3. Except for PSHostUserInterface.Prompt, all other UI/RawUI
API were connect to local UI/RawUI API
4. improved Client exception report

Version 0.1.0.301
1. Recompile for new Windows PowerShell RC1
2. Client class libary to build your own client
3. Console client use naive PowerShell.exe user interface
4. Support for all RawUI API
5. Bug fix for server

Version 0.1.0.128
1. Multiple connection (Maximum 10 connection)
2. New log file format
3. Hide some common exception on Client
4. Some bug fix

This software is distributed under BSD license. See license.txt for details.

I. What is "PowerShell Remoting"

PowerShell Remoting is a light-weighted server-client application which
provides secure remote access to Windows PowerShelll (codename Monad).
It contains two components:

Server: A Windows Service (Service Name "PowerShell Remoting") running
under NetworkService account. It will listen at certain TCP port, accept
income connection, authenticate client and provide PowerShell hosting
environment.

Client: A Class libary. It severs as a proxy between sever user interface
and client user interface. It will connect to server, provide client
credential for authentication, get user input and display results.

This software is distributed under BSD license. See license.txt for
details.

II. System requirement.
1. Microsoft .NET framework v2.0.50727 (Server & Client)
2. PowerShell RC1 or Higher (Server only)
3. Windows XP/2003 (For server); Windows 2000/XP/2003 (For client)
4. 256MB Memory, 1M hard drive space.

III. Features
1. Client authentication & protection
1) All communication between server and client is encrypted and signed.
Depend on server environment, authentication method could be NTLM or
Kerberos.

2) Multipul connection from client. (default Port 8080, Maximum 10 connection)
Can be changed by modify registry.

2. Support PSHostUserInterface & PSHostRawUserInterface
1) PSHostUserInterface will be passed to constructor of client
2) PSHostRawUserInterface is not mandatory but is supported

Note : Not supported at this version
1) Tab completion
2) start-transcript

Note. Known problems
1) Outputs of legacy program are not redirected to client

IV Installation and usage
# Server
1. Please use provided install.ps1 (install service) and uninstall.ps1
(uninstall service) to install/uninstall server component.

2. Default installation, server will listen to all available IP
(IPAddress.Any) listen at port 8080 and maximum client number is 10.
Those can be changed by modify registry
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShell Remoting
\Parameters]
"Port"=dword:00001f90
"MaxClient"=dword:0000000a

3. Log file was "Hard Coded" to
C:\Documents and Settings\NetworkService\PowerShellRemoting.log

4. Default installed as Manual start service.

# Client
1. Client application do not need to be installed, just copy it to client
PC and execute "start-remotehost.ps1". (Some modification is needed)

2. argument:
start-remotehost
Where is IP address which server is listening
(For example: 127.0.0.1- for localhost; 192.168.0.2, et, al.)
Where is port number which server is listening
(default 8080)


If you have any other suggestions, please drop a few lines in comment.

Have Fun

Tags:       


Comments:
this sounds cool, maybe i should add "client" functionality in MSH Analyzer to be able to connect to a "Remote RUnspace" which would be your server.

Karl
 
There is a problem.
My client is a thin client which does not deal with MshObject. It just serve as a dispaly terminal.
But it is doable. We would have to make a customised client with receive serialized MshObject.
 
I dont know if you can help me out here. I am consuming a COM
component from a cmdlet and I register
an event sink with the COM component.

The Advise fails with access denied.
I reckon it should be because I
dont have coinitializesecurity called
in the process ...

Are there attributes which can
do the coninitializesecurity
for the shell

thanks
 
good post :)
 

Post a Comment





<< Home