Vista - Running powershell scripts on a client computer.

Hi all,
I just wanted clarification on something. If I had a powershell script that
I wanted to run on a client machine that is connected to an application
server, am I correct in assuming that powershell must be installed on the
client machine? Can powershell be redistributed as part of the client
component? The server component contains the powershell script, is it
possible to run this component on client machines without powershell being
installed on client machines? If it is, I want to take the output of the
script and communicate it back to the Application server via WCF. App server
will have a windows service hosting a WCF web service. The scope of what I am
communicating back to the app server is Interprocess communication between a
client app process and any process communicating with that app process.

Depends on what you're doing. Alot of powershell functions can actually be
run from a remote server, thus removing the need to have powershell installed
on the station.

"Ldaled" wrote:

Totally true. But I forgot to mention, clients are not joined to a domain or
any type of active directory, so their won't be any group policies either.
Think of the app server as sort of like a game server, clients connect
through there own internet connection, My app server could have a domain
associated with it, but I currently dont have client machines joining the
domain and I am not sure if it is possible. If I were to monitor a process
remotely, on one of these clients, what about perms? I am thinking there
might be issues there. The main goal is to be able to watch communication
between a named process, the client application, and any processes talking to
that named process. I will be watching each client individually. Clients have
no relation to each other except they are connected to the app server
utilizing said application.

"Tanyril" wrote:

It gets infinitely more complex if you're not on a domain, but still
possible. You'd more or less need to have a user on every computer with the
same UN/PW.
Allthough- since it sounds like you're working on a web app i'm probably not
the right guy to help you out

"Leopold DuPuis" wrote:

Its not a web app, it'll use Web services via WCF to communicate but nothing
in a browser. server component is WCF service hosted in a Windows Service.
client component will just be installed on client machine, possibly a windows
service as well. Do you work for MS Tanyril, if you do look me up in outlook.
I have all the other stuff down, I am just trying to figure out how to
monitor the process on client machine. Its already worked out how I am going
communicate that data back to the server.

"Tanyril" wrote:

If you want to actually run scripts on the remote machine that are
controlled\started from your local machine you will need to use PowerShell v2
on both machines and the remoting features.

If you just want to access information on the remote machine you may be able
to use WMI from your local machine
--
Richard Siddaway
All scripts are supplied "as is" and with no warranty
PowerShell MVP
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Leopold DuPuis" wrote:

Sounds like you want to reference the PowerShell assemblies from a client
app so it can execute some code? You'll need PowerShell installed on the
client and there is no redistributable merge module for this at the moment.
On Vista you could use the Windows Update standalone installer but on XP
you'll have to just package the .msi if it isn't a redist violation - I have
no idea if it is.

Once you have PowerShell installed, there are plenty of examples on
www.codeproject.com and other places for hosting a PowerShell runspace in
your app to execute some code. In v2 its even easier with just a single
PowerShell object needed.

Now for the unofficial answer....

I've successfully "sorta xcopy" deployed PowerShell which seems to only
require a pretty small registry key, but it must exist in HKLM which makes
it impossible to deploy on a per-user basis. A custom client, with
appropriate permissions on the workstation, would be able to inject this
HKLM key, launch a custom PowerShell host in-process, then remove the key
when it exits. But this is of course totally unsupported and probably
illegal.

-------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1]
"Install"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\1033]
"Install"="2"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine]
"ApplicationBase"="C:\\PowerShell\\Bin\\v1.0\\"
"ConsoleHostAssemblyName"="Microsoft.PowerShell.ConsoleHost,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35,
ProcessorArchitecture=msil"
"PowerShellVersion"="2.0"
"RuntimeVersion"="v2.0.50727"
"CTPVersion"="6"
"PSCompatibleVersion"="1.0,2.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PSConfigurationProviders]
@=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PSConfigurationProviders\Microsoft.PowerShell]
@=""
"ApplicationBase"="C:\\PowerShell\\Bin\\v1.0\\"
"AssemblyName"="System.Management.Automation, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
ProcessorArchitecture=msil"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="RemoteSigned"
"Path"="C:\\PowerShell\\Bin\\v1.0\\powershell.exe"



"Ldaled" <Leopold DuPuis@xxxxxx> wrote in message
news:C2F4307F-A45B-43DF-8B06-55E529C7C4C3@xxxxxx