Vista - HowTo: Add an ActiveX control in PowerShell

Goal:
I want to be able to add ActiveX control in Powershell. Specifically Remote
Desktop Control. I am thinking of creating a windows form with RDP controls.
I am picturing something kinda like the "Remote Desktops" MMC snap-in. If I
can manage to get this working in powershell I can make it much more dynamic
than the Snap-in.

p.s. Do I need to do something special to be able to create form objects
"$tsform = new-object Windows.Forms.Form." I see that /\/\0\/\/ used it, but
I get "New-Object : Cannot find type [Windows.Forms.form]: make sure the
assembly containing this type is loaded." I would expect this to be loaded.

You need to do a partial name load, and you may find the control use to be
pretty frustrating within a windows form due to container-related issues you
would need to handle - but it's doable and DOES need to be done by someone,
then shared with the rest of us. :|

To load the Windows Forms, you can load an assembly by partial name. Here's
the function wrapper I use:

# External assembly load declaration
function add-assembly($name)
{
return [System.Reflection.Assembly]::LoadWithPartialName($name)
}
#set-alias aasm add-assembly

Here's the line of code that you would then use to add the assembly:

Add-Assembly System.Windows.Forms

I'll take a look through a couple of the custom wrappers I've written for
the RDP control and post code. It will be all WSF or HTA code, but you'll be
able to see the sequence of events in what I did, and it may help.


"Brandon Shell" <tshell.mask@gmail.com> wrote in message
news:en2SDw30GHA.3464@TK2MSFTNGP03.phx.gbl...
> Goal:
> I want to be able to add ActiveX control in Powershell. Specifically
> Remote Desktop Control. I am thinking of creating a windows form with RDP
> controls. I am picturing something kinda like the "Remote Desktops" MMC
> snap-in. If I can manage to get this working in powershell I can make it
> much more dynamic than the Snap-in.
>
> p.s. Do I need to do something special to be able to create form objects
> "$tsform = new-object Windows.Forms.Form." I see that /\/\0\/\/ used it,
> but I get "New-Object : Cannot find type [Windows.Forms.form]: make sure
> the assembly containing this type is loaded." I would expect this to be
> loaded.
>

The load thing worked great. Thanks.

Now... with RDP control and forms. You are basically saying that it is
complicated to manage the RDP control within a windows form?
If that is true, lets take look at a different approach. A -Whatif as it
were.

If I wrote a cmdlet that created a "master" form with four basic functions
(StartSession, PlaySession, PauseSession, and StopSession) I could then
write scripts that would start sessions (in "background") and then I could
call PlaySession when I need to actually use a session or Pause or Stop when
im through.

My Original thought was a master form with two panes (One small one on the
Left, and a Large One on the Right. Kinda like MMC Snap-in.) The Left pane
would have the list of servers, the right would contain the currently
selected servers RDP session. I know this sounds dumb... I mean... why dont
I just use the MMC snap-in if I like it so. Well... the reason is because
the MMC snap-in is a HUGE pain to configure... Is completely manual... and
not at ALL dynamic. If I can make this work in powershell I can add/remove
servers at will as well create server in mass.

What do you think?

"Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
news:u$eLl530GHA.4580@TK2MSFTNGP05.phx.gbl...
> You need to do a partial name load, and you may find the control use to be
> pretty frustrating within a windows form due to container-related issues
> you would need to handle - but it's doable and DOES need to be done by
> someone, then shared with the rest of us. :|
>
> To load the Windows Forms, you can load an assembly by partial name.
> Here's the function wrapper I use:
>
> # External assembly load declaration
> function add-assembly($name)
> {
> return [System.Reflection.Assembly]::LoadWithPartialName($name)
> }
> #set-alias aasm add-assembly
>
> Here's the line of code that you would then use to add the assembly:
>
> Add-Assembly System.Windows.Forms
>
> I'll take a look through a couple of the custom wrappers I've written for
> the RDP control and post code. It will be all WSF or HTA code, but you'll
> be able to see the sequence of events in what I did, and it may help.
>
>
> "Brandon Shell" <tshell.mask@gmail.com> wrote in message
> news:en2SDw30GHA.3464@TK2MSFTNGP03.phx.gbl...
>> Goal:
>> I want to be able to add ActiveX control in Powershell. Specifically
>> Remote Desktop Control. I am thinking of creating a windows form with RDP
>> controls. I am picturing something kinda like the "Remote Desktops" MMC
>> snap-in. If I can manage to get this working in powershell I can make it
>> much more dynamic than the Snap-in.
>>
>> p.s. Do I need to do something special to be able to create form objects
>> "$tsform = new-object Windows.Forms.Form." I see that /\/\0\/\/ used it,
>> but I get "New-Object : Cannot find type [Windows.Forms.form]: make sure
>> the assembly containing this type is loaded." I would expect this to be
>> loaded.
>>
>
>

Adding the terminal_services newsgroup since I believe there would be
interest over there in this topic.

"Brandon Shell" <tshell.mask@gmail.com> wrote in message
news:uPJjRQ40GHA.1300@TK2MSFTNGP05.phx.gbl...
> The load thing worked great. Thanks.
>
> Now... with RDP control and forms. You are basically saying that it is
> complicated to manage the RDP control within a windows form?

