Forum / Remote Desktop Manager - PowerShell Repository

Thoughts about the PS cmdlets

  • Create an Issue
  • Cancel

Now that I have my access to the forums straightened out.. These are my thoughts based on trying to repopulate a new datasource with connections.

[This was written after a particularly frustrating session of trying to populate a new list of RDM sessions]

Conceptually, the idea of having powershell cmdlets available to configure & manage the product is fantastic.
The implementation seems overly complex? The cmdlets don't follow best practices, and the way the parameters are
used, they are extremely difficult for the "average" scripter to utilize, and even from a programming perspective,
much of it is counterintuitive. The documentation is also very difficult to locate & interpret.. it needs a lot of help.

1. The keywords for some of the parameters do not match up with the 'standard/best practice'
In specific, I am looking at the '-kind' parameter. Every other powershell snapin/provider I have run into uses -type in this situation.

2. The keywords that have specified acceptable parameters (again, like -kind) are not set up to automatically populate
the keywords when hitting 'tab', but -kind and the others like it do not. When I write scripts, I always use the ValidateSet
configuration for this purpose.

3. The 'get' commands normally return a singular item, and leave it to the scripter to handle the collections.
In the case of get-rdmsession, it doesn't take any parameters, and automatically returns the entire collection.
To me, this is grossly inefficient for processing, and counterintuitive to what everyone else does. Normally, I would expect
to be able to pull a specific "session" by some sort of unique ID, or if the name matched others, then I would expect
it to pull all the ones that match. I would also expect to be able to take multiple parameters to "filter" the results.

For Get-RDMSession, I would expect something like:

get-rdmsession -id <guid>
- or-
get-rdmsession -hostlabel <name>
- or -
get-rdmsession -name <name>

I would also hope it would provide a -filter to use for misc. parameters as opposed to being forced to use a
"| where-object" clause.

4. The new-rdmsession is almost as bad as the get-rdmsession. It should produce a singular object, and be
easily able to handle items from the pipeline. It should return its own object, and should *not* require
the user to set a variable to it, and then use a 'set' command in order to save it!
I should be able to create a single session from new-rdmsession, and be able to easily process it.
Also, the new-rdmsession could support some sort of parameter like -confirm, rather than having to
use the pipeline with a set command. That makes the whole process far more difficult.

For example, I would like to be able to do something like this:
10..99 | foreach-object { new-rdmsession -name "Server$_" -host "Server$_" -connectiontype rdp -group 'App Servers' -AdminConsole }

The new-rdmsession cmdlet should support a -force switch to force the creation of folders/subfolders. Right now,
it does this by default - I had to stumble on it.

5. The set-rdmsessionproperty should automatically fill out the available options when hitting tab. Something like:
set-rdmsessionproperty -property <tab> --> becomes set-rdmsessionproperty -property HostName <tab> --> becomes
set-rdmsessionproperty -property DisplayName.
This could also provide a -confirm switch to force a confirmation.

6. The -norefresh switch should be the default, and then use something like -refresh to provide that capability.

7. The group names really should be much more easily addressable. See the new-rdmsession example above..
I tried this, and frequently it would fail.

8. There should be a separate new-rdmgroup cmdlet as opposed to lumping it into new-rdmsession. This was
completely counterintuitive.

9. One of the cmdlets talks about reverse-engineering an XML file to identify the properties. This is just
a poor experience. The help for the cmdlets should explain all of this, or at least have an 'about_'
help file.

10. There needs to be a default way to load the snapin with a simple add-pssnapin. The scriptlet that is provided
on the website is clunky, and is not a good way to do this. The loading scriptlet kept generating errors
for me, until I hacked the registry.

11. Installing new versions of the RDM cmdlets needs to remove the old versions.. I've upgraded a few times, and
now have 5 different versions of the cmdlets on my system. The 2nd to oldest one was loading for me until
I hacked the registry to force the correct version to load. Or at least make it easier to select a version to load.

12. There should be some sort of copy-rdmsession/copy-rdmgroup commands. Once a session or group is created, and
configured correctly, it should be simple to make new sequential copies.

13. The syntax for a direct property assignment needs to be fixed. It is very counterintuitive to force someone to
use a $variable = <setting> | set-rdmsessionproperty -name <name> -value $variable type of construct.

14. The exported files need to have the option to be unencrypted/unscrambled. (See the above reference to exporting to XML)

15. The export should also allow you to specify a set of objects, or a parent folder to be able to pick up and export any number
of sessions/groups.

16. There didn't seem to be a clear parameter for setting password inheritance. [I finally found Maurice's example to do this, but to me, it is still overly complicated.] I'd want something like this:

set-rdmsession -property Credentials -value Inherited
- or -
set-rdmsession -property InheritCredentials -value $true

17. I should be able to filter the get-rdmsession cmdlets with a -parentfolder type of parameter

18. The session & group objects need to have a better unique quality as opposed to the guid which is very
difficult to type out. For example, the Citrix cmdlets offer a -browsername as the primary identifier for most of
their commands. In the case of RDM, I would want the name to be unique, and then make better use of the hostlabel
parameter, or use a -displayname property. Those would be far easier to deal with.

19. There are very few *good* examples to follow to accomplish various tasks, and most of the documentation is spotty.

Clock5 yrs

Thank you for the post. I have entered several feature/improvements requests.

David Hervieux


Clock5 yrs