Not excessively so. Here are the two problems I see:

(1) It can take a bit of coding to set up the details of managing control +
form size/resize/scale. This isn't impossible, just takes a bit of work - a
bit more than the static HTML forms I've used takes.

(2) Sessions will end when the PowerShell session ends, since the form will
be hosted by PowerShell. This can be handled a bit more easily if the
hosting application is IE, for example, since it is an independent host
application.

> If that is true, lets take look at a different approach. A -Whatif as it
> were.
>
> If I wrote a cmdlet that created a "master" form with four basic functions
> (StartSession, PlaySession, PauseSession, and StopSession) I could then
> write scripts that would start sessions (in "background") and then I could
> call PlaySession when I need to actually use a session or Pause or Stop
> when im through.

That sounds like a fairly good approach. One point is that you can actually
surface the session data - both initial settings and some current conditions
such as connection status - as an object.

> My Original thought was a master form with two panes (One small one on the
> Left, and a Large One on the Right. Kinda like MMC Snap-in.) The Left pane
> would have the list of servers, the right would contain the currently
> selected servers RDP session. I know this sounds dumb... I mean... why
> dont I just use the MMC snap-in if I like it so. Well... the reason is
> because the MMC snap-in is a HUGE pain to configure... Is completely
> manual... and not at ALL dynamic.

All good reasons. We've talked about some of these issues in the TS
newsgroups before. Let me also mention that given sufficient demand for
tools, the TS program managers have usually been willing to bend over
backwards to help in whatever way they can.

There _are_ some tradeoffs they have on time, security, and demand, which is
why the pre-built toolset is comparatively sparse: although there are lots
of TS users, customized connection tools are generally very low-demand while
also increasing the potential target surface. One of the reasons the ActiveX
control exists, however, is to allow people to do exactly this kind of
thing. It's no accident that the control has all of the features of the
complete TS client executable built into it; the intent is that people
should be able to create their own custom solutions with a minimum of fuss.

> ... If I can make this work in powershell I can add/remove servers at will
> as well create server in mass.
>
> What do you think?

I think this is a _very_ good idea. I've been working on mapping the
properties allowed in RDP files against the ActiveX control properties which
are configurable, trying to consolidate them into an RdpClientConnector
"class" that simply talks to an available control. The connector would be
primarily theoretical, and could be serialized, or exported as an RDP file.
The part I haven't tried handling is embedding it in a Winform and then
making sure that resizing, scaling, and similar properties are handled
correctly between the form and the client control.


> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
> news:u$eLl530GHA.4580@TK2MSFTNGP05.phx.gbl...
>> You need to do a partial name load, and you may find the control use to
>> be pretty frustrating within a windows form due to container-related
>> issues you would need to handle - but it's doable and DOES need to be
>> done by someone, then shared with the rest of us. :|
>>
>> To load the Windows Forms, you can load an assembly by partial name.
>> Here's the function wrapper I use:
>>
>> # External assembly load declaration
>> function add-assembly($name)
>> {
>> return [System.Reflection.Assembly]::LoadWithPartialName($name)
>> }
>> #set-alias aasm add-assembly
>>
>> Here's the line of code that you would then use to add the assembly:
>>
>> Add-Assembly System.Windows.Forms
>>
>> I'll take a look through a couple of the custom wrappers I've written for
>> the RDP control and post code. It will be all WSF or HTA code, but you'll
>> be able to see the sequence of events in what I did, and it may help.
>>
>>
>> "Brandon Shell" <tshell.mask@gmail.com> wrote in message
>> news:en2SDw30GHA.3464@TK2MSFTNGP03.phx.gbl...
>>> Goal:
>>> I want to be able to add ActiveX control in Powershell. Specifically
>>> Remote Desktop Control. I am thinking of creating a windows form with
>>> RDP controls. I am picturing something kinda like the "Remote Desktops"
>>> MMC snap-in. If I can manage to get this working in powershell I can
>>> make it much more dynamic than the Snap-in.
>>>
>>> p.s. Do I need to do something special to be able to create form objects
>>> "$tsform = new-object Windows.Forms.Form." I see that /\/\0\/\/ used it,
>>> but I get "New-Object : Cannot find type [Windows.Forms.form]: make sure
>>> the assembly containing this type is loaded." I would expect this to be
>>> loaded.
>>>
>>
>>
>
>

Any updates on this topic? Sounds interesting.

No. We're still pondering.

"fixitchris" <fixitchris@discussions.microsoft.com> wrote in message
news:A5B08EB7-A609-4E09-9727-192DED50B1A0@microsoft.com...
>
> Any updates on this topic? Sounds interesting.

Hi Alex, good to see you are still around!

What are you up to these days?

-TP

Alex K. Angelopoulos [MVP] wrote:
> No. We're still pondering.
>

Primarily working on administrative frameworks. Some of it is related to TS
management, of course.

"TP" <tperson.knowspamn@mailandnews.com> wrote in message
news:%230Dtw9BCHHA.992@TK2MSFTNGP03.phx.gbl...
> Hi Alex, good to see you are still around!
>
> What are you up to these days?
>
> -TP
>
> Alex K. Angelopoulos [MVP] wrote:
>> No. We're still pondering.
>>
>